#snappy 2016-02-29
<a__> hi
<a__> the snappy guide starts off with the command snappy info, but in fact I get a login prompt - what is the username/password?
<didrocks> good morning!
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks
<dholbach> didrocks, shall we talk tomorrow at 10:30 or 11?
<dholbach> not sure if we'll require thibautr, but we could invite him too
<didrocks> dholbach: not possible to have one catching up discussion today even?
<zyga> good morning :)
<didrocks> the earlier, the better ;)
<didrocks> hey zyga
<dholbach> oh sure... maybe in the afternoon?
<didrocks> dholbach: good to me, pick a time
<dholbach> 16:30 or something?
<didrocks> dholbach: hum, I have to leave at 17:15 today
<didrocks> so that's not going to work I'm afraid :p
<dholbach> ok, that should work - we'll make it quick then ;-)
<dholbach> oh?
<dholbach> can't we talk for 30m?
<didrocks> dholbach: hum, I would prefer that we schedule it before, so that I don't have rush of last minutes email before leaving tonight
<dholbach> 15:30 - 16:00 then?
<didrocks> wfm!
<didrocks> will david c. be around?
<didrocks> (to show up what he worked on if he has anything already?)
<dholbach> I don't know
<didrocks> but you know about the progress, right?
<dholbach> I thought we'd also talk about the "getting feedback" bit I mentioned in my mail
<dholbach> I know what I worked on
<didrocks> dholbach: I got feedback from most of managements (olli, rickâ¦) at mwc
<dholbach> right...
<ysionneau> morning!
<noizer> Good morning
<noizer> Hi guys, I have a question about skills
<noizer> can i make my own custom skill
<noizer> The skill just need to execute the wrapper executables of an other snap
<noizer> Is someone active on the last day of februari xD
<zyga> thanks mvo  :)
<zyga> noizer: not directly, you'd have to discuss this and propose a pull request to snappy
<zyga> noizer: and I suspect that running an exec from one snap from another snap is a no-go
<zyga> noizer: perhaps if you tell us what the goal is, we can suggest an alternative
<mvo> zyga: yw!
<zyga> noizer: and FYI, today skills are called interfaces :)
<noizer> hahah right xD
<zyga> mvo: can I do something to help land https://github.com/ubuntu-core/snappy/pull/518
<noizer> zyga I will make something how i can explain my problem to you
<zyga> mvo: ?
<zyga> noizer: note that you can prototype a new interface in isolation, but you won't be able to use it in snaps that go into the store really
<zyga> noizer: so the earlier you know what you need the easier the road ahead is
<noizer> zyga I know what i want just i will make a quick draw on my whiteboard en explain it to you
<mvo> zyga: if it looks good I think the next step is to update all the integration test packages and rerun the integration test suite. it seems jenkins is a bit unhappy today so maybe not the best time? I would really like to land this only if jenkins is green
<mvo> zyga: maybe you can check if https://github.com/mvo5/snappy/commit/806756730b1a04ace671aea202fb0c8517b46131 is ok?
<mvo> zyga: no more git grep -i skill so we should be good in the branch :)
<zyga> mvo: sure, understood
<zyga> mvo: as for jenkins, let's see what happens next, if all else fails we can run integration tests locally
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/546
<noizer> zyga http://imgur.com/orqlhRD. Here you got a easy drawing how it needs to work. In the middle there is a main snap. This snap needs to controll all installed snaps. So he needs to start stop other snaps. So an very easy interface for users
<noizer> But is would be easy that i can call the wrapper out of my own main snap
<zyga> noizer: so you _can_ run other apps
<zyga> noizer: in the same snap
<zyga> noizer: you don't need interfaces for that
<zyga> noizer: I would just suggest to call the raw executables, not the snappy-generated wrappers
<zyga> noizer: try that
<noizer> is that possible?
<zyga> noizer: yes
<noizer> hmmm that should be nicee
<zyga> mvo: offtopic, upstream merged go-flags patch
<zyga> mvo: it's low priority but if I prepare the debian patch, will you sponsor this for me?
<noizer> but is it not a little bit better to call the wrapper?
<zyga> noizer: no
<zyga> noizer: in fact you cannot do that
<noizer> zyga ok xD
<mvo> zyga: I wonder if we should just push a new upstream release maybe? how much else did change?
<noizer> zyga thx
<zyga> noizer: the wrapper translates unconfined and vanilla environment to the confined snappy environment
<mvo> zyga: last release in xenial is 20160218
<zyga> mvo: thanks, I was about to complain about lack of tags upstream
<ogra_> mvo, can we sync the version numbers among the arches ? i have actually a script i could run by cron (as interim) that could convert the tarballs daily
<ogra_> but with that we end up with the same version string across all snaps (which is probably wanted anyway, but currently the store has massively varyimg versions for ubuntu-core)
<mvo> ogra_: yeah, I like that
<zyga> mvo: not much: http://paste.ubuntu.com/15242051/
<zyga> mvo: (it took me forever to compute that, failing at the github ui first)
<mvo> zyga: that looks like a new upstream is the simplest option
<zyga> mvo: there's my patch and a trivial fix
<mvo> so lets do this route
<zyga> Chipaca: http://paste.ubuntu.com/15242182/
<zyga> Chipaca: some commands use 3rd person objective while some commands use imperative mode
<zyga> Chipaca: what's the mode we want?
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/547
<sergiusens> zyga, mvo has the interfaces work landed into an image?
<mvo> sergiusens: not yet, there is a branch for this but its not in yet, but almost
<zyga> sergiusens: some, most notably old-security is still not merged
<zyga> sergiusens: I suspect it will be all in today
<sergiusens> zyga, mvo thanks; I'll keep track of https://bugs.launchpad.net/snapcraft/+bug/1549427
<ubottu> Launchpad bug 1549427 in Snappy "migrate from skills to interfaces" [Undecided,In progress]
<sergiusens> so please update when it makes it
<zyga> sergiusens: I saw that, I'va ssigned part to myself
<kyrofa> Good morning
<noizer> Good morning xD
<ogra_> moaning ...
<kyrofa> ogra_, not a good morning?
<ogra_> kyrofa, lots of mail from last week to wade through ... the curse of having been at a conference
<kyrofa> ogra_, oh brutal, yeah I bet
<ogra_> (742 MPs in my "merges" mail folder ... 1200 in "bugs" etc etc ... )
<kyrofa> ogra_, hey, quick question-- I just flashed the dragon image onto an SD card, but when I boot the lights just remain solid and nothing happens. I was about to connect the serial board to see if it's complaining about anything, but have you seen that?
<kyrofa> Yikes
<ogra_> kyrofa, hmm, did you use the very latest of my images ?
<ogra_> there was an issue with the board when no serial board was attached, that was worked around in the latest image
<kyrofa> ogra_, dragonboard-rolling-edge-251.img.xz ?
<ogra_> (and will be actually fixed with the next u-boot (thanks ppisati btw !!!) )
<ogra_> kyrofa, oooh, no, thats ancient
<kyrofa> ogra_, that might be the issue :P
<ogra_> and my other one was moved away prior to the dragon announcement
<kyrofa> ogra_, no longer here then? http://people.canonical.com/~ogra/snappy/dragonboard/
<ogra_> i wonder if i can put it back ... sadly olli is off so i cant ask him for permission
<ogra_> mvo, what happened to the branding of the shell prompt that we had in the 15.04 images, is that gone for good or just missing yet in all-snaps
 * ogra_ finds it hard to actually know which board he is working on now that all of them say "ubuntu@localhost" ... with a handfull of boards runnning and a ssh terminal open on each it gets quite confusing
<mvo> ogra_: stevebiscuit was working on the branding part recently but let me double check about the shell branding
<ogra_> it is indeed only an issue if you run multiple different boards ... so perhaps not that important
<noizer> zyga I tried it now to call an executable from an other snap but it doesn't work
<mvo> ogra_: uploaded a fix, will be part of the next ubuntu-core update
<ogra_> mvo, cool
 * ogra_ remomembers he needs to add rfkill to writable-paths before next os snap 
<ogra_> done :)
<zyga> noizer: you cannot run apps from other snaps, just from your own
<zyga> noizer: what do you want to do and why?
<zyga> noizer: maybe I can help somehow
<ogra_> yeah, the correct answer would be to bundle everything you need into the same snap and manage it internally there
<noizer> zyga I explained you earlier this day xD but here got it . I want a main snap. This snap needs to start other programs (snaps)
<noizer> zyga http://imgur.com/orqlhRD
<zyga> noizer: that diagram confused me
<zyga> noizer: it has one snap and many apps
<zyga> noizer: that _is_ allowed
<zyga> noizer: running any apps from other snaps is not
<zyga> noizer: if you control all the snaps just bundle everything
<zyga> noizer: there are no "library snaps"
<zyga> noizer: note that snap is the package
<zyga> noizer: and app is something you can run in a snap
<noizer> zyga ow wait you got 100 snaps with 1 main snap this main snap can start every snap on you device
<zyga> noizer: snap == package, app == executable
<zyga> noizer: a snap cannot have any snaps
<noizer> sorry I did some mistakes for my vocabulary xD
<zyga> noizer: so do you know what I mean now?
<noizer> wait is that possible you have now the OS and that i build everything on my OS and then install snaps and that the build on my OS (not in a snap) can manage the snaps
<noizer> zyga I know what you mean but I don't think you understand me correctly
<zyga> noizer: wha you describe sounds more like ubuntu personal
<zyga> noizer: where you just have a desktop and can pick apps to run
<zyga> noizer: currently we don't allow this in ubuntu core
<noizer> yes but the advantage of snappy that every snap is seperate from each other
<zyga> noizer: I'd suggest emailing snappy-app-devel mailing list with the details of what you want to build
<zyga> noizer: (that is true in personal as well)
<zyga> noizer: and perhaps others can suggest what to do
<noizer> zyga ok I will give it a shot
<ogra_> mvo, hmm, did the all-snaps u-d-f change the --install option ? i just built a dragonboard image with --install webdm.canonical ... it finished fine and i also saw it installing webdm ... but:
<ogra_> ubuntu@localhost:~$ snappy list|grep webdm
<ogra_> ubuntu@localhost:~$
<ogra_> http://paste.ubuntu.com/15243621/ is the build log
<mvo> ogra_: hm, no recent changes there
<ogra_> weird
<mvo> ogra_: anything in ls /snaps?
<ogra_> ubuntu@localhost:~$ ls /snaps/webdm.canonical/
<ogra_> 0.15
<ogra_> ubuntu@localhost:~$
<ogra_> no current link
<ogra_> GRRR !
<ogra_> Rejected:
<ogra_> Unable to find distroseries: xernial
<ogra_> Further error processing not possible because of a critical previous error.
<ogra_> ubuntu-core-config (0.6.38) xernial; urgency=medium
 * ogra_ fixes
<ogra_> silly xernial ... doesnt exist :P
<sergiusens> fgimenez, seems like the jenkins thing is not completely fixed; I guess you can hand over to elopio_ now
<sergiusens> but there was only 1 succesful run so far
<sergiusens> ogra_, what are you pushing though? maybe push to distroseries 'ogra' ;-)
<kyrofa> sergiusens, yeah what's going on with https://github.com/ubuntu-core/snapcraft/pull/344?
<sergiusens> kyrofa, seems some of the backend is dead; I had one succesful run this morning though
<kyrofa> sergiusens, I tried all weekend. Made me cry
<ogra_> sergiusens, indeed, i should push to omnious ogra :)
<sergiusens> kyrofa, same thing; the error doesn't even help
<kyrofa> sergiusens, no kidding
<sergiusens> didrocks, here's the thing I'd mention I'd try out from SCaLE in case you want to look; it is very deep dive https://github.com/ubuntu-core/snapcraft/pull/335
<sergiusens> kyrofa, elopio_ since weekly is cancelled I guess we will do a regular standup
<kyrofa> sergiusens, sounds good
<didrocks> sergiusens: oh nice! I'm going to give it a look (tomorrow morning probably)
<fgimenez> sergiusens, elopio_ yep, the instances still look bad http://paste.ubuntu.com/15243858/
<sergiusens> didrocks, thanks; any ideas for improvement welcome
<sergiusens> fgimenez, have you tried pinging IS directly on #is?
<fgimenez> sergiusens, sure :) http://paste.ubuntu.com/15243874/
<sergiusens> fgimenez, oh, so end of week maybe? :-P but really :-(
<fgimenez> sergiusens, hopefully it won't take too long, we have had issues like this before and they were solved quite quickly
<kyrofa> sergiusens, dang... maybe start running locally and merging without?
<kyrofa> sergiusens, I'll be 2 minutes late
<sergiusens> kyrofa, oh, integration tests happening there or not?
<kyrofa> sergiusens, yeah they will
<kyrofa> I'll get the examples tests running locally, merge that other one, then write the integration tests and ping you
<ysionneau> zyga: any idea how to run a snap app in gdbserver?
<ysionneau> the app segfaults and I wanna know why
<zyga> ysionneau: hmmm, interesting
<ysionneau> I already have gdbserver on the target, but since there is the sandboxing...
<zyga> ysionneau: you can patch the wrapper script
<ysionneau> and I cannot run the wrapper with gdb
<ysionneau> ah yes
 * ysionneau stupid
<zyga> ysionneau: or just setup a manually crafted script that runs gdb and your app via ubuntu-core-launcher
<zyga> ysionneau: or try it from the unconfined shell first, maybe you can test it better this way
<ysionneau> my snap needs some lib
<ysionneau> so I cannot run it without the wrapper which sets all the env
<zyga> ysionneau: you can
<zyga> ysionneau: the wrapper isn't magic, look at what it does
<zyga> ysionneau: just set the right environment variables
<zyga> ysionneau: you can try the whole wrapper with or without ubuntu-core-launcher (again, by manually hacking the wrapper script)
<ysionneau> ack
<zyga> ysionneau: though the launcher (not the wrapper, the actual launcher) does some interesting things that may be a factor too
<zyga> ysionneau: I'd suggest trying without the launcher, just with altered environment
<zyga> ysionneau: and do take advantage of classic dimension, apt-get install all the support tools and use them on the outside
<kyrofa> ysionneau, or grab a core dump and analyze it with gdb separately
<ogra_> ysionneau, you can use the classic shell and attach to the PID as well :)
<ogra_> (oh, zyga said so already)
<ace139> hi, I just installed snappy core for my RPi2, as it does not come with wifi support out of the box, could someone tell me what packages I need to install to get the wifi working ?
<ogra_> ace139, what wifi card is that ? the hw should definitely be recognized on the latest images
<zyga> ace139: it should work out of the box, just edit /etc/network/interfaces.d/wlan0
<zyga> ace139: and add typical ifupdown wlan config there
<zyga> ace139: quick test is to run ifconfig -a
<ogra_> ubuntu@localhost:~$ cat /etc/network/interfaces.d/wlan0
<ogra_> allow-hotplug wlan0
<ogra_> iface wlan0 inet dhcp
<ogra_>     wpa-ssid grawert.net
<ogra_>     wpa-psk XXXXXXXX
<zyga> ace139: if you see wlan0 or something like that that will be a good sign that the hardware is supported
<ogra_> that is what i use here (on a dragonboard with builtin WLAN though)
<ogra_> (and indeed XXXXXXX is actually my wpa key)
<ace139> ogra_, zyga the wifi adapter I am using, is not sensed somehow.
<ace139> I have made changes to the interfaces.d/wlan0
<zyga> ace139: does it work on your regular ubuntu
<ace139> zyga, yes, and on raspbian too
<ogra_> ace139, what chipset is that then, and what image (old 15.04 or the newer 16.04 ones)
<ace139> ogra_, 15.04
<ogra_> (though both latest images should ship a ton of wifi drivers)
<zyga> ace139: try 16.04
<ace139> zyga, can I get a link ?
<zyga> ace139: https://github.com/zyga/devtools/blob/master/ubuntu-image
<zyga> ace139: try that :)
<ogra_> ace139, the latest and greatesd should be at http://people.canonical.com/~mvo/all-snaps/
<ogra_> or try zyga's tool to build one
<ace139> zyga, ogra_ thanks, let me try
<zyga> :)
 * zyga smells raspberry pi 3 in the mail tomorrow
<zyga> snif snif
<zyga> fresh hardware :)
<ogra_> tell us about the wlan then :)
<zyga> I really want to be able to build my gadged and kernel nsaps
<zyga> snaps*
<ogra_> its a shame it cant actually do 64bit from the start
<zyga> for my work on interfaces and for doing community ports of other boards I have
<zyga> ogra_: hehe, given what pi1 was I'm super positive they will get there
<ogra_> definitely
<zyga> ogra_: remember how crappy it was in the beginning
<zyga> ogra_: and it makes sense to ship hardware before the software
<ogra_> i dont, i only started using pi's with pi2
<zyga> ogra_: well, all the blobs, the uncertain situation of the kernel
 * ogra_ doesnt care much about HW that cant run ubuntu :P
<mojo> hi
<zyga> ogra_: now it's all upstream and the GPU is getting fantastic work done in the open
<zyga> mojo: hey
<ogra_> yeah
<ogra_> dragonboard actually has a free driver though :)
<zyga> ogra_: is dragonboard using ardeno or something else?
 * zyga lost track
<ogra_> (but a similar crappy closed bootloader made out of blobs)
<ogra_> zyga, yeah ... so freedreno should just work
<zyga> ogra_: mmm, nice
<zyga> it's amazing what so few people can make
<ogra_> yeah
<zyga> all the gpu hacking, folks fit in a bigger lift together
<Guest36587> a quick questions guys, can ubuntu core snappy run on a i386 system?
<zyga> (hope they use the stairs though)
<zyga> Guest36587: yes
<ogra_> i wish i would have been able to go to linaro connect to actually talk to the people to get this working in snappy OOTB
<zyga> Guest36587: use https://github.com/zyga/devtools/blob/master/ubuntu-image to build a 16.04 based image
<zyga> Guest36587: good luck
<zyga> ogra_: the one in bangalore?
<zyga> ogra_: when is it? I think ~week(s) from now?
<ogra_> yeah, i386 didnt get much attention yet ... might be a matter of luck
<ogra_> zyga, right
<Guest36587> can it be installed as regular ubuntu image on a SD card?
<ogra_> Guest36587, you dd it to the SD and boot
<zyga> Guest36587: just "dd" it to anything that your machine boots from, it can be a HDD as well
<ogra_> right
<zyga> Guest36587: or you can use it to start a VM
<zyga> ogra_: is it too late for you to go?
<ogra_> zyga, asac stole my ticket :P
<zyga> aaahh
<zyga> hehe, I knew that asac was going
<Guest36587> ok. thank you i will give it a try.
<ysionneau> 16:16 < ogra_> ysionneau, you can use the classic shell and attach to the PID as well :) < yep but it's not a daemon and it crashes right away
<ogra_> zyga, but then asac will have to implement freedreno in the dragonboard images, so all is fine :P
<zyga> ysionneau: use gdb and run your program from gdb, then you can see why
<zyga> ysionneau: or enable core dumps and inspect the core later
<zyga> ogra_: haha, I'm sure asac will love that
<ogra_> for sure :)
 * zyga spent all weekend staring at elf sections and program headers and x86 disassembly
<zyga> but core files is something I have yet to play with
<zyga> I haven't touched a core file in a decade
<Guest36587> when running the script i get error unenxpected  "(" error on line 391
<zyga> Guest36587: oh, let me see
<zyga> Guest36587: hmm, the script has 214 lines
<zyga> Guest36587: can you show me what you did please?
<zyga> Guest36587: if I broke it I'll happily fix it :)
 * zyga should add travis CI to the script
<Guest36587> ok i did copied the script selected options i386 - then vanilla
<zyga> Guest36587: can you pastebin the output of the script?
<zyga> Guest36587: or just the error perha
<zyga> ps
<Guest36587> ok sec
<Guest36587> Building image... /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391: 1: /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391: Syntax error: "(" unexpected
<zyga> Guest36587: ahhh
 * zyga looks
 * zyga tries to reproduce
<zyga> Guest36587: what is your host OS?
<Guest36587> ubuntu 15.04 running on vbox
<zyga> Guest36587: I was testing this on Ubuntu 16.04 (xenial)
<zyga> Guest36587: I suspect 15.04 works as well though
<zyga> I can check that in a moment, trying to reproduce the issue now
<Guest36587> well i can install xenial and give it a try
<zyga> Guest36587: can you check what is inside /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391
<zyga> Guest36587: and perhaps one more thing:
<zyga> Guest36587: can you pleas add 'set -x' to the top of the script (without the quotes)
<Guest36587> seems like a data file
<zyga> Guest36587: re-run it and pastebin the whole log
<zyga> Guest36587: ok
<zyga> Guest36587: my run will finish in a moment
<Guest36587> ok let me set debug on it
<zyga> Guest36587: so far all is good
<zyga> (a few more minutes)
<kyrofa> ogra_, since the pi3 has a 64-bit processor, can we still run 64-bit ubuntu core on there even if the standard OS is only 32-bit?
<Guest36587> ok so running debug on script:
<Guest36587> + udf=/root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 + chmod +x /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 + [ -n  ] + [ -n  ] + [ -n  ] + test -z ubuntu-core.canonical + test -z canonical-pc-linux.canoni
<zyga> Guest36587: thanks
<zyga> Guest36587: please pastebin everything
<zyga> Guest36587: (copy paste and paste it to paste.ubuntu.coM)
<Guest36587> Building image... + exec sudo /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d743ee368b2337f956765670f4128210dca7df71501035f7391 core rolling --channel edge --kernel canonical-pc-linux.canonical --os ubuntu-core.canonical --gadget canonical-i386.canonical -o i386.img /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f1
<Guest36587> ca7df71501035f7391: 1: /root/.cache/ubuntu-image/blob.d8acf6b199a0a73def00dd61302afc99718cee101ec0c8d2ef845168ca9b5820ed943e90f17a6d7
<Guest36587> and the rest of it
<Guest36587> he have a limited buffer here
<zyga> Guest36587: it just built fine for me
<zyga> Guest36587: you can try this:
<zyga> Guest36587: ./ubuntu-image --no-developer-image i386
<zyga> Guest36587: ./ubuntu-image --no-developer-image i386 | pastebinit
<zyga> Guest36587: ^^ this command will be non-interactive (apart from sudo) and will paste the output (though not the error streams)
<zyga> Guest36587: ./ubuntu-image --no-developer-image i386 2>&1 | pastebinit
<zyga> perhaps this one
<zyga> Guest36587: for example this is a session I just ran to test it:
<zyga> http://pastebin.ubuntu.com/15244574/
<Guest36587> hmmm
<Guest36587> i'm missing something here
<Guest36587> ubuntu-image i guess
<Guest36587> :D
<zyga> ?
<Guest36587> i need to install it
<zyga> ubuntu-image should run without any extra deps beyond what ubuntu-device-flahs (which it downloads) requires
<Guest36587> somehow
<zyga> Guest36587: the only thing that I can think of are tools like kpartx
<Guest36587> i belive its simpler then that ;)
<zyga> oh?
<Guest36587> yup i dont have ubuntu device flash installed :O
<Guest36587> noobie
<Guest36587> ;)
<zyga> Guest36587: that is normal
<zyga> Guest36587: ubuntu-image downloads a special version
<zyga> Guest36587: the version you can install won't work (though perhaps it will help to install other dependencies)
<zyga> Guest36587: try installing it anyway and re-run ubuntu-image
<Guest36587> but wait i was expecting that after installing ubuntu-device-flash, ubuntu-image would get installed
<Guest36587> but no it seems that i need some aditional software
<zyga> Guest36587: why would you expect that, ubuntu-image is a script that is not packaged anywhere
<zyga> Guest36587: I'm not sure what happened or what actually caused that error to show up, try again (after you've installed ubuntu-device-flash)
<zyga> Guest36587: or get a pre-made image from http://people.canonical.com/~mvo/all-snaps
<zyga> (AFAIR)
<Guest36587> thank you
<zyga> Guest36587: good luck :)
<Guest36587> ;)
<ysionneau> zyga: if I want to allow an app to open some usr/lib/lib.so (via dlopen), I added /usr/lib/lib.so in the read-paths in security-override, is it the right way?
<ysionneau> I cannot give the absolute path since it's in /snaps/name/some_hash/
<dholbach> kyrofa, sergiusens: with the ros plugin gone, should the ros doc go as well?
<zyga> ysionneau: hmmm
<zyga> ysionneau: you _should_ be able to dlopen anything in your snap
<kyrofa> dholbach, oh no-- there were two ros plugins, the useless one was removed
<dholbach> ah no... it's updated
<ysionneau> fyi when the app dlopen, it segfaults
<dholbach> thanks kyrofa
<kyrofa> dholbach, though the one on dev.ubuntu.com needs to be updated-- want me to do it?
<zyga> ysionneau: I assume /usr/lib/lib.so is actually relative to your installed snap
<dholbach> kyrofa, no, I'll do it
<zyga> ysionneau: what's the deny you get (tip, check syslog)
<kyrofa> dholbach, okay :)
<dholbach> kyrofa, working through the whole list now :)
<kyrofa> dholbach, heh, good luck!
<ysionneau> I get this in syslogs zyga http://pastebin.com/szMDAht0
<ysionneau> I cannot see any deny, except from ulogcatd
<ysionneau> the name of my app here is "wifid"
<ysionneau> if in my code I do dlopen("/usr/lib/libfoo.so"); it will be able to open a lib in /snaps/wifid.sideload/INcVRgETGKeR/usr/lib/wifid/ ?
<ysionneau> or should it be dlopen("libfoo.so") :o
<zyga> ysionneau: you don't run with a chroot, you have to read appropriate $SNAP.. environment variable and dlopen stuff relative to that
<ysionneau> oh, so the app needs to know it runs in a "snap" env
<zyga> ysionneau: yes
<ysionneau> that's not transparent
<ysionneau> ok
<zyga> ysionneau: or use a relative path
<zyga> ysionneau: btw, offtopic: Feb 29 16:11:23 localhost kernel: wifid[1240]: unhandled level 1 translation fault (11) at 0x68730000, esr 0x83000005
<zyga> ysionneau: this doesn't look good
<ysionneau> it crashes in the dlopen()
<zyga> ysionneau: we've patched some common things to understand snappy better (bluez, network-manager), have a look at the approach taken there
<zyga> ysionneau: basically we look at the relevant environment and change compiled-in constants to variables/functions
<ysionneau> like env variable?
<plars> ev: are things happier with spi today?
<ysionneau> btw when I run as a non-root my snappy app I get this weird message now =>  mkdir: cannot create directory â/home/ubuntu/snaps/wifid.sideload/INcWOCRAPaVTâ: permission denied
<zyga> ysionneau: yes, exactly
<zyga> ysionneau: that looks like an outdated security profile, it was fixed a while ago
<zyga> ysionneau: if that's on 16.04 then just do sudo snappy update and reboot
<zyga> ysionneau: if that persists bug jdstrand_ about it (it should work)
<kyrofa> zyga, if it was run as root then the permissions won't work for non-root
<zyga> kyrofa: if it was run as root then it would have $HOME set to /root
<ysionneau> ah yes it's 16.04
<zyga> kyrofa: we don't do what happens on ubuntu, "sudo foo" runs with home set to /root
<zyga> kyrofa: same with background apps (services)
<kyrofa> zyga, you sure about that? When was that change made?
<zyga> kyrofa: yes
<zyga> kyrofa: a while ago, it was announced on snappy-devel by gustavo
<ysionneau> sudo snappy update just returns to shell
<zyga> ysionneau: which version do you have (of ubuntu-core) (tip: snappy list)
<ysionneau> 2016-02-22 16.04.0-10.armhf
 * zyga checks 
<ysionneau> it's weird because I could swear a few minutes ago I was able to run it as non-root without having this weird error
<zyga> hmm, odd
<zyga> and you don't see DENIED errors in syslog?
<kyrofa> zyga, so bug #1466234 is resolved?
<ubottu> bug 1466234 in ubuntu-snappy (Ubuntu) "Apparmor denial for access to SNAP_APP_USER_DATA_PATH as root" [Critical,Triaged] https://launchpad.net/bugs/1466234
<ysionneau> hmmm or maybe I was root previously ...
<zyga>  ohhhh
<zyga> kyrofa: perhaps not :)
<zyga> kyrofa: jdstrand_ would konw
<kyrofa> zyga, :)
<zyga> know*
<zyga> kyrofa: but it is consistent with what I said (as in background apps seeing /root not /home/ubuntu)
<ysionneau> zyga: that's the last syslog lines http://pastebin.com/YU2zAApz
<zyga> kyrofa: just another bug :)
<kyrofa> zyga, indeed, services run as root and use /root. However, unless that bug is fixed sudo works like it always has
<zyga> I see Feb 29 16:27:35 localhost kernel: audit: type=1400 audit(1456763254.990:16): apparmor="DENIED" operation="open" profile="ulogcatd.sideload_foreground_INcOORXgeaYG" name="/sys/devices/virtual/misc/ulog_main/logs" pid=1434 comm="ulogcat" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> kyrofa: true, true
<kyrofa> (and $HOME=/home/ubuntu)
<zyga> ysionneau: what is /sys/devices/virtual/misc/ulog_main/logs?
<ysionneau> that's related to the ulogger kernel module we have
<ysionneau> it's some kind of android logcat driver clone
<ysionneau> I'm running ulogcat because wifid is printing debug to this
<ysionneau> that's how I could trace it was going fine until doing the dlopen()
<zyga> ok
<zyga> ysionneau: I'm not sure what's going on TBH, I don't see any other denies there and it seems you are just crashing later
<zyga> ysionneau: try with gdb
<ogra_> kyrofa, seems the kernel lacks any support for 64bit yet, so for now it is 32 all the way ... once broadcom released patches we should be able to run both
<kyrofa> ogra_, alright good to know, thanks :)
<ogra_> (though the device comes with the same set of drawbacks the pi2 or pi1 had ... like overloaded USB hubs etc ... )
<ogra_> seems the design didnt change much
<ogra_> (except that you now also have a BT and WLAN device eating up your USB speed)
<zyga> ogra_: pi2 has much better electric stuff around usb hub as compared to pi1
<zyga> ogra_: otherwise agreed :)
<ogra_> zyga, better ... yeah ..
<zyga> ogra_: well, it doesn't die of overcurrent when you plug a dongle anymore
<ogra_> does it survive taking pictures with flash now or is it still shy ? :P
<zyga> ogra_: hehe not sure, I'd have to look if they changed it over from bare die
<ogra_> i guess a cheap layer of paint would even already help
 * zyga has only 3 more patches to rebase
<zyga> woot :)
 * ogra_ is sad to see kyrofa removed the useless ros plugin ... now people cant build useless robots anymore 
<kyrofa> ogra_, :P
<ogra_> :)
<sergiusens> zyga, I thought you weren't allowed to rebase ;-)
<ogra_> stuck in spain forever :)
<zyga> sergiusens: it's my demo branch
<zyga> ogra_: hehe
<zyga> sergiusens: I love to rebase :)
<zyga> and merge would be hell with all the renames
<ysionneau> I'm able to reproduce the issue with a small binary which only does printf() + dlopen()
<ysionneau> the segfault + the need to run as root
<zyga> ysionneau: plesae file a bug and attach that to the report
<ogra_> hmm, dlopen ...
<ogra_> does that respect LD_LIBRARY_PATH at all ?
 * ogra_ has a blurry recollection there was some issue with dlopen
<zyga> ogra_: doens't n-m use dlopen?
<ogra_> no idea
<tedg> zyga: I was looking at the interfaces REST interface, and I think the connections object needs an "app" field as well, no?
<zyga> tedg: hey, mmm, we know about apps internally but we're not exposing that over the REST API
<tedg> zyga: We need to know about it externally :-)
<zyga> tedg: technically each plug and slot knows about apps that are affected
<tedg> zyga: Specifically so we know which apps we can launch.
<zyga> tedg: sure, please raise this with gustavo, I'm sure we can do this
<zyga> tedg: I actually explicitly erase this so doing it should be simple
<ysionneau> I'm not entirely sure if this bug comes from my environment or not
<tedg> Seems like he's not here.
<ysionneau> maybe it's because of my build system (alchemy)
<zyga> tedg: hmm?
<zyga> tedg: who is "we" there?
<tedg> zyga: UAL
<zyga> tedg: all apps can be launched, no?
<zyga> tedg: in any case, I can trivially do this if it helps you out
<zyga> tedg: I have a big overhaul branch that fixes this
<zyga> tedg: and to expose apps I'd litterlaly have to write two lines
<zyga> tedg: I can give you a branch for testing if you're interested
<tedg> zyga: Cool. I need to get more basics working first, so you may land it before I would get ready for it.
<tedg> zyga: But I'll ping you if that becomes my blocker.
<zyga> (plus all the tests that it would affect :)
<zyga> tedg: cool
<tedg> Heh, tests are always a problem ;-)
<zyga> tedg: as a sanity check: you'd GET /2.0/interfaces
<zyga> tedg: and you'd see a single object having {"plugs": ..., "slots": ...}
<ysionneau> if I package a libc and libdl in my snap, will it use the libc of the system? or the one I packaged in my snap?
<zyga> tedg: each of those dots would be a list of Plug or Slot objects
<tedg> ysionneau: Depends on your LD_LIBRARY_PATH, but by default it would be the one in your package. But you could change that.
<zyga> tedg: each of those having an optional "connections" attribute with a list of SlotRef and PlugRef (respecitvely)
<zyga> tedg: and those just have a pair of attributes "snap" and "slot" or "plug" (respectively)
<zyga> tedg: you'd find "apps" with a list of apps that are affected on each Plug and Slot objects there (not ...Refs)
<zyga> ysionneau: I suspect yours
<tedg> zyga: Yeah, exactly. I dont' care if it's an array there or there is an entry for each app. Either way works for me.
<zyga> ysionneau: though I don't know for sure, you can always package your dynamic linker there so you have total cotrol
<zyga> control*
<zyga> tedg: I have a branch with all of this, I'll push it for reference
<zyga> tedg: one sec (just one more patch to rebase)
<tedg> zyga: Could we put version there as well? Then I could get the full AppID with one call.
<tedg> I was expecting 1+n, but 1 would be better :-)
<ysionneau> zyga: I think I packaged lots of stuff, I should have a very controled env here :o
<zyga> tedg: ah, interesting point
<ysionneau> http://pastebin.com/uRiXN9se
<zyga> tedg: not today but yeah, I'm actually making more bits available there now (as a part of the rebase)
<zyga> tedg: though I suspect gustavo may object more on this end, please bring it up with him first
<zyga> tedg: as this is clear cross-manager responsibility
<zyga> tedg: and perhaps the REST api will change (again) to address that
<zyga> tedg: right now we don't leak any information that belongs to the snap manager
<zyga> tedg: and apps and versions are a part of that
<zyga> tedg: so I see what you want and I'm just saying the road there may be curvy
<tedg> zyga: Sure, and it'd only be in UAL, so it'd be an optimization. Not something we'd bubble up to Unity/etc. So it is something we can do later without bothering them.
<tedg> zyga: Generally that makes it less pressing. We can see how costly it is.
<zyga> tedg: what does UAL stand for?
<tedg> zyga: Ubuntu App Launch
<zyga> what is that?
<ogra_> the wrapper we run to set up the env
<tedg> zyga: Basically the library that coordinates application launching for Unity/URL DIspatcher/etc.
<zyga> tedg: I see
<zyga> ok
<sergiusens> jdstrand, hey should this be allowed by default? https://bugs.launchpad.net/snapcraft/+bug/1544236
<ubottu> Launchpad bug 1544236 in Snapcraft "downloader.test example fails to run" [Undecided,New]
<plars> noise][: are things better with spi today?
<plars> noise][: I tried to submit an image, but it doesn't look like the agent ever picked up a test opportunity from it
<plars> noise][: is there some way to hunt that down? The id from the submission is 44e8d447-c36a-4e2d-8ff8-d6c9325a4083
<noise][> plars - can you query the test progress for that id?
<plars> noise][: I can do that through spi? do you have an example?
<noise][> plars- check Querying Test Progress part of the api doc
<plars> noise][: hmm, it says provfail but I didn't see it come through in the local logs... let me try again
<plars> noise][: strange, it seems to be attempting it this time. There isn't any other agent configured with that platform type, so this is the only one that could have even attempted it
<noise][> if you got a PICKED_BY_AGENT event, and result posted, _some_ agent did it :)
<noise][> and you can see what agent_id picked it
<ace139> Can anyone help me about installing vim in snappy core, whenever i run sudo snappy install vim, it says package not found
<kyrofa> ace139, vim isn't packaged for Snappy
<ogra_> sudo snappy enable-classic; snappy shell classic ... then you can use apt inside the classic shell ... there is no vim snappy package
<kyrofa> ace139, which version of Ubuntu Core are you running?
<kyrofa> ace139, if you're running 16.04, what ogra_ says
<ogra_> i think we pointed him to 16.04 earlier today ;)
<kyrofa> ace139, that vim-tiny or whatever isn't good enough for you, eh? ;)
<ogra_> people are so spoiled nowadays :)
<ogra_> wanting cursor keys to work and such :)
<kyrofa> ogra_, that's all fixable with a good .vimrc and stuff
<kyrofa> ogra_, my mantra is set nocompatible and backspace=2
<ogra_> i just get along with the defaults usually
<ogra_> often enough my installs dont survive long enough for making such changes anyway
<ogra_> my vim on desktop has quite a huge vimrc though
 * ogra_ calls it a day
<kyrofa> Bye ogra_ :)
<ace139> kyrofa, sorry got disconnected. so, can anyone help me install vim in snappy ?
<kyrofa> ace139, heh, welcome back
<kyrofa> ace139, vim isn't packaged for snappy, you'd need to do it in the classic dimension (assuming you're on 16.04)
<ace139> kyrofa, I am in 15.04
<kyrofa> ace139, ah, okay. What functionality are you looking for beyond the vim-tiny?
<ace139> kyrofa, just installed snappy, official site is providing that only
<ace139> kyrofa, I need to configure the wifi, which is not working, needed to write the conf file. but the vi editor is giving me headache,
<kyrofa> Ah, since you can't move around in edit mode and whatnot?
<ace139> kyrofa, I cannot use the backspace to delete as in vim
<kyrofa> ace139, try pasting the contents of this into ~/.vimrc : http://pastebin.ubuntu.com/15245593/
<kyrofa> ace139, then try again. Does it make it better?
<ace139> kyrofa, just a sec
<ace139> kyrofa, life saver :)
<elopio> I'm back. I had to reinstall quassel, so I lost all the backlog :(
<kyrofa> ace139, we're here for ya ;)
<kyrofa> elopio, ah, welcome!
<elopio> I'm sorry if anybody pinged me and I didn't reply. You can try again.
<ace139> kyrofa, I was not aware that .vimrc works for vi too
<kyrofa> ace139, indeed
<ace139> kyrofa, any suggestions how to get my wifi up and running
<ace139> kyrofa, doing ifconfig doesn't show a thing
<ace139> kyrofa, eth0 and loopback is there tough
<ace139> kyrofa, I was thinking about writing a wlan0 in /etc/network/interfaces.d/
<kyrofa> ace139, what hardware are you using?
<ace139> its a TP-LINK
<ace139> TL-WN722N
<kyrofa> ace139, I have the dragonboard here and writing a wlan0 in /etc/network/interfaces.d did the trick for me
<ace139> kyrofa, maybe I should give a try to.
<ace139> kyrofa, I am in luck I guess. Its detected.
<kyrofa> ace139, excellent!
<ace139> now supplying the credentials in the wpa_suppliant.conf
<ace139> kyrofa, hope it works
<jdstrand> sergiusens: I think what is happening is with the move to interfaces/skills/capabilities, the 'network-client' cap is not automatically being added if nothing is specified
<jdstrand> sergiusens: that is a change over 15.04 behavior. I don't think it was intentional, but it is probably worth discussing
<ace139> kyrofa, tighvncserver works here ?
<kyrofa> ace139, you'll probably need to package it as a snap
<ace139> kyrofa, I guess so, package is not found here.
<ace139> kyrofa, anyother vnc server you can suggest ?
<kyrofa> ace139, I don't believe any have been packaged
<kyrofa> ace139, but check the store
<kyrofa> ace139, it's always changing
<ace139> kyrofa, well I am not having a GUI here
<ace139> kyrofa, just was able to get into the Pi doing ssh
<ace139> kyrofa, okay, thanks for all the help. Need to find some way out, atleast the connection is up !
<kyrofa> ace139, SSH should work as well
<ace139> kyrofa, can I visit store using ssh ?
<ace139> means the CLI mode ?
<kyrofa> ace139, oh, I see what you're saying now. No, but in 15.04 you should be able to use snappy search
<kyrofa> ace139, you can also install webdm and visit from another computer
<ace139> I have been trying like $snappy search vnc, is returning nothing
<kyrofa> ace139, yeah, then I doubt there is anything
<ace139> kyrofa, webdm is already installed
<kyrofa> ace139, ah, then from your dev machine visit the tp-link's ip address using the port 4200
<ace139> kyrofa, not quite understand the procedure you are telling.
<ace139> I have a TP Link adapter for WIFI, plugged it in the Pi.
<kyrofa> ace139, ah haha, sorry, let me try that again
<kyrofa> ace139, from your dev machine visit the snappy device's ip address using the port 4200
<ace139> kyrofa, please ! :)
<ace139> okay
<kyrofa> Using a browser, by the way
<kyrofa> webdm is a web app for package management
<sergiusens> elopio, can you reply to my previous comment?
<ace139> kyrofa, working
<ace139> kyrofa, there is a snappy store like the one in ubuntu
<kyrofa> ace139, indeed
<sergiusens> elopio, kyrofa, https://github.com/ubuntu-core/snapcraft/pull/350
<ace139> kyrofa, its nice to explore. Have worked with Raspbian earlier. Its more user friendly I would say.
<ace139> kyrofa, you have a owncloud-server package there ?
<elopio> sergiusens: which comment? where?
<kyrofa> ace139, I do, yes
<ace139> kyrofa, thats awesome !
<ace139> clear
<ace139> oops
<sergiusens> elopio, I was just kidding :-)
<elopio> sergiusens: that was mean.
<kyrofa> sergiusens, hahahahaha
<elopio> only one autopkgtest proxy error left \o/
<sergiusens> elopio, how are you fixing these?
<elopio> sergiusens: I'm not. I just complain to RT, wait, and they get back with more holes in the firewall.
<kyrofa> sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/351
<elopio> kyrofa: what do you think of install-to?
<kyrofa> elopio, makes me think a directory should be provided
<elopio> kyrofa: ok. +1 :)
<kyrofa> elopio, yeah, no perfect solution it seems
 * kyrofa thinks something is wrong when one's SD cards are larger than one's flash drives
<kyrofa> There must be a bigger one around here somewhere..
<plars> noise][: ok, I think I see the problem... one of the agents I have with a different platform name is picking it up
<plars> noise][: does it now ignore the platform?
<noise][> plars: yes, routing is only by what products the agent has access to now
<plars> noise][: oh... sorry I'm still wrapping my head around all this, so I have some dumb questions. Doesn't that mean I need a different lp id for each platform?
<jerryG> will gdb be re-added to snappy-debug?  Why was it removed?
<kyrofa> jerryG, it was never there
<jerryG> kyrofa: it was there for 0.1
<kyrofa> jerryG, but yes, it's intended to be there eventually. Oh? I guess that was before my time
<jerryG> kyrofa:  will it be added in time for the 16.04 release... or not till after?
<kyrofa> jerryG, that's probably a better question for jdstrand and mvo
<jerryG> kyrofa: ok thanks.
 * jdstrand defers to mvo
<jdstrand> I believe the plan is once all the details are worked out with the store, multiple archs, etc, he might upload arch-specific snaps
<sergiusens> elopio, kyrofa so jenkins is down during the weekend and travis during the week
<kyrofa> sergiusens, I see that...
<kyrofa> sergiusens, can we get travis pro or something?
<mvo> yeah, we can upload arch specific snaps now, someone just needs to sit down and write some snapcraft.yaml to pick the right stuff out of gdb :)
<mvo> I think we can't have valgrind due to the way it interacts with libc :/
<kyrofa> sergiusens, how would you feel about having snapcraft do some sort of cpu detection and enable parallel builds for the plugins that support it?
<kyrofa> Is there a downside?
<sergiusens> kyrofa, there shouldn't be; we even had a MP once iirc
<kyrofa> sergiusens, okay. Low priority of course, but it'd be nice
<longsleep> hey folks, are the arm snappy disk images somewhere which directly boot in qemu?
<aatchsion> Hey guys, Mycroft is thinking about delivering on the PI 3 after the recent FCC Spec leak. If we can get our hands on some, do you have any plans for an image? They have built-in wifi and bluetooth!
<beuno> aatchsion, not yet, it's unclear when/if we'll be able to support it (they are scarce for everyone :))
<aatchsion> yeah, for sure. We don't want to have a pi zero type of situation
<aatchsion> just a thought
<sergiusens> elopio, kyrofa can you try and restart https://travis-ci.org/ubuntu-core/snapcraft/jobs/112667860 ?
<kyrofa> sergiusens, I just tried. It claims it was successful, but I see no immediate change
<kyrofa> sergiusens, there it goes
<sergiusens> kyrofa, thanks
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/353
<sergiusens> it will be a long wait to know when this is good to go though
<sergiusens> I hope travis calms down 2 or 3 hours from now
<kyrofa> sergiusens, I just learned something interesting. Both of the projects that don't work with DESTDIR do so because they used another variable for that purpose (for example, INSTALL_ROOT). These projects work fine with the prefix change, but I wonder if it might be better to support variables other than DESTDIR instead? Cleaner solution?
<kyrofa> sergiusens, or should we keep the prefix capability?
<sergiusens> kyrofa, the problem with setting prefix is that we might fall into a 'also set the rpath' situation
<sergiusens> both use INSTALL_ROOT ?
<kyrofa> sergiusens, yeah that's possible, though at least that's easy enough to disable with current configflags
<jerryG> mvo: does snappy debug 0.1's gdb work?... I'm having permission issues when attempting to use
<kyrofa> sergiusens, no, one uses INSTALL_ROOT and another does something totally differently. That particular project seems quite broken in that regard, really
<kyrofa> sergiusens, but it looks like other people use INSTALL_ROOT as well (qmake, for example)
<kyrofa> sergiusens, but still, I wouldn't say it's any sort of standard
#snappy 2016-03-01
<sergiusens> kyrofa, well it is all by convention, defacto status quo
<kyrofa> sergiusens, seriously, who writes a tool with this as the setup guide? https://github.com/kyrofa/fboss/blob/master/fboss/agent/tools/README.md
<kyrofa> sergiusens, also: ZERO INSTALL RULES
<sergiusens> omg :-P
<kyrofa> sergiusens, I'm not sure how to make this thing shippable :P
<kyrofa> sergiusens, but it's very close. Every prepreq worked more or less fine
<kyrofa> And this builds fine
<sergiusens> kyrofa, sounds good enough; a custom plugin is what makes it work and patches upstream of course
<kyrofa> sergiusens, yeah
<kyrofa> sergiusens, https://github.com/ubuntu-core/snapcraft/pull/354
<kyrofa> sergiusens, as soon as that changelog is given the go-ahead I'll release and email out an update
<sergiusens> kyrofa, +1; going to call it in since I'll be back here in no more than six or seven hours ;-)
<kyrofa> sergiusens, sounds good, thanks!
<sergiusens> kyrofa, no need for an announcement on the mailing list or at least not needed for today ;-)
<elopio> ping pitti: our autopkgtests on armhf are failing because: "sudo: no tty present and no askpass program specified". But they pass in amd64.
<elopio> Do you know what's different in the testbeds?
<pitti> elopio: armhf and s390x run in LXC, the other three arches in a full VM (in  ova)
<pitti> "nova"
<pitti> elopio: if you have to call sudo in a test, please always call it with -n, to avoid blocking indefinitiely
<pitti> and use SSH_ASKPASS
<pitti> (this is usually already set in the test env, but you might change the environment)
<elopio> pitti: ack. I'll get a lxc tomorrow to give it a try.
<didrocks> good morning
<didrocks> stgraber: hey! do you mind answering to that one (as you did the snap), please? http://askubuntu.com/questions/740692/lxd-snappy-add-and-run-continer
<dholbach> good morning
<didrocks> hey dholbach! How are you?
<dholbach> hey didrocks - doing well, just need to catch up with an avalanche of emails I got over night :)
<dholbach> how about you?
<didrocks> dholbach: quite similar! but I think I'll have time to continue on the importer :)
<didrocks> also, freezing here
<ysionneau> morning
<noizer> morning
<ysionneau> is there some documentation somewhere on how to build an armhf snap from an ubuntu xenial amd64?
<ysionneau> I guess I need some qemu debootstrap stuff
<ysionneau> but I'm wondering if the exact instructions are listed somewhere
<dpm> davidcalle, dholbach, do you happen to know if we've got any docs for that? ^
<dpm> and good morning all :)
<dpm> morning mvo, while trying to get my calculator desktop snap running I hit an issue that robertancell mentioned you also had with cap-test: "could not connect to display :0". He was saying that "you got a private /tmp directory but the X socket (/tmp/.X11-unix/X0) was not added into the snaps tmp"
<mvo> dpm: could you push the snap somewhere? happy to have a look
<dpm> sure
<dpm> mvo, http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files (see the README too)
<dholbach> dpm, in terms of docs there's just https://github.com/ubuntu-core/snappy/blob/master/docs/cross-build.md (and building on a device)
<mvo> ta
<dpm> ysionneau, ^
<dpm> thanks dholbach
<ysionneau> dpm dholbach thanks! :)
<mvo> dpm: try this //paste.ubuntu.com/15251748/
<mvo> dpm: for now, we will need a desktop profile for the security or rather a X11 interface etc
<ysionneau> dholbach: this tutorial takes for granted that I already created an arm chroot and that I'm running in it?
<dpm> mvo, cool thanks, let me have a try
<dholbach> ysionneau, I'm sorry - I didn't write the tutorial... let me see if I can find more information...
<mvo> dpm: the syntax for this snippet will change very soon but I will send you a diff once it does
<dpm> mvo, thanks a lot, building the snap now
<dholbach> ogra_, which doc do we currently recommend for building arm snaps?
<dpm> mvo, that definitely brought me forward, but now opengl is not happy at all. Do you have any ideas what could be happening here? https://paste.ubuntu.com/15252031
<mvo> dpm: indeed, you need some more libraries in the snap for now, we need to work on this and solve this problem in a generic way because we can't have all apps ship all opengl implementations
<zyga> good morning
<mvo> hey zyga
<zyga> mvo: don't we want to ship opengl in the kernel snap and use the (forgot the name) library as a dynamic adapter that apps link to?
<zyga> (so apps just link to that and ship it but that thing actually opens gl libs that live in the kernel snap)
<mvo> zyga: yes, but not on the desktop :)
<zyga> oh
<mvo> zyga: we need to sit down and solve this problem there too, its a bit unclear what the best path forward is right now
<dpm> mvo, in the interim, while there is not a generic solution, any tips on which libs/packages I should add to snapcraft.yaml for the calculator app?
<dpm> I'm hoping getting the app running might help to the discussion too
<mvo> dpm: you will need to put dri/swrast_dri.so into your snap for now
<mvo> dpm: as dri/swrast_dri.so
<dpm> with the copy plugin, I guess?
<mvo> dpm: and export LIBGL_DRIVERS_PATH=$(pwd)/dri
<mvo> dpm: in your run wrapper
<dpm> right
<mvo> dpm: sorry, we are still at a early stage when it comes to convinicence of this process :/
<dpm> mvo, no worries, looking forward to get my first desktop snap running :)
<zyga> mvo: thinking about it for a second I have a naive idea that might work
<zyga> mvo: we can do the same thing
<zyga> mvo: snappy on the desktop can just depend on a GL implementation
<zyga> mvo: and the same flow from apps shipping the gl shim to the system library will follow
<mvo> zyga: yeah, I think this is what we will do
<dpm> mvo, two questions -> 1) on that pastebin, libGL also complains about the i965 driver not being found, so I guess I should include that in addition to swrast_dri.so as well? And 2) those libs are already in the generated snap, under ./usr/lib/x86_64-linux-gnu/dri, so I guess I don't need to actually include any and simply update my wrapper with the env variable?
<mvo> dpm: yeah, if the libs are already there, just add the env var
<dpm> yeah, tryint that now
<dpm> ok, so I'm going to give this a go: "export LIBGL_DRIVERS_PATH=$SNAP/usr/lib/$ARCH/dri"
<dpm> mvo, success! :-)
<mvo> yay
<dpm> mvo, thanks so much! I'll test the store upload now. There is just one small glitch: https://paste.ubuntu.com/15252970 - line 2 where it complains about not being able to write to that location to create the local database. Any ideas?
<dholbach> dpm, can you tell it where to save its data?
<dholbach> you can use $SNAP_USER_DATA env variable
<mvo> dpm: what dholbach said, this location is inside the squashfs so we can not write there. it should use SNAP_DATA or SNAP_USER_DATA to write its database
<dpm> dholbach, mvo, the database location is set by Qt/QML IIRC, I'll have to find out if it's possible to redefine that, as I think we do with click
<dholbach> dpm, maybe upstream would accept a patch to check if SNAP_USER_DATA is set and if so, use it?
<dholbach> (if there's no command line switch or anything)
<dpm> I'm trying to ask the sdk guys. I used to know how LocalStorage for clicks worked, but I can't remember now
<mvo> dpm: I'm sure we can do something, we did something similar for other packages, just an environment var to redirect the file location is usually accepted upstream
<dpm> dholbach, mvo, so I've got the following variables defined for my appXDG_DATA_HOME data locations, which I copied from the snapcraft plugin: http://pastebin.ubuntu.com/15253544 - the sdk guys tell me I can override XDG_DATA_HOME. So in principle, I think I'll try an "export XDG_DATA_HOME=$SNAP_USER_DATA". Does that sound sensible?
<ogra_> dholbach, we have a doc ?
<ogra_> (i mean an arch specific one )
<dholbach> ogra_, I could imagine that the question on how to build stuff for arm was not brought up the first time :)
<ogra_> dholbach, no, but i dont know about a doc
<dholbach> ok...
<ogra_> typically we walk people through here (starting by telling them to use a chroot, container or the classic dimension)
<dholbach> ysionneau asked earlier
<ogra_> nothing beyond that should be arch specific
<ogra_> (create the right snapcraft.yaml, run "snpacraft snap" )
<ysionneau> so far I've been using my own cross compilation tool, but I am starting to doubt that my stuff work correctly (related to my dlopen segfault from yesterday)
<ysionneau> so I'm willing to do it "your way" to test and compare
<ysionneau> that's why I asked how you would do an arm snap
<dpm> if I've got an snap that I'm creating from fetching e.g. a repo or a .deb package, which already contains an icon, is there a way to get snapcraft.yaml to reference that fetched icon instead of copying it over to the top directory and pointing to that? I can do that, I'm just thinking in terms of unneeded duplication.
<ogra_> well, if you use snapcraft the only difference is that you need to emulate the other arch or build natively on your snappy install
<ogra_> (i usually prefer the latter nowadays, that rules out potential probs by emulation or chroot usage)
<ysionneau> hmm ok so I should create an ubuntu arm image from a debootstrap, boot it with qemu, and use it like a developer machine to build my snap
<ogra_> ysionneau, you dont have an armhf device ?
<ogra_> (how will you test your snaps ?)
<ysionneau> right now no, but I could ask for one, but I prefer testing using qemu
<ogra_> this will be horridly slow
<ysionneau> so far I've done all my tests on qemu
<ysionneau> slower than an arm board with eMMC memory?
<ogra_> definitely
<ysionneau> I have access to a Tegra X1 board but it's a bit of a nightmare to boot ubuntu on it, I have not succeeded yet to do it
<ogra_> i thought there are pre-made ubuntu images from nvidia
<ysionneau> because of the partitionning of this thing which needs tens of paritions for bootloaders etc
<ogra_> the tegra X1 will fly compared to qemu ... it will be a lot faster even if you just run from SD card
<ogra_> so i'd grab whatever nvidia provides and use debootstrap to create a xenial chroot on that system ... then build my snaps in there
<ogra_> (or just grab the classic ubuntu-core tarball, thats faster than debootstrap)
<ysionneau> yeah would be cool to have ubuntu running on the X1 board
<ogra_> https://developer.nvidia.com/embedded/linux-tegra
<ysionneau> I should try again, when the hardware department find one without buggy gpu or buggy pci-e to give me
<ogra_> buggy GPU should be fine for headless ;)
<ysionneau> yeah but it caused some kernel panics at boot because the firmware it had was running some gstreamer stuff at boot
<ysionneau> I thought it was a good idea to complain to hw department so that they give me another board...
<ysionneau> bad idea. now I have no board =)
<ysionneau> anyway, I'll use qemu for now, it's not *that* slow
<ysionneau> it allowed me to play with ubuntu-core and make some snaps, install them, play with them
<ogra_> ok :)
<zyga> anyone up for a quick review (tiny) https://github.com/ubuntu-core/snappy/pull/547
<sergiusens> zyga, mvo https://github.com/ubuntu-core/snapcraft/pull/356
<zyga> sergiusens: looking
<mvo> sergiusens: " coverage/coveralls â Coverage decreased (-83.09%) to 11.657% " hu?
<sergiusens> mvo, look at my comment :-)
<sergiusens> mvo, or at the end of https://travis-ci.org/ubuntu-core/snapcraft/jobs/112805796 ;-)
<zyga> sergiusens: nice
<torbit> Hi folks. Is it possible to have a private snappy store ?
<kyrofa> Good morning!
 * zyga goes to fight with his failing hardware for a few moments
<sergiusens> kyrofa, morning! I have something for you https://github.com/ubuntu-core/snapcraft/pull/355
<kyrofa> sergiusens, gifts? How nice!
<sergiusens> kyrofa, there's also https://github.com/ubuntu-core/snapcraft/pull/356 which I don't mind more comments for as it will need a rebase anyways ;-)
<torbit1> anyone home ?
<jdstrand> dpm, mvo: I added a few tasks to our coard on snappy on classic to review these apps. it may happen today, but more likely tomorrow
<dpm> jdstrand, which apps?
<jdstrand> calculator, caps-test, moonbuggy (already had libreoffice and firefox, but I don't think they are ready yet)
<jdstrand> and by review, I don't mean store review-- I mean test them out and adjust security policies, etc
<dpm> jdstrand, gotcha, thanks! Let me know if there is anything I can do on my end for calculator. As far as I can tell, everything is working except for the LocalStorage/XDG/Fontconfig issue I mentioned on the e-mail
<dpm> and probably the list of packaged libs can be trimmed, but my main goal was to just get it to a point it worked, tools were exercised and I could do an upload to the store
 * jdstrand nods
<mvo> jdstrand: I would love to talk to you soon about desktop files and snappy
<jdstrand> there is a 'Snaps on desktop' catchup later that I was invited to. I wonder if it would make sense to add you to that
<jdstrand> tedg: opinion? ^
<mvo> jdstrand: yeah
<ogra_> well, dont we have all that stuff in the phone already ?
<ogra_> (generating .desktop files that use a wrapper (aa-exec) and all that stuff)
<ogra_> technically it should only be translated o the new world order
 * zyga has another broken hdd, eh :/
<zyga> spinnig disk of eventual doom
<ogra_> stop using these mechanical drives :)
<zyga> one by one
<ogra_> heh, seeing all the bugs from SweetShark it seems snapcraft is getting a reality check now :)
<zyga> run-parts: /etc/network/if-up.d/ubuntu-fan exited with return code 1
<zyga> hmm, this happens on each ifup
<zyga> and the network interface is really up but ifupdown thinks it is not
<zyga> where should I report this bug, on ubuntu-fan or on snappy?
<zyga> reported as https://bugs.launchpad.net/snappy/+bug/1551747
<ubottu> Launchpad bug 1551747 in Snappy "ubuntu-fan causes issues during network configuration" [Undecided,New]
<ogra_> zyga, agains ubuntu-fan i guess
<ogra_> not sure how wlan capable it is at all
<zyga> ogra_: fan has no upstream project, just a package,
<ogra_> yeah, weird
<tedg> jdstrand: mvo: That is fine with me, it's kinda kgunn's meeting so I don't know how many guests I'm allowed to bring though :-)
<kgunn> tedg: it's definitely open to whomever has an impact/interest there
<tedg> Cool, I'll add mvo
<kgunn> jdstrand: mvo welcome
<kgunn> willcooke: ^ :)
<ogra_> kgunn, strikes me ... we might also want to discuss how to ship graphics drivers on arm/arm64 ... i dont exactly know whats needed we need to ship
<tedg> The meeting has been vogtted (sp?) ;-)
<ogra_> (not actually related to .desktop files etc ... probably deserves its own discussion)
<kgunn> ogra_: what do you mean? i mean it's just another arch
<kgunn> or am i missing something
<ogra_> kgunn, well, the RPi has its own binary blob ... most likely shipping libEGL ... do we need mesa too, could the free driver work etc etc ... same goes for the dragonbaord
<ogra_> i simply dont know what works and what doesnt ... and how i should ship it (most likely inside the kernel snap, butu i dont think we have any common setup for that yet)
<kgunn> ogra_: so it's an either or...mir/qtmir will work on either
<kgunn> ogra_: i will say, mesa is a little nicer being open source and all
<kgunn> altho...
<kgunn> hwc usually has some optimizations based on it's specific chipset
<ogra_> hwc ?
<ogra_> i'm talking about linux :)
<ogra_> we have no andfroid container
<kgunn> hwc= android's hardware composer
<kgunn> ah
<ogra_> and nobody worked on such a thing
<kgunn> ogra_: oh i'm sure chipset vendor's have it... :)
<kgunn> de facto
<ogra_> i was assuming we use the open or closed linux drivers ... and there i dont know what to ship and what we need additionally
<kgunn> ogra_: who's producing the closed ones ?
<kgunn> i would presume better maintenance/living deliveries
<kgunn> for the close ones
<ogra_> depends on the board ... dragonboard comes with adreno chipset, rpi with some proprietary broadcom
<ogra_> both have open alternatives ...
<ogra_> (but i dont know the state of either regarding Mir's needs)
<kgunn> ogra_: are there any complaints regarding the open alternatives ?
<ogra_> no idea
<ogra_> thats pretty much the end of my knowledge :)
<kgunn> ogra_: basically if there is gles/egl/drm/kms/gbm following the mesa interface model then we are good to go
<ogra_> currently both boards are competely headless, we dont ship anything
<ogra_> but given they are aour reference platforms i guess we should ship some way for people to run graphical stuff
<kgunn> ogra_: i'm keen on getting that on dragonboard
<ogra_> well, RPi is the typical kodi device ... i guess there too ;)
<kgunn> ogra_: in theory this is totally possible...i've run mir on dragonboard on regular ubuntu distro
<ogra_> aha !
<ogra_> using which driver then ?
<kgunn> ogra_: mesa
<ogra_> uuh
<ogra_> SW rendering ?
<ogra_> that doesnt sound like something i'd want to do in production :)
<kgunn> ogra_: nope, it's hw accel gl
<ogra_> oh
<kgunn> ogra_: i just shared a doc with you
<zyga> ogra_: I have the pi camera
<ogra_> ok
<zyga> ogra_: trying to get it to work
<zyga> ogra_: do you know if anyone tried that?
<zyga> ogra_: I know what to do, I'm just curious
<ogra_> zyga, nope
<ogra_> (i dont know)
<kgunn> ogra_: so in my simple understanding of looking over at the core image side of the house...do you just need to seed the image with packages from that dragonboard distro?
<kgunn> then i magically get gl/display drivers as part of the core image?
<ogra_> kgunn, well, i dont know which ... you surely need either the closed adreno or the open freedreno driver to serve mesa
<zyga> ogra_: k
<kgunn> ogra_: if the drivers themselves are closed...i don't really care, as long as the i/fs are conformant to what we need
<ogra_> and perhaps also kernel config we might not have enabled atm
<ogra_> (kms and friends)
<kgunn> ack
<ogra_> and specifically for the RPi2 i guess also the video codecs to make things like kodi work
<kgunn> ogra_: oh...and that distro is vivid...but i wanna be on xenial
<ogra_> indeed
<ogra_> we dont do non xenial for dragon atm :)
<kgunn> ogra_: how to change that ?
<ogra_> change what ? you want vivid for dragon ?
 * kgunn chants "xenial, xenial, xenial..."
<qengho> Has anyone seen "Bad system call" crashes in snap apps? I'm just beginning to debug one.
<kgunn> i want xenial for dragon...but with all the gpu goodies
<ogra_> qengho, grep for syscall in syslog ... then use "scmp_sys_resolver $syscall-id"
<ogra_> kgunn, right ... me too i guess :)
<qengho> "sigaltstack"
<ogra_> what i meant to say above is ... nobody cares for 15.04 anymore ... only for potential security updates until 16.04 release ... then 15.04 will be gone anyway
<kyrofa> qengho, that might be a seccomp filter denial
<ogra_> kgunn, i guess we need to drag some low level specialist in to tell us what we need seeded/added
<ogra_> (my knowledge here is rather limited and ends at: you need a driver with EGL support ... and perhaps MESA)
<ysionneau> what's the package to install on ubuntu-core to have the snapcraft tool?
<ogra_> ysionneau, snapcraft :)
<ysionneau> ubuntu@localhost:~$ sudo snap find snapcraft
<ysionneau> error: no snaps found for "snapcraft"
<ysionneau> (16.04)
<ogra_> ysionneau, ah, no, thats not possible
<ogra_> sudo snappy enable-classic
<ogra_> snappy shell classic
<ogra_> that gets you an apt capable environment
<ysionneau> what are those command doing?
<ysionneau> oh
<ogra_> (an lxc container that adds the apt bits to the system ... there you can do normal apt-get update and install commands)
<ysionneau> awesome!
<ysionneau> thanks
<kgunn> ogra_: i bet camako or similar could help us...
<ogra_> cool
<kgunn> camako: basically what would we need to seed from a dragonboard port to get our mir-server snap up and running
<kgunn> camako: in terms of pkgs
<kgunn> that need to be in the core image
<ogra_> well, even without pkgs :)
<camako> kgunn, ummm lemme context switch my brain
<kgunn> camako: lol...i know...vulkan...now snappy
<kgunn> sorry
<camako> :-)
<camako> kgunn, sorry what's the problem we are solving (quite a bit of scrollback to read)
<ogra_> camako, snappy on arm/arm64 is currently focused on headless
<kgunn> camako: right, so ogra_ was asking what exactly is needed to be added to the arm snappy image in order to get mir up
<ogra_> camako, we will surely have users that want to run graphical stuff on RPi2 and dragonboard
<ysionneau> hmm zyga when using your ubuntu-image script to generate a 16.04 rpi2 image, if I try to do "sudo snappy enable-classic" , then I get write /tmp/classic193779427: no space left on device after some time
<kgunn> e.g. kms, drm, gbm, display driver/fb, gles, egl
<kgunn> camako: i think that's it ^
<ysionneau> I guess the disk image is not big enough to enable the "classic" mode
<ogra_> camako, for that i need to know what we need to include in the kernel (device) snap
<ogra_> i know there is an open driver for the rpi but have no clue if thats sufficient for mir yet ... and the same goes for the dragonboard, there is freedreno but i'm not sure thats enough
<mvo> the new snap.yaml skill->interfaces change has landed
<ogra_> mvo, scary
<zyga> mvo: cool, thanks for doing this
<camako> kgunn, ogra, dragonboard runs mesa (not android) right?
<ogra_> re-learning the world again :P
<ogra_> camako, snappy doesnt have any android container (yet)
<zyga> ogra_: there's a wayland demo on raspberry pi foundation github account, perhaps mir could be there too
<ogra_> so normal linux drivers for now i guess
<camako> ogra, ok let me find out and will get back to you
<kgunn> camako: right atm
<ogra_> (i guess there is also the input side we need to cover somehow)
<kgunn> ogra_: libinput and usb drivers there...
<ogra_> camako, cool, thanks ... i know RAOF has looked into rpi a while ago, but we havent talked about it in months
<ogra_> kgunn, the other issue is if we actually want that in the core rootfs itself (not sure libinput is actually desired by default for example)
<ogra_> i guess that needs wider discussion
<ogra_> i know that sabdfl wants us to base the images on the cloud builds, the question is what we can/want to add on top without harming the IoT usecase
<kgunn> ogra_: ah yeah...true...might just be part of mir snap
<ogra_> (device specifics like drivers should indeed go into the kernel snap ... but the layer above where bits are semi-generic might not)
<ogra_> i'll send a mail before EOD so we can get a discussion running about that
<jdstrand> mvo: fyi, we are in the meeting now
<mvo> yay
<camako> ogra, kgunn, so I am told dragonboard uses freedreno drivers in mesa... and of course libinput for input... The mir-graphics-drivers-desktop in xenial pulls everything needed in.
<camako> mir-graphics-drivers-desktop package, that is
<jdstrand> mvo: you should have an invite
<ogra_> so our kernel snap should inclide the freedreno driver then, ok
<ogra_> *include
<ogra_> thats a first step ...
<ogra_> for libinput and mesa itself i guess we need more discussion how/where they should be shipped
<kgunn> ogra_: why not make the dragon board image seeding the equivalent to what is amd64 core image today?
<kgunn> just thinking like a caveman
<ogra_> because the rootfs is completely generic
<kgunn> ogra_: i dunno what that means....
<ogra_> it needs to run on all arm64 boards ... and it needs to still fully support the embedded, robotics and IoT usecases without shipping to much bloat
<ogra_> dont forget that snappy allows you to update the rootfs completely independently from the device bits, so all device specific stuff needs to be in kernel or gadget snap ... the rootfs can only ship pieces that are completely device independent (i.e. generic)
<ogra_> ths is why i think we need some wider discussion
<ogra_> (where/if to seed stuff in core etc)
<zyga> ok, I thik I know what the next step is
<elopio> kyrofa: https://github.com/ubuntu-core/snapcraft/pull/327 please.
<kyrofa> elopio, I'll trade you for https://github.com/ubuntu-core/snapcraft/pull/357
<elopio> kyrofa: I'm looking at it already. Unfair trade, I demmand compensation.
<kyrofa> elopio, :D
<kyrofa> elopio, looks good-- is it ready to ship? Or are you still tweaking?
<elopio> kyrofa: ready!
<kgunn> ogra_: wondering, would it be too much to have 3 images effectively... core-headless, core-headed, personal
<kgunn> altho core-headed and personal might start to approach each other...
<kgunn> ?
<ogra_> kgunn, thats a sabdfl question :)
<ogra_> as i said "wider discussion" :)
<kgunn> ;)
<kgunn> ricmm: ^
<kgunn> i know you follow the mir-on-core discussion...
<ogra_> yeah, he probably even has concrete plans or knows more than us :)
 * tedg got dropped because of "an error"
<ogra_> tedg, just fix it then :P
<zyga> ogra_: so it seems our kernel is missing a few modules
<zyga> ogra_: do you know who knows about pi2 kernel maintenance?
<kyrofa> So dduffey, you need the agent and fboss_route.py, right? Anything else?
<tedg> ogra_: Apparently logging in and out fixed it, but I got 2FA, so I think I was probably kicked by beuno :-)
<jdstrand> mvo (beuno and zyga you may be interested in this): the way I see it is there is some sort of 'X' interface that snaps declare (fine-- we need that for the security perms any way)
<dduffey> kyrofa, config files
<kyrofa> dduffey, alright, any other executables?
<dduffey> https://github.com/opennetworklinux/fboss-package/tree/master/etc/fboss
<jdstrand> mvo (beuno, zyga): then either gnome software has a little indication that if the app declares it, it mentions that it needs expanded access to your session, or on first launch of the app we say it needs expanded access to the session
<dduffey> kyrofa, not that I am aware of
<dduffey> basically everything from the repo you have, plus this repo (minus the kernel modules and /dev entries) https://github.com/opennetworklinux/fboss-package
<kyrofa> dduffey, okay so those json files aren't included in fboss?
<kyrofa> dduffey, is that something you would want to ship yourself?
<jdstrand> mvo (beuno, zyga): I don't like click-through security though, and that is all this is, but if we must allow all devs access to X in this manner, I think this is the best we can do. both sides have merit. what is intersting about the wrapper approach is that it sort of feels like a trust prompt
<dduffey> kyrofa, I would like then in the fboss snap so they are there already
<dduffey> yeah, they don't look to be in the fboss repo itself
<kyrofa> dduffey, ah, I wasn't clear. I mean do you want to use exactly those (i.e. make a part pulling down that repo and copying those json files over), or would it be better to ship your own json file(s) specific to this snap?
<kyrofa> dduffey, even if you manually copied them
<kyrofa> dduffey, I suspect manually copying them and maintaining them as part of the recipe would be best, but it's up to you
<dduffey> kyrofa, I would just like to use the unmodified for now
<dduffey> there are some changes I need to make to the initscript to work
<dduffey> but those json's worked fine on ubuntu 14.04 for the purposes of the demo
<jdstrand> mvo (and beuno): if first launch only-- it is easy to imagine a prompt that says something like "This application is requesting privileged access to your desktop session". Then say 'Allow', 'Temporarily allow', 'Deny' (or something). if 'allow'ed, then touch a file somewhere outside of the app's perms such that if that file exists on next run, the prompt is skipped
<kyrofa> dduffey, do you envision ever needing to change them?
<dduffey> kyrofa, not over the next two week :)
<jdstrand> mvo (beuno): this generalizes beyond 'X' which I think is good. since there will be no content-hub, in addition to X apps need to have access to (almost) all non-hidden directories in the user's home
<kyrofa> dduffey, alright
<dduffey> ATM I just want to make it so if we install the snap we get to a working demo state, even if it is a fixed config
<kyrofa> dduffey, so in order to fetch those configs (where they don't have a build system) you'll need to create a `make` part, with a Makefile to pull them down and copy them appropriately. Refer to the OpenNSL one
<kyrofa> dduffey, whereas if you copied them in manually you could use the `copy` plugin to move them into the snap. Make sense?
<dduffey> kyrofa, got it
<dduffey> kyrofa, thanks for pointing to an example
<kyrofa> dduffey, no problem. Particular pointer to the use of DESTDIR
<kyrofa> (that'll be the root of the snap)
<dduffey> kyrofa, can you point to a "copy" example?
<kyrofa> dduffey, https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/shout/snapcraft.yaml
<kyrofa> dduffey, you should checkout the entire examples/ dir when you're able
<dduffey> kyrofa, thanks
<ogra_> zyga, it is the archive kernel, maintained by the kernel team (mainly ppisati )
<ogra_> zyga, file a bug against linux-raspi2
<mvo> jdstrand: I think implementing this is straightforward
<dduffey> kyrofa, snapcraft stops on failing to make install (i.e. no .snap) ...
<kyrofa> dduffey, yup, exactly
<kyrofa> dduffey, lack of install rules
<dduffey> ls
<ogra_> file not found
<kyrofa> dduffey, so the cmake plugin is super simple. It calls cmake, make, and make install with a DESTDIR pointing into the snap
<kyrofa> dduffey, that leaves it up to the codebase to determine what should go in the snap. Unfortunately, fboss doesn't specify anything
<dduffey> kyrofa, the only think I think I used/copied was "wedge_agent" although it looks like there may be a sim_agent binary as well
<kyrofa> dduffey, indeed, there seems to be a few things in there
<kyrofa> dduffey, and from the README, the process of making fboss_route.py actually workable is terrible
<dduffey> kyrofa, yeah, it looks like they are abusing cmake
<dduffey> but folling there directions it does build
<dduffey> and then I manually copied the agent over into place (on 14.04)
<kyrofa> dduffey, so is it statically linked, then?
<kyrofa> dduffey, you don't have to run it out of the source tree or anything?
<dduffey> kyrofa, I would have to go back and review ... I think I installed .debs, then I build it from source, and then I copied over the build agent to verify it would work ... so half/half
<kyrofa> dduffey, blech :P
<kyrofa> dduffey, it does seem to be a rather large executable, so it may very well be static
<fgimenez> elopio, the credentials in the tarmac server are the scalingstack ones, for accessing the host we were using so far the canonistack ones (where the host is created), the key filename in my case looks like ues-snappy-integration-tests_lcy02.key
<fgimenez> elopio, i'll upload them there too
<plars> What's the right gadget snap to use now?
<plars> I'm getting "expected 1 gadget snaps, found 0"
<plars> ...with --gadget canonical-pc.canonical
<kyrofa> sergiusens, elopio man, travis's breakneck speed along with requiring that PRs are up-to-date with master = one new feature a day or so
<ysionneau> zyga: ok for enable-classic to work I just had to increase ram (-m 1024) + mount -o remount,size=150M /tmp
<ysionneau> now it works o/
<zyga> ysionneau: cool
<zyga> ysionneau: it works on pi with one gig very wel
<zyga> well
<ysionneau> I don't know how much ram I had, I was not specifying -m
<ysionneau> maybe I had very small amount ^^
<dduffey> kyrofa, I'm going to focus on building the 15.04 image with the correct kernel/modules/dev entries ... I'm stuck with the usersnap snap build ... not sure I can really take that further :/
<kyrofa> dduffey, adding the right install rules doesn't work?
<dduffey> kyrofa, it doesn't look like it is building wedge_agent
<dduffey> kyrofa, even a blank install rule where it doesn't copy it over (for now) is fine
<dduffey> because then for testing I could install the snap and manually copy over the missing pieces
<kgunn> so i used to do "snappy search" to see what was available in the store...is there something equivalent ?
<kgunn> and this documentation is now wrong https://developer.ubuntu.com/en/snappy/start/using-snappy/
<kgunn> sergiusens: ^
<beuno> so
<beuno> the store is broken atm
<beuno> hold tight
<kgunn> but still there is no "search"
<kgunn> command
<ogra_> kgunn, "snap find"
<ogra_> (note: not "snappy")
<kgunn> ah...ok...might want to update the online docs for that
<kyrofa> ogra_, what's the difference between snappy and snap?
<kyrofa> ogra_, or is everything transitioning to snap?
<ogra_> kyrofa, ask someone who was at some sprint :P
<kyrofa> ogra_, boy no kidding
<ogra_> :)
<beuno> there is no difference
<beuno> trying to nail down the name
<ogra_> (i really have no idea, but we apparently fragmented into two now)
<beuno> we'll use one or the other
<kyrofa> beuno, whew, good
<ogra_> beuno, how about we nail it down *before* having two half commands for the same bits ;)
<beuno> ogra_, sorry, my time machine is in the shop this week
 * ogra_ bets thats the typical thing to forget about before 16.04 ... and then we are screwed :P
<kyrofa> beuno, they keep it for a WEEK?
<kgunn> yeah, as of now snappy doesn't have find...but snap does....seems like a difference
<jdstrand> mvo: yes, I agree
<jdstrand> mvo: it might be good to get beuno's opinion on the approach first though
<zyga> kyrofa: snap is the new command line tool
<zyga> kyrofa: it's talking to snapd over the REST api
<zyga> kyrofa: snappy is the kitchen sink that we're replacing
<kyrofa> zyga, ah, okay
<kyrofa> zyga, so snappy will go away?
<zyga> kyrofa: I think so
<zyga> kyrofa: I'm sure we'll ship 16.04 with just snap and snapd
<zyga> kyrofa: no snappy
<kyrofa> zyga, good info, thank you :)
<sergiusens> kgunn, so we only deal with snapcraft; I know; as one of the main developer entry points people expect us to know everything
<beuno> well
<sergiusens> kgunn, but you really want to ping Chipaca or mvo about snap and snappy; we are really operating as different teams so I don't even know what the status is on all their plans :-)
<beuno> zyga, it's not clear if it'll be snap or snappy
<jdstrand> mvo, sergiusens: hey, with mvo's interfaces announcement, wondering when I should push the review tools branch
<jdstrand> looking at bug 1549427
<ubottu> bug 1549427 in Snappy "migrate from skills to interfaces" [High,In progress] https://launchpad.net/bugs/1549427
<sergiusens> jdstrand, well I have this https://github.com/ubuntu-core/snapcraft/pull/356
<sergiusens> we plan to release https://launchpad.net/snapcraft/+milestone/next either late Wednesday or Thursday
<jdstrand> ok, I'll commit to the tree then and do a pull request to the store later
<Shibe> snappy will run everything in docker containers?
<Shibe> wouldn't that be slow
<Shibe> and how big are docker images compared to regular apps?
<jdstrand> Shibe: that isn't how snappy works
<Shibe> I'm not sure how then
<Shibe> I've read about it but I haven't gotten the full explanation
<Shibe> how does it run docker images?
<jdstrand> Shibe: docker is available on snappy if you want to use it, but normal snappy apps don't use docker
<Shibe> okay
<jdstrand> Shibe: sudo snappy install docker
<jdstrand> then use docker like you normally would
<Shibe> what does snappy use for packaging then?
<Shibe> I thought it used docker images?
<jdstrand> no
<Shibe> okay
<Shibe> what's the format
<jdstrand> Ubuntu Core 15.04 it used ar-based files and in 16.04 it will use squashfs
<Shibe> oh ok
<jdstrand> snappy apps are integrated with the system (though in a very controlled manner). there is application isolation using a number of technologies
<jdstrand> so, install a snap, and you see it on the system. when you run it, it runs under a sandbox
<jdstrand> which is different from how docker images work
<Shibe> okay
<ev> plars: hey, sorry. Just saw your message. Weâre sprinting this week
<ev> the world should be stabilised, yes
<plars> It's cool, I talked to cprov
<plars> yeah, everything is broken :(
<plars> all my agents run any job
<plars> leo just ran a bbb job on an x86 box
<plars> it's awesome
<plars> he said y'all would talk about it at the sprint
<plars> hopefully we can come to some kind of solution
<sergiusens> elopio, kyrofa so now that we have adt; what about using that as the gate instead of travis?
<kyrofa> sergiusens, you mean the required bit? What does travis give us that adt doesn't?
<sergiusens> kyrofa, from what I am seeing, not much now
<sergiusens> kyrofa, coverage reports
<elopio> sergiusens: I'm +1, but a little worried when scalingstack is funny.
<sergiusens> elopio, today travis is funny ;-)
<kyrofa> Makes me a little nervous too, but then travis has been funny lately as well
<kyrofa> Exactly
<elopio> I always wanted to keep travis as a safety need for those cases, but maybe we can reenable it when they have more resources.
<sergiusens> elopio, doesn't this use the real adt infra or did you just replicate?
<sergiusens> kyrofa, wdyt https://github.com/ubuntu-core/snapcraft/pull/358 ?
<sergiusens> zyga, kyrofa should I merge https://github.com/ubuntu-core/snapcraft/pull/356 ?
<kyrofa> sergiusens, I've not been able to look at it yet, but it looks like you have some other reviews there
<dduffey> kyrofa, I just sent you access info to get the the Facebook Wedge running 15.04 snappy w/ the kernel and modules loaded
<sergiusens> kyrofa, yeah, it was reviewed by zyga; maybe give it a light check although by now I don't want to change anything as it just finished the travis run
<kyrofa> sergiusens, checking now
<kyrofa> sergiusens, does os.umask effect files created in self.run(), then?
<sergiusens> kyrofa, yes, because it is spawned from this env
<sergiusens> kyrofa, I testted that; but writing an integration test with that feels a bit too convoluted
<kyrofa> sergiusens, huh. Yeah, seems okay to me, though it's not a feature I use much so I can't pretend to understand it completely
<kyrofa> sergiusens, this doesn't change the umask outside of snapcraft though, right?
<sergiusens> kyrofa, no; also tested that :-)
<sergiusens> kyrofa, I can ask jdstrand
<sergiusens> jdstrand, what do you think about doing https://github.com/ubuntu-core/snapcraft/pull/358
<sergiusens> ?
<kyrofa> sergiusens, yeah he'll know more
<jdstrand> sergiusens: interesting-- so wrt to umask, the store will set umask(0) to not get in the way of what the developer intended
<jdstrand> sergiusens: a umask of 022 seems very reasonable, but on the other hand, not sure if we should second guess the developer's intent
<jdstrand> sergiusens: (re the store, it when doing the unsquashfs/mksquashfs check)
<sergiusens> jdstrand, I'm just trying to solve https://bugs.launchpad.net/snapcraft/+bug/1515394
<ubottu> Launchpad bug 1515394 in Snapcraft "Restrictive umask and permissions may cause a built snap to be unusable" [High,In progress]
<jdstrand> sergiusens: I'm not sure what umask(0) is going to do within the context of snapcraft though-- eg, with stage-packages, etc
<sergiusens> jdstrand, the intent problem is what I guess I can't get out of if trying to do this with snapcraft
<jdstrand> let me read that bug
<jdstrand> I do plan to add some tests to the review tools on weird perms, but I probably wouldn't complain if someone had '640' files (for example)
<jdstrand> sergiusens: is there a way for people to 'fix up' perms? I guess snapcraft build and then before snapcraft snap they could
<sergiusens> jdstrand, a '0' basically means only 'root' can see it
<jdstrand> a umask of zero means don't apply a mask
<sergiusens> jdstrand, err, 640 (the 0 there)
<sergiusens> sorry for being confusing
<jdstrand> sergiusens: it would, yes
<sergiusens> so if it were a cli command it would not be runnable
<jdstrand> but that would be fine for a daemon for example
<sergiusens> yes, until or if we do per uid runs
<jdstrand> this gets into second gussing what the dev wants
<sergiusens> I am not so worried about the writable bits as this gets squashed anyways
<sergiusens> jdstrand, yeah, so if that is the case, then this bug is probably not a bug
<sergiusens> we can warn I guess
<jdstrand> yeah, a tasteful warning might be the way to go
<sergiusens> jdstrand, in review tools or snapcraft?
<sergiusens> or maybe checking the current umask
<jdstrand> I was thinking snapcraft could look at the umask
<jdstrand> and then say "Hey, you may know what you're doing but I'd like to mention this might cause you problems'
<jdstrand> that may not be the exact working you want :)
<jdstrand> wording*
<sergiusens> jdstrand, thanks for the suggestion, I'll switch to that as it is not as invasive
<jdstrand> np
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/359
<kyrofa> sergiusens, lovely :)
#snappy 2016-03-02
<Chipaca> kgunn, kyrofa, snap is the new client, that just talks to the rest api; we're moving commands over to it
<Chipaca> as they get feature-complete(ish) the old one is removed from snappy
<wigleworm> Can anyone help with a question about snapcraft and "build packages"
<wigleworm> I want to create a snap with lsusb and lspci. I think I would use "build packages" with snapcraft but I keet getting a "parts" error
<wigleworm> btw I have not defined a "parts" section because I have no clue how to do that when all I want are packages
<wigleworm> rather deb packages
<wigleworm> I also read about using "stage-packages" but that makes even less sense to me given that I still have to have a "parts" section.
<wigleworm> more clarification - I want to add the functionality of lsusb and lspci to snappy as its not installed. With that in mind, I am trying to build a snap that will install the two deb packages (and dependences) into the system so that I can run them from the command line
<dholbach> good morning
<didrocks> hey dholbach
<dholbach> salut didrocks
<noizer> morning
<sergiusens> jdstrand, hey, if you have  a chance to look at, it would be great https://github.com/ubuntu-core/snapcraft/pull/360/files
<sergiusens> it is in nagging mode so most commands run (except 2) will nag
<sergiusens> this is where my creativity ends
<zyga> ppisati: hey
<zyga> ppisati: do you have a moment to talk about the raspberry pi kernel
<ppisati> zyga: what's that
<zyga> ppisati: I was trying to use video core specific modules and I found that we don't have them in our kernel
<zyga> ppisati: specifically I was trying to use bits required to use the camera interface
<ogra_> zyga, which ones specifically ?
<ogra_> the camera ones should be there with the latest image
<zyga> ogra_: oh? yesterday they were not
<ogra_> hmm
<zyga> ogra_: vcsm
<ogra_> except ....
<zyga> ogra_: and the lot
<zyga> ogra_: I can make a proper list in a moment, just got my network back
<ogra_> zyga, the modules are in the kernel, but there was a bump of the bootloader required to make them used ...
<ogra_> i'm just wondering, i think i only updated it for 15.04
<zyga> ogra_: ohhh, can you do it for 16.04 as well
<ogra_> i'll try to find some time, no promises for today though
<ppisati> zyga: how do you use the camera?
<ppisati> zyga: because
<zyga> ogra_: everything that is needed for this: https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc
<ppisati> zyga: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217
<ubottu> Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New]
<zyga> ppisati: not v4l2
<ogra_> bug 1500755
<ubottu> bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Fix committed] https://launchpad.net/bugs/1500755
<zyga> ppisati: through the videocore apis
<zyga> ppisati: the same way that raspian has this
<ppisati> zyga: someone alreaby opened a bug for it, and it was just a matter of modifying config.txt etc
<ogra_> ppisati, no, there was more
<zyga> ppisati: using official rpi foundation libs (python wrappers for libbcm_host.so)
<ogra_> my fault, i only updated the 15.04 oem snap
<zyga> ogra_,ppisati: I'd argue that for a complete system we should also ship all those binary libs in our kernel snap
<ogra_> on 16.04 the firmware is outdated
<zyga> or each snap will need them as well
<zyga> I haven't checked, maybe that part is actually open source so we can also build it
<ogra_> zyga, i'm about to trigger a discussion on the ML foir that today
<zyga> ogra_: fantastic, I'll chime in
<ppisati> i'm not familiar with the videocore api
<ogra_> (more about graphics drivers, but that should include these libs too)
<zyga> ogra_: I'm trying to get all the pi2 specific hardware to work with interfaces
<ppisati> zyga: what's the userland bin that you use to take picture?
<ppisati> zyga: raspistill?
<zyga> ppisati, ogra_: it's actually very closely related, lots of OpenMAX libs
<zyga> ppisati: no, I was using the library directly, but it's all the same, raspistill is a good test for this
<ppisati> zyga: ok then, can you take a look at this bug?
<ogra_> ppisati, we will need the videocore bits (the opensource graphics driver) to actually have graphical output on the pi
<zyga> ppisati: (through https://picamera.readthedocs.org/en/release-1.10/)
<ppisati> zyga: https://bugs.launchpad.net/ubuntu/+source/linux-raspi2/+bug/1532217
<ubottu> Launchpad bug 1532217 in linux-raspi2 (Ubuntu) "Can't modprobe bcm2835-v4l2 to use RPi2 camera module" [Undecided,New]
<ogra_> it is for display as much as for video decoding and camera
<ppisati> ogra_: uh ok, is that part of the rpi kernel or it is a separate repo?
<zyga> ogra_: the display is my next item, as soon as the camera is working
<ogra_> ppisati, i think the open one entered in 4.4
<ppisati> ogra_: cool
<zyga> ppisati, ogra_: is there anything actionable for me now?
<ogra_> id libraspberrypi-bin (from your bug above) in the archive ?
<ogra_> *is
<zyga> ogra_: not in xenial
<zyga> ogra_: looks like a raspbian package
<ppisati> ogra_: we should make this guy push all his packages into the archive
<ogra_> +1
<ppisati> https://launchpad.net/~fo0bar/+archive/ubuntu/rpi2/
<ppisati> ogra_: ^
<ogra_> yeah, thats what a serch got me
<ogra_> *search
<ppisati> he's not here :(
<ogra_> in #ubuntu-devel perhaps ?
<ppisati> oh, ok, US, he's still sleeping... :)
<ogra_> i know that nickname, so he is here occasionally i'm sure
<ppisati> ok
<ogra_> FSVO "here" .... perhaps not actually in #snappy
<ogra_> not sure how easy/hard it is to push to the archive licensing wise though
<zyga> ogra_: can we use the same bits that raspbian has?
<ppisati> ogra_: good point, the license...
<zyga> ogra_: broadcom licensing seems to say that it is okay to resistribute for broadcom hardware
<ogra_> right, but it might have to go to restricted
<zyga> (which is a bit weird but if they (raspbian) can then perhaps we can too)
<ogra_> or multiverse
<ogra_> not sure if there are binary bits in it
<ogra_> zyga, we should ... but they need to work with our kernel and bootloader
<ogra_> i.e. that needs QA
<zyga> ogra_: can we ship the same kernel as the raspberry pi foundation?
<zyga> ogra_: after all, isn't that what's snappy is all about?
<zyga> (modulo ubuntu extra modules)
<ysionneau> how can I get the core dump for a segfault on ubuntu snappy?
<ogra_> make /proc/sys/kernel/core_pattern point to a file
<ogra_> ubuntu@localhost:~$ cat /proc/sys/kernel/core_pattern
<ogra_> |/bin/false
<ogra_> you want to pipe to /tmp/core or some such ...
<ogra_> instead of /bin/false
<ogra_> (just make sure there is enough space for a whole RAM dump ;) )
<ysionneau> hehe
<ysionneau> ok I don't know what I messed up, but now it does not say "core dumped" any more
<ogra_> damn, you fixed it :P
<ysionneau> ahah no
<ysionneau> it says "segmentation fault", but without the "(core dumped)"
<ysionneau> afk lunch!
<zyga> ppisati, ogra_: is there anything actionable for me now?
<kyrofa> Good morning
<zyga> kyrofa: hey
<kyrofa> zyga, hey :)
 * ogra_ grumbles about slow SD cards
<mvo> dpm: hi, you will need to do a small tweak to your snaps: https://lists.ubuntu.com/archives/snappy-devel/2016-March/001516.html
<ciastek> "hello-world failed to install: snappy package not found" while taking a tour. Known problem?
<mvo> dpm: will probably land today
<mvo> ciastek: the store has a problem right now
<mvo> ciastek: should be fixed soon, people are working on it
<ciastek> mvo: thank you! will try later.
<dpm> mvo, thanks for the heads up, I had seen the e-mail, but wasn't sure the changes had landed. So I should basically change the snaps and re-upload them now?
<mvo> ciastek: yeah, sorry, but we will try to fix it ASAP, its affecting our integration tests as well
<mvo> dpm: not just yet, I'm waiting for our integration tests to work again (store issue) but I expect that I will land this today
<ciastek> mvo: thank again :)
<dpm> thanks mvo
<mvo> dpm: I can ping you once it is uploaded
<dpm> mvo, that'd be awesome, thanks!
<zyga> mvo: I guess a pet project to build a functional version of apt repository tools where each change yields a new URL but all the old URLs contain the old state
<zyga> mvo: do you know of anyone doing something like that?
<kyrofa> dduffey, ping
<noizer> Hi guys do someone know how to install the webdm on the rolling versions?
<mvo> zyga: sounds like snapshots.debian.net
<zyga> noizer: snap install webdm/edge perhaps
 * zyga cannot remember the right syntax for channels)
<mvo> zyga: ups, http://snapshot.debian.org/
<ogra_> just webdm.canonical shoudl work
<mvo> noizer: alias in the store is broken right now
<mvo> people are investigating
<zyga> mvo: looks kind of like what we want, do you know how that is implemented?
<zyga> mvo: is that a cron job doing snapshots
<zyga> mvo: or just a very smart archive that does this internally
<zyga> mvo: and is never inconsistent
<ysionneau> hmm
<mvo> zyga: I don't know the detials, sorry
<zyga> mvo: thanks
<mvo> zyga: I suspect more than a cron job though
<ysionneau> as soon as I change /proc/sys/kernel/core_pattern from |/bin/false to something else , I don't get the "core dumped" message anymore
<ysionneau> for instance now I've set it to /tmp/dumps/core.%e.%p.%h.%t
<kyrofa> Hey mvo, zyga: I'd like to talk about Snappy data. Both unversioned data and how we should solve the problem of storing data on a separate HD
<zyga> kyrofa: hmm
<kyrofa> (for 16.04)
<zyga> kyrofa: (in a meeting now)
<zyga> mvo: for new os snap please land pull 565 (go-flags sync)
<kyrofa> zyga, ah no problem
<kyrofa> mvo, zyga I just want to make sure we solve those issues before 16.04 comes out
<zyga> kyrofa: I'm not very familiar with snap data and update changes
<zyga> kyrofa: I'm interested in the 2nd hdd problem
<zyga> kyrofa: can you tell me more
<kyrofa> zyga, I saw some ML posts a while back about that, and there were some good ideas. I figured you'd be interest in that second one ;)
<kyrofa> zyga, ownCloud has a specific use-case. They want to ship a device that is essentially a rpi2 with a western-digital HD for ownCloud data
<noizer> mvo zyga So it is normal that the webdm not works now on 16.04
<ogra_> noizer, "not works" ?
<ogra_> can you be a bit more specific ?
<zyga> kyrofa: I think the "easy" approach is to have an interface for a given /mnt/foo data and let owncloud just use that
<kyrofa> zyga, but with a default partition layout it's not possible to even use that HD. You'd need to put the entire writable partition there
<zyga> kyrofa: I suspect it's something post 16.04 though
<noizer> when im surfing to it. it keeps loading
<ogra_> kyrofa, we would first need support for that on the system level anyway
<kyrofa> ogra_, what do you mean?
<ogra_> kyrofa, some fstab entry to have a fixed mountpoint for example
<ogra_> (one that you can use the "interfaces" system on)
<kyrofa> ogra_, ah, okay
<ppisati> ogra_: you said they moved the dtb in memory (latest rpi2 firmware), so what's the new location?
<ogra_> you dont really want someone to be able to just re-plug a usb key on some mission critical device to steal data etc
<ogra_> ppisati, no, that was dragonboard stuff :)
<ogra_> rpi is fine and stayed where it was
<ogra_> 0x100 should still work
<ppisati> ogra_: uhm
<kyrofa> ogra_, well... no way around that if you're using an external device-- at least owncloud supports encryption
<ogra_> (i think ... my rpi is still in a suitcase, i'll have to check)
<ppisati> ogra_: http://pastebin.ubuntu.com/15266835/
<ogra_> kyrofa, well, i would like my device to actually alert me and to not accept another device witgh a different UUID for example
<kyrofa> ogra_, can't UUIDs be set, though?
<ogra_> as a low level security measure
<ogra_> not atm
<ogra_> mounting all happens by labels, the fstab is generated from the initrd
<ogra_> thats fine for the internal filesystems ... but for externals i'd like some snappy config option where you can set a UUID to have it added to fstab with a specific mountpoint
<ogra_> if you then replace the USB stick the app wont just start writing critical data to it
<zyga> ogra_: you can just use the same uuid (clone it) and then booting is somewhat unreliable as far as being sure where you boot from
<zyga> ogra_: but I totally agree about doing this with some more insinght as to how external media should be exposed
<ogra_> zyga, sure, its just another stop gap
<ogra_> indeed you can clone it ... and indeed it shoudl be encrypted :)
<ogra_> but encryption isnt supported yet either
<zyga> ogra_: and here I'd say that we should treat external media as something gadget snap can influence (down the line)
<ogra_> so i dont think this is a topic for 16.04 release ...
<zyga> ogra_: agreed
<ogra_> it is a topic for 16.04 SRUs for sure though :)
<ogra_> and we shoudl start planning for it after release day
<kyrofa> ogra_, okay. So our recommended way of doing that is placing the writable label on the external?
<ogra_> for now, yeah
<ogra_> which essentially means you fully run from external in eth all-snaps world
<ysionneau> hmm weird, if I sleep 20 & then kill -s SIGSEGV %1 , it creates a core dump, but not when I run my hello world which segfaults
<ogra_> (the readonly snaps live on 7writable nowadays)
<ogra_> *on /writable
<ogra_> ysionneau, are you still running under qemu ?
<ysionneau> yes
<kyrofa> ogra_, would that be possible to automate in any way?
<ogra_> might be a vm issue
<ysionneau> the thing is, I trigger a kernel issue with my hello world
<ogra_> kyrofa, not easily ... you could have a script that calls kpartx to pull the content from /writable and push it to a USB disk indeed
<kyrofa> ogra_, zyga mvo if the external HD is a post-16.04 support issue, I guess we're just left with the unversioned data. That sounds a bit easier to solve, perhaps?
<ysionneau> ogra_: http://pastebin.com/QNu0G3w4
<kyrofa> ogra_, yeah I'll need to figure something out-- tough to have a shippable device when every device requires manual work
<kyrofa> ogra_, I may be pinging you on that later, if that's okay
<ogra_> sure
<noizer> ogra_ got this error: "Error: cannot list snaps: cannot communicate with server: Get http://localhost/2.0/snaps?sources=local: dial unix /run/snapd.socket: connect: no such file or directory"  when he did this call: http://192.168.0.105:4200/api/v2/packages/?installed_only=true
<ogra_> noizer, is that 16.04 ?
<ogra_> (works here )
<noizer> ogra_ yes
<noizer> so on your 16.4 it works ogra_
<kyrofa> Chipaca, you seemed to have some thoughts on the unversioned data stuff on the ML. Do you still think we can get that for 16.04?
<ogra_> noizer, only tried on arm64, but yes, there it works
<ogra_> (or at least did a few days ago, but there was no new webdm since)
<noizer> hmm ok
<ogra_> ppisati, hmm... there seems to be an issue on the dragonboard with /dev/urandom
<ogra_> ubuntu@localhost:~/xenial-chroot$ lsb_release -cs
<ogra_> Fatal Python error: Failed to read bytes from /dev/urandom
<ogra_> Segmentation fault (core dumped)
<ogra_> i can read from it a few times but then it doesnt work anymore and i have to reboot
<ppisati> ogra_: /dev/urandom?
<ogra_> ppisati, yeah, see the error
<ppisati> ogra_: ah, i didn't see that
<ogra_>  lsb_release -cs works for a while after fresh boot
<ogra_> but at some point i start getting python errors like the above
<ogra_> feels like there are only a few random bytes and once i used them up it starts failing ;)
<ppisati> ogra_: what if you do a 'dd if=/dev/urandom of=/dev/null'?
<ogra_> ubuntu@localhost:~$ dd if=/dev/urandom of=/dev/null
<ogra_> 0+0 records in
<ogra_> 0+0 records out
<ogra_> 0 bytes (0 B) copied, 0.000768486 s, 0.0 kB/s
<ogra_> nothing
<jdstrand> dpm: hey-- I'd like to try your calculator snap on a unity7 desktop. are there instructions for what needs to be installed?
<jdstrand> maybe that is a question for mvo ^
<jdstrand> I feel like there was an email but I can't seem to find it
<dpm> jdstrand, at the end of the the doc. Once snappy is enabled, then just 'sudo snappy install ubuntu-calculator-app'
<jdstrand> ah, maybe that was it
<jdstrand> ok, thanks
<dpm> I can also paste the instructions when I'm off the phone
<jdstrand> I'm there
<dpm> cool
<jdstrand> dpm: thanks!
<jdstrand> ah, I grabbed ubuntu-snappy-cli but not ubuntu-snappy
<jdstrand> yow
<jdstrand> http://paste.ubuntu.com/15267034/
<jdstrand> I'm glad I'm in a vm, I don't want my laptop's grub migrated :)
<jdstrand> mvo: fyi, ^
<jdstrand> (apt-get install ubuntu-snappy)
<dpm> jdstrand, added some notes to the doc to install the calc and clock apps
<jdstrand> heh
<jdstrand> man, a 144M clock
<jdstrand> I thought we were going to have a thick os snap...
<jdstrand> anyhoo
<jdstrand> thanks!
<ogra_> thats just a prototype :)
<ogra_> i'm actually surprised it is *only* 144M
<ogra_> given it pulls in the whole of sdk-libs
<jdstrand> well, with the calculator, there is another 141 ;)
<ogra_> diskspace is cheap :P
<jdstrand> apparently that is what people say :P
<jdstrand> heheh
<ogra_> (we should add that underneath the "linux for human beings" to the logo now ;) )
<jdstrand> :)
<jdstrand> pfft
<jdstrand> I was wondering how it launched with no denials
<jdstrand> unconfined template
<ogra_> shiny eh ?
<ogra_> :P
<jdstrand> well, I was wondering who did the work for me :)
<jdstrand> and now I know
 * zyga solitcits reviews of https://github.com/ubuntu-core/snappy/pull/559 
<jdstrand> zyga, niemeyer: we need to have a chat so we can nail down what needs to be done wrt old-security, moving to native interfaces and existing security interface names. can we scedule a hangout sometime this week?
 * jdstrand adds several more items to trello card wrt snappy on classic
<zyga> jdstrand: yep, let's do it
<zyga> jdstrand: I started to implement old-security natively but gustavo asked me to postpone that till the full interface core is working
<zyga> jdstrand: as for the hangout, just propose one
<niemeyer> jdstrand: Yes, please!
<niemeyer> zyga: Yes, there's little meaning in "porting" logic to a non-working mechanism :)
<jdstrand> oh, and snaps on unity7 interfaces
<jdstrand> ok, let me see if I can find something
<niemeyer> jdstrand: We also need to decide whether we need a sprint in a few weeks or not
<niemeyer> Imminently
<dpm> jdstrand, and it's ~600MB when installed (clock or calc), but probably some trimming down can be done already
<mvo> jdstrand: thanks, its a known bug
<mvo> jdstrand: it won't actually do anything, grub-migrate is dead
<ogra_> mvo, so the initrd build error is actually an issue with mkinitramfs ... seems it tries to copy the linker to a non-existing /lib64 dir
<ogra_> i wonder where that comes from
<ogra_> (no code that would do that in any of the initrd build scripts)
 * davmor2 instantly blames that ogra_ bloke bound to be him ;)
<davmor2> ogra_: see that driveby blaming there ;)
<ogra_> mvo, so if i add set -x to the last initramfs hook that gets called i get this output ... http://paste.ubuntu.com/15267323/ ... note how it expands to searching for /lib64/ld-linux-aarch64.so.1 at the end before it exists non-zero
<ogra_> i'm not sure where that lib64 comes from :(
<mvo> ogra_: in a meeting
<ogra_> ok
<mvo> ogra_: will look after that
<ogra_> i think we need infinity but he is out today
<davmor2> ogra_: no you don't need infinity it'll just keep searching if you do that
<ogra_> davmor2, canadian infinity is different
<ogra_> hmm
<ogra_> ubuntu@localhost:~/xenial-chroot$ ls /usr/share/initramfs-tools/hooks/|grep klibc
<ogra_> klibc-utils
<ogra_> klibc^i-t
<ogra_> apw, ^^ any idea whats up with that klibc hook ?
<ogra_> (update-initramfs complains about it)
<ogra_> /usr/share/initramfs-tools/hooks/klibc^i-t ignored: not alphanumeric or '_' file
<ogra_> looks like someone typoed somewhere
<kyrofa> jdstrand, does either security-override read-paths or write-paths encompass execution, by any chance?
<apw> yeah that it looks like there is a junk file in hooks
<apw> is there a file with a tab in the name in there ?
<ogra_> ubuntu@localhost:~/xenial-chroot$ ls /usr/share/initramfs-tools/hooks/
<ogra_> busybox    fixrtc       fsck         klibc^i-t  resize  thermal             udev
<ogra_> compcache  framebuffer  klibc-utils  kmod       resume  ubuntu-core-rootfs  zz-busybox-initramfs
<ogra_> dosnt look like it
<ogra_> all other files look normal
<jdstrand> kyrofa: no
<kyrofa> jdstrand, didn't think so. I have some software that wants to shell out to /sbin/ip
<jdstrand> iirc, you need the network-admin cap
<kyrofa> jdstrand, oh! That's covered by that eh? Nice
<ogra_> hmm, funny ... in the source of initramfs-tools the klibc hook looks correct
<ogra_> the arm64 binary definitely has it though
<ogra_> apw, aha, klibc-utils adds a diversion ... i guess the typo is in there
<ogra_> there we go
<ogra_> https://launchpadlibrarian.net/237842216/klibc_2.0.4-7_2.0.4-8.diff.gz
<ogra_> apw, seems like a debian bug we actually inherit
<ogra_> (introduced by bwh)
<apw> nice
<ogra_> to bad that wont help with my issue though ... i just stumbled over it trying to get arm64 to behave when building initrds :/
<ogra_> dholbach, anything to discuss today ?
<dholbach> ogra_, sorry, in a separate meeting right now
<dholbach> and no :-/
<ogra_> lets skip then
<kyrofa> kgunn, the beard! It's gone!
<ogra_> O M G !
<kgunn> :)
<kgunn> wife didn't like it
<jdstrand> mvo: do you have a moment now?
<kyrofa> kgunn, aww, too bad
<mvo> jdstrand: yes, HO? just send me the link via /msg
<ogra_> grmbl
<davmor2> kgunn: wise man say when wife happy home is happy too :)
<mvo> jdstrand: you asked about unshare() in ubuntu-core-launcher, we do use unshare(CLONE_NEWNS) when setting up the slave mount namespace (main.c:301). will this potentially cause issues with apparmor?
<noizer> How can i use the snappy ubuntu core REST API on the rolling version?
<zyga> noizer: look at docs/rest.md
<zyga> noizer: you just make http requests to an unix socket (not tcp/ip socket
<zyga> noizer: for starters, cmd/snap is doing exactly that
<zyga> mvo: can you please land https://github.com/ubuntu-core/snappy/pull/559 if you have a moment
<mvo> zyga: *if*
<zyga> mvo: yeah, I know what kind of day it is for you today
<kyrofa> Hey ogra_ I know you disabled the resize for dragon, but I just flashed an rpi and it didn't resize on boot either
<ogra_> kyrofa, oh ?
<ogra_> anything in /dev/.initramfs ?
<ogra_> there shoudl be logs
<kyrofa> ogra_, no, that doesn't exist
<wiggleworm> is there a history server somewhere - I asked a Q last night but then I closed the chat app and cannot see if there was a responce
<kyrofa> wiggleworm, http://irclogs.ubuntu.com/2016/
<dduffey> kyrofa, last night I copied over the build ... and I could see better what was happening
<wiggleworm> thanks kyrofa
<jdstrand> mvo: mount namespaces are not a problem. it is a file namespace that is the issue
<dduffey> the old yaml was including dependencies like libglog the new yaml didn't
<mvo> jdstrand: great, we are good then
<kyrofa> dduffey, I think it all working now, but it seems the system is down?
<jdstrand> mvo: we should be, yes. I'll be poking at this and I'll come to you if I notice anything issues
<dduffey> let me check
<wiggleworm> Can anyone help with a question about snapcraft and "build packages"? I want to create a snap with lsusb and lspci. I want to add the functionality of lsusb and lspci to snappy as its not installed. With that in mind, I am trying to build a snap that will install the two deb packages (and dependences) into the system so that I can run them from the command line. I think I would use "build packages" with
<wiggleworm> snapcraft but I keet getting a "parts" error. I have not defined a "parts" section because I have no clue how to do that when all I want are the deb packages. I also read about using "stage-packages" but that makes even less sense to me given that I still have to have a "parts" section.
<dduffey> kyrofa, you first have to ssh into 192.168.122.188 from the jumphost
<dduffey> and then ssh into 192.168.10.35
<mvo> jdstrand: thanks
<kyrofa> Ahh, I misunderstood
 * mvo -> dinner
<ogra_> kyrofa, oh, sorry ... that should be /run/initramfs/resize-writable.log
<ogra_> the /dev/.initramfs is what we used in the past
<kyrofa> dduffey, all good here! I'll be testing for a bit now. Sorry about that, I just though "MAAS? Why do I care about MAAS? Okay, SSHing into snappy..." :P
<dduffey> kyrofa, no problem ... I will be stepping in/out over the next hour and then I'll be out the rest of the day
<kyrofa> dduffey, good deal, I just wanted in there, I'm set now
<kyrofa> ogra_, the only thing in there is fsck-writable, and it contains http://pastebin.ubuntu.com/15268551/
<kyrofa> sergiusens, you're killing the examples tests man. 6?
<sergiusens> kyrofa, I didn't change anything that would trigger this failure though
<kyrofa> sergiusens, haha, "Everything passed[...]marked build as failure"
<mwb> good afternoon.  Anyone got a moment for a frustrated newbie?
<mwb> I'm trying to get snappy-core running in VMware workstation using the OVA.  It boots fine and I've created the basic cloud-init iso - that works.  However, as soon as I try and modify user-data to add a user, or just add ssh-keys, it breaks and I can't log in on boot.
<kyrofa> mwb, I'm sorry, I'm not sure there's much experience around here with OVA
<kyrofa> mwb, kvm, virtualbox, we gotcha
<ogra_> sergiusens, https://launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/0.7.23 ... cross your fingers :)
<ogra_> YIPIIIIEEE !!! it built
 * ogra_ waits for armhf now 
<kyrofa> ogra_, is it just me or is xenial dramatically faster than trusty on the rpi2?
<ogra_> kyrofa, well, i guess the squashfs really helps for devices with slow SD cards
<kyrofa> ogra_, no that's not it. Just compiling speed seems to be faster. Though it may have been the image I was using previously
<ogra_> ah
<ogra_> heh, so the generic initrd is 2.3MB big ...
<ogra_> vs
<ogra_> ubuntu@localhost:~$ ls -lh /boot/uboot/canonical-dragon-linux.canonical_4.2.0-2014-generic-dragon410c.snap/|grep initrd
<ogra_> -rwxr-xr-x 1 root root 8.7M Feb 19 17:40 initrd.img
 * ogra_ calls it a day ... 
<sergiusens> ogra_, nice! Now I need to get my hands dirty :-P
<kyrofa> jdstrand, trying to debug somewhat of a hacked snappy system, and u-c-l is giving me a "No such file or directory," with aa_change_onexec returning -1. Would that imply it can't find the profile, you think?
<jdstrand> it would
<jdstrand> do 'sudo aa-status' and see if the profile you expect is loaded
<kyrofa> jdstrand, ah, kernel mod isn't loaded :P
<jdstrand> kyrofa: oh, that is perhaps more than a 'somewhat hacked system' :P
<kyrofa> jdstrand, *cough*
<jdstrand> hehe
<kyrofa> So let's say I make a kernel snap, with some extra modules in it. I then make a snap that relies on those modules being present/loaded. I then upload that snap to the store. Is there anything that prevents someone running a kernel on which that snap won't run from installing it?
<kyrofa> Do we care about that?
<wiggleworm> has anyone here created a snapcraft.yaml file to build usbutils or pciutils? If so can you point me to your file?
<rajen> Hi there. Did anyone try a ruby application inside a snap app?
<kyrofa> rajen, not yet-- what are you looking to do?
<rajen> Our application has few scripts using ruby1.9.1
<rajen> We are able to include ruby inside the snap app. However, by default 2.2 ruby is downloaded from the repos. Our swig modules are not yet ported to ruby2.2. I am looking for ways to include ruby1.9.1 inside my snap environment
<kyrofa> rajen, build from source I say
<kyrofa> rajen, ruby is great to build from source
<rajen> Let me see how that goes.
<rajen> thanks for the tip
<kyrofa> rajen, sure thing. Make sure you include the packages you need though (openssl, etc.) or the build system will just skip it
<kyrofa> (ruby's, I mean)
<rajen> kyrofa, okay
<zyga> rajen: just depend on ruby1.9
<zyga> rajen: get it from the archive as any other package
<kyrofa> zyga, ha! That might be easier
<rajen> zyga, I tried that but I am using snapcraft and it doesn't seem to like when I give it as ruby1.9.1 as depends
<kyrofa> Didn't realize that was still in xenial
<zyga> ah
<zyga> it's not
<zyga> boo hoo
<zyga> rajen: get a ppa with ruby 1.9
<zyga> rajen: and use it as a support ppa for your package
<zyga> rajen: you can probably backport one into xenial or just find a ppa where someone did that for you
<rajen> zyga, few more info. I am not really familiar with ppa.
 * kyrofa always builds ruby from source, even on production servers
<rajen> Meanwhile I am trying to see if I can compile our swig modules with ruby2.2.0
<rajen> That will be my first try.
<sergiusens> kyrofa, so http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/179/testReport/junit/test_libpipeline/LibPipelineTestCase/test_libpipeline/ is erroring due to the same thing I fixed in pkg-config about the bad decode
<kyrofa> sergiusens, grr
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/362
<sergiusens> there
<sergiusens> kyrofa, for some reason the examples can't find build-packages
<sergiusens> hmm, and I'm not seeing the adt tests anymore
<robert_ancell> Does anyone know how to distinguish between a snap in the "removed" state that was installed from a store and one that was sideloaded?
<robert_ancell> i.e. the "removed" state hides if the state would otherwise be "not installed" or (does not exist)
<robert_ancell> It seems download_size is a possible check to see if it is available in the store, but not sure if that's reliable
<robert_ancell> Chipaca, ^?
<robert_ancell> There also seems to be the issue in what the version field means - if I have a snap in the "removed" state how do I know what version is available in the store? The version field will show the last installed version, which may have been sideloaded
<rajen> Hi. Can someone point me to documentation where /tmp behavior in snappy is explained.
<rajen> I need info on 16.04 implementation.
<sergiusens> robert_ancell, I think it is just missing the assertions story
<sergiusens> rajen, it is mounted under a new namespace for a running snap by the snap-launcher
<sergiusens> jdstrand, does this make any sense to you https://github.com/ubuntu-core/snapcraft/pull/360 ?
<rajen> sergiusens, In our application Snap, we have multiple commands. One central app will create bunch of files in /tmp/. Now the commands are trying to access the same /tmp folder that central app created. However, they all don't see the same tmp directory
<beuno> rajen, right, /tmp is per snap
<beuno> as they are confined
<rajen> no I see that every time I run a user exposed command, a tmp file is created.
<sergiusens> beuno, it is more per snap and app
<rajen> yeah..that is what I observed.. per snap and app
<sergiusens> jdstrand, is that the desired behavior? ^
<rajen> But we want all our apps to use same tmp dir to share information
<rajen> Is it possible?
<sergiusens> rajen, I will wait for our security guy to say some words ^
<sergiusens> my first response would be that that should be the case as beuno mentioned
<sergiusens> but from how I think it is implemented now it is as I mentioned
<jdstrand> the /tmp should be per snap. I believe it is a bug that it is per command
<rajen> What about TMPDIR. Is it still valid to use it or will it be deprecated soon?
<ogra_> wont be deprecated, no :)
<ogra_> and as a workaround you could use a wrapper script to set it to your writable snap dir
<ogra_> (or a subdir in there)
<ogra_> sergiusens, ubuntu-core-generic-initrd seeded ... will be in tomorrows tarballs
<ogra_> (i havent boot-tested it yet though, thats for tomorrow :P )
<rajen> ogra_, Problem is that in our application C code we refer hard-coded  /tmp in a lot of places. I am trying to see if Snappy provides an automatic /tmp handling.
<ogra_> well, as jdstrand said, it is supposed to be per snap so all your apps in the same snap package should theoretically see the same /tmp ... but there seems to be a bug
<ogra_> if your apps dont support TMPDIR using it is indeed not a workaround :)
<rajen> Yup there is a bug..
<rajen> I can see random directories getting created in /tmp for each command access
<rajen> It never stops..
<rajen> root@localhost:~# ls /tmp/ | grep hello snap.0_hello-ruby.sideload_BezZyD snap.0_hello-ruby.sideload_OXHsLL snap.0_hello-ruby.sideload_mM7VIZ snap.0_hello-ruby.sideload_vSAWkF root@localhost:~# hello-ruby.hello hello root@localhost:~# ls /tmp/ | grep hello snap.0_hello-ruby.sideload_BezZyD snap.0_hello-ruby.sideload_FoOB3j snap.0_hello-ruby.sideload_OXHsLL snap.0_hello-ruby.sideload_mM7VIZ snap.0_hello-ruby.sideload_vSAWkF root@localho
<lool> hi there
<rajen> http://pastebin.com/vPryWH9V
<lool> rajen: yes, each run will create a tmp dir
<lool> I'm not sure who's supposed to clean them up
<jdstrand> rajen: can you file a bug here: https://bugs.launchpad.net/snappy/+filebug
<lool> rajen: basically running a command creates a throw away temp dir, and writes to /tmp are remapped to it
<lool> jdstrand: ah I didn't know the design was supposed to be per-snap
<rajen> All: Okay..so which version is correct?
<jdstrand> I think it defeats the purpose of a tmp dir if it is per command/daemon
<jdstrand> if the original design was per command, I think there should be a bug to revisit it
<jdstrand> perhaps people didn't think through rajen's use case
<jdstrand> but how I remember it is that we were setting TMPDIR to a directory that was per snap
<jdstrand> becvause people hard-code /tmp, that was problematic
<jdstrand> so the per-snap /tmp mount was devised
<rajen> I seem to like jdstrand's philosophy. That is what I as a developer of heavy duty application would expect.
<jdstrand> the proper implementation is create/mount it if it doesn't exist, then let it persist so other commands/daemons can mount the same dir
<jdstrand> then clean up on reboot
<jdstrand> well, it doesn't totally defeat the purpose of the /tmp dir if it is per command, but it does if you have a complex app and can't easily use SNAP_APP_DATA
<zyga_> cd
<zyga_> hmm, right
<lool> jdstrand: yup
<lool> this all makes sense
<jdstrand> rajen: filing a bug will get the right people involved to decide on the path forward
<lool> I agree it's a nicer design for traditional apps
<rajen> okay let me file one
<rajen> https://bugs.launchpad.net/snappy/+bug/1552458
<ubottu> Launchpad bug 1552458 in Snappy "Sharing tmp directory across multiple commands in a snap app" [Undecided,New]
<rajen> here it is
<sergiusens> kyrofa, is examples testing broken for you too?
#snappy 2016-03-03
<didrocks> ogra_: hey! when you have some time, do you mind answering on http://askubuntu.com/questions/741088/qemu-snappy-15-04-how-to-tune-sysctl-conf ?
<didrocks> ogra_: and please poke me, I'm interested in the answer as well :)
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> salut didrocks
<zyga> good morning
<noizer> good morning
<didrocks> mvo: hey, it seems that even if we branch snapcraftv1, we can't build anymore 15.04 snaps on xenial.
<didrocks> mvo: Snapping /
<didrocks> open /home/didrocks/work/ubuntu-core/demos/youtube-streamer/snap/meta/snap.yaml: no such file or directory
<didrocks> I guess the issue is the new metadata snappy files
<didrocks> and so snappy snap doesn't know it's some 15.04 snaps and look for this
<didrocks> (I did downgrade snappy for now)
<mvo> didrocks: yeah, snappy is unfortunately not able to do 15.04 stuff in xenial
<mvo> didrocks: if that is important we could introduce a snappy-15.04 package, but then 16.04 is going to be released in some weeks so not sure about it
<didrocks> mvo: I agree, but it seems that a lot of people have (unfortunately) interests in 15.04. I guess if we tell them to use < 16.04 for now, it's ok, but still something to keep in mind in case people starts complaining
<noizer> Hi I played some with the REST API but i got an error with this call.
<noizer> http://pastebin.com/e4yVQTKj
<zyga> noizer: which version of snappy did you use?
<zyga> noizer: can you run "snap interfaces"
<noizer> 16.04
<noizer> zyga
<zyga> noizer: and FYI: https://github.com/ubuntu-core/snappy/pull/559
<zyga> mvo: thank you!
<noizer> ok but i got it for other different calls like /2.0/snaps/nameOfSnap/services
<zyga> noizer: you might have to authenticate
<zyga> noizer: or run as root
<noizer> hmmm ok i will check it first out
<zyga> noizer: look at the rest.md file
<zyga> noizer: it says what each of the method requires
<zyga> noizer: including authentication
<zyga> noizer: currently if you connect as root over the local socket then we trust you and you can touch any of the bits exposed
<noizer> zyga: but with the /2.0/snaps there needed to be authentication too but it works right out the box
<zyga> noizer: maybe your image still has /2.0/skills
<zyga> noizer: I'd recommend using my devtools scripts to run latest master on your image
<noizer> maybe
<zyga> noizer: try the get with /2.0/skills
<zyga> if that works you have older snappy in your image
<noizer> zyga: I will build a new image
<noizer> zyga when was the last update
<noizer> zyga because I build it before with you previous monday (22/02/16)
<zyga> noizer: you don't have to build a new image
<zyga> noizer: that won't change anything
<zyga> noizer: images auto-update if there are new releases
<zyga> noizer: I'd suggest injecting new snappy into your existing image
<zyga> noizer: my devtools scripts do exactly that
<noizer> zyga: oooh ok i will have a  look at it how i need to do it
<noizer> zyga can you push me fast around how it works again you devtools
<zyga> noizer: sure, clone it somewhere
<zyga> noizer: make sure you can run the kvm image or you have a device around
<zyga> noizer: make sure you can ssh to your device under the names listed in the readme file (e.g. ssh snappy-pi2)
<zyga> noizer: then run ./refresh-bits --pi2 setup snap snapd snappy run-snapd
<zyga> noizer: and read the script, it's very simple
<noizer> I don't need to do some things with go?
<zyga> mvo: I've added sorting tests, the test for Interfaces() is in a subsequent branch, do you want me to cherry pick it in or can it land separetely?
<zyga> noizer: sure, you have to be able to build the snappy tree, that's covererd by README.md in the snappy repo
 * zyga needs a bigger switch
<mvo> dpm: a new os snap is now in rolling/edge so you may need to update your example app
<dpm> mvo, thanks! so I need to 'snappy update ubuntu-core' as well I guess?
<mvo> dpm: yeah, its in edge right now, I promote to stable in a bit
<dpm> ok, I just wanted to see if I did it right, as I caouldn't see any update yet
<noizer> Zyga building !!!! niceee
<zyga> noizer: cool,
<zyga> noizer: patches are welcome, if you can improve the devtools or documentation around them
<noizer> zyga: I will think about it and let you know
<dpm> mvo, looks about right? http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/revision/282
<noizer> zyga: strange its just like you script is blocking
<mvo> dpm: yes
<dpm> great, thanks
<zyga> noizer: it is blocking
<zyga> noizer: the run-snapd subcommand blocks
<zyga> noizer: and you can see what snapd says if it says something interesting
<zyga> noizer: you can ctrl-c it to stop snapd
<zyga> noizer: if it's blocking for other reason it's probably misconfigured ssh on your side
<zyga> mvo: follow up with more tests https://github.com/ubuntu-core/snappy/pull/571/files
<noizer> ubuntu
<noizer> zyga here its blocking :s http://pastebin.com/aBafF3RW
<zyga> noizer: it's doing exactly what I said it does
<zyga> noizer: it's running snapd
<zyga> noizer: that's _expected_
<zyga> noizer: you can now ssh into your board and run ./snap
<noizer> so its done?
<zyga> noizer: no
<zyga> noizer: it's not done, it's _running_ snapd in the foreground for you to see
<zyga> + ssh snappy-pi2 sudo /lib/systemd/systemd-activate -l /run/snapd.socket ./snapd
<zyga> ubuntu@192.168.0.133's password:
<zyga> Listening on /run/snapd.socket as 3.
<zyga> noizer: keep that session around, use another session to play with snappy
<noizer> this needs then open all the time?
<zyga> noizer: yes
<zyga> noizer: this is a development tool
<zyga> noizer: it's not something you'd run for any production need
<noizer> oooh ok :D
<noizer> And now i can make some REST Calls to the new API
<zyga> noizer: great!
<noizer> zyga I think so
<noizer> zyga im trying right know
<noizer> zyga  unix connect failed: Permission denied
<noizer> nc: unix connect failed: Permission denied
<noizer> wasn't complete
<noizer> zyga: I can't make any calls to the socket right now
<zyga> noizer: is the daemon running?
<zyga> noizer: ah, just chmod the socket
<zyga> noizer: or run as root
<zyga> noizer: systemd-activate makes a socket with restrictive permissions by default
<zyga> noizer: that's just a side effect of devtools
<noizer> I think its works now
<noizer> zyga
<zyga> mvo: FYI https://github.com/ubuntu-core/snappy/pull/548#discussion-diff-54862218
<zyga> mvo: otherwise yes, LGTM
<popey> mvo: is it possible to switch (for example my pi 2) to edge/rolling? So I get latest crack? (I also have a stable pi 2)
<mvo> popey: only with a tiny bit of hackery, something like "for f in /var/lib/snappy/meta/*; do sed -i 's/channel: stable/channel: edge/g' $f; done
<mvo> popey: Chipaca is working on channel switching from the commandline
<popey> ah
<mvo> popey: will land soon but not there yet
<popey> okay, thanks!
<mvo> yw
<ogra_> zzarr, (continuing from the other channel) ... i doubt you will make X11 work on snappy unless you drop all security (which in turn will make it un-upgradeable)
<ogra_> Mir will work at some point but we are still a bit away from graphical drivers and such on the dragonboard specifically
<zzarr> would Mir be sw accelerated, or not work at all?
<ogra_> no idea, i'm still working on the basics of the image, i can tell you once i tried the driver ... really depends what state the freedreno driver is in
<zzarr> thanks ogra_, I'll begin with a Linaro image
<kyrofa> Good morning
<didrocks> ogra_: hey, have you seen my askubuntu link?
<didrocks> hey kyrofa!
<kyrofa> Hey didrocks!
<olli_> m
<ogra_> didrocks, answered now
<didrocks> ogra_: thx!
<zyga> mvo: quick question, on reboot, when the system is brought back to life, is there something that takes existing apparmor profiles, compiles them and inserts them into the kernel?
<zyga> mvo: it seems that there is something like that as my demos work after rebooting but I cannot find anything like that
<ogra_> zyga, s/inserts them into the kernel/rebuilds the cache/
<ogra_> it is like on the phone :)
<zyga> ogra_: hmm, not sure what "rebuilds the cache" means
<zyga> ogra_: apparmor_parser --reload /path/to/profile parsers, compiles and inserts the profile into the kernel
<zyga> ogra_: is that what you meant?
<kyrofa> enoch85, ping
<ogra_> zyga, qwll, i always thought it reads the binary profile from disk ... but yeah, thats what i mean
<ogra_> *well
<zyga> ogra_: so what does that?
<zyga> ogra_: does snappy do that somewhere?
<ogra_> there should be a systemd job that checks if they are outdated and kicks in on boot
<ogra_> at least that is how it works on the phone
<ogra_> ask tyhicks or jdstrand_ how it exactly works on snappy
<ogra_> but i would imagine largely the same ...
<kyrofa> zyga, I suspect that ubuntu core launcher does it, actually
<kyrofa> zyga, not 100% sure about that
<kyrofa> zyga, I figure apparmor is configured with the directory to the profiles, and when u-c-l launches the app for the first time the profile is loaded and cached
<zyga> kyrofa: no, it doesn't I did check
<zyga> kyrofa: currently snappy does that on changes
<noizer> zyga Hi what is the best way to connect to the socket with some code
<zyga> kyrofa: but I'm curious about the reboot case
<zyga> noizer: in which language?
<noizer> uuuhm python
<zyga> noizer: in go? using our offcial client API
<zyga> noizer: in python, using http package or even requests
<zyga> noizer: it's just http
<zyga> noizer: over a unix socket
<noizer> zyga ok I will give it a shot
<kyrofa> zyga, how did you check?
<zyga> noizer: you can look at the client package
<zyga> kyrofa: I read the source of the laucher
<zyga> noizer: it's well tested and has example requests and responses
<zyga> noizer: it's pretty nice as documentation
<zyga> kyrofa: the launcher handles seccomp profile compilation to ebpf
<noizer> zyga: client package? where can I find this
<zyga> kyrofa: but apparmor profile has to be already loaded in the kernel AFAIR
<zyga> noizer: in the snappy source code, the package client/ is in the top-level directory
<zyga> https://github.com/ubuntu-core/snappy/tree/master/client
<zyga> noizer: e.g. interface related API is here: https://github.com/ubuntu-core/snappy/blob/master/client/interfaces_test.go
<kyrofa> zyga, ah, you're right-- the man page says profiles need to already be loaded with apparmor_parser
<zyga> kyrofa: I suspect there's a systemd unit that does this on boot
<zyga> kyrofa: but I need to dig and I'm in the middle of meetings
<zyga> noizer: if you want to build python APIs that'd be quite useful
<zyga> noizer: I can work with you on that in small capacity
<kyrofa> zyga, etc/init/apparmor.conf in 15.04
<noizer> zyga for me thats good
<noizer> Just know how to start best on it
<zyga> noizer: noizer cool
<zyga> kyrofa: thanks!
<zyga> I'm not sure that's doing anything in 16.04, I need to see this in more detail
<kyrofa> zyga, yeah, same file on 16.04
<noizer> zyga when can we start on the python API?
<zyga> noizer: for now I'd make that a separate git/pypi project
<zyga> noizer: we're super busy with 16.04 and I'd not complicate it by trying to put it in the main snappy repo
<zyga> noizer: after 16.04 we can explore doing that
<noizer> oooh ok
<zyga> noizer: I'd model a python api after the current Go api
<zyga> noizer: if you look at cmd/snap/cmd_* you will see that each command is really trivial
<noizer> first i will experience some with the REST
<zyga> noizer: and you could re-implement snap (the tool) in python in a handful of screens of text
<zyga> noizer: so start a new project (say python-snappy) and start working on the initial package with methods that map to go methods
<zyga> noizer: and we can work on a case-by-case basis from there
<zyga> noizer: which APIs are you going to touch/need first?
<noizer> zyga start and stop services
<noizer> so the REST api to maybe the python API
<zyga> noizer: that might not be exposed yet, look at cmd/snap/cmd_snap_op.go
<zyga> noizer: those are "snap operations"
<zyga> noizer: and I don't see service operations yet
<noizer> zyga I will have a look at it tonight first and then i will let you know what we can start first.
<mvo> zyga: yes, there is a systemd job for this
<noizer> zyga just an other question about the REST api. I see that it is possible to start and stop services with a PUT
<zyga> mvo: ah, interesting piece of the security puzzle
<zyga> mvo: I sure hope we don't race with that job
<zyga> noizer: oh? perhaps -- I'm mostly focused on interfaces, perhaps all the bits you want are in
<mvo> zyga: something like snappy-runhooks
<mvo> zyga: I think it is ordered early
<zyga> mvo: ideally we'd start like this <run-hooks> <snappy> <snappy activates various apps>
<zyga> mvo: but that's only when we have dynamic interfaces that may not be "the same" after a reboot due to hook decisions
<zyga> mvo: for static world, it is nor relevant
<noizer> zyga ooh ok but it is interesting too. but for now i need to start services with the rest api. But I will try to make a python API
<kyrofa> Chipaca, sergiusens how fleshed out are the 16.04 gadget snaps? Can I write one today?
 * zyga wants to know too, I have some interface integration I want to do there
<zyga> at least for pi
<kyrofa> zyga, for pi here too
<zyga> kyrofa: you know where the sources for the gadge snap are, right?
<zyga> kyrofa: I want to add static interface declarations there so that bits like I2c and some GPIOs are exposed
<ogra_> kyrofa, i dont think they will change much
<zyga> kyrofa: and more as I enable
<noizer> zyga ok are  you online tonight. then we can discuss how to start the api etc.
<kyrofa> zyga, nice
<kyrofa> ogra_, change much from 15.04?
<ogra_> no, from 16.04
<zyga> noizer: just ping me here, even if I'm not around
<ogra_> 15.04 is dead and done
<noizer> zyga ok I will do that
<ogra_> (15.04 did not have gadget snaps ... only oem snaps ;) )
<kyrofa> ogra_, argh, I'm lost in a sea of terminology :P
<ogra_> haha
<ogra_> not only you
 * ogra_ updates his personal snaps for interskillcapability supoort
<ogra_> :P
<kyrofa> Ha!
<zyga> ogra_: if you could rename it one more time, which word would you pick?
<kyrofa> interskillability reads better
 * ysionneau ordered an rpi2, to play with Snappy on real HW.
<zyga> ysionneau: cool
<kyrofa> zyga, powers
<ysionneau> I abandonned the fucked up Tegra X1 boards we have
<kyrofa> zyga, maybe special-powers
<ogra_> zyga, i would rename it to "nomoresprints"
<ogra_> every time you gusy have a sprint i need to rebuild my world :P
<ogra_> *guys
<kyrofa> zyga, we should host a light-hearted poll on that
<kyrofa> zyga, regarding sources, you mean the rpi gadget? No, where is that?
<ogra_> https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems
<ogra_> (note that i havent updated rpi2 there yet, i only bumped the 15.04 oem snap a while ago)
<kyrofa> Hmm... pi2 or pi2.moved?
<ogra_> pi2 iirc
<wiggleworm> has anyone here created a snapcraft.yaml file to build tools usbutils or pciutils? If so can you point me to your file?
<ogra_> kyrofa, whichever has a snap.yaml (vs package.yaml)
<kyrofa> ogra_, indeed, rpi2
<jdstrand> zyga: regarding --reload. yes. that command doesn't have any caching options though, so it is just a compile and (re)load
<jdstrand> kyrofa: snappy should be using the appropriate caching options when generating the profile on install. and interfaces should when updating the profile.
<jdstrand> err
<jdstrand> zyga: ^
<kyrofa> Thanks jdstrand, I was curious as well :)
<kyrofa> ogra_, and gadget snaps are the only way to have snaps preinstalled in the generated image, right?
<jdstrand> zyga: and there is an initscript that is called on early boot that makes sure all the profiles are loaded before stuff runs. it will create caches and update outdated ones
<ogra_> kyrofa, no, you should be able to just use the --install option ... though that seems to be broken currently (i pointed mvo to it but didnt open a bug yet, seems the "current" link is missing and system units dont get installed for such snaps)
<kyrofa> ogra_, oh darn
<ogra_> (the --install option of u-d-f that is)
<kyrofa> Right
<ogra_> probably it is webdm specific though, i installed webdm that way (which btw breaks all upgradeability )
<kyrofa> ogra_, well... log that bug!
<kyrofa> :P
<zyga> jdstrand: thanks
<zyga> jdstrand: I'll be doing exactly this today and tomorrow (meetings aside)
<zyga> jdstrand: everything else has landed or waits for a review
<beuno_> zyga, sounds like enough of the syntax has landed in snap.yaml that we could kick off store integration?
<ogra_> identity crisis ?
<beuno> yes, going from sprint to sprint messes you up  :)
<zyga> beuno: yes, I think it's all in for 16.04
<beuno> ooook
 * beuno rolls up sleeves
<zyga> beuno: I don't know what the channel for transferring local interfaces over to the store is though
<zyga> beuno: I would imagine we'd send them in "search" requets
<beuno> zyga, we'll work out the API together
<zyga> requests*
<beuno> yes, in search requests
<zyga> beuno: but the primitives have landed now so snappy has this knowledge
<jdstrand> zyga, beuno: are you guys talking about skills -> interfaces is now in 16.04 images?
<zyga> beuno: it sounds like a nice card to work on next week (mid week)
<zyga> jdstrand: yes
<jdstrand> alright, I get the review tools branch landed then
<jdstrand> I'll*
<kyrofa> sergiusens, FYI ^^ time to release
<beuno> zyga, I'll find someone to work on this on the store side
<zyga> beuno: sounds good
<jdstrand> pindonga: can you do a pull of the review tools? (for the skills to interfaces change
<jdstrand> )
<jdstrand> pindonga: and hi! :)
<pindonga> jdstrand, hi :)
<pindonga> ack, will do, but not sure it'll get to prod this week
<pindonga> btw, we're on 599 on staging
<jdstrand> understood
<pindonga> with the new click-review stuff
<jdstrand> great
<jdstrand> nice! :)
<pindonga> if you can submit a few snaps/clicks to test it it'd be great
<mvo> ogra_: hm, that should work, the symlink should get created on first boot
<jdstrand> ok
<kyrofa> ogra_, do you know if we have working kernel snaps as well?
<ogra_> kyrofa, all in the store
<kyrofa> ogra_, awesome, any chance you know where the sources are?
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> dragonboard  is still a local build from the deb in the archive
<ogra_> all others come from these device tarballs
<kyrofa> ogra_, I mean the thing containing the snap.yaml. These are all built, right?
<ogra_> manually
<ogra_> using the scripts from http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
<ogra_> (which i hope to have integrated into the build system soon)
<kyrofa> ogra_, ah, thanks!
<sergiusens> ogra_, kyrofa --install is no different in udf logic to putting it in  a gadget
<kyrofa> sergiusens, awesome
<ogra_> sergiusens, well
<ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --gadget canonical-dragon.canonical --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical -o dragonboard-all-snap.img
<ogra_> that gets me an installed webdm without anyx systemd units in place and without the current symlink
<ogra_> in that state i cant remove or install the package and auto-upgrades break when trying to stop the webdm service
<ogra_> err
<ogra_> sudo ./ubuntu-device-flash core rolling --channel edge --gadget canonical-dragon.canonical --kernel canonical-dragon-linux.canonical --os ubuntu-core.canonical --install webdm.canonical -o dragonboard-all-snap.img
<jdstrand> pindonga: something isn't right. I just uploaded hello-world 16.04-2 (20) to the store and I see:
<jdstrand>  2 Passes
<jdstrand> OK Stated package version matches the manifest
<jdstrand> OK Is a valid click package
<ogra_> that was the right one (sorry, pasted from the wrong terminal)
<sergiusens> ogra_, right; I'm saying if it is roken for one case it is also brokem for the other
<kyrofa> ogra_, man was I confused :P
<ogra_> sergiusens, well, gadget is installed ... and i can manually upgrade ubuntu-core
<jdstrand> pindonga: the review tools aren't being run
<ogra_> the system works fine otherwise
<jdstrand> pindonga: https://myapps.developer.ubuntu.com/dev/click-apps/1999/rev/20/
<pindonga> jdstrand, errr... staging... the new stuff hasn't landed on prod yet
<jdstrand> oh
<jdstrand> pindonga: when do we expect that to happen?
<pindonga> jdstrand, early next week
<pindonga> I'll see if I can do that today
<pindonga> but no promises
<jdstrand> ok, thanks
<renat> Hi all! It's Renat from Screenly=)
<kyrofa> Hey renat :)
<renat> First of all I want to thank snappy team for help.
<renat> =)
<pindonga> jdstrand, if I pull this off, is r601 of crt good to go?
<renat> Our first snap worked well=)\
<jdstrand> pindonga: yes
<ogra_> renat, yay !
<renat> I have questions, as usual=)
<renat> What do snap developers use to build their snaps for raspberry pi? We used Ubuntu MATE, but maybe there are other solutions?
<pindonga> jdstrand, pls test on staging sca as we won't roll out to prod if we find the review tools broken there
 * pindonga is testing as well
<jdstrand> pindonga: the last time I tried on staging istr that I wasn't able to test
<beuno> renat, we're building out snap building into Launchpad
<pindonga> jdstrand, why?
<jdstrand> pindonga: can you tell me where to go to try again?
<beuno> renat, so you can build them for ARM in there if you don't have the hardware
<jdstrand> idr
<pindonga> jdstrand, https://myapps.developer.staging.ubuntu.com
<jdstrand> I'll try now though
<pindonga> thx, let me know if you have any troubles
<beuno> renat, just push a branch with snapcraft, and there will be an option to build a snap from it
<renat> I have=) I build on the RaspberryPI2. It's ultra slow=)
<renat> beuno, thanks! Amazing!
<jdstrand> pindonga: I can't login with the shared account
<beuno> renat, you probably need to enable ARM specifically, I think it doesn't build for ARM by default
<beuno> on the change details for the snap, once you create it
<jdstrand> pindonga: should I try with my personal lp account?
<ogra_> renat, for native builds i use the classic dimension under snappy itself ... "sudo snappy enable-classic; snappy shell classic".... then just use apt as usual
<renat> ogra_, never tried that.
<renat> Thanks for help. Now I have something to experiment with!
<ogra_> :)
<pindonga> jdstrand, remember staging myapps uses staging sso
<pindonga> so separate account
<renat> beuno, never used launchpad before. Going to investigate its capabilities soon, thanks.
<jdstrand> pindonga: I'm not trying to be dense, but I don't know what to do with that information. are you saying I need to use a separate staging account? if so, how do I get one?
<jdstrand> I think I see now why I wasn't able to test on staging :P
<pindonga> jdstrand, sorry, yes, you need a staging sso account (login.staging.ubuntu.com)
<pindonga> jdstrand, don't worry, I'll do the testing
<jdstrand> zyga: hey, I have this yaml: http://paste.ubuntu.com/15274178/ and if I try to install then I see:
<pindonga> no point in you having to struggle with this
<jdstrand> $ sudo snappy install /tmp/snappy-interfaces-security_0.1_all.snap
<jdstrand> Installing /tmp/snappy-interfaces-security_0.1_all.snap
<jdstrand> Waiting for snaps-snappy\x2dinterfaces\x2dsecurity.sideload-LSDpPYfYXdlm.mount to stop.
<jdstrand> /tmp/snappy-interfaces-security_0.1_all.snap failed to install: only a single slot is supported, 2 found
<jdstrand> pindonga: ok thanks. I think it's possible that was the exact outcome we had last time :)
<pindonga> quite likely :)
<jdstrand> zyga: is there a bug in the yaml or is this just that the interfaces work isn't completed yet?
<jdstrand> I believe I am following the documented spec
<ysionneau> zyga : so I'm still trying to find out why my hello world (which does dlopen) crashes when it's cross compiled with my own toolchain, but works when using native compiling (in classic shell)
<ysionneau> I've attached gdb to the process
<jdstrand> mvo_: ok, fyi, hello-world uploaded with updated bash. the store fixes are only on staging. pin donga is working on getting them in prod today, but it might be monday
<ysionneau> and when I look at /proc/<pid>/maps , it shows it's using the libraries from the .snap (libc, libdl, libgcc_s) but it's using the dynamic linker from the system
<ysionneau> /lib/arm-linux-gnueabihf/ld-2.21.so
<ysionneau> I guess this causes the crash
<ysionneau> any idea how I can try to use /snaps/hello.sideload/IOCceQHPQPfQ/lib/ld-linux-armhf.so.3 instead of /lib/arm-linux-gnueabihf/ld-linux-armhf.so.3 ?
<ysionneau> I can confirm if I run /lib/ld-linux-armhf.so.3 /snaps/hello.sideload/IOCceQHPQPfQ/usr/bin/hello it crashes, if I run /snaps/hello.sideload/IOCceQHPQPfQ/lib/ld-linux-armhf.so.3 /snaps/hello.sideload/IOCceQHPQPfQ/usr/bin/hello it works
<ysionneau> so it's indeed a dynamic linker issue
<ogra_> try a wrapper script that sets PATH ?
<ogra_> hmm, though that wont help i guess
<ysionneau> ok I get it now
<ysionneau> I will wrap all my binaries with something that will call $SNAP/lib/ld-linux-armhf.so.3 <binary_name>
<ysionneau> 17:04 < ogra_> hmm, though that wont help i guess < nop because the dynamic linker does not use LD_LIBRARY_PATH or PATH, it's loaded by the kernel, taking the string in the "interp" section of the ELF
<ysionneau> but it's OK to prefix the binary with the path to the dynamic linker in a wrapper
<ysionneau> o/
<ysionneau> I might end up with something which works after all...
<ogra_> awful, but will likely work :)
<ysionneau> not more awful than all the already existing wrappers :p
<ogra_> haha, yeah
<ogra_> wrappers in wrappers that are in wrapped wrappers :)
<ysionneau> ;)
<ysionneau> yep
<ysionneau> it's either this, or hard coding it in ubuntu-core-launcher like "if (there is a dynamic linker in the snap) execve prefixed with it"
<ysionneau> but I suspect you would not like this upstream
<ogra_> no idea, i dont maintain the launcher ;)
<ysionneau> ah so maybe you would +2 this :p
 * ysionneau joking
<ogra_> if it saves the dve from hassles i could actually imagine it going upstream
<ysionneau> dve ?
<ogra_> but i guess the heuristics of "whats a wrapper, how do we identify there is one" might be pretty complicated
<ogra_> err
<ogra_> s/wrapper/linker/
<ogra_> (my head is also full of wrappers it seems)
<ogra_> *dev
<ogra_> tedg, ^^
<tedg> ogra_: ?
<ogra_> tedg, if a package ships its own linker,, would it make sense to handle that from ubuntu-core-launcher ?
<ogra_> (instead of having to have another wrapper to prefix all calls with the linker path)
<tedg> ogra_: I'd say that we don't have a way to signal things to the launcher today, so the wrapper is the better option. I'd like to see the launcher get smarter, but I think that needs to be engineered.
<ysionneau> 17:22 < ogra_> (my head is also full of wrappers it seems) < that's when you wrap your head around it
<tedg> ogra_: It would be nice if it could load all the environment variables in a consistent way as well, for instance.
<ogra_> tedg, yeah, in the case of the linker you dont really have an env var though
<tedg> ogra_: Sure, just talking about other things that a more rich launcher would handle.
<ogra_> you need to wrap your exec calls into something like "$SNAP/lib/ld-linux-armhf.so.3 <binary_name>"
<ogra_> and it would be nice if we could just tell the launcher to do that for us
<ysionneau> yep, when you detect that the interp of the binary does exist in the $SNAP/
<ysionneau> means you need to parse the ELF to get the interp string
<ysionneau> that's actually not that hard to add to the launcher :o
<ogra_> well, it could be some option ... or config
<ogra_> you dont want to do it all the time
<ogra_> (most people will likely just use the system linker)
<ogra_> (and rely on LD_LIBRABRY_PATH for their own libs)
<kyrofa> wiggleworm, you still around?
<ysionneau> well, if you have a path that corresponds to the dynamic linker in your $SNAP, you most likely want to use it
<jdstrand> niemeyer: you seem to have disconeected
<kyrofa> ogra_, so if cdimage is used to create the kernel snaps, where might I find the kernel configs that we use?
<ogra_> either in the source package or in the git trees on kernel.ubuntu.com (ask the kernel team for specific branch urls)
<kyrofa> ogra_, excellent thank you
<sergiusens> ogra_, do you know if your initrd made it into an OS snap?
<ogra_> sergiusens, it made it into all tarballs ... no idea if mvo rebuilt the os snaps today though
<ogra_> (its all manual)
<ogra_> http://people.canonical.com/~ogra/core-image-stats/20160303.changes
<sergiusens> yeah
<ogra_> worst case roll your own http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
<ogra_> (the mk-os ones should suffice)
<sergiusens> ogra_, he'll be pushing one soon
<ogra_> k
<sergiusens> ogra_, where is this generic initrd installed btw?
<ogra_> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.20$ cat debian/ubuntu-core-generic-initrd.install
<ogra_> build/boot/* usr/lib/ubuntu-core-generic-initrd/
<ogra_> ogra@styx:~/Devel/packages/initramfs-tools-ubuntu-core-0.7.20$
<ogra_> :)
<sergiusens> thanks
<pindonga> jdstrand, hey, got crt 601 to prod... could you please test uploading some snap ?
<pindonga> the fact we can't upload snaps with the same name anymore is a nuisance for testing :/
<sergiusens> jdstrand, hey, I never got your ack/nack on https://github.com/ubuntu-core/snapcraft/pull/360
<rajen> Folks. Is there a place where you are uploading ".img" file or ".snap's" of daily-preinstalled xenial builds.  I am looking for ubuntu-core snap files when they get released.
<jdstrand> pindonga: it is
<jdstrand> sergiusens: I'm going to test that snap, have a quick bite to eat, then review your PR
<jdstrand> sergiusens: btw, I dig 'snapcraft snap <dir>'
<jdstrand> :)
<jdstrand> so much nicer than remembering the mksquashfs commands
<jdstrand> s/commands/args/
<jdstrand> pindonga: woo!
<jdstrand>  1 Warning
<jdstrand> could not determine fstime of squashfs security-snap-v2_squashfs_supports_fstime
<jdstrand> 58 Passes
<jdstrand> perfect-o!
<pindonga> \o/
<jdstrand> pindonga: what interesting though is I don't see the review tools commit number in the passes output any more
<jdstrand> pindonga: that certainly doesn't have to be a rushed fix
<pindonga> it's only listed for reviewers
<jdstrand> ah
 * pindonga double checks though, should be there
<jdstrand> pindonga: I can do it
<jdstrand> pindonga: 601 click-reviewers-tools version
<pindonga> yep
<jdstrand> pindonga: thanks for the quick turnaround
<pindonga> happy it (seemed) to work well (so far)
<pindonga>  :)
<jdstrand> beuno: fyi, the store is back to reviewing again :)
<jdstrand> thanks to pindonga :)
<jdstrand> I guess I helped a little
<pindonga> :)
<the-solipsist> Sorry for a stupid question, but I'm a newbie... If snappy already does app isolation, why would anyone want to install docker on it?
<Mikaela> Probably because docker has mostly everything available while snappy doesn't have so much
<the-solipsist> So, it's just a matter of time?  And, if Docker provides the kind of app isolation that snappy does, then why create snappy at all?  I can understand the need for LXD, but not for Snappy...
<sergiusens> the-solipsist, there's a nice email from Mark in the mailing lists explaining when to use one or the other
<ogra_> there are people using snappy in cloud envs ... they are used to docker and have their setups ready to just use them ...
<popey> ogra_: I'm told that in the debian world, one just does a dist-upgrade and rpi-update of an image inside a pi 2, to make it work in a pi 3.
<popey> https://twitter.com/winkleink/status/705477199042838528
<popey> so I guess we need to find out what that does, and update our image, then our image will work on pi 2 and pi 3
<ogra_> popey, yeah, most likely some kernel changes to get the devicetree file for the new pi ... and likely also some bootloader updates
<ogra_> i'll check on the weekend
<wiggleworm> orga_: Do you know anyone who has created a snapcraft.yaml file to build tools usbutils or pciutils?
<ogra_> wiggleworm, i doubt that will be possible in a way that you can upload this snap to the store
<ogra_> (i might be wrong, but i suspect you will need to access most of /proc and such which means you need to run unconfined ... which in turn means you wont be allowed into the store)
<ogra_> wiggleworm, if you want unconfined you can take a look at somehting like http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files though
<wiggleworm> thank you - I will look
<ogra_> (note though that this hasnt been ported to the security model de jour yet (now called "interfaces") bt still uses last weeks "skills" system)
 * ogra_ goes afk ...
<dduffey> kyrofa, lool : I am compiling the 3.18 kernel now and seeing if my compile of that vmlinuz still links with with binary modules I have ... if so, then I will re-compile that 3.18 with the necessary kernel settings snappy needs ... do you have a list of config options that I need (and I'm assuming it is okay to statically compile in items rather than have them as modules/add them to initrd)
<jdstrand> sergiusens: done
<sergiusens> jdstrand, thanks
<sergiusens> jdstrand, hm, should I add umask != 0 as well?
<jdstrand> sergiusens: you could. that is actually something I would expect the review tools to catch (ie, 0777 file perms)
<jdstrand> plus, other access isn't as big of a deal-- a snap shouldn't be shipping private data since it isn't actually private
<jdstrand> I don't think it is needed. let the review tools discover weird perms
<sergiusens> jdstrand, ok, seems good
<sergiusens> kyrofa, mind to start reviewing https://github.com/ubuntu-core/snapcraft/compare/master...sergiusens:feature/1552168/kernel-plugin#diff-a6d756e312a41b33e3a9de439c8527a8R9 ?
<sergiusens> kyrofa, the busybox example already works
<sergiusens> let me just create a PR
<popey> ogra_: fyi, sudo iwconfig wlan0 power off - needed on pi 3, it power saves wifi which means it's unusable
<zyga> jdstrand: thanks for the meeeting notes
#snappy 2016-03-04
<zyga> good morning
<didrocks> hey zyga
<noizer> good morning!
<zyga> hey :)
<zyga> how are you doing
<zyga> (zero days since the last terminology change ;)
<dholbach> put that in the topic :)
<ogra_> capaskillfaces !
<zyga> ogra_: now you have to read that backwards
<ogra_> heh
<ogra_> security imlpementation du jour: "interfaces with reversed plugs, 9,90â¬ ... kids plate, 6,50â¬"
<zyga> ogra_: uk plugs or us plugs?
 * zyga falls screaming into the abyss
<ogra_> doesnt matter as long as they are reversed :)
 * ogra_ wishes we would actually care for some stability inseatd
<zyga> ogra_: nah, this doesn't affect stability in any way
<zyga> ogra_: I'm glad we changed it, it was backwards
<ogra_> zyga, it occupies dev rtecources
<ogra_> *ressources
<zyga> ogra_: and saves user resources later on
<ogra_> i still cant use classic on arm64 ... i still can install all gadget snaps from froreign arches
<ogra_> (on a running system)
<zyga> ogra_: well, different resources
<ogra_> webdm doesnt really work
<ogra_> etc etc
<zyga> ogra_: webdm has tons of love lately
<ogra_> there are tonms of things that need fixing before release
<zyga> ogra_: yeah, I know
<ogra_> but we are changing terminology of core features instead
<zyga> ogra_: we're all working towards getting there
<ogra_> zyga, by 16.10 ?
<zyga> ogra_: 16.04!
<ogra_> what we have today isnt release worthy yet and still needs liots of work on all levels ...
<zyga> ogra_: in reality renames only affected my work
<ogra_> zyga, and everyone who has snaps in the store
<ogra_> (or who wants to have them in the store for release)
<zyga> ogra_: they didn't use interfaces yet, they will but nothing in the store uses them now
<ogra_> all my (three yet, because i gave up packaging when there was the announcement) snaps use them with migration-skill
<zyga> mmmm, okay, I give you that
<ogra_> and i have a few more that i had to re-do from scratch three times ...
<ogra_> for me thats fine, but for people that want their stuff in the store for release it is probably not
<sergiusens> ogra_, hey, I'm late to the party; my 410c boots android and can't make it boot from the sdcard (using your image on p.c.c); any ideas?
<noizer> How can i make from my app a service so I can start and stop it with the rest api?
<noizer> zyga
<zyga> noizer: you'd have to talk to snapd and use an appropriate request, you'd also need an interface to talk to snapd in the first place (I'm making one)
<zyga> noizer: a bit busy now, perhaps it's not all ready yet but that's the idea
<noizer> hmmm
<zyga> noizer: you want snappy services but I'm not sure if that's on the rest api today
<noizer> zyga https://developer.ubuntu.com/en/snappy/guides/rest/
<zyga> noizer: always look at docs/rest.md
<zyga> noizer: that's the current version
<zyga> noizer: this one is probably a few days old
<noizer> its the same and there i can see /2.0/snaps/name/services
<noizer> https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#20snapsnameservicesname zyga
<ogra_> sergiusens, did you set the dip switch to SD boot at the bottom of the board ?
<sergiusens> ogra_, no, I searched the manuals/internet for some sort of information about that
<ogra_> well, make sure that one switch is set to "on"
<ogra_> else it wont even try the Sd
<sergiusens> ogra_, oh, now that I turn it upside down it is obvious :-P
<sergiusens> ogra_, thanks
<ogra_> works ?
<sergiusens> ogra_, yeah; well I don't see SElinux anymore and cloud-init instead ;-)
<ogra_> good
<ogra_> tell me if the upgrade works .... there are newer kernel and os snaps in the store for it
<sergiusens> sure, let me setup wifi first
<ogra_> yeah
<ogra_> one of my cats seems to have had some bad fight tonight, she is pretty injured on one leg, i'll need to go to the vet soon
<ogra_> (no idea if/when i can return)
<sergiusens> k
<sergiusens> good luck with that
<ogra_> yeah
 * ogra_ hopes for the best ... seems she can still stand up 
<sergiusens> ogra_, oh, that bad
<ogra_> yeah
<ogra_> i guess a dog or racoon
<noizer> ogra_ do you know how that i can my apps to services. So i can start and stop my services with the REST api
<ogra_> i saw the mail discussion
<noizer> zyga about the python api does i need to take a fork of ubuntu-core/snappy?
<zyga> noizer: no, please start with an empty repo
<zyga> noizer: that will make it easier to work with on pypi later
<zyga> noizer: for releases / qa
<zyga> noizer: start with a simple package that has all the public APIs in the client/ package today (use python conventions rather than go conventions for methods though)
<zyga> noizer: and we can fill in the blanks, most of the stuff is really easy, you just have to define the input and output format (data is almost always json)
<ysionneau> morning
<zyga> o/
<ysionneau> stupid question: how would one put a binary (actually a shell script wrapper) in the snap package?
<ysionneau> I mean by having this script at the same level as the snapcraft.yaml
<ysionneau> and not cloned as a remote part
<ysionneau> s/cloned/fetched/
<zyga> ysionneau: use a part with source: .
<zyga> ysionneau: I use that all the time
<noizer> zyga oooh ok. an other question about Services. when is an app a service?
<ysionneau> right, I knew this had a simple solution, thanks!!
<zyga> ysionneau: e.g. https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml
<zyga> noizer: there are no services, the terminology for that is "all things are apps/applications"
<zyga> noizer: some applications run in the background
<ysionneau> ah so I should do a Makefile which will cp my wrapper in $(DESTDIR) ?
<zyga> noizer: an application runs in the background if it has an extra line in the snap.yaml / snapcraft.yaml that says how exactly it runs in the background
<ogra_> ysionneau, you can use the copy plugin
<ogra_> ysionneau, http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml
<zyga> ysionneau: you can, there's also some snapcraft plugin for doing just that but I don't remember, would have to refer to snapcraft source code again
<ogra_> ysionneau, (see what it does with the README)
<ysionneau> awesome, you guyz rock
<zyga> ysionneau: but a trivial makefile with the right targets is more scalable if you don't want to remember :)
<zyga> thanks ogra_ :)
<ogra_> makfile will indeed work as well :)
<zyga> nothing like good old make
<ysionneau> yes
 * ysionneau likes makefiles
<zyga> https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile
<zyga> sergiusens: https://github.com/zyga/snappy-pi2-piglow/blob/master/Makefile#L3
<ysionneau> yep I wa son it
<ysionneau> was on*
<zyga> sergiusens: small thing I found, snapcraft ignores /usr/local and if your executables are there, it crashes
<noizer> zyga why is there then in de REST api some things about services
<zyga> noizer: probably legacy
<zyga> noizer: we may rename the API
<zyga> noizer: for now you can call it a service but most places call it background application already
<noizer> zyga oooh ok so if i add something like deamon: simple it will be a background app
<zyga> noizer: yes
<noizer> zyga ok
<zyga> noizer: (we plan to consolidate that naming so expect some changes later today/next week) but yes
<noizer> zyga thats no problem it was just confusing xD
<zyga> noizer: yep
<renat> Hi all! It's Renat from Screenly=)
<renat> kyrofa, hi!
<renat> I commented in snapcraft's copy plugin pull request.
<renat> I think - that if file is absolute symlink - we should copy it as a symlink.
<dholbach> renat, might take a bit longer until kyrofa is up
<renat> dholbach, thanks. I will visit later today.
<zyga> renat: hey
<renat> zyga, hi!
<noizer> zyga can I uses ports within apps because snapcraft says it was unexpected
<zyga> noizer: nope, ports was removed
<zyga> noizer: it never really did anything
<noizer> heheeh xD
<zyga> noizer: so it was either removed now (I didn't check) or it's in the queue for removal
<zyga> noizer: just don't use it, nothing changes
<noizer> zyga ok how can i say to my background app that he may uses some sockets because there i got a permission error?
<zyga> noizer: which socket?
<noizer> tcp/ip
<noizer> zyga
<zyga> noizer: do you want to use the network or create a network service?
<zyga> noizer: (do you want to be like apache or connect to apache) in less technical terms
<noizer> i needed both
<zyga> noizer: ok, you need to use two interfaces for that:
 * zyga looks
<zyga> noizer: the new names for the interfaces are "network" (you can talk to other things on the network) and "network-bind" (they can talk to you, you can bind to ports, etc)
<zyga> noizer: but I think today the only way to use them is to use old-security interface with the names "network-client" and "network-listener"
<ogra_> i found network-client more intuitive for the first one
<sergiusens> zyga, of all todays, today I can't do irc; prepping for travel here; so a bug or tlaking to kyrofa would be best
<ogra_> "network" sounds like "globally all network features"
<noizer> zyga does i need to use then slots and ect
<zyga> noizer: I'll land a lot of interfaces today, but you still need to use the old-security with the images that are out there
<zyga> ogra_: "you want to connect to the network" was the rationale
<ogra_> zyga, sure, but the other options all have suffixes
<ogra_> so it sounds pretyt global to me
<zyga> noizer: you have to use the "slot" but next week that becomes "plug" (you plug old security into your application)
<zyga> noizer: https://github.com/ubuntu-core/snappy/pull/580
<ogra_> (me shuts up bfore anyone changes any names again)
<zyga> noizer: virtues of a development release
<zyga> ogra_: I shall name you argo
<zyga> ;D
<zyga> ogra_: most don't
<zyga> ogra_: all the old security bits were modelled after capabilities
<zyga> ogra_: and now that each connection has two sides, we can discard half of those in most cases
<noizer> dam it is very confusing with all these versions
<zyga> ogra_: e.g. mir is just one interface, no mir-client, mir-server
<zyga> ogra_: same with docker
<zyga> noizer: just wait till monday please
<zyga> noizer: it's settling
<ogra_> zyga, lol
<ogra_> high hopes
<zyga> noizer: we'll make the docs all up to date
<zyga> ogra_: I actually like this change a lot, much better than having mir-server being provider by ubuntu-core or kernel snaps
<zyga> ogra_: it's just one interface, mir
<ogra_> (my lol was rather about the "it's settling" )
<zyga> ogra_: you have an app that offers mir slot and many apps that plug into that
<zyga> ogra_: (oh, it is, really)
<ogra_> i belive it when i see it
<zyga> ogra_: (we had a three hour meeting yesterday and it was very productive)
<zyga> ogra_: very well :)
<noizer> zyga will it for now be enough to use this? http://pastebin.com/7sHfGU3Z
<zyga> no, "old-security" rather than "migration-skill"
<zyga> and also do "network-client"
<zyga> (second cap)
<zyga> because you need both
<zyga> by default snaps are offline
<noizer> zyga pfft  {'caps': ['network-listener', 'network-client'], 'type': 'old-security'} is not valid under any of the given schemas
<didrocks> noizer: using snapcraft master?
<noizer> i think so
<noizer> didrocks
<didrocks> s/type/interface/
<didrocks> (since yesterday late ;))
<zyga> noizer: "interface", not "type"
<zyga> thanks didrocks :)
 * zyga works on adding about a dozen new interfaces to snappy
<ogra_> Mar  4 11:35:33 localhost kernel: [  114.926577] audit: type=1400 audit(1457091333.026:13): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=1  capname="dac_override"
<ogra_> Mar  4 11:35:33 localhost kernel: [  114.926680] audit: type=1400 audit(1457091333.036:14): apparmor="DENIED" operation="capable" profile="webdm.canonical_snappyd_0.16" pid=1088 comm="snappyd" capability=2  capname="dac_read_search"
<ogra_> hmm
<ogra_> i guess webdm needs updating :)
<ogra_> though this is funny since webdm loads the unconfined profile first
<noizer> didrocks zyga uses:
<noizer>   listener:
<noizer>     interface: old-security
<noizer>     caps: [network-listener, network-client]
<noizer> like that?
<sergiusens> zyga, did the plug<->slot thing make it into edge?
 * sergiusens wonders about releasing a supporting snapcraft
<zyga> sergiusens: https://trello.com/c/nUsc10Ra/43-swap-plugs-and-slots-around
<zyga> sergiusens: https://github.com/ubuntu-core/snappy/pull/580
<zyga> sergiusens: needs review, then needs release (I have no idea how that works yet though)
<zyga> sergiusens: let's work together on coordinating this today
<zyga> sergiusens: I'd like to end the week in a stable state
<zyga> noizer: looking
<zyga> noizer: yep
<zyga> noizer: and refer to "listener" from slots in your snap, tomorrow this just changes to "plugs"
<noizer> zyga what will be the syntax?
<zyga> noizer: look at existing examples
<zyga> noizer: https://github.com/ubuntu-core/snapcraft/blob/master/examples/webchat/snapcraft.yaml
<zyga> noizer: tomorrow we just swap slots/plugs around
<zyga> noizer: and next week, old-security can be somewhat replaced by native interfaces: [network, network-bind]
<zyga> noizer: I'll announce it when it can be used
<stevebiscuit> ogra_: this should solve that: ttps://code.launchpad.net/~stevenwilkin/webdm/skill-to-interface-snap-yaml/+merge/287760
<zyga> noizer: snapcraft examples are the best way to learn :)
<stevebiscuit> s/ttps/https/
<ogra_> stevebiscuit, ah, cool
<ogra_> i'll just wait
<ogra_> oh, crap
<ogra_> the generic initrds are gzip compressed
<noizer> zyga ok i still got an error but i am using snapcraft 2.3.2 is that not update to date?
<zyga> noizer: I'm not sure
<zyga> noizer: what did you exactly do and what the error was?
<noizer> zyga Issues while validating snapcraft.yaml: Additional properties are not allowed ('slots' was unexpected)
<zyga> noizer: o_O not sure, ask sergiusens, maybe your snapcraft is out of date
<zyga> noizer: check if you can build the example I linked to
 * zyga -> back to hacking
<ogra_> oh crap !
<ogra_> pitti, so my initrd now ends up with a /lib64 dir
<ogra_> with the linker in it
<ogra_> which results in non executable binaries
<ogra_> yeah, moving the linker to /lib fixes it :(
<ogra_> argh
<ogra_> except ...
<ogra_> Begin: Running /scripts/local-premount ... wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
<ogra_> wait-for-root: error while loading shared libraries: libudev.so.1: cannot open shared object file: No such file or directory
<ogra_> damned
<sergiusens> zyga, we never landed that
<sergiusens> zyga, we are going to land 7 breaking changes in a row, sorry
<zyga> sergiusens: 7?
<ysionneau> I'm not the only one to fight against dynamic linker issues
<ogra_> ysionneau, well, i'm rather fighting fakechroot here
<ogra_> bug 1553110
<ubottu> bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110
<ysionneau> ah ok
<pitti> ogra_: /lib64/*ld.so* should/could just be a symlink to /lib
<pitti> ogra_: that's at least how it is on amd64
<ogra_> pitti, well, indeed it isnt beacuse i hacked the outer script to just have /lib64 ... whats more worrying though is that libudev doesnt end up in the initrd at all now
<ogra_> pitti, for the linker there is a hack in mkinitramfs for armhf already that we likely need to copy for arm64
<sergiusens> zyga, I was being sarcastic; I was about to release yesterday but with this change cancelled the release completely
<ogra_> it had a similar prob
<sergiusens> it makes no sense to promote something that is going to be inverted
<ogra_> but that doesnt explain the missing libudev
<sergiusens> I'd just tell people to use ubuntu-core/stable
<sergiusens> ogra_, I am almost there with the logic for this :-)
<ogra_> sergiusens, i guess all but arm64 should work
<ogra_> pitti, see line 337 ff in /usr/sbin/mkinitramfs
<ogra_> not actually lib64 ... but the same issue
<sergiusens> ogra_, oh I did see a lib64 in amd64's generic initrd and jumped to conclusions
<sergiusens> with an ld symlink too
<ogra_> symlink ?
<pitti> ogra_: so I guess it'd be best to actually fix fakechroot instead of adding further hacks
<ogra_> there shouldnt be one
<ogra_> pitti, hmpf
<sergiusens> ogra_, $ ls -l lib64/
<sergiusens> total 0
<sergiusens> lrwxrwxrwx 1 sergiusens sergiusens 34 mar  4 06:46 ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-2.21.so
<pitti> amd64 *should* and even *must* have a /lib64
<pitti> amd64 vs. arm64 confusion? :-)
<ogra_> pitti, i thought colin said it shouldnt
<pitti> no, he said we shouldn't proliferate that to other arches like arm64
<sergiusens> pitti, nah; I was going by ogra's symptoms, not saying anything is wrong or right
<ogra_> pitti, well, not even debootstrap creates lib64 on arm64 atm
<pitti> right
<pitti> I thought you just created it as workaround for that fakechroot thingy
<ogra_> yeah
<ogra_> and that works fine ... for everything but wait-for-root
<pitti> so maybe create the /lib64 symlink, do the fakechroot bootstrap, and remove it again before building the image?
<pitti> s/image/initrd/
<ogra_> you mean hacking up update-initramfs ?
<pitti> the place where you added it doesn't have code which runs after the initrd build?
<zyga> rpi3 arrived
<zyga> hmmm
<ogra_> no
<ogra_> well, it doesnt have code that runs "inside" the initrd
<ogra_> thats all left up initramfs-tools hook scripts
<ogra_> i'm just modifying the build chroot to have the dir
<pitti> ogra_: perhaps try wiht a /lib64 -> /lib symlink?
<pitti> instead of a symlink or even a copy *in* /lib64/ ?
<ogra_> pitti, will do, but i doubt that will fix the missing libudev
<ogra_> i can indeed forcefully copy it in place with a hack-hook or some such
<ogra_> still ... not cool :(
<noizer> zyga I need to upgrade my snapcraft what is the best way to do that?
<zyga> noizer: please wait, we're trying to figure out when to release a compatible set of tools for everyone to use so that no confusions are spread
<noizer> ok so i need to do nothing today on that?
<zyga> noizer: soon you should have all the bits in master but we need to release them to make sense
<noizer> zyga: ok how long does I need to wait for that?
<zyga> noizer: most likely on monday, we'll decide
<zyga> and announce this
<noizer> OK
<kyrofa> Good morning
<ogra_> pitti, hmm, isnt libudev also a thing that udevd should pull into the initrd
 * ogra_ still doesnt get why it is missing ... copying it in manually makes everything work 
<ogra_> (including the udevd that is in the initrd)
<ogra_> oh, wow
<ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps$ ldd $(which udevd)|grep udev
<ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps$
<ogra_> so it isnt linked against the lib at all ... interesting
<ogra_> WTF !
<ogra_> so libudev isnt in any of the initrds
 * ogra_ wonders whats going on here 
<torbit> Hi folks
<torbit>  I am currently trying to ensure that I am working on porting snappy core to a new board.
<torbit> I am trying to get it to give me output via the serial console on booting up
<torbit> anyone know where I can do that from as I can not see a grub.cfg file in boot->grub
<pitti> ogra_: right, udevd isn't meant to link against libudev, it uses an internal (richer, but unstable/non-public) API
<ogra_> yeah
<ogra_> i still dont get why the lib isnt in any of the inirds
<pitti> ogra_: I suppose the only thing that needs libudev in the initrd nomrally is wait-for-root
<ogra_> on all arches
<ogra_> yeah
<pitti> $ lsinitramfs /initrd.img |grep libudev
<pitti> lib/x86_64-linux-gnu/libudev.so.1.6.4
<ogra_> right
<ogra_> it isnt in any that my script built
<pitti> ogra_: fakechroot b0rkage?
<ogra_> (i'm 100% sure it is in the phone initrds, else they wouldnt boot at akll)
<ogra_> the script is the same ... as is the build process
<ogra_> i just uploaded a test version with libfakeroot and libfakechroot in the build chroot ... lets see if that changes anything
<ogra_> (they will end up inside the initrd though ... which i was wanting to avoid)
<pitti> ogra_: uploaded? I thought you have access to an arm64 instance to do local test builds
<pitti> (I can give you one if you need)
<ogra_> i do, but uploading is faster :)
<pitti> well..
<torbit1> ermâ¦lost connection..did anyone say anything with regards to my last post
<ogra_> ok, adding the t6wo libs didnt change a thing
<ogra_> (apart from quietening the build log)
<ogra_> pitti, did we ever find out what actually copies wait-for-root ?
<ogra_> i cant find a hook for it
<ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/share/initramfs-tools/*
<ogra_> /usr/share/initramfs-tools/scripts/local:		FSTYPE=$(wait-for-root "${ROOT}" ${ROOTDELAY:-$ARCHDELAY})
<ogra_> /usr/share/initramfs-tools/scripts/local-premount/resume:SWAPTYPE=$(wait-for-root "${resume}" ${RESUMEDELAY:-5})
<ogra_> aha
<ogra_> ogra@anubis:~/datengrab/dragonboard/all-snaps/foo/ramdisk$ grep -r wait-for-root /usr/sbin/mkinitramfs
<ogra_> copy_exec /usr/lib/initramfs-tools/bin/wait-for-root /sbin
 * ogra_ bets if he adds that to some hook it will actually DTRT
<pitti> ogra_: I don't think it's in a hook, it should be copied by the i-t core code
<pitti> ogra_: right, that
<ogra_> yeah, it is hardcoded in /usr/sbin/mkinitramfs
<ogra_> let me try making it a hook, just for fun :)
<kyrofa> beuno, if I want to ship a device with some custom kernel modules, I make a kernel snap (I assume). I make a snap to utilize those new modules, and upload it to the store. Is there anything preventing someone else (who doesn't have my kernel snap) from installing that snap which then breaks for them?
<beuno> kyrofa, hi!
<beuno> yes, interfaces!
<kyrofa> beuno, ahh, okay
<beuno> your kernel would expose interfaces for those special modules
<ogra_> would it ?
<ogra_> even if the user simply uses snappy config ubuntu-core and force-loads them ?
<ogra_> kyrofa, your user would have to actually create an image using u-d-f ... you can load different kernel snaps
 * ogra_ tried that already
<ogra_> "a snap of this name is already installed"
<ogra_> ;)
<kyrofa> ogra_, interesting, okay
<ogra_> (err: you can *not* load)
<ogra_> kyrofa, i dont see where interfaces come into play for modules though, but beuno might know more than I
<ogra_> (i mean, beyond the obvious .... accessing devices under /dev)
<kyrofa> ogra_, I assume it would be more of a "the current kernel doesn't provide a slot for this interface, so I can't plug into it"
<beuno> ogra_, you expose an interface the exposes a funcionality you don't have otherwise
<beuno> right
<beuno> so you can filter on it, etc
<kyrofa> Yeah that makes sense. Even if the interface provided nothing other than the filter
<kyrofa> Thanks beuno , ogra_ :)
<ogra_> beuno, right, but the module would load regardless, it is only the device access you block
<ogra_> (so my in-kernel-keylogger.ko would still work ;) )
<beuno> correct
<kyrofa> ogra_, right, I was really only wondering if it was possible to upload a snap to the store that requires a custom kernel snap to run
<kyrofa> That didn't break for everyone else
<beuno> kyrofa, does it sound like a good answer to your problem?
<kyrofa> beuno, indeed it does, thank you!
<beuno> w00t
<ogra_> hmm, nope ... moving wait-for-root to an actual hook doesnt change anything
<ogra_> sigh... this is so painful
<ogra_> pitti, any idea what to look for in fakechroot to make it actually work ?
<pitti> ogra_: not off-hand -- I'd start with stracing "fakechroot ldd" call (with -e trace=file) and see where things go haywire
<ogra_> hmm, k
 * ogra_ will have to prepare for the vet now ... i'll try that later 
<ysionneau> zyga ogra_ < about my yesterday dynamic linker issue, now it's fixed. I added some post-processing in my alchemy snapcraft plugin so that it creates wrappers for each detected ELF dynamic executables in installdir
<ysionneau> now it does not crash anymore o/
<ogra_> yay
<ysionneau> I should push my alchemy plugin someday when it's a bit cleaner on my github
<ysionneau> so that people could experiment doing cross compilation of snaps
<zyga> ysionneau: oh, I wasn't aware of what you were doing
<zyga> ysionneau: I think this will open a lot of very nice use cases
<zyga> ysionneau: so you're working on what exactly? generic cross compiler support?
<ysionneau> I'm adding a plugin for snapcraft to support "alchemy" build system (which is some kind of buildroot/Android-build-system on steroid)
<ysionneau> instead of Android.mk it uses atom.mk
<ysionneau> https://github.com/parrot-developers/alchemy
<zyga> ysionneau: is parrot-developers there referring to perl6 parror vm?
 * zyga wonders how that's all interconnected
<zyga> parrot*
<ysionneau> the interesting fact for snapcraft is that it would allow to generate arm32/64 snaps from your amd64 machine (cross compilation)
<ysionneau> nop it's referring to Parrot SA
<zyga> ah
<ysionneau> a French company
<zyga> just ENOGOODFREENAMES
<ysionneau> ;)
<ogra_> drones !
<ysionneau> yep drones :)
<ogra_> :D
<ysionneau> I'm experimenting with Ubuntu snappy, to see if it would be interesting for us (Parrot) to use it on our drones
 * ogra_ would so love to see that
<ogra_> i really like your HW
<ysionneau> the benefit of adding support for alchemy, on our side, is that all our soft/libraries are using this build system. We made the effort of producing atom.mk files for everything
<ysionneau> so it's basically our entry point for anything
<dpm> sergiusens, I did the "interfaces" changes to a desktop snap yesterday as instructed by mvo after the ubuntu-core update. Now when running snapcraft to build it, I get "Issues while validating snapcraft.yaml: Additional properties are not allowed ('slot' was unexpected)"
<ysionneau> anything other than alchemy is a no-go for us as we are not willing to re-do the job of porting all of stuff to a new build system
<dpm> sergiusens, was the snapcraft version that supports interface not yet uploaded?
<zyga> dpm: yeah, I think so
<zyga> dpm: we'll wait for monday to release a compatible set
<zyga> dpm: (snapcraft, snappy, ubuntu-core snap)
<ysionneau> 15:22 < ogra_> i really like your HW  < thanks :))
<dpm> zyga, ok, thanks. Any reason why the set was not released in sync? If I understood it correctly the ubuntu-core snap was already updated yesterday
<kyrofa> sergiusens, no standup today? I know you're trying to get outta here
 * ysionneau received his rpi2
<zyga> dpm: slot and plugs got swapped
<dpm> ah, ok
<jdstrand> zyga: yw
<zyga> jdstrand: hey
<zyga> jdstrand: I asked some question on the telegram, have a look please
<zyga> jdstrand: I'm about to start converting over all the interfaces we talked about to native
<jdstrand> zyga: ack-- give me a few minutes
<zyga> jdstrand: OK
<zyga> jdstrand: I'll have the static security snippet support next
<zyga> jdstrand: then moving to native interfaces
<jdstrand> ok
 * jdstrand is looking at tg now
<zyga> tg?
<zyga> sabdfl: o/
<sabdfl> hey zyga
<jdstrand> zyga: ok, so while we could support per-app device assignment, the previous agreement was that device assignment is per-snap and that is what the launcher is currently doing (per-snap)
<zyga> jdstrand: okay, let's keep that and correct the variable names to accurately reflect that
<zyga> jdstrand: is my patch sensible? i can propose it on launchpad
<jdstrand> zyga: now, all that is pre-capabilities/skills/interfaces stuff, so if it should be per-app instead of per-snap, we need to change in that part of the code and the launcher
<jdstrand> to me it seems sensible to do per-snap assignment
<zyga> jdstrand: ok, let's correct the name with my patch then
<zyga> jdstrand: I'd rather have it land quickly so next week we can release a working bundle
<jdstrand> zyga: your patch is fine in the context of of snappy, but ubuntu-core-launcher needs a corresponding change
<zyga> jdstrand: hmm? but my patch was for ubuntu-core-launcher
<zyga> jdstrand: I pastebinned a patch for that
 * zyga goes to commit and push it for real
<jdstrand> oh, heh, I was to tunnel-visioned :)
<jdstrand> ok, I think then that snappy needs a corresponding change :)
<jdstrand> let me check
<zyga> yep
<zyga> both need to happen
<jdstrand> right, yes
<jdstrand> so, ack from me if both sides are done
<zyga> jdstrand: https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/288116
<zyga> jdstrand: I'll follow up with snappy change
<zyga> perhaps /snappy-app-dev could be renamed to something more accurate too but I don't have a good candiate in my head
<qengho> Hi hi. The package I want to package in a snap has its own internal seccomp profile, and things conflict. What incantation in snapcraft will make a snap with an unconfined profile?
<zyga> qengho: why do you have your own seccomp profile?
<zyga> qengho: we're implementing something called "interfaces" if you need non-default security you'll have to work with us to establish an interface that will let your application work
<qengho> zyga: I do not, but the upstream software does.
<zyga> qengho: for the moment you can use the "old-security" interface and you can use any custom security policy inside
<jdstrand> qengho: chromium is going to be interesting here
<qengho> :(  "interesting"
<zyga> can you explain more how that works?
<wesleymason> Soooooo, I have a snapcraft.yaml for an existing py2 project, that assembles, using the python2 plugin..and I have an "apps" section that in theory should link up to the usr/bin/<appname> console_scripts entrypoint generated by setuptools...but, on sideloaded install in a snappy VM, nada (it's there in apps/ etc.), but no command available from the
<wesleymason> shell...any ideas?
<zyga> can an process constrain itself more while under existing seccomp confinement?
<zyga> wesleymason: ls /snaps/bin
<zyga> wesleymason: and we only support 16.04 here really given that this is the focus of development
<jdstrand> cause they use either a setuid sandbox (which we don't allow setuid in snaps) or a seccomp sandbox (which we disallow changing the seccomp policy in snappy)
<zyga> wesleymason: so make sure you use a recent 16.04 image
<zyga> jdstrand: mmm
<ogra_> phew
<zyga> jdstrand: well, I'll leave that to you :)
 * ogra_ returns from vet .... 
<ogra_> no broken bones \o/
<wesleymason> zyga: aha, good call, I had followed an out of date doc and grabbed a 15.04 image
<ysionneau> something I saw in my qemu test but didn't report, but that I also see in my real-hw rpi2 test : [FAILED] Failed to start Create Volatile Files and Directories.
 * wesleymason grabs a xenial image
<zyga> wesleymason: yeah, do use 16.04 and latest snapcraft from xenial please
<ysionneau> and also [FAILED] Failed to start Run snappy grub-migration.
<ogra_> ysionneau, yeah, thats on arm64 too
<ysionneau> ok
<qengho> jdstrand: I could neuter the internal chromium seccomp sandbox, but that doesn't seem better.
<zyga> wesleymason: you can get 16.04 image from https://github.com/zyga/devtools/blob/master/ubuntu-image
<ysionneau> I just wanted to be sure you were aware of that :)
<jdstrand> qengho: for this second, use something like http://paste.ubuntu.com/15281301/
<jdstrand> qengho: but soonish, we'll do what zyga said where you work with us on some interfaces to make that better
<qengho> jdstrand: Can I help pull Chromium's weird profile into snappy as a first-class option?
<qengho> Cool.
<zyga> jdstrand: let's closes https://code.launchpad.net/~zyga/ubuntu-core-launcher/trunk/+merge/288116
<jdstrand> yes, but I'm not sure what that option is otoh
<zyga> jdstrand: I'll make the other change
<jdstrand> in theory with seccomp you can keep going more and more restricted
<ogra_> ysionneau, well, filing a bug might still make sense
<jdstrand> but we don't allow changing the seccomp policy at all. perhaps we can have an interface that allows changing the seccomp sandbox
<jdstrand> have it be restricted to apps we trust, etc
<jdstrand> not sure. have to think about that
<jdstrand> but chromium isn't alone in this regard. I think vsftpd also would need something like this
<jdstrand> alternatively, compile chromium without either sandbox
<jdstrand> I'm not sure that is an option
<qengho> I'll check.
<jdstrand> what's somewhat weird about that is that our sandbox is actually making someone else's sandbox less secure
<jdstrand> (ie, the chromium seccomp sandbox allows less than we do, cause it is designed for minimal syscalls, whereas we have a bigger syscall interface to handle general purpose apps)
<qengho> jdstrand: Maybe the chromium seccomp profile could be a strict superset of restrictions of plain. An app perhaps can set the profile, but they are all at least as strict as the base.
<kyrofa> jdstrand, huh... yeah that is interesting
<jdstrand> qengho: that is what I was getting at with a possible interface
<kyrofa> jdstrand, if we allowed for a custom seccomp profile, could the review tools verify that the custom one is a subset of the typical?
<jdstrand> allow adjusting the sandbox to be more strict
<jdstrand> kyrofa: well, sure, but that isn't how the chromium sandbox works
<jdstrand> kyrofa: it has a hardcoded list of syscalls in its code (so would say, vsftpd)
<qengho> yaml: also-restrict: [ sigblahblah, obscureotherthing, llamas ]
<jdstrand> and it only goes into the seccomp sandbox when handling untrusted input
<kyrofa> Ah I see
<jdstrand> it's an interesting problem. I don't think it is insurmountable
<jdstrand> the problem with allowing changing the seccomp sandbox by default is that it might open up an avenue of attack of going seccomp unconfined/etc if there are kernel bugs
<jdstrand> we'll see. want to think more
<qengho> jdstrand: oh, that yaml is for snap meta/package.yaml, yes?
<jdstrand> qengho: is this for 15.04 or 16.04?
<qengho> jdstrand: 16.04
<jdstrand> meta/snap.yaml
 * zyga catches up
<jdstrand> it would work with snapcraft too, but we are reversing the order of slots and plugs
<zyga> jdstrand: check out https://github.com/ubuntu-core/snappy/pull/583
<zyga> jdstrand: this will let us have nice native interfaces
<jdstrand> so this time next week, that'll need to be s/slots/plugs/
 * jdstrand assumes the changes will land by then
<ogra_> unless someone changes his mind :P
<qengho> jdstrand: so, for a snapcraft now, is there a way to get that phrase to the meta/snap.yaml ?
 * ogra_ lost all trust in naming schemes til rellease day :P
<ogra_> skillcapfaces ....
<jdstrand> qengho: do this:
<jdstrand> snapcraft snap (without the slots stuff)
<jdstrand> then go in snap/meta/snap.yaml
<jdstrand> add the slots stuff
<qengho> Hah.
<jdstrand> then do snapcraft snap
<qengho> Thanks, jdstrand.
<jdstrand> this is only for a few days
<zyga> jdstrand: that's landed already
<zyga> jdstrand: it's merged :)
<jdstrand> zyga: snapcraft has interfaces in the new reversed order?
<zyga> jdstrand: I _think_ sergiusens did this already, I was talking about snappy here
<jdstrand> ah
<jdstrand> qengho: ok, then do s/slots/plugs/ in the yaml snippet I gave
<jdstrand> qengho: try it with snapcraft. if it barfs, use the method I suggested
 * jdstrand needs to update the review tools now
<jdstrand> zyga: regarding the pr, nice explanation
<jdstrand> is there a way in git hub to see the complete changes in a pr as opposed to individual commits?
<qengho> "barfs" would be a bad filesystem.
<ogra_> the opposite of foofs
<zyga> jdstrand: yes
<zyga> jdstrand: you can see both:
<jdstrand> qengho: hehe
<zyga> jdstrand: e.g.: https://github.com/ubuntu-core/snappy/pull/578/files
<zyga> jdstrand: vs https://github.com/ubuntu-core/snappy/pull/578/commits
<zyga> jdstrand: or just use a remote and git locally ;)
<jdstrand> I see
<jdstrand> thanks
<zyga> jdstrand: github has a nice any-to-any diff but I cannot remember how to find it
<jdstrand> zyga: what is meta/hooks/plug?
<zyga> jdstrand: just a random example
<zyga> jdstrand: was supposed to be the plug-side notification hook
<zyga> jdstrand: when you plug the plug into a slot, the plug gets to know this
<jdstrand> zyga: ok, so that is/will be a documented and supported hook for apps to use
<jdstrand> (that's fine)
<zyga> jdstrand: yeah, we'll get there, that's the only hook we plan to have for 16.04 AFAIR
<zyga> jdstrand: I'll implement it as soon as we're done with working interfaces (in general)
<zyga> jdstrand: hook should be easy, pedronis` is working on support for running hooks in the state engine
<zyga> jdstrand: so I just plan to wait for that to bake or bake it myself when other tasks run out
<jdstrand> only hook wrt interfaces or do you mean config is going away?
<zyga> jdstrand: wrt interfaces
<zyga> jdstrand: I think config will just hop on the same bandwagon (state engine)
<jdstrand> zyga: the waiting, etc is fine. mostly I just wanted to know what it was (remembering the .click/ design flaw)
<zyga> jdstrand: since many state engine bits just landed I will have 80% of interface functionality in the next day or so
<zyga> jdstrand: as I can just plug it in
<jdstrand> zyga: nice!
<zyga> jdstrand: I still want to see the ensure loop and at least one complete example but perhaps I'll just have to try it out
<zyga> jdstrand: it'd be naive but if we can have interfaces with real security support in the next image I'd be golden :)
<jdstrand> yeah, that would be really nice
 * zyga -> food
<ysionneau> one of the most annoying fact about 16.04 is that ogra_ 's nethack package is not yet ported to the squashfs type snap :') (at least on armhf userspace)
<ysionneau> no nethack :(
<ogra_> ysionneau, yeah, sorry, the plain nethack works only on arm64 and the ones with -$arch are both for 15.04
<ogra_> once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches
<netphreak> Hi, guys!
<kyrofa> netphreak, hey there
<netphreak> Been researching using Ubuntu and Snappy to deploy multiple IOT devices...
<kyrofa> Oh yeah?
<netphreak> How do i best deploy to a fleet of devices - not knowing their IP's
<ogra_> you mean an initial install ?
<netphreak> both initial and updates
<qengho> netphreak: For initial, you have to have it "in your hands", probably.
<qengho> netphreak: It's hard to know, without you saying a lot more.
<netphreak> Can one use snappy to pull a snap from a url and install?
<netphreak> I've setup a device that's running a preinstalled version of my software - currently it can download an embedded jar and update itself by being invoked from my control server.
<netphreak> would like to package a snap with a jdk and deploy this using snappy.
<ogra_> snappy has an automatic updater that pulls updates from the store automatically
<ogra_> so once you deployed the devices will update themselves automatically
<ogra_> you need to do the initial factory flash directly though as qengho said
<netphreak> Does the store support private repos?
<ogra_> it allows a sub store bound to you, yes
<ogra_> (for details talk to beuno )
<qengho> netphreak: you mean, for software that is secret to you, or do you want to preserve the namespace?
<netphreak> just software that is secret to me..
<ogra_> but note that snaps are namespaced anyway, you dont need to actually have a "private" one
<netphreak> It's very device specific
<netphreak> Any way to control when a device should pull an update?
<ogra_> (and snaps are fully binary ... you never upload your source to the store)
<ogra_> you can adjust the frequency the system checks for them
<netphreak> ok.. and any way to control which version, if multiple exist?
<ogra_> beyond that, as soon as your new snap exists in the store it will be pulled
<ogra_> by default it would always be the latest ... with the option to roll back to the last if something fails
<ogra_> not sure we have something in place to tell a device to hold back a version
<ogra_> (i doubt it)
<netphreak> ok..
<netphreak> currently my admin part keeps a profile of each device - detailing location and which version..
<ogra_> are the devices identical ?
<netphreak> would like to only provision updates to eg. device located in a specific city at a time.
<netphreak> yes, hardware wise they are..
<ogra_> well, you could indeed produce different images and different snaps
<ogra_> i.e. the devices in city foople all install use the foople.netphreak image that has  bar-foople.netphreak preinstalled
<ogra_> one image per city ...
<ogra_> one package per city
<ogra_> that way you would be able to control them via the store
<netphreak> problem is these devices will be installed in over 200 cities..
<netphreak> Company expects to be able to sell atlas 10000  year.
<netphreak> atleast
<ogra_> well, thats quite a headdache in all cases :)
<ogra_> the image you woul ddeploy would be identical apart from the snap name ... and you would have to maintain 200 snaps in your store ...
<ogra_> potentially many of them being the same one just with a different name
<netphreak> yes.. -> pretty inconvenient
<ogra_> well, not more or less inconvenient than having to push them to the devices and maitain tables with lists of versions
<ogra_> i really think the store people could help you here ... but beuno seems to be off atm
<netphreak> all devices when booted sends their profile info to the admin server - where i can do version/location filtering etc.
<netphreak> and send configuration changes to a group of devices or one specific.
<ogra_> hmm, and they cant send their IP ?
<netphreak> most of them will be behind a firewall.
<ogra_> ah
<ogra_> well, so the polling model is surely the better one
<ogra_> and if you can send config changes you also can send commands i guess
<ogra_> and trigger the poll ...
<netphreak> exactly.
<qengho> netphreak: I think you should keep one grand package and differentiate based on the package config. That is, part of a device deciding which part of the single grand package to use depends on the setting you seeded the device with.
<netphreak> hmm...
<netphreak> so you're telling me it's possible from my device application to instruct snappy to start pulling a snap?
<ogra_> definitely
<ogra_> snappy has a REST api that you should be able to use to manage snaps
<netphreak> now we're talking ;)
<netphreak> would it require to install the webdm part?
<ogra_> i think the API itself is independent ...
<ogra_> Chipaca would know
<ogra_> afaik webdm just starts using it actually
<netphreak> ok..
<netphreak> how is it exposed on the device?
<ogra_> throoug a socket afaik (i never used it)
<ogra_> *through
<zyga> re
<ogra_> zyga, !
<ogra_> you know about the REST api, right ?
<zyga> ogra_: yep
<zyga> ogra_: how can I help you?
<ogra_> netphreak, zyga is your man then :)
<zyga> netphreak: tell me
<netphreak> i suppose this rest api is not exposed externally on the device?
<zyga> netphreak: it's currently exposed over a unix socket
<zyga> netphreak: but AFAIR the plain is to expose it over tcp/ip as well
<zyga> netphreak: right no we just rely on local peer credentials for authentication
<zyga> netphreak: you can develop an app that talks to current snappy REST api and work with us to expose it on the network
<zyga> netphreak: what specifically do you need?
<netphreak> Currently my admin server can communicate securely with the device - receive device profile (application version, location etc).
<netphreak> And can instruct it to download an update from say AWS S3 repo - as a jar..
<netphreak> What i was after was the transactional updates and security of Snaps..
<netphreak> So actually my java app on the device could call either the rest api or a snappy command directly
<zyga> netphreak: snappy maanges device updates, what you are describing actually happens on the server side
<zyga> netphreak: so I believe it is possible as a service you get from canonical
<zyga> netphreak: on a given snappy device you can switch between channels like "beta" or "stable"
<netphreak> yes.. but i need to control which devices (according to location) are updated when.
<netphreak> my admin server handles all received profiles, and can manage and filter (by location and version etc.) which devices to update
<zyga> netphreak: I believe this is supported but you'd have to get in touch with someone from product management to discuss details
<zyga> netphreak: you can control a device but it's not exactly what you think or are describing
<zyga> netphreak: as in, control which versions go where
<zyga> netphreak: but that's all server side
<zyga> netphreak: I'd suggest you to watch development towards 16.04 and get in touch with canonical sales to get a dedicated contact and understand better how server-side management works
<qengho> netphreak: You want to defer updates of snap packages based on criteria the device knows about.
<qengho> That was a question.
<netphreak> The control part is already handled by our middleware software - i just need to tell Snappy on one or more devices to go pull an update with version x.y.z
<netphreak> Eg middleware platform tells device x - go fetch update snap xyz version x.y.z
<zyga> netphreak: snappy has specific design on how updates work, who has control over what (os vendor, appX vendor, appY vendor, brand of the device, user)
<zyga> netphreak: what we designed may not be what you immediately think about but it's a very powerful system
<netphreak> hmm..
<zyga> netphreak: I know we're really moving rapidly and not everything is available or documented but as we progress towards 16.04 it will become clear how you can fit your idea into that model
<zyga> netphreak: e.g. if I install your app, can I still override your decision
<netphreak> Well. no need for that part - as the software is for a very specific IOT device..
<zyga> netphreak: right, what I'm saying that we designed something that can handle various cases, not just the one you described
<netphreak> Sounds interesting..
<zyga> netphreak: but perhaps the manner in which that is acheived is not the same as what you described
<netphreak> what's the timeframe for 16.04?
<ogra_> 04 2016 ;)
<zyga> netphreak: so for now I can only suggest to contact canonical professionally and discuss this more and also to wait towards 16.04 as we publish more documentation and design docs
<zyga> netphreak: 16.04 :D
<ogra_> (april )
<zyga> netphreak: it's nice to have nice date-based releases
<netphreak> hehe..
<netphreak> I'll get a hold of canonical and get some more info :)
<netphreak> And see if it'll fit our schedule..
<netphreak> are there any previews available to get a feeling of how it it would work?
<zyga> netphreak: it's an exciting and very busy period, I'd suggest to explore aligning on 16.04 and working towards using ubuntu as the core of your product
<zyga> netphreak: it's all in the open
<zyga> netphreak: you can get "edge" images from https://github.com/zyga/devtools/blob/master/ubuntu-image easily (or get pre-built images from links mvo and others send to the snappy-devel mailing list)
<zyga> netphreak: you can check snappy activity on github.com/ubuntu-core/snappy
<zyga> netphreak: and we're all here so it's all in the open
<ogra_> yeah
<netphreak> ok.. will have a look..
<ogra_> netphreak, what CPU arch are your devices ?
<netphreak> arm
<zyga> netphreak: armv7+ or earlier?
<ogra_> v7 ?
<netphreak> v7
<ogra_> cool
<netphreak> maybe a Cortex A53 - if needed
<ogra_> yeah, that should both be fine
<netphreak> Thanks for your time, guys! :)
<ogra_> np, if you have more questions, just come around
<ogra_> :)
<netphreak> will do :)
<jdstrand> pindonga: hey, fyi, I just committed change to the review tools for the plugs/slots reversal. this doesn't need to be pulled immediately, but I wanted to alert you to it
<jdstrand> pindonga: next week I imagine I am going to ask for another pull request for old-security/caps to native interfaces change that zyga is working on
<pindonga> jdstrand, sure
<pindonga> let me know and I'll do the pull next week
<jdstrand> ok
<zyga> jdstrand: ok, 4-way security snippet support has landed
<zyga> jdstrand: is there something I could try to convert over as the first thing?
<jdstrand> zyga: yes, let me push something
<jdstrand> zyga: https://code.launchpad.net/~jdstrand/+junk/snappy-interfaces-security
<jdstrand> zyga: look in snap.unpacked
<jdstrand> since snapcraft doesn't do interfaces yet, I unpacked a snap that used 'uses', then converted the snap.yaml and moved some things around
<jdstrand> zyga: it is not tested to work, but it should give you the idea
<zyga> jdstrand: looking
<zyga> jdstrand: thanks
<zyga> jdstrand: https://trello.com/c/qm0XzFfl/44-switch-udev-security-to-app-level-granularity FYI
<zyga> hmm
<zyga> jdstrand: I was under the impression that 'network' and 'network-bind' would just become real top-level interfaces, not under old-security
<jdstrand> zyga: yes
<zyga> jdstrand: ok
<jdstrand> zyga: you asked for me to give you something to convert :)
<zyga> jdstrand: yeah, like "network"
<jdstrand> convert away! :)
 * zyga reads
<jdstrand> network-client -> network
<jdstrand> network-listener -> network-bind
<zyga> jdstrand: right I know
<zyga> jdstrand: hmm, I was hoping to get the network.go at the end of this exercise
<jdstrand> these are different static perms
<zyga> jdstrand: that implements "network"
<jdstrand> sure
<zyga> jdstrand: and after the basics are set up, iterate and convert all of those over
<jdstrand> zyga: I gave you a snap that had stuff in that used old-security. what precisely do you want and I'll give it to you
<zyga> jdstrand: so to be clear, I don't want to implement old-security now
<jdstrand> no, of course not
<jdstrand> you used the word 'convert'
<zyga> jdstrand: (I can but it's more complex)
<zyga> jdstrand: ah, sorry
<jdstrand> so I gave you the old system so you could convert
<zyga> jdstrand: I'd like to see the bits that go into making "network" tick
<zyga> jdstrand: so I can quickly create NetworkInterface{} type that has the same semantics
<jdstrand> we want old-security/caps to go away
<zyga> jdstrand: we can look at how that looks next week and decide how to proceed with other interfaces
<jdstrand> zyga: tell me exactly what you want now and I will give it to you
<zyga> jdstrand: ok, one se
<zyga> sec*
<zyga> jdstrand: given those four methods: https://github.com/ubuntu-core/snappy/blob/master/interfaces/core.go#L81
<zyga> jdstrand: (consecutive)
<zyga> jdstrand: I'd like to know what security snippets to put inside for "network"
<jdstrand> oh
<jdstrand> zyga: did you look in the ppa?
<zyga> jdstrand: I suspect that it translates to a few syscalls and maybe some AA
<zyga> jdstrand: no, which ppa, sorry, maybe I missed a link
<jdstrand> I sent it via email yesterday. don't worry, let me point you at a branch
<zyga> oh, sorry, I'm not great with catching up on email; thanks
<jdstrand> zyga: http://bazaar.launchpad.net/~ubuntu-security/ubuntu-core-security/trunk/files/head:/data/
<jdstrand> zyga: drill down into {apparmor,seccomp}/policygroups/ubuntu-core/16.04/network
<zyga> jdstrand: that's exactly what I needed, thank you
<zyga> :)
<zyga> woot
<jdstrand> np, sorry for the confustion
<zyga> hehe, sorry, this was a looong day (yesterday too)
<jdstrand> zyga: if it helps you, there is an ubuntu-core-security in https://launchpad.net/~ubuntu-security-proposed/+archive/ubuntu/ppa/+packages that did all the renames from yesterday (ie, what is in that branch)
<jdstrand> but I suspect the branch is enough
<zyga> jdstrand: yeah, the branch is enough
<zyga> jdstrand: and as a sanity check, the "network" interface will have a slot on the ubuntu-core os snap and all the snaps that want to talk to it will have a plug on their side
<jdstrand> zyga: correct
<zyga> great
<zyga> one moment :)
<kyrofa> jdstrand, are the read/write paths new to 16.04? Or did they exist in 15.04 as well?
<kyrofa> Looks like the docs have been replaced on developer.ubuntu.com, now I can't remember :P
<zyga> (almost done, writing tests)
<jdstrand> kyrofa: security-override/read-paths and write-paths were technically available in 15.04, but in a really hard to use way that is not at all like the 16.04 yaml
<kyrofa> jdstrand, I don't suppose you know of any examples?
<jdstrand> kyrofa: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/15.04
<kyrofa> jdstrand, ah ha!
<kyrofa> jdstrand, is the policy_group in the override of that example redundant due to the cap of the service?
<jdstrand> yes
<kyrofa> Or do they need to match up?
<kyrofa> Okay
<jdstrand> oh wait
<jdstrand> I thought you were asking a different question
<jdstrand> kyrofa: security-override can only be used by itself on 15.04
<kyrofa> Oh wow, I totally missed that there were two services
<kyrofa> Ahem
<jdstrand> kyrofa: so, any 'caps' you had in your yaml, but in the policy_groups of the json
<jdstrand> then remove the caps from the yaml
<kyrofa> Gotcha, okay. Yeah, I like 16.04 better, too ;)
<jdstrand> yes
<kyrofa> Thanks for the pointer!
<jdstrand> np
<jdstrand> historically, this is because of the click compat stuff and it not getting all moved by 15.04
<jdstrand> I did say it was horrible to use :)
<kyrofa> Yeah that makes total sense
<zyga> jdstrand: ok
<zyga> jdstrand: ready?
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/587
<zyga> jdstrand: note that this is the no-shortcuts taken version
<zyga> jdstrand: with 2nd one I'll itroduce a simple "base class" like support so all the grotty details will go away
<zyga> jdstrand: and 99% of the code will be copy-paste from your bzr branch
<kyrofa> jdstrand, FYI typo on that page, overrides has no s
<zyga> ogra_: ^^ it's happening
<zyga> jdstrand: tell me what you think
<zyga> jdstrand: I have to leave in 7 minutes
<jdstrand> zyga: 7 minutes is not a lot of time. I looked at it and see how it works
<jdstrand> zyga: I look forward to the 99% case next week :)
<zyga> jdstrand: cool
<zyga> jdstrand: I'm getting off then
<zyga> jdstrand: have a nice weekend
<zyga> jdstrand: I'll simplify this and send a dozen pull requests your way
<jdstrand> zyga: you too! thanks! :)
<wililupy> question: Has anyone seen the error: ubuntu-core-launcher unalbe to make /tmp/ private. errmsg: Invalid argument?
<wililupy> my snaps that are system services are failing to start and going into a failed state.
<ysionneau> 18:49 < ogra_> once the security du jour changes are done (interfaces etc) i'll push all my snaps to the store for all arches < ahah I know what you mean =
<ysionneau> =)
#snappy 2016-03-05
<orby> what is the correct way to configure the ip address of a snappy ubuntu-core?
<orby> in the same vein is there any special procedure for replacing the ubuntu account with a different admin user? or is it the same process as normal ubuntu?
<orby> not really sure how configs live on with the imaging system
<sergiusens> asac`, ogra_, hey, so the kernel plugin now seems to work; I am just getting "Cannot load shared library libudev.so.1" on boot; I know you were looking into that and I'm working from a cached version, so is it working now?
<ogra_> sergiusens, yeah, i'm working on that
<sergiusens> getting end to end working would be awesome :-)
<sergiusens> ogra_, kudos to you for being great :-)
<ogra_> there are bugs in fakechroot that i'm currently trying to hack around
<sergiusens> the pieces are comming together
<sergiusens> ogra_, this affects all arches, right? I'm trying on amd64 due to convenience
<ogra_> yeah, it does
<sergiusens> I guess I won't be able to try out the procedure on  a dragonboard until I get to linaro connect
<ogra_> on arm64 the linker wasnt copied in at all, sorry, i did care for that first yesterday, should have done it the other way round :)
<sergiusens> heh, no worries you never know what will break next until it breaks
<sergiusens> and getting things out of the way is a good thing ;-)
<sergiusens> ogra_, do you know out of hand if to get a nice kernel build from git://kernel.ubuntu.com/ubuntu/ubuntu-xenial.git I can go with kdefconfig on its own?
<sergiusens> I'm afraid debian/rules does a lot of massaging in between, but maybe just to get a deb
<ogra_> i dont thijk you can ... the config usually lives in the debian ir debian.$arch dir in ubuntu
<ogra_> s/ir/or/
 * sergiusens tries
<ogra_> assembled by scripts (ande checked for required parameters) during build
<sergiusens> ogra_, heh, the assembled by scripts means it is not there initially in a clone/checkout though :-)
<ogra_> it is there, but in parts
<ogra_> sergiusens, i though asac had asked the kernel team for their check scripts and included them in the kernel plugin
<ogra_> after all we need to make sure that the required options are all set (systemd reqs., cgroups, squashfs etc etc)
<sergiusens> ogra_, you mean this http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian/scripts/config-check ?
<ogra_> sergiusens, yeah, there is another one though
<sergiusens> ogra_, well we don't have that yet, but nothing says we can't force enable some features (to make it transparent)
<ogra_> ah, mightr just be an input file
<sergiusens> http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian/scripts/misc/kernelconfig
<ogra_> debian.$arch/config/annotations has the required options
<ogra_> not sure which script exactly consumes it though
<sergiusens> ogra_, that's a generated file though, not here http://kernel.ubuntu.com/git/ubuntu/ubuntu-xenial.git/tree/debian
<ogra_> (these scriptrs are a maze of perl code )
<sergiusens> yup
<ogra_> sergiusens, ok, 0.7.32 should ship with libudev now
<ogra_> oh, but i havent disabled the resize script yet, that might cause havoc on second boot
<ogra_> (on the dragonboard only)
<sergiusens> ogra_, heh; so I just need to create an os image now; I hope my bandwidth is good enough
<sergiusens> ogra_, can you remind me mvo's branch for creating those?
<ogra_> sergiusens, http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
<ogra_> sergiusens, but that means you need a fresh tarball too
<ogra_> (which will take some time, the package is still in -proposed
<ogra_> )
<ogra_> i'll trigger a tarball build once it migrated
<ogra_> heh, and having said that, it just did
<sergiusens> ogra_, oh, ok; I'll wait for the rootfs build
<ogra_> triggered
 * sergiusens is still cloning from kernel.ubuntu.com
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/
<ogra_> (if you want to watch it)
<sergiusens> ogra_, what else can I do :-P
<sergiusens> ogra_, Receiving objects: 100% (4489986/4489986), 999.75 MiB | 119.00 KiB/s, done.
<ogra_> all done
<sergiusens> ubuntu kernel
<sergiusens> wow
<sergiusens> a shallow clone
<ogra_> heh
<sergiusens> ogra_, builders during the weekend are a joy!
<ogra_> yeah :)
<ogra_> so now i need to fix the resize script ... and i think we should have a script included in the initrd package that makes injecting modules and firmware an easy task
<ogra_> (doing all the nasty depmod stuff for you etc)
<longsleep> ogra_: _that_ would be awesome :)
<sergiusens> ogra_, by mounting /lib/modules?
<sergiusens> ogra_, oh, now I see
<ogra_> sergiusens, just something like "inject-modules.sh /path/to/initrd.img /path/to/modules/dir"
<ogra_> it would unpack, push the needed modules in, run depmod and re-pack
<ogra_> since thats quite fiddly
<sergiusens> ogra_, to replace https://github.com/sergiusens/snapcraft/blob/feature/1552168/kernel-plugin/snapcraft/plugins/kernel.py#L154
 * ogra_ looks
<sergiusens> ogra_, yeah, basically what is done there, maybe cleaner
<ogra_> sergiusens, i see it uses modules.dep ... where would that come from ?
<sergiusens> ogra_, so infinity talked about writing a "copy_module" thingie which would take care of copying the correct firmware
<ogra_> (our kernel packages only run depmod from the postinst)
<sergiusens> ogra_, the kernel build
<ogra_> ah, i see. it is a source build
<sergiusens> yeah, this is all source
<sergiusens> using the upstream ubuntu kernel deb comes later
<ogra_> well, that is the bit i need on the builders
<ogra_> where we use packaged kernels
<ogra_> hmm, do i see that right that you actually include *all* modules ?
<ogra_> that will give you quite a bloated initrd in the end ...
<sergiusens> ogra_, no just the modules listed
<ogra_> after all you only want squashfs and vfat/nls as mandatory modules
<sergiusens> ogra_, it only does a --show-depends for self.options.kernel_initrd_mods
<sergiusens> which is in snapcraft.yaml
<ogra_> ah, k
<sergiusens> and I guess we can add mandatory modules here as an improvement; unless `show-depends` returns `builtin`
<ogra_> yeah
<ogra_> (i still think we shold just enforce squashfs to be builtin on all non distro kernels though)
<ogra_> that way you wouldnt even need to re-pack the initrd at all :)
<sergiusens> ogra_, heh, I'd say the same for fat
<sergiusens> why create a module for something will always load
<sergiusens> *that will
<longsleep> sometimes it might not even be possible to build a kernel - but in my configs i include all the modules required for snappy directly in vmlinux - so should be good
<ogra_> vfat is builtin in your distro kernel
<ogra_> but the nls modules arent
<longsleep> ah
<ogra_> s/your/our/
<longsleep> i am currently working on the Pine64 kernel config, i got nls,vfat and squashfs
<ogra_> yeah, thats good
<sergiusens> don't forget apparmor
<ogra_> right, and the right cgroups options
<longsleep> yeah - i did not backport that yet .. its crappy Kernel 3.10 again :)
<ogra_> fun
<longsleep> if you are interested - https://github.com/longsleep/linux-pine64/blob/pine64-hacks-1.2/arch/arm64/configs/sun50iw1p1smp_linux_defconfig
<longsleep> no snappy yet, but i got a fully functional xenial image
<ogra_> would be interesting to see if it works with the new snapcraft plugin;)
<longsleep> will try it soon - an probably for odroid c2 as well if not somebody else will have done it when i find the time
<longsleep> (c2 has Kernel 3.14 which is not much better ..)
<sergiusens> ogra_, longsleep I am still missing dtb integration
<sergiusens> going to work on that during my 12 flight that's just around the corner
<ogra_> where are you atm ?
<sergiusens> I hope I have everything ready to work offline though :-)
<sergiusens> ogra_, Chile
<ogra_> oh, not changed the continent yet
<sergiusens> ogra_, bad connections, 12 hour layover here as well
<ogra_> woah
<sergiusens> ogra_, the flght leaving last night was fully booked
<longsleep> sergiusens: dtb just needs to be copied to /boot or /media/boot for pine64,c1 and c2
<sergiusens> so total travel time is 43 hours
<longsleep> oh my
<ogra_> woah
<sergiusens> return is only 246 :-)
<sergiusens> woops
<sergiusens> 26
<sergiusens> ogra_, it's fine, they have beds here; I
<ogra_> heh
<longsleep> i hope you can bring a battery to the cabin - last time they took mine away before boarding "too high capacity" ..
<sergiusens> I'm only worried that I will arrive Monday 00:30 so no time to adapt to a new timezone and only 6 hours or less of sleep to get ready for a packed Monday
<sergiusens> longsleep, I got upgraded to business ;-)
<sergiusens> most planes here have plugs for long haul flights in economy though
<longsleep> right if they work :)
<sergiusens> heh, you have to checkout the awesome planes we have here :-)
<sergiusens> in any case it is 12 hours to Sidney then 8 more to Bangkok
<longsleep> well in business that should be ok :)
<longsleep> did you get upgraded for both flights?
<sergiusens> the first 12 are business
<sergiusens> the remaining 8 are something else
<longsleep> so when you land snapcraft has learned to build a perfectly fine device snap (or whatever it is called)?
<sergiusens> kernel snap
<sergiusens> longsleep, it already seems to be building correctly for amd64 except for that initrd thing ogra just uploaded
<longsleep> sergiusens: thats good, i will finish up to build a classix xenial image for Pine64 this weekend amd then go snappy next week - i guess that will help a lot
<sergiusens> nothing glamorous about this, but what the heck http://paste.ubuntu.com/15291572/
<longsleep> what about building stuff for u-boots which do not support initrd.img or vmlinuz?
<ogra_> not supported anymore
<longsleep> i did not look into arm64 booting on snappy yet, but at least the kernel cannot be named vmlinuz can it?
<ogra_> people need to use the u-boot patches for raw files and need to use the patches for the .env file
<ogra_> we use the same patches on the dragonboard ... kernel is vmlinuz, initrd is initrd.img
<longsleep> ok i see - i have some research to do then
<longsleep> how do you build vmlinuz for arm64? Or is it just Image gzip compressed there?
<ogra_> its like five lines in the build config to change usually
<ogra_> mak zImage
<ogra_> ?
<ogra_> *make
<longsleep> i was under the impression that is not supported on arm64 - probably got that wrong
<ogra_> works fine on the dragonboard ...
<ogra_> but i guess it is a matter of the u-boot implementation
<ogra_> (and on what u-boot release you base initially)
<longsleep> that too, but i thought that there is no self extractor code in the kernel on arm64
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/dragonboard/view/head:/uboot.patch
<longsleep> but i can already tell that it will be some work to get devices boot vmlinuz and initrd instead of uImage and uInitrd
<longsleep> what is the u-boot command you boot with on dragonboard?
<longsleep> bootz?
<ogra_> booti i think
<longsleep> ok thats good, but what i do not get is how booti works with vmlinuz but thats probably something i missed
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/dragonboard/uboot.env.in
<ogra_> thats our current dragonboard env
<ogra_> booti ${linux_addr} ${ramdisk_addr}:${initrd_size} ${fdt_addr}
<longsleep> thanks, looks good and pretty compatible to mainline u-boot
<longsleep> though, i am far away from mainline on the pine64 at the moment :/
<ogra_> yeah, thanks to the 96boards guys ...
<ogra_> i think their stuff is already flowing upstream even
<longsleep> right now, i need to use boota on pine64 and thus also do not have a vmlinuz nor a initrd.im, its all inside a android wrapped kernel.img
<ogra_> oh ?
<longsleep> i want to backport booti to the old u-boot eventually, might even be a requirement to get snappy running
<ogra_> why dont you make u-boot that kernel.img then ?
<ogra_> and just use the u-boot features
<ogra_> thats what i do on the dragonboard
<longsleep> sure, but regarding snapcraft support that will not work right
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/dragonboard/files
<ogra_> thats my basic boot setup (independent from snappy)
<ogra_> (see the README for details)
<longsleep> yes, i got a similar thing https://github.com/longsleep/build-pine64-image/tree/master/u-boot-postprocess
<ogra_> the dragonboard also only supports android style booting by default
<ogra_> lk -> kernel.img usually
<ogra_> i just trun it into lk -> u-boot.img
<longsleep> ok, but their u-boot supports booti already
<ogra_> by pretending the u-boot.img is a kernel one
<ogra_> yeah, indeed
<ogra_> and you have neither booti nor bootz ?
<longsleep> well bootz will not work with the Kernel i have as it does not have an extractor for gz, i have only the uncompressed image and put that into the android format
<longsleep> it has bootz, but the bootz code does not have the hack to switch to 64-bit mode
<ogra_> isnt that just a kconfig thing ?
<longsleep> yes and no, there is just no aarch64 code for it in the kernel
<ogra_> bah
<longsleep> ogra_: thats the u-boot config i currently use btw https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/include/configs/sun50iw1p1.h
<longsleep> everything should work out somehow, i was planning to backport booti from mainline u-boot including the world hack anyways to get rid of the android boot stuff
<ogra_> sounds good
<longsleep> longsleep@mose2:/media/longsleep/Storage/Pine64/build-pine64-image/linux-pine64$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION=-longsleep -j4 zImage
<longsleep> make: *** No rule to make target 'zImage'.  Stop.
<longsleep> :)
<ogra_> oh my
<longsleep> i did not even know that mainline Kernels now have a self extractor for aarch64
<longsleep> because i did not look that is :)
<longsleep> so for now, i would prefer if snappy/snapcraft would not be fixated to require vmlinuz or initrd.img or be fixed to those file names
<longsleep> could make it much easier for platform adopters
<ogra_> well, as long as you support uboot.env you should still be free to do what you want after all
<longsleep> yeah, thats good then
<ogra_> uboot.env is definitely essential though since snappy modifies it
<longsleep> i alread added all the stuff for the env file including the redundant thing we figured out ages ago. I hope it did not change :)
<ogra_> from userspace
<ogra_> see the dragonboard patch ;)
<ogra_> didnt change
<ogra_> (and the option still has the typo upstream ;) )
<longsleep> hehe ok great - then i think all is well
<longsleep> ogra_: btw, do you know the reason why in Xenial the serial getty service starts after rc-local service? Seems wrong and is annoying.
<longsleep> /lib/systemd/system/serial-getty@.service has After=rc-local.service
<ogra_> nope, no idea
<ogra_> but thats a getty ... you actually want all boot scripts to have run before you allow logins
<ogra_> it's a bit weird to tie it to that specific service though
 * ogra_ goes afk a bit 
<sergiusens> ubottu, am I here?
<ubottu> sergiusens: I am only a bot, please don't think I'm intelligent :)
<sergiusens> ogra_, asac` http://paste.ubuntu.com/15293021/
<sergiusens> it is alive!
 * sergiusens prepares for boarding
<zyga> sergiusens: congrats
<zyga> sergiusens: have a safe trip
<sergiusens> zyga, thanks, I just need it working on a dragon board now
#snappy 2017-02-27
<zyga> o/
<mup> PR snapcraft#1123 closed: Adding Fish shell source and IDEA IDE to gitignore <Created by joedborg> <Closed by joedborg> <https://github.com/snapcore/snapcraft/pull/1123>
<cappe> It doesnt work very good, restartunit error, socket error and so on. Im on the latest ubuntu
<cappe> i was here some weeks ago trying to solve the bug(?)
<cappe> (at least report it)
<morphis_> ogra_: ping
<ogra_> morphis_, yo
<morphis_> ogra_: didn't you enabled ALSA support for the pi sometime ago with a change in the config.txt?
<ogra_> morphis_, well, audio device support, but yes ... all edge builds should have it
<morphis_> ah only in edge
<ogra_> well
<ogra_> we cant update gadgets in stable ... so you wouldnt get it
<morphis_> why that?
<ogra_> because nothing in /boot gets updated on gadget upgrade
<morphis_> ah right
<ogra_> only snap.yaml (and i think gasget.yaml)
<morphis_> that problem ..
<morphis_> :-)
<ogra_> morphis_, mvo was working on a config.txt inrterface, that might help around this
<morphis_> I remember
<morphis_> yeah saw those PRs but AFAIK it hasn't landed yet
<ogra_> but i guess as long as the core-support interface is completely disable that wont work
<morphis_> yeah
<ogra_> even if it would land ... the base interface needs to come back first
<morphis_> ogra_: ok, another thing with the latest gadget from edge for the pi3 I should be able to get Mir working, right?
<ogra_> morphis_, i have mir kiosk running here, so yes
<morphis_> great
<mup> PR snapd#2940 opened: interfaces: use kmod and seccomp specs <Created by stolowski> <https://github.com/snapcore/snapd/pull/2940>
<mup> PR snapd#2941 opened: Connectivity status interface <Created by xavi-garcia-mena> <https://github.com/snapcore/snapd/pull/2941>
<Elleo> I seem to have got into a strange state where snapd refuses to acknowledge that an interface I'm working on exists; I've tried reverting to a known good commit but when installing snaps it still claims it's an unknown interface
<Elleo> is there some sort of interface registry or anything that could have got into a bad state?
<ogra_> Elleo, well, snapd re-execs to the snapd inside the core snap ...
<ogra_> i belive your interface would have to exist inside there ... ( zyga ? )
<Elleo> ogra_: is that a new change? this was working a couple of weeks ago
<ogra_> not *that* new ... but also not really old ... i have to defer to zyga perhaps i'm wrong
<zyga> Elleo: hey
<zyga> Elleo: first of all, set SNAP_REEXEC=0
<zyga> Elleo: otherwise your snapd will reexec and you won't see what you are hacking on
<zyga> Elleo: second of all, is the interface supposed to be on the core snap or on a different snap?
 * Chipaca waves at vds 
 * vds waves back to Chipaca :)
<Elleo> zyga: for different snaps, it's the maliit interface
<Elleo> zyga: setting SNAP_REEXEC=0 fixes my problem, thanks :)
<mup> PR snapd#2942 opened: tests: add core-snap-refresh test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2942>
<zyga> Elleo: great :-)
<didrocks> ogra_: hey! I thought the postgresql snap was using aliases (I need one example from tutorial), ideally doing aliases and config script. Do you have any idea handy?
<ogra_> uhm ... i have neither ever used aliases nor ever used the postgres snap
<didrocks> ogra_: ok, I'll create an example for it I guess :)
<ogra_> didrocks, i know that samuele is our alias specialist though ... but he seems to be not on IRC
<didrocks> ogra_: ah, I can wait for him to see if there is already an interesting example in the store
<pedronis> didrocks: how aliases work will change again, there was some confiusion around the decision of the first implementation ... and we were asked to tweak how they works. the end result is that there will be nothing to do in the snap, it's something that developer will have to ask reviewers to setup
<pedronis> anyway this will change in 2.24 (current estimate)
<didrocks> pedronis: ok, thanks for the head's up. I'm only doing the consumer-side for now (snap user), so I guess that part won't change?
<pedronis> *confusion around the decisions
<ogra_> oops, seems i'm blind !
<didrocks> ogra_: you're not *that* old :)
<ogra_> (why did pe<tab> not properly expand ?)
<pedronis> didrocks: it will change as well (users will be able to setup snaps but given that the snap itself will have no opinions they have to specify everything, unless has I said the snap has aliases setup in the store, then there is nothing to do, it's all automatic)
<ogra_> didrocks, no, i just smell like it :P
<pedronis> s/to setup snaps/to setup aliases/
<didrocks> pedronis: oh interesting, ok, waiting for the change thenâ¦
<pedronis> didrocks: so if something merits automatic aliases, it can be setup with the old way, and we will migrate it, but indeed IÂ would not recommend asking users to play with them atm
<didrocks> pedronis: ok, I'm just skipping that part of the tutorial for now
<didrocks> (well, skipping writing it)
<ogra_> or make it a one word tutorial "guess"
<ogra_> ;)
<didrocks> :)
<Chipaca> ogra_â your tab completion probably doesn't expand on first tab if more than n options are available?
<ogra_> well, i tabbed a few times
<Chipaca> speaking of which, tab completion is a mystery wrapped in a conundrum, but the mystery is putrid and the conundrum is covered in hives
<ogra_> hahaha
<Chipaca> mup, poke bdmurray
<mup> Chipaca: Plugin "ldap" is not enabled here.
<Chipaca> ah
<Chipaca> 6am still
<Chipaca> anyway i'll take a break from this
<ogra_> seems to be always 6am there
<Chipaca> ogra_â i always get impatient about the same time i guess :-D
<ogra_> or pacific time is actually on a fixed hour permanently :)
<elopio> ppisati: I am back, and I am the test guy. How can I help you?
<ppisati> elopio: https://github.com/snapcore/snapcraft/pull/1149
<mup> PR snapcraft#1149: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1149>
<ppisati> elopio: let's start with this one
<elopio> ppisati: ok. That one timed out downloading a snap. There's an open bug for the store related to that. I've just retried it.
<elopio> ppisati: you have to add unit tests to cover the code paths you added.
<ppisati> elopio: so, is that being retried now or not?
<ppisati> elopio: and, how about these other two:
<ppisati> https://github.com/snapcore/snapcraft/pull/1150
<mup> PR snapcraft#1150: kernel plugin: remove MAKEFLAGS from the environment <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1150>
<ppisati> https://github.com/snapcore/snapcraft/pull/1148
<mup> PR snapcraft#1148: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1148>
<mup> PR snapd#2943 opened: many: only tweak core config if hook exists <Created by zyga> <https://github.com/snapcore/snapd/pull/2943>
<elopio> ppisati: those two are green. I will trigger the autopkgtests there in a moment.
<ppisati> elopio: while the other is still red for the open bug, right?
<elopio> ppisati: the other should pass with a retry. You can add the tests, don't worry about that failure
<kyrofa> Hey ogra_, do you have any recommendations for workaround for bug #1667865
<mup> Bug #1667865: Unable to sideload large snap on DragonBoard <Snappy:New> <https://launchpad.net/bugs/1667865>
<kyrofa> fstab has a big "do not edit" banner on it
<ogra_> kyrofa, unmount /tmp
<ogra_> (and reboot after installing the snap)
<kyrofa> ogra_, that makes /tmp read-only
<ogra_> huh ? shouldnt
<kyrofa> error: cannot read POST form: open /tmp/multipart-072813492: read-only file system
<ogra_> yeah
<ogra_> hmm
<ogra_> mount it to some place in /writable then
<kyrofa> ogra_, there we go...
<kyrofa> ogra_, what would you say is the ideal fix for that bug?
<ogra_> well, snapd was supposed to have a fix ... by not using /tmp to unpack
<kyrofa> Okay, agreed
<ogra_> but i'm not sure if that has landed anywhere ...
<mup> PR snapcraft#1162 opened: tests: pass the autopkgtest secret to the container <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1162>
<kyrofa> ogra_, let's say that work hadn't happened. Where is the ideal location to do this work?
<ogra_> kyrofa, snapd i suppose
<kyrofa> ogra_, I was thinking /var/tmp, thoughts?
<kyrofa> ogra_, I mean on the filesystem
<ogra_> oh, you mean the unpacking
<ogra_> yeah, /var/tmp seems to be on disk by default alread
<ogra_> y
<kyrofa> Yeah I realize now I used "work" twice in the same sentence to refer to two different things :P
<mup> Bug #1668349 opened: Classic snap fails to run  <Snappy:New> <https://launchpad.net/bugs/1668349>
<mup> PR snapd#2944 opened: interfaces/builtin/alsa: add read access to alsa state dir <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2944>
<mup> PR snapcraft#1162 closed: tests: pass the autopkgtest secret to the container <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1162>
<mup> PR snapd#2943 closed: many: only tweak core config if hook exists <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2943>
<lazyPower> kyrofa: hey there, i think you pinged me on friday re: my mail about etcd snap channel unable to find a revision
<kyrofa> lazyPower, hmm... that was a long time ago. My memory isn't what it used to be ;)
<mup> PR snapd#2945 opened: interfaces: miscellaneous policy updates for unity7, udisks2 and browser-support (LP: #1667480) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2945>
<lazyPower> kyrofa: thats true, but i'm  not positive that was you either :)
<mup> PR snapd#2946 opened: interfaces: consistently use 'const' instead of 'var' for security policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2946>
<zyga> jdstrand: hey, could you please have a look at https://github.com/snapcore/snapd/pull/2947/files
<mup> PR snapd#2947: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <https://github.com/snapcore/snapd/pull/2947>
<mup> PR snapd#2947 opened: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <https://github.com/snapcore/snapd/pull/2947>
<mup> PR snapcraft#1163 opened: docs: update the directory where the API pages are generated <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1163>
<jdstrand> zyga: I thought you were off this week?
<zyga> jdstrand: starting tomorrow :)
<zyga> jdstrand: one more 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'd love to land that one
<zyga> jdstrand: I did what you asked me to do, made a 2nd build of snap-confine
<zyga> jdstrand: I have enough patches piledl locally to send one each day during all my holidays :)
<zyga> jdstrand: the one about /etc/os-release is more important as people are hit hard by this issue (canonical-livepatch)
<zyga> jdstrand: the scond one is just a +1 as I basically did what you asked all along
<zyga> second*
 * zyga wonders how a BT keyboard can be so terrible at multi-keypress
<zyga> jdstrand: this one is really interesting: it begins the meaty part of snap-update-ns: https://github.com/snapcore/snapd/pull/2938
<mup> PR snapd#2938: cmd/snap-update-ns: compute next action to transition mount profile <Created by zyga> <https://github.com/snapcore/snapd/pull/2938>
<zyga> jdstrand: I'll merge master into it / rebase on master when I land https://github.com/snapcore/snapd/pull/2936
<mup> PR snapd#2936: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <https://github.com/snapcore/snapd/pull/2936>
<jdstrand> 2827 is already on my list
<zyga> thank you!
<zyga> I will be partially offline but I'll try to see what's going on next week
<zyga> er
<zyga> this week
<zyga> tomorrow I just need to pack a few bits and not miss my plane :")
<Pharaoh_Atem> hmm
<zyga> Pharaoh_Atem: hey
<Pharaoh_Atem> it seems stupid that you don't identify in /etc/os-release that ubuntu-core is like ubuntu
<zyga> Pharaoh_Atem: well
<zyga> Pharaoh_Atem: it's not
<Pharaoh_Atem> but it is
<zyga> Pharaoh_Atem: it is in some ways
<Pharaoh_Atem> or add UBUNTUCORE_* IDs
<zyga> Pharaoh_Atem: but it is so much read only that I think it is good to not identify like any other distro
<zyga> (via ID_LIKE)
<zyga> Pharaoh_Atem: though propose it, maybe ogra will agree and it gets merged
<zyga> ogra_: ^ ID_LIKE=ubuntu for core
<Pharaoh_Atem> uhh
<Pharaoh_Atem> I'd do the following
<Pharaoh_Atem> ID_LIKE=ubuntu debian
<Pharaoh_Atem> UBUNTUCORE_ORIGVERSION=16.04
<zyga> is is space-separated or comma-separated?
<Pharaoh_Atem> space separated
<zyga> isn't that ID_VERSION=16 ?
<zyga> (16.04 is not a thing, core is just 16)
<Pharaoh_Atem> I know
<Pharaoh_Atem> but it's derived from 16.04
<zyga> but it is 16, distinct series
<Pharaoh_Atem> series 16 could move from derived on 16.04 to 16.10, etc.
<zyga> no, it won't ever move
<zyga> it will stay 16 forever
<nacc> i don't think that's what the series means
<zyga> we'll get 18 series but not 16.10
<nacc> yeah what zyga said :)
<zyga> Pharaoh_Atem: I think the more interesting question is this:
<Pharaoh_Atem> except that you need something to match between livepatch and local
<zyga> Pharaoh_Atem: once we have base snaps, where does /etc/os-release live? is it core or is it in the base snap?
<Pharaoh_Atem> since you guys did the thing where you hardcode stuff
<Pharaoh_Atem> zyga: it probably belongs in the base snap
<Pharaoh_Atem> ideally, the core snap should only include snapd
<zyga> Pharaoh_Atem: livepatch was hit by our bug where it could no longer realize where it is running on
<zyga> Pharaoh_Atem: I think that bug is fixed with my PR (although devil in the details)
<Pharaoh_Atem> the answer is not to go back to lsb-release, though
<zyga> Pharaoh_Atem: as for core vs base I'm not sure; I think it could belong to both but it's not clear what that means
<zyga> Pharaoh_Atem: no, I'll make sure it's not lsb_release
<zyga> anyway, need to sleep and finish things
<mup> PR snapd#2936 closed: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2936>
<mup> PR snapd#2948 opened: interfaces/bluez,network-manager: implement ConnectedSlot policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2948>
#snappy 2017-02-28
<ogra_> kyrofa, i'm  pretty sure we could just add a serial interface to all gadgets by default, lets talk tomorrow
<mup> PR snapd#2939 closed: cmd/libsnap: add sc_string_append_char <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2939>
<mup> PR snapd#2949 opened:  cmd/libsnap: add sc_string_append_char_pair <Created by zyga> <https://github.com/snapcore/snapd/pull/2949>
<RoninDev> Hello! Can you help me please. I try to make snap using github sources. Github sources contains perl scripts. I need to run perl build script and after it copy all directory into the snap. But my prime and stage folders are empty. I use plugin dump, scriptlet "build: perl build.pl". If i comment build scriptlet, all sources persists in destination stage and prime. But if I uncomment it, destination folders are empty
<mup> PR snapd#2950 opened: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <https://github.com/snapcore/snapd/pull/2950>
<mup> PR snapd#2899 closed: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2899>
<mup> PR snapd#2951 opened: interfaces: use seccomp specs <Created by stolowski> <https://github.com/snapcore/snapd/pull/2951>
<mup> PR snapd#2940 closed: interfaces: use seccomp specs <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2940>
<om26er> Hi! where can I get snapcraft lxd image ?
<om26er> do we maintain one ?
<ogra_> om26er, iirc a "snapcraft cleanbuild" downloads it, it should show the download location it uses (i could be wrong though)
<om26er> ogra_: hmm, seems snapcraft downloads a normal ubuntu image and installs packages afterwards
<kalikiana_> om26er: what else do you expect? regular snapcraft also builds on your classic ubuntu
<om26er> kalikiana_: just an image with upto date snapcraft preinstalled :)
<kalikiana_> om26er: You don't need snapcraft in the image. It copies itself
<mup> PR snapd#2952 opened: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/2952>
<mup> PR snapd#2953 opened: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <https://github.com/snapcore/snapd/pull/2953>
<mup> Bug #1667844 changed: r1325 core snap candidate rebooting every 7 min without iTCO_wdt module loaded <Snappy:Fix Released> <https://launchpad.net/bugs/1667844>
<mup> PR snapd#2954 opened: wip: 2nd setup-profiles done after restart for installing core <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2954>
<mup> PR snapd#2955 opened: cmd: fixes to run correctly on opensuse <Created by mvo5> <https://github.com/snapcore/snapd/pull/2955>
<Pharaoh_Atem> wut
<Pharaoh_Atem> mvo: openSUSE?!
<Pharaoh_Atem> oh, these are zyga commits in disguise
<mup> Bug #1642581 changed: Livepatch checkState: check-failed <Snappy:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1642581>
<kyrofa> Hey ogra_, I don't think the serial-port interface has an "all" option, does it?
<ogra_> kyrofa, no, but if your plug defines it and the device is fixed it should still work
<kyrofa> ogra_, judging from this comment, the definition of individual devices actually needs to be slot-side right now: https://bugs.launchpad.net/snapd/+bug/1645445/comments/2
<mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <snapd:Confirmed> <https://launchpad.net/bugs/1645445>
<kyrofa> ogra_, i.e. in the gadget itself
<ogra_> kyrofa, so we could define two at least .... /dev/ttyS0 and /dev/ttyUSB0
<kyrofa> ogra_, yeah that's the best we could do I think, and it doesn't help I'm afraid. Not only does it not work for multiple devices, but the inability to determine which device is which means even if we expanded that it's not very helpful
<kyrofa> ogra_, we have udev as an interface backend. I don't understand why the serial-port is slot-only
<ogra_> why ? if you have a single usb dongle attached it will always be USB0
<kyrofa> ogra_, as soon as you have more than one that breaks down
<ogra_> and if there is a local serial port the first one is always ttyS0
<ogra_> indeed
<ogra_> but it works for a single serial port device, either native or USB
<ogra_> and you can add more slots ... USB1 ttyS1
<ogra_> for USB that becomes kind of tricky indeed
<ogra_> since the order wont be fixed
<kyrofa> ogra_, yeah that's what I mean by the inability to determine which device is which
<ogra_> and you have multiple in all your cases ? ?
<kyrofa> For my specific use-case, no. I'm currently only using one. But in the systems I've used in the past we had several
<thresh> so... "\Adjusting snap declaration for the slot side to include "deny-auto-connection": "true" since it was mistakenly omitted.Ã¢" what does that mean?
<kyrofa> thresh, where are you seeing that?
<lazyPower> is there a way to skip the fetch phase of the dump plugin? My upstream source seems to be having flakey connectivity issues today, i have the .tar.bz2 source already fetched, seems like it should just take that unless i clean it?
<kyrofa> lazyPower, if the pull step has already completed it shouldn't be trying it again
<kyrofa> lazyPower, are you cleaning it each time?
<lazyPower> kyrofa: :| thats unfortunate. its attempting to fetch etcd over and over
<lazyPower> i was, however i've placed the release tarball its expecting in $PWD and it seems to think thats not good enough, its still attempting to fetch it.
<kyrofa> lazyPower, yeah snapcraft does its own state tracking
<kyrofa> lazyPower, stop cleaning the pull step, then. You can clean each step of the lifecycle individually. If you don't want to pull again, just clean back to the build step: snapcraft clean -s build
<lazyPower> ahhhh ok
<kyrofa> lazyPower, you can do that per-part as well: snapcraft clean <part> -s build
<lazyPower> now i just need to get past this connectivity issue and we should be golden once i've got the package fetched again
<lazyPower> thanks for the details kyrofa
<kyrofa> lazyPower, it's why I'm here! Any time
<lazyPower> oh, also! I discovered what my issue seems to have been wrt snap refresh bailing... (i think it was zyga that followed up actually... but i pinged you instead. derp!) https://bugs.launchpad.net/snapd/+bug/1668659
<mup> Bug #1668659: Using snaps in lxd can be problematic during refresh (using squashfuse) <snapd:New> <https://launchpad.net/bugs/1668659>
<lazyPower> looks like squashfuse works great until you go to refresh and the apparmor profile steps in to create schenanigans
<kyrofa> Ah interesting
<lazyPower> so its isolated to lxd, i gave it some additional love on clouds and things were working as expected
<lazyPower> i expected to find dragons in there tbh... snaps in lxd is still experimental no?
<kyrofa> lazyPower, as far as I know, yes. But that's a better question for stgraber
<lazyPower> fair enough, consult with the oracle of containers
<kyrofa> Indeed :)
<lazyPower> kyrofa: i just need to edit a shellscript to resolve some syntax errors i built with the last push. is it going to set off alarms if i just edit the wrapper in place?
<lazyPower> on the installed unit (not sure if we tripwire or crc check or whatever integrity checks in snaps... but i know its a big deal)
<kyrofa> lazyPower, "in place" meaning what... within the installed snap itself? You will quickly become sad if so
<lazyPower> oooookay, thats why i asked before i hozed it :)
<kyrofa> lazyPower, haha, so yes, that's what you meant?
<kyrofa> lazyPower, we don't check the integrity within the snap as it's immutable-- it's a squashfs image, you can't actually change it
<kyrofa> lazyPower, so: you won't be sad because things will break, but because you won't actually succeed
<lazyPower> ooo
<lazyPower> okay, well that makes sense
<lazyPower> sorry still wrapping my head around the tech and poking it with progressively longer sticks to see what it does
<kyrofa> lazyPower, squashfs is a compressed filesystem that is by definition read-only
<mup> PR snapcraft#1164 opened: tests: run the master tests against the staging server <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1164>
<kyrofa> lazyPower, and no apology necessary, sorry if I came off as abrasive there, I'm just messing with ya
<lazyPower> no way :) you're good kyrofa
<kyrofa> lazyPower, are you still developing this snap? Or when you say "[...] with the last push" did you release something?
<lazyPower> not to the store, no. I'm picking up where sabdfl left off with etcd and massaging it into the charm
<kyrofa> lazyPower, do you know about `snap try`?
<lazyPower> i do not
<kyrofa> lazyPower, well, squashfs images being read-only is a cool, important part of the snap story. But it's incredibly annoying when you're still developing your snap, as you may have noticed
<lazyPower> yeah, this looks like the devmode stuff from before but minus the squashfs bits
<lazyPower> interesting
<kyrofa> lazyPower, snapcraft's 'prime' step creates a `prime` directory that is literally the final snap, but not put into the final image
<kyrofa> lazyPower, instead of running all the way through snapcraft's lifecycle, you could stop on `prime` and just `snap try prime`
<kyrofa> lazyPower, then instead of installing/mounting the squashfs image (which would be read-only), snapd will bind-mount the `prime` directory into place and treat it as the snap
<lazyPower> ok, i'll give this a go once i can unblock snapcraft (s3 is down \o/)
<kyrofa> lazyPower, which means it's no longer read-only. As you change stuff in `prime`, you change the snap
<kyrofa> lazyPower, s3 is only down in us-east I think
<kyrofa> lazyPower, us-west-2 is working here
<lazyPower> seems to be what i'm routing to :(
<kyrofa> Poor guy
<kyrofa> lazyPower, anyway, consider that your snappy lesson of the day
<lazyPower> thanks kyrofa :) its very helpful
<kyrofa> lazyPower, any time
<mup> PR snapcraft#1155 closed: beta <Created by snappy-m-o> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1155>
<lazyPower> kyrofa: one additional question you might have insight into
<kyrofa> lazyPower, sure
<lazyPower> kyrofa: We have user requests to support durable storage for applications. /var/snap/$snap/$revision is a versioned fs path, i cant just bindmount the block device to a specific version. The only way to work around this would be to take over the /var/snap/$snap path?
<kyrofa> lazyPower, durable storage = remains when the snap is removed?
<lazyPower> well, think AWS EBS volumes.
<lazyPower> yeah
<kyrofa> lazyPower, ah sure
<lazyPower> you could nuke the application, and restore from that data dir and dump + restore
<lazyPower> but snap remove would effectively wipe that out wouldn't it?
<kyrofa> lazyPower, I suggest using the `removable-media` plug
<kyrofa> lazyPower, that would allow access to disks in /media/
<lazyPower> hmmm ok
<lazyPower> https://github.com/CanonicalLtd/snappy-docs/blob/master/reference/interfaces.md - that appears undocumented
 * lazyPower files a bug
<kyrofa> lazyPower, I see it there
<lazyPower> argh darn me and my typos
<lazyPower> you are correct its inline
<jsolano> hello, any freelancers out there in Germany or Switzerland with experience with Ubuntu Core and snaps on ARM hardware?
<jsolano> or any hint at where to find them? Somebody I know is looking for an engineer for a short placement with this kind of experience
<diddledan> jdstrand: I got a notification that you made a change to corebird-diddledan to a slot declaration. Do I need to make any changes to my snapcraft.yml at all for future uploads to automatically have that or is the fix entirely store-side?
<jdstrand> diddledan: no. just a store side thing
<kyrofa> jsolano, have you mentioned this to Canonical? They might be able to help you
<diddledan> thanks
<jdstrand> diddledan: np
<jdstrand> diddledan: I just wanted you and other reviewers to know I did it
<diddledan> cool :-)
<jsolano> kyrofa, yes, I checked with them and I think they posted the information on linkedin, but no luck so far
<kyrofa> jsolano, did you speak to them about a commercial engagement for them to do the work?
<balloons> if i snap refresh --revision, what happens when the next refresh happens?
<kyrofa> balloons, I have that same question. Chipaca, are you around to answer that one?
<jsolano> kyrofa, actually not, I didn't think about that route, perhaps something worth considering
<kyrofa> jsolano, direct message your contact info to me, I can put you in touch with the right people
<kyrofa> (if you're interested, of course)
<balloons> kyrofa, I think it would require you to be the owner to do it? I'm not sure. The same question exists if you revert to a specific revision. I imagine either way you'll be bumped forward again by the next one
<kyrofa> balloons, indeed, I know that in order to use specific revisions you need to be a developer for the snap in question
<kyrofa> balloons, but the question about what happens by an update, no idea
<mup> Bug #1668738 opened: core snap with configure hook fails for some people <Snappy:New> <https://launchpad.net/bugs/1668738>
<bdmurray> Is there something equivalent to cronjobs in snaps?
<mup> PR snapd#2945 closed: interfaces: miscellaneous policy updates for unity7, udisks2 and browser-support (LP: #1667480) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2945>
<lazyPower> Is there a way to query the snap package listing in a format other than smart output? I need to surface some data and >>> check_output(split('snap list | grep rclone')).strip().split(b'\n')[-1].split(b' ')[2] seems like a really ugly and brittle way to do this
<mup> PR snapd#2946 closed: interfaces: consistently use 'const' instead of 'var' for security policy <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2946>
<thresh> how do I ship logrotate files and systemd service files in snap packages?  I want to package a server-side software.
<lazyPower> thresh: so snappy creates systemd files for you when you declare daemons in the snapcraft.yaml
<lazyPower> thresh: for example i'm working with the etcd snap and it creates a 'snap.etcd.etcd' service which is the etcd systemd job that controls ensuring the daemon is up and running.
<thresh> kyrofa, I believe jdstrand did something to my VLC snap that is uploaded to the store :)
<thresh> lazyPower, aha, nice, thanks!
<lazyPower> thresh: regarding the logrotate jobs, i'm not positive on that front, might be worth a ping to the snapcraft ML if nobody pipes up here
<jdstrand> thresh: I did not touch the snap. I adjusted its snap declaration
<thresh> jdstrand, do we have to do anything on our side?
<jdstrand> thresh: nope
<thresh> It was a bit weird, though.
<jdstrand> thresh: just wanted people to know the change was made
<thresh> OK, thanks!
<mwhudson> can i build classic snaps in launchpad yet>
<mwhudson> ?
<kyrofa> mwhudson, I haven't tried lately, but I _think_ so
<mwhudson> ah heck, i can't use the same snap name for two branches
<mwhudson> although maybe that doesn't actually matter here
<mwhudson> Setting up '/home/buildd/.cache/snapcraft/projects/snapcraft-core/snap_hashes/ppc64el/d8e9e73dabe243321f9df8b09e270bccfde6f273f05d90a21365aa6f77574127274479af8033389c0be076797c74a595' in '/snap/core/current'
<mwhudson> looks promising
<kyrofa> mwhudson, yeah, the snap name in LP is specific to LP. When it comes to uploading it, it uses the one declared in the YAML
<mwhudson> kyrofa: makes sense, if i a bit confusing at first
<kyrofa> Indeed
<mwhudson> kyrofa: i guess support for auto pushing to tracks from lp is on some trello board somewhere but not yet done?
<kyrofa> mwhudson, yeah no idea on that one
<mwhudson> paging cjwatson wgrant etc
<mwhudson> hmm would also be nice if snap builds dumped out the build environment like sbuild does
<mwhudson> oh right i guess cleanbuild works with classic snaps now too
<kyrofa> It should, yes
<wgrant> mwhudson: Yeah, we're a bit busy atm, but it's on the agenda.
<mup> PR snapd#2956 opened: interfaces: 'getent' by default; add /etc/ethers to network_{control,observe} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2956>
<jdstrand> kyrofa: fyi ^
<kyrofa> jdstrand, hey thanks!
<jdstrand> np
<kyrofa> jdstrand, did you see on the mailing list that I finally learned what was going on with the DNS issues?
<jdstrand> kyrofa: I did. a cname bug. annoying :\
<kyrofa> Indeed
<jdstrand> kyrofa: but at least the mystery is solved
<kyrofa> jdstrand, no kidding. Man was I ever confused
<jdstrand> ssweeny: fyi, this is committed now: https://github.com/snapcore/snapd/pull/2945/files#diff-52246fa9c4d8b0b81c71014fbec7b1b6R91
<mup> PR snapd#2945: interfaces: miscellaneous policy updates for unity7, udisks2 and browser-support (LP: #1667480) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2945>
<cjwatson> mwhudson: yep, I'm due to talk with Facu about it when not entirely swamped with MWC
#snappy 2017-03-01
<mwhudson> argh
<mwhudson> the way LDFLAGS is set for classic snap builds is painful
<mup> Bug #1662357 opened: Can't use lsb_release on Ubuntu Core 16 <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662357>
<mup> PR snapcraft#1165 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1165>
<mwhudson> waaait a minute
<mwhudson> can i build classic snaps on launchpad for all architectures?
<mwhudson> strongly getting the feeling that the interpreter is wrong for these builds
<mup> PR snapd#2957 opened: snapstate: include change kind/summary in error report <Created by mvo5> <https://github.com/snapcore/snapd/pull/2957>
<mup> PR snapd#2958 opened: snapstate: disable running the configure hook on classic for the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2958>
<mup> Bug #1668891 opened: Can install non classic snap with --classic, but classic flag isn't set <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1668891>
<mup> PR snapd#2959 opened: data: re-add snapd.refresh.{timer,service} with weekly schedule <Created by mvo5> <https://github.com/snapcore/snapd/pull/2959>
<thresh> jdstrand, what exactly does that change mean, btw?  I'm too stupid to understand docs.
<mup> PR snapd#2960 opened: release: add linuxmint 18 to the whitelisted distros <Created by mvo5> <https://github.com/snapcore/snapd/pull/2960>
<mup> PR snapd#2961 opened: ifacestate: re-generate apparmor in InterfaceManager.initialize() <Created by mvo5> <https://github.com/snapcore/snapd/pull/2961>
<mup> PR snapd#2962 opened: tests: temporarly unbreak docker by manually connecting the interfaces <Created by mvo5> <https://github.com/snapcore/snapd/pull/2962>
<Son_Goku> gurgle
<mup> PR snapd#2963 opened: interfaces: use MockInfo in tests <Created by stolowski> <https://github.com/snapcore/snapd/pull/2963>
 * ogra_ hands Son_Goku a snorkel
 * Son_Goku takes it, then chokes on it
<ogra_> should i have removed the cork at the end ?
<paulliu> hi. I have a problem. I'm snapcrafting zenity. But zenity wants to load its ui file from /usr/share/zenity/zenity.ui
<paulliu> I'd like to know if there's any tricks other than patching zenity?
<Son_Goku> ogra_: probably :P
<ogra_> :)
<mup> PR snapd#2962 closed: tests: temporarly unbreak docker by manually connecting the interfaces <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2962>
<mup> PR snapd#2957 closed: snapstate: include change kind/summary in error report <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2957>
<Son_Goku> ogra_: I hate golang now
<Son_Goku> a lot
<Son_Goku> before, I just disliked it
<Son_Goku> :/
<mup> PR snapd#2964 opened: errtracker: forward port the 2.22.7 fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/2964>
<mup> PR snapcraft#1166 opened: tests: Fix name registration window limit test to latest changes <Created by fgallina> <https://github.com/snapcore/snapcraft/pull/1166>
<zioproto> coreycb, james I was able to compile the nova package versione 13.1.3 I pushed stable/mitaka and pristine-tar branches to https://code.launchpad.net/~zioproto/ubuntu/+source/nova/+git/nova    How does it work for the merge request on launchpad ? I have to do 1 MR for each branch ? I will be testing the new package on our staging cluster. I will do the merge request when I am sure it is okay.
<zioproto> ops wrong channel :)
<zioproto> sorry for the noise:)
<ssweeny> jdstrand: awesome, thanks!
<mup> PR snapd#2965 opened: snapstate: error in LinkSnap() if revision is unset <Created by mvo5> <https://github.com/snapcore/snapd/pull/2965>
<enoch85_work> hey, anyone knows where kyrofa is?
<jdstrand> thresh: the snap declaration issued by the store did not include an auto-connection constraint when it should have so that would make snapd auto-connect snaps that plugged yours
<mup> PR snapd#2966 opened: daemon: DevModeDistro does not imply snapstate.Flags{DevMode:true} <Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/2966>
<mup> Bug #1669000 opened: classic snap can't use confinement override <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1669000>
<Tryum> ping didrocks (Thibault Jochem ^^)
<mup> Bug #1669012 opened: Can't reinstall a snap already installed switching confinement mode <amd64> <apport-bug> <xenial> <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1669012>
<jdstrand> morphis_: hey, I was looking into mmcli not auto-connecting and it seems your yaml should be: http://paste.ubuntu.com/24090328/
<morphis_> jdstrand: hey
<morphis_> jdstrand: that syntax was working quite well so far, what is broken with this short form?
<jdstrand> morphis_: I'm not sure if that is a bug in snapd or not. I know mmcli: null is supposed to work
<morphis_> hm
<morphis_> auto-connection AFAIK works
<morphis_> or do you see this with a pretty recent snapd version?
<jdstrand> morphis_: but this is supposed to be a dict. I'm looking at the docker snap declaration and the modem-manager snap declarations, and they are identical in how they allow auto-connect, but docker's works and modem-manager does not
<jdstrand> morphis_: and this is the difference I see in their snap.yamls
<jdstrand> $ snap --version
<jdstrand> snap    2.22.7
<morphis_> hm
<morphis_> jdstrand:  let me try to reproduce this
<jdstrand> morphis_: hmm. if I look at nm, it has the same style as mm, and it auto connects
<morphis_> yeah, that is what makes me wonder and we have a CI test in place which verifies this doesn't break
<jdstrand> morphis_: oh, weird
<jdstrand> hmm, this is on classic
<jdstrand> morphis_: let me reproduce on all snaps
<jdstrand> I just noticed that :modem-manager and modem-manager:service were both in the list
<morphis_> jdstrand: ah you do this on classic?
<jdstrand> morphis_: I did. gimme a minute before spending time on it
<morphis_> ok
<jdstrand> morphis_: it is fine on all snaps
<mup> PR snapd#2955 closed: cmd: fixes to run correctly on opensuse <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2955>
<morphis_> jdstrand: ok
<morphis_> reminds me we should put a CI job for testing classic in one day too
<mup> PR snapd#2967 opened: tests: remove workaround for docker again, snap-declaration is fixed now <Created by mvo5> <https://github.com/snapcore/snapd/pull/2967>
<jdstrand> morphis_: is ofono supposed to auto-connect to bluez?
<jdstrand> there is no snap decl for that
<didrocks> hey Tryum ;)
<didrocks> Tryum: saw your email on the ML, let's see if that triggers ideas :)
<jdstrand> morphis_: it seems clear there should be, so I granted it just now
<morphis_> jdstrand: oh thanks, yeah it should
<mup> PR snapd#2960 closed: release: add linuxmint 18 to the whitelisted distros <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2960>
<mup> PR snapd#2964 closed: errtracker: forward port the 2.22.7 fixes <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2964>
<jdstrand> mvo: hey, I have 2 PRs that are 'Waiting for status to be reported' for travis-ci. They were submitted/updated yesterday. is there an issue with travis?
<jdstrand> https://github.com/snapcore/snapd/pull/2948 and https://github.com/snapcore/snapd/pull/2956
<mup> PR snapd#2948: interfaces/bluez,network-manager: implement ConnectedSlot policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2948>
<mup> PR snapd#2956: interfaces: allow 'getent' by default with some missing dbs to various interfaces <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2956>
<mvo> jdstrand: yes, travis is in unhappy-land currently, I think related to the s3 outage the other day
<jdstrand> mvo: ah, ok, thanks
<mvo> jdstrand: also thanks for your feedback on the dynamic-detection of the apparmor features branch, happy to look at the directory instead of version_signature
<mvo> jdstrand: lets talk tomorrow or friday, I need to get 2.23 out of the door today but I'm keen to fix snapd/snap-confine interaction soon :)
<jdstrand> mvo: we might want to discuss with tyhicks and come up with a plan for making this easier/more robust
<jdstrand> mvo: ah, ok, sure
<mup> PR snapd#2965 closed: snapstate: error in LinkSnap() if revision is unset <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2965>
<jdstrand> mvo: would you ind looking at 2948 and 2956 for 2.23 then?
<jdstrand> mind*
<mvo> jdstrand: yeah, I was  unaware of this problem until recently, we added some more distros for 2.23 (mint,zorin) so its not super urgent
<mvo> jdstrand: sure, let me check
<jdstrand> mvo: 2956 is super obvious. 2948 impacts morphis_' snaps, but he gave the +1
<mvo> jdstrand: could you please merge master and push them? that hopefully wakes travis up again
<jdstrand> sure
<jdstrand> mvo: done for both. it looks like travis is 'in progress'
<mvo> jdstrand: I keep an eye on it and restart if needed, thank you. reviewing now
<jdstrand> mvo: thanks!
<mup> PR snapd#2968 opened: overlord/snapstate: drop forced devmode <Created by chipaca> <https://github.com/snapcore/snapd/pull/2968>
<pshod> set up a pi3 with core
<pshod> from console asks for localhost login
<pshod> ssh with sso username asks for password
<pshod> help!!!
<kyrofa> pshod, did it ever work?
<kyrofa> pshod, or did you just finish the initial setup?
<pshod> got till successfully registering my sso account
<pshod> ssh ssousername@192.168.1.18
<kyrofa> And your SSO account has SSH keys in it?
<pshod> using this from the machine from which ssh keys are generated
<pshod> yes
<kyrofa> RSA ones (I seem to remember DSA not being supported)
<pshod> should the pi3 be shown @ my sso accnt
<pshod> ?
<pshod> yes
<pshod> twas a rsa key
<kyrofa> pshod, run ssh with -vvv and pastebin the output (feel free to sanitize as necessary)
<pshod> on every boot it goes to localhost login screen
<pshod> okay.
<pshod> wait.
<kyrofa> pshod, that sounds like it may be an old image-- I think it should be listing available keys and its IP address
<kyrofa> pshod, where did you get it?
<pshod> from the ubuntu's site
<kyrofa> davidcalle, how do I log a bug against https://developer.ubuntu.com/core/get-started/dragonboard-410c ?
<kyrofa> pshod, can you please give me the link you used?
<kyrofa> pshod, the link to the image could be out of date, I've discovered that before
<davidcalle> kyrofa: https://github.com/ubuntudesign/developer.ubuntu.com/issues
<davidcalle> pshod: I'm interested in where you got the image as well
<pshod2> http://pastebin.com/rKHrQGPx
<pshod2> pshod here
<pshod2> frm inside vm
<pshod2> david: ubuntu's website
<pshod> https://github.com/ubuntudesign/developer.ubuntu.com/issues
<pshod2> https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3
<pshod2> tis is the link
<pshod2> to the image
<jdstrand> mvo: I think you may want to read and weigh in on https://github.com/snapcore/snapd/pull/2947#discussion_r103728147
<mup> PR snapd#2947: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <https://github.com/snapcore/snapd/pull/2947>
<kyrofa> davidcalle, interesting, that page is using releases, whereas the DB one uses cdimage
<kyrofa> davidcalle, releases hasn't been updated since november
<davidcalle> kyrofa: https://github.com/ubuntudesign/developer.ubuntu.com/pull/223
<kyrofa> davidcalle, whereas cdimage was updated the end of January: http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<kyrofa> davidcalle, ah ha!
<kyrofa> pshod2, try the image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/ instead
<mvo> jdstrand: sure, looking
<jdstrand> mvo: it's kind of a philosophical question that I think requires an architect/lead to consider
<mvo> jdstrand: that sounds more like gustavo, but I will give my 0.02â¬ still
<jdstrand> hehe
<pshod2> anybody checked the pastebin?
<pshod2> eating
<pshod2> brb
<kyrofa> pshod2, please try with a newer image. If it happens again we'll look at the pastebin
<pshod2> how long till you are here
<pshod2> i will download it and flash
<pshod2> will take me some
<kyrofa> pshod2, I'll be here for about 5 hours or so
<pshod> md5?
<pshod> should i cpy?
<pshod> kyrofa
<kyrofa> pshod, I don't understand what you're asking
<pshod> while flashing the image onto the sd card
<pshod> there is an option of copying md5 checksum file
<pshod> should I use it?
<kyrofa> You mean to verify the image you downloaded was good?
<kyrofa> That's always a good idea
<pshod> yes
<pshod> okay
<pshod> kyrofa: why is it that i need to use a sd card formatter off the net instead of the in built format option
<kyrofa> pshod, which OS are you using?
<pshod> windows
<pshod> though have a vm running ubuntu 16
<pshod> corportate workstation limits
<pshod> shitty*
<pshod> generated the ssh keys in vm
<pshod> would ssh from there only
<kyrofa> pshod, that's a question for davidcalle. I didn't know Windows had a built-in tool for flashing images
<pshod> no
<pshod> not a built in tool
<pshod> Win 32 diskimager, redirected from the ubintu page
<pshod> ubuntu
<davidcalle> pshod: it's not a formatter it's a disk flasher, you can use https://etcher.io/ if you prefer
<pshod> yes
<pshod> used a diff app to format
<pshod> now pi is booting
<davidcalle> kyrofa: PR from earlier deployed thanks for pointing it out
<pshod> kyrofa: thanks bro reflashing with new image worked.
<kyrofa> pshod, good deal. Thanks for the update davidcalle!
<mup> PR snapd#2827 closed: cmd: add helpers for mounting / unmounting <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2827>
<mup> PR snapd#2948 closed: interfaces/bluez,network-manager: implement ConnectedSlot policy <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2948>
<mup> PR snapd#2966 closed: daemon: DevModeDistro does not imply snapstate.Flags{DevMode:true} <Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2966>
<mup> PR snapd#2961 closed: ifacestate: re-generate apparmor in InterfaceManager.initialize() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2961>
<mup> PR snapd#2958 closed: snapstate: disable running the configure hook on classic for the core snap <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2958>
<mterry> Why might the version from "snap version" not match my installed deb version?  (I have xenial-updates version 2.22.3 installed, but snap version says 2.22.7)
<jdstrand> mterry: because of snap reexec on classic
<jdstrand> mterry: the core snap has a newer snapd than what is installed on the system
<jdstrand> mterry: and there is magic to use it instead of what is shipped in the deb
<mterry> jdstrand: interesting.  Is there a way I can turn that off so that I can test a manually rebuilt snapd deb?
<jdstrand> mterry: I think SNAP_REEXEC=0
<mterry> jdstrand: ah thx!
<mterry> running snapd manually doesn't seem easy -- it seems to re-trigger its systemd job
<mup> PR snapd#2934 closed: errtacker,overlord/snapstate: more info in errtracker reports <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2934>
<lazyPower> hey stgraber - just wanted to follow up on http://pad.lv/1668659    Thanks for digging deep on this one. It sounds like the "sudo mount --make-rshared/" is a viable work around until the regression is patched? Is that a safe assumption to make?
<stgraber> lazyPower: yeah
<mwhudson> hey
<mwhudson> what's the status on https://bugs.launchpad.net/snapcraft/+bug/1665165 ?
<mup> Bug #1665165: classic snaps fail to build in launchpad in archs other than amd64 <classic> <launchpad-buildd:Invalid> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1665165>
<mwhudson> because boy did i get confused about that yesterday
<mup> PR snapd#2968 closed: overlord/snapstate: drop forced devmode <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2968>
<mup> PR snapd#2956 closed: interfaces: allow 'getent' by default with some missing dbs to various interfaces <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2956>
<bdmurray> is there something equivalent to cronjobs in snaps?
<kyrofa> bdmurray, personally I just use sleep in a normal simple service
<mup> Bug #1669151 opened: No way to discover one's own appID <Snappy:New> <https://launchpad.net/bugs/1669151>
<bdmurray> kyrofa: sleep for 24 hours? if its a cron.daily job
<kyrofa> bdmurray, yep: https://github.com/nextcloud/nextcloud-snap/blob/master/src/https/scripts/renew-certs#L29
<kyrofa> bdmurray, not saying it's ideal by any means, but it's the only way I know to do it today
<kyrofa> bdmurray, I expect at some point snapd will expose systemd's timers
<bdmurray> kyrofa: thanks for the idea
<mup> PR snapd#2949 closed:  cmd/libsnap: add sc_string_append_char_pair <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2949>
#snappy 2017-03-02
<mup> PR snapd#2970 opened: Add support for retrieving snap history from API <Created by justincan> <https://github.com/snapcore/snapd/pull/2970>
<mup> PR snapcraft#1165 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1165>
<mup> PR snapcraft#1167 opened: tests:install wget in the container that triggers the beta tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1167>
<mup> PR snapd#2959 closed: data: re-add snapd.refresh.{timer,service} with weekly schedule <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2959>
<mup> PR snapd#2971 opened: data: ship "snap.mount" service that ensures /snap is MS_SHARED <Created by mvo5> <https://github.com/snapcore/snapd/pull/2971>
<mup> PR snapd#2972 opened: cmd/libsnap: add sc_quote_string <Created by zyga> <https://github.com/snapcore/snapd/pull/2972>
<mup> PR snapd#2973 opened: cmd/snap-confine: use sc_do_mount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2973>
<mup> PR snapcraft#1168 opened: Add support for 7-zip sources <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1168>
<pshod> installedsnappy ubuntu for pi3
<pshod> able to ssh into it with my sso login
<pshod> how do i install my snaps developed at host
<pshod> ?
<mup> Bug #1669329 opened: "error: cannot install snap has changes in progress" should exit >1 <Snappy:New> <https://launchpad.net/bugs/1669329>
<ogra_> pshod, snap install ...
<pshod> i would also want to develop for the pi3
<pshod> can i scp my snap into the pi?
<ogra_> well, unless your snap only contains shell scripts you probably want to build on the pi to get the binaries built for the armhf architecture
<ogra_> you can easily set up a classic development environment on the pi:
<ogra_> snap install classic --devmode --edge
<ogra_> sudo classic
<pshod> i want to build for the pi arch so either i will have to develop on board or using alaunchpad project
<ogra_> then ... in the classic shell ... sudo apt update and you are good to go ... it behaves like any other ubuntu in there
<pshod> building on board sounds better
<pshod> why whould i sudo apt update?
<ogra_> to exit the classic shell you can just hit ctrl-d (or type exit) ... to enter it again just run "sudo classic" again
<pshod> if release my snap onto edge or beta
<pshod> then i can use only snap install
<ogra_> the classic shel gives you a deb based system ... you can apt install snapcraft to build snaps
<pshod> yes yes
<ogra_> the shell shares the same home dir with the outside snap system
<pshod> doesnt that bring in security vulnerablities?
<ogra_> so once you built your snap inside the classic shell, you exit it and run snap install /path/to/your.snap to install it
<ogra_> only if you give people full access to the board :)
<pshod> if i develop there then I wont have to publish my snap too
<pshod> hmmmm
<pshod> i can always remove the classic env
<pshod> right?
<ogra_> (teh classic shell cant run system daemons (well, it can if you manually start them for dev. purposes, but they wont auto-start))
<ogra_> just snap remove classic and it is all gone
<pshod> before sending it to production i would do that then
<pshod> ogra: remember _prasen_?
<pshod> i guess that is the user name i was using
<ogra_> if it is a larger project launchpad is surely better for building and all ... but for quick iteration and development on the board the classic shell is the best option
<ogra_> yup, i do :)
<pshod> trying to run core on a vm
<pshod> well I have got the pi now
<pshod> :D
<pshod> hey!
<pshod> hell everything is better outside the office
<pshod> took the pi home yesterday
<pshod> was able to do some stuff
<pshod> brought it back
<pshod> network proxy and lack of hdmi monitor
<pshod> :'(
<ogra_> sad
<pshod> yes
<Rumple> I have a package stuck on 'Manual review pending', and can't push a new version - which would fix the review issue. The same issue as in https://bugs.launchpad.net/snapcraft/+bug/1632136
<mup> Bug #1632136: Releasing a new snap is blocked by a previous uploading pending manual review <store> <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1632136>
<Rumple> Can the 'Manual review pending' revision be removed? The package is fancon
<mup> PR snapd#2954 closed: overlord: phase 2 with 2nd setup-profiles and hook done after restart for core installation <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2954>
<mup> PR snapd#2974 opened: many: add new (hidden) `snap debug ensure-state-soon` command and use in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2974>
<mup> PR snapd#2975 opened: overlord/snapstate: small cleanup of ensureForceDevmodeDropsDevmodeFromState <Created by chipaca> <https://github.com/snapcore/snapd/pull/2975>
<gbisson_> hi all, what's the latest stable core version/rev of snappy?
<gbisson_> I built an image for my platform (i.MX6Q) and get core     16-2     1292  canonical  -
<gbisson> however when I look at RPi3 I get: core        16-2          1267  canonical  -
<gbisson> (even after a snap refresh)
<gbisson> why aren't the two revisions aligned?
<ogra_> gbisson, run snap info core on both of them ;)
<ogra_> i assume you use different channels (unless they are actually different arches ... i.e. arm64 vs armhf)
<gbisson> ogra_: thanks yes my boards tracks beta...
<ogra_> i'd use edge while doing development
<gbisson> whereas rpi follows stable which makes sense
<gbisson> ogra_: thanks for the quick reply
<ogra_> (it rarely breaks)
<gbisson> well the problem I have with beta it that I can't install snapwbe
<gbisson> snapweb
<ogra_> oh ?
<ogra_> whats the error ?
<gbisson> error: cannot install "snapweb": snap "snapweb" has changes in progress
<gbisson> so I'd rather stick to the stable version ;)
<ogra_> and snap changes ? what does it tell ??
<ogra_> (you can see details with "snap change $changenumber")
<gbisson> http://pastebin.com/TqkCk936
<gbisson> nothing about snapweb I think
<ogra_> Error   2017-03-01T17:39:40Z  2017-03-01T17:39:49Z  Install "webdm" snap
<gbisson> then I tried webdm
<gbisson> but it's not the same right?
<ogra_> no, indeed
<gbisson> I have to say webdm/snapweb is confusing
<ogra_> webdm was the old name of snapweb
<gbisson> depending on the website you read it's either one or the other that is mentioned
<gbisson> how can I clear the snap changes ?
<ogra_> well, old docs might still mention webdm
<gbisson> how can I switch to stable channel for core?
<ogra_> sure
<ogra_> snap refresh core --stable
<gbisson> error: cannot refresh "core": snap "core" has changes in progress
<gbisson> I'm cursed
<gbisson> 1    Doing   2017-03-01T17:06:27Z  -                     Initialize system state
<gbisson> isn't this stuck somehow?
<ogra_> looks like
<ogra_> how did you create that image ... looks like there are issues with it
<gbisson> yes I'll check that process, thanks for the precious feedback
<ogra_> not properly signed assertion, broken gadget or some such
<gbisson> yes it's weird cause I don't see my kernel snap
<ogra_> yeah, that definitely means it wasnt properly initialized
<gbisson> yep, I'll let you know, thanks!
<ogra_> core, kernel and gadget should always be there before you do anything
<ogra_> else it would install a core ... rthats definitely worng
<jdstrand> mvo: thanks for reviewing and merging my branches yesterday :)
<mup> PR snapd#2714 closed: interfaces: interface to allow autopilot introspection <Created by sbaldassin> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2714>
<mterry> didrocks: looks like in snapd trunk, the content: field for content interfaces is now mandatory -- so that bit of doc in snapcraft-desktop-helpers might need updating to include it
<didrocks> mterry: hum, is that an error? on the spec it's told that content is implicitely plugname is not named
<didrocks> unsure if zyga is around ^
<didrocks> if so, it's a regression compared to previous behavior
<mterry> agreed it's a regression compared to before
<mup> PR snapd#2969 opened: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<mterry> But spec is correct for latest stable release at least
<mterry> Just won't be soon
<didrocks> mterry: mind opening a bug? :)
<didrocks> should be high/critical before release
<didrocks> mvo: ^
<didrocks> let's avoid that regression
<jdstrand> morphis: hey, fyi https://github.com/snapcore/snapd/pull/2969. This is the PR I was talking about last week
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<morphis> jdstrand: oh nice
<mterry> didrocks: https://bugs.launchpad.net/snappy/+bug/1669476
<mup> Bug #1669476: content: piece of content interfaces now mandatory in trunk <Snappy:New> <https://launchpad.net/bugs/1669476>
<mup> Bug #1669476 opened: content: piece of content interfaces now mandatory in trunk <Snappy:New> <https://launchpad.net/bugs/1669476>
<didrocks> mterry: commented, thanks! I hope mvo is going to have a look at it
<mup> Bug #1669477 opened: Snap installed as devmode can end up running confined <Snappy:New> <https://launchpad.net/bugs/1669477>
<morphis> jdstrand: btw. I am going to hook up our CI soon so it runs nightly against edge for the core snap so that we spot problems early on
<pedronis> didrocks: which spec?
<jdstrand> morphis: that sounds great :)
<mup> PR snapd#2967 closed: tests: remove workaround for docker again, snap-declaration is fixed now <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2967>
<amosbird> hi
<amosbird> does snap support centos 6?
<ogra_> amosbird, https://github.com/snapcore/snapd/wiki/Distributions
<amosbird> hmm
<mvo> didrocks: looking now
<mvo> didrocks: I will look over the code, I don't remember reviewing that
<didrocks> mvo: thanks!
<cvldrg> Hi, would anyone help me to install wget or curl with snao ?
<joc> elopio: hi, do you think the plainbox-provider plugin PR will be ok to go in next snapcraft release?
<elopio> joc: oh, I hope so. I'm seeing that the test error is not related to your change. I'll hit update to get a fresh run.
<joc> elopio: great, thank you
<jdstrand> tyhicks: hey, wondering if you would have time to review the description and my comments in this PR: https://github.com/snapcore/snapd/pull/2969 (ie, don't need a code review yet (unless you want to), just verify the approach and advise on my comment)
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<mup> PR # closed: snapd#2230, snapd#2302, snapd#2592, snapd#2624, snapd#2644, snapd#2749, snapd#2752, snapd#2782, snapd#2787, snapd#2793, snapd#2837, snapd#2855, snapd#2869, snapd#2877, snapd#2895, snapd#2929, snapd#2930, snapd#2932, snapd#2938, snapd#2941, snapd#2942, snapd#2944, snapd#2947,
<mup> snapd#2950, snapd#2951, snapd#2952, snapd#2953, snapd#2963, snapd#2969, snapd#2970, snapd#2971, snapd#2972, snapd#2973, snapd#2974, snapd#2975
<genii> Whoa
<jdstrand> tyhicks: if now isn't convenient, I have other things I can work on
<mup> PR # opened: snapd#2230, snapd#2302, snapd#2592, snapd#2624, snapd#2644, snapd#2749, snapd#2752, snapd#2782, snapd#2787, snapd#2793, snapd#2837, snapd#2855, snapd#2869, snapd#2877, snapd#2895, snapd#2929, snapd#2930, snapd#2932, snapd#2938, snapd#2941, snapd#2942, snapd#2944, snapd#2947,
<mup> snapd#2950, snapd#2951, snapd#2952, snapd#2953, snapd#2963, snapd#2969, snapd#2970, snapd#2971, snapd#2972, snapd#2973, snapd#2974, snapd#2975
<tyhicks> jdstrand: how come you were thinking that netlink_sendmsg() doesn't call out to the LSM in some situations?
<mup> PR snapd#2977 opened: releasing package snapd version 2.23 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2977>
<tyhicks> I quickly walked through netlink_sendmsg() but don't see any short circuits for the root user
<tyhicks> jdstrand: oh, I think I see it now
 * tyhicks reads
<jdstrand> tyhicks: early in the function. search for -EPERM
<tyhicks> jdstrand: that's equiv to DAC being applied before MAC (the only time the LSM isn't called is when the user doesn't have CAP_NET_ADMIN and the sendmsg() fails)
<jdstrand> tyhicks: yes
<tyhicks> jdstrand: ah! I thought you were saying that LSM is bypassed in some non-error conditions
<tyhicks> I misunderstood
<jdstrand> tyhicks: no. I was only saying that I observed socket(AF_NETLINK, ..., NETLINK_ROUTE) as root did not go through the lsm
<tyhicks> ok
<tyhicks> I need to go back and read the first comment in the PR
<tyhicks> there looks to be a good amount to digest so it'll take me a little bit
<jdstrand> tyhicks: because if I remove 'socket AF_NETLINK - NETLINK_ROUTE', I get a seccomp denial. if I add it, I get no apparmor denial for a lack of 'network netlink ...,' rule
<tyhicks> jdstrand: ok, I'm still missing some context on why you think the netlink-audit and netlink-connector "escape hatches" are needed
<tyhicks> I can say that NETLINK_AUDIT will be needed by any trusted helpers that audit through the audit subsystem (dbus-daemon is an example)
<jdstrand> tyhicks: currently, NETLINK_AUDIT is only in account-control. I did a rdepends on libaudit1 and there was enough there that made me feel like a 3rd party app may try to use it
<jdstrand> tyhicks: and we wouldn't want something that simply uses 'python-audit' to be able to create user accounts
<tyhicks> jdstrand: ok, I understand the desire for netlink-audit
<tyhicks> jdstrand: you didn't justify netlink-connector very much
<tyhicks> jdstrand: it has been years since I looked at NETLINK_CONNECTOR but I don't remember anything using it
<jdstrand> tyhicks: NETLINK_CONNECTOR isn't used in any of the policy, but I saw it in a few places on codesearch
<jdstrand> lvm2, ulatencyd, ruby-god, powerstat and v86d
<jdstrand> and stress-ng
<tyhicks> jdstrand: ok, that makes some sense but note that we won't be able to mediate individual NETLINK_CONNECTOR users
<jdstrand> tyhicks: my concern is that we had a bare socket rule before and that all accesses aren't going through the lsm. I was hoping every AF_NETLINK would need a corresponding 'network netlink <type>' rule, but at least with NETLINK_ROUTE, that isn't the case
<tyhicks> jdstrand: from what I remember, it is just a common transport mechanism and anything that we can NETLINK_CONNECTOR access to will be able to set up a side channel
<tyhicks> s/that we can/that we grant/
<jdstrand> tyhicks: right, which is why I thought a separate interface that requires manual connection would be good
<jdstrand> same with audit
<mup> PR snapcraft#1169 opened: tests: update the ftp source for integration test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1169>
<tyhicks> well, not quite the same
<tyhicks> I think the routing for NETLINK_CONNECTOR is done based on the addr.nl_groups value
<jdstrand> tyhicks: because we are now mediating all socket(AF_NETLINK, ...) socket calls, I wanted to make sure people had a way to do what they could do before
<jdstrand> tyhicks: all I meant by same was the base declaration requires manual connection
<tyhicks> ah, gotcha
<jdstrand> tyhicks: is that a +1 on netlink-audit and netlink-connector?
<tyhicks> jdstrand: still confused about one thing... the java server that hit the NETLINK_ROUTE seccomp denial worked fine after you added the seccomp rule even thought you didn't add an apparmor rule?
<jdstrand> tyhicks: that is precisely correct, which was puzzling. I did not chase down why
<tyhicks> jdstrand: ok, +1 on both (I'll leave a comment) but I'm going to spend a little bit of time looking at the NETLINK_ROUTE code path
<jdstrand> tyhicks: ok, thanks (on both)
<lazyPower> mvo is my new hero. Holy cow the response time on http://pad.lv/1668659 is intense. Just wanted to stop by and say thanks for all the help both in here and on the bug everyone.
<jhodapp> Is there a standard place that I should put a custom wrapper script in for an app for my snap's source tree?
<kyrofa> jhodapp, nope, it's completely your playground!
<kyrofa> jdstrand, I typically just put stuff like that in a bin/ dir in the root of the snap
<jhodapp> kyrofa, so putting it in snap/ is not bad? I heard that snap/ is starting to become standard directory for other things
<kyrofa> jdstrand, sorry, I meant jhodapp
<jhodapp> it's ok, that happens to jdstrand and me all the time :)
<kyrofa> jhodapp, I'm just so used to typing his nick! :P
<kyrofa> jhodapp, anyway, you're right-- snap is actually not the best place
<kyrofa> jhodapp, snapcraft likes to own that dir
<jhodapp> ok, I saw another snap use it and I copied that...so I'll make sure to move away from that
<jhodapp> thanks kyrofa
<kyrofa> jhodapp, so you're not asking about where it should be the _final_ snap so much as asking for recommendations about how to organize your source tree?
<jhodapp> kyrofa, yes exactly
<kyrofa> jhodapp, I typically make a src/ directory, with a subdirectory for each part
<jhodapp> kyrofa, hmm interesting
<jhodapp> kyrofa, this might be something to start recommending...maybe a blog post or whatnot
<kyrofa> jhodapp, yeah, perhaps elopio and I could put together a weekly "tips and tricks" post of some kind
<jhodapp> kyrofa, would love that...snaps are so powerful with so much choice...knowing best practices would be *very* helpful
<jhodapp> kyrofa, to take off of Effective C++, could be an Effective Snapping series
<kyrofa> Ah, my favorite book
<jhodapp> mine too :)
<kyrofa> jhodapp, you and I need to meet sometime ;)
<jhodapp> haha, cheers
<kyrofa> Hmm. That came off creepier than I anticipated
<jhodapp> no I got your gist ;)
<jhodapp> no worries
<kyrofa> Hahaha
<kyrofa> elopio, how do you feel about something along those lines? ^^
<jdstrand> mwhudson: fyi, I approved your snap, but you need to release it still
<mwhudson> jdstrand: thanks
<mwhudson> huh snap install core in my lxd container downloads 5 megs really quickly then fails
<mwhudson> outside the container it is much slower but appears to be working?
<mwhudson> oh no, snap download core in the container is slow and working too
<mwhudson> hm if i've run snap download, how do i make snapd see the assertions file?
<kyrofa> mwhudson, snap ack
<kyrofa> mwhudson, then you can just `snap install` without --dangerous
<mwhudson> kyrofa: oh of course
<mwhudson> mount: wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1395.snap,
<mwhudson> eh what
<kyrofa> mwhudson, do you have squashfuse?
<mwhudson> yes
<kyrofa> mwhudson, you've reached the limit of my expertise :P
<kyrofa> (I've not tried this before)
<mwhudson> i'm trying to reproduce that thing where classic snap builds on !amd64 don't work
<mwhudson> "interpreter /snap/core/current/i386-linux-gnu/ld-2.23.so"
<mwhudson> that path looks pretty unlikely
<mwhudson> it's missing a /lib
<mwhudson> because someone didn't understand how symlink resolution works??
<kyrofa> Hmm... it actually looks like i386 is missing the core-dynamic-linker field all-together
<kyrofa> So it does a readlink on /snap/core/current/lib/ld-linux.so.2 and appends that to /snap/core/current
<kyrofa> Which of course won't work if the link is relative
<kyrofa> mwhudson, is that what you're talking about?
<mwhudson> kyrofa: yes
<kyrofa> Yeah, it should make that link relative to the core path before appending back onto it
<mwhudson> uh i hope /lib/ld-linux.so.2 is always a symlink
<kyrofa> Indeed
<mwhudson> oh readlink raises if it's not a symlink
<mwhudson> that's at least confusing than if it just returned its argument
<mwhudson> *less confusing
<elopio> kyrofa: +1. Like a short post of a couple of paragraphs? Or like a tutorial to snap something from 0, including an interesting detail?
<kyrofa> elopio, I was thinking something relatively short and sweet. The Effective Snapping idea was excellent
<mwhudson> https://github.com/snapcore/snapcraft/pull/1170
<mup> PR snapcraft#1170: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170>
<mup> PR snapcraft#1170 opened: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170>
<kyrofa> Thanks for that mwhudson
<mwhudson> after the amount of time i spent figuring out what was going on, the least i can do is save anyone else from the pain
<mwhudson> now can i have the fix on launchpad pls? :)
#snappy 2017-03-03
<tyhicks> jdstrand: circling back to our earlier discussion... a review of the code netlink code doesn't show anything odd and a simple test program which calls socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE) definitely requires a 'network netlink raw,' apparmor rule
<tyhicks> here's the denial I get if I don't add that rule to the profile:
<tyhicks> audit: type=1400 audit(1488499593.813:25): apparmor="DENIED" operation="create" profile="test" pid=1969 comm="nl" family="netlink" sock_type="raw" protocol=0 requested_mask="create" denied_mask="create"
<mup> PR snapcraft#1171 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1171>
<mup> PR snapd#2973 closed: cmd/snap-confine: use sc_do_mount everywhere <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2973>
<mup> PR snapd#2953 closed: release: detect if we are in ForcedDevMode by inspecting the kernel <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2953>
<mup> PR snapd#2978 opened: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <https://github.com/snapcore/snapd/pull/2978>
<liuxg> ogra_, ping
<liuxg> ogra_, I used your sample code in the mailinglist to launch google.com using xdg-open, but it did not work in my place. the source code is at https://github.com/liu-xiao-guo/launchwebsite
<mup> PR snapd#2950 closed: interfaces: use spec in kmod backend, updated firewall_control, openvswitch_support, ppp <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2950>
<mardy> cjwatson: hi! Just found out about build.snapcraft.io :-) Are there plans to make it support gitlab.com?
<stub> How to I revert a channel to an older release?
<stub> Do I need to download the old snap and reupload it, or is there a smarter way?
<mup> PR snapd#2970 closed: many: add support for retrieving snap history from API <Created by justincan> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2970>
<ogra_> liuxg, do you have snapd-xdg-open installed on the host ?
<joedborg> o/ all
<joedborg> I'm trying to set an environment variable inside an app declaration (inside snapcraft.yaml).  I need to base this off the $SNAP variable, but I can't get it to resolve.
<joedborg> e.g. $ echo $PYTHONPATH
<joedborg> $SNAP/horizon
<mup> PR snapd#2979 opened: tests: add ubuntu-core-16-32 system to the external backend and fix docker test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2979>
<kalikiana_> stub: Unpublish, re-publish, that's the best way I found to do it
<stub> ta.
<liuxg> ogra_, ping
<ogra_> liuxg, hey, did you see my reply above ?
<liuxg> ogra_, sorry, I did not see the reply :) I will try it. thanks
<liuxg> ogra_, is it a snap or debian?
<ogra_> its a deb you need installed on your desktop (it was discussed in the thread)
<cjwatson> mardy: Not at present
<liuxg> ogra_, sorry, I did not read it through. I think it is good to have it as a build-package in the snapcraft.yaml
<ogra_> liuxg, nope
<ogra_> you need it installed on the desktop, nothing in snapcraft.yaml will help with that
<liuxg> ogra_, I just installed it, and it worked.
<liuxg> ogra_, so build-package will not install it onto the desktop?
<ogra_> no
<ogra_> snapcraft only operates inside the snap
<liuxg> ogra_, ok. I got it. thanks.
<liuxg> ogra_, thanks for your help on this. so, this is an dependence.
<ogra_> right
<didrocks> ogra_: I think the user wants to install a snap in the store (ktouch)
<didrocks> not creating it
<ogra_> didrocks, hmm, that wasnt clear to me, yeah, you might be right
<didrocks> ogra_: so, the issue I guess is that the platform snap isn't connected to it, and the KDE helper (but I don't know how it works exactly) don't do this check with a nice error message unlike our desktop helper
<popey> yeah, i agree
<popey> they need to connect the content snap
<didrocks> sitter: hey, you might way to either use our desktop helpers or add this kind of check as we do
<didrocks> ogra_: feel free to rephase ;)
<didrocks> rephrase*
<didrocks> even
 * ogra_ re-phases and is now fully positive charged 
<didrocks> ahah
<didrocks> two or three phases? :)
<ogra_> old school .... only two and a grounding (at times) :)
<didrocks> heh
<mup> PR snapd#2977 closed: releasing package snapd version 2.23 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2977>
<jdstrand> tyhicks: maybe I got rate limited (even though I set it to '0')
<jdstrand> tyhicks: but it was weird-- if I added the seccomp rule, no apparmor denial, if I removed it, seccomp denial. I then tried it multiple times...
<jdstrand> (ie, went back and forth)
 * jdstrand tries with dgram
<stokachu> hmm how do i select a different organization in build.snapcraft.io?
<stokachu> i made sure it had access to that org on github
<jdstrand> dgram makes no difference
<jdstrand> tyhicks: maybe it was incredibly poor timing-- I can confirm that it is denied by apparmor as root and non-root. I can also confirm that if I go fast enough even with rate limiting disabled, I don't always see it in the log
<didrocks> mvo: hey, didn't you tell yesterday that 2.23 was blocked for zesty due to autopkgtests failing?
<mvo> didrocks: it was, then things fixed themself, it was an outdated core snap on ppc64el that held it back. sorry, I understand this is annoying now :(
<didrocks> mvo: we maybe should have put a holdâ¦ yeah, annoying it did fixed himself
<Jasem[m]> Quick question: If I build a snap on 17.04, it will work on 16.04?
<didrocks> Jasem[m]: if you include your all dependencies in your snap for a fully confined one, it should, indeed :)
<Jasem[m]> didrocks: Thanks, I decided to build on 16.04 just to be safe
<ogra_> Jasem[m], if you restrict yourself to run "snapcraft cleanbuild"  the host distro shouldnt matter (it will build in a xenial lxd container then)
<Jasem[m]> ogra_: thanks will take that into consideration. So I'm building a snap now in 16.04, so deploying it to Ubuntu-Core wouldn't be an issue I presume?
<ogra_> right
<Jasem[m]> Anyone here used Ubuntu-Core with Snapdragon board? I just saw the Embedded Linux videos
<ogra_> well, i'm maintaining the port ... so i occasionally actually use it ;)
<ogra_> s/port/image port/
<Jasem[m]> ogra_: I was considering it for my embedded project, but then read some issues about WiFi.. I think I might be eventually settle for the good-old RPI3
<ogra_> the dragonboard has no wifi issues
<ogra_> the pi3 does though :)
<Jasem[m]> PI3 working fine here with WiFi.. well, I tried other boards but each has its own issues. RPI3 is the most reliable so far despite its shortcomings
<ogra_> (only for the inital setup, it is rock solid afterwards ... but pi3 needs to do the setup wired )
<Jasem[m]> No USB3, no Gigabit Ethernet
<Jasem[m]> From the Embedded Linux presentation, it seems everything around Ubuntu-Core is free.. how does Canonical make any money of that then?
<ogra_> services, support, contracts with device manufacturers for porting/maintaining an image for their HW
<Jasem[m]> is there a service for "Here is X, Y, Z software I need. Make them into snaps and give me an image" ?
<Jasem[m]> Oh I'll just contact Canonical and find out
<mup> PR snapd#2980 opened: client, daemon: move "snap list" name filtering into snapd <Created by chipaca> <https://github.com/snapcore/snapd/pull/2980>
<mup> PR snapd#2981 opened: tests: add kernel-module-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2981>
<joedborg> is there any reason why snapcraft doesn't stage hidden files?
<joedborg> as in it seems to explicitly seems to ignore them
<mup> PR snapd#2944 closed: interfaces/builtin/alsa: add read access to alsa state dir <Created by ssweeny> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2944>
<ssweeny> thanks jdstrand
<jdstrand> ssweeny: np
<SuperJonotron> running into an odd issue here with snaps, done this a thousand times before but just rebuild a snap with two commands, both show up in the binary and if I navigate to that directory and call them by name ./snapName.command it says no such file or directory when trying to run
<SuperJonotron> does this maybe indicate snapcraft created a bad snap?
<mup> PR snapd#2982 opened: daemon: add desktop file location for app to the API <Created by mvo5> <https://github.com/snapcore/snapd/pull/2982>
<cholcombe> i'm giving snappy-debug a try and it cannot connect to log-observe: error: snap "ubuntu-core" has no slot named "log-observe".  Anyone else encountered this?
<kyrofa> cholcombe, can you pastebin the output of `snap interfaces`?
<cholcombe> sure one sec
<cholcombe> kyrofa: http://paste.ubuntu.com/24103211/
<cholcombe> this is on an ec2 xenial box
<kyrofa> Uh... huh. It says it's connected
<cholcombe> lol i know
<kyrofa> Does it work now? :P
<cholcombe> nope
<cholcombe> snap connect snappy-debug:log-observe ubuntu-core:log-observe
<cholcombe> error: snap "ubuntu-core" has no slot named "log-observe"
<cholcombe> is that the right command?
<kyrofa> Ohhh
<kyrofa> cholcombe, no, it's only core now
<kyrofa> cholcombe, in fact, you can leave the last arg off completely
<cholcombe> oh ok
<kyrofa> cholcombe, just run `snap connect snappy-debug:log-observe`
<cholcombe> yeah that works now
<kyrofa> cholcombe, ooo, gluster, that sounds like fun
<cholcombe> kyrofa: gluster has a new iscsi manager that i'm trying out
<cholcombe> i might even be bold and snap gluster
<cholcombe> the daemon is hanging when i start it and i'm not sure what's going on.  maybe strace will tell me something
<cholcombe> oh maybe this doesn't fork.  i must've misread the C code
<kyrofa> Hahaha
<kyrofa> So it's actually working?
<cholcombe> i'm not certain.  i'm messing around with it
<cholcombe> strace says it's waiting on futex
<cholcombe> kyrofa: yeah i think it is working
<cholcombe> looks like i need targetcli and some other crap.  need to rebuild the snap
<ogra_> snap "ubuntu-core" ?????
<ogra_> you shouldnt have that at all
<kyrofa> ogra_, probably referring to out-of-date docs
<ogra_> everyone should have been moved from ubuntu-core to core nowadays
<ogra_> kyrofa, well, it is in the error message above
<kyrofa> ogra_, because it's not intelligent
<kyrofa> $ sudo snap connect foo:bar baz:qux
<kyrofa> error: snap "foo" has no plug named "bar"
<ogra_> oh
<ogra_> silly !
<kyrofa> Agreed
<ogra_> add AI !!!!!
<cholcombe> kyrofa: if gluster-blockd needs to access targetcli do i need an interface for that?
<kyrofa> cholcombe, are they in separate snaps?
<cholcombe> i'm not sure if targetcli is snapped.  i could just apt install it
<kyrofa> cholcombe, is that something that should be contained within the snap?
<cholcombe> hmm.  i'm guessing not
 * kyrofa isn't sure what targetcli is
<cholcombe> kyrofa: it's a python program that configures iscsi initators
<kyrofa> cholcombe, think about it this way. If someone installs your snap on a clean install of Ubuntu, what's going to happen?
<kyrofa> cholcombe, you can't depend on a deb
<cholcombe> then yeah targetcli's python script will be missing
<kyrofa> cholcombe, so an interface isn't going to help you here
<cholcombe> and tcmu-runner whatever that is.  it's also complaining about that
<kyrofa> Oh man. Out of coffee before 10am. This will not be a good day
<cholcombe> ah crap tcmu-runner is another C program i need to snap
<cholcombe> so yeah i guess i should package this all together
<kyrofa> Yeah I think so
<kyrofa> cholcombe, just consider what happens if someone installed your snap alongside, I dunno, the ceph snap that also bundles those things (let's assume). Will it still work okay?
<cholcombe> i'm not sure
<cholcombe> ceph will likely also want iscsi targets
<cholcombe> it's unlikely they'll both be on the same machine but you never know
<kyrofa> Yeah it doesn't really change what you need to do (just bundle them), just something to keep in mind
<cholcombe> ok
<mup> PR snapcraft#1169 closed: tests: update the ftp source for integration test <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1169>
<mup> PR snapd#2983 opened: Support spread testing with proxy <Created by nuclearbob> <https://github.com/snapcore/snapd/pull/2983>
<kyrofa> jdstrand, within a snap, /tmp used to be unique to each app
<kyrofa> jdstrand, is that no longer the case? i.e. is the same /tmp/ shared across apps in the same snap?
<kyrofa> jdstrand, I guess it was specific to the instantiation, huh
<kyrofa> jdstrand, but has that changed?
<jdstrand> kyrofa: /tmp is shared across commands in the same snap
<kyrofa> jdstrand, do you remember when that change was introduced? Or was is all snap-confine?
<jdstrand> kyrofa: all commands share the same mount namespace. this is part of the reason why the snap-update-ns exists
<jdstrand> kyrofa: iirc it was snap-confine 1.0.43
<kyrofa> jdstrand, wonderful, that really simplifies some things
<jdstrand> snap-update-ns issue*
<cholcombe> kyrofa: gluster-blockd makes a unix socket in /var/run/gluster-blockd.socket.  If i want to access that from a user space program do i need to do anything special?
<cholcombe> i guess i'm asking which way the confinement goes.
<kyrofa> cholcombe, gluster-blockd is the thing you're trying to snap? And "a user space program" is outside of snaps?
<cholcombe> correct
<cholcombe> can user space programs access that socket or does it go both ways and i have to be in the snap to access it?
<kyrofa> cholcombe, you wouldn't need to do anything special from the user-space point of view, but I don't think a confined snap can place something directly in /var/run
<cholcombe> ok
<cholcombe> yeah i'm still in dev mode
<kyrofa> cholcombe, for the most part, you're not running a chroot (ala docker or lxd)
<cholcombe> ok
<kyrofa> cholcombe, well, I guess that's not quite right nowadays
<kyrofa> cholcombe, you're essentially chrooted into the core snap with stuff from the system bind-mounted in
<cholcombe> i see
<cholcombe> that's what i thinking
<cholcombe> so if i stay in classic of dev mode i'm good to go.  but if i go strict i'm going to have issues with that unix socket
<kyrofa> cholcombe, indeed. If strict you'll need to put that somewhere the snap can actually write
<cholcombe> yeah
<cholcombe> coreycb: for https://github.com/open-iscsi/tcmu-runner/blob/91d23191f97937bb92c19cc73565c8ea73c3cc7e/CMakeLists.txt do you know how to set LIBNL_LIB in the snapcraft.yaml?
<coreycb> cholcombe, it looks like you can set environment variables in snapcraft.yaml - https://bugs.launchpad.net/snappy/+bug/1583259
<cholcombe> kyrofa: looks like tcmu-runner wants me to drop files into /etc/dbus-1/system.d
<mup> Bug #1583259: Snappy needs to influence environment variables in applications  <snap-desktop-issue> <verification-done> <Canonical Click Reviewers tools:Fix Released by jdstrand> <Snappy Launcher:Invalid> <Snapcraft:Fix Released by sergiusens> <Snappy:Fix Released> <click-reviewers-tools
<mup> (Ubuntu):Fix Released> <click-reviewers-tools (Ubuntu Xenial):Fix Released> <click-reviewers-tools (Ubuntu Yakkety):Fix Released> <https://launchpad.net/bugs/1583259>
<kyrofa> cholcombe, so it needs the systemd dbus eh? That sounds like an interface
<cholcombe> coreycb: cool thanks for
<cholcombe> kyrofa: like i need to write an interface or i just make use of one?
<kyrofa> cholcombe, I'm not quite sure. I've successfully avoided dbus in snaps so far, so I don't have experience to fall back on here. jdstrand can probably help you more
<cholcombe> ok
<jdstrand> cholcombe: take a look at the dbus interface and specify 'bus: system'. that will give you the dbus policy in /etc/dbus-1/system.d
<cholcombe> jdstrand: ok
<jdstrand> cholcombe: if that interface isn't enough for you, you will need to a new interface
<jdstrand> to write*
<cholcombe> jdstrand: ok i'll take a peek in a minute
<jdstrand> cholcombe: https://github.com/snapcore/snapd/wiki/Interfaces#dbus
<cholcombe> this is prob a silly question but when i'm building snapcraft packages are all the dependencies being apt installed on my local system or are they in a chroot?
<kyrofa> cholcombe, no silly questions here :)
<cholcombe> :)
<kyrofa> cholcombe, it actually depends
<kyrofa> cholcombe, which depedencies are we talking about? How are they specified?
<cholcombe> i guess the question is should i building in a lxc container
<cholcombe> anything i say as build dependencies
<cholcombe> i'm wondering if i'm polluting my desktop with tons and tons of dev packages
<kyrofa> cholcombe, yep. build-packages are installed on the host
<cholcombe> ok
<kyrofa> cholcombe, stage-packages aren't-- they're unpacked right into the snap
<cholcombe> hmm alright
<kyrofa> cholcombe, indeed, every snap I personally build is in a new lxc container
<cholcombe> yeah i was wondering :D
<cholcombe> i need to start doing that
<kyrofa> cholcombe, is also ensures that I determine ALL dependencies
<cholcombe> exactly
<pmcgowan> kyrofa, does a configure hook run before or after connecting interfaces
<kyrofa> pmcgowan, neither, there are new hooks being written for that (called interface hooks)
<kyrofa> pmcgowan, oh wait, do you mean when installing?
<pmcgowan> kyrofa, well I mean in general
<kyrofa> pmcgowan, the configure hook won't run when you use `snap connect/disconnect`
<pmcgowan> I just added a configure hook to my snap and now the content interface is not really connecting
<kyrofa> pmcgowan, interesting, that shouldn't affect anything there
<kyrofa> pmcgowan, do you get an error?
<pmcgowan> wondering if its related before I back off
<pmcgowan> no error
<kyrofa> So helpful :P
<pmcgowan> just that I should connect the interface
<pmcgowan> whih shows connected
<pmcgowan> kyrofa, I will back up and see then
<kyrofa> Huh... not sure what's happening there
<Pharaoh_Atem> wtf
<Pharaoh_Atem> why is 2.23 not 2.23?
<Pharaoh_Atem> the snapd 2.23 tagged in git doesn't match what I expect it to be
<Pharaoh_Atem> it's ~14 days old
<pmcgowan> kyrofa, oy, I removed the hook and it works again
<pmcgowan> enough for friday
<kyrofa> pmcgowan, haha, okay, well ping me Monday then, happy to dig into that with you
<pmcgowan> kyrofa, k have a good weekend
<kyrofa> pmcgowan, you too!
<cholcombe> kyrofa: think you could take a quick peek at this? http://paste.ubuntu.com/24104552/  i'm trying to build the targetcli python part
<cholcombe> it seems to build correctly and then fail
<cholcombe> i can paste my snapcraft.yaml also
<cholcombe> http://paste.ubuntu.com/24104562/
#snappy 2017-03-04
<gnufan23> cool video about stallman :D https://www.youtube.com/watch?v=kb2T8hWRu8g
<mup> Bug #1575593 changed: Snappy installed manpages aren't accessible through man <snapd:Triaged> <https://launchpad.net/bugs/1575593>
<Jasem[m]> Hello I downloaded this plugin: https://github.com/apachelogger/kf5-snap-app/blob/master/parts/plugins/x-stage-debs.py
<Jasem[m]> and placed it under snap/plugins relative to the current snapcraft.yaml
<Jasem[m]> running snapcraft it still complains unknown plugins, any clues?
<mup> PR snapcraft#1172 opened: demos, tests: add the mount-observe plug to be able to run godd <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1172>
<mup> PR snapcraft#1173 opened: demos, tests: add a message to exit the mosquitto subscriber <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1173>
#snappy 2017-03-05
<mup> PR snapcraft#1095 closed: Plainbox providers run validate <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1095>
<ee> hi, I have posted a question in stack-overflow: http://stackoverflow.com/questions/42607918/error-after-installing-packages-with-snap?noredirect=1#comment72345436_42607918
<mup> PR snapcraft#1167 closed: tests:install wget in the container that triggers the beta tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1167>
<mup> PR snapcraft#1148 closed: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1148>
<mup> Bug #1670165 opened: alsa interface can't see micrphones <Snappy:New> <https://launchpad.net/bugs/1670165>
<obb> hi, I want to install snappy on debian jessie
<obb> is it possible/did anyone try it?
#snappy 2018-02-26
<mup> PR snapcraft#1958 opened: Migrating to more granular store permission <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1958>
<mborzecki> morning
<mup> PR snapd#4733 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4733>
<mup> PR snapd#4732 closed: [2.31] timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4732>
<mup> PR snapd#4734 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.31 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4734>
<mup> PR snapd#4736 closed: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.32 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4736>
<mup> PR snapd#4713 closed: cmd/snap: add self-strace to `snap run` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4713>
<mvo> hey mborzecki ! good morning
<mborzecki> mvo: hey, morning
<mborzecki> mvo: is it also that cold where you live?
<mvo> mborzecki: yeah, unusually cold. up to minus 10 or so in the nights
<mvo> mborzecki: very clear skys all the time, sunny but bitter cold :)
<mborzecki> mvo: my outside thermometer is showing -14 atm
<mborzecki> mvo: yeah, it's clear and sunny.. and cold :P
<mvo> mborzecki: woah, -14 even
<mvo> impressive!
<mborzecki> my dogs were unimpressed this morning :)
<mvo> heh
 * mvo checks his outside thermometer
<mup> PR snapd#4739 opened: many: remove snapd.refresh.{timer,service} <Created by mvo5> <https://github.com/snapcore/snapd/pull/4739>
<zyga> good morning
<mvo> hey zyga ! good morning
<zyga> hey
<zyga> mvo I experienced something very odd last nigth
<zyga> 54   Do      2018-02-24T10:49:28Z  -                     Auto-refresh snap "core"
<zyga> my snapd is stuck updating
<zyga> I sent a pastebin as well, still valid: 	https://pastebin.ubuntu.com/p/sj6s9qNzFQ/
<zyga> and I had one denial
<zyga> 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> I'm currently on core              16-2.29.4.2  4144  canonical  core
<zyga> I wonder if this is some bad revision that didn't have the symlink to make it work
<zyga> or if we missed something bigger
<zyga> and release will break
<zyga> oh, and none of the snaps work now
<zyga> they fail with that same denial
<mup> PR snapd#4737 closed: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4737>
<zyga> looking at snapd.service logs I see one more error:
<zyga> lut 24 11:49:38 fyke snapd[35097]: 2018/02/24 11:49:38.755234 backend.go:91: cannot create host `snap userd` dbus service file: failed to copy all: "cp: nie
<zyga> and that's all
<zyga> ideas welcome, I'm not sure what's failed
<zyga> for instance, I don't understand why the change is stuck
<zyga> why is it not auto-connecting things
<zyga> deadlock?
<mvo> zyga: uh, thats serious if that is stable to stable
<mvo> zyga: yeah, its very strange. 2.29 you say? its double strange as it should also have tried to go to 2.30 before already
<zyga> I think something odd has happened
<zyga> it is on distro package now
<zyga> I didn't set any reexec flags
<zyga> nothing in /etc/environment
<zyga> any ideas on what to check for next?
<zyga> note: I installed a snap on Friday evening
<zyga> mvo how can I be on 4144 which is more recent than beta but less recent than core
<zyga> and still be on 2.29.4.2?!?
<zyga> is. that some build that was made to make an out-of-bounds release
<zyga> this makes no sense to me
<mvo> zyga: what channel are you tracking?
<zyga> edge
<mvo> zyga: and what does "apt list --all snapd" show?
<mvo> zyga: edge, huh
<zyga> Name  Version                   Rev   Developer  Notes
<zyga> core  16-2.31+git583.0e8bcef    4104  canonical  core,disabled
<zyga> core  16-2.31+git586.d89ba3c    4117  canonical  core,disabled
<zyga> core  16-2.31.1+git587.d3e52a0  4133  canonical  core,disabled
<zyga> core  16-2.29.4.2               4144  canonical  core
<mvo> zyga: apt :)
<zyga> given this revision progression
<zyga> haha
<mvo> zyga: you mentioned your packaged version is run
<zyga> I didn't see apt
<zyga> I replaced "snapd" with core without thinking though
<zyga> yeah
<zyga> because of the +17.10 version
<zyga> zyga@fyke:~/go/src/github.com/snapcore/snapd$ snap version
<zyga> snap    2.29.4.2+17.10
<zyga> snapd   2.29.4.2+17.10
<zyga> mvo is it sane that 4144 has version 16-2.29.4.2?
<mvo> zyga: no, that does not sound sensible
<zyga> can you pull that revision and check?
<mvo> zyga: what does snap changes show? is it maybe trying to refresh for some time wihtout success?
<zyga> ID   Status  Spawn                 Ready                 Summary
<zyga> 54   Do      2018-02-24T10:49:28Z  -                     Auto-refresh snap "core"
<zyga> 55   Done    2018-02-26T00:51:39Z  2018-02-26T00:51:39Z  Refresh all snaps: no updates
<zyga> I pastebinned snap change 54 earlier
<mvo> zyga: and before that? when was the last successful core update?
<zyga> that 55 is "fun" because there *are* updates but core has changes in progress
<zyga> there's nothing more, is there a switch for earlier history?
<mvo> zyga: uh, you are right: 4144    2018-02-24T04:25:30Z  amd64    16-2.29.4.2                       edge
<mvo> zyga: so it looks like on sat we had 2.29.4.2 in edge for a brief time before a new build kicked in
<mvo> zyga: and we got the git version again
<zyga> store bug?
<mvo> zyga: so you went from master (from friday) to 2.29.4.2 and then back to git and that seems to be not working
<mvo> zyga: I think more a problem with the snap-cron publish to edge thing
<mvo> zyga: what does `snap version` give you?
<mvo> zyga: i.e. which version is active right now?
<mvo> zyga: (sorry if you said this already)
<zyga> 2.29.4.2
<zyga> since all other versions are deactivated
<pstolowski> good morning!
<zyga> well
<zyga> 2.29.4.2+17.10
<zyga> so that is the vanilla packaged version
<mvo> zyga: so here is my theory: you started with 2.32~git, that generated a new auto-connect tasks, then it installed core 2.29.4.2 because of silliness, then that rebooted and tried to do the tasks that are in the state
<mvo> zyga: however 2.29.4.2 does not know about auto-conneect so its stuck in doing
<zyga> didn't we have an unknown task handler now?
<zyga> maybe not in 2.29
<mvo> zyga: exactly, not in 2.29
<mvo> zyga: fortunately its only people tracking edge that are affected and the change will be auto-abort after 7(?) days
<mvo> zyga: still not great
<zyga> do we keep track of the edge publishing cron job
<zyga> to ensure this was really it?
<mvo> zyga: I think so, we have the spread-cron logs for vendor-sync and the ppa upload history and the core build logs
<zyga> btw, off-topic: I will have some fixes to layouts
<zyga> can we do another RC?
<mvo> zyga: yes
<zyga> this will make them work on core
<zyga> excellent
<zyga> I will have two or three patches
<zyga> just running spread to make sure it's green before I start chopping
<zyga> wow
<zyga> mvo I aborted change 54 and instantly I got a change 66 that refreshed core correctly
<zyga> I'm tracking edge again now
<mvo> zyga: sounds good, either a 2.32 targeted PR or make the PR with as little commits as possible so that we/i/you can cherry-pick
<mvo> zyga: thanks for confirming, so it will auto-heal
<zyga> those will be separate for review and because they are not related; each one should be ok to cherry-pick
<kalikiana> moin moin
<zyga> hey kalikiana
<zyga> woot :)
<zyga> it passed :)
<mup> PR snapd#4740 opened: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Created by zyga> <https://github.com/snapcore/snapd/pull/4740>
<zyga> mvo 1st PR: https://github.com/snapcore/snapd/pull/4740/files
<mup> PR #4740: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Created by zyga> <https://github.com/snapcore/snapd/pull/4740>
<zyga> mvo 2nd PR: https://github.com/snapcore/snapd/pull/4741/files
<mup> PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4741>
<zyga> once those land the spread test should pass
<mup> PR snapd#4741 opened: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Created by zyga> <https://github.com/snapcore/snapd/pull/4741>
 * zyga -> breakfast
<Chipaca> morning!
<zyga> hey
<zyga> I saw your PR last night
<Chipaca> zyga: which of 'em?
<Chipaca> it's been a fun weekend :-)
<zyga> the one on sunday night
<zyga> anyway, I will go over PRs soon
<zyga> but some 2.32 things first
<pedronis> mvo: hi, thinking a bit, in 2.32 we should probably not  ask for snap_yaml_raw on snap find/store.Find
<mvo> pedronis: ok, what is the alternative we should use?
<pedronis> mvo: ?
<mvo> pedronis: we need the plugs to get the default provider
<mvo> pedronis: we use snap_yaml_raw to get that data
<pedronis> mvo: I'm saying we should ask for details
<pedronis> but not find
<mvo> pedronis: oh, on find? yes
<mvo> pedronis: that sounds sensible
<pedronis> mvo: we don't use it
<pedronis> afaict
<pedronis> on find
<Chipaca>                    oooh, oohh
<Chipaca> can i work on that?
<pedronis> is just that fields is the same for all
<Chipaca> :-)
<pedronis> atm
<Chipaca> i've been wanting to make fields per request
<pedronis> Chipaca: yes, please, as I said, something we can still add to 2.32 though
<Chipaca> 2.32 is _right now_, no?
<pedronis> yes
<Chipaca> ok
<pedronis> but I suspect we neeld .x
<Chipaca> (btw, if you guys haven't tried the Go (mono) font, you should)
<mvo> Chipaca: yeah, please do! we are at 2.32~pre1 so as long as it can be cherry picked all is well
<palasso> Hello, I'm a bit confused about something. Are the channel risks 4 (stable, candidate, beta, edge) or can there be more?
<Chipaca> palasso: the risks are those four
<palasso> https://forum.snapcraft.io/t/channels-2-0-implementation/156
<palasso> "This allow publishers to go beyond the current 4 channels we offer and provide custom channels."
<Chipaca> palasso: risks != channels
<Chipaca> palasso: a channel is track/risk[/branch]
<palasso> So the channels go beyond in the sense of having tracks and branches?
<Chipaca> palasso: with a default track of 'latest'
<Chipaca> palasso: I think I've been in the 'new' channels world for too long and I don't remember well being where you are, but I'll try
<Chipaca> palasso: we used to have just four channels, representing risk levels
<Chipaca> palasso: what used to be just 'stable', is now fully called latest/stable
<Chipaca> palasso: (although we'll still call it just stable, because the latest/ is implied)
<Chipaca> palasso: and, devs can ask for more "tracks", which is the 'latest' bit
<palasso> Ahh I see
<Chipaca> palasso: if you do Â«snap info goÂ» you'll see a good example
<palasso> Chipaca: If an app were to have an "LTS" stable release (e.g. firefox has ESR) how would they do it under the current 4 risks model? they'd introduce an ESR/stable?
<Chipaca> palasso: yes, or if there are going to be multiple ESRs (like Ubuntu has multiple supported LTSs), they could call it something more specific
<Chipaca> palasso: or have both, a generic ESR that tracks the latest ESR, and a more specific ESR-x-y-z
<palasso> I see, thank you :)
<Chipaca> palasso: the mysql snap also makes good use of tracks
<pedronis> that's why tracks were introduced,  to support parallel streams of maintained releases
<palasso> Okay I'll check out go and mysql. Thank you for providing me examples as well
<Chipaca> palasso: a bad example of a snap is if you have a commercial and a free version, you shouldn't really use tracks for one and t'other
<Chipaca> s/bad example of a snap/bad example of a use of tracks for a snap/
<palasso> Yeah I've noticed for example how JetBrains does it
<Chipaca> k
 * Chipaca gets back to codin'
<Chipaca> mvo: I was meant to write a forum topic before that current pr got merged
<Chipaca> :-)
 * Chipaca writes
<Chipaca> also! mvo, pedronis, zyga, (mborzecki, pstolowski?), niemeyer, feedback appreciated on the 'debugging tab completion' tutorialish thing
<zyga> Chipaca where can we read it?
<Chipaca> https://forum.snapcraft.io/t/debugging-tab-completion/4198
<mup> PR snapd#4730 closed: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4730>
<Chipaca> mvo: #4737 isn't going to sneak into 2.32, right?
<mup> PR #4737: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4737>
<Chipaca> ie it's 2.33 material, which is not for another month/
<Chipaca> ?
<mvo> Chipaca: if there is a compelling reason we can cherry pick it
<mvo> Chipaca: its still early in 2.32
<Chipaca> mvo: on the contrary, I want it _not_ in 2.32
<Chipaca> mvo: to give people more forewarning of the change
<Chipaca> mvo: am I right in guesstimating 2.33 is a month away?
<Chipaca> from hitting stable
<Chipaca> or is it a month from release, and another month to stable?
<mborzecki> zyga: pstolowski: can give #4695 another pass?
<mup> PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
<zyga> yes, in a moment
<mborzecki> great, thanks
<pedronis> Chipaca: it should go to beta around when 2.32 goes to stable (roadmap says mar 12), but we still have things for 18.04 that are not in 2.32, not sure how that will play on 2.33 timing
<Chipaca> pedronis: mar12 is right after the sprint
<Chipaca> that seems to be setting us up for insanity
<Chipaca> let's not do that :-)
<pedronis> do what?
<Chipaca> pedronis: set ourselves up for insanity
 * pedronis expects Mar to be insane
<pstolowski> mborzecki, sure, sorry i didn't do that last Fri, will do
<zyga> I need two reviews for critical PRs
<Chipaca> zyga: shout
<zyga> last two open PRs
<zyga> one trivial
<zyga> one more complex
<zyga> 4740 is trivial
<mup> PR snapd#4728 closed: store: move infoFromRemote into details.go close to snapDetails <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4728>
<Chipaca> zyga: you're going to need el jay-dee to look at 4741 i think
<Chipaca> zyga: am I reading it right that with this change we _always_ use detach?
<zyga> for directories, yes
<zyga> for files we keep the regular thing
<Chipaca> zyga: is that reasonable?
<zyga> yes, as the commit message explains we have no other choice
<Chipaca> i guess we don't record when we recursed?
<zyga> no no, we always pair recurse with detach
<zyga> we don't always detach
<Chipaca> ah ok
<zyga> or am I missing something
<mvo> Chipaca: yeah, 2.33 is about a month away
<zyga> I mean, that is the intent
<Chipaca> zyga: https://github.com/snapcore/snapd/pull/4741/files#diff-4480ffd44957efa3395867c929f88014L377
<mup> PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4741>
<Chipaca> zyga: that's the bit that looked very unconditional
<Chipaca> but i might be missing part of the logic
<zyga> that's the safe keeping directory
<zyga> it is originally rbind'ed
<zyga> each rbind should be paired with MNT_DETACH
<Chipaca> k
<zyga> https://github.com/snapcore/snapd/pull/4741/files#diff-4480ffd44957efa3395867c929f88014L331
<Chipaca> heh, and pedronis agrees from backstage
<mborzecki> 'backstage' ;)
<Chipaca> 'bambalinas' translates as that, but it doesn't feel the same
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> hmm?
<Chipaca> it's used as 'behind the scene' more than 'backstage', i guess, although those two are the same (but different)
<Chipaca> zyga: he quietly added jdstrand as reviewer of the PR
<zyga> oh I would definitely have jamie review it
<pedronis> stage are scenes but not all scenes are stages
<zyga> I said so last week
<Chipaca> zyga: but who listens to you
<Chipaca> pedronis: translating is hard
<mup> PR snapd#4740 closed: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4740>
<zyga> mvo any idea why snapd-control-with-manage consistently failed in your PR?
<zyga> https://api.travis-ci.org/v3/job/346163312/log.txt
<zyga> this is inside 4739
<mvo> zyga: let me check
<mvo> zyga: yes, let me fix it
<zyga> do you know what happened there?
<mvo> zyga: yes, a leftover that checked for snapd.refresh in a test
<mvo> zyga: I killed that and force pushed (for cherry-picking)
<zyga> cool, thanks!
<mborzecki> mvo: https://paste.ubuntu.com/p/4y6jghpWQz/ maybe you're missing this
<mborzecki> mvo: I did those changes on Friday but didn't open a PR yet :)
<mvo> mborzecki: yes, except for the first bit :) -  echo 'from the store start/enable the snapd.service' is still needed, right? or will it be enabled (snapd.service) on arch on install?
<mvo> mborzecki: if so I can kill it
<mvo> mborzecki: that line
<mborzecki> mvo: you can kill it to
<mvo> mborzecki: cool
<mborzecki> mvo: there's one peculiar scenario with the timers that I mentioned here https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/20
<mborzecki> not sure if anyone uses it like this, but if you only have snapd.socket enabled, then snapd will not run unless something activates it, and if so, no refreshes will be applied
<mvo> mborzecki: are you sure it can be removed? the current install says "to use snapd start/enable the snapd.socket" but that means that on the next reboot snapd will only come up after "snap list" (or similar). so to get refreshes the user still has to enable the snapd.service so that it runs persistently? or am I missing something
<mborzecki> mvo: yes, that PKGBUILD is not used and i'll be syncing it with the one that's in the AUR repo
 * Chipaca -> break (physio)
<mborzecki> mvo: that echo was removed there as well
<mvo> mborzecki: aha, I think we are on the same page. so we should keep the message about "systemctl start/enable snapd.service" ?
<mborzecki> mvo: you can keep it for now
<mvo> mborzecki: I mean, we should contribute that back to upstream (this echo?)
<mvo> mborzecki: ok
<mborzecki> zyga: pushed an update to 4695
<zyga> ack
<mborzecki> mvo: what do you think about the case when only socket activation is enabled?
<mvo> mborzecki: a good question, I think its an unsupported mode of operation, we should advice our packagers to recommend to enable the service. and if its not done, well
<mvo> not much we can do - we could warn of course
<mup> PR snapd#4727 closed: many: simplify mocking of home-on-NFS <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4727>
<mborzecki> a bit crazy, but i thought we could do something like the timer services, autogenerate snapd.refresh.timer and have `snap refresh --timer='...'`
<pedronis> we have a bunch of extra logic around refreshes
<pedronis> we retry to some extent if they fail (but waiting at least some time)
<mborzecki> pedronis: right, but it only works as long as snapd is running, whereas if you do socket activation only then it may not be running at all
<pedronis> mborzecki: my point is more that implementing that way add different complexity to support an unsupported mode
<mborzecki> pedronis: aah, you're right, maybe it's not worth doing this at all
<pstolowski> mborzecki, my comment re systemd-analyze was about making sure we run this check on predefined systems (similiar to what we do in some spread tests) and not just rely on path lookup
<pstolowski> mborzecki, but I'm not sure how to do that nicely and if it's worth it. just 'nice to have'
<pstolowski> otherwise we have no guarantee we run this validation at all
<mborzecki> pstolowski: we could fail the test if systemd-analyze is not found, but that seems a bit overager
<mborzecki> s/overager/overeager/
<pstolowski> mborzecki, maybe just a warning that the check was disabled?
<mup> PR snapcraft#1949 closed: repo: silence deb caching when fetching packages <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1949>
<mborzecki> pstolowski: yeah, warning will probably do
<mup> PR snapd#4742 opened: overlord/snapstate: verify that default schedule is randomized and is  not a single time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4742>
<mborzecki> so that we don't accidentally break the store again ^^
 * cachio afk
<zyga> jdstrand hey, please have a look at 4714
<zyga> jdstrand I think it can land for 2.32 cherry-pick then
<zyga> (though it might be a bigger pick)
<zyga> jdstrand please also look at a layout bugfix in 4741
<zyga> jdstrand with that in the spread test in 4644 passes
<zyga> ok, now for a tiny break and then back to mount validation
 * zyga FAIL: store_asserts_test.go:161: storeSuite.TestCheckAuthority
 * zyga store_asserts_test.go:180:
 * zyga     c.Assert(err, ErrorMatches, `store assertion "store1" is not signed by a directly trusted authority: other`)
 * zyga ... error string = "store assertion timestamp outside of signing key validity (key valid since \"2018-02-26 10:45:06 +0000 UTC\")"
 * zyga ... regex string = "store assertion \"store1\" is not signed by a directly trusted authority: other"
<zyga> this popped up on an unrelated PR
<zyga> pedronis ^
<zyga> the PR is 4739
<mborzecki> zyga: seen it a couple of times already
<mborzecki> hmm the tst suite setup is using time.Now().Truncate(time.Second), while respective tests just do time.Now().Format(...)
<mborzecki> zyga: are you updating those tests?
<zyga> nope, go ahead please
<zyga> I'm still trying to finish the race detector
<mup> PR snapd#4742 closed: overlord/snapstate: verify that default schedule is randomized and is  not a single time <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4742>
<mborzecki> mvo: can you publish 2.31.1 release files on github?
<mvo> mborzecki: sure, done
<mup> PR snapcraft#1955 closed: meta: make sure adapter does not propagate <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1955>
<mborzecki> mvo: thanks
<mup> PR snapcraft#1844 closed: Included fix for error messages <codein> <Created by Tanesh1701> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1844>
<zyga> mborzecki having read https://www.freedesktop.org/software/systemd/man/systemd.time.html I really think syntax is hard
<mborzecki> zyga: ours or theirs?
<zyga> theirs
<mborzecki> zyga: yeah agreed, feels slightly awkward, on top of this, the entries OnCalendar, OnFoo.. are cumulative
<mborzecki> don't recall if that's mentioned int he manuals or not
<pedronis> zyga: might be related to the test renames, some tests that worked because of order, IÂ will look
<mup> PR snapd#4743 opened: packaging/arch: sync with snapd/snapd-git from AUR <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4743>
<mup> PR snapd#4744 opened: testutil: allow mocking syscall.Fstat <Created by zyga> <https://github.com/snapcore/snapd/pull/4744>
<mup> PR snapd#4745 opened: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745>
<mup> PR snapd#4746 opened: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink <Created by zyga> <https://github.com/snapcore/snapd/pull/4746>
<mup> PR snapd#4747 opened: cmd/snap-update-ns: use recursive bind mounts for writable mimic (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4747>
<zyga_> mvo I opened two PRs for 2.32 backport for overlay fixes
<zyga> er, not overlay, layout
<mvo> zyga: ta
 * pstolowski lunch
 * zyga needs to go out to do some errands, I'll be back later
<mup> PR snapcraft#1959 opened: elf: only patch elf files that aren't referenced by DT_NEEDED <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/1959>
<cachio> mvo, already running beta validation
<cachio> hello
<mvo> cachio: good morning
<mvo> cachio: thank you
<mvo> cachio: how are things looking so far?
 * kalikiana food
<cachio> mvo, about sru, is it ready to run the validation?
<mvo> cachio: yes
<cachio> ok, I'll start it
<zyga> re :)
<zyga> man it is *cold* outside
<zyga> like really cold
<zyga> I need warmer pants
<zyga> jdstrand so looking at your response
<zyga> apart from updating comments, do you want to see any other changes?
<zyga> my main motivation for that is not having to chagne a lot of the algorithms behind the current process
<mup> PR snapcraft#1746 closed: cli: add version command <bug> <Created by gsilvapt> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1746>
<Chipaca> zyga: I've got something to warm the cockles of your heart
<zyga> as we don't have to know what is currently mounted (via mountinfo) to get things correct
<zyga> we only act on fstab delta
<Chipaca> zyga: not as good as warm trousers, but https://pastebin.ubuntu.com/p/nd67wh7p3x/
<jdstrand> zyga: just the comment change, but that was based on your answer
<zyga> Chipaca ohh
<zyga> I like the raw sys call thing
<zyga> I need to do that anyway
<zyga> cool, let me update the comment then
<Chipaca> pedronis: can you think of other fields that'd only be used for details?
<pedronis> Chipaca: not without being backward incompatible
<pedronis> Chipaca: we return most feilds through the rest api, no?
<pedronis> IÂ mean snap list doesn't use all them
<pedronis> but in the api they are there
<Chipaca> pedronis: well, I'll stop asking for the channel map (but we weren't getting it anyway)
<jdstrand> zyga: can you re-review PR 4714 when you get a chance? the test failure was unrelated. I restarted travis
<mup> PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
<pedronis> Chipaca: in search
<zyga> jdstrand yes, sure
<zyga> jdstrand btw, I merged master into it today
<zyga> did you see that?
<pedronis> Chipaca: that's ok
<Chipaca> pedronis: yep
<zyga> ah, you did
<Chipaca> bah, maybe i'm going too meta
<zyga> cool, lookin g
<Chipaca> and i should make it simpler
<Chipaca> hmmm
<Chipaca> especially if we're going to throw this away for v++
<Chipaca> yeah, screw it
<pedronis> Chipaca: the old code is complicated mostly for tests
 * Chipaca git revert's
<zyga> oh
<zyga> so I learned something today :)
<Chipaca> zyga: ?
<pedronis> Chipaca: new api is diferent, also I'm also testing it differently
<Chipaca> pedronis: good :-)
<pedronis> Chipaca: I'm testing the equivalent of infoFromRemote which we didn't
<Chipaca> pedronis: if it were the same i'd start asking if we learned nothing :-)
<pedronis> and makes for verbose tests
<pedronis> for everything
<zyga> jdstrand so to understand this correctly, if the upperdir has space we need quoting to make that work?
<Chipaca> pedronis: are you using detailFields for anything?
<zyga> and with that, brb, I'll make some tea, it's sooo cold today
<jdstrand> zyga: yes, the parser will not like it
<pedronis> Chipaca: no, a have a different list
<pedronis> s/a have/I have/
<pedronis> that is a global
<pedronis> not coming from config
<pedronis> and many fields have new names or are grouped in the new api
<pedronis> Chipaca: you can hardcode stuff, if you can keep the tests happy
<Chipaca> pedronis: yup
<Chipaca> pedronis: resisting the temptation of kaizen
<Chipaca> for this one
<Chipaca> must . resist .
<jdstrand> roadmr: hey, fyi, the store is occasionally oopsing when adding feedback
<pedronis> mvo:  I'm getting this:  overlord/ifacestate/handlers.go:580: github.com/snapcore/snapd/overlord/state.Retry composite literal uses unkeyed fields from go vet here
<roadmr> jdstrand: got an oops id for me?
<jdstrand> OOPS ID: OOPS-612e03a3abfe4e63b67bd58b51731171
<roadmr> thanks!
<zyga> jdstrand (re, suspended) - does our live media use whitespace in upperdir?
<jdstrand> roadmr: that was putting in the text and doing 'Ask for information'
<jdstrand> roadmr: there was another when I went to the feedback url that oops. I lost that oppsid
<jdstrand> zyga: no
<roadmr> jdstrand: oh I see. It's trouble contacting rabbitmq (the thing you're doing presumably uses a celery task)
<zyga> jdstrand so what triggered the use of " ", the fact that it is possible?
<jdstrand> zyga: the idea is simple-- we are getting something from outside of snappy and injecting it into policy
<zyga> right
<roadmr> jdstrand: and this is in turn because at least one of our rabbitmq units was rebooted for upgrade purposes
<zyga> just wanted to understand that bit
<jdstrand> zyga: so yes, being cautious. we didn't need it when the policy was hard-coded before, but now we are detecting, so I am being defensive
<jdstrand> roadmr: does that mean it is temporary?
<roadmr> jdstrand: yes, checking current status of rabbit
<nathancahill> Have some odd behavior with Ubuntu Core (on Docker) vs Ubuntu Desktop
<nathancahill> Fonts aren't being loaded from the file:// protocol in Firefox on Ubuntu Core
<nathancahill> Works fine on Ubuntu Desktop though. Also works fine if they are served via http
<Chipaca> nathancahill: so you've got Firefox, on X? mir? wayland?, on ubuntu core, on docker, and it's not loading fonts from file:///
<Chipaca> nathancahill: ?
<nathancahill> firefox headless (latest build supports running headless with no display server)
<Chipaca> nice
<nathancahill> yeah, it's really slick
<roadmr> jdstrand: things look healthy here, can you retry those things you were doing?
<zyga> jdstrand does https://github.com/snapcore/snapd/pull/4741/commits/8169900842c19cb09cb9510bdbafb4e8ca61554e look all right now?
<mup> PR #4741: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/4741>
<nathancahill> can't figure out the exact different between the ubuntu snap build and ubuntu desktop that's causing the issue though
<nathancahill> i installed ubuntu-server and ubuntu-desktop on top of ubuntu:latest and the issue persists
<zyga> Chipaca as to your pastebin
<zyga> Chipaca is that string zero terminated?
<zyga> I don't think it is in that way you wrote it
<zyga> Pharaoh_Atem hey, what do I need to reproduce the problem
<zyga> is F27 sufficient or do I need F28?
<Pharaoh_Atem> zyga: you need F28
<zyga> ah, thanks, I will update then
<zyga> jdstrand if you ack that patch I will also push it into the 2.31 PR
<zyga> er
<zyga> 2.32
<Chipaca> zyga: yes
<Chipaca> #fingerscrossed
<Chipaca> :-)
<Chipaca> zyga: I haven't checked why, but it works like that, so yeah
<zyga> you need something ...
<zyga> like...
<Chipaca> zyga: to actually do that kind of thing, I'd suggest checking (or enforcing) :-)
<jdstrand> roadmr: I tried a couple more, it seems fine now
<roadmr> jdstrand: yay thanks!
<zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/bootstrap.go#L96
<jdstrand> zyga: approved, thanks
<zyga> woot, thank you
 * Chipaca looks around for mvo
<zyga> Chipaca he went for hockey
<mup> PR snapd#4744 closed: testutil: allow mocking syscall.Fstat <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4744>
<mup> PR snapd#4748 opened: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748>
<Chipaca> smart
<Chipaca> pedronis: ^
<pedronis> thx, will look in a bit
 * zyga installs more ram
<pedronis> Chipaca: one comment
<Chipaca> pedronis: I could rename the function to `getStructFieldsExceptSnapYAML`
<pedronis> Chipaca: still strange
<Chipaca> pedronis: what I'd been doing before reverting everything was having another tag
<pedronis> that is overkill
<Chipaca> e.g. only:"SnapInfo"
<pedronis> though
<Chipaca> pedronis: getStructFields(theStruct, anException) and it skips just that tag?
<Chipaca> even a list there feels silly :-)
<pedronis> it can be a list, no?
<Chipaca> I mean, it can, but we're only going to use it for one
<pedronis> we have strings.ListContains
<Chipaca> and we're calling this thing for every request (which is stoopid)
<Chipaca> ah wait
<pedronis> are we?
<Chipaca> no
<Chipaca> no ,not the getStructFields
<pedronis> I hope not
<Chipaca> ok, fair
<Chipaca> doing the change
<pedronis> Chipaca: in case this is annoying, I'm using getStructFields in the new code
<Chipaca> pedronis: ah, then it's fine
<pedronis> that's why the hard coded old style field is a bit strange
<Chipaca> yeah, i thought getStructField was done for
<Chipaca> ok
<pedronis> it seems useful, to not forget field
<pedronis> s
<Chipaca> pedronis: one change I'd like to make, which might be silly, is to change it to take a pointer to a struct instead of a struct
<pedronis> that's fine
<Chipaca> pedronis: ok, i'll do that in a separate pr then
<zyga> mvo oooh
<zyga> I just ran "htop"
<zyga> and got the c-n-f thing :)
<zyga> snap htop or deb htop
<pedronis> Chipaca: also IÂ suppose the exceptions can  be  ...string
<zyga> what I'm missing is install instructions, we used to have those
<Chipaca> pedronis: way ahead of you
<pedronis> :)
 * zyga doubled ram in his thinkpad for peanuts :)
<Chipaca> zyga: why do you have a thinkpad for peanuts
<Chipaca> zyga: that thing must be tiny
<zyga> haha
<zyga> I made a good deal
<zyga> sold the x250, got t470
<zyga> got money left
<zyga> now at twice the ram
<mup> PR snapd#4749 opened: ifacestate: be consistent passing Retry.After as named field <Created by pedronis> <https://github.com/snapcore/snapd/pull/4749>
<pedronis> ^ trivial  (also makes my local go vet happy)
<r4co0n> Hi, I have a seemingly simple problem: I got an archive (mysql dependency boost) that's supposed to be in directory /boost during build of my snap. the archive contains itself a directy boost, which should become /boost/boost, however, I can't figure out how to make the dump plugin do that.
<r4co0n> I managed to make snapcraft get locked in 'Staging' by stating to organize 'boost' to 'boost/boost' and '*' to 'boost/'
<Chipaca> pedronis: and 4750 is a silly tweak to it'
<r4co0n> No, now it failed, with an error stating boost/boost/boost/boost/...
<Chipaca> r4co0n: boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/boost/
<Chipaca> r4co0n: boost/boost/?
<Chipaca> :-p
<Chipaca> r4co0n: don't do that :-D
<mup> PR snapd#4750 opened: store: getStructFields now take pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4750>
<Chipaca> r4co0n: I mean, you can't put a booster on your booster to booster your booster
<Chipaca> ok, i'll stop now
<Chipaca> but it is funny :-)
 * Chipaca wraps up his day and goes to get dinner ready for the hoard
<r4co0n> I just want a way to tell snapcraft to put everything in the dump source to a specific path.
<r4co0n> my problem is, the path is existing in the source, hence everything at that location won't get moved by: "'*': /subdirectory"
<r4co0n> It did get moved by the same "copy" command, that I'm trying to rewrite
<nacc> r4co0n: you shouldn't be using absolute paths anyways, right?
<zyga> jdstrand +1 to merge (2.32 copy of) https://github.com/snapcore/snapd/pull/4747
<mup> PR #4747: cmd/snap-update-ns: use recursive bind mounts for writable mimic (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/4747>
<r4co0n> I'm not, it's just a habit...
<mup> PR snapd#4746 closed: cmd/snap-update-ns: use syscall.Symlink instead of os.Symlink (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4746>
<nacc> r4co0n: oh ok
<r4co0n> https://paste.debian.net/hidden/c6f9fd43/
<r4co0n> This is my snap/snapcraft.yaml
<nacc> r4co0n: it doesn't make sense
<nacc> r4co0n: * will include banana/
<nacc> r4co0n: i think you would need to specify everything except for banana itself
<r4co0n> I got only banana/banana/peach in there
<nacc> r4co0n: or use filesets?
<r4co0n> Isn't there something like a parent directory for dump
<r4co0n> Like, dump everything under this location...
<nacc> r4co0n: well, why are you doing both?
<nacc> r4co0n: i mean, if you wante veryting under banana/ just do the '*: banana/' ?
<nacc> r4co0n: not sure why you'd move banana itself then do something else
<r4co0n> That executes a move which will leave banana/peach as banana/peach, not banana/banana/peach
<r4co0n> I want boost to be at /boost, but I dont want boost/boost/funnyexecutable to be at boost/funnyexecutable
<nacc> r4co0n: then do two parts
<nacc> r4co0n: with different organize lines?
<r4co0n> Like, extract the same archive twice?
<r4co0n> Two dumps?
<r4co0n> https://github.com/nextcloud/nextcloud-snap/blob/master/snap/snapcraft.yaml#L239
<r4co0n> That's the part I want to rewrite with dump
<r4co0n> This tarball contains a folder /boost
<r4co0n> I think I need a good reason to split up building this build dependency of a dependency
<nacc> r4co0n: why can't you do exactly what that yaml does?
<r4co0n> How?
<nacc> r4co0n: does that yaml not work (i know copy is deprecated)
<r4co0n> If I change file for organize and copy for dump, it doesn't work
<nacc> r4co0n: well, right, becuase they aren't synonyms
<r4co0n> I tried lots of ways and ended up with a DOS for snapcraft
<nacc> r4co0n: to be clear, if all you need is the boost headers, then just grab the boost headers
<nacc> r4co0n: don't grab the whole thing
<nacc> r4co0n: so yes, you'd have two parts
<nacc> r4co0n: one is 'boost_headers' and one is 'the rest of the boost tarball' (if you need it); afaict, that particular yaml doesn't need the second
<mup> PR snapd#4741 closed: cmd/snap-update-ns: use recursive bind mounts for writable mimic <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4741>
<r4co0n> mysql looks for boost during build, I don't know which files it checks under /boost ...
<nacc> r4co0n: i'm not sure why that's relevant
<nacc> r4co0n: perhaps you misunderstand what that part is trying to do?
<r4co0n> You say I only need the headers
<nacc> r4co0n: it's taking a tarball and extracting just some part of it
<nacc> r4co0n: if you want to do the same thing, just ... do the same thing?
<r4co0n> it's extracting everything, to /boost
<r4co0n> I want to replicate that
<r4co0n> that's not possible because the tarball contains boost/, which doesn't get moved to boost/boost/
<r4co0n> But if you say I only need some headers ouf of that anyways, I'm open for another solution...
<r4co0n> Ideally a single command
<nacc> r4co0n: sorry, i misunderstood
<r4co0n> nacc, np, thank you for trying to help :)
<mup> PR snapd#4747 closed: cmd/snap-update-ns: use recursive bind mounts for writable mimic (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4747>
<zyga> 4644 will now get green :)
<nathancahill> fyi, resolved that firefox issue. loading via the file protocol from / instead of a subdirectoy was causing an issue with sandboxing in firefox
<r4co0n> If nobody has any idea how to solve my issue, I will open a bug so it doesn't pass unhandled.
<mup> PR snapd#4749 closed: ifacestate: be consistent passing Retry.After as named field <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4749>
<jdstrand> niemeyer: hey, I'm still not sure what to do with 'software-boutique'. I saw your answer, and I see that you intend for it to not be 'ubuntu-software-boutique', but I don't see an explicit ack for it to be classic as 'software-boutique' (maybe I missed it?) or criteria that should be applied to snaps that are like software-boutique or gnome-software
 * zyga fiddles thumbs while travis picks up 4644
<zyga> jdstrand it will be green and all I can do is wait :)
<jdstrand> niemeyer: maybe you didn't mean for software-boutique to fall under this category and have it be a separate category?
<jdstrand> niemeyer: if you can say +1 classic with the reasoning that is all I need. if you have additional criteria for gnome-software/software-boutique snaps, then I can incorporate it into our process
<jdstrand> zyga: yeah
<zyga> jdstrand wanna +1 a trivial helper PR? https://github.com/snapcore/snapd/pull/4745/files
<mup> PR #4745: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745>
<mup> PR snapcraft#1960 opened:  extractors: add support for common-id  <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1960>
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Earlier today I've responded to your questions in the forum.. have you seen that?
<elopio> matiasb: there seems to be a bug on the reviewer tools : The store was unable to accept this snap.
<elopio>   - 'common-id' must be used with 'daemon'
<elopio> y
<elopio> matiasb: that shouldn't be limited to daemons.
<matiasb> elopio, o/ makes sense to me, I didn't set that restriction :)
<jdstrand> niemeyer: yes, this was in response to that
<matiasb> jdstrand, fyi ^? (re common-id)
<jdstrand> let me double check
<jdstrand> matiasb: ack
<jdstrand> elopio: what snap?
<jdstrand> I can manually approve
<jdstrand> niemeyer: I think you're saying all the criteria was for welcome snaps (fine), but I don't see any criteria for gnome-software/software-boutique snaps and/or an ack for software-boutique as classic
<jdstrand> maybe I missed something
<niemeyer> jdstrand: Ah, sorry, I was the one misunderstanding your question now
<jdstrand> niemeyer: no worries, I thought it might go that way so opted for realtime :)
<niemeyer> jdstrand: Is software boutique just a fork of gnome-software?
<jdstrand> niemeyer: I don't know tbh. flexiondotorg could say for sure. what I know about it is that it used AptDaemon dbus apis for adding ppas and installing software
<jdstrand> niemeyer: I was under the impression it is its own thing
<jdstrand> so it is gnome-software like, but I think different
<flexiondotorg> niemeyer jdstrand No, software-boutique is a from scratch "software center".
<jdstrand> there we go
<jdstrand> flexiondotorg: thanks
<elopio> jdstrand: I was just running a test, no need to approve it.
<niemeyer> flexiondotorg: Aha, okay.. hmm
<flexiondotorg> Original part of Ubuntu MATE Welcome, but now decoupled.
<jdstrand> elopio: can you paste your snap.yaml?
<niemeyer> jdstrand: I think we can use the same rationale we used for the welcome tool.. if it is something that a given distribution wants its own users to have access to, and there's a real community behind it to justify the risk of such a classic snap in the store, then it sounds reasonable
<flexiondotorg> niemeyer: Thanks :-) And as jdstrand says, I very keen to see if we can confine both in the longer term.
<niemeyer> jdstrand: Also the fact it's interactive instead of a daemon that responds to external commands
<flexiondotorg> Perhaps a session for next week.
<jdstrand> niemeyer: that seems ok to me (in fact, I thought you were saying that all along, until today :) the question then is about criteria '3' -- prefixing with 'ubuntu' or not
<niemeyer> jdstrand: So that gives some rationale for why that's okay while someone trying to do apt management with their own small tool that responds to external activity is not
<jdstrand> niemeyer: flexiondotorg doesn't want that (for good reason); I don't mind it
<Usysem> Wht is the command to install OPEN-vpn snap ?
<niemeyer> jdstrand: Okay, that's the question I responded in the forum I think.. yes, I don't think that's sensible
<jdstrand> niemeyer: and if not, is that something I should try to capture in the process criteria or just something for this one snap
<niemeyer> jdstrand: The prefix suggestion was specifically to the welcome thing, because it's very closely bound to that one distribution
<jdstrand> ok
<jdstrand> case by case basis for others for now?
<Usysem> What is the command to install OPEN-vpn snap ?
<niemeyer> jdstrand: Yeah.. unless there are other foo-welcome things
<jdstrand> niemeyer: budgie has a welcome snap, so renamed to ubuntu-budgie-welcome, but they don't have a software-boutique like snap
<jdstrand> so we should be good for now
<niemeyer> Usysem: "snap find vpn" tells me about "easy-openvpn", so maybe that one?
<jdstrand> I'll take care of the approval and update the process docs slightly
<jdstrand> niemeyer: thanks!
<niemeyer> Usysem: Haven't tried it myself
<niemeyer> jdstrand: Thanks!
<Usysem> its not easy-openvpn - I've tried that & it doesn't show up in my menu, afterwards. Where is the simple OPEN-vpn ? and how do I install that snap ?
<zyga> jdstrand 4644 is green :DDD
<Usysem> hi - I need halp.
<zyga> Usysem then perhaps there is no such snap yet
<Usysem> there is . I installed it months ago - I jus forgot what its called. Can't find it on forum.
<Usysem> I reinstalled my system - so I am re-installing snaps.
<zyga> sorry, I don't know then
<Usysem> thanks.
<Pharaoh_Atem> flexiondotorg: how come sw-boutique is still using aptdaemon?
<Pharaoh_Atem> didn't it switch to pk months ago?
<jdstrand> niemeyer: fyi, left our process document the same but added a note: "Note that some âinstallerâ snaps (eg, gnome-software and software-boutique) are not distro-specific (eg, they work with any number of package backends) and therefore may not be required to be prefixed with <distro>-. This will be evaluated case by case using the above criteria as a starting point."
 * jdstrand fixes typos :)
<mup> PR snapd#4644 closed: tests: add a spread test for layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4644>
<jdstrand> zyga: are you planning on a PR for PR 4727 for 2.32? if not, it will make the 2.32 PR for 4714 more complicated
<mup> PR #4727: many: simplify mocking of home-on-NFS <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4727>
<jdstrand> PR 4714
<mup> PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
<jdstrand> zyga: also, I saw your comments wrt layouts-- remember, they were conditional in 2.32 provided that per-snap s-u-n profiles are in place
<mup> PR snapd#4751 opened: tests: add support for external backend executions on listing test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4751>
<niemeyer> jdstrand: Thanks!
<zyga>  jdstrand I can, though I think it will be a bit painful
<zyga> jdstrand I will look at that though
<zyga> jdstrand yes, I remember and I'll ensure there are hardening patches next
<mwhudson> does snapcraft have a way of verifying a source against a gpg signature?
<mwhudson> hm doesn't look like it
<mwhudson> should it? :)
<mup> PR snapcraft#1957 closed: schema: improve the snap name's validator <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1957>
<mup> PR snapd#4752 opened: tests: make interface-broadcom-asic-control test work on rpi <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4752>
<jdstrand> roadmr: hey, would you mind pulling r1007?
<roadmr> jdstrand: sure!
<jdstrand> roadmr: it isn't particularly time-sensitive
<roadmr> I don't mind, I mean :)
<jdstrand> cool :)
<roadmr> jdstrand: ok... we've been in the crapper with rollouts due to all the mitigation madness :(
<jdstrand> I bet
<roadmr> 1007 is in the queue, I'll finish merging it and QAing it tomorrow
<roadmr> (due to impending EOD)
<jdstrand> roadmr: thanks!
<mwhudson> does anyone have an example of triggering a jenkins job on a snap publication via webhooks?
<jdstrand> elopio, Chipaca: fyi, that request for a store pull of the review-tools has both your fixes
<jdstrand> ^
#snappy 2018-02-27
<niemeyer> jdstrand: A bit late, but just in case, are you around?
<niemeyer> jdstrand: It's not urgent
<mwhudson> 'libc6' is required inside the snap for this part to work properly.
<mwhudson> this particular part ships a single text file
<mwhudson> wat
<mwhudson> oh it's emitted for all parts if is_host_compatible_with_base is not true
<mwhudson> that's a bit broad :)
<niemeyer> mwhudson: Yeah, and also the idea of installing packages on the local machine to build.. we had a call today, and have a session in the sprint next week to discuss the future of snapcraft
<niemeyer> mwhudson: In this sense specifically.. we need significantly simpler and more consistent
<niemeyer> mwhudson: There are some good ideas in place already, in terms of building from within a container or image with shared access to the data
<niemeyer> mwhudson: We just need to be a bit more opinionated and have a single workflow that always works
<mwhudson> niemeyer: my use case is a bit strange because i need to include libraries from bionic
<mwhudson> (thanks systemd journal format non-stability)
<mwhudson> but yes
<niemeyer> mwhudson: That's not too strange.. part of the conversation is precisely making sure it works no matter what the target base is
<niemeyer> mwhudson: IOW, decoupling local host from build env
<mwhudson> i guess i really want to use a bionic base...
<niemeyer> Right
<niemeyer> We have one of those coming :)
<niemeyer> core18
<mwhudson> niemeyer: due around 18.04.1 time or did i get that wrong?
<mwhudson> "Files from the build host were migrated into the snap to satisfy dependencies that would otherwise not be met."
<mwhudson> would looove to know which files had these dependencies
<niemeyer> mwhudson: :)
<niemeyer> mwhudson: Yeah
<mwhudson> oh wow i have far too much in this snap :(
<pablo_> hi: i'm begginer with ubuntu core. Trying to add startup comand in rc.local but shell says "read only file syste". How can i solve this?
<pablo_> basically i want to automatically start a snap i built in startup
<nacc> pablo_: wouldn't that be done by shipping a daemon normally?
<pablo_> nacc: eh, this is the first snap i build and the tutorials did not helped me too much (or i'm too dumb to understand them). How could i build a daeomn snap?
<pablo_> nacc: thanks a lot for the answer btw! :)
<nacc> pablo_: https://docs.snapcraft.io/build-snaps/metadata
<nacc> pablo_: i think that hooks into systemd
<pablo_> nacc: so i add daeomn: simple and should start at startup?
<nacc> pablo_: i'm not sure, i've never done it, but that seems worth trying ;)
<pablo_> nacc: yes, i'm pakaging the snap right now. I'm worried cause my snap needs root privileges to change GPIO of my board. But if its hooks systemd it may work, doesn't it?
<nacc> pablo_: you might need to enable an interface, and connect to it, i don't know
<pablo_> didn't start at reboot :(
<mup> PR snapd#4753 opened: tests: fix dependency for ubuntu artful <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4753>
<nacc> pablo_: are you able to start it manually?
<pablo_> IT workied!!! i rebooted again and worked
<pablo_> thanks a lot nacc! for answering my noob question
<nacc> pablo_: not noob! it's a bit confusing
<chris062689> Good afternoon! I'm attempting to setup a snap package for Citra (3DS emulator) and was hoping I could work with someone with a bit more knowledge of how snap packages are developed? I'm really flying blind here... I've attempted to read the documentation on snapcraft.io but am still fumbling around quite a bit.
<pablo_> chris062689: yes, snapcraft doc is not useful for me either. I wrote a snap of a python script and to be honest, it was all try an error.
<pablo_> do you have a snapcrafst.yaml created so far? if you paste it in pastebin perhaps someone can help you
<chris062689> I'm slowly hacking away at it. I was just curious if I could partner with someone. If I'm still having trouble and at the end of my rope I'll paste it here :)
<mup> PR snapd#4754 opened: spread: start moving towards google backend <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4754>
<mup> PR snapd#4754 closed: spread: start moving towards google backend <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4754>
<mborzecki> morning
<zyga> good morning
<zyga> -14C now
<mborzecki> zyga: hey
<mborzecki> -17 here
<zyga> brrr :)
 * zyga goes for breakfast
<zyga> hey mvo
<mborzecki> zyga: check the build error in this PR https://github.com/snapcore/snapd/pull/4751 maybe it's of interest to you
<mup> PR #4751: tests: add support for external backend executions on listing test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4751>
<mborzecki> mvo: hey
<zyga> checking
<zyga> hmmmm
<zyga> no such file or directory...
<zyga> [Mon Feb 26 20:50:27 2018] audit: type=1400 audit(1519678227.940:302): apparmor="DENIED" operation="mount" info="Failed name lookup - deleted entry" error=-2 profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/etc/group" pid=13952 comm="3" flags="rw, bind"
<zyga> deleted entry
<zyga> so
<zyga> something killed that file form under us
<zyga> prepare/restore logic?
<mborzecki> but that's supposed to be run before/after the test right?
<zyga> yeah but we saw many times that there is something that definitely runs at the wrong time
<zyga> I don't know really
<zyga> what would delete /etc/group otherwise
<zyga> and note, we normally handle missing things just fine
<zyga> we stat and look
<zyga> and if missing create
<zyga> and only then we proceed to mount
<zyga> so before we stated and mounted something removed that
<mvo> mborzecki, zyga good morning!
<zyga> o/
<mborzecki> zyga: can you take another look at #4695? (sorry to be nagging you :)
<mup> PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
<zyga> yes, sorry for not sending feedback, I have it open all the time but I was checking if I understand the problem space and that took forever
<kalikiana> sliff
<pstolowski> morning!
<mvo> hey pstolowski ! good morning
<mborzecki> pstolowski: hey
<mup> PR snapd#4753 closed: tests: fix dependency for ubuntu artful <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4753>
<mup> Bug #1752031 opened: core `service.ssh.disable` key not taken into account <Snappy:New> <https://launchpad.net/bugs/1752031>
<Chipaca> on the subject of InstallDate, and using the timestamp from current vs the timestamp from MountDir
<Chipaca> I seem to remember that we went with current because it was a better indicator of when the thing was last refreshed to whatever is current
<Chipaca> however if not current, there'd be no install date -- meaning no refreshed in info
<Chipaca> I _could_ fall back to mountdir timestamp if there is no current
<Chipaca> how well would that work?
<Chipaca> (i think it'd work fairly well, but i might be missing something)
<zyga> my vote goes for simplicity
<Chipaca> (i could make a table of scenarios, but then people won't look at it)
<Chipaca> :-)
<zyga> just show what we know, not what we can make up (sort of)
<Chipaca> we know both these things, and both can be arguably called an install date, or a refreshed date
<Chipaca> and both are simple :-)
<zyga> my point is that I'd personally feel better if the information always came from one source
<Chipaca> if we use just one, the current timestamp is the right thing, as it's wrong less often (and when it would be wrong it's zero, which isn't printed)
<zyga> is this a temporary situation and over time we will always have the right data?
<Chipaca> that is the hope yes
<Chipaca> we'll be adding this to snapstate at some point
<mborzecki> anyone know a snap that places a *.desktop file under $SNAP_USER_DATA/.config/autostart?
<Chipaca> zyga: the plan (small p) is to have, in snapstate, something like {refreshed: <timestamp>, reverted: <...>, ...}, or maybe a short log [(refreshed, <>), (refreshed, <>), (reverted, <>), ...)
<zyga> log would be nice
<Chipaca> mborzecki: I don't expect there to be a lot, as it doesn't work
<zyga> mborzecki nope
<Chipaca> mborzecki: (there's a bug open for that)
<Chipaca> maybe on the bug?
<Chipaca> mborzecki: https://bugs.launchpad.net/snapd/+bug/1736926
<mup> Bug #1736926: No way to autostart a snap of a desktop application <snapd:Triaged> <https://launchpad.net/bugs/1736926>
<pedronis> Chipaca: the log would be truncated ?Â or just one entry per type, even if its' a log?
<Chipaca> pedronis: i'm making stuff up on the fly, but I imagine it'd be, say, 5 entries?
<Chipaca> i mean, all we're seeing immediate use for is the latest entry
<pedronis> Chipaca: well, keeping installed forever seems useful
<Chipaca> pedronis: as opposed to refreshed
<Chipaca> yes
<pedronis> that's when you introduced the snap into the system
<Chipaca> but reverted vs refreshed vs enabled/disabled are much the same imho
<Chipaca> so, well, something for this space :-)
<Chipaca> point is, yes zyga, temporary until we have proper data instead of inferences
<mborzecki> Chipaca: yeah, i'm working on that atm
<pedronis> zyga: IÂ think IÂ understand the problem with that storeSuite.TestCheckAuthority  test, otoh it's hard to reproduce the failure
<Chipaca> mborzecki: popey might be the person to ask then
<pedronis> I can propose something untested
<mborzecki> Chipaca: hah, good idea ;)
<Chipaca> mborzecki: but, is all the above a good enough answer for why the timestamp of current instead of of mountdir, wrt #4735?
<mup> PR #4735: daemon, snap: fix InstallDate, make a method of *snap.Info <Created by chipaca> <https://github.com/snapcore/snapd/pull/4735>
<Chipaca> pedronis: not this week -- i want to wrap snapshots
<Chipaca> pedronis: next week i hear we're going to be idle, so maybe then
<pedronis> Chipaca: ?
<Chipaca> <pedronis> I can propose something untested
<pedronis> Chipaca: that was about my comment to zyga about flaky test
<Chipaca> ah :-) ok
<Chipaca> too many threads
<pedronis> Chipaca: IÂ have a gazillion other things to do
<zyga> pedronis is it a test failure or a deeper bug?
<Chipaca> pedronis: i must admit i was a little surprised, but i thought you were itching for something simple to relax
<pedronis> zyga: it's a test failure
<mborzecki> Chipaca: mountdir timestap if no current seems fine, but then if you disable/enable that would 'alter' the installed date?
<pedronis> zyga: it's purely an order of stuff/timing issue, is just hard to reproduce here
<pedronis> zyga: the fix is swapping two lines
<pedronis> well two statements
<popey> Chipaca: mborzecki hmm?
<mborzecki> popey: do you know of a snap that tries to do autostart by dropping a desktop file under $SNAP_USER_DATA/.config/autostart?
<popey> mborzecki: yes, discord
<mborzecki> popey: thanks :)
<popey> https://www.irccloud.com/pastebin/YcIz40Cr/
<popey> I think it does that post first run, it ticks the box by default.
<mup> PR snapd#4755 opened: snap/squashfs: add BuildDate <Created by chipaca> <https://github.com/snapcore/snapd/pull/4755>
<mup> PR snapd#4756 opened: asserts: fix flaky storeSuite.TestCheckAuthority <Created by pedronis> <https://github.com/snapcore/snapd/pull/4756>
<pedronis> zyga: ^
<zyga> mborzecki have a look
<zyga> pedronis looking
<mup> PR snapd#4756 closed: asserts: fix flaky storeSuite.TestCheckAuthority <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4756>
<mup> PR # closed: snapd#3963, snapd#3998, snapd#4285, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4486, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4597, snapd#4600,
<mup> snapd#4639, snapd#4672, snapd#4682, snapd#4695, snapd#4696, snapd#4700, snapd#4714, snapd#4720, snapd#4721, snapd#4723, snapd#4725, snapd#4735, snapd#4738, snapd#4739, snapd#4743, snapd#4745, snapd#4748, snapd#4750, snapd#4751, snapd#4752, snapd#4755
<Chipaca> ooooh, github is dead
<zyga> oh, what's wrong mup?
<mup> PR # opened: snapd#3963, snapd#3998, snapd#4285, snapd#4349, snapd#4358, snapd#4369, snapd#4387, snapd#4399, snapd#4416, snapd#4443, snapd#4486, snapd#4497, snapd#4504, snapd#4509, snapd#4510, snapd#4545, snapd#4551, snapd#4562, snapd#4571, snapd#4578, snapd#4588, snapd#4597, snapd#4600,
<mup> snapd#4639, snapd#4672, snapd#4682, snapd#4695, snapd#4696, snapd#4700, snapd#4714, snapd#4720, snapd#4721, snapd#4723, snapd#4725, snapd#4735, snapd#4738, snapd#4739, snapd#4743, snapd#4745, snapd#4748, snapd#4750, snapd#4751, snapd#4752, snapd#4755
<zyga> https://github.com/snapcore/snapd/pull/4714 needs 2nd review
<mup> PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
<zyga> mvo this is from jamie for 2.32
<mvo> zyga: ok
<mborzecki> zyga: thanks for the review, i've pushed an update, once it's green i'll merge that pr
<zyga> sorry for taking so long
<Chipaca> mvo: do you remember why we made --no-wait hidden?
<mvo> Chipaca: I think because initially it was meant for our tests
<mvo> Chipaca: but I think if it is useful outside of that we should just unhide it
<Chipaca> mvo: I'm +1 for unhiding it, but only because it messes up some help screens and seems unnecessary for it to be hidden
<mvo> Chipaca: sounds good to me
<pedronis> Chipaca: it's mostly hidden also because we never had a discussion how to call it properly
<pedronis> as long as it was for us, that was not a problem
<Chipaca> pedronis: in what sense? you mean --no-wait might be a bad name for the flag?
<Chipaca> ah
<pedronis> yes, how to call the flag
<Chipaca> ok, i'l raise it as part of this por
<Chipaca> pr*
<Chipaca> zyga: do we have a backwards containment checker?
<zyga> mmmm, what?
<zyga> what is backwards containment?
<Chipaca> I know we have a [foo,bar] contains foo checker
<zyga> aaah
<Chipaca> do we have a foo in [foo,bar]
<zyga> I think that's Contains
<Chipaca> (same check, different error)
<zyga> no, wait
<zyga> I mean
<zyga> we have is x in [x, y, z] checker
<zyga> is that what you mean?
<Chipaca> zyga: I think it's just that Contains is used for checking that a container you got from the test has an element you expect it to have, and not viceversa
<zyga> what is vice versa here? that an element exists in a container?
<zyga> I mean
<zyga> the check is the same, the error may be different
<zyga> like Contained or something?
<Chipaca> zyga: I'd call it In, but yeah
<Chipaca> let me get an example for you
<zyga> jdstrand I have a prototype of per-snap update-ns profiles
<zyga> it works, I need to adjust some tests
<zyga> and think about edge cases
<zyga> where it would break
<zyga> currently the policy is the same as before though
<zyga> but I expect that to come in with small patches to policy and interfaces/layouts after this one lands
<Chipaca> actually seeing the error message from contains, i guess it makes no difference; the expectation that the thing in test is first and the test valyue second is probably just mine
<Chipaca> the other checkers have an obtained/expected thing though
<Jasem[m]> hello, I just tried to push a snap using --release beta but it's been saying "Processing..." for an hour now
<Chipaca> Contains just has container/elem
<Chipaca> Jasem[m]: I'm not sure at what point snapcraft says "Processing"; is your network or cpu/disk busy?
<zyga> Jasem[m] (you can use dstat to check)
<Chipaca> Jasem[m]: otherwise it's possible the store went away for a bit, in which case maybe ^C and try again?
<Chipaca> but if it's working, maybe let it work
 * Chipaca might not be a snapcraft nor a store person
 * cachio afk
<Jasem[m]> ctlr+c doesn't even stop it
<Jasem[m]> need to kill
<Chipaca> Jasem[m]: ctrl+\ ?
<mup> PR snapd#4695 closed: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
<Jasem[m]> Chipaca: running again, will see how it goes
<Jasem[m]> Chipaca: ok now 'internal server error' .. try in few minutes the page returned.
<Chipaca> that's not very good is it
<Chipaca> Jasem[m]: in the 500 page you probably have (in the source) a OOPS id
<Chipaca> Jasem[m]: could you look for that?
<Chipaca> brb, cranking the heating up
<Chipaca> hands're freezing
<zyga> Chipaca what's the temperature?
<zyga> (outside)
<zyga> here it's gotten much warmer
<zyga> -8 now
<Chipaca> yeah you're sending it all this way
<Chipaca> but nah, it's zero
<mup> PR snapcraft#1879 closed: extractors: replace desktop file ids with paths <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1879>
<Chipaca> just that the wind's up, and snow
<Chipaca> going to hit -4 by sundown
<ikey> oddly warm here
<ikey> calm before the storm
<zyga> I don't mind thinking about spring now
<Chipaca> my uncle works on the tube, was expecting to be stuck somewhere today
<zyga> like having +20 would be ... amazing
<ikey> 3c here atm, "warm" lol
<ikey> tonight is when the wind and snow is meant to be kicking off..
<zyga> still 11C more than here :)
<ikey> ah yeah but we'll be down to -10C soon
<zyga> I woke up and sent kids to school at -14
<ikey> and a foot of snow
<ikey> oof
<zyga> my daughter said she wants to see snow in Poland
<zyga> (after living in Spain almost her entire life)
<zyga> I told her "careful what you wish for"
<zyga> well, she's getting the snow all right
<zyga> "are you having fun yet?"
<ikey> lol
<zyga> speaking of which
<zyga> my hands are freezing too
<zyga> this new imac is not making any heat that my old AMD system used to do
<zyga> how can I fix 12 failing tests when I cannot feel my fingers anymore :/
<mup> PR snapd#4757 opened: cmd/snap: unhide --no-wait; make wait use go via waitMixin <Created by chipaca> <https://github.com/snapcore/snapd/pull/4757>
<Chipaca> niemeyer: how do you feel about --no-wait? :_)
 * pstolowski lunch
 * Chipaca straightens his nose ;-) 
<Jasem[m]> Chipaca: ok tried again and now it says that a file with the exact content already been uploading
<Jasem[m]> it's kstars_2.9.3_amd64.snap
<Chipaca> Jasem[m]: something's going on because now login.ubuntu.com is  out
<zyga> 9 errors left :-)
<zyga> but all should be trivial two line changes
<zyga> https://status.snapcraft.io shows stuff is "ok"
 * Chipaca goes for lunch
<Jasem[m]> ok I'm getting the same error of the file already being uploaded :(
<mup> PR snapd#4696 closed: wrappers: timer services <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4696>
<mup> PR snapd#4758 opened: tests/main/snap-service-timer: spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
 * zyga food
<mup> PR snapd#4735 closed: daemon, snap: fix InstallDate, make a method of *snap.Info <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4735>
<niemeyer> Chipaca: The functionality seems nice, the argument name seems awkward
<niemeyer> Chipaca: --no-wait=false :)
<mup> PR snapd#4759 opened: [RFC] snap application autostart support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4759>
<niemeyer> Chipaca: --wait=no
<Chipaca> niemeyer: i don't understand --no-wait=false
<niemeyer> Exactly :)
<Chipaca> i mean, what?
<Chipaca> niemeyer: i mean, i don't understand what you mean
<niemeyer> Chipaca: I mean pretty much what you mean too: negatives makes it a bit awkward, when it could be a straight positive
<Chipaca> niemeyer: what'd be the positive?
<niemeyer> Chipaca: 1/yes/true
<Chipaca> niemeyer: that's the side of the thing I knew
<niemeyer> Chipaca: Yeah, it's a bit of an early morning conversation I suppose.. :)
<niemeyer> Chipaca: Let's chat in a few mins
<Chipaca> niemeyer: and a good morning to you too sir :-D
<niemeyer> Morning!
<niemeyer> It'll be even better if I learn that the google backend is working smoothly
<niemeyer> Looks fine!
<niemeyer> mborzecki: This failure on master probably needs some attention: https://travis-ci.org/snapcore/snapd
<niemeyer> mborzecki: Ah, it's not master..
<niemeyer> mborzecki: It's a PR for master.. confusing Travis
<niemeyer> It's this: https://github.com/snapcore/snapd/pull/4758
<mup> PR #4758: tests/main/snap-service-timer: spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
<ikey> jdstrand, ping
<niemeyer> https://usercontent.irccloud-cdn.com/file/UhcAcUK4/gce.png
<Chipaca> mvo: #4748 is for 2.31 (or is that 2.32), fwiw
<mup> PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748>
<mvo> Chipaca: .32 - but yeah, I was almost looking at it
<Chipaca> mvo: I'll milestone it
<mvo> Chipaca: ta
<Chipaca> mvo: there's one in the review queue milestoned for .31, should i change it to .32?
 * ikey fixes yama in solus kernels
<mvo> Chipaca: if we need it for .31 we should make sure it goes to both
<mvo> Chipaca: does .31 already ask for snap_yaml_raw?
<Chipaca> mvo: I don't know
<Chipaca> pedronis might
 * kalikiana lunch time
<pedronis> Chipaca: I think it came with the default-provider stuff
<pedronis> which is 2.32 afaik
<mup> PR snapcraft#1956 closed: snap: actually plug the completer in <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1956>
<mvo> Chipaca: yeah, that is my understanding, its the default-provider so 2.32, so lets retarget
<jdstrand> mwhudson: hey, I just saw this 'thanks systemd journal format non-stability'. Not sure what your plan is, but I looked at this before and found that older journald's didn't work with newer journals *and* vice versa (I was using the python bindings). it was frustrating
<jdstrand> mwhudson: fyi only
<jdstrand> zyga: re per s-u-n profiles. cool :) seems fine to factor out now and tailor policy later
<zyga> yep :)
<jdstrand> niemeyer: hi! I'm here now if you still need me
<jdstrand> ikey: hi!
<ikey> jdstrand, howya
<ikey> jdstrand, so just seen your forum reply sorry (transitioned to a craptop)
<jdstrand> ikey: heh
<jdstrand> ikey: I was going to ping you this week if didn't hear from you :)
<ikey> so the original PR had some problems that we encountered, in that it somehow conflicted with core
<jdstrand> ikey: right. we can work through all that
<ikey> like on a fresh install with no snapd state no new snaps could be installed
<ikey> in the mean time im enabling yama in the kernels per your advice
<ikey> but yeah the actual how-the-interface-fits bit i think is the one i need most help with
<ikey> and with devmode snaps changing soon i think now is certainly the time to do it
<jdstrand> ikey: nice! I think you'll like that as a feature in general. do note, you'll likely need some docs stating how to disable it for your devs. in the beginning, Ubuntu carried a patch to strace and gdb iirc to let devs know (users never cared)
<niemeyer> jdstrand: Thanks!  Not quite sure what it was about, but I'll probably remember as I go through the notes again :)
<ikey> yeah patching those seems sufficient
<jdstrand> niemeyer: hehe, ok :)
<ikey> building kernels on this laptop isn't the fastest thing in the world :(
<jdstrand> ikey: ok, so I see you responded in the forum. I'll move it to the top of my list to go through the PR with a fine-toothed comb and we'll iterate get it into mergeable state. if the fresh install or other bugs remain and we can't solve them, we'll get help
<ikey> cheers jdstrand - i think i just got the initial declaration part wrong
<ikey> but the apparmor bits seem ok
<jdstrand> cool
<jdstrand> I just came online, but hopefully I can get to this today (famous last words, haven't seen inbox yet ;)
<ikey> hah my inbox is closed today
<ikey> too much to do
<jdstrand> smart
<jdstrand> :)
<ikey> had to get the mesa 17.3.6 emergency update out as they'd broken igp
<jdstrand> icky
<ikey> mm
<jdstrand> hopefully for an emergency update, all the depends didn't sping out
<jdstrand> spin*
<pedronis> mvo: niemeyer: I noticed https://forum.snapcraft.io/t/the-content-interface/1074  doesn't mention  default-provider
<niemeyer> pedronis: What a great opportunity! ;)
<jdstrand> I don't do much with mesa, but when I do, I update all the libs
<jdstrand> :P
<ikey> jdstrand, luckily not in this case
<ikey> no abi change
<ikey> no dep changes, etc
<jdstrand> nice
 * ikey likes when cherry-picks live up to their name
<jdstrand> still, emergencies aren't conducive to getting to planned stuff :)
<ikey> really not
<ikey> that and waiting for this storm to kick in any minute
<ikey> started snowing already
<jdstrand> we're waiting for the rains to stop
<jdstrand> fingers crossed, soon
<ikey> id love to cross my fingers but they're too cold xD
<jdstrand> hehe
<ikey> alright once i have the kernels done ill ping you again
<pedronis> niemeyer: I asked the question about hold
<niemeyer> pedronis: Replying as we speak
<niemeyer> or sort of :)
<jdstrand> ok
<pedronis> niemeyer: thanks
<niemeyer> pedronis: np, hope it makes sense
<niemeyer> pedronis: More seriously, would you mind to fix the lack of content-provider there? We need to get used to doing those opportunistic fixes to bring docs up-to-date
<pedronis> niemeyer: I can try, in a little bit,  trying to wrap up some things
<mborzecki> Chipaca: posted a note https://forum.snapcraft.io/t/how-to-autostart-a-snap-of-a-desktop-application/2449/17
<mborzecki> zyga: layout test failed again https://api.travis-ci.org/v3/job/346757570/log.txt
<zyga> looking
<zyga> hmm, I haven't seen this kind of failure
<zyga> looks like snap install failed (hanged?)
<zyga> ah, no wait
<zyga> wrong part of the log
<zyga> there's no /etc!?
<zyga> hmm hmm
<mup> PR snapd#4759 closed: [RFC] snap application autostart support <Created by bboozzoo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4759>
<zyga> niemeyer can you please share credentials / tokens / whatever needed to run against google backend?
<niemeyer> zyga: Right on.. what's your gmail email?
<zyga> zkrynicki@gmail.com
<niemeyer> zyga: Done..
<niemeyer> zyga: You'll need to install gcloud, then:
<niemeyer> zyga: gcloud auth application-default login
<niemeyer> zyga: and you should be good to go
<zyga> this thing? https://cloud.google.com/sdk/downloads
<niemeyer> zyga: Yeah.. we really need a snap for that.. I'm hoping they will do it :)
<ackk> hi, is it possible to specify constraints on package versions in 'stage-packages'?
<niemeyer> ackk: I don't think so.. it doesn't match the apt model super well
<Chipaca> mborzecki: thank you for the heads-up; replied
<zyga> Pharaoh_Atem FYI, I hate bugzilla
<niemeyer> ackk: But I'm guessing.. sergiusens (when he's around) will know for sure
<niemeyer> zyga: FYI, everybody does
<zyga> I got 30 email notifications about some CC change that someone is doing to a selinux+snapd bug
<zyga> my iphone beeps every 5 seconds
<ackk> niemeyer, yeah that's true, I was wondering how could you have reproducible builds for snaps that use dependencies from debs
<zyga> how do people use this?!
<zyga> every tiny action sends more mail
<niemeyer> zyga: Most people don't nowadays.. it was fairly popular in the 90s though
<zyga> there's no conservation of energy there, you touch your mouse and bam, that's an email to everyone that had a browser open on this bug ever
<zyga> 40 emails now
<zyga> the notifications are so bad I don't even know what's being changed
<mborzecki> bugzilla & mantis, both supper chatty
<niemeyer> ackk: It's a problem outside the realm of snapcraft a bit.. there solutions to control a repository of packages so they don't change out of control
<ackk> niemeyer, can you specify the source where debs are taken from?
<zyga> niemeyer apparently RH still uses it for everything though
<ackk> ah, I see https://forum.snapcraft.io/t/proposal-additional-package-sources/2199
<kalikiana> re
<Son_Goku> zyga: it's supposed to be motivation to fix things, so you make bugzilla shut up :)
<niemeyer> ackk: Yeah
<Son_Goku> zyga: and maybe now you'll make the mystical SELinux backend :D
<ackk> niemeyer, yeah that's a nice feature
<zyga> jdstrand running tests now, so far so good
<zyga> jdstrand can you please look at https://github.com/snapcore/snapd/compare/master...zyga:feature/snap-update-ns-profiles?expand=1#diff-af477950316a096b57d91c74478bc4d2R160
<zyga> is this all that I have to do on snap-confine side?
<zyga> (the rest of the changes in C just push the argument through the functions)
<pedronis> niemeyer: I wrote something about default-provider
<niemeyer> pedronis: Thank you!
<zyga> jdstrand and unrelated to that, is this line still required? I how do implicit and explicit profile transitions interact with each other? https://github.com/snapcore/snapd/compare/master...zyga:feature/snap-update-ns-profiles?expand=1#diff-798ce6f0668878eda67847b4ab492745L467
<mup> PR snapd#4760 opened: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760>
<cachio> elopio, hey
 * zyga is interrupted by arrival of construction team
<zyga> jdstrand I will look at results of 4760 when they show up
<zyga> I want to break out one part to a separate PR
<cachio> elopio, I have seen some snapcraft errors on the autopackgtests exec for snapd
<zyga> jdstrand but if you can look at it and give me some early feedback I can iterate on it today
<cachio> elopio, things like these https://paste.ubuntu.com/p/9q6NzrtZR5/ https://paste.ubuntu.com/p/2wjfMRBw7k/ https://paste.ubuntu.com/p/FYfgJ2nD3J/
<zyga> I suspect we can mostly merge it in the next few hours
<cachio> mostly on armhf
<cachio> elopio, those don't seem to be related to snapd, could you please confirm that?
<cachio> elopio, most of them are here http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd
<ackk> niemeyer, is the PPA option for "Source archive for automatic builds" on LP snap builds basically what I was asking about? or is that just for build-packages?
<Chipaca> brb, reboot
<mup> PR snapcraft#1947 closed: errors: add ability to send stack traces to sentry <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1947>
<ackk> sergiusens, I see that launchpad-build passes SNAPCRAFT_LOCAL_SOURCES to make snapcraft use the host apt repos, but I see no mention of it in the snapcraft source
<mup> PR snapcraft#1961 opened: Sentry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1961>
<ondra> sergiusens one more bug about that sanity check, if you are using environment part to update PATH, so it can find executable, snapcraft will not honour it fail with error that executable does not exist
<sergiusens> ackk: because it is the default
<sergiusens> ondra: use the full relative path
<ackk> sergiusens, oh, so if you build a snap for the xenial base on xenial and you have PPAs on your machine, you have stage-packages that come from those PPAs?
<ondra> sergiusens I know that workaround, but sure if executable is PATH then snapcraft should honour it and see it
<ondra> sergiusens because snap works, it's only snapcraft refusing to build it
<sergiusens> ackk: yes, this is why we want to move to building in containers for everything, using a container which's host would match that base to avoid all the confusion during "deployment" time (local installation or ci)
<sergiusens> ondra: if you use `adapter: none` it will not, the snap runtime now expects `command` to be a full path to the binary
<sergiusens> we don't want to deviate from that, sorry; hard line on that one
<ikey> jdstrand, nearly finished doing all the kernel jankery
<ikey> my guess is we'd reconvene on the steam thingy tomorrow
<ackk> sergiusens, you mean having snapcraft do the build in the container (vs manually setting up a container and running snapcraft in it)?
<ondra> sergiusens so command requires full path regardless adapter?
<sergiusens> ondra: yes, it is masked by the fact we create a wrapper which is incidentally the actual relative path inside the snap to the command
<ondra> sergiusens OK
<sergiusens> ackk: yes, essentially bringing up SNAPCRAFT_CONTAINER_BUILDS to the front lines
<ondra> sergiusens still it seems to be picky, if executable is in PATH snapcraft it happy, if PATH is updated using environment, it will fail
<sergiusens> and leaving "building on host" as an advanced mechanism "I get to keep my broken pieces to myself" mode
<ondra> sergiusens so there is inconsistency
<sergiusens> ondra: ok, I am willing to go the other way and making it be a full path as something mandatory (we will warn though to not break existing builds)
<ackk> sergiusens, cool, thanks
<ondra> sergiusens yeah I don't know if how it is now breaks anything existing, but if it was like this then better to leave it
<sergiusens> ondra: IOW, using `environment` in `apps` is a runtime thing, not a build time one
<ondra> sergiusens yes, but snapcraft checks should not fail on something that will be correct in run time, erroring that executable is not there
<sergiusens> ondra: that's the thing, in the future, it won't
<sergiusens> once we get rid of the wrappers
<ondra> sergiusens right, that makes more sense
<niemeyer> Chipaca: If you have a moment soonish, can we please have a quick hangout?
<mup> PR snapd#4761 opened: osutil: handle file being matched by multiple patterns <Created by zyga> <https://github.com/snapcore/snapd/pull/4761>
<Chipaca> niemeyer: yes
<Chipaca> niemeyer: anything in particular?
<niemeyer> Chipaca: Yeah, it's quick.. just want to get you interested on something :)
<Chipaca> doom doom doooooom
<Chipaca> just finishing a (let's keep it between us: rather disgusting) pizza the boys made for me at school, and i'll be free
<Chipaca> I need something to unclog my chest
<niemeyer> Chipaca: Great, enjoy, and just ping me
<kyrofa> Haha, Chipaca what kind?
<zyga> Chipaca pizza is never bad
<zyga> it's just sometimes in the wrong week
<zyga> wait a little, it will get better
<zyga> like wine
<Chipaca> kyrofa: tea is fine
<zyga> mborzecki can you please look at 4761
<kyrofa> Chipaca, I mean the pizza
<Chipaca> kyrofa: there's three different cheeses in there
<Chipaca> kyrofa: and pepperoni
<Chipaca> and gluten free pastry, because that's how they roll
<Chipaca> maybe it's the wrong time of day for so much stodge
<Chipaca> niemeyer: ready; standup ho?
<mup> PR snapcraft#1962 opened: store: stringify message for StoreDeltaApplicationError <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1962>
<mup> PR snapd#4762 opened: servicestate: use systemctl enable+start and disable+stop instead of --now flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/4762>
<niemeyer> Chipaca: Let's do it
<mup> PR snapd#4763 opened: osutil: handle file being matched by multiple patterns <Created by zyga> <https://github.com/snapcore/snapd/pull/4763>
<niemeyer> zyga: I've removed your gmail address and added your canonical one.. if you've logged in, you'll need to do it again
<zyga> niemeyer thanks, I haven't logged in yet; I'll try that soon
<jdstrand> ikey: ok. feel free to look at the PR, get it into shape for me to review and just reference me with @jdstrand and I'll get to it (if all you do is get it to apply clean to master, that's fine with me)
 * Chipaca hugs pstolowski 
<ikey> yeah ill need to redo as i closed the old one
<jdstrand> zyga: sorry, buried in email and was in a meeting (out now)
<zyga> whee
<pstolowski> Chipaca, thanks for the review!
<zyga> it's always good to get out of a meeting ;)
<zyga> jdstrand have a look at the initial shape of the PR
<zyga> it feels too easy, I wanted to make sure I didn't miss anything
<jdstrand> https://github.com/snapcore/snapd/compare/master...zyga:feature/snap-update-ns-profiles?expand=1#diff-798ce6f0668878eda67847b4ab492745L467 isn't needed with change_onexec. you will need a rule to allow that change_onexec
<zyga> ah, I see, how does such rule look like?
<zyga> btw, there's a PR now
<zyga> so you can comment there if you want
<ikey> jdstrand, ill have that PR in for you tomorrow
<jdstrand> change_profile -> snap-update-ns.*,
<ikey> then we can redo the snaps as strict and set a minimum version
<ikey> and generally kick ass
<jdstrand> ikey: +1 :)
<jdstrand> zyga: what is the pr number?
<zyga> 4760
<jdstrand> zyga: ok, I'll take a look. btw, I'm not neglecting a review for the portals work, am I? afaik, I'm caught up...
<zyga> jdstrand no no
<zyga> jdstrand I want this finished as 2.32 is soon going to be released
<jdstrand> I see
<zyga> with the FIXMEs that this will help addressing
<jdstrand> we need livecd PR in 2.32 so willcooke, seb128 and the gang can test. I saw that you asked mvo for an additional review (thanks!)
<zyga> jdstrand yes, I think that PR is ready but I didn't want to just land it myself
<seb128> jdstrand, when is 2.32 due?
<jdstrand> zyga: I also don't need your testsuite fixes in 2.32, but I need to know if they will be in 2.32
<mvo> seb128: in ~2 weeks
<zyga> jdstrand testsuite fixes?
<jdstrand> zyga: I phrased that weird
<zyga> the profile hardening
<jdstrand> zyga: the nfs_test.go and overlay_test.go bits
<zyga> ah,  that
<zyga> that is done though :)
<Chipaca> huh, snap on fc25 never comes back from the polkit dialog
<seb128> mvo, thanks, I guess that will have to do, some apps not working in the live session in not the end of the world
<zyga> I was working on that to prepare for conservative mount changes that also need to mock things
<zyga> and I didn't want to get into a huge PR that changes test infra in one go
<zyga> Chipaca F25 is not supported, is it better in F27?
<Chipaca> zyga: I don't have f27 :-)
<zyga> Chipaca update :)
<Chipaca> I'll get that set up when I get my new machine
<Chipaca> (or when I dedicate the old one to fedora)
<zyga> Chipaca offtopic, can you please look at small https://github.com/snapcore/snapd/pull/4761
<mup> PR #4761: osutil: handle file being matched by multiple patterns <Created by zyga> <https://github.com/snapcore/snapd/pull/4761>
<jdstrand> zyga: again, I don't need you to do anything other than let me know if you are pushing it to 2.32. it sounds like you are not, so I'll just do a separate 2.32 that isn't all cherrypicks
<zyga> there's a similar 2.32 backport branch but you don't have to review it separately
<Chipaca> zyga: in a mo'
<zyga> Chipaca thanks
<Chipaca> my fedora just lit up the 'check engine' light
<zyga> jdstrand ah, I see
<Chipaca> so i'm going to set it on fire and run
<zyga> jdstrand I'm not doing a separate 2.32 one
<zyga> yes we will need more cherry picks
<jdstrand> ok
<Chipaca> that's what you do when a car you downloaded off the internet tells you to check engine, right?
<jdstrand> seb128: you may want to be aware of https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1751667
<mup> Bug #1751667: classic snap does not run on live session <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1751667>
<zyga> sorry, I took forever to understand what you meant there
<seb128> jdstrand, oh, thanks
<seb128> kenvandine, ^
<jdstrand> seb128: I *think* once the PR in question lands, that becomes a non-issue. if it doesn't, the foundations team may be doing something with apparmor that is preventing apparmor to load policy on boot
<zyga> seb128 yes, it should just work soon
<jdstrand> (doesn't become on non-issue that is)
<jdstrand> seb128, kenvandine: I commented in the bug
<seb128> thx
<niemeyer> jdstrand, zyga: Can you have a look here: https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203/5
<jdstrand> seb128, kenvandine: to be very clear, you'll need https://github.com/snapcore/snapd/pull/4714 in the snapd deb in the livecd for you to be able to run any snaps before a core refresh
<mup> PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
<zyga> looking
<niemeyer> jdstrand, zyga: This is not just about Debian.. I found the same problem in the GCE images
<niemeyer> cachio: ^
<cachio> niemeyer, yes
<zyga> niemeyer I think this was the bug in ubuntu that was fixed with a new kernel
<zyga> where apparmor profiles would not be loaded by the apparmor service
<zyga> let me look up the #
<jdstrand> niemeyer, zyga: this is a known issue to me
<jdstrand> let me triple check that statement
<niemeyer> jdstrand: This looks like a pretty serious issue LXD is just not working
 * zyga is still looking
<jdstrand> actually, the issue I knew about was: https://github.com/lxc/lxd/issues/4198
<jdstrand> that has to do with partial confinement and newer kernels
<jdstrand> and is high on my list
<jdstrand> let me look at the forum again
<niemeyer> jdstrand, zyga, stgraber: For context, our entire suite passed in GCE's 16.04 image, except for lxd that failed with that error message
<zyga> oh
<zyga> GCE 16.04 image on ubuntu kernel or on google kernel?
<jdstrand> that is different from https://github.com/lxc/lxd/issues/4198 then
<niemeyer> zyga: The GCE image is produced by Canonical
<jdstrand> well, yes, I was assuming ubuntu kernel
<zyga> I see
<jdstrand> ok
<jdstrand> this is lxc running a snap inside a container
<jdstrand> and the snap-confine in the container doesn't have the profile loaded
<jdstrand> on Debian, this is I think expected
<jdstrand> 4.9.0-5-amd64
<jdstrand> that kernel doesn't support apparmor stacked policy
<stgraber> jdstrand: where did you see that this is inside a container?
<jdstrand> the Ubuntu container comes up, notices that the kernel doesn't have stacking support and skips profile loads
<jdstrand> stgraber: https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203
<stgraber> jdstrand: right, where do you see in there that this is inside a container?
<jdstrand> stgraber: I was thinking the lxc list indicated that, but looking more carefully, no, that would still be the host policy
<jdstrand> I thought that was trying to launch a snap, it is just list though
<jdstrand> that kernel should have partial apparmor support
<stgraber> yeah, AFAIK he's using a normal Debian system with snapd installed and the lxd snap installed. He can run the "lxc" command as root but not as a normal user and some update changed that for him (it used to work)
<stgraber> and he says he's on stable, so it's unlikely to be the apparmor enablement that's going on with buster
<jdstrand> the error there shouldn't make a difference if root or not
<stgraber> yeah, though it does, he can interact with lxd fine as root
<stgraber> https://discuss.linuxcontainers.org/t/snap-confine-issues-more-things-changing-without-my-doing-things/1276 is where he initially reported the issue before I sent him over to snapd
<zyga> well, the error simply says that snap confine detected it is not running under confinement but apparmor is enabled and available in the kernel
<jdstrand> hrm. btrfs is in the picture
<zyga> that seems to say that either it's a non-standard setting that has apparmor enabled
<zyga> or that the kernel in stable got updated to enable it (unlikely)
<mborzecki> zyga: 4761 fixes the /etc thing we were seeing?
<cachio> mvo, there?
<zyga> mborzecki no, it's not related, it's a new bug I ran into while trying to use the multi-glob dir sync
<cachio> I found a problem with refresh in 2.32
<zyga> mborzecki we don't use syncdir for any of the mimic construction code
<mvo> cachio: yes
<mborzecki> zyga: ahh ok
<cachio> mvo, look at this https://paste.ubuntu.com/p/RwPt9qRNjc/
<jdstrand> that bug is all over the place
<mborzecki> zyga: review swap can you take a look at https://github.com/snapcore/snapd/pull/4758 ?
<mup> PR #4758: wrappers, tests/main/snap-service-timer: restore missing commit, add spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
<cachio> mvo, refresh starts
<cachio> mvo, there is a connection refused
<zyga> ack
<mvo> cachio: yeah, looks like dns is not ready
<cachio> and then network configuration is changed
<mvo> cachio: actually it is trying to do a ipv6 connection
<jdstrand> zyga: nice comment in the forum
<cachio> mvo, weird, I should disable ipv6 and try again
<cachio> I didn't enable ipv6
<mvo> cachio: good luck
<niemeyer> jdstrand, zyga, stgraber: Again, we see the exact same error in our own tests in GCE, in Ubuntu
<jdstrand> niemeyer: what kernel is that?
<niemeyer> So trivial reproducer: grab spread, run google:ubuntu-16.04-64:tests/main/<the lxd test>
<niemeyer> jdstrand: Whatever is in GCE
<niemeyer> jdstrand: I don't have any machines live right now, but can have
<zyga> I haven't installed the new google-enabled spread and the google SDK required yet but that will be my next step
<jdstrand> right, I don't know what that is :)
<niemeyer> jdstrand: We're even then! ;)
<mvo> cachio: do you think you could try to reproduce 1752031 on a regular amd64 image?
<jdstrand> heh
<niemeyer> jdstrand: The point is that someone needs to investigate, and probalby not all of us
<jdstrand> zyga: we need a google sdk installed?
<niemeyer> jdstrand: Yes, just to auth..
<zyga> jdstrand for the auth, as far as I know
<niemeyer> jdstrand: Then run: gcloud auth application-default login
<niemeyer> jdstrand: Meanwhile, I'm adding you to the project so you have access
<jdstrand> if it isn't obvious yet, I'm not setup for this either
<niemeyer> jdstrand: What? How come!?  This is working since at least 3AM my time!
<zyga> mborzecki done
<mvo> cachio: and if you can, the outpt of the ls command would be great and whatever you can find out about this. we are "masking" the service, so there should be a symlink from sshd.service to devnull in that /etc/ dir
<jdstrand> niemeyer: hehe
<niemeyer> jdstrand: Add you to the project.. if you grab snapd's master and do the auth suggested above, you should have access.. I'll grab the command line to run spread for you, just a sec
 * kalikiana heading out for the day
<jdstrand> niemeyer: where does 'gcloud' come from? is this a pay service like with amazon? do I give my canonical google info?
<niemeyer> jdstrand: gcloud is their CLI client for all things cloudy
<jdstrand> niemeyer: right. where does one obtain that? snap install? :)
 * jdstrand hasn't used gce before. can you tell?
<niemeyer> jdstrand: I wish it was a snap, but I think it still isnt'
<niemeyer> jdstrand: It is a paid service, but you don't need to worry about it.. the project pays the bill
<niemeyer> jdstrand: https://cloud.google.com/sdk/
<niemeyer> and yes, this is a great candidate for being a snap
<jdstrand> ugh, tar balls with install.sh
<jdstrand> ah, debs down below. slightly better
<zyga> jdstrand those are debs with sudo install.sh :D
<zyga> aka postinst
<jdstrand> maybe I'll just do this in a vm
<mborzecki> zyga: thanks, i've added the comments around timers :)
<jdstrand> or a container. ugh
<niemeyer> jdstrand: You can run the test with "spread -reuse -debug google:ubuntu-16.04-64:tests/main/lxd"
<Chipaca> zyga, i've got a silly / funny question for you
<niemeyer> jdstrand: You'll need to change the "systems" setting in the test, though, because I've removed that specific system so we could move on with the migration
<zyga> yes
<niemeyer> jdstrand: You can see the change here: https://github.com/snapcore/snapd/pull/4754/files
<mup> PR #4754: spread: start moving towards google backend <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4754>
<Chipaca> zyga: i'm working on snap-exec right now
<Chipaca> zyga: so I change it, build it, copy it to /usr/lib/snapd
<zyga> "how do you test this"
<zyga> is the question
<zyga> that's not useful
<Chipaca> zyga: and i never see the new one
<Chipaca> (it's not reexec)
<zyga> we don't use that one
<zyga> snap-exec is almost always used after pivot_root
<Chipaca> ajjj
<Chipaca> of course
<Chipaca> zyga: thank you
<zyga> so you have to bind mount your snap-exec to /snap/core/current/usr/lib/snapd/snap-exec
<zyga> :)
<Chipaca> yep yep
 * zyga hugs Chipaca 
<Chipaca> say no moew
<Chipaca> also, say no more
 * Chipaca hugs back
<zyga> meow
<niemeyer> jdstrand: I think it's kept entirely inside the source directory
 * zyga is distracted by drilling, cutting and other noises 
<zyga> on the up side, I will finally not have to store clothing and books on the floor so
<zyga> whee
<Chipaca> man i wish there were a flag equivalent of .hushlogin
<zyga> take that neighbours!
<Chipaca> zyga: ?
<zyga> a team is constructing some furniture in the room next to me
<zyga> they were supposed to be here in the morning
<zyga> but ... reality
<zyga> they will keep assembling things for the next few hours at least
<zyga> <sound of electric saw>
<niemeyer> jdstrand: That's how I run it at least.. it has bin/gcloud, and it all works
<zyga> stgraber do you test LXD in GCE?
<pstolowski> Chipaca, addressed your feedback
<pstolowski> eod o/
<cachio_> niemeyer, did you call me?
<cachio_> niemeyer, do you want to start with the new backend migration?
<zyga> jdstrand any feedback?
<pedronis> cachio_: I'm trying staging tests again (to test the new api),  when you have a moment could you copy over a recent edge core
<cachio_> pedronis, sure, I'll finish with a bug that was raised and I'll take that
<pedronis> thank you
<jdstrand> zyga: in the PR? I gave it a little while ago. did you not get the email?
<zyga> no, refreshing
<zyga> I installed debian 9 with snapd
<zyga> but
<zyga> I cannot install core
<zyga> search.apps.ubuntu.com is not working anymore?
<zyga> oh, I see store is down
<zyga> bummer
<jdstrand> yeah, I'm stuck too
<pedronis> yes, store is hiccuping again
<zyga> seems totally down
<zyga> jdstrand I didn't get any email
<niemeyer> Oh no
<zyga> I can see the feedback now
 * niemeyer looks
<jdstrand> zyga: I don't know what to say... https://github.com/snapcore/snapd/pull/4760#pullrequestreview-99778381
<mup> PR #4760: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760>
<zyga> niemeyer do you know about https://status.snapcraft.io ?
<zyga> jdstrand read your review
<zyga> jdstrand I think the only thing I want to ensure we are in sync on is...
<zyga> https://github.com/snapcore/snapd/pull/4760#discussion_r171024214
<mup> PR #4760: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760>
<niemeyer> zyga: I didn't
<ikey> cat /proc/sys/kernel/yama/ptrace_scope
<ikey> 1
<ikey> yay.
<niemeyer> cachio_: So, you have access to the google back already right now.. just login with your canonical email address
<niemeyer> cachio_: To login, install the google cloud sdk, and run: gcloud auth application-default login
<niemeyer> cachio_: That's all
<niemeyer> cachio_: spread should work from then on
<cachio_> niemeyer, perfect
<cachio_> niemeyer, so the idea is to make spread suite for in all the systems that we have right now, right?
<kyrofa> Linode was just too unstable, eh?
<cachio_> ubuntu-16.04-64 is already working
<ikey> jdstrand, valgrind + gdb  still work nicely
<ikey> and ltrace/strace, yay.
<niemeyer> cachio_: HAve you seen the initial PR?
<niemeyer> cachio_: Let me get you a link, just a sec
<zyga> https://github.com/snapcore/snapd/pull/4754/files ?
<mup> PR #4754: spread: start moving towards google backend <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4754>
<jdstrand> ikey: yeah. where they don't is -p
<niemeyer> zyga: Thanks!
<niemeyer> cachio_: That one ^
<ikey> right, attaching to a random process
<ikey> so we probably want a simple set of scripts to "start" and "stop" secure modes
<ikey> or rather, enter dev mode
<niemeyer> cachio_: As you see there, I've preserved the system name, and just moved the system across from one backend to the other
<niemeyer> cachio_: I also had to disable one test which jdstrand is looking into right now (lxd)
<ikey> jdstrand, strace: attach: ptrace(PTRACE_SEIZE, 1574): Operation not permitted
<ikey>   :D
<mvo> niemeyer: nice!
<niemeyer> cachio_: But that's the idea.. we want to gradually move every one of those systems there.. I suggest starting with systems for which images are already available
<jdstrand> ikey: nice!
<jdstrand> niemeyer: fyi, spread -reuse -debug google:ubuntu-16.04-64:tests/main/lxd
<jdstrand> error: backend "google" has unsupported type "google"
<cachio_> niemeyer, ok
<ikey> also wow my strace -p tab completion is awesome
<niemeyer> jdstrand: I assume you are using the snap? Will rebuild it
<jdstrand> niemeyer: I'm in a checkout of master
<niemeyer> jdstrand: So just update it
<niemeyer> jdstrand: Exists as of last night
<cachio_> niemeyer, could you please push the change to support google bacjkend
<cachio_> I have the same problem
<jdstrand> niemeyer: what snap are you talking about?
<niemeyer> Is it not pushed?
<zyga> jdstrand git pull in snapd/spread
<jdstrand> spread is still r34 everywhere afaict
<zyga> jdstrand the code is there
<jdstrand> zyga: I already did that
<niemeyer> jdstrand, cachio_: Everything is up-to-date, apparently...
<zyga> jdstrand did you go install?
<cachio_> niemeyer, yes, it is pushed
<jdstrand> I have c1d1c84e975e2d96ec665de7241c0a1495e2c098
<cachio_> git was stuck
<niemeyer> 5c9c4856e38fa8a757c6c22969585bdb353a0576
<niemeyer> jdstrand: %
<niemeyer> ^
<cachio_> niemeyer, so, I'll start migrating one by one
<jdstrand> niemeyer: for snapd or spread?
<niemeyer> jdstrand: For spread
<jdstrand> zyga: I don't know what you are talking about
<jdstrand> niemeyer: oh, no upload in the store? ok. I was curious why it wasn't there
<niemeyer> jdstrand: Okay, wait.. :)
<pedronis> IÂ think jdstrand like me uses the snap
<jdstrand> oh yes
<jdstrand> everyone doesn't?
<niemeyer> Okaaay.. :)
<pedronis> IÂ don't know
<niemeyer> jdstrand: You said you used master, when I said I was going to update the snap :)
<niemeyer> Anyway, all good.. updating it
<zyga> I used a local build because I have some patches
<jdstrand> niemeyer: sorry, I meant snapd master. I missed I needed to update spread (I figured I did, but when I saw it wasn't updated I focused on snapd
<jdstrand> )
<niemeyer> jdstrand: All good! Working on it already, just a sec
<niemeyer> jdstrand: Done
<jdstrand> ok, snagged r35 and it is doing stuff
<jdstrand> niemeyer: thanks!
<niemeyer> jdstrand: Thanks a lot for digging into this issue, and sorry for the confusion
<zyga> niemeyer, jdstrand: snapd + lxd works ok on debian 9 vanilla install
<zyga> but apparmor is disabled in vanilla installs
<zyga> I just tested that all the way from downloading debian, installing it in a VM, setting up lxd snap and creating a xenial container inside
<niemeyer> zyga: Thanks, the GCE case is an easy target to look into.. I bet we'll learn something about Debian there too
<zyga> yeah, GCE is next
<zyga> I wanted to follow up on what the reporter was using
<jdstrand> zyga: it is strange though that having apparmor enabled caused that issue. is this a 2.29 bug partial support bug?
<zyga> I suspect that it indicates we don't generate the profile if apparmor is partially on
 * zyga looks at the source
<niemeyer> mvo: cloud team already has bionic under the ubuntu-os-cloud-devel project!
<jdstrand> I've reproduced in gce
<jdstrand> the issue is different in gce though
<jdstrand> in debian, it was 'lxc list' that caused the issue
<niemeyer> cachio_: "image: ubuntu-os-cloud-devel/ubuntu-18.04-64"
<jdstrand> in gce, that works fine. it is this that fails: lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-tools.echo from-the-inside' ubuntu
<cachio_> ogra_, hey, any idea why it could be happening? https://bugs.launchpad.net/snappy/+bug/1752031
<mup> Bug #1752031: core `service.ssh.disable` key not taken into account <Snappy:In Progress> <https://launchpad.net/bugs/1752031>
<niemeyer> cachio_: This should give us bionic
<zyga> jdstrand when apparmor is totally disabled we don't load the backend so there's nothing that happens, how can I enable apparmor on debian 9? (even partial support is good)
<cachio_> niemeyer, perfect
<jdstrand> which is what I was talking about before-- the policy isn't loaded in the container
<zyga> jdstrand is that a kernel bug? the one where detection of containers doesn't function?
<jdstrand> zyga: boot with security=apparmor apparmor=1
<zyga> ok
 * zyga snapshots and tries
<jdstrand> right, in the container, the reexec profiles are loaded, but not the one from /etc/apparmor.d
<jdstrand> this is a 4.13
<zyga> I see
<jdstrand> this is that bug
 * jdstrand finds
<zyga> right
<zyga> so, since this happens in GCE but not in linode does it indicate that GCE kernel is older?
<zyga> or that the base set of packages (apparmor) in the container is older (not sure where the bug was fixed)
 * zyga enabled apparmor on debian 9 and rebooted
<zyga> with partial confinement LXD works ok
<jdstrand> zyga: gce has a 4.13 kernel. that is the kernel that changed what the unit is looking at
<mvo> niemeyer: yay for bionic tests
<jdstrand> jjohansen: hey, the fix for https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463, I thought that needed to be fixed in the kernel?
<mup> Bug #1746463: apparmor profile load in stacked policy container fails <apparmor (Ubuntu):Confirmed> <apparmor (Ubuntu Artful):Fix Committed> <apparmor (Ubuntu Bionic):Confirmed> <https://launchpad.net/bugs/1746463>
<jdstrand> jjohansen: see https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463/comments/3 for context
<jdstrand> zyga: there is no need for you to look at gce (at least wrt this)
<niemeyer> mvo: Yeah, and with an official image even
<zyga> jdstrand ack, thank you
<jdstrand> niemeyer: where do you want me to comment on gce? the lxc topic doesn't mention it
<zyga> niemeyer, jdstrand: so at least in debian 9, even if I enable apparmor (non default configuration) snapd and LXD works correctly
<jdstrand> zyga: sounds like you can report that and ask for more info to reproduce the reporter's environment
<niemeyer> jdstrand: Seems okay to mention it there, since the error message and the context (lxd) is exactly the same
<jdstrand> niemeyer: note, it is the same message, but coming from inside of the container. the reporter said it was outside the container, so the cause is different, but I'll comment
<niemeyer> jdstrand: Cool, just mention that we were already looking into this related issue which looks a lot like it but is slightly different
<jdstrand> yep
<pypt> hello! not sure if it's been reported already, but api.snapcraft.io does not seem to be accessible from Travis: https://travis-ci.org/StreisandEffect/streisand/jobs/346906976#L1802
<zyga> pypt it was down a moment ago but it should be back up again
<zyga> pypt have a look at status.snapcraft.io
<pypt> thank you, retrying
<pypt> seems to work!
<zyga> jdstrand question about change_profile
<zyga> I get how that works and makes sense
<zyga> but what should I do to rules like this
<zyga>     /var/lib/snapd/hostfs/usr/lib{,exec,64}/snapd/snap-update-ns Cxr -> snap_update_ns,
<zyga> I want to keep the path expression but drop the profile transition
<zyga> should I just say "xr" there?
<pedronis> mvo: did you see this  https://forum.snapcraft.io/t/how-to-figure-out-why-ubuntu-core-keeps-restarting/4257 ?
<mvo> pedronis: I have not
 * mvo looks
<jdstrand> zyga: you should delete those rules. those rules are for binary attachment. you are using libapparmor so you need the change_profile rules. you probably need an r rule still. otoh, I don't remember, but it is easy for you to test. comment out the Cx rules, add the change_profile and see what pops out
<mvo> pedronis: " snap âcoreâ has ârefresh-snapâ" is strange, it seems to lack context
<zyga> yep
<zyga> thanks
<jdstrand> np
<pedronis> mvo: what's on errors
<mvo> pedronis: looking now, need to get my 2fa token
<mvo> pedronis: " ERROR cannot finish core installation, there was a rollback across reboot"
<zyga> gadget issue?
<mvo> pedronis: looks like some blacklist on core revert is needed
<zyga> try/trying thig?
<pedronis> mvo: well it rolled back
<pedronis> so it wouldn't work either way
<pedronis> mvo: that message means a rollback from  initrd
<mvo> pedronis: do you know more about this? or is all the info in this forum post?
<pedronis> IÂ just saw the post there
<pedronis> IÂ know nothing more
<pedronis> mvo: ah, you mean apply blocked ?
<pedronis> we don't set blocked indeed
<mvo> yeah
<pedronis> if the revert is from initrd
<mvo> I think that would help a little bit
<pedronis> but not sure
<mvo> its an open question
<pedronis> IÂ don't remember the logic
<mvo> I replied
<mvo> in the forum, I hope we learn why it fails
<jjohansen> jdstrand: needed? no, there are work arounds, as the bug is to due with the kernel not displaying the ns_name as userspace expects it.
<pedronis> mvo: do we have  other similar errors on errors?
<pedronis> or is an isolated case
<jjohansen> jdstrand: the kernel fix has been sent to the kt, but it got put in the backlog due to spectre/meltdown retpoline kernel respins.
<mvo> pedronis: I don't know and I can't find out without help from the foundations team, we don't get a data export from the error tracker anymore :(
<jdstrand> jjohansen: right. the bug task if for apparmor, but it is the kernel that will be fixed. that is what I wanted to know
<jdstrand> jjohansen: thanks!
<zyga> jdstrand I adjusted the rules and started a local run, fingers crossed
<zyga> it also works on my desktop
<jdstrand> nice
<zyga> anything I should change apart from the profile transition rule?
<zyga> I will iterate for sure but I want to know if anything is blocking this now
<jdstrand> jjohansen: I added a couple of tasks to the bug. feel free to adjust if I got anything wrong (I wasn't sure if Fix Committed for the apparmor task translated to Fix Committed for the artful 'linux' task)
<zyga> mvo, pedronis: do you have a moment for 2nd review of 4761?
<mup> PR snapcraft#1963 opened: Fix Store integration tests with updated snap name registration error messages <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/1963>
<jdstrand> zyga: I left a few comments and questions... did you not see them? I haven't gotten back to the pr for a few minutes
<zyga> jdstrand wording changes, yes
<zyga> jdstrand I was worried that we don't understand each other on when the profiles are generated
<zyga> not sure if you saw my question on IRC earlier
<jdstrand> I don't think I did
<zyga> jdstrand my main point was that we generate the per-snap profile always
<jdstrand> zyga: you have a comment to the contrary
<zyga> because I don't want to use it for just layouts (that can be arguably "rare")
<zyga> if so I will remove that comment, probably from an earlier draft
<zyga> but also for content interface and for other things that we may need to do
<zyga> and with your suggestions (per-snap) I think this is a good idea even more than originally so
<jdstrand> zyga: https://github.com/snapcore/snapd/pull/4760/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR364
<mup> PR #4760: many: generate and use per-snap snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4760>
<zyga> I went this way to not have to duplicate the apparmor profile for snap-update-ns
<zyga> ah
<zyga> yes, stale comment,
<zyga> I will remove it and re-read the diff to ensure they are all up-to-date
<jdstrand> it looked like the comment was stale from the code, but I wanted to bring it up
<zyga> cool! I think we are in sync then
<zyga> I will go over all the things you mentioned on the next push, after tests turn green locally
<jdstrand> zyga: I do worry about an extra profile, but at least it is only an extra one per snap instead of an extra one per command
<zyga> yeah, it's not _that_ bad
<zyga> and it will allow us to be much stricter WRT securiy
<zyga> as it will allow us to essentially expand $SNAP_NAME and remove a lot of globs
<mup> PR snapd#4761 closed: osutil: handle file being matched by multiple patterns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4761>
<Chipaca> niemeyer: you still there?
<pedronis> cachio_: I'm going afk, can you leave me a note if you manage to update core edge in staging still today?
<cachio_> pedronis, I am running right now
<cachio_> pedronis, It took time because I am running in google
<cachio_> and I had to recompile spread with the latest changes
<pedronis> ah
<cachio_> pedronis, which issue do you see?
<cachio_> pedronis, tests failing?
<pedronis> cachio_: yes, some are missing snaps (that's ok, I'm just sanity checking something)
<pedronis> but I see a lot of
<pedronis> of errors about snap-update-ns
<pedronis> that I think is because core is too old
<cachio_> pedronis, ok, I'll send you an email with the results
<cachio_> ot a note here
<cachio_> as you wish
<pedronis> cachio_: so I think with a new core in edge copied from prod
<pedronis> errors should be mostly down to missing new snaps
<pedronis> that's my hope at least
<cachio_> pedronis, I copied the core 2 weeks ago
<cachio_> I'll copy the latest one
<pedronis> IÂ know
<pedronis> but layout happened since
<pedronis> IÂ think
<zyga> layotu?
<zyga> *layout?
<pedronis> zyga: I see a lot snap-update-ns errors when running tests against staging
<pedronis> given that doesn't relate to store
<pedronis> I suspect is just that staging edge core (that we tweak) is too old
<zyga> what does such an error look like?
<zyga> ah
<zyga> that's possible
<pedronis> because of layouts related changes
<pedronis> that's my theory atm
<zyga> layouts, perhaps, maybe snap-device helper change?
<zyga> do you have an error handy?
<pedronis> some permission denied when running snap-update-ns
<pedronis> seems IÂ lost the scroolback with the exact error
<zyga> if you get it I would love to see but yeah, I think getting staging in sync with prod would be useful
<nacc> niemeyer: is this part of the new c-n-f? https://paste.ubuntu.com/p/jb76TmdG3V/
<nacc> niemeyer: and if so, can i strongly request it be rethought? that's not user-helpful output
<pedronis> zyga: [Tue Feb 27 20:37:43 2018] audit: type=1400 audit(1519763863.485:46): apparmor="DENIED" operation="exec" profile="/snap/core/375/usr/lib/snapd/snap-confine" name="/snap/core/375/usr/lib/snapd/snap-update-ns" pid=17068 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<zyga> hmm
<zyga> if staging uses very old stuff then perhaps
<zyga> but this doesn't seem immediately layout-y to me
<pedronis> IÂ have no changes but related to store bits
<pedronis> and IÂ just rebased on master very recently
<zyga> ok
<pedronis> just seems the snap-confine is wrong/old
<pedronis> sorry, snap-confine profile
<pedronis> I can also try to run without my changes
<pedronis> but agains staging
<mup> PR snapd#4764 opened: configstate: when disable "ssh" we must disable the "sshd" service <Created by mvo5> <https://github.com/snapcore/snapd/pull/4764>
<pedronis> trying that
 * pedronis really needs to stop sitting for a bit
<stgraber> sergiusens: hey, for LXD with clustering we need to set some custom CGO_LDFLAGS and CGO_CFLAGS variables, is there a clean way to do so with snapcraft?
<Chipaca> stgraber: you can't do it with //cgo: stuff?
<stgraber> Chipaca: nope because that includes a filesystem path
<Chipaca> stgraber: I didn't follow, but I trust
<stgraber> Chipaca: I basically need to set something along the lines of:
<stgraber> CGO_LDFLAGS=-L/home/stgraber/data/code/lxc/sqlite/.libs/
<stgraber> CGO_CFLAGS=-I/home/stgraber/data/code/lxc/sqlite/
<stgraber> so an include and lookup path for the compiler and linker
<Chipaca> stgraber: and you can't convince it via PKG_CONFIG_PATH?
<Chipaca> if sergiusens isn't around maybe kyrofa knows
 * kyrofa jerks awake
<Chipaca> unless he's lost his beard
<stgraber> Chipaca: it's not using pkg-config so no
<kyrofa> Chipaca, don't joke, I think it'll be gone in the next few days. My newborn HATES it and I can't snuggle him at all
<Chipaca> kyrofa: I joke because I know :-)
<Chipaca> kyrofa: less joking, more making fun of you
<sergiusens> stgraber: we need to implement the build-env part attribute for this to work cleanly
 * kyrofa pouts
 * Chipaca hugs kyrofa 
<sergiusens> stgraber: so the sorried answer is, not yet
<kyrofa> Yeah, a local plugin could do it, but it's not quite as clean
<sergiusens> stgraber: while I have your attention though, is there a way to query lxd to if it has been through `lxd init`?
<mup> PR snapcraft#1941 closed: project_loader: handle invalid unicode chars <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1941>
<stgraber> sergiusens: not really because you can go through lxd init and not actually do any configuring :)
<stgraber> sergiusens: best to look for what you actually need the user to configure
<sergiusens> stgraber: ok, sounds good; I will probably be looking you up next week with a couple of things I'd like to solve wrt integration
<stgraber> ok
<sergiusens> we want lxd to be the default go-to setup for snapcraft
<mup> PR snapcraft#1927 closed: catkin plugin: extract Wstool into its own module <enhancement> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1927>
<Chipaca> ooh, ooh, can i also jump on the 'i am stgraber AMA'?
<Chipaca> stgraber: the 'container' env var set in lxd, is that part of a standard of some sort? does it nest? :_)
<Chipaca> lxc*
<stgraber> Chipaca: not sure who started it, we might have :) but yeah, liblxc will container=lxc, I think vserver, openvz and docker also set something
<Chipaca> should snaps set it, and should snaps running in lxc have something more complicated, and what if lxd is a snap :-)
<mup> PR snapcraft#1852 closed: Added a missing step in Hacking.md <codein> <Created by Tanesh1701> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1852>
<Chipaca> (i'm going to propose we expose it in PS1 in 'snap run --shell' if set, but might not if it's going to get messy)
<zyga> jdstrand updated update-ns PR
<zyga> jdstrand I added a comment that describes the changes made so that it is easier to follow
<jdstrand> thanks
<zyga> jdstrand I force-pushed to be friendlier to cherry-pick this
<pedronis> niemeyer: can IÂ be added to use the gce backend?
<zyga> jdstrand thank you!
<zyga> jdstrand tomorrow I'll prepare another single PR that changes layout-induced open rules to update-ns snippets
<zyga> jdstrand and hopefully there are no more FIXMEs for layouts left :)
<pedronis> jdstrand: did the spread snap work for you with gcloud?
<zyga> jdstrand I also added tests and extra escaping in https://github.com/snapcore/snapd/pull/4745
<mup> PR #4745: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745>
<jdstrand> pedronis: as it happens, I use the spread snap, but unconventionally. I download r35 and was able to run tests in gcloud, yes
<pedronis> jdstrand: I'm a bit confused because the creds are under ~/.config
 * zyga EODs
<zyga> this has been a good day :)
<pedronis> anyway I don't have access so it's moot :)
<jdstrand> pedronis: right, my dev environment is an lxd container. I don't run the spread snap, I download it, unsquash it and use the binary
<jdstrand> like I said, 'unconventional'
<jdstrand> :)
<jdstrand> zyga: thanks!
<pedronis> ah
<jdstrand> I could use spread git, but do it this way so I have released versions
<zyga> jdstrand the container has apparmor applied?
<jdstrand> zyga: no
<pedronis> jdstrand: I was really using the snap, but I see a problem now that needed creds are under ~/.foo
<jdstrand> well, it would except I have the 4.13 kernel
<jdstrand> pedronis: yes, that makes sense. you would need to copy your creds over to ~/snap/spread/current/... I guess
<niemeyer> pedronis: Yeah, everybody is in already
<niemeyer> pedronis: Just log in with your Canonical email using "gcloud auth application-default login" and spread should work
<pedronis> niemeyer: I see except that I was really using the snap,  and the creds are under ~ /.config
<niemeyer> pedronis: Oh, I see
<niemeyer> pedronis: The other alternative is to export the credentials json file (or just copy it I guess) and define SPREAD_GOOGLE_KEY as the filename
<niemeyer> pedronis: Should just equally well
<niemeyer> nacc: Yes, it should be something along those lines.. what's the part you feel strongly about?
<pedronis> niemeyer: yes, that works it seems
<niemeyer> pedronis: Sweet
<niemeyer> pedronis: Did you copy the file over or export it via the CLI?
<pedronis> I copied it
<pedronis> cachio_: sorry, I confused myself, these are the failures IÂ get: https://pastebin.ubuntu.com/p/JRVqzgkX9B/  so new snaps and core transition
<pedronis> which IÂ don't know if IÂ broke (I touch that code)Â or is a fluke
<pablo_> hi: it's beeing impossible to me to make a snap from a Qt/QML app i wrote. If i paste the *.yaml file in pastebin, could anyone help me a lil bit?
<nacc> niemeyer: it's totally contrary to what we have now
<niemeyer> nacc: Looks quite related to me.. still can't tell where your strong feelings come form
<niemeyer> from
<nacc> niemeyer: run 'deb jq' at your shell
<nacc> niemeyer: run 'snap jq' at your shell
<nacc> niemeyer: not at all what c-n-f emits now
<nacc> niemeyer: i've commented in LP: #1749777 for mvo
<mup> Bug #1749777: Syntax tweaks for snap-friendly output <command-not-found:In Progress> <command-not-found (Ubuntu):In Progress> <https://launchpad.net/bugs/1749777>
<niemeyer> nacc: Reading your comment, I guess what you mean is that the example command is not being shown?
<nacc> niemeyer: and command-like output that is not commands at all, instead
<niemeyer> nacc: This is command-not-found in 16.04:
<niemeyer> $ blah
<niemeyer> No command 'blah' found, did you mean:
<niemeyer>  Command 'blam' from package 'blam' (universe)
<nacc> niemeyer: it doesn't emit the 'sudo apt install ...' line?
<niemeyer> So there's nothing quite "contrary" here, or even so extremely different.. we are actually quite sensitive to not producing a lot of output on that command for obvious reasons, and we've already spent several hours discussing this exact issue.
<nacc> niemeyer: and, afaict, the cnf chagne is happening in bionic not xenial currently
<niemeyer> nacc: Right, it doesn't for this case
<nacc> niemeyer: it does on bionic for actual packages
<niemeyer> nacc: Because it favors compactness
<niemeyer> nacc: Not for this case either, I believe
<nacc> niemeyer: i think you're conflating things
<niemeyer> nacc: It hasn't changed
<nacc> niemeyer: there are two cases for cnf: mistyped commands and not-yet-installed commands
<nacc> i don't care about the former
<nacc> but the latter should not change in behavior because snaps are available
<nacc> and it has now
<niemeyer> nacc: No, I'm explaining the rationale.. command-not-found aims at producing compact output and helpful output.. now and in the past, when facing with too much data, it would choose sensible over writing command lines out
<nacc> niemeyer: but the case you provided is 100% *not* the case i'm talking about
<nacc> niemeyer: so, again, for a package that is available and you didn't typo, please don't regress the output
<niemeyer> nacc: Command lines, as demonstrated with actual output from 2016, were not paramount to its working..
<nacc> niemeyer: glad your opinion gets to decide this :)
<niemeyer> nacc: So the discussions we have today, preserve that aspect, and preserve the intention of being helpful and sensible in its output
<nacc> niemeyer: since it feels like policy which should go to ubuntu-devel-discuss
<niemeyer> nacc: Ironically, the output you see wasn't suggested by me
<nacc> niemeyer: you have not preserved the output, as i have put in teh bug
<niemeyer> nacc: My suggestion had more output, and I decide not to argue about it because I appreciate the short output
<nacc> niemeyer: more output than what?
<niemeyer> More output than what the latest proposal you are discussing presents.
<nacc> niemeyer: what i proposed is what is already in bionic
<nacc> or was until this latest upload published
<nacc> niemeyer: regular users do not necessarily even know what "deb" is
<nacc> niemeyer: you should never have exposed that in that manner
<niemeyer> nacc: There's no need to be so aggressive and confrontational when discussing ideas..
<niemeyer> nacc: Already in 2016, command-not-found might not present commands in certain cases.. we're tuning behavior, and I'm willing to discuss ideas for improvement as there's still time for that, but we need to be willing to look at the data and stop handling this as the end of the world.
<dpb1> sorry didn't know you were discussing here.  I just filed: https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1752185
<nacc> niemeyer: ok, i don't feel like i can actually have this discussion with you. I think you've made a bad UX decision, I've articulated my reasoning in the bug.
<mup> Bug #1752185: Formatting of command-not-found with snap addition could use cleanup <command-not-found (Ubuntu):New> <https://launchpad.net/bugs/1752185>
<niemeyer> nacc: That's understandable, thank you
<niemeyer> dpb1: Can you please copy over your comment to the original ticket
<dpb1> the original ticket == https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1749777 ?
<mup> Bug #1749777: Syntax tweaks for snap-friendly output <command-not-found:In Progress> <command-not-found (Ubuntu):In Progress> <https://launchpad.net/bugs/1749777>
<dpb1> niemeyer: ^
<niemeyer> dpb1: You are articulating the issue nicely.. I also don't like the header of those lines.. the listing is even okayish, but it'd be nice to have some better wording there
<niemeyer> dpb1: Yeah, the 777 one
<dpb1> k, will do
<niemeyer> Thanks!
<dpb1> ty, will follow the bug progress
<cachio_> pedronis, email sent with the restults
<cachio_> pedronis, all the tests passing with the new core
<cachio_> pedronis, using google backend
#snappy 2018-02-28
<mup> PR snapcraft#1961 closed: Sentry <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1961>
<mup> PR snapcraft#1962 closed: store: stringify message for StoreDeltaApplicationError <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1962>
<mborzecki> morning
<Faults> Goood Morning!
<mborzecki> mvo: morning
<mvo> hey mborzecki !
<mvo> mborzecki: good morning
<mborzecki> heh the timer services spread test is failing on 14.04, can't figure out why, cannot reproduce it in spread debug shell either even if i do `snap enable test-snapd-timer-service && snap disable test-snapd-timer-service` in a loop
<mborzecki> and the error does not make any sense `start snap.test-snapd-timer-service.random-timer.timer] failed with exit status 6: Failed to issue method call: Unit snap.test-snapd-timer-service.random-timer.timer failed to load: No such file or directory`
<mborzecki> hmm and we don't seem have any tests for enable/disable that touch services
<mvo> mborzecki: hm, I have not seen this error before
<mborzecki> mvo: this happens when i reenable the snap that has timer services, i'm adding a test right now to see if this happens also if there's just regular snap with services
<mborzecki> mvo: also, the start happens after enabling the unit, so somehow systemctl enable worked, but systemctl start does not
<zyga> hey mvo :)
<mborzecki> zyga: hey
<zyga> hey :-)
<zyga> man, I overslept
<mvo> mborzecki: hm, lets hope its not a general problem
<mvo> zyga: hey, good morning
<zyga> I got a failure of snap-service-refresh-mode
<zyga> reinstall did stop a service that shouldn't
<zyga> full log in https://api.travis-ci.org/v3/job/346989504/log.txt
 * zyga notices the extended reply on https://forum.snapcraft.io/t/lxd-issue-due-to-snap-confine-apparmor-profile/4203/19
<Jasem[m]> Can anyone help in this? https://forum.snapcraft.io/t/cannot-upload-to-store/4250/9
<Jasem[m]> i.e. why am I getting this external libusb symlink when I built with Snapcraft?
<zyga> kalikiana ^
<pedronis> hi
<mborzecki> pedronis: hey, morning
<pedronis> mvo: while trying to understand why the core transition tests failed with my new code, IÂ found an interesting thing about them
<mvo> pedronis: tell me more
<pedronis> mvo: since we have the base code we always install core when installing a new snap (if it's not there), even if ubuntu-core is there, so the two kind of test are the same now
<mvo> pedronis: oh, indeed
<pedronis> IÂ don't know if there is something to do
<pedronis> but IÂ was confused for a bit
<pedronis> (I found the problem with my new code)
 * mvo nods
<pedronis> mvo: we might want to remove of them, or merge them somehow
<pedronis> s/of them/one of them/
<pedronis> IÂ don't think at this point fixing the "bug" make sense
<mvo> pedronis: indeed, I would love to get rid of all of them but not quite yet (its an expensive test)
<zyga> and let them live there before they get removed
<zyga> pedronis did you push the fix for the timestamp issue to 2.32?
<pedronis> no
<pedronis> only master
<zyga> I just got this failure in a 2.32-based PR, perhaps it's worth doing so
<zyga> mvo I wanted to update you on layouts
<zyga> there is one PR that I asked you to co-review with jamie, that I would like to cherry-pick into 2.32
<zyga> there will be a follow-up today, building upon the concept, that will have a similar fate
<zyga> both of those should be cherry-picked into 2.32
<zyga> the changes are non-trivial so I wanted you to be aware of that
<mvo> zyga: what is the risk of breaking things there? i.e. is it a new feature (user mounts) or modifying exiting behaviour?
<pstolowski> mornings
<zyga> mvo a bit of both
<zyga> mvo snap-update-ns will now use per-snap profile
<zyga> mvo the follow-up PR will remove broadly open permissions and replace them with values that match the layout of a given snap
<zyga> as well as inject $SNAP_NAME (expanded) into many places that currently use a glob
<mvo> zyga: how critical is that? 2.32 already contains quite a bit of churn and its only 2 weeks away. I'm a bit concerned about adding things that might break
<mvo> zyga: maybe we can discuss in more detail in the standup?
<zyga> mvo pretty critical I'm afraid, jamie requested that to be in 2.32
<zyga> to avoid pretty-much unconfined snap-update-ns
<mvo> ok
<kalikiana> o/
<Chipaca> mo'in
<Chipaca> mvo: I'm off to the dentist's first thing, should be back for a late start (my 11am)
<mvo> Chipaca: hey, thanks
<mborzecki> https://github.com/snapcore/snapd/blob/master/wrappers/services.go#L250 daemon-reload should probably happen when we add service files, regardless of those being enabled or not, shouldn't it?
<mvo> mborzecki: yes, good catch
<zyga> hmm
<zyga> I'm seeing failres of snap-info
<mborzecki> zyga: oh, featured list changed again? or the install date?
<zyga> no, it is summary, it seems
<zyga> + snap info basic_1.0_all.snap /home/gopath/src/github.com/snapcore/snapd/tests/lib/snaps/basic-desktop test-snapd-tools test-snapd-devmode core /etc/passwd test-snapd-python-webserver
<zyga> + python3 check.py
<zyga> in test-snapd-tools.summary expected 'Tools for testing the snapd application', got ''
<zyga> starting local run now
<zyga> I doubt this is something that is broken in my branch as it is entirely unrelated
<mborzecki> btw. don't recall, do we do any testing with recentish nvidia cards?
<zyga> mborzecki sergio ran some tests remotely recently
<zyga> mborzecki not sure how recent the hardware was though
<mborzecki> hmm, the user that had the stack smashing detected on manjaro with nvidia drivers got back to me, he's seeing the problem on arch too, nvidia drivers 390
<mborzecki> i'll suggest him to open a topic in the forum, maybe jdstrand will be able to suggest something
<zyga> and indeed
<zyga> I don't get a summary
<zyga> https://pastebin.ubuntu.com/p/m5KQPxNSw4/
<zyga> any ideas anyone?
<zyga> description is also empty
<mborzecki> it's coming from the local snap.yaml i suppose
<ackk> mvo, hi, I'm getting this error https://paste.ubuntu.com/p/gTrF3Z8yTS/ when trying to rebuild the maas snap with the custom base-18. did something change in bionic?
<mborzecki> zyga: when it goes from the store there's both summary and description https://paste.ubuntu.com/p/3GZR5q5XJC/
<mvo> ackk: this looks like a snapcraft change, I wonder if it is not taking bases into account? it takes about core there
<mvo> ackk: maybe kalikiana can help with the above error (cc https://paste.ubuntu.com/p/gTrF3Z8yTS/)
<ackk> mvo, oh, I wonder if I'm usin an older version now (I used to use snapcraft from the snap)
<zyga> hmm, test-snapd-tools doesn't have a summary
<zyga> (or description)
<zyga> checking master now
<zyga> hmm
<zyga> it passed on master
<zyga> trying again
<zyga> and now my branch passed
<zyga> mvo there's something wonky going on, snap-info fails ~ 2/3 runs
<mvo> zyga: woah, for snap info - that is astonishing
<zyga> I don't understand it yet, running one test I saw a failure a moment ago
<zyga> now no failures for 3 runs
<mvo> zyga: only in tests? or also on a real system
<mvo> zyga: is this coming from the store or from the local snap?
<zyga> only in tests so far
<zyga> main/snap-info
<zyga> good question
<zyga> from the store
<zyga> maybe we hit different machine via load balancing
<zyga> and one gives wonky answers
<BjornT> mvo: do you know anything about this error? https://pastebin.canonical.com/p/mdnpq6rM7T/
<BjornT> mvo: it started happening recently (noticed it today), so i would suspect something changed in snapcraft
<BjornT> mvo: this is trying to build agains the base-18 on bionic
<zyga> mvo so on my bionic machine I just installed test-snapd-tools
<zyga> and it has a summary and desscription
<ackk> mvo, BjornT's error is the same as mine
<zyga> but just a moment ago inside a test I did the same and they were both empty (see the pastebin I sent earlier)
<ackk> mvo, BjornT I'm trying to build with snapcraft from the snap (rather then the bionic one) and it now gets stuck on priming
<pedronis> zyga: was the test using a different channel?
<zyga> no
<zyga> same test in a loop
<zyga> it doesn't fail now, maybe store got fixed now
<mvo> BjornT: I talked about this with ackk some minutes ago, it looks like snapcraft is not taking "base" into account when it warns about the glibc incompatibilities
<BjornT> mvo: any chance of getting it fixed (or a workaround) quickly? it's blocking maas development
<ackk> ah, the deb in bionic is newer than the snap stable version, I wonder if something broke there
<mvo> BjornT: that is a question for sergiusens and/or kalikiana - I am not working on snapcraft myself, sorry. but lets hope they get back to you quickly
<pstolowski> mvo, do you think #4762 could go o 2.31?
<mup> PR #4762: servicestate: use systemctl enable+start and disable+stop instead of --now flag <Created by stolowski> <https://github.com/snapcore/snapd/pull/4762>
<ackk> kalikiana, around? any suggestion on the issue above? ^
<zyga> I cannot reproduce snap-info error anymore
<zyga> so maybe just a temporary fluke
<zyga> pedronis is the store undergoing any updates now?
<pedronis> we reverted something IÂ think
<pedronis> don't know if it was related
<mvo> pstolowski: definitely 2.32, I think I will also cherry-pick to 2.31 just to be on the safe side
<zyga> mvo 4760 is ready for your review now
<mvo> zyga: must be later todday, I need to meet the feature freeze deadline for c-n-f
<zyga> mvo understood
<zyga> mvo curious, will you still tweak the output?
<mvo> sorry!
<zyga> I really didn't like the odd output I saw last night?
<mvo> zyga: tweak the output of c-n-f ?
<zyga> yes
<mvo> https://bugs.launchpad.net/command-not-found/+bug/1749777 has the latest agreements as-i-understand-them
<mup> Bug #1749777: Syntax tweaks for snap-friendly output <command-not-found:In Progress> <command-not-found (Ubuntu):In Progress> <https://launchpad.net/bugs/1749777>
<mvo> zyga: there is a bit of controversy still but its difficult to find a solution that makes everyone happy, we discussed that quite a bit
<zyga> what bugs me the most is that the mixed advice there doesn't give instructions on how to do anything about installing it
<mvo> zyga: indeed, I think we did a pad with some clever ideas, just need to find it
<zyga> mvo I made a trivial suggestion
<zyga> https://bugs.launchpad.net/ubuntu/+source/command-not-found/+bug/1752185/comments/3
<mup> Bug #1752185: Formatting of command-not-found with snap addition could use cleanup <command-not-found (Ubuntu):Confirmed> <https://launchpad.net/bugs/1752185>
<mvo> zyga: https://pad.ubuntu.com/1C0cSZX9oB
<mvo> zyga: sure, that is welcome
<zyga> mvo is "this is what we will do" part true?
<zyga> as in, that's the thing you will code
<pstolowski> mvo, ack
<mup> PR snapd#4762 closed: servicestate: use systemctl enable+start and disable+stop instead of --now flag <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4762>
<mvo> zyga: it was true
<mvo> zyga: and then this bugreport with another version of the syntax came along
<mvo> zyga: that was the outcome of a long(ish) meeting with john and gustavo, I think the result is good but its also noisy, the idea from mark has the advantage that its very compact
<zyga> I think it just hast to be useful and feel good
<zyga> good luck on that
<kalikiana> ackk: Sorry, I was in a call. Looking in a moment
<ackk> kalikiana, thanks
<kalikiana> BjornT: What Snapcraft are you building with? Edge? There've been some recent fixes on master although base support is still a work in progress. I'd defer to sergiusens here since he's working on that.
<ackk> kalikiana, I've been using stable, I'm building with edge now
<ackk> kalikiana, priming now seems to take a very long time
<ackk> kalikiana, it fails with edge as well
<ackk> kalikiana, so, stable does seem to take into account bases, edge (or bionic package) doesn't
<ackk> BjornT, kalikiana even no-system-libraries fails for me
<BjornT> kalikiana: i'm using git master to build the snap. using no-system-libraries takes me further. it still prints out warnings and i get a snap. but now i get python import errors when trying to run the snap. it seems that /usr/bin/python3 is used, which doesn't have my python modules
<cachio_> pedronis, hey, running again the tests against stagin
<cachio_> g
<pedronis> cachio_: no, need, I did this morning
<pedronis> also there's a problem with staging
<pedronis> we are trying to fix
<cachio_> pedronis, ok, so many errors?
<pedronis> yes, not  a lot
<pedronis> but more that there should be
<cachio_> pedronis, ok, I am making a run now
<cachio_> pedronis, I already started it
<pedronis> ok
<mpt> Is it possible to have multiple versions of a snap installed simultaneously?
<zyga> mpt not yet but Chipaca is working on that
<mpt> ah, cool
<Chipaca> no i'm not
<Chipaca> :)
<Chipaca> but i will be, next
<Chipaca> or, rather, that's the next big thing i'll be working on
<mup> PR snapd#4765 opened: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<mup> PR snapcraft#1964 opened: Fix Store integration tests with updated snap name registration error messages (take 2) <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1964>
<zyga> I need some reviews
<zyga> for this (last patch only)
<zyga> and the one before
<zyga> anyone interested
<zyga> this one is actually trivial
<zyga> https://github.com/snapcore/snapd/pull/4765/commits/caafe76f4c3040426573b81def2a645119c68451
<mup> PR #4765: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<mpt> Chipaca, ok. When you do have multiple versions installed, will they always have access to the same interfaces? Or will it be possible to differentiate? (for example one version has access to the camera while the other doesnât)
<Chipaca> mpt: as I understand it they'll be separate entities as far as that aspect of things
<Chipaca> mpt: but there isn't even a forum topic about it yet, so it's rather green
<mpt> Chipaca, thanks. (Reason Iâm asking is, that means theyâll need to be listed separately â and disambiguated â in GUIs for seeing/changing what permissions they currently have.)
<Chipaca> mpt: (if you feel strongly one way or the other now'd be an ideal time to bring it up :-) )
<cachio_> pedronis, I uploaded 3 snaps to staging
<cachio_> pedronis, it should fix the 3 failing tests that I swaw
<cachio_> I0ll re run to see we have 100% passing
<BjornT> kalikiana: fwiw, i tried this patch: https://paste.ubuntu.com/p/s2t3wct5J3/
<BjornT> kalikiana: the maas snap builds then, but then the configure hook complains: https://paste.ubuntu.com/p/G3dsTh33Fg/
<BjornT> kalikiana: libssl.so.1.1 is in the snap, though
<BjornT> kalikiana: btw, LD_LIBRARY_PATH doesn't seem to be set
<mup> PR snapd#4766 opened: userd: add an OpenFile method for launching local files with xdg-open <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4766>
<zyga> Chipaca have a look at 4755 please
<cachio_> mvo, still working with sru
<cachio_> I see some denials
<cachio_> https://paste.ubuntu.com/p/6WJfXd952Q/
<cachio_> zyga, I am tesintg on google and I see bionic has not SElinux enabled
<zyga> cachio_ why would it be enabled?
<cachio_> zyga, well, hte problem is that we are trying to uninstall snapd_selinux package
<cachio_> and it is failing
<zyga> that package only exists for fedora
<cachio_> the package is not installed
<zyga> why would we do that?
<cachio_> we do that in the upgrade test
<cachio_> ok, in that case something else is wrong
<cachio_> zyga, after remove and reinstall snapd
<zyga> there's no such package in ubuntu or anywhere else but fedora
<cachio_> zyga, I see all the snaps broken
<zyga> so probably some wrong pattern somewhere
<cachio_> zyga, ok, thanks!!
<Chipaca> zyga: you sure you meant to ask me to look at my own pr?
<zyga> yes :) meant to look at the feedback
<Chipaca> zyga: I think I'll just replace it with a MatchCounter
<Chipaca> the gist of this pr predates that :-)
<mup> PR snapd#4767 opened: interfaces: disconnect hooks <Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<mup> PR snapd#4763 closed: osutil: handle file being matched by multiple patterns (2.32) <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4763>
<jdstrand> zyga: hey, I approved PR 4745
<mup> PR #4745: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <https://github.com/snapcore/snapd/pull/4745>
<zyga> jdstrand hey, thank you!
<jdstrand> zyga: I looked at PR 4765, but I think the rules need tuning. lots of apparmor denieds
<mup> PR #4765: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<zyga> jdstrand I'm going through hardening, got slowed down by store issue in the morning but now I'm iterating quickly
<zyga> yes, I'm fixing that now
<jdstrand> ok
<jdstrand> I've added it to my list. when it passes automated tests, I'll look at it
<zyga> thanks!
<mup> PR snapd#4745 closed: osutil: allow creating strings out of MountInfoEntry <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4745>
<mvo> cachio_: hm, wonder if snapd-app-helper in our installed profile
<mup> PR snapd#4768 opened: [RFC] snap userd autostart v2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4768>
 * kalikiana lunch time
<Chipaca> sergiusens: kyrofa: snapcraft#1964 fixes your integration tests vis-a-vis new validation failure messages
<mup> PR snapcraft#1964: Fix Store integration tests with updated snap name registration error messages (take 2) <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1964>
<sergiusens> mvo: BjornT no, becuase I asked what the official bases would be named (you are CCed in that email mvo) to actually work on this ;-)
<sergiusens> Chipaca: maxiberta is the integration store server updated to follow these strings? Once this is updated, all the store triggers will fail until updated, are you aware of that?
<Chipaca> sergiusens: what's the 'integration store server'?
<Chipaca> sergiusens: and what are 'store triggers'?
<mup> PR snapcraft#1963 closed: Fix Store integration tests with updated snap name registration error messages <Created by maxiberta> <Closed by maxiberta> <https://github.com/snapcore/snapcraft/pull/1963>
<sergiusens> Chipaca: OLS triggers pre-deployment tests using our test suite against the integration/staging store
<Chipaca> sergiusens: ah! that's why maxiberta wrote the first PR (which didn't address the whole issue)
<sergiusens> Chipaca: yeah, but this is chicken and egg problem unless we allow dual results in the tests :-)
<mvo> sergiusens: core18
<mvo> sergiusens: will be the name
<mvo> sergiusens: but there might be more
<Chipaca> sergiusens: â¦ the code with the new errors is on staging
<Chipaca> sergiusens: maybe I'm not understanding something
<sergiusens> Chipaca: oh, I am asking, I am not stating :-)
<sergiusens> Chipaca: let's make this simple, cprov can you +1 https://github.com/snapcore/snapcraft/pull/1964 :-)
<mup> PR snapcraft#1964: Fix Store integration tests with updated snap name registration error messages (take 2) <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1964>
<Chipaca> sergiusens: maxiberta is probably the person to answer, then
<Chipaca> I am far from understanding all the links, I just dived in there and broke stuff
<Chipaca> :)
<maxiberta> the new strings are already deployed on staging Store
<cprov> sergiusens: production rollout is in progress, the changes matches what we have in production
<sergiusens> mvo: is there a forum post or something where everyone +1s? I thought that was the process for bases. I would really like to see general agreement for this as it would be really hard for us to change this (wrt SRUing) if this changes
<cprov> *will* have in production in a few minutes
<sergiusens> cprov: great, then in it goes
<cprov> thank you
<zyga> pstolowski, niemeyer: when you talk about "snap connections", I'd love to participate
<maxiberta> thanks Chipaca, sergiusens
<pstolowski> zyga, sure. but i think i'll go with something straighforward as outlined by nimeyer during the standup, not sure we will discuss it more
 * pstolowski lunch
<mup> PR snapcraft#1964 closed: Fix Store integration tests with updated snap name registration error messages (take 2) <bug> <Created by chipaca> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1964>
<Chipaca> sergiusens: what is the 'assigned' thing github tells me when you merge stuff?
<Jasem[m]> I'm getting error when uploading a snap to the store
<Jasem[m]> package contains external symlinks: usr/lib/x86_64-linux-gnu/libusb-1.0.so lint-snap-v2_external_symlinks
<sergiusens> Chipaca: just my internal way of making sure later who worked on what to backtrack and provide a thank you drink ;-)
<Jasem[m]> But the package was built with snapcraft, isn't suppose to take care of such links?
<sergiusens> Jasem[m]: some snaps are allowed some symlinks, so we cannot remove them "magically" or part of the building populus might be unable to create snaps in the first place
<Jasem[m]> Chipaca: well, any idea how to resolve this problem then?
<sergiusens> you can use `stage` or `prime` keywords to filter it out, but somehow I think the actual package from the archive in this case might be problematic as .so files are usually linked directly to a .so.<version> in the same directory (and this one seems to be using an absolute path)
<cachio_> mvo, did you see the denial on the sru?
<cachio_> mvo, I have a debug open
<niemeyer> zyga, pstolowski: We should definitely have talk about it before spending much time on one direction
<niemeyer> Forum is great for that
<niemeyer> Chipaca: Just responded on that thread
<Chipaca> niemeyer: appreciated
<mup> PR snapd#4769 opened: wrappers: detect whether systemd-analyze can be used in unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4769>
<Chipaca> niemeyer: can we line up the 'days' to make scanning easier?
<niemeyer> Chipaca: think  it'll look awkward in the general context
<niemeyer> Chipaca: Similar issue we had with "installed" (the version)
<niemeyer> Chipaca: Also, "today" and "yesterday" won't align either
<Chipaca> true dat
<Chipaca> the former is less a concern now that the first indent isn't all uniform
<Chipaca> (for the best i think)
<Chipaca> but, it's not like we're oging to have 10 of these lines :-) so i'm just being a nit
<Chipaca> niemeyer: thanks
<niemeyer> Chipaca: np, thanks for calling it out
<zyga> mmmm
<zyga> pierogi :-)
<zyga> I missed that
<zyga> jdstrand 4765 is green now
<zyga> if you look at the 2nd patch there the review is easier
<mvo> cachio_: yeah, so about the denial> what do you see with " grep device-helper /etc/apparmor.d/usr.lib.snapd.snap-confine.real "
<cachio_> mvo, empty
<mvo> cachio_: hm, that sucks
<mvo> cachio_: if you grep for udev in there, what do you get?
<mvo> cachio_: and please also grep for usr.lib.snapd
<jdstrand> zyga: ack
 * cachio_ afk
<zyga> mvo that's weird
<zyga> what's on bionic?
 * zyga finished with pierogi and gets back to hardening
<mvo> zyga: it looks like something is wrong with the apprmor profile, but its strange
<zyga> hmm, didn't we have something like that a moment ago
<mvo> zyga: oh, actually - 2.31 still have udev/snappy-app-dev
<zyga> the device-helper rules went away
<zyga> hmmmm
<zyga> what was that
<zyga> ah
<zyga> I remember now
<zyga> but that was for a re-exec rule
<zyga> and just for testing scenarios
<zyga> not for real-life issues
<zyga> and in either case, we fixed that one
<zyga> so ...
<zyga> no idea, I'll go back to hardening
<mvo> cachio_: do you have more context about the sru error? I see the denial but in what test is that happening? what is odd is that on 2.31 we have /lib/udev/snappy-app-dev - we moved to snap-device-helper only in 2.32
<mvo> cachio_: just let me know when you are back, happy to look at this then
<pstolowski> niemeyer, zyga ok!
<ikey> ok jdstrand whats a good non-conflict definition to copy for an interface?
<zyga> to copy for an interface?
<zyga> what does that mean?
<ikey> like for making a new interface
<zyga> ah
<zyga> you wanna start with something and iterate
<ikey> whatever it is i went with last time was wonky
<zyga> start with common
<zyga> then see what you miss
<zyga> most things are fine with common
<ikey> my actual definitions were fine for apparmor and seccomp
<ikey> its the actual interface struct that was wonky
<ikey> which seems woefully undocumented
<zyga> no no, just use commonInterface
<pedronis> zyga: I'm getting this kind of error:  cannot update snap namespace: cannot create writable mimic over "/opt": permission denied
<pedronis> snap-update-ns failed with code 1
<ikey> i c
<zyga> pedronis on /opt?, hmmm that's weird
<zyga> do you have the full log
<pedronis> I get this:  [Wed Feb 28 14:44:11 2018] audit: type=1400 audit(1519829052.799:113): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="/snap/core/409/usr/lib/snapd/snap-confine//snap_update_ns" name="/tmp/.snap/opt/" pid=14715 comm="3" srcname="/opt/" flags="rw, rbind"
<ikey> so yeah im using commonInterface.
<ikey> i think this is what causes the problem: https://hastebin.com/wonojepoqo.cpp
<ikey> but i honestly have nfc what it means
<ikey> i copy pasted from something else a while back
<zyga> pedronis do you have this line in the profile:
<zyga>   mount options=(rbind, rw) /** -> /tmp/.snap/**,
<pedronis> that IÂ don't know
<pedronis> it's a full run
<zyga> is it just a log?
<zyga> ah
<zyga> drat
<zyga> no idea
<zyga> it looks like we start and we have the wrongest profile ever
<zyga> I saw this with /etc
<zyga> maybe it's the same bug that mvo saw as well
<zyga> as something clearly puts the wrong profile (like very old one) around us
<pedronis> zyga: maybe you can add debug:Â to print the profiles to main/layout ?
<zyga> maybe one of the migration tests reaks t he backup
<zyga> yeah, good idea, I'll do that
<zyga> *breaks the backup
<ikey> zyga, any thoughts on that paste?
<zyga> ikey oh, I didn't notice
<zyga> looking
<zyga> ikey and what's the problem?
<ikey> its borked
<zyga> so
<ikey> so it was working on our existing snapd installs
<ikey> but for *new snapd users* it bricked core
<zyga> those are rules that say what can be done with an interface
<ikey> right and i cant find any *usable* documentation on it
<zyga> bricked coreR?
<ikey> ya
<ikey> core couldnt be installed
<zyga> allow-installation: false
<zyga> is this an implicit interface?
<ikey> idk what that means either
<ikey> again, documentation, lol
<zyga> the rules are basically saying what you can and cannot do
<ikey> ive been asking about this for months now..
<ikey> its the steam-support interface that gives permissions to the steam snaps
<ikey> and ideally we only want those to use it
<ikey> but apparently thats all private store side behaviour
<zyga> they get enforced by the policy checker
<zyga> look at basedeclaration.go
<ikey> ya ive read it
<zyga> there's a lot of documentation there
<pedronis> cachio_: hi, afaict we need newer versions of test-snapd-content-plug/slot in staging
<ikey> lots of words that dont really explain anything to anyone outside the inner circle
<zyga> ikey so maybe I can help you out in practice
<zyga> tell me about the interface you're working on
<zyga> is it going to be added by core implicitly
<zyga> or will it live in a specific snap
<cachio_> pedronis, ok
<cachio_> 1 minutes
<pedronis> thank you
<ikey> zyga, its the interface that will be added to snapd to give the permissions for steam to run
<ikey> so linux-steam-integration would connect to it
<ikey> and pop holes in the sandbox
<zyga> ikey who will have the slot side?
<ikey> ?
<zyga> is it going to be linux-steam-integration snap itself
<ikey> ya
<zyga> or is that going to be on core?
<ikey> what
<zyga> I mean, look at network interface
<pedronis> cachio_: IÂ have all the other tests passing also with my code  (except layout but that sort of weird fluke IÂ have seen prod spread too)
<ikey> ok see now you're confusing me again
<ikey> there is no documentation on this difference
<zyga> the core provides is (the slot) and anyone can get a plug and connect
<ikey> just assumptions of prior knowledge and examples
<zyga> the network interface is "implicit" so it gets automatically added to the core snap (as a slot)
<ikey> i dont use core snap
<cachio_> pedronis, perfect
<ikey> this is for solus-runtime-gaming + linux-steam-integration..
<zyga> another idea is to have a special interface that is not on the core snap (the slot) and is actually added, directly, in meta/snap.yaml in some snap
<ikey> remember solus-runtime-gaming is a base snap
<zyga> ikey sure but even if you don't use the core snap the interface has a plug and slot side and both plugs and slots must inhabit *some* snap to exist
<zyga> so
<zyga> my question is: who has the slot side of this new interface
<ikey> at this point i genuinely dont know the different between slot and plug
<ikey> because the terminology is grossly conflated
<zyga> depending on the answer to that question we can determine the policy that will make it work
<ikey> linux-steam-integration is the snap that *uses* steam-support
<zyga> ikey a plug and a slot is just two ends of a wire
<ikey> yes i know that but which ends go were aren't exactly well defined
<ikey> case in point, core
<zyga> typically the slot side is the offering end
<zyga> it provides some service or capability or other thing
<ikey> ok well in the plugs in snap.yaml we add steam-support
<ikey> cuz we need it there.
<zyga> until you connect the plug side to the slot side, the plug side cannot consume that thing and doesn't get permissions
<zyga> ok
<ikey> for linux-steam-integration
<zyga> ok
<zyga> so I suspect the slot side of steam-support is going to exist on the core snap (again, just for the sake of having to exist somewhere)
<cachio_> pedronis, test-snapd-content-plug updated
<ikey> so "core snap" in this context really meaning "snapd" ?
<zyga> but I may not be fully up to date on your discussions with jamie
<zyga> ikey the long story short
<zyga> no, the core snap
<ikey> but i dont use core snap..
<zyga> it's all in snapd code but the core snap is the thing that can host implicit slots
<cachio_> pedronis, the test-snapd-content-slot seem to be already in the last rev
<pedronis> cachio_: ok, good, wasn't sure
<pedronis> thank you
<pedronis> I'll try the one tests again
<zyga> it isn't relevant, it's the same as you use the "network" plug in your apps and then even if you use a different base snap you get the network permission parts from this connection
<zyga> ikey to fix your problem:
<ikey> ok
<ikey> so core defines /things/
<zyga> ikey drop the allow-installation: false line
<ikey> what about those deny ones?
<ikey> i assume we want autoconnect defined by store right?
<zyga> and if I'm wrong and the slot side is going to be in a dedicated snap, you need to have this pre-arranged with jdstrand
<zyga> yes
<ikey> slot side meaning .. ?
<zyga> the deny connection and deny auto connection look fine
<ikey> ok
<ikey> i dont "use" slots anywhere btw
<zyga> the "slot side" is "the name of the snap that will ship something that looks like slots: steam-support"
<ikey> just plugs
<zyga> do you have any connection-based rules in that interface?
<ikey> https://hastebin.com/qoqozopire.bash <- is what i have
<zyga> if you have a longer pastebin with the diff, I could look
<zyga> ha :D
<zyga> thank you
<zyga> steamSupportConnectedPlugSecComp
<zyga> so the name here says it all
<zyga> this is what the *plug* side gets after connecting (to a slot side) in terms of seccomp permissions
<ikey> (not really its a copy paste job :P)
<ikey> right
<zyga> and I see you have "implicitOnCore"  and "implicitOnClassic"
<ikey> ya, copy paste
<ikey> i have no idea what it does
<ikey> :P
<zyga> (yeah but my point was that those are still connection oriented concepts)
<ikey> righto
<ikey> i believe the original notion was to block any snap in the store autoconnecting steam-support
<ikey> due to the holes it exposes
<zyga> ok, if you drop the line I mentioned (allow-installation) it should move on
<zyga> yeah
<ikey> cuz the whole ptrace kerfuffle
<zyga> then specific snaps will get an assertion that say it can connect to steam-support
<ikey> like linux-steam-integration ^^
<ikey> im copying this log down locally for notes btw :P
<ikey> ok so nuke that line, rebase onto git, and new PR
<zyga> cool! :)
<zyga> see if it works for you
<zyga> not sure if anything else is missing
<ikey> well that was the only issue was ran into
<ikey> fresh snapd went to fetch core for the first time
<ikey> and complained loudly about steam-support
<ikey> obviously its a fairly nasty interface in that it "extends" another
<ikey> alright cheers ima go do that
<zyga> cool, good luck
 * zyga replied on the LXD issue and prepares a patch for the layout bug and writes more hardening patches 
<zyga> zyga.fork().fork().fork()
<ikey> lol
<ikey> cgroups chase you
<zyga> cgroups are lovely
<zyga> until 2.0 that is
<ikey> xD
<pedronis> cachio_: interfaces-content now passes
<zyga> pedronis what did you chagne?
<zyga> *change
<pedronis> zyga: this was about wrong snap revision
<pedronis> zyga: that failure was from main/layout
<pedronis> IÂ mean nothing to do with the thing we discussed about /opt
<zyga> ack
<mvo> cachio__: forum post about this problem that snap-confine runs /lib/udev/snappy-app-dev from the core snap which is a symlink in the beta core which leads to the apparmor denails that you saw on the SRU verification
<mvo> cachio__: I'm not sure what the right fix is. I'm also not sure why we run the snappy-app-dev inside core and if we have to do that
<mvo> zyga: I guess you don't remember why we run snappy-app-dev inside core - maybe we need to run it late when we are already inside this env. but it might mean we can never rename snappy-app-dev :/
<mup> PR snapd#4770 opened: store: parse the JSON format used by the coming new store API to convey snap information <Created by pedronis> <https://github.com/snapcore/snapd/pull/4770>
<zyga> why we run snappy-app-dev inside core, I think that's easy
<zyga> because we do that after we pivot root
 * zyga looks
<zyga> yeah
<zyga> we do that super late
<zyga> hold on
<zyga> we _can_ rename
<zyga> we just have to be less direct
<zyga> we can try the new name first
<zyga> and if it's not there, fall back
<zyga> and allow both in apparmor
<zyga> it's like renaming snap-exec to snap-make-it-so
<zyga> just
<zyga> make it so
 * zyga swooshes away
<mvo> zyga: right, but it means we need a transiton time where the appamor profile is updated
<zyga> yes
<mvo> zyga: which means we probably need to revert the rename for 2.32
<mvo>  /o\
 * zyga thinks
<zyga> so
<zyga> 2.32
<zyga> is this for revert?
<zyga> or from reexec from stable deb
<mvo> zyga: it is for when you run 2.31 and disable re-exec. then 2.31 snap run will run the 2.31 snap-confine which will not have the right rule yet
<mvo> zyga: for 2.31 with re-exec everything is fine because then the right snap-confine with the correct profile runs
<zyga> wait I don't follow
 * mvo waits
<zyga> so
<mup> PR snapd#4771 opened: store: add Store.InstallRefresh to support the new install/refresh api endpoint <Created by pedronis> <https://github.com/snapcore/snapd/pull/4771>
<zyga> 2.31 is in the deb or in the core snap in your example?
<cachio__> zyga, we install 2.31.1 from deb
<zyga> ok
<cachio__> and the core snap is the one in beta 2.32
<cachio__> and it is set
<zyga> so 2.31.1 deb, with all the right snap-confine profiles, installs core and gets 2.32
<cachio__> SPREAD_MODIFY_CORE_SNAP_FOR_REEXEC=0 SPREAD_TRUST_TEST_KEYS=false SPREAD_SNAP_REEXEC=0 SPREAD_CORE_CHANNEL=beta
<zyga> mvo so far so good?
<zyga> mvo is that accurate?
<mvo> zyga: sorry, 2.31.1 is in the deb, 2.32 (with the rename) is in the core snap
<zyga> ok
<zyga> so far so good
<zyga> and that so far works
<mvo> zyga: with *no* reexec
<zyga> then we disable reexec, right?
<mvo> zyga: correct
<zyga> ah
<zyga> I see
<zyga> but
<zyga> ahhh
<zyga> we have a compat symlink?
<zyga> nothing more?
<mvo> zyga: correct
<mvo> zyga: aha!
<zyga> ok
<mvo> zyga: so we just install the real thing :) ?
<mvo> zyga: smart!
 * mvo hugs zyga
 * zyga hugs mvo back and thinks about what the solution is
<mvo> zyga: didn't you just suggest the solution?
<zyga> mvo you made the solution, I'm just the garden thing :)
<zyga> haha, I apparently did b
<zyga> but you get it and I'm still processing
<mvo> zyga: if we install the real thing in two places
<zyga> yes
<zyga> that will work
<mvo> zyga: nstead of a symlink it should work
<ikey> i seem to remember you guys mentioned this being fixed somewhere: go build github.com/snapcore/snapd/cmd/snap-seccomp: invalid pkg-config package name: --static
<ikey> any pointers?
<zyga> ikey ah, that's the golang security SNAFU
<zyga> i think we reverted the --static linking in master
<ikey> oh right
<zyga> and do soma hackery in ubuntu builds to restore it manually
<ikey> o
<zyga> but I didn't do that so no good links
 * ikey hits up https://github.com/snapcore/snapd/commits/master/cmd/snap-seccomp
<ikey> https://github.com/snapcore/snapd/commit/536f30bebcbaca8b391919afbda8dd67b360d45d.patch
<ikey> heh
<mup> PR snapd#4772 opened: tests/lib/fakestore/store:  teach the fake store to fake the new install/refresh endpoint <Created by pedronis> <https://github.com/snapcore/snapd/pull/4772>
<zyga> mvo I was thinking about a bind mount becase that fools apparmor
<zyga> but installing twice is just perfect
<zyga> +10
<ikey> iirc we really /should/ force static linking on seccomp right?
<zyga> it's complex
<zyga> sometimes yes
<ikey> i seem to remember it giving heartattacks to apparmor
<zyga> but it depends on the context
 * ikey finds a lump hammer
<ikey> bye freenode
<zyga> hmm?
<ikey> hi freenode. >_>
<zyga> was that a bouncy hammer?
<ikey> lol wasnt me i swear
<ikey> this seems to make it work:
<ikey>     GOPATH="`pwd`" go build -o bin/snap-seccomp --ldflags '-extldflags "-static"' -v github.com/snapcore/snapd/cmd/snap-seccomp
<zyga> ikey of *course* it does
<zyga> programming is so logical
<ikey> XD
<ikey> ok well it builds at least
<ikey> lets see the verdict ..
<ikey> zyga, it might make more sense if i reopen my original PR and submit the fix-commit on top?
<ikey> this way we preserve the old discussions
<zyga> yeah, that'd be great
<ikey> and then if someone wants to chuck the rebase on top, go for gold
<ikey> we'll see if github likes the notion of merging first
<ikey> ill get runtime-snaps changed over in git and wean them off devmode
<ikey> zyga, https://github.com/solus-project/runtime-snaps/commit/d3e3e6c0e231b3e09081a603296331a0e97917e7 :p
<zyga> arses in gear
<zyga> that's the spirit
<ikey> lol
 * zyga googles what that means
<zyga> does it mean
<ikey> literally just get moving and stop stalling
<zyga> "let's get off our ass and do an interface"?
<ikey> right
<zyga> very graphic :)
<ikey> mm
<zyga> as we literally didn't move much
<zyga> to write this
<ikey> alright in theory i can install the (very old) runtime
<ikey> and just build a new sideloaded snap app
<ikey> and then test they havent died
<ikey> i.e. regressed from the last time
<ikey> and that should be all good in the hood for sending
<ikey> can snaps hit the store prior to the interfaces being generally available btw?
<ikey> i want to kill the old snaps with fire
<zyga> I don't know
<ikey> guess we'll find out eh
<zyga> I suspect it will be flagged for manuak
<pedronis> I started proposing some PRs for the new api
<zyga> manual*
<ikey> sudo ./mkapp.sh  193.03s user 40.57s system 46% cpu 8:25.21 total
<ikey> not bad :o
<mup> PR snapd#4773 opened: tests: add debug for layout test <Created by zyga> <https://github.com/snapcore/snapd/pull/4773>
 * zyga read that tonight parts of poland will go to -24C
<ikey> :o
<zyga> so close
<zyga> I remember going to high school one day (during daytime) when it was -25
<zyga> but it was before we all had phones
<zyga> so nobody knew the school is closed
<zyga> so I went back and forth
<ikey> oof
<ikey> btw is the store seeing traffic issues lately?
<ikey> only hitting 2.30mbs on a download
<ikey> (100mbps connection)
<zyga> dunno
<zyga> download is from CDN
 * ikey blames snow
<mup> PR snapcraft#1965 opened: tests: remove ProjectOptions dependency from integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1965>
<ikey> ok looking good
<ikey> steam client is downloading..
<ikey> (had to manually snap connect ofc :))
<ikey> zyga, https://ibin.co/3tHZHjqBVVBh.png :)
<zyga> I need to refresh my steam game collection
<zyga> but ... all the patches
<zyga> ikey nice :-)
<ikey> ok so i reopened old PR, added the new commit on top
<mup> PR snapd#4538 opened: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
<ikey> ty, bot
<cachio__> zyga, do you have a5 minuts to see something?
<zyga> sure
<sergiusens> niemeyer: here's a first start on the ref https://forum.snapcraft.io/t/snapcraft-yaml-reference/4276
<cachio__> zyga, hold on, I can't find the pass for the vm on google backend
<niemeyer> sergiusens: Sweet, thank you!
<niemeyer> sergiusens: The formatting is a bit strange, but with that material we should be able to easily play until we find something comfortable
<sergiusens> niemeyer: as a first draft I welcome any suggestions
<niemeyer> sergiusens: I'm not even sure what to suggest at this point.. not obvious to me either.. but now that we have the material it's easy to play.. I'll have a try later today
<sergiusens> niemeyer: I tried to mimic the google docs we had, the table width should be modifieable with some CSS (on the forum at least)
<niemeyer> sergiusens: I'd prefer to not play with the width.. if we're going too wide, it's not going to be comfortable to read
<niemeyer> sergiusens: See the introductory material for example (Getting started, etc).. the width feels pretty reasonable
<p7f_> hi: could someone help with creating a Qt/QML snap? nothing i found in internet worked for me
<sergiusens> niemeyer: yeah, that one does look good :-)
<cachio__> zyga, any idea what could be causing that problem?
<zyga> no
<cachio__> zyga, it is just happening on bionic
<zyga> see if this is package update scripts
<zyga> or something the test is doing
<zyga> I don't know
<cachio__> zyga, ok, I'll start with the update scripts
<cachio__> tx
 * kalikiana heading out
<sergiusens> cprov: some store things seem broken https://travis-ci.org/snapcore/snapcraft/jobs/347284826
<cprov> sergiusens: let me take a look
<cprov> sergiusens: pexpect timeout don't tell us much about what is failing :-/
<niemeyer> pedronis: Where's account "title" coming from?
<pedronis> niemeyer: it's the display-name
<niemeyer> pedronis: We have "username" and "display-name" in the account assertions
<sergiusens> cprov: yeah, I know, these silent tests are killing me in the sense that we never really know what goes on, elopio can we get this one fixed?
<niemeyer> pedronis: That's also how we generally referred to those filed, I think?
<niemeyer> pedronis: A person's "title" is something else (Ms., etc)
<cprov> sergiusens: I can only think of some issue with the test creds, tests are passing locally against staging -> https://pastebin.canonical.com/p/XfPbxgWHg7/
<pedronis> niemeyer: I think they come from wgrant/nessita, these names
<niemeyer> pedronis: Sure, I mean in terms of design :)
<sergiusens> cprov: thanks, I'll leave it to elopio then
<pedronis> niemeyer: I need to have dinner, I'm personally fine either way,  I'm not quire sure why s/display-name/title/
<niemeyer> pedronis: Okay.. let's catch up with nessita and wgrant then
<niemeyer> pedronis: Enjoy!
<pedronis> niemeyer: IÂ mean I'm quite sure they were called  display-name and username at some point, I'm not sure why they got changed to this
<niemeyer> pedronis: Agreed, let's catch up with them
<pedronis> niemeyer: as you can see in infroFromStoreSnap most other things have quite matching names now
<pedronis> niemeyer: the only other serious divergence IÂ spot  is  in deltas:  source/target vs  FromRevision/ToRevision
<niemeyer> pedronis: It'd definitely be good to sync, but I'm less concerned about that one.. we won't be talking much about that
<pedronis> yes
<pedronis> just pointing out
<niemeyer> pedronis: Accounts is a can of worms, though, and that's part of the sauce inside that can
<pedronis> afai see the rest is quite aligned, except publisher
<pedronis> but I vaguely remember we started from the assertion names
<pedronis> and I don't know why we got there
<niemeyer> pedronis: What about publisher?
<niemeyer> pedronis: Is publisher not the publisher?
<pedronis> it is the publisher
<pedronis> IÂ mean the field inside it
<pedronis> *fields
<niemeyer> pedronis: Ah, ok, phew
<pedronis> no publisher is the publisher
<pedronis> (IÂ would be very unhappy if we do all this work to again mix that up)
<cprov> sergiusens, elopio: FWIW our creds results in a green run -> https://travis-ci.org/snapcore/snapcraft/builds/347383931
<cachio__> pedronis, do you know which scripts are executed when the snapd upgrade is done?
<pedronis> cachio__: nothing super interesting  ,  debian/snapd.maintscript  and debian/snapd.postinst
<pedronis> we do interresting things when we are removed though
<pedronis> snapd.postrm
<cachio__> pedronis, ah, ok, I'll take a look to those scripts
<cachio__> zyga, do you know where all the mounts are done after an upgrade?
<mup> Issue snapcraft#1954 closed: Implement support for `common-id` <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1954>
<mup> PR snapcraft#1960 closed:  extractors: add support for common-id  <enhancement> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1960>
<cachio__> niemeyer, I dont see any ubuntu - 32 bits
<cachio__> in google compute images
<cachio__> niemeyer, any idea where to find?
<cachio__> which project
<pedronis> cachio__:  I think there was some discussion around having them made, but no, they don't exist yet afaik
<cachio__> pedronis, ah, ok
<cachio__> bad news
<mup> PR snapd#4774 opened: tests: adding ubuntu-14.04-64 to the google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4774>
<pedronis> niemeyer: talked with Natalia,  no big objection to rechanging but double checking,  we want s/title/display-name/   s/name/username/ in publisher ?
<mup> PR snapcraft#1965 closed: tests: remove ProjectOptions dependency from integration suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1965>
<mup> PR snapcraft#1966 opened: grammar: support `to` statement in source <do-not-merge-yet> <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1966>
<niemeyer> pedronis: I think that matches exactly what's in the account assertion now, right?
<niemeyer> If so, yeah, sounds like a good win to have a single set of terms
<niemeyer> These terms also feel less ambiguous, which is another win.. username is classical.. everybody knows what to expect, and display-name is a bit more unusual, but also typical in our usage
<niemeyer> cachio__: I don't think they have it.. as I mentioned today in the standup, ideally the cloud team would just push that one too.. otherwise we'll need to cook the image ourselves
<mup> PR snapd#4775 opened: timeutil: timeutil.Human(t) gives a human-friendly string for t <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775>
<cachio__> niemeyer, ok
<cachio__> about the ubuntu core
<cachio__> 2018-02-28 17:40:04 Cannot allocate google:ubuntu-core-16-64: cannot find any Google image matching "ubuntu-os-cloud-devel/daily-ubuntu-core-16-v20161108" on project "ubuntu-os-cloud-devel"
<cachio__> I see this error trying to use that image
<cachio__> niemeyer, https://paste.ubuntu.com/p/NXPSSVgQXN/
<cachio__> this is the image I am trying to use
<cachio__> but itdoesn't work if I set image: ubuntu-os-cloud-devel/daily-ubuntu-core-16-v20161108
<cachio__> in spread.yaml
<cachio__> niemeyer, any idea?
<niemeyer> cachio__: Strange.. let me check
<cachio__> I am gonna add some extra debug info into the google backend to see
<niemeyer> cachio__: Is that for our snapd's ubuntu-core images?
<pedronis> niemeyer: yes, assertion has username and display-name
<cachio__> yes
<niemeyer> pedronis: Cool
<cachio__> niemeyer, I am trying to test that
<niemeyer> cachio__: Note that our images are not ubuntu-core images.. we can't do much with one of those
<cachio__> niemeyer, on, in that case I'll try to use the xenial image as we are doing currently
<niemeyer> cachio__: I suggest digging a bit into the way ubuntu-core images are cooked for testing..
<cachio__> niemeyer, ok
<mup> PR snapcraft#1967 opened: project_loader: improve the logic to install patchelf on arm <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1967>
<niemeyer> cachio__: Found the problem.. the API is returning less results than documented, 10 fold less.. I'll need to add support for pagination
<cachio__> niemeyer, good
<cachio__> niemeyer, thanks for see that
<niemeyer> np
<niemeyer> But now it's time for school pick up.. laters
<mup> PR snapcraft#1968 opened: demos: avoid use of the wrapper for java-hello-world <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1968>
<zyga> cachio__ mounts are done by systemd, we don't stop / start the units on package updates
<zyga> unless that's something new in bionic but I don't know anything about that
<Chipaca> bash manpage: "use --rcfile <file> to run file instead of /etc/bash.bashrc and ~/.bashrc". bash code: "source /etc/bash.bashrc; source rcfile or ~/.bashrc"
<Chipaca> :-((((
 * Chipaca goes for icecream
<zyga> Chipaca ?
 * zyga hands chipaca some lemon ice cream
<Chipaca> zyga: the bash in xenial at least, and against what's documented, always sources /etc/bash.bashrc
<Chipaca> which means:
<Chipaca> you'll always get the 'how to use sudo' message on 'snap run --shell'
<Chipaca> zyga: please tell me you're going to the sprint next week
<Chipaca> I remember how excited you got over turkish delight in london, and budapest is swimming in the stuff
<kyrofa> noise][, nessita the store had a "scan error" on one of my snap revisions. It's not even showing up in my rev list, but none of the subsequent snaps are being scanned as a result (they all say "waiting for <link to other scan> to finish")
<kyrofa> I'm fairly certain I could unblock things by rejecting and removing from the queue, but this seems like something that shouldn't happen
<kyrofa> I don't see a reason to hold up reviews because earlier ones had issues
<kyrofa> roadmr, I guess that ^ may interest you as well
<kyrofa> Some sort of "rescan" button would be nice
<kyrofa> I guess I'll try rejecting this one
<roadmr> kyrofa: WIT
<roadmr> WAIT
<roadmr> which snap is this?
<kyrofa> Okay
<kyrofa> nextcloud
<roadmr> give me a sec
<roadmr> kyrofa: https://dashboard.snapcraft.io/snaps/nextcloud/revisions/5423/ is the blocky one, right?
<kyrofa> You got it
<roadmr> kyrofa: we've been seeing upload issues since yesterday, this strange state seems to be because there's no upload linked to this snap :(
<roadmr> we haven't pinpointed the cause for the problem yet.
<kyrofa> roadmr, status.snapcraft.io is all green
<kyrofa> roadmr, anyway, not sure what the deal is with that snap, but we need these other ones released. How best do we unblock this?
<roadmr> kyrofa: give me a sec to check things on my side.
<kyrofa> Alright
<roadmr> kyrofa: don't start rejecting/removing others from the queue. It won't help - the wedged one will remain there and block any new uploads
<roadmr> kyrofa: to be clear - this is abnormal, a bug
<roadmr> kyrofa: usually when an upload gets stuck there's a very clear "rescan this dammit" button
<roadmr> I don't see it here; like you said, hell, I don't even see the upload
<roadmr> kyrofa: oh wow - an oops referencing another oops
<kyrofa> Oops inception
<roadmr> oopseption :)
<kyrofa> roadmr, things seem to be moving, now
<roadmr> kyrofa: wgrant fixed them. Thanks William!
<wgrant> It'll take a few minutes to process the backlog of nextcloud revisions, but it's getting there.
<kyrofa> wgrant, these are uploads from LP. They aren't being released into proper channels, but I haven't received any emails about failures. Will it try again at some point?
<kyrofa> Or have they timed out?
<roadmr> kyrofa: if an upload gets held for manual review, the "intent to release" for the other ones is lost, as I remember :(
<roadmr> https://bugs.launchpad.net/snapstore/+bug/1684529
<mup> Bug #1684529: Need for manual review loses intent to release to channel <Snap Store:New> <https://launchpad.net/bugs/1684529>
<kyrofa> Ah yes, I remember that one
<roadmr> kyrofa: sorry about that... if once the queue is clear you do another build, that one should get released properly, since the queue is clear
 * roadmr said "queue is clear" twice
<roadmr> thrice! no one expects the spanish inquisition!
<roadmr> kyrofa: do you accept transfer of snappy-m-o to you from elopio ?
<kyrofa> roadmr, I do. Just put it into the forum for tracking purposes as well
<roadmr> kyrofa: thanks, it's the proper place, I normally then e-mail the parties to verify but since elopio is a well-known user and so are you, I can check via irc :)
<kyrofa> roadmr, good deal, thank you :)
#snappy 2018-03-01
<nacc> hrm, why did my snap that just built get a version of 0.7.1-dirty? it's building via a LP build recipe and when I built the 0.7 version it built fine (as 0.7)
<nacc> it also blew up by 10 M when it shouldnt' have
<nacc> i dont' understand how snapcraft would ever emit a -dirty version for a git repo
<nacc> seems like something is busted
<nacc> and uh, like half my parts didn't build?
<nacc> did something happen to change on LP between the two runs I just did?
<nacc> cjwatson: --^ you may have some idea (i assume you're not around now, but maybe you would be later)
<kyrofa> wgrant, same thing happened again with rev 5445 of nextcloud, blocking reviews again :(
<wgrant> kyrofa: afk atm, will look in more depth when I'm back
<wgrant> nacc: nothing's changed in LP there recently. compare logs?
<nacc> wgrant: yeah i'll have to -- makes no sense
<nacc> a build an hour ago worked fine
<stgraber> hmm, why is s390x snap builds broken now?
<stgraber> "Could not find a required package in 'build-packages': patchelf"
<stgraber> it's not something the LXD snap itself is using, so wondering if snapcraft got updated and is unhappy on z somehow?
<stgraber> hmm, or is it an external parts that's broken maybe? /me checks
<stgraber> hmm, nope, doesn't appear to be coming from lxd or from the one external part we're using (go)
<stgraber> sergiusens: ^ any ideas?
<sergiusens> stgraber: oh, this is unfortunate, I'll have to propose a fix for that
<stgraber> sergiusens: is that going to affect all s390x builds? if so, that's a bit of a problem :)
<sergiusens> we don't have good testing infra for z to actually notice in this unfortunately
<sergiusens> yes
<sergiusens> stgraber: do you have a way test snaps on s390x builds?
<stgraber> sergiusens: I have s390x systems, yeah
<sergiusens> stgraber: lucky you; it is kind of late here, but I'll work on a quick fix tomorrow morning; if you are really in a hurry, I guess we can ask for a revert of the SRU
<stgraber> sergiusens: is that an option for you? (revert)
<stgraber> if so, I can do it pretty trivially using a cheap revert method, so not uploading a reverted package (because that makes the versioning crazy) but just remove the current SRU and publish the previous one again
<sergiusens> stgraber: I can push a version that potentially fixes this, it is one line of code
<stgraber> sergiusens: ah, give me a diff and I can test it for you
<sergiusens> stgraber: http://paste.ubuntu.com/p/sc9TfT5sCG/
<sergiusens> stgraber: in retrospect this could have been an arch specific Depdends :-/
<stgraber> ok, that got me past the error, will see if the rest works, but it should
<stgraber> sergiusens: do you have upload rights to push that or should I do it?
<sergiusens> stgraber: I do; your snap is not classic so it should just work
<stgraber> sergiusens: ok, if you upload a fix I can let it in and then push it straight to -updates once it's built
<sergiusens> ok, one sec
<sergiusens> stgraber: before dputting, care to corroborate this https://paste.ubuntu.com/p/VydCV8ssZr/
<stgraber> sergiusens: LGTM
<sergiusens> stgraber: awaiting approval
<stgraber> accepted
<stgraber> will wait for it to build and publish, then will release it into updates
<sergiusens> stgraber: great thanks
<sergiusens> stgraber: also, most of all, sorry for all of this; I think we should talk about this next week
<stgraber> sergiusens: I thought that snapcraft had an autopkgtest suite, shouldn't that have caught it on s390x?
<stgraber> and no worries, it's an easy enough fix, it's just a bad time for us as we're moving a lot of stuff around and are about to release betas for all our repos so want to make sure everything builds properly everywhere as we do that :)
<sergiusens> stgraber: hey, sorry, dozed off for a bit, long day. We do have tests, but most of the things we build has always been red on s390x (we need to scope it down with some skips, but the release team preferred that we slowly fixed them)
<sergiusens> I am heading out, if it still doesn't work, feel free to go ahead and revert
<nacc> wgrant: i think it's the snapcraft SRU
<nacc> totally broke my snap :/
<nacc> wgrant: yeah ,i think my system at home hasn't received the update yet (nor has our CI based builds) so it isn't breaking, but ftpmaster.internal had
<nacc> stgraber: --^ i guess sinc eyou were looking at it, something to worry about
<nacc> classic snap that is not dirty is getting marked as -dirty and the python plugin behavior has apparently changed (at a minimum)
<wgrant> nacc: Ah, ouch.
<nacc> wgrant: i'm fairly sure, at least. I think I just happened to hit a weird window on ftpmaster
<wgrant> nacc: Yeah, totally makes sense.
<wgrant> kyrofa: Another compute node reboot semi-broke snap storage again, fixing.
<stgraber> nacc: hmm, odd, something to look at after the s390x fix I guess
<stgraber> nacc: lxd doesn't seem to hit that -dirty issue somehow
<nacc> stgraber: it's not a classic snap is it?
<nacc> i wonder if it only is hitting classic somehow
<nacc> LP: #1752481 filed
<mup> Bug #1752481: Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35) <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1752481>
<stgraber> nacc: yeah, lxd is strictly confined
<nacc> wgrant: hrm, are reviews backed up again? I have a few git-ubuntu ones that seem to be queued for longe rthan ormal
<nacc> intersting LP reports that as a store upload failed, although the store found it
<nacc> https://launchpad.net/~usd-import-team/+snap/git-ubuntu/+build/158161
<nacc> (i rejected it manually)
<nacc> oh nm, that one went through
<wgrant> nacc: Things are a bit sluggish atm but should work
<nacc> wgrant: ack, it does seem to be going through (the auto uploads from LP were hung, but i rejected those and the one i manually built was able to release)
<wgrant> nacc: Ah yeah, looks like the stuck upload was 4h ago when things were still rather sad.
<wgrant> Rebooting 100 different parts of a system at 100 different times over two weeks exposes some amusing issues
<wgrant> Some of which we knew about, but a couple of which we didn't...
<nacc> wgrant: ack, np!
<happyaron> hi, is there a plan to review classic confinement requests?
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey
<zyga> hey :-)
<zyga> -14 still
<zyga> *brr*
<zyga> man, I'm looking forward to any positive temperatures
<zyga> even if +1
<mborzecki> zyga: https://images.meteociel.fr/im/132/tempresult_ciz8.gif
<zyga> I could look at that all day :)
<keshav> hello people
<zyga> hey hey
<keshav> hi zyga
<keshav> am bulldog
<keshav> am having an issue
<keshav> am snapping an app and its not getting its desktop entry in unity menu or any other app launcher
<keshav> @zyga my snapcraft.yaml https://paste.ubuntu.com/p/Z727mQ4B9s/
 * zyga honestly doesn't remember how to do desktop files
<zyga> I know how they have to be after building
<zyga> but I don't remember how to them in snapcraft
<zyga> let me look
<keshav> my .desktop file is under snap/gui with an icon
<keshav> okay i appriciate
<zyga> question: what happens after you build?
<zyga> where is the destkop file relative to the top level directory of the snap
<zyga> I found: https://github.com/ubuntu-core/snapcraft-examples/tree/master/03-hello-world-desktop-devmode
<keshav> after install or while building snap ?
<zyga> it has an app "hello-world-desktop" that matches the desktop file
<zyga> after you finish building
<zyga> what is in the prime/ directory
<zyga> (I mean, what are the paths of .desktop files relative to the prime directory)
<keshav> okay wai t
<zyga> ok
<keshav> inside setup/gui and snap/gui
<keshav> also in meta/gui
<zyga> ok
<zyga> that looks good
<keshav> yeah but after installing the app gets no entry in menus
<zyga> ok
<zyga> after installing look at /var/lib/snapd/desktop/applications
<zyga> do you see your launcher there?
<zyga> if so, look inside, does it have the Exec= line?
<keshav> wait bro
<keshav> nah no exec line is there
<zyga> ok
<zyga> that means the exec line was incompatible with the snap
<zyga> and that's why you cannot launch it from the menu
<zyga> what was the original exec line?
<zyga> (in setup/gui)
<keshav> okay wait
<keshav> Exec=Kdictionary %F
<zyga> ok, please change that to match your snap name
<zyga> K is upper case, I suspect that's why it is being filtered out
<keshav> damn
<keshav> okay let me check bro
<keshav> you are very helpful all the time
<keshav> zyga all this need to be documented in snapcraft.io
<zyga> no disagreement there
<keshav> it working now
<keshav> ty very much man
<pstolowski> heyas
<kalikiana> moin moin
<zyga> hey hey
<mborzecki> pstolowski: kalikiana: hey
<mvo> hey pstolowski - good morning
<mborzecki> mvo: hey
<mborzecki> https://github.com/snapcore/snapd/pull/4769 needs a second look
<mup> PR #4769: wrappers: detect whether systemd-analyze can be used in unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4769>
<mup> PR snapd#4769 closed: wrappers: detect whether systemd-analyze can be used in unit tests <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4769>
<zyga> mvo do you have time for a 2nd review now?
<ackk> kalikiana, so, it seems snapcraft lost the ability of building on different bases (as specified by the app's base attribute). Or is there a different way to do that now?
<Chipaca> hah! be careful how you write "is this number is smaller than -1" in go or it'll get really grumpy
<Chipaca> and good morning
<zyga> good morning! :)
<Chipaca> (and because you're thinking "smaller than -1" it'll take you a while to understand)
<kalikiana> ackk: There's no such ability. Unless you're talking about Snapcraft's patching libraries to make them compatible with the target
<kalikiana> ackk: That is, you can build on different hosts, but there is no explicit support for building against a different base (yet)
<kalikiana> Chipaca: Do you have an example of that?
<kalikiana> Like, what do you mean by grumpy
<Chipaca> kalikiana: if d<-1 { println("smaller!") }
<zyga> Chipaca so what's the catch?
 * Chipaca giggles
<Chipaca> it's funny how the brain works
<Chipaca> zyga: kalikiana: <- is an operator
<zyga> is d a channel? :D
<zyga> btw, I really wished go used <= for that
<zyga> <=shove=
<zyga> =yank=>
<zyga> <=poem=
<Chipaca> zyga: â
<mborzecki> <~ ~>
<zyga> gotta have your trigraphs
<ogra_> mvo, the nightly core snap builds failed on all arches with a weird error (and i'm at embeddedworld, can't research atm) ... https://launchpadlibrarian.net/359032850/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<ogra_> OSError: [Errno 6] No such device or address: '/build/core/prime/dev/dsp2'
<ogra_> Build failed
<Chipaca> ogra_: oh hi
<ogra_> (or zyga if you feel like looking ... )
<zyga> hmm hmm
<ogra_> hey Chipaca
<zyga> hey ogra_, this doesn't ring a bell immediately
<ogra_> (this error is seriously weird)
<Chipaca> ogra_: I had a question for you, but then realised it's probably for mvo :-)
<Chipaca> about tweaking a file on core
<ogra_> heh
<mvo> zyga: right now I'm working on apt :/
<mvo> Chipaca: ok
<mborzecki> hey Chipaca, ARS is a really unfortunate abbreviation for a timezone
<zyga> kalikiana why does snapcraft want to open /dev/dsp2?
<mvo> ogra_: hm, sounds like a test misbehaving
<kalikiana> Chipaca hot damn, I did not see that. the thought that the 1 is not assumed to be a number... I guess that's where the parser is either too smart or not enough
<zyga> if it is a device
<zyga> this is coming from internal/elf.py
<Chipaca> mborzecki: :-)
<zyga> looks like a bug in snapcraft elf resolver
<zyga> hey mvo, no worries :)
<pstolowski> zyga, i had another layout test failure on 4358 (but it was run yesterday in the afternoon)
<mvo> ogra_: aha, no - its our "fault"
<zyga> Chipaca maybe you can do a 2nd review instead of mvo
<mvo> ogra_, kalikiana I think the problem is that in "core" we ship some device files
<ogra_> Chipaca, either in  https://github.com/snapcore/core-build/tree/master/config (needs a release of the deb to the PPA after committing) or via live-build hooks https://github.com/snapcore/core/tree/master/live-build/hooks
<zyga> pstolowski do you remember what the error was
<ogra_> well, debootstrap creates a populated /dev ...
<zyga> I just merged a helper that will give us more debug data in such cases
<ogra_> but it always did that
<mvo> ogra_, kalikiana which we need for booting, snapcraft should just put them into the snap without trying to be smart and open them etc
<zyga> ogra_ yeah, it looks like a snapcraft change
<ogra_> ah
<ogra_> yeah, that makes sense
<pstolowski> zyga, cannot update snap namespace: cannot create writable mimic over "/etc": no such file or directory
<mup> PR snapd#4773 closed: tests: add debug for layout test <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4773>
<pstolowski> zyga, https://api.travis-ci.org/v3/job/347256945/log.txt
<Chipaca> ogra_: ack, i'll have a chat with em vee oh after things have frozen (i'm staying out of his path today)
<zyga> pstolowski hmm hmm
<zyga> thank you
<pstolowski> zyga, snap-update-ns failed with code 1: File exists
 * ogra_ goes back to booth duties (students-day here today ... will be crowded)
<zyga> pstolowski I *bet* our test suite is broken
<zyga> pstolowski as /etc doesn't just go away
<zyga> let's hope we learn some more from debug data
<zyga> Chipaca so about that review, maybe you want to look at 4760
<zyga> it's not long really, a chunk of file got moved
<Chipaca> zyga: will do
<zyga> and a few bits got added to other places
<Chipaca> wrapping up an edit here and will do
<zyga> I'm pushing this as it is 2.32 material
<zyga> and EOUTATIME
<ackk> kalikiana, I'm building a base-18 snap on bionic
<ackk> kalikiana, but it seems there' an hardcoded "core" mention in the code
<ackk> kalikiana, BjornT was able to get it to work with this change: https://paste.ubuntu.com/p/s2t3wct5J3/
<ackk> I mean, managed to build the snap, but then it seems there are missing libraries
<ackk> and LD_LIBRARY_PATH is not set
<Chipaca> zyga: looking
<zyga> Thank you!
<Chipaca> zyga: 4760, per-snap profiles?
<zyga> yes
<kalikiana> ackk: Perhaps you can file a bug with some context? I fear this is getting lost in IRC backlog otherwise.
<ackk> kalikiana, sure
<Chipaca> zyga: can you explain the 'per-snap' comments?
<zyga> yes
<Chipaca> good :-)
<Chipaca> please do?
<zyga> those are places that can benefit from per-snap paths instead of globs
<zyga> so instead of /snap/*/**
<Chipaca> ?
<zyga> we can say /snap/$SNAP_NAME/**
<Chipaca> /snap/thesnap/*8
<Chipaca> yeah
<zyga> and expand the variable
<zyga> yep
<zyga> I'm doing that in subsequent branches though
<zyga> it's going to be a while
<zyga> and it's tricky
<Chipaca> k
<Chipaca> ah!
<Chipaca> i figur he wrote the shorter per-snap ones after writing the longer one :-)
<Chipaca> zyga: branch looks fine, and jdstrand is awesome
<zyga> Indeed :)
<Chipaca> i'm reminded what a privilege it is for us to have him on team
<Chipaca> zyga: is there any reason we aren't using templates for the templates?
<zyga> legacy
<zyga> one change at a time perhaps
<zyga> this is very very old code now
<Chipaca> zyga: ok, fair
<zyga> I would love to get rid of ###SNAP_NAME### though
<zyga> it's just weird
<zyga> but predictable :)
<Chipaca> +1, and +1 on one-change-at-a-time
<zyga> thank you!
<Chipaca> when the churn dies down a little maybe we can look at switching them to templates
<Chipaca> but no hurry; this works
<zyga> yeah, I'd like that
<zyga> and unify the interface code with the same means of replacing text
<zyga> we have a few weird conventions now with ###FOO### @@FOO@@ or {{foo}}
<mborzecki> pstolowski: since you reviewed timer services before, can you take a look at https://github.com/snapcore/snapd/pull/4758 ?
<mup> PR #4758: wrappers, tests/main/snap-service-timer: restore missing commit, add spread test for timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
<mup> PR snapd#4760 closed: many: generate and use per-snap snap-update-ns profile <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4760>
<pstolowski> mborzecki, sure
<Chipaca> go 1.10's caching of test results is uncanny
<zyga> hmm?
<zyga> what's that?
<Chipaca> zyga: have /snap/bin/go be 1.10; run tests with it; see it zip through things it's tested that haven't changed
<zyga> oh
<zyga> that's *neat*
<Chipaca> zyga: that's not the neatest bit
<Chipaca> zyga: run tests, they pass; change the file, tests fail; edit the file back to what it was. Tests are already cached.
<Chipaca> I'm afraid to look where it's caching and how big that cache is, but it's neat
<zyga> in the cloud ;-))
<mborzecki> iirc it's also running vet under the hood now
<Chipaca> zyga: do you remember the name of the property of numbers where if a!=b, a>b or b>a?
<Chipaca> mborzecki: and that yes :-)
<zyga> hmm, no I don't sorry
<zyga> I mean
<zyga> Chipaca I can recall papers and who wrote them but I don't know how the term is called
 * Chipaca adds a 'go go go go!' label
<BjornT> kalikiana, ackk: https://bugs.launchpad.net/snapcraft/+bug/1752538
<mup> Bug #1752538: Building snap using base-18 is broken with 2.39 <Snapcraft:New> <https://launchpad.net/bugs/1752538>
<zyga> hmm
<zyga> I run out of memory during tests
<zyga> I'm building a string that's maybe dozen lines long
<zyga> WTF?
<zyga> on 8GB Vm
<Chipaca> zyga: go test -memprofile mem.out
<sergiusens> hey zyga, any insight on this one https://bugs.launchpad.net/snapcraft/+bug/1752498 to generate a more thorough response?
<mup> Bug #1752498: cleanbuild fails with lxd snap <Snapcraft:New> <https://launchpad.net/bugs/1752498>
<zyga> looking
<zyga> so, the host is pureos, it uses snaps and has the lxd snap
<zyga> and then that runs a xenial container
<zyga> and that fails to mount snaps
<zyga> do I get that right?
<zyga> Chipaca trying
<zyga> Chipaca it crashes with OOM and doesn't give me the mem.out file
<Chipaca> zyga: go test -memprofile mem.out -timeout <something less than it takes to oom>
<Chipaca> (but -memprofile might only work for successful tests, in which case you'll have to do it by hand)
<Chipaca> (but try it this way first)
<Chipaca> (parenthetical)
<zyga> Chipaca it doesn't write the memory profile when a timeout occurs
<zyga> I mean, not sure what to do
<Chipaca> zyga: it's in a single test that fails, or is it the suite as a whole?
<zyga> I don't get an OOM without a trivial loop
<zyga> not sure yet
<Chipaca> zyga: in the test, or in setupsuite, or in init, start the mem profiler, start a goroutine that sleeps then stops and closes the profiler before it ooms
<zyga> running one test doesn't oom
 * zyga thinks
<Chipaca> in init would work (but tests can't have init? not sure)
<zyga> I got something useful now
<zyga> filepath.Split is broken? :/
<Chipaca> probably not :-)
<Chipaca> zyga: but, tell me how you think it's broken :-)
<zyga> p is "/snap/vanguard/42/"
<zyga> split of p is "/snap/vanguard/42/" ""
<zyga> that's ... unexpected
<Chipaca> zyga: you need to filepath.Clean it
<zyga> yeah
<Chipaca> filepath is broken in that half of the things Clean the path unconditionally, half of them break if you don't, and half of them return a Clean path, and half of them don't, and â¦ none of those overlap
<Chipaca> i mean, those four sets are different and not complementary
<Chipaca> or something
<Chipaca> it's a mess
 * Chipaca should write a path package that did things properly :-p
 * Chipaca is still working on a package that knows how wide something you printed to the terminal was
<zyga> woah
<zyga> that's silly
<zyga> (^H dumb)
<zyga> p is "/snap/vanguard/42/usr"
<zyga> split of p is "/snap/vanguard/42/" "usr"
<zyga> so filepath.Split returns unclean result
<zyga> ...
<Chipaca> zyga: that's because of the property of Split that the first element will always end in / so that you can + the things together and get the original
<Chipaca> I'm not sure how that property is useful though
<Chipaca> if you're looping, just lob off the last byte
<zyga> yeah, done now
<Chipaca> zyga: why were you accumulating in that loop though
<zyga> I was doing this...
<zyga> https://pastebin.ubuntu.com/p/68f45jQ2tG/
<zyga> those are per-snap apparmor rules for snap-update-ns for a single layout line
<zyga> I need to give write permissions to all the path segments
<zyga> jdstrand ^ FYI, does that look sane>?
<Chipaca> quoth the raven, eep
<zyga> Chipaca less wildcards :)
<Chipaca> zyga: i'm lazy, can you point me to the code that builds / uses this?
<Chipaca> zyga: also can you review #4748 :-)
<mup> PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748>
<zyga> not committed yetr
<zyga> https://pastebin.ubuntu.com/p/j8XXgMzct8/
<zyga> sure
<zyga> I mean, not rocket science
<zyga> just very talkative
<zyga> Chipaca question about that PR, the filtering out thing I understand, the queryForSnapInfo part I don't
<zyga> why is that needed?
<Chipaca> zyga: because SnapInfo _does_ want to get the yaml
<zyga> no no
<zyga> I understand we want it
<zyga> just don't understand how the code is laid out to need "snap_yaml_raw" explicitly mentioned in queryForSnapInfo
<zyga> I assumed we took all the variables
<zyga> so the exception list makes sense
<Chipaca> zyga: so, this changes getStructFields to take a list of fields not to look at
<zyga>  so the part at line 425 that gets all the things except the yaml, is is fine
<Chipaca> zyga: and the default config loads all things except the yaml
<Chipaca> zyga: but then we want that field back for snap info
<zyga> what is the default?
<Chipaca> so, start with the default field list, add yaml
<zyga> defaultSnapQuery ?
<Chipaca> yes
<zyga> where is the logic that says defaultSnapQuery doesn't get the yaml field?
<Chipaca> yes, if you expand just above queryForSnapInfo you 'll see it
<zyga> yes, I did that
<Chipaca> 1 sec...
<zyga> I mean, reading this https://github.com/snapcore/snapd/pull/4748/files#diff-1f8872a5d54402aa220c723deb16293cR499
<mup> PR #4748: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <https://github.com/snapcore/snapd/pull/4748>
<zyga> I don't understand why it doesn't ask for the yaml field
<Chipaca> zyga: +var detailFields = getStructFields(snapDetails{}, "snap_yaml_raw")
<zyga> and detailFields gets copied to Store somewhere?
<Chipaca> zyga: that's the default for the config
<Chipaca> yes
<zyga> ah
<zyga> ok, then it makes sense now
<zyga> thank you!
<Chipaca> i mean, it was meant to be a small refactor
<Chipaca> otherwise i'd've gotten rid of the indirection
<zyga> it's fine, I just didn't connect the dots
<Chipaca> but pedronis is doing a good job of doing exactly that while moving to the new api
<Chipaca> so \o/
<sergiusens> zyga: you got it right
<zyga> sergiusens okay
<mup> PR snapd#4748 closed: store: don't ask for snap_yaml_raw except on the details endpoint <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4748>
<Chipaca> mborzecki: got a question on #4743 otherwise +1
<mup> PR #4743: packaging/arch: sync with snapd/snapd-git from AUR <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4743>
<zyga> sergiusens does pop os use our kernel?
<Chipaca> also why are we doing this: UNCLEAN="$(git status -s|grep '^??')" || true
<zyga> I know it used to be a derivative
<Chipaca> that || true
<Chipaca> wat
<sergiusens> zyga: PopOS? I almost certain it does, cannot say for sure; but this is PureOS
<mborzecki> Chipaca: i believe it's to cover the case when it's runnig in a spread test where the sources are packed sans .git directory
<zyga> ah
<zyga> sorry
<zyga> then I don't know why it fails
<zyga> maybe the kernel doesn't work with fuse
<zyga> someone would have to look at the error messages in the journal
<zyga> (the ones from the kernel)
<sergiusens> zyga: once you know what it is, would it be wise to add it as a pre-flight check before attempting a `snap install` to even get started?
<zyga> hmmm
<zyga> no idea
<zyga> I mean, we don't check if the kernel can mount squasfs files
<zyga> or how such a check would look like
<zyga> because the details are burried in kernel config
<zyga> and you may not even be able to read that
<mup> PR snapd#4758 closed: wrappers, tests/main/snap-service-timer: restore missing commit, add spread test for timer services <go go go go!> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4758>
<zyga> (you can squashfs but you cannot read XZ compression, for example)
<zyga> and inside a container it gets even more complex as you need FUSE and helpers
<Chipaca> mborzecki: yeah, just that the construction is super weird (and makes you really think about whether UNCLEAN is bound if the git fails)
<Chipaca> mborzecki: (but this itself wasn't a comment on your PR)
<Chipaca> mborzecki: also, I'd love to know why ${foo=} even works
<mborzecki> Chipaca: that's supposed to be the default value, if my memory serves me right the : in := is optional, but i might be wrong :)
<mborzecki> let me check bash manpage :)
<Chipaca> empirically yes
<Chipaca> but the manpage doesn't say the : is optional
<Chipaca> and i'd never seen this usage
<Chipaca> Â¯\_(ã)_/Â¯
<pedronis> Chipaca: yes, the manual copying  is annoying/fragile, not sure a complicated solution using reflection is better though
<mborzecki> Chipaca: `Omitting the colon results in a test only for a parameter that is unset`
<mborzecki> Chipaca: funny how they use : and 'colon' in that particular sentence
<Chipaca> mborzecki: ooh
<Chipaca> so ${foo?error} errors only if unset
<Chipaca> fair enough
<Chipaca> pedronis: was your comment on #4738 a request to remove or improve?
<mup> PR #4738: snap: unify snap name validation w/python; enforce length limit <Created by chipaca> <https://github.com/snapcore/snapd/pull/4738>
<Chipaca> mvo: #4720 has you tagged for reviewing it, but it's got a +1 from zyga and j.d.strand, dunno how to proceed
<mup> PR #4720: interfaces: add xdg-desktop-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4720>
<Chipaca> zyga: I think you just broke 4714, is that something you could deconflict?
<zyga> oh, I always deconflict that one :D
<zyga> done
<Chipaca> thanks
 * Chipaca reviewing
<Chipaca> woo! we're below 3 pages
<Chipaca> :-(
<mup> PR snapd#4743 closed: packaging/arch: sync with snapd/snapd-git from AUR <go go go go!> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4743>
<Chipaca> zyga: why is tests/main/layout failing so much
<zyga> I don't know yet, I merged some debug helper to see what we can learn
<zyga> what I saw seemed to indicate that /etc is gone
<zyga> which is ... worrying
<Chipaca> zyga: https://pastebin.ubuntu.com/p/Yj8MKv3h2m/ <-
<Chipaca> ah yes
<zyga> perhaps I want to adjust the debug output to do "ls -ld /etc"
<Chipaca> cachio__: good morning sir! as a waking-up present, you have conflcits in #4721
<mup> PR #4721: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
<pedronis> zyga: remember there's a denial too, so not clear is gone, or cannot be operated on
<pedronis> also IÂ have /etc and /opt
<pedronis> *I have seen
<zyga> yep
<zyga> but ENOENT cannot happen via apparmor
<zyga> still unclear what is wrong really
<pedronis> Chipaca:   improve
<pedronis> I didn't get it was a joke
<pedronis> it seems
<Chipaca> pedronis: ok, i'll improve
<pedronis> Chipaca: did you see my comment about copying fields,  did you have something better in mind?Â IÂ have only complicated things
<Chipaca> pedronis: I just wish these things were assignable
<Chipaca> pedronis: wishful thinking on my part
<Chipaca> nothing more, i fear
<pedronis> ok
<pedronis> wondering if there's a way to check I didn't leave out any field
<pedronis> though
<pedronis> I'll think a bit more,   I need to rename a couple of fields anyway
<pedronis> because of last night discussions
<pedronis> Chipaca: is go go go! a new thing?
<Chipaca> pedronis: yes i created it today
<Chipaca> and expect it to be given a more professional name :-) but
<Chipaca> we need a tag to not waste time looking at a pr because it's good-to-go
<Chipaca> maybe because i'm not always comfortable merging somebody else's code (as i presume if they haven't merged it there's a reason)
<pedronis> in theory you can just go and merge it I suppose,  though for mine it would have been wrong, well not wrong, but IÂ need to tweak it
<pedronis> that is fair
<pedronis> yes, not a fan of merging code unless I have the full context
<Chipaca> zyga: does the layout error happen on every pass, or is it random?
<zyga> random
<Chipaca> zyga: IOW, should i just hit restart
<zyga> if it was every pass it wouldn't land
<Chipaca> because there's a bunch of prs red because of it
<zyga> hmmm
<zyga> I'll look into it
<zyga> meanwhile please restart
<Chipaca> zyga: so i should leave them red?
<Chipaca> ah ok
 * Chipaca punches the button
<zyga> nah, I need to reproduce that or add more debugging
<Chipaca> cachio__: in #4725, it's completely unclear to me whether you're saying it's in the model/gadget/whatever (and thus it shouldn't get removed and we have a bug), or not (and thus the model needs tweaking)
<mup> PR #4725: tests: avoid removing preinstalled snaps on core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4725>
<Chipaca> zyga: you probably want to re-review #4672
<mup> PR #4672: tests: adding test for removable-media interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
<zyga> question about that ../../../bin/sh trick
<zyga> how do you want to tackle that
<Chipaca> the one that's going away?
<Chipaca> first, do a scan of all snaps to make sure it's just our snaps that use it
<Chipaca> second, let you use absolute paths
<mvo> Chipaca: looking at 4720
<Chipaca> third, forbid you from using ..
<Chipaca> zyga: <end>
<Chipaca> zyga: if the first step fails, we need to address that before moving to #2 and #3
<zyga> ln -s .. foo
<Chipaca> bah, #2 can move ahead independently and might be needed to address #1
<zyga> ls foo/
<zyga> just saying
<Chipaca> zyga: this is snap.Container-level validation
<Chipaca> so you can read that link, probably
<mup> PR snapd#4720 closed: interfaces: add xdg-desktop-portal support to desktop interface <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4720>
<Chipaca> * needs more work but it's doable
<Chipaca> that is, snap.Container would need a ResolveSymlink or something, as the walk on its own doesn't have enough info
<mup> PR core#82 opened: xdg-open: add implementation capable of opening local files <Created by jhenstridge> <https://github.com/snapcore/core/pull/82>
<cachio__> Chipaca, we don't have a bug
<cachio__> Chipaca, this PR is to run our test suite on caracalla device
<cachio__> Chipaca, in this case the caracalla image has different snaps preinstalled
<cachio__> some of them cannot be uninstalled
<cachio__> Chipaca, so the idea is to avoid removing those when we reset
<mborzecki> jamesh: hmm i see the xdg-open PR, what reminds me that I've seen some snaps call xdg-mime directly, discord does that for instance, do you think we should handle this as well?
<jamesh> mborzecki: mvo's xdg-mime proxy already handles that, no?
<mborzecki> jamesh: let me try to grab the log from discord
<mvo> iirc we don't do xdg-mine, we do xdg-settings though
<jamesh> ah.  Got those confused
<mvo> jamesh: just saw your glib xdg-open PR, nice!
<mvo> jamesh: will we need to register more handlers? I see we right now do http,https,mailto,help, how will open other types (like normal text) work?
<jamesh> mvo: I've got a hack to make that work, but don't want to put it in core
<mvo> jamesh: aha, nice
<mvo> jamesh: so that will be per-snap?
<jamesh> mvo: I just forwarded you an email about the hack I used: it relies on a stub shared-mime-info database so that everything maps to a single mime type
<jamesh> i.e. not the kind of thing I'd want to make part of the ABI of the core snap
<mborzecki> jamesh: https://paste.ubuntu.com/p/pHMSZgZG6M/ grep does not show any trace of xdg-mime in unpacked snap, so no clue where that's called from
<mborzecki> jamesh: this is what it's trying to do with xdg-mime: https://paste.ubuntu.com/p/dsDJ7DqjfV/
<jamesh> mborzecki: fwiw, I filed a wishlist issue against xdg-desktop-portal about supporting default app associations, but it got knocked back: https://github.com/flatpak/xdg-desktop-portal/issues/126
<jamesh> mborzecki: if we wanted to support this kind of thing, it isn't something we can fob off to xdg-desktop-portal in future
<jamesh> I am sympathetic to their point of view that confined apps shouldn't be changing associations
 * Chipaca disappears in a cloud of 'omg lunch'
<mup> PR snapcraft#1969 opened: Add a "--profile" parameter to cleanbuild <Created by chrisglass> <https://github.com/snapcore/snapcraft/pull/1969>
<pedronis> mvo: IÂ noticed we still avae snap.Info.LicenseAgreement and snap.Info.LicesenseVersion, are they still a thing in snapcraft.yaml ?
 * pedronis can't type
<kaliy> hi, quick question: I'm assuming that I need to use classic confinement if I need to drop a policykit policy file system-wide during install, is this correct? or could I do this in any other way?
<Chipaca> kaliy: please don't do that unless you also remove it on uninstall
<Chipaca> but, yes, as a classic snap you would be able to do that
<kaliy> Chipaca: that's already done :)
<Chipaca> kaliy: how?
<kaliy> with the remove hook
<Chipaca> we have a remove hook?
 * Chipaca is behind the times
<pedronis> we have all sorts of hooks
<Chipaca> oh dear
<kaliy> I was about to post to the forum asking for review for a classic confinement snap, but I wanted to make sure if I hadn't misunderstood something
<Chipaca> pedronis: I had a vision of you doin ga 'From Dusk till Dawn' thing with hooks
<Chipaca> kaliy: please do a forum post. I'm interested in knowing what you need the policykit thing for, to see if we can't accommodate it with interfaces in the future
<Chipaca> kaliy: also i'd be interested in knowing how you'd handle a missing policy kit, or running on arch
<Chipaca> (have you tested on arch)
<Chipaca> then 'run snaps cross-distroly' breaks down easily for classic snaps :)
<kaliy> Chipaca: this app uses a polkit policy for launching openvpn. the app will complain if no polkit agent is running, and we try hard to launch any usable polkit agent that can be found on the system
<kaliy> I saw a reference to interfaces for polkit in the forum, but I was unsure how this would be implemented
<Chipaca> kaliy: me too :-) more examples help
<Chipaca> so, go forum post asking for classic, give us the juicy, juicy details of what you need :-)
<kaliy> Chipaca: sure, thanks :)
<pedronis> Chipaca: after standup could you look at the commits IÂ added to #4770
<mup> PR #4770: store: parse the JSON format used by the coming new store API to convey snap information <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4770>
<Chipaca> doing so now
<mup> PR snapcraft#1958 closed: store: support for more granular store permissions <enhancement> <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1958>
<zyga> [Wed Feb 28 17:17:47 2018] audit: type=1400 audit(1519838267.637:342): apparmor="DENIED" operation="mount" info="Failed name lookup - deleted entry" error=-2 profile="/usr/lib/snapd/snap-confine//snap_update_ns" name="/etc/group" pid=14239 comm="3" flags="rw, bind"
<zyga> so this clearly shows something removed /etc/group while we were working
<mup> PR snapd#4774 closed: tests: adding ubuntu-14.04-64 to the google backend <go go go go!> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4774>
<jdstrand> mvo: hi! I see in backscroll that you noticed the xdg-open PR. Please see this in particular: https://github.com/snapcore/snapd/pull/4766/#discussion_r171275533
<mup> PR #4766: userd: add an OpenFile method for launching local files with xdg-open <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4766>
<mvo> jdstrand: thanks, in a meeting right now but I will read this, thanks for the info. please note that this is not a security measure, this is just to get the transient parent for the window that is displayed :)
<mup> PR snapcraft#1970 opened: meta: parse LAUNCHPAD_BUILD_INFO for inclusion in the manifest <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1970>
<jdstrand> mvo: that's a different comment I want you to look at. that was just a warning. what I asked you to look at is the snap name lookup in snapFromSender since you can bypass the "I proved I could open the file" check in that PR
<zyga> jdstrand hey
 * kalikiana going for lunch
<jdstrand> hey zyga
<zyga> jdstrand I just found a bug in layouts and I'm super in progress with layout harderning
<zyga> jdstrand /etc is the real /etc on classic
<zyga> jdstrand so it's writable
<zyga> jdstrand so we create symlinks there (oops)
<zyga> jdstrand not sure if we should do
<zyga> *what
<jdstrand> zyga: can you connect the dots a little more. I understand on classic, /etc is the host's etc. this is why we don't allow specifying non-$SNAP* source mounts. what are you referring to?
<zyga> we still allow one to make a symlink in /etc/foo -> stuff
<zyga> and that creates a real symlink in real /etc
<zyga> we also allow creating file bind mounts
<zyga> and that creates a real empty file in the real /etc as a mount point
<zyga> and in fact, any writable location will have this property
<zyga> that the symlink and empty files/directories are really actually created there
<jdstrand> ok, so while the source mount is $SNAP*, the target needs to exists for the mount point
<jdstrand> exist*
<jdstrand> that is definitely wrong
<mup> PR snapcraft#1916 closed: lxd: initialize remote lazily <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1916>
<zyga> well, that's not how layouts work
<zyga> otherwise you cannot put stuff into /usr/share/myapp
<zyga> myapp doesn't exist when the layout is being constructed
<jdstrand> it is wrong that the files are leaking outside of the snap that is
<zyga> oh, no disagreement there
<zyga> it's just something we need to figure out
<jdstrand> I thought that was going to be handled with a writable mimic?
<zyga> it is
<zyga> but /etc is _writable_
<zyga> mimics are not constructed there
<jdstrand> you're saying writable mimic only kicks in if the source is readable
<zyga> we only invoke the mimic if the write returns EROFS
<jdstrand> right. what if you always did that instead of doing that check?
<zyga> I'm saying the mimic only kicks in when the mount point cannot be created
<zyga> it's not clear at which level we'd construct the mimic
<zyga> at the parent?
<zyga> that is
<zyga> for /usr/share/foo we'd always make a mimic at /usr/share
<zyga> jdstrand stashing that converstation
<zyga> can I ask you to take a quick look at a bit of apparmor policy
<jdstrand> sc_populate_mount_ns has a list of dirs that are affected, no?
<zyga> it's representative for all the layout bits we need to do
<zyga> hold on, looking
<zyga> jdstrand yes, I think that's roughly the list
<zyga> though I don't know thinking about it quickly if that's _the_ list
<zyga> or if something contributes elsewhere
<jdstrand> zyga: we can either just do the parent or some variation on that, which would mean more mimics, or we are precise an when to mimic
<jdstrand> which is fewer mimics
<zyga> hmm, I almost agree
<zyga> but not fewer in some cases, let's see /usr/share/foo/bar is something we need to make
<zyga> this would give us a mimic at /usr/share and then another one (not needed) at /usr/share/foo, right?
<Chipaca> niemeyer: mvo: I was trying to say something but it froze up
<mvo> Chipaca: what was it?
<cachio__> mvo, I already tagged 2 PRs for 2.32
<zyga> jdstrand I need to think about this, I just realized this happens
<jdstrand> I presented two choices. a) mimic the parent (or a variation), b) mimic based on this list
<mvo> cachio__: thank you
<zyga> jdstrand can you please look at this policy test: https://pastebin.ubuntu.com/p/CM9tJ5W7cF/
<niemeyer> Chipaca: Ah, oops, sorry :)
<Chipaca> niemeyer: mvo: bash in 16.04 (i haven't looked elsewhere) that --rcfile overrides reading /etc/bash.bashrc, but it doesn't
<zyga> jdstrand ack
<jdstrand> so, with 'a', you mimic at /usr/share/foo
<Chipaca> niemeyer: mvo: so to do what I want to do I'm going to have to tweak /etc/bash.bashrc
<jdstrand> but if you then have /usr/share/baz/norf, you mimic as /usr/share/baz
<jdstrand> so that is 2 under /usr/share
<zyga> with a) exiting code would also kick in and make a mimic at /usr/share since foo is not a thing in the base snap
<niemeyer> Chipaca: That'd mean not working for most people.. :(
<Chipaca> so, that. No biggie, but it's going to take a while more (and involve more people) than the quick hack it would've been otherwise
<niemeyer> Chipaca: And perhaps some people upset when it does work :)
<Chipaca> niemeyer: /etc/bash.bashrc is from core
<jdstrand> but, if /usr/share is in the list, you mimic /usr/share
<niemeyer> Chipaca: Ah, hmm, that's also not so great given bases
<zyga> jdstrand I think we need the list of directories
<niemeyer> Chipaca: I mean, behavior will be inconsistent
<zyga> as that seems as a more natural thing to do
<zyga> it's complex as that list is variable
<zyga> and I don't know if it's simple to connect the dots yet
<niemeyer> Chipaca: Did you dig into what was going on with --rcfile?
<jdstrand> for /usr/share/foo/bar and tack on /usr/share/baz/norf under that existing mimic
<zyga> perhaps we can start with a blacklist (e.g. extend it to refuse /home mounts) and a simpler rule for just /etc
<zyga> (and similarly /var)
<jdstrand> zyga: right. I'm not expressing a preference. I just recalled there was a list, so maybe it could be leveraged
<zyga> jdstrand yeah
<zyga> I just wanted to let you know because I didn't anticipate this before
<Chipaca> niemeyer: as I said, the documentation says it overrides reading the system rc, but it doesn't
<jdstrand> zyga: I like starting simpler. we would have to consider if there are any valid use cases for the ones we leave out of the list
<Chipaca> the code is: load system rc; load rcfile or ~/.bashrc
<jdstrand> zyga: I didn't explicitly think about this either-- I was thinking 'oh, this is a per-snap mimic so all is good'. curious, did this come about from the apparmor hardening?
<jdstrand> zyga: btw, thank you for that hardening
<Chipaca> niemeyer: are bases required to have bash?
<zyga> jdstrand yes this came out of the hardening as I was testing this on my host system
<zyga> jdstrand and I noticed /etc is populated with placeholders
<zyga> jdstrand hardening is almost complete for layouts (modulo review and fixes) but I need to go all the way and make content interface do something similar or I won't be able to drop some of the wildcards
<zyga> once content interface also adds update-ns rules I should be able to remove the biggest offenders :)
<jdstrand> zyga: yeah for hardening! :)
<jdstrand> zyga: you asked me to look at some apparmor rules?
<zyga> yes
<zyga> in the pastebin above
<zyga> https://pastebin.ubuntu.com/p/CM9tJ5W7cF/
<zyga> it's a part of a test
<zyga> there's a simple layout
<jdstrand> I responded to 4765 yesterday (you probably saw)
<zyga> and the resulting rules
<zyga> yeah, I will iterate with the hardening there
<Chipaca> zyga: why does snap-confine create SNAP_USER_DATA, but not any other of the four data dirs?
<zyga> Chipaca not sure
<zyga> I think it is doing that because /home/zyga/snap/snapname/ is not writable in general
<zyga> so it will do /home/zyga/snap/snapname/42/
<zyga> the common one is done somewhere else (right?)
<zyga> but really that's just a guess
<zyga> that's some oooold code pre-dating many of the things we have now
<mup> PR snapd#4739 closed: many: remove snapd.refresh.{timer,service} <go go go go!> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4739>
<roadmr> hey folks. Is bsutton here? does anybody know him?
<zyga> roadmr not me
<pedronis> mvo:   snap-rervice-refresh-mode seems flaky:  https://travis-ci.org/snapcore/snapd/builds/347750674?utm_source=github_status&utm_medium=notification
<Chipaca> zyga: there's no SNAP_USER_COMMON in snap-confine
<zyga> I think that's something to garden
<Chipaca> zyga: the mkdir, or the lack of them?
<zyga> not sure, they ought to be made, just unsure where
<zyga> I suspect in snap-confine though, due to permissions
<mvo> pedronis: hm, I think we had this before that tests/main/snap-service-refresh-mode  was flaky, iirc cachio__ did some fixes (or was it mborzecki) from leftover systemd logs. I will look in a wee bit
<Chipaca> zyga: ok, I'll dig
<pedronis> thanks
<Chipaca> zyga: I need to change this code anyway
<zyga> what kind of changes do you need to make?
<Chipaca> zyga: SNAP_DATA and SNAP_USER_DATA are going to point at symlinks
<zyga> hmm
<zyga> that's interesting
<Chipaca> zyga: very precise symlinks, so, a little code to desymlink them and we'll be good
<Chipaca> a readlinkat and a add-this-to-that
<mborzecki> mvo: yup, it was journalctl --sync && journalctl --rotate
<jdstrand> Chipaca: what is the symlink and what will the symlink point to? what is the motivation of the change?
<Chipaca> jdstrand: current
<cachio__> pedronis, mvo I'll take a look to that test
<Chipaca> jdstrand: motivation is that if an app uses $SNAP_USER_DATA for something, they should be able to store it without it breaking on refresh
<Chipaca> jdstrand: e.g. vlc using $SNAP_USER_DATA/Videos (or whatever) as default for where to find videos
<jdstrand> Chipaca: that only solves part of the problem
<Chipaca> jdstrand: (there's a second half of this work that's "move then copy back on refresh, instead of copy forward")
<jdstrand> Chipaca: but will improve things, yes
<jdstrand> Chipaca: the hard problem is open fds
<Chipaca> jdstrand: that's fixed by the move-then-copy-back thing
<Chipaca> right?
<pedronis> mvo: cachio__:  journalctl has cursors, maybe we can use those
<cachio__> pedronis, ok, let me check if that works on trusty
<pedronis> --show-cursor  and  --cursor  and --after-cursor
<jdstrand> I don't see how. it does solve newly opened files. eg, vlc opens 1/foo, a frefresh happens, the apparmor policy is reloaded, making 1/foo readonly and 2/foo readwrite, when vlc writes to its fd, the kernel will do a revalidation of that fd, see it is in 1/foo, which is readonly and then deny it
<mborzecki> pedronis: hm intersting, worth exploring if the test continues to be flaky
<mborzecki> pedronis: the last attempt was to make sure that the journal is flushed and rotated before each test
<pedronis> that should be overkill with cursors (if they work on 14.04)
<niemeyer> Chipaca: Yes, the shell needs to be in the base, at least for now
<niemeyer> Chipaca: In a call, but will be with you shortly
<jdstrand> Chipaca: there are only four ways to fix this: the application gets a signal and does something smart, we make the previous revision readwrite, we defer the policy reload or we have per-revision apparmor policy (like we did with click)
 * zyga -> lunch
<cachio__> pedronis, we can use cursors in all the systems but 14.04
<pedronis> :/
<Chipaca> jdstrand: if we mv 1/ 2/, won't the revalidation see the fd of 1/foo as on 2/ now?
<cachio__> pedronis, 14.04 should be removed soon from our test suite I think
<jdstrand> Chipaca: each has drawbacks. for the first, the app needs to be really smart. for the second, that destoys rollbacks. for the fourth, the running app writes to the old dir after the migration
<jdstrand> Chipaca: the third is not impossible (defer/prompt the refresh if non-daemon processes are running in the freezer cgroup)
<jdstrand> Chipaca: hmm, maybe. did you test that actually works?
<Chipaca> jdstrand: I don't have the code to do that yet, no, but I should be able to get there before eod
<jdstrand> Chipaca: we should ask jjohansen if that is expected to work
<Chipaca> jdstrand: asking somebody whether it'll work >>> doing the work to check if it works :-)
<Chipaca> jjohansen: OHI
<jdstrand> Chipaca: well, I was thinking you would write a very small test to see if the revalidation happens rather than changing snapd since that might waste your time
<jdstrand> Chipaca: let me ask
 * Chipaca lets
<pedronis> cachio__: do you that travis log or can IÂ restart the tests?
<pedronis> *do you need
<cachio__> pedronis, restart it
<pedronis> thx
<cachio__> np
<jdstrand> jjohansen: hi! consider a profile has '/1/** rw,' and an app has an fd for /1/foo. when the profile is reloaded to only allow '/2/** rw,' then when the app writes to the fd, it is denied cause of revalidation (fine)
<jdstrand> jjohansen: now consider profile has '/1/** rw,', app has open fd to /1/foo. then, the app is frozen via freezer cgroup, /1 is moved to /2, the profile is updated to allow only '/2/** rw,' and reloaded, then app is unfrozen
<jdstrand> jjohansen: what is expected to happen when the app writes to the open fd? does revalidation kick in? the path is different, but the inode backing it is the same
 * zyga tunes in as this is interessting
<jdstrand> Chipaca: fyi, jjohansen may not be online for a little while
 * ikey also has the popcorn
<zyga> I didn't know apaprmor does revalidation
<Chipaca> jdstrand: it's ok, i've got plenty of other stuff to work on meanwhile :-)
<jdstrand> Chipaca: assuming for a moment that works, deferring/prompting is still desired
<jdstrand> Chipaca: this operation could take several seconds to migrate, reload, etc
<kalikiana> re
<jdstrand> Chipaca: while the whole time the application is frozen. if the application is vlc, its playback is stopped. the window goes gray, the user is like 'wth?'
<elopio> cachio__: those look like network timeouts
<Chipaca> jdstrand: yes, we still want apps to be able to say "don't refrsh me just yet plz"
 * zyga never imagined jdstrand would say "the user is like 'wth?'" :D
<jdstrand> Chipaca: if we have that ability. or even simply the ability to prompt and say "I have a refresh pending. Deferring the refresh until vlc closes'. Then you watch for when the cgroup has no non-daemon processes running in it, and do it then
<Chipaca> zyga: jdstrand: do we know how many things are in the freezer?
<jdstrand> Chipaca: then you don't need the rigamorole
<zyga> yes
<Chipaca> because we could defer a refresh if the freezer isn't empty
<jdstrand> zyga: note, it was the user that said that, not me :P
<zyga> you can enumerate processes and threads
 * zyga hugs jdstrand for being so awesome
 * jdstrand hugs zyga :)
 * Chipaca adds it to quotes
<Chipaca> zyga: do you have to freeze it before you can answer 'is it empty'?
<jdstrand> Chipaca: yes, like zyga said. the trick is 'non-daemon' and by that I mean snap commands that don't use 'daemon: ...' in the yaml, since they are expected to be running
<zyga> Chipaca I think no
<zyga> although the process you will find may be gone now
<zyga> so you can see "not empty" without freezing
<Chipaca> jdstrand: daemons are a whole other â¦ uh â¦ species?
<jdstrand> Chipaca: I may not be clear. we handle daemons across refresh fine. so we just want to know if non-daemons are in the cgroup.
<cachio__> pedronis, journalctl on trusty supports cursors
<Chipaca> jdstrand: yes
<Chipaca> bah
<Chipaca> yes
<Chipaca> i wouldn't mind if at first we were just careful about purely-non-daemon snaps
<mvo> niemeyer: I put the apt integration ideas here: https://forum.snapcraft.io/t/providing-hints-about-snaps-from-apt/4301
<Chipaca> baby steps, etc
<cachio__> pedronis, I'll make a change to use it instead of rotating the logs
<mup> PR snapd#4776 opened: Do not auto-import from loop/ram devices <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4776>
<niemeyer> mvo: Thanks!
<niemeyer> Chipaca: I'm in the travel stuff call, but while the propaganda goes on: it would be nice to understand *why* --rcfile doesn't work
<Chipaca> niemeyer: you mean, *why* the code does what it does?
<niemeyer> Chipaca: Yeah, it's not like bash changes very often.. that sort of breakage sounds surprising
<Chipaca> niemeyer: or are you asking about the code
<jdstrand> Chipaca: I can imagine something along the lines of: refresh is downloaded. snapd sets a flag 'refresh pending', it checks the freezer, if nothing running, refresh. if running, idle til no running, then refresh, then unset the review pending flag. we can use the 'review pending' flag in snap run to avoid a race for starting the app between the 'is empty' check and the refresh is finished
<Chipaca> niemeyer: it's a distro patch that adds /etc/bash.bashrc that tweaks the manapage one way, which is not how shell.c is written
<jdstrand> Chipaca: with what I outlined, that could be all implemented without a prompt. ie, snapd becomes smarter about when to refresh. than at some future date, could tastefully alert the user that the refresh is pending
<niemeyer> [niemeyer@nomad ../snapd/cmd/snap]% bash --rcfile ./foo.sh
<niemeyer> What
<niemeyer> niemeyer@nomad:~/src/github.com/snapcore/snapd/cmd/snap$
<niemeyer> Chipaca: That's 16.04
<Chipaca> jdstrand: âerror: the app "hello-world" has a refresh pending; please try again later (you can close all current apps from the snap to make this happen faster)â?
<jdstrand> Chipaca: yes. but maybe 'a refresh in progress' would be better
<Chipaca> jdstrand: true
<Chipaca> sounds very doable (but a lot of work) (also, need something for gui apps)
<Chipaca> niemeyer: and without --rcfile?
<zyga> jdstrand I'll do that lunch for real now, let me know if the apparmor rules in the pastebin look sensible, I will open a PR soon
<jdstrand> Chipaca: because you only prompt for that when we started the refresh. ie, if vlc is running and a refresh is pending, the user should be able to launch another vlc
<jdstrand> Chipaca: both need to be gone to [trigger the refresh, which blocks the launch
<jdstrand> s/\[//
<Chipaca> niemeyer: how about: bash --rcfile ./foo.sh -x
<Chipaca> jdstrand: ah, gotcha
<jdstrand> Chipaca: that's a pretty cool idea if I say so myself :)
<Chipaca> jdstrand: quick write it down
<jdstrand> I think it only took a year or more of my brain thinking about it in the background to think of it :P
<jdstrand> Chipaca: the real trick is the 'is cgroup empty of non-daemons' check. everything else should be relatively straightforward
<Chipaca> this still needs the 'drop revision from env vars'
<jdstrand> Chipaca: yes
<Chipaca> but might not need the 'cp -> mv && cp' change
<jdstrand> Chipaca: cause we don't have a way to change the environ for a running process in a way that could possibly be contrued as sane
<jdstrand> Chipaca: so the env handles new files. the defer handles open fds, but also adds robustness and improves usability
<jdstrand> (and by handling them, it punts on them :)
<jdstrand> but that's ok and desirable
<jdstrand> it is very natural to defer an update if something is running. it is less so to change things behind the apps back
<jdstrand> Chipaca: actually, we don't need the env. the refresh was deferred. the new env will only ever be in effect after the refresh
<Chipaca> jdstrand: right, but if the app picks up the env var to stick it in config, it breaks
<jdstrand> Chipaca: that's entirely fair
<jdstrand> Chipaca: pointing at current is a good idea for lots of reasons
<ackk> sergiusens, mvo, will "base-18" be called "core" on bionic, once it's released? or will it keep the numbering?
<jdstrand> Chipaca: istr we didn't initially cause we weren't sure we always wanted the symlink
<roadmr> zyga: I found bsutton in the forum :)
<sergiusens> ackk: I have no idea, which is why I wanted this a bit more formally documented (not just IRC fly by conversation)
<sergiusens> I suspect, no; but it would be nice to have this recorded
<ackk> sparkiegeek, I'm asking 'cause we currently have "base: base-18" in our snap for bionic, if it's going to be called "core" I'm not sure how you could run a bionic snap on xenial
<ackk> err, sergiusens ^
<niemeyer> Chipaca: https://gist.github.com/niemeyer/c1cfd64dbc8b3f094333b061cd0422fb
<ackk> sparkiegeek, sorry :)
<Chipaca> niemeyer: exactly
<Chipaca> niemeyer: that's /etc/bash.bashrc
<niemeyer> Chipaca: I don't get it.. so what?
<niemeyer> Chipaca: We can set a PS1 like that, can't we?
<Chipaca> niemeyer: that's what sets up command-not-found, which won't work
<niemeyer> Chipaca: Is there no way to disable it?
<Chipaca> niemeyer: that's what echoes "here's how to run sudo"
<mvo> mborzecki: fwiw, I looked at systemd-analyize in a chroot and also at the source, it does not require a dbus connection for me, so either thats a bug in older systemd (I only checked git) or the buildd is doing even stranger things
<Chipaca> niemeyer: the first one yes, the second one no :-) (can't un-echo)
<mup> PR snapd#4723 closed: Translate polkit strings <Created by gunnarhj> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4723>
<Chipaca> niemeyer: if it's the best we can get, I'm ok with it; I'd rather tweak bash.bashrc in core to avoid that
<niemeyer> Chipaca: Okay, but those sound like two separate issues: we can do less in bashrc, which would be a bug for the base, and then have a stock bashrc which does more, which doesn't have to be in the base
<Chipaca> niemeyer: bases will still work because they (shouldn't / won't) have /etc/bash.bashrc in the first place
<Chipaca> niemeyer: i mean, my proposed change for bash.bashrc was literally '[[ "$SNAP" ]] && return'
<niemeyer> Chipaca: Ah, ok, and the PS1 change elsewhere?
<Chipaca> yes
<Chipaca> could also go with SNAP_COOKIE if SNAP is too easy
<Chipaca> :-)
<Chipaca> (aside: why do we have both SNAP_COOKIE and SNAP_CONTEXT)
<niemeyer> Chipaca: Brilliant!
<niemeyer> Chipaca: Histerical
<Chipaca> sigh
<niemeyer> Chipaca: One of these is obsolete and should be dropped eventually
<Chipaca> niemeyer: you know how they cured hysteria, right?
<Chipaca> I can't tell you because NSFW
<Chipaca> anyhow, moving on
 * cachio__ lunch
<arm1e> Hi,
<arm1e> I would like to package software as snaps but I have no packaging experience. I have read the documentation but where can I learn how to package software. I heve no programming experience, but really want to help port apps
<Chipaca> zyga: i addressed your concerns with #4775 i think
<mup> PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775>
<mup> PR snapd#4777 opened: i18n: simplify NG usage by doing the modulo math in-package <Created by chipaca> <https://github.com/snapcore/snapd/pull/4777>
<zyga> Chipaca ack
<Chipaca> popey: do you have anything you'd recommend arm1e ?
<popey> wat wat?
<mup> PR snapcraft#1971 opened: tests: remove dependency of internal repo from integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1971>
<mup> PR snapcraft#1972 opened: tests: remove _options dependency from integration suite <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1972>
<popey> oooh
<popey> arm1e: hello!
<arm1e> hey popey
<popey> arm1e: https://docs.snapcraft.io/build-snaps/get-started-snapcraft
<popey> thats a good place to start, to get your system setup to build snaps :)
<arm1e> allready done :)
<popey> (if anything on that page doesn't work, let me know, I wrote it)
<popey> Maybe start seeking out some things to snap. Want an idea or two?
<arm1e> please
<Chipaca> pedronis: #4770 is all nice and pretty and ready to go places
<mup> PR #4770: store: parse the JSON format used by the coming new store API to convey snap information <Created by pedronis> <https://github.com/snapcore/snapd/pull/4770>
<pedronis> Chipaca: thx
<popey> One relatively easy place to start is with electron apps
<popey> Especially if they use electron-builder
<popey> We wrote this task for Google CodeIn, but it's still valid. https://codein.withgoogle.com/tasks/5004124745629696/
<mup> PR snapd#4770 closed: store: parse the JSON format used by the coming new store API to convey snap information <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4770>
<popey> That might be a good starting point :)
<arm1e> cheers
<jjohansen> jdstrand: interesting question. It will depend on the ordering of the update and operations in the unfreeze. If the migration happens before the profile update, I think a revalidation should happen. Basically on the migration the task has to be associated with a profile before the profile update.
<jjohansen> As long as that happens the revalidation should happen, if however the association of task to profile happens on say unfreeze, that would be after the profile update, and the update then becomes invisible to the task, so revalidation would not happen.
<Guest85417> any tutorial to build a golang snap?
<Guest85417> i have an app that uses the com port, trying to port it on an ubuntu-core gateway
<davidcalle> Guest85417: golang snaps have a nice intro here https://docs.snapcraft.io/build-snaps/go
<Guest85417> Thanks. going to try this
<jdstrand> jjohansen: interesting. I think the question is academic at this point, because the idea that prompted it had a usability issue
<mup> Issue snapcraft#1973 opened: Support quering package manager in tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1973>
<mup> Issue snapcraft#1974 opened: organize with forward slashes should be stripped <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1974>
<cachio__> mvo, snapd upgrade does not work with last systemd on bionic
<cachio__> mvo, confirmed also running on qemu
<mvo> cachio__: what error do you see?
<nacc> sergiusens: would really appreciate your guidance on LP: #1752481
<mup> Bug #1752481: Regressions in 2.39.2 in xenial-updates in classic snaps (relative to 2.35) <snapcraft (Ubuntu):New> <https://launchpad.net/bugs/1752481>
<cachio__> mvo, after upgrade the snaps are not mounted anymore
<cachio__> mvo, I see this with systemd 237-3ubuntu3
<zyga> mvo I looked at that briefly and mount units were all stopped
<zyga> mvo I didn't recall if other things were stopped
<cachio__> it is like you install a new snapd and then the snaps appear as broken
<cachio__> mvo, I am kind of stuck, don't know where to see
<cachio__> zyga, what do you suggest to review?
<cachio__> zyga,  not sure how to continue
<zyga> cachio__ look at the journal output during the update
<zyga> see what happens
<zyga> maybe there's a hint as to who stops the units
<zyga> maybe they get stopped because of some reverse dependency with snapd
<zyga> so maybe check if stopping snapd.{socket,service} affects anything else
<cachio__> the only weir thing I saw in the logs is
<cachio__> Mar 01 13:22:58 autopkgtest snapd[30308]: 2018/03/01 13:22:58.805777 main.go:78: Exiting on terminated signal.
<cachio__> after the units are unmounted
<zyga> that's snapd being SIGINT'ed probably
<zyga> after?
<cachio__> zyga, https://paste.ubuntu.com/p/zVWGtZc6yj/
<cachio__> yes, afetr
<cachio__> then the units are not mounterd
<zyga> yeah
<zyga> no idea
<zyga> really
<zyga> mvo more reasons to make 2.32.1.x as a quiet safe thing
<cachio__> I'll add more log in this line to see if there is some hink
<zyga> cachio__ reproduce this manually
<zyga> and poke around
<zyga> not sure
<zyga> see if updating the package really triggers this
<zyga> see if there's something in the postinst/preinst scripts
<cachio__> zyga, already check those
<cachio__> zyga, np, I have something to dig into
<nacc> so i've got a tricky situation in a classic snap building on xenial; I need the latest version (well technically just the files) from specific packages (debian-archive-keyring and ubuntu-keyring) in the latest release.
<zyga> cachio__ does it happen if you update from 2.31 to 2.31.1 on bionic?
<cachio__> did not try that
<zyga> I'm trying to understand if 2.32 is broken
<zyga> or if bionic is broken
<cachio__> I updated from 2.31.1 to the current
<cachio__> well, if I run the same in another system it works
<cachio__> even in an older bionic
<cachio__> the problem is in the last bionic versions
<cachio__> at some point systemd and the kernel were updated
<mvo> cachio__, zyga hmmm, thank you. so just to confirm 2.31 is ok?
<mvo> cachio__: or is that a bit of an unkown at this point?
<zyga> mvo I don't know yet, I'm not checking either (digging in another hole)
<cachio__> I'll run sru on this bionic version to see if it works
<sergiusens> nacc: is your not working link an actual non working one?
<sergiusens> nacc: is this version related?
<nacc> sergiusens: it's a bunch of stuff it seems like
<nacc> sergiusens: well, the snap it built is non-functional
<nacc> sergiusens: and it *was* functional just before the snapcraft SRU
<sergiusens> nacc: oh, ic; this seems not related to the patchelf work but probably our pip consolidation; kyrofa want to take look?
<nacc> sergiusens: the version seems wonky, though
<cachio__> zyga, mvo I installed 2.29 and upgraded to 2.31.1 and works
<zyga> cachio__ good, thank you for checking htat
<cachio__> then I upgraded to 2.32~ and failed
<sergiusens> nacc: yes, some files got modified locally during build it seems; can I see your sources?
<zyga> it means we can safely release point release from 2.31
<zyga> cachio__ can you diff packaging before/after
<nacc> sergiusens: https://git.launchpad.net/usd-importer?h=master
<zyga> I mean the actual package for 2.31 and 2.32
<zyga> I recommend meld (in the archive) for that
<zyga> see if anything odd stands out
<arm1e> popey: 'Update the version of electron-builder to â^19.53.0â in dev/Dependencies' How do I do this?
<nacc> sergiusens: sigh
<nacc> sergiusens: you changed where you look for setup.py
<nacc> sergiusens: from self.builddir to self.sourcedir
<nacc> sourcedir is not updated for subdir
<cachio__> zyga, ok, I'll do
<zyga> you can unpack the packages with dpkg or with mc :)
<nacc> sergiusens: i can see it in the srcpkg diff
<sergiusens> nacc: oh; darn :-/ To shed some good news though, you probably do not need to build your own python anymore
<nacc> sergiusens: hey, that's something! :)
<nacc> sergiusens: what changed there? we do depend on a newer python3 than in xenial
<sergiusens> nacc: this happened https://forum.snapcraft.io/t/classic-snaps-failing-on-ubuntu-17-10/2324/34
<nacc> sergiusens: relevant diff https://paste.ubuntu.com/p/8dC9Bmh7r2/
<sergiusens> we use the python3 in xenial
<nacc> sergiusens: right, that's tool old for us
<sergiusens> nacc: yeah, this is kyrofa's refactor (not his fault) as it slipped me too... this source-subdir feature is such a pain :-/
<nacc> sergiusens: now, what you linked to might fix some of the stuff i hit with the loader when i was building 'on' artful
<nacc> sergiusens: ack, just happened to break us pretty badly :)
<sergiusens> nacc: try the deb on bionic or the snap on artful, they should do the right thing
<nacc> sergiusens: well, snapcraft cleanbuild jsut started failing on my bionic mahcine at home
<sergiusens> nacc: it eventually broke everyone as it is a feature tied with single threaded strings
<nacc> sergiusens: oh you mean for the above change, ack
<popey> arm1e: it's in the package.json
<nacc> sergiusens: the problem is right now i can now no longer cleanbuild and i can't get LP to build correctly because xenial-updates is busted :(
<sergiusens> nacc: sorry, yeah, snapcraft in bionic-updates will give you what you need wrt to proper "library environemtns"
<nacc> sergiusens: cool, i will try it
<sergiusens> nacc: and source-subdir is a dreadful feature
<sergiusens> nacc: the other dreadful feature we have is that we do not require `setup.py` in the source :-/
<sergiusens> nacc we plan to do an SRU on Monday, I will make sure to include a fix for you
<nacc> sergiusens: i can imagine; what would you recommend i do in the meantime?
 * kalikiana heading out for the day
<nacc> sergiusens: any idea on the version thing?
<sergiusens> nacc: I think it is related to running pip from that source and a lack of .gitignore; I can run locally to determine which file is getting layed out where it shouldn't
<nacc> sergiusens: would it make sesne to get the version *before* doing the build?
<nacc> sergiusens: since using git to get the version is an attribute of the original repository
<sergiusens> nacc: the reason it is done this way is to account for all the possible scenarios; this feature was mostly done to support giving the core image a version which would attach the version of snapd inside it; that meant; after the livecd-rootfs build was done and primed
<sergiusens> nacc: but yeah, for `git` specifically we could
<sergiusens> we will be working in the coming weeks on pre/post prepare,build,stage,prime and adding setters for version, description and summary as a start which could be scripted any way you like
<nacc> sergiusens: nice
<sergiusens> nacc: I will migrate to a faster location and work on this, I will keep you updated
<nacc> sergiusens: thanks, i really appreciate it
<cachio__> zyga, there are many diffs
<cachio__> zyga, the systemd part is the same
 * Chipaca EODs
<cachio__> mvo, I found something interesting
<cachio__> mvo, if I upgrade from 2.29 to 2.32 it works
<cachio__> it I upgrade from 2.31.1 it fails
<mvo> cachio__: woah, that is interessting indeed
<mup> PR snapcraft#1975 opened: python plugin: find setup.py when source-subdir is used <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1975>
<sborovkov> Hi. Can anyone take a look at this forum thread? Ubuntu core nodes just die after few hours of uptime. https://forum.snapcraft.io/t/how-to-figure-out-why-ubuntu-core-keeps-restarting/4257/2
<sborovkov> which seems to be a pretty serious issue
<zyga> re
<zyga> cachio__ did you unpack maintainer scripts?
<zyga> as in, did the tree contain the upper-case DEBIAN directory
<zyga> cachio__ and if so, did you did that part as well
<cachio__> zyga, no that part
<cachio__> something weird is that upgrade 2.29 - 2.32 works
<cachio__> 2.31.1 - 2.32 doesn't
<cachio__> I was running ubuntu core now
<cachio__> zyga, there is an error that you could be interested
<cachio__> the layout test is failing in ubuntu core
<cachio__> zyga, last exec it passed
<arm1e> popey: Sorry, had to sort kids. I am looking for the package.json file and it does not mention electron builder. There is one in the electron folder and another in the core folder
<cachio__> zyga https://paste.ubuntu.com/p/wgDf97qZRP/
<cachio__> zyga,  there is a denial
<cachio__> but it is not failing 100%, sometimes it passes
<zyga> I saw that error and that denial, not sure what's wrong yet
<zyga> I'm spending time with my son now (homework)
<zyga> cachio__ but I have one idea what is wrong with layouts now
<zyga> may be the same bug, not sure yet
<cachio__> zyga, sure, np
<arm1e> can anyone help teach me about snapping an electron app please?
<cachio__> zyga, the control files are identical
<cachio__> for 2.31.1 and 2.32
<cachio__> the only one diffs are some dependencies
<arm1e> anyone help with building an electron app please? I cant find the "scripts" stanza in the package.json file
<arm1e> there is no build or target
<roadmr> hi sergiusens . parts-service is borky because one of the parts has yaml syntax errors. I contacted the author hours ago but nothing. WHat's usually done here? remove the part entirely?
<sergiusens> roadmr: yes, remove the part
<sergiusens> comment it out
<roadmr> sergiusens: will do
<roadmr> thanks!
<mup> PR snapd#4755 closed: snap/squashfs: add BuildDate <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4755>
<mup> PR snapd#4778 opened: tests: moving debian 9 from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4778>
<jdstrand> slangasek: hey, do you have a moment to talk about https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1751667
<mup> Bug #1751667: classic snap does not run on live session <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <ubiquity (Ubuntu):New> <https://launchpad.net/bugs/1751667>
<slangasek> jdstrand: sure
<jdstrand> slangasek: I can give you the summary
<jdstrand> slangasek: if you recall, the bionic kernels use overlay
<jdstrand> slangasek: so I fixed that and classic and strict (and devmode) snaps all work (yay, will be in 2.32)
<slangasek> nice!
<jdstrand> slangasek: but something regressed in bionic in that nothing in /etc/apparmor.d/ is loaded
<slangasek> hmm
<jdstrand> slangasek: which causes snap-confine to fail like so:
<jdstrand> $ hello-world
<jdstrand> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<jdstrand> slangasek: this happens with  just the livecd today, so you don't even get to the point where overlay broke things
<jdstrand> slangasek: I couldn't remember what you did before to make classic snaps work
<jdstrand> slangasek: really, we do *not* want to load all of /etc/apparmor.d, but we do want to load /etc/apparmor.d/*snap-confine*
<jdstrand> slangasek: so I think in the general case, the livecd is doing the right thing
<mwhudson> can we blame casper
<jdstrand> slangasek: but we're missing the 'apparmor_parser -r /etc/apparmor.d/*snap-confine*' somewhere
<slangasek> jdstrand: doesn't snap-confine being confined rely not just on /etc/apparmor.d being loaded, but also on snap-confine being at /usr/lib/snapd/snap-confine , which it isn't, because overlay?
<jdstrand> slangasek: no
<jdstrand> slangasek: if I do 'sudo apparmor_parser -r /etc/apparmor.d/*snap-confine*', then I can run hello-world and see the overlay denial (or if you have my deb, it works)
<slangasek> jdstrand: as far as what we did previously, I don't think we did anything... subiquity Just Worked by accident, and then failed when snapd restarted, so we fixed it so snapd didn't restart
<mwhudson> subiquity is ok in this case because it runs as root
<jdstrand> oh, was classic ever only ok with subiquity?
<jdstrand> I was thinking ubiquity, but maybe it never worked there
<slangasek> we never tested on ubiquity
<jdstrand> slangasek: I think reexec will work with snapd 2.32 btw
<jdstrand> ok, then no regression
<jdstrand> I mean, someone should check subiquity-- pretty sure it will die without snapd 2.32
<jdstrand> how could it not?
<jdstrand> slangasek: ok, so if you were going to fix this in ubiquity, what would you do?
<mwhudson> er hm if i load the apparmor profile subiquity doesn't start, complains about libudev.so.1
<mwhudson> oh right that's the sort of thing 2.32 fixes
<jdstrand> slangasek: all I want is to load the snap-confine profiles
<mwhudson> jdstrand: what loads the profiles in a normal boot?
<jdstrand> mwhudson: how does it complain about libudev.so.1?
<mwhudson> jdstrand: DENIED on /rofs/lib/x64-64-linux-gnu/libudev.so.1
<jdstrand> mwhudson: the apparmor init script. it knows that if it is on livecd not to load
<jdstrand> mwhudson: that seems like you are not using the overlayfs kernel?
<mwhudson> oh maybe this is aufs still :(
<jdstrand> mwhudson: artful used aufs, so I would expect denials on /rofs
<mwhudson> yes it is
<jdstrand> mwhudson: bionic is shiny and uses overlay. you would see denials on /upper/... for various thinfs
<jdstrand> things*
<mwhudson> because https://code.launchpad.net/~mwhudson/debian-cd/live-server-cmdline-2/+merge/336177 is not merged
<mwhudson> slangasek: can you merge that branch?
<jdstrand> mwhudson: ah. yes, if you merge that and get snapd 2.32 (couple weeks?) that should work
<mwhudson> slangasek: adam has long passed the timeout for complaining :/
<slangasek> jdstrand: I think I would check where the at-boot apparmor_parser is being suppressed, and add an exclusion there for snap-confine.  Which I think means casper
<jdstrand> slangasek: let me check something
<slangasek> mwhudson: not currently, my stack is full.  email?
<mwhudson> slangasek: ok
<mwhudson> slangasek: is there anyone else who can review this stuff?
<jdstrand> [ -d /rofs/etc/apparmor.d ]  && exit 0 # do not load if running liveCD
<jdstrand> that is in /lib/apparmor/profile-load
<jdstrand> and that exists in bionic
<jdstrand> slangasek: so you are suggesting I do something more like: [ -d /rofs/etc/apparmor.d ] && apparmor_parser -r /rofs/etc/apparmor.d/*snap-confine* ; exit 0
<jdstrand> I might have to tweak that for the shell, but you get the idea
<jdstrand> slangasek: you know, actually, profile-load isn't used by the systemd unit
<jdstrand> I'll look at casper
<jdstrand> ah, but the initscript does
<jdstrand> (apparmor's)
<mwhudson> jdstrand: the service has conditionpathexists=!/rofs/etc/ ...
<jdstrand> slangasek: ok, well, thanks for letting me bounce ideas off ofyou :)
<mwhudson> and it calls the initscript, which has the same checks again, its seems...
<jdstrand> since the initscript has it, I can remove the conditional
<jdstrand> in the service
<mwhudson> i guess that might affect things that require= on apparmor.service?
<mwhudson> i don't know if there are any of those though
<jdstrand> so the service calls the initscript, the initscript just loads those two things
<mwhudson> oh right yes
<mwhudson> once snapd 2.32 is in bionic please :)
<jdstrand> mwhudson: why? the profiles are fine to load
<jdstrand> mwhudson: loading the profiles just means that snaps fail to run in a different way
<jdstrand> mwhudson: am I missing something?
<slangasek> jdstrand: the conditional on the service surely makes a difference for whether dependent things consider the service started or not
<slangasek> or to-be-started
<slangasek> but maybe that gives the wrong answer here in any event
<jdstrand> Condition: start condition failed at Thu 2018-03-01 21:18:49 UTC; 45min ago
<jdstrand> that is what we have now
<mwhudson> jdstrand: if the profiles are loaded subiquity fails to start
<mwhudson> jdstrand: in the current situation the 'elevated privileges' check only fires if subiquity is started as non-root, which isn't interesting anyway
<jdstrand> ah
<jdstrand> yes
<jdstrand> but if it is root, then snap-confine dies cause of /rofs
<jdstrand> got it
<jdstrand> maybe it would be better if snapd loaded them
<mwhudson> right
<jdstrand> bah, my test case was bad. snapd *will* load the profile itself. *sigh*
<jdstrand> systemctl start snapd with 2.32 will load the profile since it generates the overlay. in the bug I did the wrong thing to reproduce
<jdstrand> at least we know how to fix subiquity now :)
<jdstrand> s/overlay/overlay policy/
<jdstrand> sorry for the noise
<mup> PR snapd#4714 closed: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
<arm1e> I have been trying to snap up an electron app but I can't find the relevent sections in the json file. Can anyone please help
<arm1e> I have been trying to snap up an electron app but I can't find the relevent sections in the json file. Can anyone please help
<nacc> arm1e: i've never built an electron snap, but i can try and help
<nacc> arm1e: what happens when you try to snap it?
<mup> PR snapd#4779 opened:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<arm1e> Failed to parse package.json data.
<arm1e> npm ERR! package.json must be actual JSON, not just JavaScript.
<arm1e> npm ERR!
<arm1e> npm ERR! Tell the package author to fix their package.json file. JSON.pars
<arm1e> nacc, basicallly want to learn how to snap packages but I have no experience of packaging or programming and want to learn.
<arm1e> I have completed the tutorial, but EVERY time I attempt to snap something there is a huge hurdle, such as files missing, or expected build properties not present. I just dont know how to learn if there is always a huge problem that I cant understand
<nacc> arm1e: and where is the source?
<nacc> arm1e: it feels counterintuitive to want to make snaps if you aren't the author of the thing you are snapping
<nacc> arm1e: not impossible of course, but it can be harder
<arm1e> https://github.com/LightTable/LightTable
<arm1e> This is from the Google Code-in stuff I was given by popey
<nacc> arm1e: it doesn't seem like a normal electron app, but i don't know
<arm1e> Also tried https://github.com/princejwesley/Mancy/blob/master/package.json
<arm1e> nacc:  That's what I thought so I gave up
<arm1e> I will look into it another day. Too late now, off to bed
<arm1e> nacc: thanks for trying :)
#snappy 2018-03-02
<mup> PR snapcraft#1975 closed: python plugin: find setup.py when source-subdir is used <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1975>
<mup> PR snapcraft#1976 opened: elf: only consider regular files as possible ELF binaries <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/1976>
<mup> PR snapcraft#1977 opened: lifecycle: when priming dependencies need to be primed <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1977>
<mborzecki> morning
<zyga> re
<mborzecki> zyga: hey
<zyga> good morning :)
<mborzecki> damn cold outside, -16 right here
<zyga> but hey
<zyga> it's spring :)
<zyga> city bikes have been re-installed and enabled today
<zyga> :D
<mborzecki> it's spring in ~3 weeks from now :P
 * zyga runs content interface tests and goes for some tea
<mup> PR snapd#4764 closed: configstate: when disable "ssh" we must disable the "sshd" service <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4764>
<mup> PR core#82 closed: xdg-open: add implementation capable of opening local files <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core/pull/82>
<kalikiana> good morning
<pstolowski> morning
<mup> PR snapd#4751 closed: tests: add support for external backend executions on listing test (2.32) <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4751>
<mup> PR snapd#4752 closed: tests: make interface-broadcom-asic-control test work on rpi (2.32) <go go go go!> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4752>
<Chipaca> mvo: good morning!
<mvo> hey Chipaca
<Chipaca> mvo: I'll merge master into #4750, maybe that'll help
<mup> PR #4750: store: getStructFields now take pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4750>
<mvo> Chipaca: aha, ok
<Chipaca> mvo: there
<Chipaca> mvo: the motivation for that PR is a silly / small one (it's a silly little pr): those are some bick heckin' structs :-)
<Chipaca> big*
<Chipaca> my hands were already writing heck
<zyga_> hey Chipaca
<Chipaca> zyga_: you like what I did to the NG-using pr?
<Chipaca> zyga_: also as a directo consequence of that, the NG-improving pr :-)
<zyga_> NG-using pr
<zyga_> I think I need another coffee to parse that
<zyga_> NG
<zyga_> what is that
<Chipaca> i18n.NG
<Chipaca> or was that GN
 * Chipaca looks
<Chipaca> NG
<zyga_> are you referring to ngettext?
<Chipaca> #4775
<mup> PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t <go go go go!> <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775>
 * zyga_ looks
<zyga_> ah
<zyga_> I wasn't aware it's called NG
<Chipaca> zyga_: and #4777
<mup> PR #4777: i18n: simplify NG usage by doing the modulo math in-package <Created by chipaca> <https://github.com/snapcore/snapd/pull/4777>
<zyga_> is the empty argument sensible?
<zyga_> if this is anything like gettext I would expect
<zyga_> NG("%d day ago", "%d days ago", someNumber)
<zyga_> and why does it now say "at 15:04 MST" ?!?
<zyga_> Chipaca feel free to correct me, maybe I'm not really awake yet
<Chipaca> zyga_: mborzecki feedback, that named timezones are more friendly
<Chipaca> zyga_: the first entry is for n==1, and n is never one there, that's why it's empty
<zyga_> but why does humanTimeSince use a hard-coded string "15:04 MST"
<Chipaca> that's the format
<Chipaca> go's t.Format("<the string of how you want a particular date to look>")
<zyga_> ahh
<mborzecki> zyga_: time referecen format https://godoc.org/time#pkg-constants
<zyga_> that's cool I didn't know htat
<mvo> Chipaca: I tripped over this too, maybe a comment?
<Chipaca> / RTFM
<Chipaca> :-P
<zyga_> who designed that :)
<mvo> Chipaca: I remembered this format thing then and forgot abou tit
 * Chipaca is laughing, but at himself
<mvo> zyga_: someone who loves this particular date
<zyga_> at HH:MM XXX would be much nicer
<Chipaca> how could you forget abou tits
<zyga_> Chipaca never forget about tits
 * zyga_ gets that coffee
<Chipaca> ikr
 * mvo wonders about the backstory of that date
<zyga_> <quote day>
<mvo> eh? this is a family channel!
<Chipaca> mvo: families dont have 'em?
<mborzecki> FWIW that format spec is pretty smart compared to the str[fp]time madness
<mvo> *cough*
<mborzecki> it's much more WYSIWYG than other 'formats'
<zyga_> this is like a := 1, b := 3; assert eval("2 + 2", a, b) == 3
<Chipaca> mborzecki: i wish you could precompute them though
<Chipaca> that's a lot of repetitive jiggery to do in a loop
<mborzecki> yeah, the implementation is a bit convoluted :P
<zyga_> last few loops on hardening
<zyga_> the base template got a lot shorter :)
<zyga_> and there are almost no globs left :)
<zyga_> there's one more chunk left but it will become visible with this test pass (extra directory writability permissions)
<zyga_> https://github.com/snapcore/snapd/pull/4765 has a lot of WIP patches, sorry for that, I'll get rid of them
<mup> PR #4765: interfaces/apparmor: use snap name instead of wildcards <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<zyga_> I'll tidy this up soon
<Chipaca> mvo: zyga_: so, should ngettext _always_ have a first, reasonable string even when you know it's never singular? is there a case where ngettext will return the singular for n>1?
<zyga_> not in english,
<zyga_> in english it is only for n==1
<zyga_> in other languages you have many cases and you should not assume there's no "singular" because of the value
<Chipaca> right, but it'd not be using the empty string in those cases
<Chipaca> unless it confuses things because msgid?
<zyga_> hmm, I don't know
<zyga_> I don't suppose it hurts to just use the singular string
<Chipaca> eh, ok, i'll change it
<Chipaca> drat, it needs to have a %d doesn't it
<mvo> Chipaca: I was thinking about this too, all the plural forms I know have only a single singular and many multiple plurals (> 2, >10 etc) but *maybe* there are more so it does not hurt to have the singular
<mvo> plus the comment
<Chipaca> mvo: like https://github.com/snapcore/snapd/pull/4775/commits/75cc9c7966e0eb67d4f637e3d31e8628f85d9006 ?
<mup> PR #4775: timeutil: timeutil.Human(t) gives a human-friendly string for t <go go go go!> <Created by chipaca> <https://github.com/snapcore/snapd/pull/4775>
<mvo> Chipaca: :+1:
<sergiusens> Chipaca: we did time formatting like that for ubuntu-push-notifications iirc
<Chipaca> sergiusens: anything learned?
<sergiusens> good morning and good day (parting towards next weeks destination)
<sergiusens> Chipaca: I still don't like it if you asked me again :-P
<Chipaca> sergiusens: is there anywhere in snapcraft you check summaries don't have \n's?
<sergiusens> Chipaca: I am not sure, but I need to shutdown, will continue from the airport (where irc is blocked)
<Chipaca> sergiusens: telegram me :-)
<Chipaca> sergiusens: o/
<sergiusens> o/
<Chipaca> ok, physio time
 * Chipaca afk for a while
<mvo> jdstrand: does 4766 look good to you after the latest changes from james?
<mup> PR snapd#4780 opened: snap: add autostart app property <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4780>
<mvo> zyga_: I just pushed a fix for 4779
<zyga_> Thank you!
 * pstolowski lunch
<ackk> mvo, hi, I see your last commit on base-18 is about adding tzdata, but it doesn't seem that the snap actually has /usr/share/zoneinfo files?
<ackk> (was testing the maas snap with it, but postgres still fails because of missing timezones)
<zyga>  jdstrand hey
<zyga> jdstrand please have a look at 4765 again
<zyga> I can split it if that makes it easier
<zyga> I just fired one more run and it shoud *fingers crossed* work
<mup> PR snapd#4780 closed: snap: add autostart app property <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4780>
<mborzecki> Chipaca: guess what failed https://paste.ubuntu.com/p/G2wTbP4f6r/ SquashfsTestSuite.TestBuildDate
<mvo> ackk: hm, maybe it was not build or something, let me check
<mup> PR snapd#4781 opened: wrappers: refactor desktop file sanitizer to support autostart files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4781>
<mborzecki> mvo: have you looked into adding some shlexer to our codebase?
<sborovkov> is there some env variable that has core version? Or how can I find out snapd version from my own snap?
<zyga> sborovkov there's no such variable
<zyga> why do you need to know the version of snapd?
<zyga> there are a few ways perhaps but not sure why you'd want to know that
<sborovkov> well we want to report node info
<sborovkov> in case there are issues on the customer's device
<sborovkov> having snapd version would help
<zyga> I think you can get it the same way snap --version does
<zyga> there's an API endpoint for this
<zyga> I think it is /v2/system-info
<zyga> just GET that
<zyga> over the snapd socket
<sborovkov> ok thanks
<mborzecki> Chipaca: bad news, there does not appear to be any no timezone information in squashfs files
<mborzecki> Chipaca: well, at least in unsuqashfs -s output
 * zyga small break
<pedronis> mborzecki: does it respect TZ if set ?
<pedronis> that might be a way out
<mborzecki> pedronis: yes, i'm fixing it right now
<mup> PR snapd#4776 closed: Do not auto-import from loop/ram devices <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4776>
<Chipaca> mborzecki: gah
<Chipaca> mborzecki: yes, squashfs times are always local
<Chipaca> so there's a bug in the test
<mborzecki> Chipaca: i'm opening a PR in a minute
<ackk> mvo, AFAICS LP did build it and publish, not sure what happened thouhg
<Chipaca> mborzecki: ah ok
<mup> PR snapd#4782 opened: snap/squashfs: set timezone when calling unsquashfs to get the build date <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4782>
<mborzecki> Chipaca: ^^
<Chipaca> ogra_: you around?
<mborzecki> linode is down? https://paste.ubuntu.com/p/4v2qHSsnV9/
<Chipaca> mborzecki: silly question, does it work if you _just_ set Env to TZ=UTC?
<mborzecki> Chipaca: without append(os.Environ()..) ?
<Chipaca> mborzecki: yep
<mborzecki> let me check
<Chipaca> mborzecki: that's a very clever way of fixing it, we should do it in Walk as well
<mborzecki> Chipaca: yeah, just TZ=.. works too
<Chipaca> mborzecki: hmm
<Chipaca> mborzecki: so, the way Walk handles it is by doing time.ParseInLocation(..., time.Local)
<Chipaca> mborzecki: see parseTime in snap/squashfs/stat.go
<mborzecki> Chipaca: right, that might be even nicer than enforcing TZ
<Chipaca> well, maybe
<Chipaca> what happens if you're just before DST
<Chipaca> such that time.Local and unsquashfs have different opinions on what side of the change you are
<pedronis> TZ=UTC   and  ParseInLocation(time.UTC) then
<pedronis> or is that the default for Parse ?
<Chipaca> it is
<mborzecki> hm time.Parse(time.ANSIC..) implies UTC
<jdstrand> mvo: hey. re 4766> no. nothing was done with snapFromSenderImpl (that's also the bit I asked you to look at)
<mborzecki> for that matter, any time.. format that lacks timezone placeholder implies UTC, i ca make it explicit though, Chipaca pedronis what do you think?
<zyga> jdstrand hey!
<jdstrand> hey zyga :)
<zyga> jdstrand https://github.com/snapcore/snapd/pull/4765 may be ready, I am looking at fixing the bug in /etc and other similar places
<jdstrand> looking at 4765 now
<mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<zyga> thanks!
<pedronis> mvo: mborzecki: any reason not to fix the todo  about passing  MaxDuration into timeutil.Next , IÂ need to reuse maxDuration in snapstate so IÂ would like to do that change
<Chipaca> i like the garters-and-belt approach of TZ=UTC and Parse
<jdstrand> zyga: cool
<zyga> jdstrand it ended up big, feel free to request extra tests and other refactorings
<Chipaca> (Parse picks up location from the value but falls back to UTC, so there's an extra layer of strapping there)
<jdstrand> zyga, mvo: if you could look at PR 4779, that would be great :)
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<zyga> jdstrand ack
<Chipaca> mborzecki: can you do the same thing to the one over in stat?
<pedronis> mvo: mborzecki: I'm talking about this:  https://github.com/snapcore/snapd/blob/master/timeutil/schedule.go#L401
<mborzecki> pedronis: go ahead as far as i'm concerned, iirc niemeyer wanted get rid of it too
<jdstrand> pedronis: hey, curious if you were going to backport the go vet fix to 2.32 for: overlord/ifacestate/handlers.go:580: github.com/snapcore/snapd/overlord/state.Retry composite literal uses unkeyed fields
<mborzecki> Chipaca: just Parse(), no InLocation?
<jdstrand> exit status 1I saw you fixed it in master (thanks!)
<jdstrand> err
<pedronis> jdstrand: I can if needed
<mup> PR snapd#4775 closed: timeutil: timeutil.Human(t) gives a human-friendly string for t <go go go go!> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4775>
<Chipaca> mborzecki: yes
<jdstrand> I saw you fixed it in master (thanks!)
<jdstrand> pedronis: I mean, it would be handy for me (I develop in a 16.04 container), but I don't know who else is affected
<jdstrand> I can work around it
<pedronis> jdstrand: np, IÂ just didn't bothered because it didn't seem to affect anything else
<pedronis> but it's useful IÂ can
<pedronis> there's also a flaky test fix that I was asked to backport
<jdstrand> like I said, it would be to me, but I don't know how hard the fix is and would hate to add more to your plate (I was mostly asking out of curiosity). I can work around it
<jdstrand> so I'll leave it up to you
<pedronis> jdstrand: I'm a bit juggling many things (aren't we all), but I'll look into it today
<mvo> sborovkov: hey, you mentioned a boot failure right? do you have more details like what the fs looks like (post-mortem) or even give us access to a copy of the fs?
<jdstrand> pedronis: if you get to it, thanks. if not, that's totally fine and thank you for considering it :)
<mborzecki> Chipaca: pushed
<zyga> jdstrand how do you feel about that hardening PR?
<Chipaca> pedronis: I fixed the comment on #4738 fwiw
<mup> PR #4738: snap: unify snap name validation w/python; enforce length limit <Created by chipaca> <https://github.com/snapcore/snapd/pull/4738>
<jdstrand> zyga: I'm still looking at it
<sborovkov> mvo: so this happens after snapd updates from 2.31 to 2.31.1 here
<sborovkov> sure I have what fs looks like
<sborovkov> give me few mins to download that
<mvo> sborovkov: ohhhhh
<mvo> sborovkov: that is interessting
<sborovkov> https://www.dropbox.com/s/gx17h6emu9uott5/corrupt-disk.img.7z?dl=0
<mvo> sborovkov: we have an independent report about an upgrade issue on bionic (but only there)
<sborovkov> this is the dump of the SD card
<mvo> sborovkov: \o/ thank you
<sborovkov> I also have an image where this reproduces :)
<sborovkov> I managed to reproduce it 3 times today
<mvo> sborovkov: can I haz?
<mvo> sborovkov: I'm really keen to get to the bottom of this
<sborovkov> yeah sure
<sborovkov> but you will need ssh assertion to login to that system
<sborovkov> https://storage.cloud.google.com/screenly-diskimages/promoted/screenly-v2-pi3-2018-02-09-bbc27f2.img.zip.md5
<sborovkov> this is the image
<sborovkov> so today I did this few times - flashed it out. Let it initialize
<mvo> sborovkov: ok, let me first look at the broken one
<mvo> sborovkov: maybe that gives me some clues
<sborovkov> it works great after reboots
<sborovkov> as soon as I do snap refresh core
<sborovkov> it fails at the next reboot
<sborovkov> or one after next
<mvo> sborovkov: so this is 2.31 -> 2.31.1 ?
<sborovkov> yes
<sborovkov> image was created from stable 1 week ago
<mvo> ta
<sborovkov> image is created by ubuntu-disk-image with 2 extra snaps
<sborovkov> one is our own snap. another one is udisks.
 * kalikiana lunch
<sborovkov> mvo: I also can flash another one of that and run some logging during/after core update if needed
<sborovkov> but only today as I have flight to Shanghai tomorrow
<mvo> sborovkov: I need to travel soon too so today is definitely my preference
<mvo> sborovkov: I am looking at the diff right now
<niemeyer> sborovkov: ping
<niemeyer> sborovkov: Do you have a moment for a call with some of us?  Would be nice to have a quick conversation with more bandwidth
<niemeyer> sborovkov: In 45 minutes maybe, if that works for you (30 mins past the hour)
<mvo> I just tested a 2.31->2.31.1 on amd64 and that went fine, I'm trying on armhf now
<jdstrand> zyga: https://github.com/snapcore/snapd/pull/4765#pullrequestreview-100766399
<mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<sborovkov> niemeyer, sure
<zyga> Thank you!
<zyga> looking
<jdstrand> zyga: I have an appt in a few minutes and will step away for a little bit, but will be back after not too long
<zyga> ok
<zyga> thank you for letting me know
<mvo> ok, 2.31 -> 2.31.1 on pi3 is also fine
 * mvo scratches head
<sborovkov> mvo, another thing that we noticed is that it does not fail all the time. One of test nodes is still running, but for all devices that are broken we did insert the USB stick to RPI (in my case for assertion with ssh).
<mup> PR snapd#4782 closed: snap/squashfs: set timezone when calling unsquashfs to get the build date <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4782>
<mvo> sborovkov: thanks, that is a very useful data-point, let me try this too. maybe some bad interaction with the udisk snap or something like this
<mup> PR snapd#4783 opened: ifacestate: be consistent passing Retry.After as named field (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4783>
<mup> PR snapd#4784 opened: asserts:  use a timestamp for the assertion after the signing key has been created (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4784>
<pedronis> mvo: zyga: jdstrand: I created a couple of trivial cherry-picks for 2.32 ^^^
<zyga> kk
<sborovkov> niemeyer, i am ready :)
<niemeyer> sborovkov: Let's go.. let me get a link
<niemeyer> sborovkov, mvo, zyga: https://hangouts.google.com/hangouts/_/canonical.com/debug-session
<cachio__> mvo, hey
<cachio__> mvo, dod you already know when the 2.32 rc2 is comming?
<mvo> cachio__: on hold right now, zyga found a critical bug with layouts
<zyga> I will propose a fix for this later today
<cachio__> perfect
<cachio__> zyga, it is related with the error on the test that I sent you yesterday?
<cachio__> i also saw it on linode today
<zyga> not sure which one was that
<zyga> about /etc, yes
<zyga> if not about /etc then no
<cachio__> yes
<cachio__> that one
<cachio__> nice
<cachio__> zyga, so
<cachio__> thanks for fixing it
 * Chipaca afk for a bit
<mup> PR snapcraft#1978 opened: ci: switch to stable lxd and unconfined containers <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1978>
<zyga_> popey who is managing sublime-text-3 snap?
<zyga_> I'd love edge to have the more recent dev build
<zyga_> (dev build has a feature I like)
<popey> https://github.com/snapcrafters/sublime-text
<popey> pull requests welcome ;)
<zyga_> Chipaca should snap list show the size of the snap?
<Chipaca> zyga_: it doesn't
<zyga_> I know
<zyga_> I was thinking what if it did
<Chipaca> zyga_: let's talk at the sprint
<sborovkov> mvo: what's your pgp key? will send you an assertion encrypted
<zyga_> Chipaca sounds good
<zyga_> sborovkov https://keyserver.ubuntu.com/pks/lookup?fingerprint=on&op=index&search=0xDA6C6754D8887626CD06A12898CABB3ABD4CA59E
<mvo> sborovkov: https://pgp.mit.edu/pks/lookup?op=vindex&search=0x98CABB3ABD4CA59E
 * Chipaca really afk this time
<sborovkov> mvo: https://fd-files-production.s3.amazonaws.com/private/190661/25604/iY9HQ7y0B_z3z_NPI7WKhA?X-Amz-Expires=300&X-Amz-Date=20180302T152436Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIA2QBI5WP5HA3ZEA/20180302/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=e3f124f18e208640518bf87e62cdcd31b2ab6bca8ad59eb926ad96c17b207796
<sborovkov> and this is link to image - https://storage.cloud.google.com/screenly-diskimages/promoted/screenly-v2-pi3-2018-02-20.img.zip
<zyga-ubuntu> hmm hm
<mvo> sborovkov: downloading the image now
<mvo> sborovkov: the other link is expired, please jsut mail it to me
<mvo> zyga-ubuntu: any clues?
<zyga-ubuntu> mvo: no, looking at the raw image
<mvo> zyga-ubuntu: yeah I find it interessting that only hte old core is on the image
<mvo> zyga-ubuntu: no trace of the new one
<mvo> zyga-ubuntu: I was also browsing the logs
<mup> PR snapd#4785 opened: tests: moving ubuntu core from linode to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4785>
<jdstrand> mvo: does PR 4779 need a second +1? I see you fixed up an unrelated merge issue and the tests now pass
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<zyga-ubuntu> mvo: after mounting p1 I see that there are two "uboot.env" files
<zyga_> -rwxr-xr-x 1 root root  131072 lut 28 13:34 uboot.env*
<zyga_> -rwxr-xr-x 1 root root  131072 lut 28 13:34 uboot.env*
<mvo> jdstrand: I think its fine to land, I wanted to have a closer look but $things happend to me :/
<mvo> zyga: how is that even possible
 * mvo looks
<zyga-ubuntu> mvo: no idea, just mount p1 and see
<zyga-ubuntu> maybe we can use some low-level fat tool to list and read that file
<zyga-ubuntu> (there is such a thing, I will look at that)
<mvo> zyga-ubuntu: I see it too
<mvo> zyga-ubuntu: hm - no error from fsck.vfat (well, dirty bit set but no real error) but still two uboot.env files
<zyga> this is from fatcat
<zyga> https://pastebin.ubuntu.com/p/mnhDXb7jXP/
<mvo> sborovkov: I have things ready here, just need the ssh assertion, will step out for some minutes but will read scrollback
<mvo> zyga looking
<zyga> there's a lower-case and an upper-case version of that file
<zyga> as _separate_ files
<mvo> zyga haha, of course
<zyga> one is from 1980
<zyga> and another one from 2018
<zyga> hold on, I think I can remount the fs to see them
<mvo> zyga is it possible to diff them
<zyga> yes, they are identical
<zyga> this is probably not perfect but doesn't look like a bug
<zyga-ubuntu> mvo: core snap is at revision 4020, nothing else is around
<jdstrand> zyga: saw your comments on PR 4765. I responded and think with just the small tweak you mentioned (though see my comment) that it can land
<mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<mvo> zyga-ubuntu: yeah, but uboot.env has snap_try_core=41..
<mvo> zyga-ubuntu: right? which is very strange
<zyga-ubuntu> jdstrand: thank you, I will look shortly
<zyga-ubuntu> jdstrand: I'm in the same place that mvo debugs
<jdstrand> zyga: well, it sounded like you might want to make another tweak for that redundant-looking rule-- I'll let you decide how to handle that
<zyga-ubuntu> jdstrand: do you think there's something to harden further?
<zyga-ubuntu> (apart from this PR)
<jdstrand> s/rule/line of code/
<zyga-ubuntu> jdstrand: yes, I forgot to change that, I will look at your feedback and push another round
<zyga-ubuntu> mvo: the snap in the cache is core with snapd 2.31.1
<jdstrand> zyga-ubuntu: re more hardening> this is really nice. nothing else would be needed for 2.32 imho. we may want to tweak later, but this is way better than 2.3*1*. really liking this
<zyga-ubuntu> jdstrand: woot, that's great :-)
<zyga-ubuntu> I will go and check the feedback in a moment
<jdstrand> zyga-ubuntu: yes it is. thank you :)
<zyga-ubuntu> mvo: I'm looking at state.json, nothing out of the oridinary yet
<jdstrand> zyga-ubuntu: note I think you missed this comment: https://github.com/snapcore/snapd/pull/4765/files#r171846644 (just a comment addition)
<mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<zyga-ubuntu> mvo: so I see the change where we wanted to do a refresh to 4114
<jdstrand> at least, I didn't see a commit, thumbs up or a comment
<zyga-ubuntu> jdstrand: I saw that, I was wondering how to do that since the comment is from a totally generic piece of code
<jdstrand> (just mentioning it in the interest of time)
<mup> Bug #1752916 opened: Desktop interface should allow accessing to recent files and xdg dirs <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1752916>
<zyga-ubuntu> jdstrand: thank you
<jdstrand> zyga-ubuntu: yeah, I know. that's why I said a code comment would be sufficient instead of contorting to create a policy comment
<pedronis> mborzecki: I'm getting   this  from run-checks recently:   [[: not found   it seems you added that  ... afaict on ubuntu that is run with dash , not bash
<jdstrand> zyga-ubuntu: "// This will generate rules that expected to be in the per-snap mount namespace" or some such
<jdstrand> zyga-ubuntu: your call. I don't mind where the comment is and don't want you to have to add undue complexity
<jdstrand> zyga-ubuntu: maybe wording the policy comment to have 'may' in it works. anyway, think about it, but not too hard :)
<jdstrand> zyga-ubuntu: you know, we lost all specific policy comments such as: https://github.com/snapcore/snapd/pull/4765/files#diff-a34e166c5b3016c122430c5884f41e9bL588. I wonder if it makes sense to have a code comment that coherently summarizes what the template and snippet policy intends to achieve the call it a day.
<mup> PR #4765: interfaces: harden snap-update-ns profile <Created by zyga> <https://github.com/snapcore/snapd/pull/4765>
<jdstrand> zyga-ubuntu: ie, taking all the contextual policy comments that were removed, rewording and smoothing the language in a code comment
<zyga-ubuntu> jdstrand: right
<zyga-ubuntu> jdstrand: do you want to write that? :-) You are much better at wordsmith that intersects with policy
<zyga-ubuntu> mvo: I put this on hold to finish the branch I'm discussing with jamie
<jdstrand> zyga-ubuntu: yeah I can do that
<pedronis> Chipaca: around?
<jdstrand> zyga-ubuntu: I'm going to pivot to steam-support and then circle back a bit later
<zyga-ubuntu> jdstrand: ok, I'll go through your comments and before I push another batch I will check your comments again
<zyga-ubuntu> jdstrand: sounds good, thank you
<zyga-ubuntu> IRC from a phone is interesting
<Chipaca> pedronis: yes
<Chipaca> git st
<Chipaca> why no head tracking
<mvo> zyga-ubuntu: ok
<pedronis> Chipaca: I'm a bit confused  why is not failing more but https://github.com/snapcore/snapd/pull/4743/files added a bashism ([[) to run-checks
<mup> PR #4743: packaging/arch: sync with snapd/snapd-git from AUR <go go go go!> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4743>
<pedronis> Chipaca: bun run-checks is run with dash (at least on default with the usual sh)
<sborovkov> mvo: did you manage to decrypt it?
<Chipaca> pedronis: wow
<pedronis> Chipaca: we should just /sh/bash  in the #! IÂ suppose
<pedronis> unless there was a reason to use dash
<Chipaca> pedronis: no strong reason
<mvo> sborovkov: yes, for some reason it wasn't imported on the system though, maybe a faulty usb-stick. I named it auto-import.assert and put it on the root of the usb-stick, thats enough iirc?
<Chipaca> pedronis: beyond that if bash is not needed, why require it
<Chipaca> pedronis: i'll fix
<sborovkov> mvo: it should be inserted after system starts up
<sborovkov> that's all I think
<pedronis> Chipaca: it's the [[ toward the end:     ./run-checks: 250: ./run-checks: [[: not found
<Chipaca> pedronis: yep yep
<pedronis> it got me staring/puzzled for a bit, even wondering if my disk was corrupted or what
<Chipaca> pedronis: sorry :-(
<mvo> sborovkov: thanks, I try again with a different stick
<mup> PR snapd#4786 opened: run-checks: remove accidental bashism <Created by chipaca> <https://github.com/snapcore/snapd/pull/4786>
<Chipaca> pedronis: ^
<pedronis> Chipaca: also you had a comment about  the line before ?
<pedronis> that IÂ don't if it was addressed
<Chipaca> pedronis: it was
<Chipaca> although... maybe that's a bashism as well
<Chipaca> drat, let me look
<Chipaca> pedronis: not a bashism
<Chipaca> pedronis: all the :- := etc have a :-less version that only checks for unset
<Chipaca> pedronis: âuse of the colon in the format results in a test for a parameter that is unset or null; omission of the colon results in a test for a parameter that is only unset.â
<Chipaca> pedronis: (that's from 'man dash'; bash says something similar; also, shellcheck said it was ok \o/)
<pedronis> Chipaca: it's ok, IÂ still wonder if it's worth the trouble to keep this one as dash
<pedronis> seems we have a mixture
<Chipaca> pedronis: everything spread-ish is bash, everything complete-ish is bash
<pedronis> everything packaging is sh
<pedronis> or so it seems
<Chipaca> pedronis: that's a requirement afaik, but not sure
<pedronis> likely so
<mvo> yeah its a software requirement - packaging should be sh, but we could use bash would just be odd
<mup> PR snapd#4777 closed: i18n: simplify NG usage by doing the modulo math in-package <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4777>
<mborzecki> pedronis: yes, sorry for that, Chipaca thanks for fixing this
<pedronis> mvo: seems something backported one of my tests rename to 2.32 and now release/2.32 is red
<pedronis> mvo:   store/store_test.go:2563: undefined: storeTestSuite
<mup> PR snapcraft#1978 closed: ci: switch to stable lxd and unconfined containers <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1978>
<pedronis> Chipaca: seems to be your change about getStructField
<pedronis> it could not be just cherry-picked
<pedronis> because of renames IÂ did
<mup> PR snapd#4786 closed: run-checks: remove accidental bashism <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4786>
<Chipaca> pedronis: D:
<pedronis> but it was
<pedronis> and now 2.32 is red
<Chipaca> i can fix
<Chipaca> where's 2.32 at
<pedronis> in flux?
<pedronis> Chipaca: release/2.32
<mvo> pedronis: yeah, there is a fix as part of a jamie PR
<Chipaca> ah!
<mvo> pedronis: I noticed this afternoon
<Chipaca> ok
<mvo> https://github.com/snapcore/snapd/pull/4779
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<pedronis> isn't that one undecided?
<pedronis> I think we probably want to fix it alone
<pedronis> unless that one goes in now
<Chipaca> ah, i'd reviewed this one for master
<Chipaca> +1'ing
<mup> PR snapd#4787 opened: strutil: introduce UnsafeString and UnsafeParagraph <Created by chipaca> <https://github.com/snapcore/snapd/pull/4787>
<Chipaca> mvo: pedronis: #4779 gtg
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<mvo> Chipaca: I think so
 * kalikiana wrapping up for the week
 * ikey|busy has literally been wrapping up all week
<ikey|busy> jdstrand, if you're around and before the EOW kicks in , where do we stand on that PR?
<pstolowski> eow.. see you all on the sprint o/
<jdstrand> ikey|busy: I've literally been looking at it for the last hour and a half :)
<ikey|busy> sorry XD
<jdstrand> ikey|busy: no worries. I thought that I could do it yesterday, so I was owed a question on when :)
 * ikey|busy just likes chasing
<ikey|busy> :3
<pedronis> jdstrand: could you merge #4779
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<jdstrand> pedronis: I plan to after the steam-support PR review. I want to check one thing with PR 4779 before I do
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<pedronis> jdstrand:  #4783 is red and needs the fix that mvo piggy-backed on #4779
<mup> PR #4783: ifacestate: be consistent passing Retry.After as named field (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/4783>
<mup> PR #4779:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
<jdstrand> pedronis: almost done with steam-support. I'm coming! :)
<ikey|busy> *cue runaround sue background track*
<jdstrand> ikey|busy: ok, done. I'll be sprinting next week, but it is an engineering sprint so I'll be able to keep an eye on the PR. thanks for the updates!
<ikey|busy> i see no existing open questions
<jdstrand> ikey|busy: go here: https://github.com/snapcore/snapd/pull/4538#pullrequestreview-100828987
<mup> PR #4538: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
<ikey|busy> also that concat didnt work for me
<ikey|busy> go cried
<ikey|busy> thats why it is like it is now
<ikey|busy> btw we *removed* the allow-installation line already cuz that was what was breaking core...
<jdstrand> ikey|busy: I think we can make that work somehow. just comment that you tried, it didn't work, then we can look at it
<ikey|busy> https://github.com/snapcore/snapd/pull/4538/commits/6006da7a5d78f878c95dfbb48800a2a99c8e6f27
<mup> PR #4538: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/4538>
<ikey|busy> (also, 4.15 kernel :P)
<jdstrand> ikey|busy: your allow-installation was different than mine
<ikey|busy> ok - but just as a headsup half of this stuff isnt documented at all - or very poorly
<ikey|busy> so a lot of this is copy  paste
<ikey|busy> and capability sys_ptrace *is* needed, thats why i aded it
<ikey|busy> it used to kill the processes before :)
<ikey|busy> ill fix up the rest of it and see whatcha think of it next week
<ikey|busy> also please note you've reopened some old comments that aren't valid
<jdstrand> ikey|busy: can you test without it? not having the 'ptrace' syscall kills. lack of 'capability sys_ptrace,' in apparmor would not kill
<ikey|busy> like [0-9] stuff
<ikey|busy> we tried that stuff already months ago
<ikey|busy> apparmor imitates fnmatch
<ikey|busy> isn't quite there
<ikey|busy> and i *added* the capability because it crashed before
<ikey|busy> this is questions 3+ months after the bug
<jdstrand> I don't know what happened months ago or how the rules were added in which order
<jdstrand> as in, you probably had a seccomp kill, so you added ptrace syscall
<ikey|busy> ya
<ikey|busy> wasnt apparmor doing the murdering
<ikey|busy> and that was pre-yama too
<ikey|busy> so nothing has happened to make that any looser
<ikey|busy> also the notion that this snap is only being used on solus is flawed
<ikey|busy> no point in making the snap if its solus specific
<jdstrand> please feel free to respond to my comments in the PR so everyone can benefit
<jdstrand> the comment about solus specific was *today* it is
<jdstrand> and *today* this is where this is being tested
<ikey|busy> no it isnt - its being tested on ubuntu and arch
<ikey|busy> and *Developed* on solus
<jdstrand> *tomorrow* we need to add the 4.8 kernel stuff and likely things to make this work on ubuntu
<ikey|busy> i dont know where these assertions are coming from
<jdstrand> ikey|busy: I'm basing this on what I thought I remembered from our conversations
<jdstrand> ikey|busy: if it is wrong, correct me in the PR
 * mvo loves that he can just do "snap watch 4" and see how the auto-refresh is doing
<ikey|busy> jdstrand, you'll forgive me if i seem a bit frustrated in repeating myself since before december.
<jdstrand> ikey|busy: but I'm trying to unblock this interface for you
<jdstrand> ikey|busy: I'm sorry, there is a tremendous amount of context for this PR. I'm doing the best I can
<ikey|busy> ill make the /necessary/ edits over the weekend as im assuming you'll not be around before the weekstart
<ikey|busy> (like normal hoomans)
<ikey|busy> is hardware-observe something autoconnectable?
<ikey|busy> (with forum request ofc.)
<jdstrand> ikey|busy: please correct my statement that this is intended to work on ubuntu right away, cause we may need to do something about 4.8 right away
<jdstrand> ubuntu/arch/whatever
<ikey|busy> jdstrand, well its "universal" applications, right?
<jdstrand> I think ubuntu is the only one with affected kernels though
<jdstrand> ikey|busy: of course. but trying to do things in steps
<ikey|busy> we can keep initial scope to 4.9+
<ikey|busy> and maybe add a uname check in LSI itself
<ikey|busy> throwing a big warning for pre 4.9 usage
<jdstrand> ikey|busy: if it happened to be true that this was tested on solus and not on ubuntu, then I would still allow the PR to land
<jdstrand> ikey|busy: and others interested in ubuntu could improve the interface for it
<jdstrand> ikey|busy: you're saying that isn't the case (I thought it was), so correct me in the PR
<ikey|busy> im saying we target all snap enabled distros and primary development happens on solus
<jdstrand> ikey|busy: don't add 4.9 stuff to the PR yet. niemeyer has thoughts and I have an open question to him
<ikey|busy> not the PR
<jdstrand> ikey|busy: I know what your saying
<ikey|busy> to LSI
<jdstrand> if you do that in LSI, that's fine, but a potentially bad experience for users
<jdstrand> the right place is in snapd
<ikey|busy> occurs to me life would be far simpler had feral not used ptrace
<jdstrand> ikey|busy: what your saying wasn't what I thought was the case when I wrote the comment. so, again, please correct me in the PR so the others looking at the PR have the correct context
<ikey|busy> assuming i send you fixed on Monday for the PR, likelihood of merge next week?
<jdstrand> ikey|busy: don't get hung up on the 4.9 stuff. I don't think it should block the PR
<ikey|busy> obviously testing is limited to anyone who then has snapd with steam-support interface
<ikey|busy> in terms of scope limitations
<mvo> idle though: when the system is seeding it would be nice if "snap list" would show a better message than: "no snaps installed yet"
<mvo> seeding is really slow on arm
<jdstrand> ikey|busy: I expect light iteration after the fixes on monday. I don't see why it couldn't be approved next week
 * mvo notices that `snap changes` while seeding takes a long time, like a minute or so without any user visible feedback
<ikey|busy> general difference between approved vs merged?
<jdstrand> ikey|busy: another option with 4.9 is that since I think Ubuntu is the only kernel that is affected, we patch our kernels
 * mvo thinks we need to improve the UX on slow hardware
<ikey|busy> jdstrand, backporting the ptrace changes..?
<jdstrand> yes
<jdstrand> it is just an ordering problem
<ikey|busy> sure
<jdstrand> small fix
<ikey|busy> but time and goals and sequence
<jdstrand> difference between approved and merged is that it will need 2 people to approve to merge. I can say I can approve. I would think zyga would be able to, but I'm not his boss, so..
<jdstrand> it should be able to be merged
<ikey|busy> sure
<ikey|busy> just wanting to understand the processing is all
<jdstrand> I'm not the project lead, so I can't commit to merged :)
<ikey|busy> mainly so i can sorta juggle my own time for next week too
<ikey|busy> i sorta have a distro to run at the same time :P
<jdstrand> ikey|busy: now that we have the agreed upon approach, things can move fast. you did the PR, I did the big initial review. we can iterate fast
<ikey|busy> much appreciated, ill take a spork to it over the weekend and make sure any remaining items are ticked off
<jdstrand> I will try to be responsive to the PR to keep it moving
<jdstrand> yes, and please correct me if I mispoke
<jdstrand> (in the pr)
<ikey|busy> ya it can wait til monday, just figured id ask those bits while you were still reachable
<jdstrand> ikey|busy: I'll try to be on irc next week. it is just tricky at a sprint. but like I said, it is an *engineering* sprint, so I will have time to respond
<jdstrand> and review
<ikey|busy> yeah no worries ill just look out for the pings on github
<jdstrand> perfect
<ikey|busy> as long as i roughly know what direction things are moving in and what timescale,then i can adjust to it
<ikey|busy> all comes down to communication :P
<ikey|busy> then im fine
<jdstrand> ikey|busy: they are moving in a positive direction quickly now :)
<ikey|busy> aye, once its merged then its just add "missing" bits
<jdstrand> and yes, we'll keep discussing int he PR
<ikey|busy> like improving joystick
<jdstrand> ikey|busy: ok, so it sounds like joystck will be a different pr (fine)
<ikey|busy> yeah i need the groundwork in first
<jdstrand> the other 'move these 5 rules to interface foo' don't have to be separate
<jdstrand> oh right
<ikey|busy> need folk to be able to test the snap before we can extend it :D
<ikey|busy> and devmode cripples it
<jdstrand> I meant to say, anything that isn't autoconnected that needs to be, we'll auto-conect via snap declaration
<ikey|busy> ah yeah
<jdstrand> so, hardware-observe, joystick, etc
<ikey|busy> joystick, hardwa...
<ikey|busy> :D
<ikey|busy> alright if theres nothing else i gotta go walk through a blizzard
 * ikey|busy wishes he was joking
<jdstrand> and since I've been involved in all of this, I will be a strong advocate in that process (meaning, there shouldn't be any issues)
<jdstrand> ikey|busy: stay warm!
<ikey|busy> cheers, and yourself if you're also being attacked by porchbournesnowballs
<jdstrand> ikey|busy: nope, I'm in Texas. weird, annoying weather lately, but no snow
<jdstrand> pedronis: merged!
<mup> PR snapd#4779 closed:  interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd (LP: #1729867) - 2.32 <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/4779>
 * mvo grumbles about "cannot finish core install, there was a rollback accross reboot" vs "... (%d != %d)", snapInfo.Revision, rev) so that debugging give some more clues
<pedronis> mvo: don't we have some of that info in the traces
<mvo> pedronis: this is what I have https://paste.ubuntu.com/p/CgTM2cZvpm/
<mvo> pedronis: I need to look if debug will help
 * mvo tries that
<pedronis> mvo: I see we know what we are installing 4114
<pedronis> but don't see the previous rev
<pedronis> or if there's a rev at all
<pedronis> mvo: that code should also mark the revision as blocked (though we need to extend the way we track that)
<pedronis> because normal revert assumes the revision stays around, which is not the case here
<pedronis> we remove it again
<mvo> pedronis: yeah
<mvo> pedronis: maybe I can find out things from looking at the state and snapsetup
<pedronis> mvo: well what that code is looking at really
<pedronis> is the boot env vars
<mvo> pedronis: yeah, a debug trace of those would be great
<mvo> pedronis: or when we update the core_snap env
<pedronis>  CurrentBootNameAndRevision
<mvo> https://paste.ubuntu.com/p/ChcW6xKhpr/ <- looks good before the reboot
<mvo> pedronis: yeah
<pedronis> anyway in my open PR
<pedronis> that code is factored better in a helper
<mvo> pedronis: oh, nice
<pedronis> right now it hangs oddly in ifacestate
<pedronis> https://github.com/snapcore/snapd/pull/4497
<mup> PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<mvo> pedronis: ok, this gets stranger and stranger, it claims the rev is wrong, however: # snap version
<mvo> snap    2.31.1
<mvo> snapd   2.31.1
<mvo> pedronis: so it looks like the uboot update is too late maybe
<pedronis> mvo: dit it actually reboots btw?
<pedronis> is not that snapd restarts?
<mvo> pedronis: yes, it did reboot
<chachasmooth> `snap refresh` (without providing a snap name) always returns "All snaps are up to date"
<chachasmooth> even if some snaps have upgrades available
<chachasmooth> seems like a bug to me?
<nacc> chachasmooth: --^ is on debian fyi
<nacc> (may help know if it's an already fixed thing upstream, etc)
<chachasmooth> snapd                         2.21-2+b1                    amd64
<zyga-ubuntu> re
 * zyga-ubuntu was preparing for the trip
<Chipaca> mvo: it wasn't the mounts, then?
<mup> PR snapd#4783 closed: ifacestate: be consistent passing Retry.After as named field (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4783>
<mvo> Chipaca: I think not
<mvo> (he said and vanished in a puff of logic)
<mvo> (sorry, silly descartes joke)
<mvo> Chipaca: I think I'm close to figuring it out
<zyga-ubuntu> mvo: hey, how are things?
<mvo> zyga-ubuntu: good, I think I'm close
<zyga-ubuntu> chachasmooth:  you are on debian and you have 2.21-2+b1? is that what snap version says as well or just dpkg
<zyga-ubuntu> mvo: want me to be your garden troll?
<zyga-ubuntu> (so you tell me what the bug is and that's how you get the last bit)
<chachasmooth> zyga-ubuntu ^ was the output of dpkg
<zyga-ubuntu> chachasmooth: in debian stable that is expected
<chachasmooth> well, it's still misbehaving
<chachasmooth> it shouldn't say "snaps are up to date" when they are not
<zyga-ubuntu> chachasmooth: so that's interesting, how do you determine that there are snaps that are out of date?
<zyga-ubuntu> chachasmooth: and what does "snap changes" say
<chachasmooth> after running snap refresh lxd the snap upgraded
<chachasmooth> ^ zyga-ubuntu
<zyga-ubuntu> can you paste "snap changes"
<zyga-ubuntu> and snap version, please
<chachasmooth> 23   Done    2018-03-02T19:20:39Z  2018-03-02T19:20:39Z  Refresh all snaps: no updates
<chachasmooth> that's the only line returned
<chachasmooth> snap --version
<chachasmooth> snap    2.31.1
<chachasmooth> snapd   2.31.1
<chachasmooth> series  16
<chachasmooth> debian  9
<chachasmooth> kernel  4.9.0-6-amd64
<zyga-ubuntu> this looks fine, hmm
<zyga-ubuntu> and when you "snap refresh lxd", which revision did you get?
<chachasmooth> I don't remember, the most recent one
<chachasmooth> it's been a week or so since
<chachasmooth> haven't upgraded lxd in a few months
<zyga-ubuntu> chachasmooth: can you open a forum topic about this, I just don't want it to get lost
<chachasmooth> where?
<zyga-ubuntu> lxd would refresh by itself
<zyga-ubuntu> on forum.snapcraft.io
<chachasmooth> ok, might take a few days though
<zyga-ubuntu> next week will be very busy but we'll try to look at it
<zyga-ubuntu> no worries, thank you for reporting this
<zyga-ubuntu> I'm worried that snap changes doesn't show the LXD refresh
<zyga-ubuntu> maybe it already got garbage collected
<zyga-ubuntu> (the change, that is)
<chachasmooth> I did a reboot since fyi
<zyga-ubuntu> succesful changes are discarded relatively quickly but I forgot how often that is
<chachasmooth> it should be rather easy to check what a plain `snap refresh` does
<zyga-ubuntu> yes, I know what it does
<chachasmooth> what does it do?
<zyga-ubuntu> I'm wondering how this could happen
<zyga-ubuntu> it mainly asks the store if there's a refresh for any of the snaps that are installed,
<chachasmooth> it should get a list of all snaps installed and execute `snap refresh $SNAP` for each
<zyga-ubuntu> it has some logic to not refresh snaps that have changes in progress
<chachasmooth> what does "in progress" mean?
<zyga-ubuntu> it's doing that but has some logic to not be too silly if a refresh is in progress
<zyga-ubuntu> well
<zyga-ubuntu> many things
<zyga-ubuntu> if you are refreshing a snap
<zyga-ubuntu> and it's pullling updates
<zyga-ubuntu> then you run a refresh in another terminal
<zyga-ubuntu> it will not refresh that snap
<chachasmooth> it was not doing that
<zyga-ubuntu> that's a kind of change
<zyga-ubuntu> there are all kinds of other changes as well
<zyga-ubuntu> but it's unlikely those were running at the time
<zyga-ubuntu> one last obvious thing is that when you ran "snap refresh" lxd was about to be published
<zyga-ubuntu> and then a moment later it was published and you managed to refresh it manually
<chachasmooth> no, stgraber did the release a few weeks earlier
<zyga-ubuntu> another possibility is a store bug
<chachasmooth> well, but `snap refresh lxd` worked, so how could this be a store bug?
<zyga-ubuntu> because the query is different
<zyga-ubuntu> not sure
<zyga-ubuntu> the person that's the expert on this is probably EOD'd
<zyga-ubuntu> Chipaca: ^
<chachasmooth> is there a way to reproduce by installing some outdated snap which has a newer stable release to which I can upgrade?
<zyga-ubuntu> yes but you have to be the developer of a given snap to install an older revision
<zyga-ubuntu> I'll talk to chipaca next week, he knows that code much better than I do
<mup> PR snapcraft#1976 closed: elf: only consider regular files as possible ELF binaries <bug> <Created by jhenstridge> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1976>
<mup> PR snapd#4784 closed: asserts:  use a timestamp for the assertion after the signing key has been created (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4784>
<mvo> zyga-ubuntu: I replied in the forum, the reason is that we have two uboot.env files, UBOOT.env and uboot.env and uboot sets one of them to `snap_mode=trying` but snapd reads the other one with `snap_mode=try`
<zyga-ubuntu> mvo: wow
 * zyga-ubuntu goes to read the forum
<zyga-ubuntu> mvo: there's a mount flag to control file names like that
<mvo> zyga-ubuntu: i tried them and could not find one
<zyga-ubuntu> looking
<zyga-ubuntu> ah, one more sec
<mvo> zyga-ubuntu: its also very unclear why this started to happening suddenly
<zyga-ubuntu> it's not a mount option, it's a switch in proc somewhere (or sys)
<zyga-ubuntu> yeah
<mvo> zyga-ubuntu: ohhhh
<zyga-ubuntu> maybe a new gadget?
<zyga-ubuntu> new uboot?
<zyga-ubuntu> or just bad luck
<mvo> zyga-ubuntu: they have their own, but its the same uboot afaict
<zyga-ubuntu> btw, how did you get to the point where the files differed?
<zyga-ubuntu> they did not differ in the corrupted image
<mvo> zyga-ubuntu: after the refresh they started to differ I think the difference is subtle, try vs trying
<zyga-ubuntu> I see
<mvo> but it seems like it is the unix side that mis-behaves, it starts writing lower case
<zyga-ubuntu> found it
<zyga-ubuntu> mvo: shortname=lower|win95|winnt|mixed
<zyga-ubuntu> default is mixed
<zyga-ubuntu> https://www.kernel.org/doc/Documentation/filesystems/vfat.txt
<zyga-ubuntu> we could try shortname=lower
<mvo> zyga-ubuntu: when I played with that I couldn't see a difference
<zyga-ubuntu> and see if that changes how the file is opened
<zyga-ubuntu> or we could mount it as msdos (not vfat)
<mvo> zyga-ubuntu: oh, I think I did not try that, I tried the iocharset ones
<mvo> zyga-ubuntu: thats a nice idea
<zyga-ubuntu> msdos doesn't support long file names
 * zyga-ubuntu tries with mount -t msdos
<zyga-ubuntu> 2018 and we are fighting bootloaders and msdos filenames
<mvo> zyga-ubuntu: yeah, please update the forum if you find anything, I need some sleep
<zyga-ubuntu> I will
<mvo> zyga-ubuntu: it might also be that their usage fiddles with mount options somehow
<mvo> zyga-ubuntu: what is also interessting is why eventually things get corrupted and stop booting but my gut feeling is that its all related
<mvo> anyway, I need to get some rest
 * mvo waves
<mup> PR snapcraft#1979 opened: pluginhandler: simplify logic when elf patching is required <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1979>
<mup> PR snapcraft#1980 opened: elf: remove all un-primed libs from soname cache <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1980>
#snappy 2018-03-03
<mup> PR snapcraft#1981 opened: tests: remove the internal os_release dependency <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1981>
<mup> PR snapcraft#1967 closed: project_loader: improve the logic to install patchelf as a build tool <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1967>
<mup> PR snapcraft#1980 closed: elf: remove all un-primed libs from soname cache <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1980>
<mup> Issue snapcraft#1973 closed: Support quering package manager in tests <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1973>
<mup> PR snapcraft#1971 closed: tests: remove dependency of internal repo from integration suite <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1971>
<mup> Issue snapcraft#1952 closed: add support for in test release information <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1952>
<mup> Issue snapcraft#1982 opened: Update snaps_tests to use the testing tools from tests.integration <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1982>
<mup> PR snapcraft#1981 closed: tests: remove the internal os_release dependency <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1981>
<mup> Issue snapcraft#1714 closed: catkin plugin: recursively merge rosinstall files <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1714>
<mup> PR snapcraft#1934 closed: catkin plugin: support recursive rosinstall files <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1934>
<mup> Issue snapcraft#1953 closed: Add in test architecture <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1953>
<guiverc> a user on #ubuntu claims a snap is "deceptive" in its description on snap store.. does anyone know where this/they should go to report, elevate etc?
<Chipaca> guiverc: deceptive how?
<Chipaca> guiverc: forum might be a good place
<Chipaca> guiverc: (a lot of the team is already en route to budapest)
<guiverc> Chipaca, thanks - I've reported via https://forum.snapcraft.io/t/snap-package-in-store-seems-deceiving/4320 for user ...
<guiverc> and thanks I didn't know about Budapest ...
<Chipaca> guiverc: I don't understand the deception
<guiverc> i don't so couldn't explain... i was using words of reporter
<Chipaca> guiverc: you mind if I edit your post a little for readability?
<guiverc> not at all.
<guiverc> the user has left #ubuntu sorry.
<Chipaca> guiverc: if you could edit to include what yolozulu is responding to (in particular where they say "right on")
<Chipaca> that'd help understand also
<guiverc> added (i didn't think important; why I left it out; yeah the right-on was confusing sorry)
<Chipaca> guiverc: is the deception that it isn't there for GUI but is from the terminal?
<guiverc> i have no idea.. i was just in #ubuntu and tried to respond to to user...
<Chipaca> guiverc: ah well. If you see them again, ask them to explain a little more
<guiverc> i will, I'll give them a link to the forum so they can do it themselves (instead of via 3rd party)
<guiverc> thank you for your help Chipaca, appreciated.
<Chipaca> guiverc: thanks
<Chipaca> if it's just that it isn't there on gui, that might be a bug (or a series of bugs)
<guiverc> (i was trying to find where to pass on to, they'd left before I found somewhere appropriate, ie. forum)
<Chipaca> guiverc: it's fine, here's hoping the appear again
<popey> interestingly, that snap they're talking about does indeed not show up in gnome software here
#snappy 2018-03-04
<mup> PR snapd#4787 closed: strutil: introduce UnsafeString and UnsafeParagraph <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4787>
#snappy 2019-02-25
<mup> PR snapcraft#2485 opened: project loader: remove special LD_LIBRARY_FLAGS handling for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2485>
<mborzecki> morning
<mup> PR snapd#6535 opened: tests: remove snapweb from tests (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6535>
<mup> PR snapd#6504 closed: tests: not checking 'tracking channel' after refresh core on nested execution <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6504>
<mup> PR snapd#6313 closed: tests: add a tests for xdg-desktop-portal integration <Created by jhenstridge> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6313>
<mup> PR snapd#6535 closed: tests: remove snapweb from tests (2.37) <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6535>
<mup> PR snapd#6488 closed: interfaces/network-manager: no peer label check for hostname1 <Created by alfonsosanchezbeato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6488>
<mborzecki> back in an hour or so
<mup> PR snapcraft#2481 closed: meta: handle symlinked hooks (#2478) <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2481>
<sergiusens> mborzecki: so quiet ð
<zyga> hey ho
<zyga> just popping in briefly
<zyga> ah, mvo is off the whole week :)
<zyga> I meant to ask him something
<mborzecki> re
<mborzecki> sergiusens: yeah, apparently it's just me today
<sergiusens> well, I enjoy it being a bit more quiet, so all for the better
<mup> PR snapd#6533 closed: interfaces/seccomp: increase filter precision <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6533>
<mup> PR snapd#6536 opened: interfaces/seccomp: increase filter precision <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6536>
<mup> PR snapd#6537 opened: tests: fix upgrade-from-2.15 with kernel 4.15 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6537>
<mborzecki> zyga: ^^ so this should unbreak 2.37
<zyga> Perhaps
<zyga> Lets see
<mup> PR snapcraft#2485 closed: project loader: remove special LD_LIBRARY_FLAGS handling for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2485>
<mup> PR snapcraft#2464 closed: project_loader: use hardened flags by default <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2464>
<mup> PR snapd#6536 closed: interfaces/seccomp: increase filter precision (2.37) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6536>
<popey> My spidey sense is tingling. https://forum.snapcraft.io/t/hi-guys-im-new-here-have-some-questions/10143
<mup> PR snapcraft#2475 closed: sources: avoid marking changes to the snap directory as dirty <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2475>
 * diddledan tingles popey 's spiders
<mup> PR snapd#6537 closed: tests: fix upgrade-from-2.15 with kernel 4.15 (2.37) <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6537>
<mup> PR snapd#6526 closed: tests: run tests on opensuse leap 15.0 instead of 42.3 <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6526>
<mup> PR snapd#6531 closed: cmd/snap: fix error messages for snapshots commands if ID is not uint <Created by stolowski> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6531>
<Katnip> how do i check to update in a term?
<Gargoyle> Katnip: sudo snap refresh
<Katnip> oh ty :)
<mup> PR snapcraft#2486 opened: colcon plugin: support build-time chaining <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2486>
#snappy 2019-02-26
<mborzecki> morning
<mborzecki> google:ubuntu-18.04-64:tests/main/desktop-portal-open-file seems broken
<zyga> Hey
<zyga> I will be around shortly
<mborzecki> zyga: hey
<mup> PR snapd#6538 opened: tests/main/desktop-portal-*: try to collect some debug output in the tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6538>
<mborzecki> hm in both test runs that failed, document portal test was executed before the desktop portal one
<zyga> back now
<zyga> kids sorted out, dressed, fed, combed, sent off to school, kitchen cleaned, dog handled - all good, let's work :)
<zyga> mborzecki: I haven't looked at the tests yet but perhaps they leak processes that make things fail
<zyga> all the portals need to be killed / unmounted across testing sessions
<mborzecki> zyga: yeah, that's my guess
<mborzecki> tweaked spread priorities to make it run the document portal test before desktop ones :/
<zyga> uh
<zyga> sucks
<mborzecki> anyways, i need coffee
<pstolowski> hey o/
<zyga> hey pawel
<pstolowski> zyga: i frogot to give you back your serial adapter; i can send it
<zyga> oh
<zyga> no worries :)
<zyga> keep it
<zyga> I have more at home
<pstolowski> zyga: ok, next time
<zyga> and they are 3euro each so no point in sending it anywhere :)
<pstolowski> :)
<mborzecki> pstolowski: hey
<mborzecki> aand reproduced
<zyga> mborzecki: what is it?
<mborzecki> idk yet, just got the same backtrace as on travis
<mborzecki> so running document-portal activation before the test made it fail
<zyga> mborzecki: mount
<zyga> mborzecki: ps aux
<mborzecki> hmm https://paste.ubuntu.com/p/2CJ63xWDG4/
<zyga> that's expected!
<zyga> unmount / kill them
<mborzecki> hm xdg destkop portal is not starting for some reason
<zyga> how are you starting it?
<zyga> btw: the more I see this the more I'm inclined to require tests to clean up by themselves
<zyga> we are wasting lots of time on prepare/restore
<zyga> and it's not working
<mborzecki> hahah https://paste.ubuntu.com/p/cpNrbBkBH7/
<zyga> woah :D
<zyga> how did we miss that :)
<mborzecki> test execution order probably
<mborzecki> soemthing cleaned up too much or not enough
<mborzecki> yup, apt install python3-dbus and it worked :P
<mborzecki> zyga: heh https://paste.ubuntu.com/p/hfhSxpF7tT/ document portal activation is a bit eager with the cleanup
<zyga> yeah
<zyga> good catch
<zyga> I wish we had tagging in spread
<zyga> we could tag a test as "dirty" or "clean"
<zyga> and work our way through the maze
<mborzecki> hm idk, i'd like to run the test on a snapshot of the rootfs, something like systemd-nspawn does, or a subvolume you can discard afterwards
<zyga> mborzecki: I would use that only to detect violations
<zyga> we still need to run them in contexts where we cannot afford such luxury
<zyga> but I strongly agree on a need for automatic verification
<zyga> we leak processes, mount points, random files, cache, temp files, package changes, kernel settings
<mborzecki> i suppose i'll leave the extra debug info in the tests
<zyga> https://9to5mac.com/2019/02/25/bbedit-12-6-sandboxing-mac-app-store/
<zyga> this is curious, it's an IDE / developer editor that runs sandboxed on macos sandbox and will now be distributed by the app store
<zyga> I wonder what the usability is like
<zyga> pstolowski: can we detect gpio's via hotplug?
<mborzecki> pushed a patch, #6538 should fix master once it lands
<mup> PR #6538: tests/main/desktop-portal-*: try to collect some debug output in the tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6538>
<zyga> thanks, looking
<zyga> mborzecki: I was thinking if the debug section should run without "set -e"
<zyga> we have to resort to silly || true or risk more failure
<mborzecki> pstolowski: is #5962 the last of the hotplug series?
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<zyga> I'll take one more stab at https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<pstolowski> mborzecki: yes (as far as feature is concerned; there is a spread test+serial port interface in a followup)
<mborzecki> pstolowski: great :) i'll take a look at the PR now
<pstolowski> mborzecki: ty!
<marlinc> Hey there, is there a way to make a 'team account'? I'm building some snaps for my company but having them be published using my name isn't very nice
<pstolowski> zyga: good question, i'm not sure and familiar with gpio; fwtw this is what i see with udevadm info -e on rpi3 (not complete, just a snippet): https://pastebin.ubuntu.com/p/pqvFJkQyvx/
<pstolowski> *not familiar*
<pstolowski> this is what the interface can get & process as part of hotplug
<mborzecki> need to go out for a while
<mup> PR snapd#6539 opened: cmd, daemon: split out the common bits of mapLocal and mapRemote <Created by chipaca> <https://github.com/snapcore/snapd/pull/6539>
<Chipaca> moin moin
<Chipaca> ^ PR from the fun flight home
<zyga> pstolowski: hmm, that's new to me as well
<zyga> Chipaca: hey :)
<Chipaca> zyga: 'sup
<zyga> pstolowski: are any of the values pointing to a /dev/XXX entry (perhaps via a symlink)
<zyga> Chipaca: settling back in the office, all is good, yourself?
<zyga> https://www.monkeyuser.com/2019/pivoting/ (no association to snapd, just funny)
<Chipaca> zyga: going through reviews :-)
<pstolowski> zyga: the only one i can find in udevadm output is referencing /dev/gpiomem, but that doesn't seem relevant for the gpio interface we have atm
<zyga> yeah
<zyga> gpio via memory mapped registers
<zyga> oh well
<mup> PR snapd#6529 closed: daemon, client, cmd/snap: snap debug base-declaration <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6529>
<pedronis> Chipaca: hi, it's a bit strange that a GET gets an "action" there ^
<Chipaca> pedronis: hi!
<Chipaca> oh dear :-/
<pedronis> Chipaca: I mean I understand where it's coming from, but is not the most appropriate term for something that should be idempotent
<pedronis> sorry
<pedronis> without effects (actually)
<Chipaca> pedronis: would select= have been better?
<Chipaca> dunno, we don't have another one of these really
<pedronis> Chipaca: select would be better, we use it already in other queries, no?  a cutesy one could be "aspect"
<pedronis> debug which aspect (but as I said a bit too cute)
<pedronis> maybe
<Chipaca> pedronis: yes, we use select=all and =enabled (for list), select=refresh or =private (for find), all and connected on interfaces, all, in-progress and ready on changes, â¦
<Chipaca> select is always a filter tho
<Chipaca> (bah, refresh is weird0
<pedronis> Chipaca: your pick, it's debug after all, I'm happy with either "select" or "aspect"
<Chipaca> I like aspect, but i like the consistency of select
<Chipaca> hm
<mup> PR snapd#6540 opened: daemon, client, cmd/snap: debug GETs have actions, not aspects <Created by chipaca> <https://github.com/snapcore/snapd/pull/6540>
<Chipaca> wait I got that backwards
 * Chipaca groans
<pedronis> Chipaca: changed
<Chipaca> snap_mode=try means it hasn't rebooted after changing core/kernel/gadget, right?
<zyga> Chipaca: I think so
<zyga> Chipaca: bootloader changes that to trying
<zyga> Chipaca: so snapd knows what's going on
<Chipaca> so maybe that's the bit that's broken
<zyga> what are you seeing? sorry, I'm deep in another topic and just responded because I saw the question
<Chipaca> zyga: stay there :-)
<Chipaca> zyga: i'm just talking to myself
<zyga> tea helps :)
<zyga> I'm drinking some now, it's not as warm as it was in the south
<Chipaca> pedronis: on snapd stat, if snap_mode==try, we should set the restarting flag
<Chipaca> start*
<Chipaca> this'll probably break some of our tests
<Chipaca> also, our minds
<Chipaca> Â¯\_(ã)_/Â¯
 * Chipaca tries a reproducer
<pedronis> Chipaca: ?
<pedronis> Chipaca: I wouldn't solve the problem that way
<Chipaca> pedronis: ok
<pedronis> Chipaca: too much conceptual change
<pedronis> Chipaca: boot ids seems still a bit more of a solid bit of info than our flags
<pedronis> Chipaca: let's have a chat later
<greyback> hey all, I've got 2 approvals on this PR, can it land? https://github.com/snapcore/snapd/pull/6525
<mup> PR #6525: interfaces/wayland: allow wayland server snaps function on classic too <Created by gerboland> <https://github.com/snapcore/snapd/pull/6525>
<pedronis> greyback: yes
<Chipaca> pedronis: should I just merge it
<pedronis> Chipaca: yes
<Chipaca> boom
<mup> PR snapd#6525 closed: interfaces/wayland: allow wayland server snaps function on classic too <Created by gerboland> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6525>
<greyback> thanks guys
<pedronis> greyback: notice that it's ok because of jdstrand review, typically anything in interfaces/builtin needs that
<pedronis> not just 2 reviews
<greyback> pedronis: understood.
<pstolowski> zyga: i'm trying to understand the core-support plug/slot wrt to you comment in the migration-fix PR, checked some very old releases (2.14-2.16); it actually seems to be introduced for the "core" snap, not "ubuntu-core"?
<zyga> pstolowski: oh? perhaps I was mistaken, if it was never present on ubuntu-core, does that simplify the bugfix?
<pstolowski> zyga: most likely yes; we probably don't need to do anything special with it on undo (core back to ubuntu-core) since core-support is obsolete so will not appear on current core if we fail on transition and need to go back to u-c
<pstolowski> pedronis: ^ do you think this makes sense? do you remember when did we introduce core-support?
<mborzeck1> re
<mup> PR snapcraft#2486 closed: colcon plugin: support build-time chaining <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2486>
<zyga> mborzecki: how are you feeling?
<pedronis> pstolowski: ok, we need to chat about that PR in general
 * pedronis finishing my lunch break
<pstolowski> pedronis ok; btw core-support was added in 2.22
<pedronis> pstolowski: it doesn't seem like ubuntu-core used it, it didn't in its last table release
<pedronis> and at that time core was
<zyga> Lunch time
<pstolowski> pedronis: yes, let's talk in the standup
<mborzecki> wth just happend with freenode?
<pstolowski> mborzecki: hmm looks fine here
 * pstolowski lunch
<pedronis> pstolowski: zyga: I'm confused by the preexisting comment in that PR, wouldn't core and ubuntu-core profiles have different disk names?
<cachio> niemeyer, hey, could you please add permission for
<cachio> ERROR: (gcloud.compute.disks.snapshot) HTTPError 403: Required 'compute.zoneOperations.get' permission for 'projects/computeengine/zones/us-east1-b/operations/operation-1551185626188-582cb8c3acb08-df0e03b2-6722caa8'
<Facu> may you help me to run the tests in snapcraft? I've installed all the system dependencies as README indicates, then created the venv, and installed all there as indicated, but when I run the tests I get a RuntimeError: Snapcraft requires PyYAML to be built with libyaml bindings
<zyga> pedronis: let me look at the PR
<zyga> Facu: perhaps your venv didn't built pyyaml because you were lacking C headers for the C shared library it depends on?
<zyga> pedronis: which comment are you referring to?
<zyga> is it https://github.com/snapcore/snapd/pull/6530#discussion_r259345905 ?
<mup> PR #6530: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6530>
<Facu> zyga, there's no complain at all in the install process: http://linkode.org/#NLIK5LANIbGcPu11FZcKy4
<zyga> Facu: I don't know, just a guess
<pedronis> zyga: I'm probably just confused
<zyga> pedronis: I added the comment because I read this part
<zyga> https://github.com/snapcore/snapd/pull/6530/files#diff-b88a3954d898e0a8ab681d98f1407a0fR344
<mup> PR #6530: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6530>
<zyga> but after discussing with pawel I think there is no way that we can have plugs on ubuntu-core / core there
<zyga> still, that was my reasoning at the time I added the comment
<pedronis> zyga: I forgot that profiles are generally per app/hook, and ubuntu-core had none afawu
<zyga> pedronis: there was the "core-support" plug on the configuration hook but I forgot if it was present in ubuntu-core
<mborzecki> pstolowski: will hotplug land for .38?
<mborzecki> anyone wants to do a 2nd review of #6538?
<mup> PR #6538: tests/main/desktop-portal-*: try to collect some debug output in the tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6538>
<cachio> jamesh, hi
<pstolowski> mborzecki: i think so, the plan was to land it by malta sprint. i need to check if mvo wants to take a look, then i can merge. thanks for re-review btw!
<mborzecki> aand it's green
<Chipaca> pedronis: https://forum.snapcraft.io/t/how-get-snap-set-property-list-snapd-api-extension/10155
<pedronis> zyga: do you remember from what repo ubuntu-core was built?
<zyga> pedronis: the snap?
<zyga> let me look
<zyga> https://launchpad.net/~snappy-dev/+snap/ubuntu-core
<zyga> apparently this one https://code.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk
<pedronis> zyga: never had hooks
<pedronis> Chipaca: is that post formatting broken? it seems cut up
<Chipaca> pedronis: not as much broken as nonexistent
<pedronis> I cannot parse bits of it
<mup> PR snapd#6538 closed: tests/main/desktop-portal-*: fix handling of python dependencies <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6538>
<pedronis> Chipaca: pstolowski: standup?
<Chipaca> yeah was fighting the setup
<diddledan> I added architecture tracking: https://snapstats.org/architectures
<pedronis> Chipaca: I asked the poster the review the formatting
<mup> PR snapcraft#2469 closed: cli: clean up snapcraft push output <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2469>
<zyga> Pharaoh_Atem: hey
<zyga> around?
<Chipaca> pedronis: seems like that forum topic is about config validation -- which we make impossible by not allowing you to -d the whole config
<Chipaca> (we already have people asking for this)
<pedronis> Chipaca: do you have super powers to fix the formatting of that post? he reposted but the formatting is still broken
<Chipaca> pedronis: I do
<Chipaca> pedronis: I didn't because I doubt it'll make more sense, but if it'll help you I'll do it
<pedronis> Chipaca: unless it's really cut off
 * Chipaca does it
<Chipaca> pedronis: it's really cut off
<pedronis> ah
<pedronis> :/
<pedronis> ok
<pedronis> nvm
<Chipaca> pedronis: at least the PROBLEM section is now sensible :-)
<zyga> Pharaoh_Atem: I think I got what you asked for on snapd.mk review, I will run one more round of spread and propose my changes back
<mborzecki> damn, why the desktop test always have to be so flaky
<zyga> mborzecki: leaking processes
<mborzecki> google:ubuntu-18.04-64:tests/main/desktop-portal-filechooser failed now
 * diddledan spills some processes all over the carpet
<mborzecki> wth is this? https://paste.ubuntu.com/p/CZJ4JqZ4qg/
<diddledan> <troll> I'd say that's a paste of some terminal output *duck*
<diddledan> can't see what's going wrong though :-(
<mborzecki> OSError: [Errno 38] Function not implemented: '/run/user/12345/doc/257d6b8c/file-to-write.txt'
<diddledan> just spotted it :-)
<mborzecki> the portal is running though
<mborzecki> wonder if it's because of python trying to truncate the file
 * cachio lunch
<mborzecki> duh, obviously the test works in isolation, even when repeating it a couple of times
<zyga> mborzecki: think about system level solutions
<zyga> how to find broken tests?
<diddledan> heisenbug
<zyga> no, just order bug
<zyga> tests don't clean properly
<mborzecki> zyga: given it's ENOSYS, i'd guess it's from fuse as used by xdg-desktop-portal
<diddledan> aah
<zyga> random order may put stuff that leaks stuff ahead of test that is affected by it
<mborzecki> or document portal to be exact
<zyga> mborzecki: yes
<mborzecki> damn desktop tech
<zyga> Pharaoh_Atem: https://github.com/snapcore/snapd/pull/6111
<zyga> can you re-review that please
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> mborzecki: ^ perhaps you can have a look as well
<zyga> the next thing to fix is to move golang hardening flags to a helper like I indended
<zyga> then all of snapd.mk should be reusable
<stgraber> ever heard of snapd forgetting to generate a unit? https://discuss.linuxcontainers.org/t/containers-fail-to-start-after-server-upgrade-to-ubuntu-18-04-2-lts/4174/7
<stgraber> snap.lxd.daemon.unix.socket is present, snap.lxd.daemon.service isn't. Doing a back and forth refresh between two channels fixed it (back to same rev that was broken)
<zyga> stgraber: no
<zyga> that's interesting
<zyga> stgraber: can you ask for `snap changes` on the LXD forum?
<zyga> perhaps there are some clues there
<stgraber> zyga: output now included
<zyga> it would be awesome if pasting something into the forum showed a clippy saying "perhaps you wanted to paste pre-formatted text"
<zyga> "running service command" is interessting?
<mborzecki> zyga: just a hunch, but that's probably ENOSYS i'm seeing https://github.com/flatpak/xdg-desktop-portal/blob/master/document-portal/document-portal-fuse.c#L718-L735
<stgraber> ah yeah, I'm editing people's posts all the time :)
<zyga> perhaps ask for "snap tasks NNN" for the ones that failed?
<zyga> stgraber: same here, thank you for doing that :)
<zyga> mborzecki: oh, nice catch
<zyga> I didn't know the portal did not support that
<zyga> mborzecki: ^
<stgraber> zyga: updated
<zyga> Chipaca: ^ do we clean up if a service refresh fails, with regards to unit files?
<zyga> thanks, I see
<Chipaca> zyga: stgraber: it's possible an in-task cleanup is wonky
<zyga> feels like worth reporting, even to add a spread test to see it works forever
<mborzecki> zyga: 'works forever' don't know which industry is that, but not this one :P
 * zyga shrugs and writes medical-grade code ;-)
<diddledan> medical grade as in it makes you vomit?
 * zyga inserts matrix reference with no-mouth neo
<diddledan> "so offensive it kills 99.9% bacteria"
<pedronis> pstolowski: did you find out how to check about the snap-confine profile?
<zyga> pedronis: we talked about it, I gave a few suggestions that all should be sufficient to check this
<pedronis> ok, thx
<pstolowski> pedronis: yes, but i'm fighting a spread test error after the change
<zyga> afk for 30 min
<Chipaca> pedronis: I fear the followup refactor commit on #6540 is bigger than the original :-)
<mup> PR #6540: daemon, client, cmd/snap: debug GETs ask aspects, not actions <Created by chipaca> <https://github.com/snapcore/snapd/pull/6540>
<pedronis> Chipaca: looks good though
<pedronis> thank you
<Chipaca> huzzah
<Chipaca> HAH! the fix for service completion is in my 'git stash'
<Chipaca> never pushed a PR with it :-(
<pedronis> pstolowski: was in meetings, can we help somehow?
<pstolowski> pedronis: it's fine, thanks, will push in a moment
<mup> PR snapd#6541 opened: tests: change how dir is umounted on desktop-portal.sh <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6541>
<pedronis> zyga: can you review the new tests added to #6530
<zyga> sure
<mup> PR #6530: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6530>
<zyga> looking
<zyga> +1
<zyga> pedronis: I wish we had a "snap debug wait-for-change-type core-transition" or something like that
<zyga> pedronis: if mvo does a release, I will package it first thing tomorrow
<mup> PR snapd#6542 opened: cmd/snap: fix `snap services` completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/6542>
<zyga> cachio: hey
<zyga> cachio: has the leap 42.3 image changed?
<zyga> cachio: I thing we could use an update (just take stock 42.3 and run "zypper refresh && zypper dup" on it)
<mup> PR snapcraft#2483 closed: cli: Handle legitimate provider exec errors <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2483>
<mup> PR snapcraft#2487 opened: Release changelog for 3.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2487>
<kyrofa> Hey zyga, any idea why this doesn't work in LXD? https://paste.ubuntu.com/p/QT2mnJWZ5J/
<kyrofa> zyga, this works though: https://paste.ubuntu.com/p/zgf528P6sN/
<cachio> zyga,  in progress
<cachio> I almost have the tumbleweed image
<cachio> but there are some permissions that are missing and untils those are not granted I can't publish the image
<cachio> niemeyer, hey
<zyga> cachio: ack, thank you
<zyga> kyrofa: looking
<cachio> zyga, I think the images will be ready tomorrow
<cachio> I need those perms
<zyga> kyrofa: I don't know how here doc are implemented but I'm sure you have a denial saying why it didn't work
<zyga> kyrofa: most likely that shell opens a temporary file
<zyga> kyrofa: and passes a fd to the child process as input
<zyga> kyrofa: in the case it works the apparmor profile describes that file and allows snap-confine and bash to both use it
<zyga> kyrofa: in the case where it does it is denied by the outer stacked profile
<zyga> kyrofa: on the forum there are some discussions of "apparmor object delegation" but this is not implemented in the kernel or in userspace yet
<zyga> kyrofa: so for now, it's a bummer and we can only fix it by adjusting lxd profile; not sure if the adjustment is sane from security point of view though
<kyrofa> zyga, indeed, here are the denials (on the host): https://paste.ubuntu.com/p/4Sh6Hkf8sQ/
<zyga> kyrofa: report a bug on lxd with those details, perhaps it will be included
<zyga> it would be good to check what is the temporary file name pattern
<zyga> is it always sh-*
<kyrofa> stgraber, does that sound like a lxd bug to you? Happy to report it
<kyrofa> stgraber, uh, context: the fact that this doesn't work in LXD: https://paste.ubuntu.com/p/QT2mnJWZ5J/
<kyrofa> stgraber, with this type of denial on the host: https://paste.ubuntu.com/p/4Sh6Hkf8sQ/
<stgraber> kyrofa: the file_inherit stuff is some kind of apparmor bug causing the profile in a container to have to be slightly more comprehensive than on the host
<stgraber> kyrofa: IIRC this is something we ran into with snaps a LONG time ago and which got fixed by adding the required allow rule in snapd generated profiles
<stgraber> the /apparmor/.null path is a bit odd though
<kyrofa> stgraber, huh, so perhaps this used to work and regressed?
<stgraber> kyrofa: yeah, that's posssible, it could have been a change to the generated apparmor profile, can be a change to the kernel or a change to the apparmor parser
<stgraber> kyrofa: in all cases, you want someone from apparmor taking a look into this, jdstrand might know what's happening or jjohansen
<stgraber> kyrofa: the exact kernel you're running may also matter here
<kyrofa> stgraber, alright, thank you!
<Chipaca> pedronis: am I right to think we said we should make 'snap debug connectivity' use the GET path as well?
<Chipaca> pedronis: (so everything listed under snap debug -h works without sudo)
<mup> PR snapcraft#2488 opened: cli: Fix traceback count check in error test <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2488>
<mup> PR snapcraft#2489 opened: cli: Mock Raven client in error tests <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2489>
#snappy 2019-02-27
<mup> PR snapcraft#2488 closed: cli: Fix traceback count check in error test <Created by cmatsuoka> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2488>
<mup> PR snapcraft#2489 closed: cli: Mock Raven client in error tests <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2489>
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey hey
<zyga> how are you feeling?
<mborzecki> zyga: quite fine, thanks
<zyga> I was fighting odd build issue last night
<zyga> golang changed in suse again
<zyga> but this time for the better
<mborzecki> zyga: again?
<zyga> yeah, the maintainer applied my suggestion
<zyga> and removed /etc/profile.d/go.sh
<zyga> so no more magic variables
<pstolowski> mornings
<zyga> the problem is that now it doesn't work because we start with those
<zyga> I will try to sprinkle unset in strategic places
<mborzecki> pstolowski: hey
<zyga> I think I have a fix
<zyga> not sure if it's just me or is master broken too
<zyga> but I'm working oni t
<kjackal> Hi snappy people. Do we know when the next snapcraft release is scheduled? I cannot work on MicroK8s since I am not able to build it due to this https://bugs.launchpad.net/snapcraft/+bug/1817300 . Do we at least have a workaround?
<mup> Bug #1817300: autotools plugin fails to build in classic confinement <Snapcraft:Fix Committed by sergiusens> <Snapcraft legacy:Fix Committed by sergiusens> <Snapcraft trunk:Fix Committed by sergiusens> <https://launchpad.net/bugs/1817300>
<mborzecki> pstolowski: i'm thinking the script that patches mount units to add selinux context should be part of the PR with policy refactor
<zyga> yay
<zyga> master is fixed with my patch
<zyga> pushed
<zyga> once green I'll land https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<pstolowski> mborzecki: ok
<zyga> if urgent we can cherry-pick https://github.com/snapcore/snapd/pull/6111/commits/27d844a3b86b73bddf97a837faa6e2fb66124003
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<sborovkov> ogra, zyga https://github.com/snapcore/core/pull/98 can this be merged in, has been in this state for months
<mup> PR core#98: Add force_turbo rpi option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/98>
<zyga> sborovkov: looking
<zyga> sborovkov: I will merge it today after getting an ack from pedronis
<sborovkov> thanks
<pedronis> sborovkov: zyga: remember that we don't use that configure hook anymore
<sborovkov> oh ok, this needs to be changed then?
<sborovkov> pedronis, because I can't see any other references to rpi config options anywhere
<pedronis> https://github.com/snapcore/snapd/blob/master/overlord/configstate/configcore/picfg.go
<sborovkov> got it thanks
<pedronis> we probably need to decide what to do with the hook is was mostly there for compat in some refresh scenarios
<Chipaca> mo'in
<pedronis> Chipaca: hi, yes we discussed about allowing connectivity also without sudo
<pedronis> Chipaca: #6540 can be merged
<mup> PR #6540: daemon, client, cmd/snap: debug GETs ask aspects, not actions <Created by chipaca> <https://github.com/snapcore/snapd/pull/6540>
<mup> PR snapd#6543 opened: Add force_turbo to the list valid pi config keys <Created by sergey-borovkov> <https://github.com/snapcore/snapd/pull/6543>
<Chipaca> huzzah
<sborovkov> pedronis, zyga https://github.com/snapcore/snapd/pull/6543
<mup> PR #6543: Add force_turbo to the list valid pi config keys <Created by sergey-borovkov> <https://github.com/snapcore/snapd/pull/6543>
<mup> PR snapd#6540 closed: daemon, client, cmd/snap: debug GETs ask aspects, not actions <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6540>
<mup> PR snapd#6530 closed: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core <Squash-merge> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6530>
<mup> PR snapd#6472 closed: overlord: fix ensure before slowness on Retry <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6472>
<zyga> hmm, build failed on https://travis-ci.org/snapcore/core/builds/444677088
<zyga> sil2100: are you looking after core builds with mvo?
<zyga> or is that just mvo?
<mup> PR snapd#6544 opened: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6544>
<sil2100> zyga: I think it's just mvo, I don't do much with core itself
<zyga> I see, thanks
<sil2100> Since core is still a snapd thingy ;)
<pstolowski> pedronis: hey, do you have time today to talk about perf measurements?
<pedronis> pstolowski: yes,  would in 45 mins work?
<mborzecki> interesting, xdg-open does not work with portal-test snap, which uses core18 base
<pstolowski> pedronis: yes
<mborzecki> all i get is /usr/bin/xdg-open: 2: exec: snapctl: not found
<pedronis> mborzecki: seems like a real bug
<mborzecki> relevant strace https://paste.ubuntu.com/p/YsXvK7tYQW/
<mborzecki> a random snap with core base works just fine
<zyga> mborzecki: interesting
<zyga> mborzecki: what is /usr/bin/xdg-open?
<zyga> mborzecki: in core it was a special version that came from a PPA
<zyga> perhaps we... missed that?
<zyga> (should have upstreamed a patch to xdg-open)
<mborzecki> zyga: no, it's a shell script that calls to snapctl user-open "$@"
<zyga> mborzecki: that's good
<zyga> what happens when you call snapctl user-open http://example.com/
<zyga> does it work?
<mborzecki> zyga: bash: snapctl: command not found :? hmm
<zyga> oh
<zyga> I know
<zyga> is /usr/bin/snapctl there?
<zyga> no? that's that :)
<zyga> it's not on path
<zyga> it's only in /usr/lib/snapd/snapctl
<zyga> is it?
<zyga> \o/
<mborzecki> zyga: nope, not there
<pedronis> in core it's a symlink
<zyga> real bug
<zyga> so...
<oSoMoN> I'm trying to ship chromedriver in the chromium snap, but it needs to run chromium with a full path, which I specify as "/snap/bin/chromium", but it's not seeing it, I assume that's a confinement thing. Is there a documented way of making one app in a strictly confined snap execute another app in the same snap?
<zyga> how does /usr/bin/snap work?
<zyga> mborzecki: where is `snap` on core18?
<mborzecki> btw. core18 is withouth snapd, so that content of /usr/lib/snapd i see is from the host?
<pedronis> yes
<zyga> oSoMoN: you cannot run apps this way, you can run executables but you will retain your current set of permissions
<zyga> mborzecki: correct
<zyga> oSoMoN: you can run anything via $SNAP/... (not /snap/bin)
<zyga> oSoMoN: but as I said, if you have two apps with different permissions, you will not transfer the permissions over
<mborzecki> is snapctl a symlink to /usr/lib/snapd/snapctl on ubuntu?
<zyga> mborzecki: yes
<pedronis> mborzecki: yes
<zyga> mborzecki: not just on ubuntu
<zyga> mborzecki: it should be that everywhere
<pedronis> but it comes from the package
<zyga> a symlink to ../lib/snapd/snapctl
<oSoMoN> zyga, that probably won't work thenâ¦ thanks for confirming
<oSoMoN> I guess I'll have to split chromedriver into its own separate, classic snap
<mborzecki> ok, so there's 2 things that can be wrong in my setup, /usr/lib/snapd not in PATH (is it on ubuntu?) and arch packaging (snapctl is not a symlink)
<zyga> mborzecki: /usr/lib/snapd should not be on path anywhere
<zyga> the bug is the symlink
<zyga> mborzecki: but but but
<zyga> mborzecki: you can use snapd.mk to fix arch package RSN
<zyga> :D
<zyga> I'm happy to help
<mborzecki> zyga: haha ok
<zyga> it handles all that
<zyga> aaand it's in
<mborzecki> zyga: but w8, if /usr/lib/snapd is not in $PATH inside snap executio env, how will xdg-open work then?
<zyga> just got green :)
<zyga> mborzecki: xdg-open works because snapctl is on path
<zyga> via the symlink
<mborzecki> unless core18 should ship a symlink then?
<zyga> yeah, that's the next question
<zyga> I ... think so
<mup> PR snapd#6111 closed: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6111>
<zyga> but perhaps mvo has some opinions
<mborzecki> ah there is a symlink
<zyga> oh?
<mborzecki> yeah, bash is smart to not show it in completion when it's dead :/
<zyga> ah
<zyga> makes sense
<zyga> why is it dead?
<zyga> no snapctl in /usr/lib/snapd?
<mborzecki> yup, ok, i'm gonna fix arch package then
<zyga> try using snapd.mk
<zyga> if it sucks for whatever reason please tell me
<mborzecki> zyga: but it's in master only now, isn't it?
<zyga> yeah
<zyga> ah, i see what you meant now
<zyga> for release do whatever makes sense
<zyga> just for future reference packaging in master
<mborzecki> so, it looks like we're missing a ... spread test :)
<zyga> mborzecki: indeed!
<zyga> but that's true of lots of core18 things
<oSoMoN> zyga, given that chromedriver's sole purpose it to execute and drive chromium, it shouldn't be too bad if I give the app the same set of permissions as chromium itself, I'll give that a try
<mup> PR snapd#6545 opened: cmd/snap, daemon: make the connectivity check use GET <Created by chipaca> <https://github.com/snapcore/snapd/pull/6545>
<mup> PR core#98 closed: Add force_turbo rpi option <Created by sergey-borovkov> <Closed by zyga> <https://github.com/snapcore/core/pull/98>
<mup> PR core#102 opened: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <https://github.com/snapcore/core/pull/102>
<mborzecki> as a side note, since snapctl runs in snap mount ns, it should probably be built statically
<zyga> mborzecki: yeah
<mup> PR snapcraft#2487 closed: Release changelog for 3.2 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2487>
<pedronis> pstolowski: in the standup ho?
<zyga> https://github.com/snapcore/core/pull/102 this needs a review
<zyga> ogra: ^
<mup> PR core#102: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <https://github.com/snapcore/core/pull/102>
<mborzecki> pushing an update to arch package in a bit
<pstolowski> pedronis: coming
<zyga> brb, need to get daughter to school
<zyga> re
<zyga> Feb 27 09:57:30 feb270955-025300 snapd[2233]: link.go:75: cannot update fontconfig cache: cannot run fc-cache-v6 on core: signal: terminated
<zyga> blast from the pastQ
<mborzecki> arch package updated
<mborzecki> and we do have a symlink in our packaging/arch setup already
<oSoMoN> zyga, for information, the approach of pointing chromedriver to the chromium wrapper script under $SNAP and giving it the same permissions worked, thanks for the help
<zyga> +1
<mup> PR snapd#6546 opened: packaging: build snapctl as a static binary <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6546>
<mborzecki> zyga: ^^
<zyga> looking
<zyga> replied
<zyga> I think snapd.mk doesn't handle snap-failure
<zyga> what is that for?
<vvug> Hi. Should I prefer the LibreOffice snap package or deb package? Which one is the best maintained one?
<mborzecki> zyga: lest build a static tree :P
<zyga> heh
<zyga> vvug: both should be maintained but the snap should have more versions to choose from
<zyga> vvug: for example, the classic package can be from a less recent major / minor versions
<zyga> but with security fixes applied
<Chipaca> zyga: snap only has 6.2.0.3 right now tho :-)
<zyga> the snap package may offer multiple versions (including most recent one)
<zyga> vvug: having said that, I'm not maintaining that snap, perhaps popey would know?
<Chipaca> vvug: the snap package is 6.2.0.3 which is newer than any in-distro one fwiw
<vvug> zyga: thanks. It's a bit confusing to have both. I wonder if there is a longish-term plan to ditch the .deb in favor of the snap
<zyga> vvug: I think both will remain supported for a while, eventually the deb might cease to be installed by default but I suspect it will stay being available forever
<vvug> I see. I guess that if one want to follow the LTS releases but have an up-to-date LibreOffice the snap is a good option. But there is also a "fresh release" PPA I think. It's nice to have options, but sometimes confusing too :)
<zyga> vvug: just complexity, you get to see the intermediate points
<pedronis> Chipaca: the new api_debug*.go should probably says 2019 ?
 * Chipaca looks at the calendar
 * Chipaca notices it still says 1974
<Chipaca> drat
 * zyga gives Chipaca a battery for his calendar
 * Chipaca hopes it's an artillery battery
<mborzecki> wish systemctl had something like try-stop to return whether a stop action was actually executed or not
<mborzecki> otherwise systemctl is-active .. && systemctl stop feels racy
<Chipaca> mborzecki: why do you care?
<Chipaca> mborzecki: i mean, stop works even if the thing is stopped
 * pstolowski lunch
<mborzecki> Chipaca: hmm maybe i shouldn't, otoh when patching mount units for selinux i can't restart them without affecting the services
<Chipaca> mborzecki: mount units don't do reload?
<mborzecki> Chipaca: they may do, but you cannot change a security context of a mounted block device
<mborzecki> Chipaca: the kernel blocks it intentionally
<pedronis> Chipaca: pstolowski: some of mvo commens on #6356 and #6322 (not sure about the Commit helper there though, would have to be tried)
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<pedronis> in case of doubt ask me
<Chipaca> and conflicts!
<tobikoch> Hi
<tobikoch> Is there a way to skip the connectivity check during snapcraft cleanbuilds?
<pedronis> Chipaca: that oo
<pedronis> too
<Chipaca> pedronis: did you understand the comment about the filter, or should I ask mvo?
<pedronis> Chipaca: I think he is proposing that reRefreshUpdateMany be set to a function that hides the passing of the filter
<pedronis> not sure if that messes with testing or not
<pedronis> Chipaca: changing this line var reRefreshUpdateMany = updateManyFiltered
<pedronis> to be = func ...
<pedronis> Chipaca: I'm also not sure I like that change
<pedronis> Chipaca: I think the issue is more with the name: reRefreshUpdateMany
<Chipaca> pedronis: i.e. if it's for reRefresh already why does it need a filter?
<pedronis> Chipaca: yes, I think that's his thinking (guessing here)
<pedronis> the name implies it does the full job
<Chipaca> yeah
<Chipaca> ok, I'll change that because it's a good point, and then will confirm with mvo there wasn't a deeper one
<zyga>   /me walk ...
<pedronis> Chipaca: change that in which way? the name or the line?
<Chipaca> the name
<pedronis> ok
<Chipaca> I'll call it totallyNotReRefreshUpdateManyMaybe
 * Chipaca hides
<pedronis> doingTheThingConsideringTheThingsAndTheTimeOfTheYear
<Chipaca> pedronis: ...(thing Thing, things map[string]Thinger, moon moon.Phase) Result { â¦
<pedronis> mborzecki: I did pass over #6079
<mup> PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<mborzecki> pedronis: thanks!
<pedronis> Chipaca: ^ something for your list of things to look at as well
<Chipaca> ack
<Chipaca> pedronis: do you have a suggestion for a better name for the "laneSnaps" helper?
<pedronis> Chipaca: refreshedSnaps ?
<pedronis> the comment can say how their are determined, but is not so relevant to the role
<pedronis> s/role/purpose/ of the function
<Chipaca> pedronis: sgtm
<zyga> back now
<zyga> feels like spring now :)
<dot-tobias> I'm suddenly getting âexecv failed: No such file or directoryâ during the install hook run of my snap â but the hook is in snap/hooks, has mode 0700 and is included in the snap file
<Chipaca> dot-tobias: is it a script, or a binary?
<zyga> good hunch
<dot-tobias> Chipaca: script, starts with shebang and only creates a directory in $SNAP_COMMON
<zyga>  dot-tobias what is the interpreter?
<Chipaca> zyga: no, just 'shebang' :-p
<dot-tobias> #!/bin/sh -e, like in the docs
<zyga> ah
<zyga> dot-tobias: any apparmor denials?
<dot-tobias> zyga: I'm trying in devmode, getting three STATUS messages with âprofile_replaceâ, âsame as current profile, skippingâ
<zyga> those are harmless
<zyga> look for ALLOWED
<dot-tobias> Nothing, just those three. (Note: I'm tailing /var/log/syslog during the install attempt, any other logs?)
<zyga> mmm, that should be it
<zyga> dot-tobias: can you report a bug with a reproducer please?
<dot-tobias> zyga: Sure, will do
<zyga>  what is https://github.com/snapcore/snapd/pull/6544 failing on
<mup> PR #6544: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <https://github.com/snapcore/snapd/pull/6544>
<zyga> I see it restarted over and over
<mup> PR snapd#6513 closed: [RFC] many: support `snap install --skip-service-start` <â Blocked> <Created by chipaca> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6513>
<pedronis> zyga: master is green, so it would be something 2.37 specific
<zyga> pedronis: I merged https://github.com/snapcore/snapd/pull/6544
<zyga> are we ready for .4?
<mup> PR #6544: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6544>
<mup> PR snapd#6544 closed: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core (2.37) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6544>
<pedronis> zyga: I think so afaik
<pedronis> I pinged mvo in tg
<cwayne> zyga: will you be pushing a .4 to beta imminently?
<zyga> no, not me
<zyga> if anyone, mvo would
<cwayne> I mean you as in the collective team :)
<zyga> let me ask if he would consider this
<zyga> mvo is off this week
<cwayne> its not a problem if youre not, just wanted to be ready in case
 * cwayne isnt pushing for one right now :)
<zyga> cwayne: mvo is on the road now, he will do it later today
<cwayne> zyga: thanks for the headsu p
<zyga> cwayne: I will let you know more once I konw
<zyga> *know
<cwayne> no worries, thanks man
<Chipaca> pedronis: stdup?
<mup> PR snapd#6547 opened: tests: enable opensuse tumbleweed on spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6547>
<mup> PR snapd#6546 closed: packaging: build snapctl as a static binary <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6546>
<dot-tobias> zyga , Chipaca: nvm the previous query about install hook failures, it seems like it was caused by a layout I added for /usr (which, what I would've seen if I had scrolled the layout docs down to the bottom, is currently not possible)
<zyga> oh
<zyga> layout for _entire_ /usr?
<zyga> or for a sub-directory?
<zyga> can you tell me more what your use case was?
<dot-tobias> zyga: entire /usr, dunno what I was thinking. I'm currently snapping the WPE fork of WebKit and it assumes a bunch of libs and other stuff in /usr/ sub-directories, so I was basically being lazy. I specified /usr/share/X11 and it's installing fine again; although I now have the problem that some libs are in arch-triplet subdirectories and I want to avoid that. Final target is arm, testing on amd64 â¦ but I think I'll use organize for this
<zyga> ok, thank you
<zyga> I think we should warn / do something smart about layout for /usr
<zyga> as that hides /usr/lib
<zyga> and thus /usr/lib/snapd
<zyga> cachio: https://en.opensuse.org/Lifetime -- openSUSE Leap 42.3 will be supported till the 30th of June
<zyga> 15.0 will be EOLd in November but .1 is pending so I think we will drop 42.3 and switch to 15.1
<zyga> (that is switch 15.0 to 15.1)
<mup> PR snapcraft#2490 opened: test: test-beta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2490>
<pedronis> pstolowski: is the hotplug main PR description/commit msg correct or does it need updating to reflect the bit really in the change?
<pedronis> otherwise it can go in
<pstolowski> pedronis: thank you, indeed, i will tweak it
<jdstrand> Chipaca: hey, I noticed in a895e537c55a350af30250e5bedc1b16e0c095ab you introduced src/github.com/snapcore/snapd/overlord/snapstate/export_test.go:221:19: expected type, found '=' on bionic with golang 1.10
<jdstrand> Chipaca: is there something I should be doing differently? /me thought bionic and 1.10 would be good enough these days
<zyga> oh
<zyga> are we  using type aliases?
<zyga> hey jdstrand :)
<jdstrand> hey zyga :)
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6499 is a low hanging fruit, has +2, just needs your ack
<mup> PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
<mup> PR snapd#5962 closed: ifacestate/hotplug: integration with udev monitor <Complex> <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<pstolowski> cachio: hey, in my nested vm branch i've a change in spread.yaml and i'm not sure if is required - plan: n1-standard-2 - i probably added it long time ago
<pstolowski> cachio: was it your suggestion?
<Chipaca> zyga: for testing, yes
<cachio> pstolowski, let me check
<Chipaca> jdstrand: that should work from 1.9 onwards
<Chipaca> jdstrand: where's the error from?
<Chipaca> jdstrand: (we run the unit tests with 1.9 and 1.10 so it should all work)
<jdstrand> Chipaca: run-checks
<jdstrand> $ ./run-checks
<jdstrand> ...
<jdstrand> Checking for naked returns
<jdstrand> could not parse input /home/ubuntu/gocode/src/github.com/snapcore/snapd/overlord/snapstate/export_test.go:221:19: expected type, found '='
<cachio> pstolowski, it is required
<jdstrand> $ go version
<jdstrand> go version go1.10.4 linux/amd64
<jdstrand> Chipaca: ^
<pstolowski> cachio: ack, thanks for checking!
<Chipaca> jdstrand: rebuild nakedret
<cachio> pstolowski, np
<Chipaca> jdstrand: :-)
<cachio> pstolowski, it is a more powerfull machine than the regular ones
<jdstrand> Chipaca: that seemed to work
<Chipaca> jdstrand: huzzah :-)
<jdstrand> Chipaca: thank you :)
<Chipaca> jdstrand: np. Sadly there's no good way of rebuilding the tools conditionally
<Chipaca> and non-conditionally slows things down without a huge gain
<jdstrand> ack. I made a note in case this happens again
<pstolowski> pedronis: https://github.com/snapcore/snapd/pull/6491/ has been updated with master and is ready for reviews
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<zyga> pstolowski: any luck with there LMP board for your work?
<pstolowski> zyga: i didn't have time yet to check it out
<Wimpress> Snapcraft Live starts in a few minutes - https://www.youtube.com/watch?v=B4OFvrwoZ8I
 * zyga goes after the forum :-)
<zyga> Wimpress: nice, I wish I could watch that now
<Chipaca> zyga: keep the tab going in the background, it's like being at a sprint or sth
<mup> PR snapd#6542 closed: cmd/snap: fix `snap services` completion <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6542>
<zyga> Chipaca: I would but the people studying around me might complain :-)
<Chipaca> zyga: it's in a different language, it doesn't interfere
<Chipaca> right?
<zyga> Iâd ask but Iâm just starting ;-)
<cwayne> zyga: they should be studying snapcraft anyway
<cwayne> its a favor really
<mup> PR snapd#6547 closed: tests: enable opensuse tumbleweed on spread <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6547>
<Chipaca> popey: I need to report a bug in word-salad :-)
<popey> haha
<popey> https://github.com/popey/word-salad-snap/issues
<Chipaca> need to EOD now, but I'll file a pr later :-)
<roadmr> zyga: are you around? ;)
<mup> PR snapd#6548 opened: release: snapd 2.37.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6548>
<zyga> roadmr: re (though I won't be long)
<roadmr> zyga: oh, it was about that thing about the store :)
<zyga> ack
<jdstrand> roadmr: hi! can you pull r1190 of the review-tools. This would be best for a Monday/Tuesday deploy. I rewrote the snap decl checks for better clarity, quality and maintenance and fixed various bugs. all the old unit tests pass (167 iirc) as well as new ones
<roadmr> jdstrand: great! thanks! sure, I'll put it in the queue
<jdstrand> roadmr: thanks! :)
<mup> PR snapd#6549 opened: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549>
#snappy 2019-02-28
<mup> PR snapcraft#2490 closed: test: test-beta <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2490>
<mwhudson> hmm trying to use the fakestore and failing
<mwhudson> just get http 418s from everything
<mwhudson> anyone around?
<mwhudson> i guess i'll ask in the forum
<mborzecki> morning
<mborzecki> brb kernel update
<zyga> Hey guys! I will be in the office in 20 minutes. Doing some babysitting now.
<mborzecki> arch package update pushed
<pstolowski> mornings
<pedronis> pstolowski: hi, mvo created this: https://trello.com/c/h3v4bN13/172-fix-build-failure-on-armhf-in-edge-ppa
<pedronis> is that a new test?  or associated with recent changes?  seems it's failing in the armhf builders
<pedronis> timing?
<pstolowski> pedronis: hey, yes, i got email from trello, investigating, reproduced locally by running in a loop, seems like a race
<pedronis> pstolowski: ok, thank you,  and yes it's a priority given it's stopping us from producing edge builds for arm
<pstolowski> pedronis: i don't think it's because yesterday's changes, this landed last week
<pedronis> pstolowski: not quite sure when the error appeared
<pstolowski> pedronis: more worrying is the amd64 failure in same ppa on TestHotplug
<pedronis> pstolowski: ok
<pstolowski> pedronis: looks like something got stuck on udev monitor, might be something build env specific, hard to tell
<pstolowski> but also, not related to yesterday's change i think, that test was landed long time ago
<pedronis> pstolowski: ok, let me know how it goes
<pstolowski> pedronis: sure
<mborzecki> rpm triggers for downgrade suck
<pstolowski> pedronis: ok, i got it, PR coming
<mup> PR snapd#6550 opened: daemon/tests: fix race in the disconnect conflict test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6550>
<pstolowski> pedronis: ^
<pstolowski> pedronis: the amd64 failure on 14.04 is unclear atm, not sure why we didn't see it before; the udev mon test run for 10 minutes and got killed, i'll see if i can reproduce on 14.04
<pedronis> pstolowski: +1 on the first fix
<Chipaca> moin moin
<pedronis> Chipaca: hi
<Chipaca> pedronis: 'sup
<mborzecki> hmm rpm triggers are most interesting, semi-useless documentation, only thing you can really do is experiment :/
<pedronis> Chipaca: how's the tweaking of 6356 ?
<Chipaca> pedronis: nearly done, just the reRefreshUpdateMany rename pending
<Chipaca> pedronis: problem is I either make it _the_ update many, or fix it with a comment
<Chipaca> dithering too much on that
<pedronis> Chipaca: can I help? but I'm not understanding those last two comments
<Chipaca> pedronis: I'll let you know :-)
<zyga> uh, re
<zyga> hey
<zyga> sorry, tough night, tough morning
<zyga> pstolowski: I see you know about the card mvo made
<zyga> we discussed it last night and he asked me to relay that you have a look
<pstolowski> zyga: yep, https://github.com/snapcore/snapd/pull/6550
<mup> PR #6550: daemon/tests: fix race in the disconnect conflict test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6550>
<zyga> pstolowski, pedronis: should we do a .5 with this or is it sufficient to just patch master?
<pedronis> zyga: as far as I understand it was affecting edge
<pedronis> not 2.37
<zyga> pedronis: the failure was reported on .4 build
<zyga> https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages
<zyga> on line three there
<pedronis> then mvo explained himself badly
<zyga> let me check the state of beta
<zyga> pedronis: I think we're good, I see .4 in beta across all architectures
<Chipaca> zyga: hella good
<zyga> Chipaca: :-) hey, how are you doing?
<Chipaca> zyga: hating names
<zyga> oh?
<zyga> what's wrong?
<Chipaca> :-)
<Chipaca> zyga: nothing unusual there though
<pstolowski> google:ubuntu-14.04-64:tests/main/snapd-reexec failed on my PR (unrelated to the PR), and lots of aborts again
<pedronis> pstolowski: yes, lots of aborts
<pedronis> in many PRs
<pedronis> pstolowski: spread error output about aborts is always hard to chase
<pstolowski> uhm
<pedronis> usually is allocating machines?
<pedronis> pstolowski: zyga: ah,  2019-02-28 07:08:49 Cannot allocate google:opensuse-tumbleweed-64: cannot find any Google image matching "opensuse-tumbleweed-64" on project "computeengine" or "opensuse-cloud"
<pstolowski> uh
<pedronis> we should disable it until cachio can debug
<pedronis> it worked yesterday once or so
<pedronis> pstolowski: add a manual:true in its stanza (as we have for others)
<pedronis> in your PR
<pstolowski> pedronis: you mean in #6491?
<mup> PR #6491: interfaces: hotplug nested vm test, updated serial-port interface <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<pedronis> pstolowski: ?
<pedronis> pstolowski: the easy one
<pedronis> pstolowski: #6550
<mup> PR #6550: daemon/tests: fix race in the disconnect conflict test <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6550>
<pedronis> pstolowski: the other needs a review process no?
<pedronis> pstolowski: we need a PR that we want to land and can land soon
<pstolowski> pedronis: yes sure the other PR needs reviews; ok, will set opensuse-tumbleweed to manual for now
 * Chipaca brb
<pedronis> mborzecki: could you review #6356 when you have some time?
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<pedronis> pstolowski: thanks
<mborzecki> pedronis: sure, gladly, got quite fed up with the rpm crap
<mborzecki> heh, i cannot use snap-mgmt to do the patching of mount units and we'll have to ship a separate script, otherwise downgrade to pre selinux-aware snapd won't work
<zyga> 2.37.4 panic in unit tests
<zyga> https://www.irccloud.com/pastebin/Ky7i9Vr5/
<mup> PR snapd#6499 closed: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6499>
<zyga> I added a trello card
<pedronis> zyga: about ?
<zyga> about that failure, so that I don't forget to look at it later today
<zyga> going through the release process now
<pedronis> zyga: when does it happen?   2.37 is green
<pedronis> on GH
<zyga> pedronis: it seems like a race, it happened in 2.37.4 unit tests during package build
<pedronis> ok, weird
<pedronis> I would those tests don't need to do weird racy things
<pedronis> but what do I know
<zyga> yeah :(
<pedronis> the test is probably complicated
<pedronis> zyga: no, I fear a real bug
<pedronis> the manip of the counter is wrong
<pedronis> will send a fix after lunch
<Chipaca> pedronis: somebody at the sprint said that when we remove a snap we forget all connections, but it was in the middle of a bigger discussion and I didn't correct them even though I don't think that's right
<Chipaca> pedronis: that wasn't you was it?
<Chipaca> we so don't forget them, you can ask for connections of snaps that aren't even installed
<zyga> that was me
<zyga> when we remove the last revision we add one more task
<Chipaca> zyga: I'm not theorising, I'm looking at it on my system
<zyga> oh
<zyga> so bug :)
<Chipaca> zyga: is it though
<Chipaca> zyga: I've heard it described as a feature
<Chipaca> it does feel at least partially buggy in that connections only accumulate
<Chipaca> e.g. I iterated on the connections on icdiff, and my snapd remembers all the names as separate things
<Chipaca> even more interestingly, 'snap connections' lists it as connected even though the snap is removed
<Chipaca> which sounds like fun :-)
<zyga> uh
<zyga> can you add a card please
<zyga> I'll look
<Chipaca> pedronis: can you comment on this behaviour, wrt whether we want it one way or another please
<mup> PR snapd#6550 closed: daemon/tests: fix race in the disconnect conflict test <Simple ð> <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6550>
<pstolowski> pedronis: ^ merged
<pedronis> Chipaca: we have a thing called discard-conns
<pedronis> isn't it called
<pedronis> ?
<Chipaca> pedronis: no
<Chipaca> that was an easy grep
<pedronis> Chipaca: ?
<Chipaca> pedronis: it's not called
<Chipaca> pedronis: grep -r --include \*.go --exclude \*_test.go discard-conns
<pedronis> Chipaca: it was at some point
<pedronis> have we lost it?
<pedronis> addHandler("discard-conns", m.doDiscardConns, m.undoDiscardConns)
<pedronis> ifacestate does define it
<popey> Is there some way to do a "snap why <snap>" to find out why a particular snap is installed? e.g. "snap why core18" might tell me opentoonz is why i have it installed?
<Chipaca> pedronis: yes we lost it
<pedronis> Chipaca: how, when?
<pstolowski> pedronis: yes i think we last it when we switched to running disconnects
<pstolowski> *lost
<pedronis> pstolowski: but disconnect should remove conns?
<pedronis> but Chipaca says conns are there
<pedronis> there is bug
<Chipaca> pedronis: dc290cac8b548ec7369433dda75c9cdd6d71e271
<pedronis> Chipaca: anyway, yes it's bug, we don't want to keep conns around for removed snaps
<Chipaca> ok
<Chipaca> we do :-)
<pedronis> we are not supposed to
<pedronis> would be good to find out how
<pedronis> because disconnect should remove them
<pedronis> at least one by one
<Chipaca> popey: we don't currently track that though
<pedronis> Chipaca: anyway sounds like we are missing a test somewhere
<pedronis> or is more complicated
<pedronis> and we don't lose them only sometimes
<pstolowski> pedronis: yes we do delete(conns, cref.ID()), although its condition on auto flags etc, so maybe that's wrong
<pedronis> pstolowski: ?
<pstolowski> *conditional
<pedronis> ah
<Chipaca> ah, maybe we only don't forget manual ones
<pstolowski> pedronis: in doDisconnect
<pedronis> something seems off
<pedronis> discard-conns removed everything
<pedronis> anyway depends which auto flag
<pstolowski> Chipaca: do you see undesired:true on those connections?
<Chipaca> pstolowski: in the state itself?
<pstolowski> Chipaca: yes
<pedronis> pstolowski: the code seems right to me tough
<pedronis> it always delete
<Chipaca> pstolowski: "icdiff:personal-files core:personal-files":{"interface":"personal-files","plug-static":{"read":["$HOME/.gitconfig"]}}
<pedronis> unless it's a autodisconnect
<pedronis> it's not a auto-disconnect
<pedronis> are we setting that flag wrong?
<pstolowski> doAutoDisconnect: // "auto-disconnect" flag indicates it's a disconnect triggered as part of snap removal, in which case we want to skip the logic of marking auto-connections as 'undesired' and instead just remove them
<pstolowski> and we set it there
<pedronis> exactly
<pstolowski> i looked at disconnect() as well, the flag is carried there, looks sane
<pedronis> we are missing a test and/or not understanding what happens/happened on Chipaca's system
<cachio> pedronis, lokking this problem
<Chipaca> pedronis: pstolowski: what happens to connections on refresh? if a snap's connections change, in particular
<Chipaca> I imagine there it's sane to keep them all
<Chipaca> on removal, do we only look at the 'current' connections?
 * Chipaca should look at the code
 * Chipaca should also try to reproduce this from scratch
<pedronis> zyga: fix https://github.com/snapcore/snapd/pull/6551
<mup> PR #6551: systemd: decrease the checker counter before unlocking otherwise we can get spurious panics <Created by pedronis> <https://github.com/snapcore/snapd/pull/6551>
<Chipaca> anyway, first to go back to reviewing connections
<mup> PR snapd#6551 opened: systemd: decrease the checker counter before unlocking otherwise we can get spurious panics <Created by pedronis> <https://github.com/snapcore/snapd/pull/6551>
<pedronis> Chipaca: we don't keep connections per revision, so there is no current
<pstolowski> Chipaca: you might be onto something with this question, doSetupProfiles/setupProfilesForSnap looks a bit suspicious and it relies - again - on reloadConnections (which was wrongly uses on core transition and i was fixing it last week)
<pstolowski> pedronis: ^
<pstolowski> did we run discard-conns on refreshes before switching to new revision?
<pedronis> no
<pedronis> it was strictly for full removal of snaps
<pedronis> only
<pstolowski> ok
<pstolowski> so yes, a test with refresh to a revision with less connections may give an answer
<pedronis> pstolowski: but those I think fully remove the snap from repo in a refresh
<pedronis> pstolowski: there's a DisconnectSnap  and RemoveSnap in those
<pedronis> before adding it back and reloading connections
<pstolowski> pedronis: yes, but where do we update conns be in sync with repo?
<pstolowski> *to be
<pedronis> pstolowski: ?
<pedronis> we drop everything from repo
<pedronis> pstolowski: Chipaca: but there is code that would keep around connections for unknown slots/plugs
<pstolowski> pedronis: yes, but don't we have the same problem we had with ubuntu-core transition? we need to keep conns in sync with repo, but reloadConnections only adds connections from conns in state, never removes
<pedronis> pstolowski: we DisconnectSnap and RemoveSnap
<pedronis> on repo
<pedronis> that should remove everything
<pedronis> then we add back
<pedronis> in reloadConnections
<pedronis> pstolowski: we reset the repo first or that's the intention at least
<zyga> yes
<pstolowski> pedronis: yes, but DisconnectSnap/RemoveSnap remove in memory only
<pedronis> pstolowski: ?
<zyga> pstolowski: what else would it remove?
<pedronis> pstolowski: we keep the same conns
<pedronis> if what you are asking
<pedronis> because of the code in reloadConnections
<pedronis> that ignore some errors
<pedronis> but that has nothing to do with sync with repo
<pedronis> repo should be a clean slate at that point
<zyga> pedronis: I'm wondering if we should change things so that repo is only constructed from state on demand
<zyga> pedronis: repo is very useful
<zyga> pedronis: but the mental model of how to sync it is non trivial
<zyga> pedronis: RepoFromState(st *state.State) (*interfaces.Repository, error)
<zyga> then work on repo all you want
<pedronis> maybe
<zyga> and then some sort of commit/abort to change state again
<pedronis> seems a bit unrelated to the problem here
<zyga> yes
<pstolowski> pedronis: i mean: when we refresh to a snap with less connections, we remove all connections from repo with RemoveSnap/DisconnectSnap, but they stay intact in conns. Then we re-add snap to repo and reloadConnections so we have them back in repo. back we're left with an extra connection in state (conns), no?
<zyga> just thinking about the reasoning about what reload does
<pstolowski> s/back/but/
<pedronis> pstolowski: they are not back in repo  because you cannot connect things that don't exist
<pedronis> pstolowski: what happens is this:  https://github.com/snapcore/snapd/blob/master/overlord/ifacestate/helpers.go#L311
<pedronis> which maybe is what John hit or not
<pstolowski> pedronis: yes, i understand this. we're left with a stray connection in conns, that's it
<pedronis> we don't have stray connections in repo
<pedronis> as such
<pedronis> or shouldn't
<zyga> we cannot
<pstolowski> it's not ending up in repo
<pstolowski> yes
<zyga> but AFAIK we do keep those in state
<pstolowski> yes
<pstolowski> that's the issue
<pstolowski> and I think it explains those stray connections problem we observed long time ago (which we didn't understand), for which we added that "unknown plug/slot" logic in reload (to ignore them)
<pedronis> well, there's a comment that says we don't know what to do from ago
<pedronis> but yes then we added removeStaleConnections
<pedronis> only on startup
<pedronis> but that considers snaps
<pedronis> not plug/slots
<pedronis> anyway still unclear if this what John hit or something else
<cachio> pedronis, I am creating a new tumbleweed image
<Chipaca> I need to step out, but I just finished the review on connections, I can look at reproducing this from scratch if it'll help
<Chipaca> I'm not sure what's needed, from all the above, though
<cachio> pedronis, I don't know what happened with the previous one but it is not registered anymore
 * Chipaca bbiab
<pedronis> cachio: fascinating
<pedronis> cachio: thanks, I suppose we should a day to see if this one sticks around before turning the tests back on
<pedronis> *should wait
<cachio> pedronis, I see some errors related to lack of permissions in the logs
<cachio> pedronis, perhaps that could be the cause
<cachio> I'll continue researching
<cachio> but what I see is that the image is not in out pool anymore and it was not manually deleted
<pedronis> Chipaca: did you change the name of the plug at some point?
<pedronis> pstolowski: is it on you queue to look at the comments by mvo on #6322 ?
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<mup> PR snapd#6552 opened: ifacestate/tests: fix/improve udev mon test <Created by stolowski> <https://github.com/snapcore/snapd/pull/6552>
<pstolowski> pedronis: ah, thanks, that one went under a radar a bit due to other things, i'll revisit it today
<cachio> pedronis, tumbleweed image is ready again
<pedronis> pstolowski: that test you fixed, the accesses were, you have channels but you the things you access could be mutated by next loop of the monitor
<pedronis> while you were checking them
<pedronis> *were racy
<pstolowski> pedronis: i kinda had a gut feeling about that, thanks
<pedronis> pstolowski: you can try go test -race  , sometimes it useful
<pstolowski> pedronis: will do, thanks!
<pedronis> pstolowski: here on master it detects are race on remInfo for example
<pstolowski> pedronis: right, i can confirm, works great! and doesn't report it anymore on my PR
<pstolowski> cachio: opensuse will need to be enabled back as I disabled it in the PR that landed earlier
<pstolowski> cachio: I'll prepare a PR
<cachio> pstolowski, yes, thanks, I am trying to understand what happened
<mup> PR snapd#6553 opened: tests: enable opensuse tumbleweed back <Created by stolowski> <https://github.com/snapcore/snapd/pull/6553>
<pstolowski> cachio: ^
<pedronis> let's see how it goes, probably we shouldn't merge it until tomorrow
<cachio> pstolowski, pedronis I think the problem is a bug in the google lib
<Chipaca> pedronis: I did change the name of the plug, yes
<pedronis> Chipaca: ok
<Chipaca> pedronis: am i evil
<pedronis> we need to be a bit more clever in that code
<mborzecki> off to pick up the kids
<mup> PR snapd#6551 closed: systemd: decrease the checker counter before unlocking otherwise we can get spurious panics <â  Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6551>
<zyga> pedronis: that feels like a real bug
<zyga> pedronis: I was thinking we should do a .5
<pedronis> zyga: I poked mvo about that
<zyga> and keep the 2.37 branch around as an LTS, with regular security updates and serious bug fixes
<pedronis> ?
<zyga> it's the idea I was talking to mvo about a few times already
<zyga> we move too fast and too slow
<zyga> we should not release to the world on day one of 2.38
<zyga> server should stay behind on 2.37 until we had a few cycles of 2.38 desktop feedback
<pedronis> we cannot do that without tracks
<pedronis> anyway it's probably not a discussion to have this week
<zyga> yeah, we'd have to do something to change how we release
<zyga> but I think it's a good candidate for a starting point
<pedronis> given that mvo is not really around
<pedronis> also not sure that bug is good candidate for that logic, is probably not very likely to hit in the field
<pedronis> often
<Chipaca> zyga: pedronis: listen to the wind! âcï¾a.n*aï½¥rï½¡iï¾e.sï¾
<zyga> it's not that bug
<zyga> is the polishing effort that goes into 2.37
<pedronis> Chipaca: anyway if the plug was renamed, is not a regression, we had this kind of behavior since a long time
<pedronis> probably day 0 of the stuff
<Chipaca> pedronis: a zero-day bug! /o\
 * Chipaca promotes headless chickens
<pedronis> zyga: I'm not particularly against or pro, I'm not sure an LTS as usual fits, also notice that the biggest non security issue with 2.37 was on servers
<pedronis> it was on people CI pipelines
<zyga> we will never prevent all regressions but think we should consider this move as it may fix our credibility on stability where people really seriously depend on snaps for day-to-day work
<zyga> we could also use lts on ubuntu lts desktops
<zyga> and use non-lts on devel releases
<zyga> but those are just ideas, I'd like to raise it as a topic next week when we are back in full set
<pedronis> at some point we will just reduce the pool of testing to the point where we will hit the same issues but later
<Chipaca> zyga: seriously, canarying is for this, or am I missing the point
<pedronis> if anything our issue is that people don't use beta/candidate enough
<zyga> Chipaca: how would canarying prevent what we saw during 2.37?
<Chipaca> zyga: depends on what you mean by "what you saw"
<zyga> Chipaca: the point is simple, now we release almost synchronously all around the planet
<Chipaca> "what we saw" i mean
<pedronis> we try not to really
<zyga> Chipaca: I'd like to change that because we cannot maintain quality for production workloads
<Chipaca> zyga: and how is that _not_ canarying?
<zyga> Chipaca: perhaps I misunderstand but canarying is not a separate release schedule
<zyga> it's just a pool of machines that say yes or no automatically
<zyga> that's not the same in my eyes
<pedronis> anyway it's super unclear that the people that hit our bugs would have not run lts
<Chipaca> zyga: canarying is where, say, 1% of the installed base gets a new revision
<pedronis> and then back to square one
<Chipaca> zyga: if nothing breaks, 5%, 10, â¦ etc
<zyga> Chipaca: breaking 1% of server people IMO too much; I also don't trust in the automated aspect and holding that back; it feels like a good additional system but not a replacement for what LTSes are
<Chipaca> zyga: if something breaks, you rollback
<zyga> Chipaca: I don't disagree on that, just that the set of times you have to roll back burns our credibility and we should avoid  that
<zyga> Chipaca: we should do better in all the ways we can, including in how we release
<zyga> anyway
<zyga> I think we should discuss next week
<zyga> just wanted to explain my point of view over canarying
<pedronis> zyga: as I said, no strong opinion right now, I just have the impression that this will just delay when we see the bugs
<pedronis> and that's it
 * pstolowski off to the doctor
 * zyga breaks and goes for a late walk
<zyga> I'll skip standup today: my update is short, started late after rough night, releasing .4 everywhere;
<zyga> one unusual aspect is that I filed bugs to help include snapd in opensuse
<zyga> that's all
<pedronis> zyga: thx for the update
<mborzecki> re
<Son_Goku> zyga: erk: https://koji.fedoraproject.org/koji/buildinfo?buildID=1217519
<Son_Goku> did you accidentally chop the changelog entry up?
<Son_Goku> Michael's name is missing from the changelog entry and it looks like it was squished with the 2.37.4 release entry
<zyga> There was no changelog entry this time
<Son_Goku> I see one here? https://github.com/snapcore/snapd/commit/af063cbb045a1e232bfb5131683657f78b0cd7ad
<Son_Goku> err. https://github.com/snapcore/snapd/commit/af063cbb045a1e232bfb5131683657f78b0cd7ad#diff-29bff6a81f0669dfd7375cb5e5f13a89
<zyga> Oh? When I looked I saw TBD
<zyga> maybe stale view
<zyga> I took entries from the release page
<Son_Goku> Michael puts them in as part of the tag-release commit
<Son_Goku> so they're usually there
<zyga> I am afk but when I looked at the Fedora spec it had a placeholder only
 * Son_Goku shrugs
<Son_Goku> I'll fix it in dist-git
<Son_Goku> no worries
<zyga> Thanks!
<Son_Goku> zyga, thanks for doing the update stuff anyway :)
<pedronis> Chipaca: pstolowski: standup?
<Chipaca> yep, omw
<zyga> My pleasure :-)
<Son_Goku> zyga, new snapd packages are building
<Chipaca> mborzecki: https://www.youtube.com/watch?v=OZpgnYhzdkI
<Son_Goku> when you get a moment, go ahead and file them as updates after they've been built
<zyga> Yep
<zyga> Iâm heading home slowly
<zyga> Hashtag baby hashtag walk
<cwayne> Hashtag babywalk?
<Chipaca> popey: where can I find an Evan these days? (I know not IRC)
 * cachio afk 15 mins
<cory_fu> sergiusens: Do you have a moment to assist with a snap build issue I'm having?
<pstolowski> re
<pstolowski> pedronis: sorry, i had an eye check today, i mentioned that yesterday during standup
<Chipaca> pstolowski: and via the forum
<zyga> re
<zyga> jdstrand: hello
<zyga> jdstrand: could you please look at a suggestion we got from the suse security team: https://bugzilla.opensuse.org/show_bug.cgi?id=1127366#c3
<sergiusens> cory_fu: what version? Also /join #snapcraft instead
<zyga> the idea is to make snap confine ownership: snap-confine 6750 root:snapd
<zyga> this way you can use snaps if you are a member of the group snapd
<zyga> though I worry about setgid aspect of snap-confine (group root)
<zyga> doing this would speed up entry to suse
<zyga> Pharaoh_Atem: did you run another round of builds
<zyga> Pharaoh_Atem: or shall I before I send stuff to bodhi?
<zyga> pedronis: CC on the message to jdstrand
<jdstrand> zyga: I'm not opposed to the idea, though it may complicate the priv-dropping code in snap-confine somewhat. it will definitely cause usability issues on suse since only people in the snapd group would be able to use snaps
<jdstrand> pedronis: ^
<zyga> jdstrand: right
<zyga> jdstrand: I understand the plan is to use this to simplify the review
<zyga> jdstrand: and ship snapd in kubic OS by suse
<zyga> jdstrand: where the users will have the permission by default
<zyga> jdstrand: can you explain how it would complicate the priv dropping code?
<pedronis> jdstrand: don't we have also issues with reexec and the fact that we have one core
<pedronis> respectevely snapd snap
<jdstrand> zyga: it would have to be reviewed-- it may not, but it may. I recall we very precisely drop uid and gid
<zyga> yeah
<jdstrand> s/drop/drop, raise, drop/
<zyga> I can attempt that to see what happens (just chmod/chown it on my system)
<zyga> I suspect we may need a patch on snap-run
<zyga> to say "please add the users to snapd group" or something alike
<zyga> and some changes to snap-confine (there are probably three places that manipulate uid thre)
<zyga> *there
<pedronis> jdstrand: my question how can we have snap-confine have different perms on different distros while keeping one core snap
<zyga> pedronis: I think we are not using snap-confine from core/snapd on suse / fedora
<zyga> so perhaps in those places as a special case?
<jdstrand> pedronis: it wouldn't work in the reexec case
<pedronis> jdstrand: but then it means people can circumvent that check by turning reexec on
<jdstrand> I mean, it could theoretically work if you get the same gid for snapd in all the distros and your distro packaging adds the group with that gid and the snap also uses that gid, but yikes, hard to coordinate
<jdstrand> pe
<jdstrand> pedronis: yes
<pedronis> we would need to hardwire somehow no reexec
<zyga> I think kubic would not allow reexec,
<zyga> pedronis: we do that today
<zyga> there's no reexec on suse
<jdstrand> zyga: but a user could set the env var, certainly
<pedronis> I thought we always respected the env var
<zyga> jdstrand: it is ignored on suse
<zyga> I ... don't know
<pedronis> heh
<zyga> worth checking :)
<zyga> but I think it does nothing
<zyga> because it doesn't function
<jdstrand> interesting
<zyga> things just don't work in many ways still
<zyga> different paths etc
<zyga> I'd love to be able to turn it on
<zyga> have a default that distros agree with
<zyga> but a knob the user can toggle
<zyga> it's just that we're not there yet
<pedronis> but we they ask for this
<pedronis> we cannot turn it on
<pedronis> the two things feels a bit incompatible
<jdstrand> snapd could disable reexec if the sgid bit was set on snap-confile
<zyga> I agree
<jdstrand> snap-confine
<zyga> jdstrand: I would have it as a first class concept: no reexec mode set at build time
<zyga> then there's simpler way to control this
<zyga> it's just off
<zyga> though for now I think that's premature, we should just check what happens with the different group and see if we'd be happy with that mode during review (and land any extra changes before this goes in)
<zyga> Pharaoh_Atem: updates posted to bodhi :)
<zyga> you have to tell me one day how to do sets so that all the three updates can be in one big set
<Pharaoh_Atem> zyga: it's not a thing sadly
<Pharaoh_Atem> when we moved from Bodhi 1.0 to Bodhi 2.0, the ability to push a single update across multiple distributions went away
<Pharaoh_Atem> or are you referring to a set of packages per update?
<zyga> Pharaoh_Atem: ah, I confused that
<zyga> I thought it was a thing
<zyga> but that's okay
<Pharaoh_Atem> anyway, I gave karma to everything
<mup> PR snapcraft#2491 opened: Fix and enable multipass spread tests <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2491>
<Pharaoh_Atem> so it'll push out in the next 48 hours
<zyga> Pharaoh_Atem: thank you
<zyga> Pharaoh_Atem: say, what about manjaro
<zyga> should we do something there?
<Pharaoh_Atem> hm?
<zyga> is snapd in manjaro?
<Pharaoh_Atem> I believe so
<zyga> do you have any contacts there?
<zyga> someone we could talk to in case we need to release urgently?
<Pharaoh_Atem> nope
<Pharaoh_Atem> I don't know anyone in Manjaro anymore
<zyga> ok,  thank you
<zyga> we're doing our best where we can
<zyga> I will work on suse concept for some more time and then EOD
<Pharaoh_Atem> if it works out with the reworked packaging for SUSE, we can look at integrating those changes into the Fedora packaging and tweaking it to build for SUSE distributions too
<zyga> Pharaoh_Atem: I already started :)
<zyga> Pharaoh_Atem: I need to finish selinux support in snapd.k
<zyga> .mk
<zyga> it's not a priority for me  this week but I expect to switch more and more packaging over to it
<Pharaoh_Atem> be careful, though
<Pharaoh_Atem> I still need to be able to build it everywhere
<zyga> it has not lost any features
<zyga> it should really be just less repetition without any other effects
<Pharaoh_Atem> and having a way to ensure things like the golang build flags are passed in are important
<zyga> yep, that's part of why this is not ready yet
<zyga> I'm just saying it's important for me to get this done to simplify packaging work
<Pharaoh_Atem> sure
<Pharaoh_Atem> I'd like it to be simpler too
<Pharaoh_Atem> it's a big part of why I hate Go so much :/
 * zyga EODs
<mwhudson> pedronis: thanks for the answers about the fake store
<mwhudson> hm
<mwhudson> snap seeding appears to be completely hung in this image
<mwhudson> i've probably broken something but how can i diagnose?
<zyga> mwhudson: set SNAPD_DEBUG=1 in snapd.service override, hack the image to have serial tty,
<mwhudson> i have a tty
<mwhudson> and i think that env var is set
<mwhudson> yeah it is
<mwhudson> it is complaining about not being able to find a snap-declaration
<mwhudson> ah whoops killed vm by mistake
<zyga> well, good luck :)
<tylerscheuble> Hey, I'm trying to build a snap with a custom plugin, and I'm getting a "/bin/sh: 29: snapcraftctl: not found" on the pulling step. snapcraftctl isn't in the source of any of my files.
<tylerscheuble> Any ideas? Thanks
<mwhudson> ah the fakestore can make a declaration too
<mwhudson> omg it lives
<RalphBa> hi all
<RalphBa> short question, is there an equivalent to flatpak's --user?
<RalphBa> for unpriviliged and formost userlocal installations
<RalphBa> so installed into their home, system state stays unalterd
<mwhudson> now just the api/v1/snaps/auth/nonces thing
<roadmr> RalphBa: no :) (short answer)
<RalphBa> ok, and how is an app behaving when used by 2 users?
<RalphBa> say two users use nextcloud snap
<RalphBa> nextcloud-client
<kyrofa> RalphBa, no differently than the deb installed once and used by both users. Settings are stored in a user-specific area
<RalphBa> kyrofa: so all the data downloaded from nextcloud server is stored somewhere in /home/user directory? Where?
<kyrofa> RalphBa, you said nextcloud-client, perhaps we're misunderstanding each other
<RalphBa> the snap nextcloud-client available in store
<RalphBa> I can access its data via the current directory
<kyrofa> But yes-- the nextcloud client syncs stuff from client to server, and its settings are stored per-user. Where the stuff it syncs is located shouldn't really matter
<RalphBa> but where is it stored?`and why is it available via /snap
<RalphBa> it matters because I have multiple paritions for multiple stuff
<RalphBa> I have a backup concept
<RalphBa> I need to know where stuff is
<kyrofa> RalphBa, what I mean to say is: where stuff syncs is up to the user(s). It has no bearing on whether or not multiple users can use it
<RalphBa> default setting of that snap is to store data in some shady mount thing
<RalphBa> how said, I access that data via /snap/.../current
<kyrofa> The snap itself is installed into /snap like any other snap. That's not a shady mount thing, it's a squashfs image. That's what a snap is
<kyrofa> It doesn't store anything there though. It's read-only
<kyrofa> It just executes from there
<RalphBa> Nextcloud downloadded 3 GB, the squashfs image had 87MB
<kyrofa> Just like, if it was a deb, it'd probably be in /usr/bin/
<RalphBa> hm...
<RalphBa> this was the path ~/snap/nextcloud-client/current/Nextcloud o /snap/nextcloud-client/current/Nextcloud
<RalphBa> and also /...
<RalphBa> the symlink pointed to snap/nextcloud-client/10
<RalphBa> which was the mountpoint of that .snap file
<kyrofa> /snap/nextcloud-client/* is the snap installation path. ~/snap/nextcloud-client/current/ is the user-specific path where it might store user-specific settings (and yes, it can sync there as well, although I don't recommend it)
<RalphBa> ok, but where is that user specific stuff?
<RalphBa> if I want to put that file on a tape, where to find it?
<kyrofa> Uh. Which file?
<RalphBa> "user-specific path where it might store user-specific settings" << the file or the files in there
<RalphBa> in the current directory
<RalphBa> ok, where is a good technical documentation?
<kyrofa> Anything in ~/snap/nextcloud-client/current/ falls under that category... I'm not quite sure what you're looking for
<RalphBa> ~/snap/nextcloud-client/current/ is just a symlink to a mount point
<kyrofa> No, it's a symlink to a directory
<kyrofa> /snap/nextcloud-client/current IS a symlink to a mountpoint though
<kyrofa> The one in $HOME is different
<RalphBa> hm
<RalphBa> oh
<RalphBa> ok, got it
<RalphBa> that was the point, I thought ~/snap/.../10 is a mount point
<RalphBa> seems not to be the case
<kyrofa> Indeed not, perhaps that explains both of our confusion :)
<RalphBa> :-D thanks for that one
<RalphBa> just one to come, can I move /snap to /data/snap and symlink it?
<kyrofa> Snaps have a few defined places where they can always write-- that's one of them (SNAP_USER_DATA). This might enlighten you further: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data/762405#762405
<kyrofa> I doubt it, snapd will want to be able to update it etc.
<RalphBa> hmmm... I really would like to get the installed stuff out of the base system
<RalphBa> deb for system stuff, snap and flatpak for application stuff
<RalphBa> might it tolerate /snap beeing an own mount point?
<kyrofa> RalphBa, I'm afraid I don't know, that's a question for the snapd devs, who are all probably gone for the day. I suggest coming back earlier tomorrow to ask
<mwhudson> hmm so now when i try to refresh from the fake store i get a complaint about mismatched revisions
<mwhudson> the assertion says rev 2 but somehow the snap has revision 1?
<mwhudson> but i don't understand how a snap has a revision that is different from what the assertion says...
#snappy 2019-03-01
<mborzecki> morning
<zyga> Hello
<mborzecki> zyga: hey
<zyga> Hey :-)
<zyga> Thank you for the archlinux update
<mborzecki> zyga: wa debian updated too?
<zyga> Yes
<mborzecki> heh go linters stopped working when i switched to 1.12
<pstolowski> morning
<zyga> Hey
<mup> PR snapd#6487 closed: interfaces: add new intel-mei interface <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6487>
<mborzecki> pstolowski: hey hey
<zyga> 2nd coffee
<mup> PR snapd#6554 opened: interfaces/intel-mei: small follow up tweaks <Created by pedronis> <https://github.com/snapcore/snapd/pull/6554>
<zyga> plan for this weekend:
<zyga> sleeeeep
<zyga> and bike ride
<zyga> pedronis: we are all good on 2.37.4 so far
<zyga> pedronis: I will work with cachio and mvo next week on ubuntu release and bug gardening
<zyga> let's get back to branches and patches
<mborzecki> heh, looks like master will be failing with arch due to go1.12 update
<zyga> what's the status?
<greyback> hi folks, can I get another pair of eyes on https://github.com/snapcore/snapd/pull/6281 please? I've a jamie +1 already
<zyga> certainly
<mup> PR #6281: interfaces: add Multipass-support interface <Created by gerboland> <https://github.com/snapcore/snapd/pull/6281>
<zyga> looking
<mborzecki> zyga: i'll open a PR in a bit
<zyga> greyback: I'm going through the review again
<pstolowski> pedronis: hey, i'm addressing mvo's comment to #6322 re a new helper; what do you think about applyChanges for its name? https://paste.ubuntu.com/p/Ngv3yyR6qv/
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<zyga> greyback: as a general comment please ensure that all questions are answered
<zyga> greyback: even if the answer is +1 or done or "no longer applicable"
<greyback> zyga: ah ok
<zyga> this helps when there are multiple comments
<zyga> it is easier to see the status this way
<pedronis> pstolowski: looks ok, I would swap its arguments though
<pstolowski> pedronis: ok
<zyga> greyback: I'm sure it is fine, I'm sorry for asking for some responses or clarifications
<zyga> greyback: it helps me since I was not involved with the review and design as deeply as Jamie was
<greyback> zyga: not at all
<greyback> happy to clarify anything I can
<zyga> I will read the full diff enxt
<zyga> *next
<mup> PR snapd#6555 opened: tests/main/high-user-handling: fix the test for Go 1.12 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6555>
<pedronis> degville: thanks for looking at my new interface doc,  are you at the office? did John joined in the end or not?
<degville> pedronis: yep, I'm in the office. John isn't here.
<pedronis> degville: thx
<zyga> greyback: done
<zyga> pstolowski: hey, the description on https://github.com/snapcore/snapd/pull/6552 has some unusual formatting, is that intentional?
<mup> PR #6552: ifacestate/tests: fix/improve udev mon test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6552>
<mborzecki> can we land #6555 ?
<mup> PR #6555: tests/main/high-user-handling: fix the test for Go 1.12 <Simple ð> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6555>
<zyga> yes
<zyga> lets
<zyga> pedronis: ^
<mborzecki> or pstolowski maybe ^^ ?
<pedronis> merged
<mup> PR snapd#6555 closed: tests/main/high-user-handling: fix the test for Go 1.12 <Simple ð> <â  Critical> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6555>
<mborzecki> pedronis: thanks!
<pedronis> mborzecki: it was not clear from the descr that it was for a failing test though and not local to some people
<zyga> mborzecki, pedronis: some idea on https://github.com/snapcore/snapd/pull/6485#pullrequestreview-209527174
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<mborzecki> zyga: yeah, that's what we discussed with mvo
<zyga> ah, that's great
<zyga> I think it is an easy win for some performance
<zyga> ah, I see now
<zyga> +1 on that :)
<zyga> pedronis: do you think you will have some time to look at https://github.com/snapcore/snapd/pull/6502 today?
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<mborzecki> zyga: another win would be not forking to run snap-seccomp, but that probably has more constraints
<zyga> yeah
<zyga> but that's more complex
<zyga> I have some ideas
<zyga> but not for a minor change
<pedronis> zyga: not today,  monday, I prioritized a bit 2.38 stuff
<zyga> sounds good, thank you
<zyga> I'm going through reviews
<pedronis> (and long outstanding store stuff)
<zyga> understood
<zyga> https://github.com/snapcore/snapd/pull/6482/files seems like a low hanging fruit
<mup> PR #6482: [RFC] cmd/snap: make 'snap list' show disabled snaps dimmed <Created by chipaca> <https://github.com/snapcore/snapd/pull/6482>
<pedronis> I'm very undecided about it
<pedronis> atm
<zyga> should we mark it as blocked?
<pedronis> it's cute but then is another thing that we need to consistently everywhere
<pedronis> I'm closing it for now with a comment
<mup> PR snapd#6482 closed: [RFC] cmd/snap: make 'snap list' show disabled snaps dimmed <Created by chipaca> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6482>
<mup> PR snapd#6548 closed: release: snapd 2.37.4 <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6548>
<mborzecki> Chipaca is off today, isn'the?
<zyga> I think so
<zyga> I think I should burn my holidays
<mborzecki> pedronis: i've updated the snap connections branch
<mborzecki> ok, now the bpf branch
<mborzecki> there should be a button on github that'd allow merging master to a PR
<zyga> yeah
<zyga> or rebase
<pedronis> mborzecki: I need to comment on the plan there (the bpf branch)
<mborzecki> pedronis: ok
<pedronis> mborzecki: done, asked a couple of questions on the plan
<pedronis> mborzecki: oops, sorry I should have commented before,  we probably want printing the deprecation warning in a separate PR (to go with early 2.39, not 2.38)
<mborzecki> pedronis: ok, i'll revert the patch then
<pstolowski> zyga: thanks for looking at hotplug test PR!
<zyga> the greengrass PR is complex
<zyga> but almost done
<pedronis> mborzecki: thanks for reverting that bit, feel free to propose a PR with just it
<pstolowski> zyga: re hotplug test, is there a better way than 'test -w ...' than doesn't require real writes to serial port?
<zyga> pstolowski: I doubt it
<pstolowski> and that would fail on cgroup
<zyga> pstolowski: maybe reverse the test
<zyga> pstolowski: write when you expect it to fail
<zyga> and look for faiure
<zyga> *failure
<zyga> *failure
<pstolowski> zyga: would be better to test positive scenario as well. i think qemu serial port allows read/writes, need to investigate
<zyga> I'm sure they do
<zyga> perhaps the output goes to a file on the host?
<mborzecki> off to pick up the kids
<pstolowski> zyga: yeah i think you can redirect it wherever you want
<mup> PR snapd#6556 opened: cmd/snap: hide 'interfaces' command, show deprecation notice <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6556>
<zyga> brb, tea time ahead of the standup
<degville> pedronis / zyga: I'm not going to be able to make it to the standup - still in discussions n the office.
<pedronis> degville: ok
<zyga> degville: ack thank you
<zyga> pedronis: are you able to attend the standup today?
<zyga> mborzecki: please cherry pick the fix to 2.37 in case we need more releases, easier while we remember about the issue
<mup> PR snapd#6557 opened: tests/main/high-user-handling: fix the test for Go 1.12 (2.37) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6557>
<mborzecki> zyga: ^^
<zyga> thank you
<zyga> mborzecki: I started looking at the selinux branch
<zyga> I will review it carefully but I need to take the dog out first because it's very late already
<zyga> mborzecki: I left a few comments
<zyga> two small actions: cleanup functions please
<zyga> I'll be back in 30-40 minutes
<mborzecki> zyga: thanks, will take a look
<zyga> pedronis: I didn't give my update but I was mainly doing reviews, forum and yesterday release work
<zyga> pedronis: the issue with personal files is interesting, it's just a hidden assumption, I will have some more thoughts on the forum about that
<pedronis> zyga: sorry
<pedronis> zyga: thanks
<pedronis> zyga: I created the card
 * cachio afk
<jdstrand> pedronis and zyga: responded to/addressed all feedback in https://github.com/snapcore/snapd/pull/6549, but please see my comments wrt 2.38
<mup> PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549>
<pstolowski> mborzecki: do you have a moment? would be nice to land https://github.com/snapcore/snapd/pull/6552
<mup> PR #6552: ifacestate/tests: fix/improve udev mon test <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6552>
<mup> PR snapd#6281 closed: interfaces: add multipass-support interface <Created by gerboland> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6281>
 * mborzecki off to the swimming pool
<mup> PR snapd#6552 closed: ifacestate/tests: fix/improve udev mon test <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6552>
<zyga> I need to take a nap see you later
<kyrofa> roadmr, I got a "Task 40048685-93b9-49b7-96b6-83dabd1d83bb failed" on a nextcloud snap (that's the error-- no review issues, just a job failure) that causes all other uploads to fail with  "Waiting for previous upload(s) to complete their review process". That really sucks
<kyrofa> Jobs are going to fail sometimes. I get it. But it shouldn't require manual intervention from the snap dev to get back up and running
<roadmr> kyrofa: which manual intervention did you need to do?
<roadmr> kyrofa: ah, "reject and remove from review queue" probably
<kyrofa> Yeah, and re-spin all the builds that failed to upload
<mup> PR core#103 opened: hooks: apt warning should return an error <Created by townsend2010> <https://github.com/snapcore/core/pull/103>
 * cachio EOW
<lborda> hey I built a simple reproducer for a bug while trying to create a snap for cdk collector logs... have you ever experienced this issue ? https://github.com/lborda/snap-bug/issues/1
<mup> PR snapd#6554 closed: interfaces/intel-mei: small follow up tweaks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6554>
<mup> PR snapd#6494 closed: interfaces/builtin/udev: add spec to disable udev + device cgroup <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6494>
<mup> PR snapcraft#2493 opened: Specify default expiration time for export-login <Created by felicianotech> <https://github.com/snapcore/snapcraft/pull/2493>
#snappy 2019-03-02
<jdstrand> joedborg: hey, can you turn off autouploads for winetricks until you request classic in the forum (see your inbox). thanks!
<joedborg> Will do when I have my laptop jdstrand
<jdstrand> joedborg: thanks
<om26er> can I put my snapcraft yaml in a different directory and point `snapcraft` to build using that ?
<om26er> anything that's not snap/snapcraft.yaml .snapcraft.yaml or snapcraft.yaml on the root of the project
#snappy 2020-02-24
<zyga> Hey
<zyga> Back to school day
<mborzecki> morning
<zyga> We need to land the critical PR
<mborzecki> zyga: hey, which one?
<zyga> Stuff is still broken, eh
<zyga> Last one
<zyga> 8178
<mborzecki> uhh
<mborzecki> zyga: that's why pushing snapd to store failed on friday?
<zyga> re
<zyga> checking what failed
<zyga> yes
<zyga> sucks, eh?
<zyga> I saw some failover failures yesterday
<zyga> and eh
<zyga> fu**
<zyga> https://www.irccloud.com/pastebin/RwhTm8UI/
<mborzecki> fun? :)
<zyga> where do we get foo frm?
<zyga> crap from other test?
<mborzecki> yeah, tha'd be my first guess
<zyga> pushed a fix
<mborzecki> there's security-private-tmp test
<mborzecki> and it ran before
<zyga> mmm
<zyga> I'll get coffee and fix this properly
<mborzecki> zyga: maybe as a workaround, we could also take down the setgid flag in postinst?
<zyga> hmm?
<zyga> postinst of the deb?
<zyga> that would ruin the snap, no?
<zyga> as in, that would cause the snap to be g-s
<zyga> unless I don't understand how it's made
<zyga> in either case, it's all temporary
<zyga> we'll fix review tools today
<zyga> deploy in a day or two
<mborzecki> duh, yeah, that may produce a different result for deb and snap
<mborzecki> hm looks like the snap is built by just extrating snapd, so we'd have to tweak the bit there too
<mborzecki> but that would break review-tools again :/
<zyga> mborzecki: I didn't test-build the deb because i didn't feel comfortable guessing how it's really built
<zyga> mborzecki: but the deb, for sure, has no g+s anymore
<zyga> er
<zyga> *has*
<zyga> so with some luck it will pass
<zyga> brb
<mup> PR snapd#8179 opened: interfaces: power control interface <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8179>
<zyga> re
<zyga> mborzecki: can you review 8178
<zyga> I'll land with one review
<mup> PR snapd#8178 closed: packaging: work around review-tools and snap-confine <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8178>
<mup> PR snapd#8180 opened: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>
<zyga> mborzecki: ^ quick follow-up
<zyga> hey mvo
<zyga> good morning
<zyga> mvo: FYI https://github.com/snapcore/snapd/pull/8178
<mup> PR #8178: packaging: work around review-tools and snap-confine <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8178>
<mvo> hey zyga
<mvo> zyga: looking
<pstolowski> morning
<zyga> hey Pawel :)
<zyga> mvo: this was pre-approved but I wanted to let you know it landed
<zyga> mvo: it allows core/snapd snaps to be published again
<mborzecki> mvo: pstolowski: hey
<mvo> hey pstolowski and mborzecki
<mvo> zyga: yeah, saw the mails over the weekend
<zyga> failover still fails
<mvo> zyga: do you know if jamie is aware that the review tools need fixing?
<zyga> yes
<mup> PR snapd#8136 closed: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8136>
<pedronis> mvo: yes, he said he was working on it
<zyga> we talked (Jamie / Pedronis / me) about it together
<mvo> cool
<pstolowski> mvo: hey! it occured to me over the weekend that snap-pressed could be made a classic snap, which is what you probably meant when you suggested making it a snap :)
<zyga> snapd-failover failure on top of current master https://www.irccloud.com/pastebin/pxEx4fth/
<mvo> pstolowski: yeah, that will work
<mup> PR snapd#8168 closed: snapcraft.yaml: add comments, rename snapd part to snapd-deb <Simple ð> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8168>
<pstolowski> mvo: good, i'll prep a PR for that (a snapcraft.yaml inside cmd/snap-presseed?) and will make a quick test
<pedronis> pstolowski: do we know it's needed? I'm probably missing something
<zyga> hey pedronis, good morning :)
<pstolowski> pedronis: the only alternative afaict is to use a ppa right now, until a new deb lands in the distro
<mvo> pstolowski: it's probably ok to wait for them for feedback first, their build setup is special and may not be suitable for snaps (I honestly don't know). so might be worth to double check before we invest time in this
<mborzecki> btw. trying to find out why spotify core dumps on arch reminded me of the missing feature of having access to debug symbols, that we discussed but never got down to working on it
<pedronis> mborzecki: there is been work on the snapcraft side on that
<pedronis> we actually need to play with it
<pedronis> but not much time atm
<pstolowski> mvo: sure
<mborzecki> pedronis: interesting, is there some info about the snapcraft bits?
<pedronis> mborzecki: yes
<pedronis> mborzecki: I can give some pointers in the standup
<mborzecki> pedronis: please do, thanks!
<pedronis> mvo: I made a comment on #8100, does #8142 need a master merge?
<mup> PR #8100: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>
<mup> PR #8142: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <https://github.com/snapcore/snapd/pull/8142>
<pedronis> mborzecki: did you see my remark on #6708 ?
<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> pstolowski: are you waiting on reviews from me atm ?
<pstolowski> pedronis: no. thanks for asking!
<pedronis> mborzecki: when you have a second could you push master into #8147 ?
<mup> PR #8147: cmd/snap-bootstrap: verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8147>
<mborzecki> pedronis: sure
<pedronis> thx
<mvo> pedronis: thanks, will followup, 8142 probably needs a master merge
<mborzecki> spread tests should be fixed now in #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> mvo: pedronis: the recovery chooser binary is /usr/lib/snapd/snap-recovery-chooser, does that sound ok? i want to open a PR to subiquity with changes to console-conf-wrapper
<ackk> hi, how do I remove a broken (try) snap? it complains because it doesn't find the .service file
<ackk> https://paste.ubuntu.com/p/r4H46ycwVq/ is what I get
<ackk> oh, it seems umounting the snap before trying to remove it worked
<mvo> mborzecki: sorry for the delay, was in a meeting. the name sounds good to me
<mvo> ackk: thanks, this feels a bit like a bug on our side, we need to be robust against failures here
<ackk> mvo, TBF this was a "snap try" whose prime dir ended up being removed/overwritten, so kinda of an edge case
<mvo> ackk: agreed and yet we should handle it better :) but agreed on the edge-case so not that high of a priority right now
<mvo> ackk: out of curiosity, did you guys made progress on the run-away supervisor processes?
<ackk> mvo, sort of. BjornT experienced something similar installing maas on a rpi4. my gut feeling is that if for some reason there's a high cpu usage and everything slows down, supervisord times out on starting processes, kills and restarts them, making things worse
<ackk> mvo, in my case because of squashfuse using all cpu, on the rpi because of limited cpu power
<ackk> mvo, there doesn't seem to be any error in logs in these cases, just processes being started and killed
<mup> PR snapd#8181 opened: packaging: revert "work around review-tools and snap-confine" <Skip spread> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8181>
<mvo> ackk: woah, ok
<zyga> mvo: https://github.com/snapcore/snapd/pull/8181 has two patches, only one should be reverted (the other will conflict once https://github.com/snapcore/snapd/pull/8180 lands
<mup> PR #8181: packaging: revert "work around review-tools and snap-confine" <Skip spread> <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8181>
<mup> PR #8180: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>
<mborzecki> yay, opened https://github.com/CanonicalLtd/subiquity/pull/636
<mup> PR CanonicalLtd/subiquity#636: bin/console-conf-wrapper: detect whether snapd recovery chooser should run <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/636>
<zyga> mborzecki: looking :)
<mborzecki> i'm thinking that maybe w should have a list of ttys in snapd that the chooser can be invoked on, like /etc/securetty, this can easily be gadget dependent
<zyga> mborzecki: looks innocent enough :)
<mborzecki> yeah, it does ;)
<mvo> zyga: aha, thanks, feel free to edit and force push, in a meeting righ tnow
<zyga> mvo: ack, will do
<mborzecki> /var/lib/snapd/choosertty
<mborzecki> again soemthing with jenkins spread test?
<zyga> mborzecki: I saw that today
<zyga> their repo times out
<zyga> eh
<mup> PR core20#23 opened: hooks: ensure console-conf@ is started after snapd.recovery-chooser-trigger.service <Created by bboozzoo> <https://github.com/snapcore/core20/pull/23>
<zyga> mborzecki: question
<zyga> what happens if that service is disabled?
<zyga> namely if you systemctl disable snapd.recovery-chooser-trigger.service
<zyga> how does that affect dependency chain?
<mborzecki> zyga: nothing, it's only Before/After ordering, not Requires
<zyga> aaah
<zyga> that's great
<zyga> ok
<zyga> mborzecki: wild west idea: a tool that reads from a google spreadsheet, allowing us to put a marker in a specific cell that means jenkins test is skipped
<zyga> or that arch or tumbleweed are broken today
<zyga> etc
<zyga> mborzecki: the sheet could be ACLd and locked
<mborzecki> zyga: we have s3 like storage for out gcp now, we could easily upload a list of disabled tests there, download it to the host, and skip at runtime, then track which run skipped what
<zyga> mborzecki: spreadsheets are way easier to work with
<zyga> mborzecki: and I bet the ACLs on entire file is not as nice as per-cell ACL
<mborzecki> idk, i prefer plain text files :P
<zyga> mborzecki: even changing files in s3-like thing is hard
<zyga> and the other thing is self-documenting, you open a URL to a specific cell
<zyga> and if you can, you can edit it
<zyga> easy
<zyga> core 20 setup is sloooooooow
<mup> PR snapd#8133 closed: cmd/snap-confine: deny snap-confine to load nss libs <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8133>
<mup> PR snapd#8182 opened: build: enable type: snapd <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8182>
<pedronis> zyga: we'll start taking care of some todos that should improve that a bit this week
<zyga> that's good to know
<mborzecki> #8176 is simple and green
<mup> PR #8176: tests: adding amazon linux to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8176>
<zyga> brb, cold and somewhat hungry as a result
<zyga> re
<zyga> hot tea :)
<zyga> did anyone debug why tests/go.{mod,sum} show up
<zyga> kids back from school
<zyga> also school is back
<zyga> whee
<zyga> :)
<mborzecki> duh, wonder why nothing is printed out with termbox-go controlling ttyS0
<zyga> mborzecki: maybe it establishes exclusive control over tty?
<zyga> there's an ioctl for it
<zyga> I used it once
<zyga> https://github.com/snapcore/core-build/blob/master/initramfs/testing/init.c#L212
<pedronis> mborzecki: some comments and questions on 8156
<mborzecki> zyga: hm so input works, i'm loogginmg when keys are pressed and so on, but the output does not work
<zyga> that's odd
<cmatsuoka> zyga: are you aware of any mount flag that disables directories bind mounts but won't affect regular file bind mounts?
<zyga> cmatsuoka: no, because that's not a property of a mount point
<zyga> cmatsuoka: in other words, that's not possible AFAIK
<cmatsuoka> zyga: I'm having this really weird bug where I can't bind mount directories but files work normally
<cmatsuoka> I mean, bind mounting files work, but directories fail silently
<zyga> cmatsuoka: can you tell me more please
<zyga> cmatsuoka: also /proc/self/mountinfo would help
<cmatsuoka> zyga: ok, so it's a long story. I'll start with the symptoms
<zyga> cmatsuoka: sure
<zyga> cmatsuoka: do you want to HO or is here find?
<zyga> *fine
<cmatsuoka> in a HO it will be easier to explain
<zyga> sure
<cmatsuoka> I'm in the SU room
<zyga> one sec
<pedronis> cmatsuoka: hasn't xnox made progress (see uc20)
<xnox> cmatsuoka:  all i can see is that without a valid /etc/crypttab things that require writable mount and bind to it, all get torn down by systemd, because it says dev-mapper-ubuntu-data.device? i don't need that, stop it now.
<xnox> cmatsuoka:  i'm now redoing to provide a valid /etc/crypttab in the mounted system, to ensure the post-switch-root systemd has left and right half of the brain connected together.
<zyga> for reference, we discussed some ideas, including unbindable, and will look at mountinfo data to try to understand what is going on
<cmatsuoka> xnox: thanks, I think the most interesting piece of information is that switching from a point as late as initrd-cleanup still works
<zyga> snap session agent socket activation failed
<zyga> https://www.irccloud.com/pastebin/8UEOWyMx/
<zyga> jamesh: ^
<xnox> cmatsuoka:  yes, it's the systemd from the rootfs that gets confused.
<xnox> cmatsuoka:  you can boot with init=/bin/bash => such that switch-root pivots to a bash shell, where everything still looks sane
<cmatsuoka> xnox: will try that
<pedronis> mvo: what is happenign here:  https://api.travis-ci.org/v3/job/654356068/log.txt there's a SKIP_GOFMT=1 but an error about go fmt ??
<zyga> pedronis: it runs gofmt
<zyga> and ignores the result
<zyga> that's how I remember it
<zyga> (it's kind of weird)
<zyga> pedronis: it really failed on FAIL: overlord_test.go:694: overlordSuite.TestEnsureLoopPruneAbortsOld
<zyga> pedronis: roughly before the middle of the test log
<pedronis> ah
<pedronis> I was confused
<pedronis> pstolowski: https://api.travis-ci.org/v3/job/654356068/log.txt
<zyga> yeah, we should remove that gofmt thing on SKIP_GOFMT
<zyga> it's silly
<zyga> pedronis: I'll do it later today
 * zyga looks outside at endless rain
<zyga> good thing I have tea :)
<cmatsuoka> xnox: confirmed, it works just after switch root and before init
<mborzecki> zyga: what about SKIP_GOFMT?
<zyga> mborzecki: it's really RUN_GOFMT_AND_NOT_FAIL_LOL=1
<mborzecki> well, that's its purpose
<zyga> mborzecki: it's a weird purpose
<zyga> mborzecki: it's always noise
<zyga> mborzecki: why would you want to look at gofmt from incompatible version of go?
<mborzecki> zyga: not sure i follow
<zyga> mborzecki: we set SKIP_GOFMT=1 when we know the result is garbage anyway
<mborzecki> zyga: the problem is that travis builds and cheks with go 1.10, which i don't use locally
<zyga> mborzecki: when it is equal to 1 then we _run_ gofmt, print a bunch of diff, and not fail on that
<mborzecki> zyga: right, so that you know what's wrong wrt. 1.10 that travis uses
<zyga> mborzecki: are you saying it's always wrong? :)
<mborzecki> zyga: if go didn't break the formatting in 1.11 we wouldn't have the problem, but they did
<zyga> mborzecki: anyway, if you look at what the code does now
<zyga> mborzecki: I think you will agree that what we do is silly
<zyga> mborzecki: we do run the gofmt check with the right go
<zyga> mborzecki: (in other places)
<zyga> mborzecki: but we always run and print useless diff regardless of anyone asking for it
<pedronis> as data point I was confused by it and missed the real issue initially
<mborzecki> zyga: but other palces isn't travis unit tests job , maybe it shouldn't check gofmt then
<zyga> mborzecki: there's a task that checks gofmt with the right version
<zyga> mborzecki: it's not the quick-and-early check
<zyga> mborzecki: the quick and early check does run gofmt verification, wasting time, producing confusion and _ignores_ the result because go version mismatch
<zyga> mborzecki: that's the problem
<pedronis> mmh, this was not the early check
<pedronis> this was unit/go
<pedronis> afaict
<zyga> pedronis: right
<zyga> pedronis: because that's the same piece of code
<zyga> it runs twice
<mborzecki> zyga: because we run unit tests twice
<zyga> I think we should just not run gofmt check at all if SKIP_GOFMT is set
<zyga> mborzecki: correct
<mborzecki> zyga: once in travis, then antoher one in spread, the 2nd may run on a new distro where go isn't 1.10
<zyga> mborzecki: that's correct too
<mborzecki> zyga: so shoudl the early check fail, you get a diff of the code wrt. 1.10, and you know what to fix or reformat
<zyga> mborzecki: that's not what I'm saying
<zyga> mborzecki: unless I'm confused: <zyga> I think we should just not run gofmt check at all if SKIP_GOFMT is set
<zyga> mborzecki: this is sufficient to keep checking exactly what we check now and reduce the confusing diff intermixed with actually relevant unit test failures
<zyga> jdstrand: hey
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/8123 is ready for a quick re-review
<mborzecki> zyga: ah ok, so yeah, skip the whole thing then
<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> jdstrand: please check my comments but I think you will find that it implements what you outlined
<jdstrand> zyga: I saw
<jdstrand> well, I saw it was ready for re-review
<zyga> jdstrand: I didn't implement the helper that makes the permissions side more understandable
<jdstrand> I haven't gone through it yet
<ijohnson> guten tag friends :-)
<zyga> jdstrand: but you indicated that as optional for now
<jdstrand> hey ijohnson :)
<ijohnson> hey jdstrand
<zyga> jdstrand: I'll get back to transient scope pr now
<zyga> ijohnson: halo :)
<ijohnson> how are you zyga? have a good weekend?
<zyga> ijohnson: pretty good, yeah
<zyga> ijohnson: winter holidays are over so kids are back to order ;)
<ijohnson> nice, it got really warm here over the weekend (like 5-10 C I think) and we had a bbq at my mom's house, and I found some paczki to share for dessert!
<zyga> ijohnson: oh, nice :)
<zyga> ijohnson: what's the flavor?
<ijohnson> zyga: it had custard cream in it with some powdered sugar on the outside
<ijohnson> let me see if I can find a picture
<zyga> NO :D
<ijohnson> I guess it's a bit "americanized"
<zyga> I didn't have lunch yet
<ijohnson> hahaha
<zyga> I'll be super hungry all standup :D
<zyga> ijohnson: we usually have some jam inside, rose or plum
<zyga> ijohnson: and carmelized orange peel on the outside
<ijohnson> https://usercontent.irccloud-cdn.com/file/RhgAaQJe/paczki.png
<zyga> (yummy)
<ijohnson> ah that sounds really good
<ijohnson> ^ that's what the ones I found look like
<zyga> that's a sizable bag :D
<zyga> oh well
<zyga> I have some leftovers from dinner to warm up after standup
<zyga> (not paczki though)
<ijohnson> :-)
<zyga> cmatsuoka: I see the mountinfo data
<pstolowski> pedronis, zyga oh it failed despite the sleep bump last Friday? hmm
<zyga> pstolowski: not sure but I think I saw one failure after rebasing
<zyga> pstolowski: I don't know the state of the branch that Samuele was looking at
<pstolowski> i see
<zyga> cmatsuoka: and when it was in the broken state, what's the mount operation that you tried to perform exactly?
<zyga> oh
<zyga> standup
<mup> PR snapd#8183 opened: tests: remove tmp dir for snap not-test-snapd-sh on security-private-tmp test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8183>
<zyga> https://github.com/snapcore/snapd/pull/8180 needs a 2nd review and should be [simple]
<mup> PR #8180: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>
<jdstrand> zyga: ok, responded to PR 8123
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> jdstrand: thank you
<jdstrand> zyga: did you see my comment in PR https://github.com/snapcore/snapd/pull/7731#issuecomment-589829764
<mup> PR #7731: usersession/userd: add "apt" to the white list of URL schemes handled by xdg-open <â Blocked> <Created by oSoMoN> <https://github.com/snapcore/snapd/pull/7731>
<zyga> jdstrand: not yet
<jdstrand> zyga: you might want to see my other comments from friday
<zyga> jdstrand: I will, github has some nice new notifications
<zyga> I need to start using that again
<jdstrand> zyga: I think we can merge it now, cherry-picking to 2.44 if needed
<zyga> (the previous one was just noise and hard to find anything in)
<zyga> jdstrand: ack, I'll review both shortly
<mvo> meh, my inbox just exploded with snapd edge build failures :(
<zyga> yeah
<zyga> did you check
<zyga> I'm considering checking or having quick lunch ahead of core 20 sync
<roadmr> does a rabbit qualify as "quick lunch"?
<roadmr> also - baby oil - which part of the baby does it come from? ð¤
<cwayne> roadmr: i literally asked that yesterday
<roadmr> you were around asking questions about baby oil on #snappy on sunday?
<jdstrand> roadmr: you are on fire today :)
<zyga> failure from launchpad builders https://www.irccloud.com/pastebin/i6AZBoZK/
<roadmr> and it's only 10:15 am :)
<jdstrand> \o/
<zyga> pstolowski: ^ does that ring a bell
<ijohnson>  zyga: have you seen this kind of spread failure ? https://pastebin.ubuntu.com/p/TQ3mkHcQW5/ I've seen this twice now in the past week
<zyga> ijohnson: yes, it's fixed
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8180 would help too
<ijohnson> zyga: ack I'll merge master into my PR
<ijohnson> thanks
<mup> PR #8180: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8180>
<zyga> ijohnson: if you review, it's +1 and green and simple
<zyga> thank you
<ijohnson> zyga: +1d and merged
<mup> PR snapd#8180 closed: tests: rm -rf /tmp/snap.* in restore <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8180>
<zyga> little description is confusingly close to little encryption
<pstolowski> zyga: no, not really
<zyga> pstolowski: ok,
<mvo> zyga: I see a lot of failures in the ppa build with "cannot set effective group to 0: Operation not permitted" - do you know anything about this?
<mvo> zyga: https://launchpad.net/~snappy-dev/+archive/ubuntu/edge/+packages e.g. the s390x build for 19.10
<mvo> zyga: fwiw, it happens when running the unit tests it seems
<zyga> mvo: hmmm
<zyga> mvo: probably the setgid change
<zyga> mvo: I'll check
<mvo> zyga: yeah, I was wondering if it might be
<mvo> zyga: thanks for having a look!
<mvo> zyga: the error does indicate it, maybe the priv dropping leaking into the unit tests?
<mvo> zyga: anyway, strange that it suddently starts
<zyga> mvo: perhaps that's the change I landed in the morning
<mvo> zyga: that sounds plausible
<mvo> zyga: that's around the time it started to fial
<zyga> aaah
<mvo> fail
<zyga> I get it
 * mvo hugs zyga
<zyga> the test run as user
<zyga> and this is new code path
<zyga> I'll fix this today
<zyga> sorry
<zyga> it didn't come out in our tests because those ... run as root
<zyga> OR
<zyga> there's something else missing
<zyga> I think we may have started to run tests as a user as well
<mvo> zyga: yeah, it breaks the snap building so let's treat is as high priority
<zyga> I'll finish dinner and fix it
<mvo> zyga: if I can help please let me know, happy to investigate myself but I also feel it's probably silly because you know the details way better than me
<mvo> ijohnson: a review of 8182 would be appreciated, I saw you self-requested a review, we would like to cordinate with the store to do this RSN
<ackk> hi, does snapd need access to anything else than api.snapcraft.io:443 to for store access?
<zyga> re
<zyga> ackk: probably, for downloads
<zyga> ackk: but dunno for sure
<pedronis> ackk: yes, there is more, the store keeps an official list
<mup> PR snapd#8182 closed: build: enable type: snapd <â Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8182>
<ackk> pedronis, thanks
<ijohnson> pedronis: re: error wrapping in #8177, is it okay if I wrap errors in other places? or would you prefer that I just not wrap errors there for now and add a TODO:UC20: to wrap those errors later? because many of the seed errors are a bit unclear on an actual system to see why boot failed IMHO
<mup> PR #8177: cmd/snap-bootstrap/initramfs-mounts: mount the snapd snap in run-mode too <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8177>
<pedronis> ijohnson: I would prefer not to wrap for now
<pedronis> because that code is in flux
<ijohnson> pedronis: ack I will just remove the wrapping for now then
<pedronis> ijohnson: there's some common code there, that probably should go in a single helper
<ijohnson> pedronis: in this PR or later with  TODO:UC20:
<ijohnson> ?
<ijohnson> I know the TODO's are a bit piling up now
<pedronis> ijohnson: later
<ijohnson> ok
<pedronis> ijohnson: I need to change a bit the signature of LoadMeta
<mup> PR snapd#8142 closed: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8142>
<ijohnson> sure that would make it easier/quicker in run mode
<ijohnson> pedronis: 8177 is ready again but still needs second review
 * ijohnson updates 8147 now
<pedronis> ijohnson: I reviewed both
<ijohnson> thanks pedronis
<ijohnson> I'll do a little bit more gardening of my open PR's then get back to opening the boot robustness tests PR
<pedronis> thx
<pedronis> ijohnson: I'm reading now grub TryKernel, I don't understand when it would return true and err at the same time
<sarnold> maxiberta: hello :) what would you think about autoconnecting htop's necessary permissions? last week a user on #ubuntu had a seriously unhappy machine https://pastebin.com/raw/hJASew3R
<ijohnson> pedronis: but we will eventually have multiple implementations of ExtractedRunKernelImageBootloader, i.e. uboot, lk, etc.
<pedronis> ijohnson: they should all behave this way
<pedronis> it's not a sane api
<ijohnson> pedronis: but can't we be more safe ?
<pedronis> ijohnson: yes, and no
<pedronis> we can but that invariant broken is very confusing for readers
<pedronis> so I'm not sure this is a long term sane state of things
<ijohnson> would a comment help this to explain we're being extra cautious there ?
<pedronis> ijohnson: maybe but honestly I wouldn't expect users of that api to need to be cautius
<pedronis> it's really unusual for a go function to return an error and other values != zero
<pedronis> it happens but it's rare
<pedronis> and usually very documented
<ijohnson> yes but when it happens it's a usually a bug so we're trying to be resilient here against a bug
<ijohnson> if we aren't careful then we would panic and boot would fail
<ijohnson> err rather
<ijohnson> if we aren't careful and there is a bug, we would panic and boot would fail
<ijohnson> I'm perfectly fine with your suggestion to change the order of the check
<ijohnson> i.e. `if err == nil && tryKernelExists` seems fine to me
<pedronis> ijohnson|lunch: related to this boot.ExtractedRunKernelImageBootloader probably merits more details docs about the methods behavior
<mup> PR snapd#8184 opened: cmd/libsnap, tests: fix C unit tests failing as non-root <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8184>
 * zyga pushes one small PR and EODs
<zyga> please land that to unbreak PPA builds
 * zyga is afk, tg in case of urgency
<mup> PR snapd#8171 closed: cmd/snap-failure/snapd: rm snapd.socket, reset snapd.socket failed status <Simple ð> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8171>
<mup> PR pc-amd64-gadget#37 opened: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> PR snapd#8176 closed: tests: adding amazon linux to google backend <Created by sergiocazzolato> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8176>
<mup> PR snapd#8185 opened: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
<ijohnson> hey mwhudson do you still maintain console-conf for ubuntu core?
<mwhudson> ijohnson: "maintain"
<ijohnson> :-)
<ijohnson> quick question
<ijohnson> this PR: https://github.com/CanonicalLtd/subiquity/pull/389 was merged to the core/bionic branch, but I don't see any other core/... branches, so if we need to do the same thing/similar thing for uc20, where would we propose that change to?
<mup> PR CanonicalLtd/subiquity#389: services: run console-conf after core18.start-snapd.service <Created by mvo5> <Merged by sil2100> <https://github.com/CanonicalLtd/subiquity/pull/389>
<ijohnson> or better yet, could we just land the equivalent change for uc20 to subiquity master and have it show up in focal eventually ?
<ijohnson> mwhudson: ^
<mwhudson> ijohnson: hmmm the version of console-conf in focal may well be a bit broken
<mwhudson> ijohnson: in general xnox knows a lot more about uc20 things
<ijohnson> mwhudson: ok, just curious about the branching situation with console-conf
<mwhudson> ijohnson: magic 8 ball says "vague"
<mwhudson> ijohnson: basically there isn't one i guess
<ijohnson> mwhudson: haha, fair enough
<ijohnson> mwhudson: also thoughts on having the console-conf service always specify `After=... <insert-ubuntu-core-specific-things ad infinitum>` in the systemd unit? I don't think that breaks anything because if the uc things don't exist if it's just After then it's just ignored IIRC
<ijohnson> i.e. put that in master so it runs on classic and core
<xnox> ijohnson:  i've dropped version number from the systemd job in core20, because it is silly.
<mwhudson> ijohnson: sounds vaguely sane
<mwhudson> ah hi xnox
<xnox> ijohnson:  and yes, something similar needs to land to master + dput to focal
<xnox> ijohnson:  ie. After=core.start-snapd.service After=core18.start-snapd.service to cover all basis
<ijohnson> xnox: so should I file a PR to subiquity master with those changes then?
<xnox> ijohnson:  we are overdue a consoleconf upload.
<xnox> ijohnson:  yes please
<ijohnson> ok, sounds good
<xnox> ijohnson:  i can pre-test them against hand-built core20 snap too with a UC20 image
<ijohnson> xnox: also not sure if you saw, but maciej opened this: https://github.com/snapcore/core20/pull/23, but I think the better way to do that is to just put it all in console-conf upstream
<mup> PR core20#23: hooks: ensure console-conf@ is started after snapd.recovery-chooser-trigger.service <Created by bboozzoo> <https://github.com/snapcore/core20/pull/23>
<xnox> ijohnson:  i think so
<ijohnson> xnox: ok, I think I will file a PR with the core18 specific hacks first then maybe maciej re-opens his core20 PR against subiquity upstream then
<ijohnson> thanks xnox and mwhudson
<hellsworth> part
<mup> PR snapd#8147 closed: cmd/snap-bootstrap: verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8147>
<pedronis> ijohnson: after further thinking, I still we should follow the pattern we use in other cases (like ErrNoState) and have a special error (ErrNoTryKernelRef ?) instead of the bool for TryKernel
<ijohnson> pedronis: ok, that's easy enough to do and I think I can wrap that up succinctly in my next PR
<pedronis> s/still/think/
<pedronis> ijohnson: thx
<zyga> ensure prune thing is still failing
<zyga> https://github.com/snapcore/snapd/pull/8186 as promised
<mup> PR #8186: run-checks: SKIP_GMFMT really skips formatting checks <Created by zyga> <https://github.com/snapcore/snapd/pull/8186>
<zyga> and back to bed
<mup> PR snapd#8186 opened: run-checks: SKIP_GMFMT really skips formatting checks <Created by zyga> <https://github.com/snapcore/snapd/pull/8186>
<mup> PR snapd#8187 opened: boot: misc UC20 changes <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8187>
<mup> PR core18#148 opened: hooks: delete console-conf hack <Created by anonymouse64> <https://github.com/snapcore/core18/pull/148>
<mup> PR core20#24 opened: hooks: delete console-conf hack <Created by anonymouse64> <https://github.com/snapcore/core20/pull/24>
#snappy 2020-02-25
<mup> PR snapcraft#2952 opened: spread: introduce appstream parse-info test <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2952>
<mborzecki> morning
<mborzecki> school run
<mborzecki> re
<mup> PR snapd#8184 closed: cmd/libsnap, tests: fix C unit tests failing as non-root <Test Robustness> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8184>
<mvo> ijohnson: meh, it looks like 2020-02-24 22:05:33 Error executing google:ubuntu-core-18-64:tests/core/snapd-failover :  is still failing on master even after merging your latest fix for it :(
<mvo> ijohnson: https://api.travis-ci.org/v3/job/654625002/log.txt which is a run after 8171 got merged
<mborzecki> mvo: hey
<mvo> hey mborzecki
<mborzecki> ouch, failover still failing? :/
<mvo> mborzecki: at least one log still has it
<mborzecki> mvo: there's one oustanding PR with fixes iirc
<mvo> mborzecki: aha, there is?
<mvo> mborzecki: 8169 ?
<mborzecki> hm i think it was #8140
<mup> PR #8140: tests: enable more tests for UC20/UC18 <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8140>
<mborzecki> let me check, it was referenced in one that got merged
<mborzecki> mvo: right 8169
<zyga> good morning
 * zyga is sleepy today, sorry for starting late
<mvo> zyga: hey!
<zyga> mvo: hey, I fixed the error from last evening
<mvo> zyga: I saw, thanks for this! merged already
<zyga> ah, good
<zyga> mvo: I wanted to raise https://github.com/snapcore/snapd/pull/8123
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> mvo: jamie gave it a +1 and expressed ok to put this in 2.44
<zyga> my reasoning for raising it is that I prefer one variant rather than two
<pstolowski> morning
<zyga> mvo: if 2.44 ships (a) (merged) and then we switch to (b) in 2.45 that's more churn than just going with (b)
<zyga> mvo: at the same time, it's not a priority fix, just for your consideration
<mborzecki> zyga: pstolowski: hey guys
<zyga> hey maciek!
 * zyga is sleepy, couldn't sleep last night
<zyga> I'll make a 2nd coffee and be back soon
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/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>
<pstolowski> sure
<mup> PR core20#23 closed: hooks: ensure console-conf@ is started after snapd.recovery-chooser-trigger.service <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/core20/pull/23>
<mborzecki> pstolowski: thanks!
<mvo> zyga: thanks, it looks like samuele wants to have another look, I'm not against this (at all)
<zyga> yep, I saw,
<mup> PR snapd#8188 opened: spread.yaml: make qemu ubuntu-core-20-64 use ubuntu-20.04-64 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8188>
<zyga> what's the timeline for 2.44?
<zyga> PPA is busted?
<zyga> https://www.irccloud.com/pastebin/BCFak9n5/
 * zyga wonders if we could just get on with slack
 * mborzecki prepares to buy another 16GB of ram
<zyga> mborzecki: that's easy though :)
<zyga> mborzecki: remember when vista was around
<zyga> mborzecki: all that free memory
<mborzecki> i think i wouldn't mind matrix really
<pstolowski> mborzecki: +1 with small remark
<mborzecki> pstolowski: thanks, pushing the update now
<mborzecki> seems like there's a bunch of mobile apps, probably none as well supported as slack app, but still looks better than mattermost
<mborzecki> mvo: so, about the chooser ui, i think we should have some intiial prompt rather than jumping straight away to options that do something
<mborzecki> mvo: for instnace, on serial you may have trouble with baud rate setting, or the output may not apepar right away, if the user presses enter and that activates some 'funky' option there may be trouble ahead
<zyga> mborzecki: does matrix have a good phone app?
<mvo> mborzecki: good point
<mborzecki> zyga: hmm https://play.google.com/store/apps/details?id=im.vector.app&hl=en_US
<mborzecki> 677 reviews, heh
<zyga> seems poor
<mborzecki> there's this one too https://play.google.com/store/apps/details?id=im.vector.riotx&hl=en_US
<zyga> 5k installs
<mborzecki> yeah
<degville> zyga / mborzecki: I've used Riot.im for some time, and it has really improved over the last 12 months. I use it mostly as an IRC bridge though. RiotX looks good - it would be great to see how Mozilla gets on with Matrix, because it's scale that worries me and can't test.
<zyga> degville: I wonder if matrix can be summarized as "good desktop experience, irrelevant mobile experience"
<zyga> degville: which might explain why mozilla is OK with it
<zyga> degville: I would probably not use slack on my phone outside of conferences and occasional "let's check that one thing from bed" moments
<degville> zyga: me neither. my phone is too old and it will probably reduce battery to 30 mins. I used the web client when I needed to use slack. It does seem a little 'over engineered'. It would be great to get behind an open replacement for IRC imo, because it's not just us who could benefit.
<degville> though I did get the weechat (IRC client) to slack plugin working, which is a nice compromise.
<zyga> degville: I think one thing has changed though, the acceptance level has shifted up
<zyga> degville: people expect a more polished experience
<zyga> degville: and in the endless quarrels of FOSS people we have not managed to raise above that to produce an excellent opinionated product that is also free
<zyga> degville: I fear we'll go to a non-free product just because it is actually working well
<zyga> degville: a bit like going with google for mai
<zyga> *mail
<zyga> can we run our own mail server, sure
<zyga> is it nice to most people, not as much
<zyga> I think IRC will be exactly the same thing
<zyga> (and email has much nicer desktop apps than IRC ever did)
<degville> yeah, you're right. I really don't h
<degville> have a problem with non-free at all. It is about the best tool.
<degville> but... it's also a change to differentiate, and also flex some open source credentials when other people may be going the other way.
<zyga> I wish there was a monetarily supported free product that's really nice and offers good experience
<zyga> I wonder what suse and rh are doing in this regard
<degville> yep. I was seriously considering getting in touch with a couple of friends to see if they wanted to create a startup :)
<zyga> I think being able to host your own FOSS server would be 90% of what we want
<degville> well, RH has just gone with Slack.
<degville> over MS teams (https://www.theverge.com/2020/2/10/21132060/ibm-slack-chat-employee-rollout-microsoft-teams-competition)
<zyga> the apps could just be closed source for all I care (mobile) and web apps running from the same server
<zyga> oooooh
<zyga> RH slack?
<mborzecki> degville: as in 'just now' or just (as in no other options considered) ?
<zyga> are they using the snap? ;)
<mborzecki> ah ok, IMB
<degville> ahahah...
<mborzecki> IBM
<degville> yeah, true. I didn't realise it was only 350k employees either, which is a drop in the IBM ocean.
<zyga> wait, what's 350k employees?
<degville> IBM's employees.
<zyga> ouch
<zyga> that must cost some pretty penny
<degville> ...actually, all of it's employees.
<degville> its
 * mborzecki wonders about uinput for snap-boostrap recovery-chooser-trigger spread tests
<zyga> uinput?
<zyga> what's that?
<mborzecki> zyga: userspace driven input device, basically create /dev/input/<event*> from userspace and inject input events
<zyga> aha
<zyga> all this input devices are now yours
<zyga> except evdev
<zyga> attempt no open there
<zyga> ;)
 * zyga goes back to hitting his head on sessions
<MattJ> zyga, degville: there are multiple options for self-hosted FOSS team chat... RocketChat, Mattermost, etc. - curious why you're dismissing them (iirc this community used to be on RocketChat, what happened?)
<MattJ> I've been working on FOSS chat stuff for ~15 years, so I'm 100% curious to hear from folk (and happy to chat in private if it's too off-topic here)
<zyga> MattJ: I don't know - do any of those offer identity management and mobile apps?
 * zyga wonders what the requirements are
<MattJ> Yes
<mborzecki> hm mattermost mobile app was pretty crappy tbh
<MattJ> I've never used their mobile app myself, but the rest of Mattermost is generally fairly polished (it's essentially a Slack clone)
<MattJ> Main issue with Mattermost is that they do the do the "enterprise edition" thing, and refuse to add (or accept contributions for) certain features in the community edition
<zyga> typical open core
<zyga> is that bad tough
<zyga> otherwise the open part would not be there either
<MattJ> *shrug* - that's an entire debate in itself :)
<MattJ> I'm personally not a fan of it, but I do also find it weird how many stories I've heard of companies running the open-source version with bunches of patches applied because they don't want to pay for the commercial version
<MattJ> but then they basically have to maintain their own fork
<MattJ> but I guess dev/ops time spent on that doesn't appear explicitly on balance sheets, so it's ok
<zyga> combinations of imperfect realities
<zyga> we should all use git irc
<zyga> like irc
<zyga> just with the usability of git ;)
<zyga> commit your messages
<zyga> don't rebase public channels
<zyga> that kind of stuff
<zyga> for usability it comes with a man page generator
<MattJ> There are plenty of blockchain chat solutions if that really tickles your fancy :D
<mborzecki> ICO included ;)
<mborzecki> looks like it's a choice between lest crappy solution
<MattJ> Well there are plenty of annoyances with Slack and other proprietary solutions too, so... welcome to software :)
<MattJ> I'm looking to possibly release something in this space later in the year, so I've been doing a fair amount of research
 * zyga is feeling so so today
<mup> PR snapd#8177 closed: cmd/snap-bootstrap/initramfs-mounts: mount the snapd snap in run-mode too <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8177>
<zyga> [Tue Feb 25 08:37:42 2020] audit: type=1400 audit(1582619862.212:29075): apparmor="DENIED" operation="open" profile="snap.test-snapd-audio-record.play" name="/etc/pulse/client.conf" pid=11535 comm="paplay" requested_mask="r" denied_mask="r" fsuid=12345 ouid=0
<zyga> https://www.irccloud.com/pastebin/06KY87al/
<ackk> hi, is there a way to programmatically (from a script) check for snapd support for default tracks?
<zyga> ackk: apart from version query, probably not
<ackk> zyga, ok. so >=2.44 ?
<zyga> ackk: I don't know, please ask mvo about the details
 * zyga is deep in systemd-pam
 * ackk looks around for mvo :)
<mvo> ackk: yeah, 2.44 is the best bet right now
<ackk> mvo, ok, thanks
<mvo> ackk: we could build something programmatic if needed
<ackk> mvo, are versions guaranteed to be x.y (just two numbers)?
<mup> PR snapd#8189 opened: seed,cmd/snap-boostrap: introude seed.Snap.EssentialType, simplify bootstrap code <Created by pedronis> <https://github.com/snapcore/snapd/pull/8189>
<pedronis> mvo: mborzecki: ^ this is relatively simple, the size is mostly from test updates that change indent
<mvo> pedronis: thanks
<mup> PR snapd#8156 closed: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<mvo> ackk: following the ubuntu versioning schema, so 2.44 or 2.44.1
<pedronis> is not the step that reduces validations but is on the way there
<ackk> mvo, thanks
<pedronis> mborzecki: thanks for review and for spotting the image_test.go issue
<pedronis> image_test.go fixed
<mup> PR snapd#8190 opened: overlord, taskrunner: exit on task/ensure error when preseeding <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8190>
<jdstrand> pedronis: hi! curious, is there a store api to determine the highest snap-declaration format the store supports?
<pedronis> jdstrand: not at the moment
<jdstrand> ok, thanks
<pedronis> it could be added if needed
<pedronis> but needs to involve the store (obviously)
<jdstrand> pedronis: sure, it isn't important
<jdstrand> pedronis: I'm just writing a small tool to help reviewers working with store apis. I can hardcode it with a pointer to maxSupportedFormat in asserts/asserts.go
<pedronis> jdstrand: fwiw, it doesn't support 4 yet
<jdstrand> I know
<pedronis> I'll ask for a bump during 2.44 release cycle
 * jdstrand nods
<mup> PR snapd#8191 opened: [RFC] cmd/snap-recovery-chooser: add a recovery chooser <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8191>
 * zyga is deep into PAM but feels like it is actually working now
<zyga> mborzecki: fun stuff
<mborzecki> zyga: pam?
<mborzecki> zyga: the session/scope thing?
<mup> PR core20#25 opened: hooks/200-console-conf-after.chroot: perform console-conf ordering checks <Created by bboozzoo> <https://github.com/snapcore/core20/pull/25>
<mborzecki> hmm signal?
<zyga> mborzecki: yeah, I feel I'm starting to understand WTF when you log in
<zyga> I need to take the dog out
<zyga> ttyl
<zyga> I'm taking off
<zyga> cannot stand smell of food and cooking at home
<zyga> $motherinlaw is on a cooking spree
<mborzecki> hmm looks like all spread jobs are failing?
<cmatsuoka> mborzecki: the error message also looks wrong
<cmatsuoka> 'If that is intentional, please update the package list in the'
<mborzecki> cmatsuoka: the error is way up in the log
<cmatsuoka> ah ok, it continues after in a new echo
<cmatsuoka> never mind
<mborzecki> but i meant that snapd spread jobs are failing due to snapd-failover
<cmatsuoka> mborzecki: make install error, that's strange
<cmatsuoka> did we land ian's snapcraft.yaml fix?
<cmatsuoka> anyway, I'm not familiar with this usr/share/snappy/dpkg.list
<cmatsuoka> mborzecki: ah, failover again? I thought mvo fixed that a few days ago
<mvo> cmatsuoka: I thought so too :(
<mvo> cmatsuoka: investigating this again, it's a PITA
<cmatsuoka> mvo: btw dimitri's fix worked and now we have run mode working, with and without tpm
 * zyga is at a cafeteria 
<zyga> finally no food smell
<roadmr> what :)
<mvo> cmatsuoka: \o/
<mborzecki> zyga: must be a bad cafeteria if you're no smelling any food
<zyga> mborzecki: are you kidding me?
<zyga> mborzecki: there's coffee and food but you don't smell any of it
<zyga> mborzecki: it's not a kitchen
<mborzecki> zyga: sure, it doesn't smell like beef steaks, but these places have a very distinct smell too (one i actually enjoy)
<zyga> mborzecki: I think I'm just overly happy that it doesn't smell like the back of a kitchen anymore :)
<mborzecki> hahaha ;) fair enough
<zyga> mborzecki: but on topic, pam is really key to my understanding of the whole problem
<zyga> mborzecki: building pam with debugging and setting up the debug log
<zyga> mborzecki: also forkstat
<zyga> that opened my eyes as to what's going on on login
<zyga> in various contexts
<zyga> I'm going through the config and the pam modules that interact with default sessions you may open, piecing together the picture of how it works
<mborzecki> zyga: you'll have to do a write up for everyone
<zyga> mborzecki: yep, including instructions on how to get stuff into debuggable state :)
<mborzecki> and not break your system in the process
<zyga> mborzecki: pam_systemd.c (in systemd's tree) is really 99% of what I care about
<zyga> although some other bits are also relevant in other modules
<zyga> heh
<zyga> this is a fun comment
<zyga> https://www.irccloud.com/pastebin/zk6NdIwe/
<mup> PR snapd#8192 opened: tests: add more debug output to the snapd-failure handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/8192>
<zyga> hmm, how to set syslog priority level
<zyga> mvo: I'll skip standup; my update is a deep-dive into logind, pam, ssh, getty and systemd in order to write proper tests for the issue discovered by jamie
<ijohnson> hey folks
<zyga> mvo: I'll update the standup notes later today, as I've been taking notes on with pen&paper
<ijohnson> zyga: sounds like fun :-)
<zyga> ijohnson: yeah, and useful
<zyga> I didn't know this at all
<zyga> but I'm slowly building towards a tool that will let us run stuff as a user in a session of given properties
<mvo> zyga: ok
<mborzecki> ijohnson: looks like we need to sync about core20/subiquity PRs
<mborzecki> ijohnson: opened this one https://github.com/CanonicalLtd/subiquity/pull/638 to master
<mup> PR CanonicalLtd/subiquity#638: debian/console-conf.service: ensure correct order with respect to snapd services <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/638>
<ijohnson> mborzecki: hmm talk more after we talk after SU about the other thing?
<mborzecki> ijohnson: and this one to core20 https://github.com/snapcore/core20/pull/25
<mup> PR core20#25: hooks/200-console-conf-after.chroot: perform console-conf ordering checks <Created by bboozzoo> <https://github.com/snapcore/core20/pull/25>
<mborzecki> ijohnson: yeah, let's stay after standup
<zyga> mborzecki: this is cool
<zyga> https://www.irccloud.com/pastebin/XACC4Nqv/
<zyga> for example, this is running "true" via ssh
<zyga> https://www.irccloud.com/pastebin/9Bmj2q1M/
<zyga> (so much noise and garbage)
<zyga> it's also interesting as to what PATH is set to specific components, e.g. update-motd
<zyga> or the number of times python has to run before you get the shell prompt
<zyga> each time to run lsb_release
<zyga> mborzecki: comparison of /etc/pam.d/{su,sudo} is interesting
<zyga> one involves common-session and the other common-session-noninteractive
<zyga> common-session invokes pam_systemd.so while common-session-noninteractive does not
<pstolowski> cmatsuoka: hey, you're probably aware of https://bugs.launchpad.net/snapd/+bug/1863886 ?
<mup> Bug #1863886: snap-bootstrap should validate which ubuntu-data is mounted <core20> <snapd:New> <https://launchpad.net/bugs/1863886>
<cmatsuoka> pstolowski: ah yes
<cmatsuoka> pstolowski: we still must check the best way to do that
<pstolowski> sure
<cmatsuoka> but yes, it's in my todo list
<pstolowski> cmatsuoka: ok, i'll assign it to you then
<cmatsuoka> pstolowski: ok, thanks!
<mborzecki> ijohnson: added your patch to https://github.com/CanonicalLtd/subiquity/pull/638
<mup> PR CanonicalLtd/subiquity#638: debian/console-conf.service: ensure correct order with respect to snapd services <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/638>
<ijohnson> mborzecki: cool sounds good, I hadn't noticed your branch didn't have the other old uc18 specific service
<mborzecki> ijohnson: can you do a quick review of https://github.com/snapcore/core20/pull/25 maybe?
<mup> PR core20#25: hooks/200-console-conf-after.chroot: perform console-conf ordering checks <Created by bboozzoo> <https://github.com/snapcore/core20/pull/25>
<ijohnson> mborzecki: sure looking now
<mborzecki> ijohnson: thanks!
<mup> PR core20#24 closed: hooks: delete console-conf hack <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/core20/pull/24>
 * zyga has a small eureka moment!!!
<zyga> in case I get hit by a bus on my way home
<zyga> the magic to run a command in a session
<zyga> is
<zyga> systemd-run /sbin/runuser -l USER -c COMMAND
<zyga> one can also pass --send-sighup and --tty to systemd-run, for instant gratification
<zyga> the rationale is as follows:
<zyga> systemd-run runs the rests as a servicem outside of our existing logind session
<zyga> runuser -l invokes pam_systemd which asks logind for a new session - this normally fails if we already have one (hence systemd-run)
<zyga> the session lives for the duration of the executed command
<zyga> I'll work on making this nice and useful for writing tests
<zyga> CC ^ mborzecki
<ijohnson> zyga: nice work that's pretty great to know
<mborzecki> *magic*
<zyga> I'll make some test primitives
<zyga> and adjust our test code where it matters
<zyga> I have extra notes on how to get debug information
<zyga> the critical bit was tracing logind code paths to understand that it fails to create a session if the requesting PID already inhabits one
<zyga> I'm happy about this day now :)
<zyga> I think I deserve lunch now
<zyga> I'll head home
<zyga> and sit some more to write down the code in the evening
<zyga> CC jdstrand ^ (how to test in a user session above)
<zyga> I need to check this on more distributions as PAM config matters
<zyga> mainly to check if there's any important skew from one distro to another
<jdstrand> zyga: nice! :)
<zyga> jdstrand: the journey through PAM was interesting
<zyga> jdstrand: one-more-way-to-setenv
<zyga> perhaps a way out of some of our environment problems
 * jdstrand nods
<zyga> ogra: is this reliable? https://github.com/ogra1/snapd-docker
<mvo> hm, I get "remote failed to report status" when I try to push to github
<mvo> anyone else seeing this? pushing a new branch
<zyga> systemd-run --pipe --quiet --wait /sbin/runuser -l test -c "COMMAND"
<zyga> wooot
<zyga> that's what we need :)
<zyga> https://status.github.com/
<zyga> increased error rate
<zyga> so probably broken
<zyga> partial outage
<mvo> aha
<mvo> it's very annoying, it *may* be the fix for the failover
<zyga> hahaha
<zyga> that's indeed a bit annoying
<zyga> ok, I need to stop coding and wrap up
 * zyga waits for spread to finish
<mup> PR snapd#8193 opened: snapstate: do not restart in undoLinkSnap unless on first install <Created by mvo5> <https://github.com/snapcore/snapd/pull/8193>
<mvo> ijohnson: I pushed 8193 with something that worked for me at least once, let's hope it proves to be ok
<ijohnson> mvo: nice I'll try that in combination with 8169
<zyga> oooh
<zyga> wow
<zyga> mvo: is this intentional? https://github.com/snapcore/snapd/pull/8193/files#diff-5a87044d1fc20ea2664be6c683755bffR129
<mup> PR #8193: snapstate: do not restart in undoLinkSnap unless on first install <Created by mvo5> <https://github.com/snapcore/snapd/pull/8193>
<ijohnson> zyga: I have that in my branch too
<ijohnson> zyga: it's quite useful I think because if we are at the point where snap-failure is running, something has went wrong so having debug info from snapd when it is invoked from snap-failure is very useful
<zyga> I don't doubt usefulness
<zyga> I wonder what the consequences of running with debug are
<ijohnson> it's rather quiet because in this case snapd should only revert the snapd snap and exit
<zyga> I'll review stuff with clear head later
<zyga> I think working outside is a bit more tiresome than indoors
<zyga> but this was a good day
<zyga> (at least for me)
 * zyga EODs
<mvo> zyga: yeah, it's on prupose, like ijohnson says, the output is actually quite short but very useful
<cjwatson> zyga: FYI I released man-db 2.9.1 with the /snap/man change
<cjwatson> as discussed
<ijohnson> mvo: I've done 3-4 spread runs of your branch with mine on top on core18 qemu and haven't run into the race yet
<ijohnson> but to be fair I was only seeing it once every 30 or so runs, so not sure how excited to get about that data point
<zyga> mvo: ack, I just wanted to check
 * zyga is back with fixed bikes
<zyga> cjwatson: ack, thank you
<zyga> cjwatson: I'll look at the state on our side soon
 * zyga spawns some more tests and goes for dinner 
 * zyga is starving
<mvo> ijohnson: ohhhhhh
<mvo> ijohnson: fingers crossed - I will stop irc now and pretend the bug is fixed :)
<ijohnson> haha
 * mvo hugs ijohnson 
<zyga> drat
<zyga> my laptop suspended while running tests
<zyga> oh well
<kyrofa> Hey zyga, when I run `snap login`, does that macaroon ONLY have the ability to install snaps? Nothing else?
<zyga> kyrofa: mmmm, no
<zyga> kyrofa: I think that is equivalent to root
<kyrofa> What other possibilities are there?
<zyga> kyrofa: the details are in api.go
<zyga> kyrofa: you can remove snaps, configure them, etc
<zyga> kyrofa: let me check
<kyrofa> zyga, right, but none of those things relate to the macaroon
<kyrofa> For example, a macaroon can have the ability to upload snaps as well, which we use in snapcraft
<zyga> I think it is subtle
<zyga> one moment
<kyrofa> Alright, thanks :)
<zyga> https://github.com/snapcore/snapd/blob/master/daemon/api.go#L192
<zyga> look at all the UserOK: true things
<zyga> those can be done as an authenticated user
<zyga> you can get app icon, search the store, manage snaps, interfaces, changes, and more
<kyrofa> zyga, does the polkit integration end up with the same permissions?
<zyga> not quite
<zyga> for example an authenticated user can search
<zyga> and that doesn't require any polkit permissions
<zyga> UserOK means a non-root can GET the endpoint
<kyrofa> zyga, to clarify: if app A uses polkit and app B runs `snap login`, do they end up being able to do the same things, or does one have more ability than the other?
<zyga> ah wait
<zyga> wait
 * zyga is misreading stuff
<zyga> kyrofa: I think they are not identical and thus could be different
<zyga> for example, /v2/logs has PolkitOK
<zyga> so it requires a polkit prompt to see
<kyrofa> Ah ha
<zyga> https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L132 is relevant
<kyrofa> zyga, exactly what I needed
<zyga> https://github.com/snapcore/snapd/blob/master/daemon/daemon.go#L139
<zyga> this seems to suggest that if you are logged in
<zyga> then you can access anything that's not specifically walled off
<zyga> so if you log in you get more power
<zyga> which is weird, nothing sets RootOnly?
<zyga> aha, I see
<zyga> those are now split up to separate files
<zyga> kyrofa: creating users require to be root
<zyga> kyrofa: also profiling snapd
<kyrofa> Thanks zyga
<zyga> kyrofa: pleasure :)
<mup> PR snapd#8194 opened: o/devicestate: unset recovery_system when done seeding <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8194>
<mup> PR snapd#8193 closed: snapstate: do not restart in undoLinkSnap unless on first install <â  Critical> <Created by mvo5> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8193>
#snappy 2020-02-26
<mup> PR snapd#8195 opened: tests/lib/prepare.sh: simplify, combine code paths <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8195>
<mup> PR snapcraft#2953 opened: meta: remove remaining `__dict__` and key list usage in snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2953>
<mup> PR snapd#8189 closed: seed,cmd/snap-bootstrap: introduce seed.Snap.EssentialType, simplify bootstrap code <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8189>
<mup> PR snapd#8183 closed: tests: remove tmp dir for snap not-test-snapd-sh on security-private-tmp test <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8183>
<mup> PR snapd#8140 closed: tests: enable more tests for UC20/UC18 <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8140>
<mup> PR snapd#8186 closed: run-checks: SKIP_GMFMT really skips formatting checks <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8186>
<mup> PR snapd#8085 closed: [RFC] netutil: add default gateway monitor <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8085>
<mborzecki> morning
<mvo> mborzecki: good morning
<mup> PR snapd#8196 opened: client: add "Resume" to DownloadOptions and new test <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8196>
<mup> PR snapd#8188 closed: spread.yaml: make qemu ubuntu-core-20-64 use ubuntu-20.04-64 <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8188>
<mborzecki> mvo: hey! so PRs are finally green :)
<mvo> mborzecki: yes, it's quite nice, if we push a bit we could go below 50 today
<mup> PR snapd#8081 closed: tests/main/user-session-env: add test verifying environment variables inside the user session <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
<mborzecki> hmm can't push an update to #8169
<mup> PR #8169: tests/many: don't use StartLimitInterval anymore, unify snapd-failover variants, build snapd snap for UC16 tests <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
<mborzecki> looks like ian didn't tick allow edits from maintainers box
<mvo> mborzecki: meh, a shame
<mup> PR snapd#8195 closed: tests/lib/prepare.sh: simplify, combine code paths <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8195>
<mup> PR snapd#8197 opened: snap: refacot code in `snap download` to prepare for snap downloads <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8197>
<mup> PR snapd#7707 closed: snap: add TestDownloadDirectStoreHappy test <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7707>
<jamesh> could someone restart https://travis-ci.org/snapcore/snapd/builds/655225016 for me?  It looks like it failed on a timeout talking to github.com
<mborzecki> jamesh: sure
<jamesh> mborzecki: thanks
<mborzecki> jamesh: looks like it's already restarted
<zyga> DobÄ
<zyga> Done even
<jamesh> I wonder how hard it'd be to cut Travis out of the loop completely
<jamesh> the main feature missing from github actions is the option to make secrets available to PRs
<zyga> jamesh: oh? Are you sure?
<zyga> I saw secrets used in some actions I looked at
<jamesh> zyga: yeah.  Secrets come up blank if the the job is initiated by someone without write access to the repository
<zyga> Aaaah
<zyga> I see
<zyga> I guess that is only expected
<jamesh> in contrast, anyone can submit a PR that changes .travis.yml so that their test run will exfiltrate the secrets
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<mvo> pstolowski: I saw some of these in travis: https://paste.ubuntu.com/p/3jdZTp7QPd/
<mborzecki> damn serial terminals
<pstolowski> mvo: is this with latest master?
<mvo> pstolowski: I think so, let me double check
<mborzecki> mvo: pstolowski: i saw this locally today when merging master to ijohnson's branch
<pstolowski> mborzecki: ah, ok. that's annoying :(. i'll intensify my efforts on the followup then, i was hoping the last bump of the sleep time was enough as a temporary workaround
<mvo> pstolowski: we could bump again by 1s or so
<mvo> pstolowski: until we have the fix
<jamesh> mvo: I noticed that, and had it happen locally.  I needed to up the wait to 3 seconds
<jamesh> wasn't sure if it was something I'd introduced
<mvo> jamesh: it's a recent change from pstolowski
<mvo> jamesh: 3s each? anything unusal about your machine? particularly slow or fast?
<pstolowski> okay, i can propose one more bump, and in the meantime will continue working on the better fix
<jamesh> mvo: just that one test.
<jamesh> mvo: I tried bumping in smaller increments locally, but had no idea what it was doing with the time
<jamesh> the system is not particularly fast
<mvo> jamesh: thank you for letting us know
<mup> PR snapd#8198 opened: o/tests: bump TestEnsureLoopPruneAbortsOld sleep time <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8198>
<zyga> Sleep bump a day keeps those pesky races at bay
<mup> PR snapd#7146 closed: [sketch] UC20: cmd/snap-verify: sketch of snap-verify <UC20> <â Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7146>
<kbroulik> Is it true Ubuntu ships chromium or chrome as Snap soon/by default or something along the lines?
<zyga> kbroulik: dunno, is that announced somewhere?
<kbroulik> https://snapcraft.io/blog/chromium-in-ubuntu-deb-to-snap-transition I think this
<zyga> This seems like a deb is migrating to a snap, is that what you meant?
<kbroulik> yeah, sorry, my wording wasn't clear
<zyga> That is not the same as ship by default (preinstall)
<kbroulik> "is it true Ubuntu ships chromium as a snap instead of a deb?" :)
<kbroulik> right
<zyga> Given that post it would seem so
<kbroulik> hm maybe I should try it first and see if it breaks my project :)
<mup> PR snapd#8199 opened: tests: enable snapd-failover on uc20 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8199>
<mvo> mborzecki: for your recovery-chooser pr - you need to install it in the debian packaging to some place
<mvo> mborzecki: check e.g. debian/snapd.install
<mborzecki> mvo: it's already added there
<mborzecki> hmmm
<mborzecki> uhh 14.04
<mvo> mborzecki: was just looking over the recent failure in spread, not really looking closely
<kbroulik> ok so yeah I tried chromium snap and as I feared: it breaks plasma-browser-integration as it cannot find the native host :/
<kbroulik> interestingly it does have a whitelist for /etc/chromium which should allow this
<kbroulik> ah. ok, so chromium snap also breaks gnome chrome shell. so the whitelist doesnt actually work
<kbroulik> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074 ok, is known. thanks anyway :)
<mup> Bug #1741074: [snap] chrome-gnome-shell extension fails to detect native host connector <snap> <chromium-browser (Ubuntu):Triaged> <https://launchpad.net/bugs/1741074>
<zyga> mvo: I wonder if master will be red by Friday
<mvo> zyga: mh, why?
<mvo> zyga: it looks mostly green right now
<zyga> mvo: that prune thing
<zyga> mvo: feels like a deeper problem
<mvo> zyga: no worries, pawel is working on a better version of this test
<mup> PR snapd#8200 opened: [RFC] cmd/snap-chooser-ui-demo: a demo of recovery chooser UI <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8200>
<pedronis> zyga: #7219 was force pushed a bunch of times, that is not great
<mborzecki> mvo: the UI demo bit ^^
<mup> PR #7219: devicestate/firstboot: check for missing bases early <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7219>
<pedronis> heh, I meant #7129
<mup> PR #7129: userd: allow setting default-url-scheme-handler <â Blocked> <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<jwheare> unfortunately rebasing onto master was required and that requires a force
<jwheare> this has been open a looong time heh
<zyga> pedronis: yeah, I noticed, I just +1 the fact that the contributor has not lost interest
<pedronis> jwheare: well, it means now it needs a review by me, even it got a lot of +1s already
<zyga> it looks like the entire history is kept, just rebased
<mborzecki> damn, github ui popup when you start entering #<PRnumber> is so confusing and buggy
<zyga> pedronis: can you delegate that review to others?
<pedronis> zyga: maybe
<pedronis> I still need to understand what the PR does either way
<pedronis> I planned to do that in any case
<jwheare> also, as was mentioned in the comments, i was iterating yesterday just to force sloow test reruns, often including white space changes, which were useless. during that time there were some comments before i had finished, and i squashed at the end. the squashed part is clearly marked out
<zyga> I had a look at this originally, the key is the {Check,Get,Set}Sub API - it's a part of the xdg-settings system https://portland.freedesktop.org/doc/xdg-settings.html
<zyga> the rest is glue to our stack
<zyga> pedronis: ^
<pedronis> I marked it for me, hopefully I can decide something about it still this week
<zyga> pedronis: perhaps github UI has improved as the rebase did not break the flow of the comments
<pedronis> it seems it has
<pedronis> zyga: also it should probably not go in 2.44, we are too close to wanting to cut it
<pedronis> and it's already full of things
<mborzecki> yeah, the comments stay and are marked as outdated, you can also click on the rebase change and see the diff
<mvo> mborzecki: nice!
<zyga> pedronis: it's not my decision, I would probably let it in as it's been there for a while and I'm not sure how getting it in at the next cycle will help - it probably won't be tested by anyone apart from the currently, single user interested in it (as in single snap)
<mborzecki> time to put all the recover bits back together again
<pedronis> zyga: if nothing else it changes spread tests, that's reason enough not to merge just before cutting
<mup> PR snapd#8194 closed: o/devicestate: unset recovery_system when done seeding <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8194>
<pedronis> zyga: I looked a bit, there are actually issues with the code
<zyga> pedronis: I'll check your review
<pedronis> zyga: I haven't reviewe, I'm just skimming, but saw a place where it could panic for example
<zyga> pedronis: on SplitN?
<pedronis> yes for example
<pedronis> also why the cast to string
<zyga> on checkOutput? bytes / strings
<jwheare> that was in the original code
<pedronis> no, there's SplitN(string(thing)...  but thing is already a string
<pedronis> anyway it needs clearly another review pass and checking for coverage
<pedronis> sorry
<jwheare> https://github.com/snapcore/snapd/blob/master/usersession/userd/settings.go#L168
<mup> PR snapd#8201 opened: [WIP,RFC] Mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
<pedronis> jwheare: different assumptions, but yes that code is fragile too, but that code doesn't even assume there's a path wher the 2nd part is not there
<jwheare> probably down to me copy/pasting existing code to a different place. well spotted
<pedronis> the string bit is needed because output is []byte there
<jwheare> yeah
 * zyga straces systemd-run to see why it hangs
<zyga> good old 18.04
<zyga> everything works
<pedronis> anyway, I'll try to give this some attention still this week (next week we are at a sprint), but no promises, my own queue is long atm
<zyga> extend tests to all systems
<zyga> 16.04 shows it's rusty fangs
<jwheare> pedronis: there is no rush, more eyes are always good
<jwheare> i have to say i lost a lot of time to that "not" command
<jwheare> "why is this erroring when i test this on some dummy bash code locally"
<jwheare> also trying to work out what's happening in failing tests that check stderr output by redirecting to a file when set -x prints to stderr too is fun
<mup> PR snapd#8202 opened: cmd/snap-bootstrap,seed: verify only in-play snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/8202>
<jwheare> 90% of this PR was probably test wrangling heh
<pedronis> mvo: mborzecki: #8202 should speed up snap-bootstrap a bit
<mup> PR #8202: cmd/snap-bootstrap,seed: verify only in-play snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/8202>
<zyga> so I guess I have a solution for the systemd-run getting stuck
<zyga> it changes the usability a little but not by much, at least for testing
<pedronis> pstolowski: hi, should I look at #8201, or not yet?
<mup> PR #8201: [WIP,RFC] Mock prune ticker in overlord tests to reduce wait times <Created by stolowski> <https://github.com/snapcore/snapd/pull/8201>
<pstolowski> pedronis: let's see if it passes first, i'll re-run it a few times
<pedronis> ok
<mvo> fun on arm64 it seems http://paste.ubuntu.com/p/Q7CMcqRK5T
 * mvo retries the ppa build where this happend
<zyga> mvo: that's the new stopper code?
<pedronis> yes
<mvo> yes
<zyga> maybe want to see my simple epoll code instead
<zyga> though it's kind of close to release
<zyga> so dunno
<mvo> lookng now
<zyga> maybe just more locking / if nil things
<mvo> zyga: yeah, looks like the timeout is nil for some reason
<mborzecki> pedronis: cool, let me take a look
<mup> PR snapd#8192 closed: tests: add more debug output to the snapd-failure handling <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8192>
<ijohnson> mborzecki sorry not sure why the box wasn't ticked on 8169 but it should be good now
<mborzecki> ijohnson: cool, let me merge again and push
<pedronis> mvo: ah, you cannot pass nil for timeout on arm64
<mvo> pedronis: interessting, shall I push a fix or will you?
<mvo> pedronis: breaks the arm64 builds right now
<pedronis> mvo: yes, but it's a bit unclear what the fix should be, null means don't timeout
<pedronis> 0 means don't even try
<pedronis> mvo: this is fixed in newer versions of go :/
<mvo> pedronis: oh no
<mvo> pedronis: we could workaround with timeout.Sec: 999999
<zyga> mvo: perhaps the man page is relevant
<mvo> pedronis: fugly but would probably be ok?
<zyga> I didn't read the code so not sure if that's the culprit
<zyga> https://www.irccloud.com/pastebin/zFnzXT9r/
<pedronis> mvo: we probably should workaround but setting everything to the max but only on arm64
<mvo> pedronis: +1
<mvo> pedronis: I can prepare a PR
<pedronis> zyga: the panic points to a place and the place is reading timeout
<ijohnson> mborzecki did you see my typo in the PR too? Seems the spread tests didn't run due to my typo in that PR
<pedronis> it's fixed in newer go
<zyga> pedronis: I see
<pedronis> see the if at line 90 here: https://golang.org/src/syscall/syscall_linux_arm64.go
<pedronis> older go don't have it
 * pedronis lunch
<zyga> uh, I see
<zyga> sucks, bug in the wrapper
<mvo> yep
<mborzecki> ijohnson: yeah, i'm looking and shellcheck, it's unhappy about some things, also one of the warnings looks like a bug in shellcheck ;)
<ijohnson> :-(
<mborzecki> ijohnson: hahah https://paste.ubuntu.com/p/yb6d9NMN3B/
<ijohnson> Ahh
<mup> PR snapd#8203 opened: netlink: fix panic on arm64 with the new rawsockstop code <Created by mvo5> <https://github.com/snapcore/snapd/pull/8203>
<pedronis> mvo: in theory if we timeout the subsquent read will give us EWOULDBLOCK or similar and we retry, so just having some kind of long timeout should work
<pedronis> mvo: not sure if we can test somehow that scenario though
<mvo> pedronis: I pushed the workaround with int64 seconds timeout
<mborzecki> ijohnson: pushed
<mvo> pedronis: it's enough time I think, still worth double checking if select behaves sanely for such a huge value
<pedronis> mvo: or we don't make it huge but as I said check that the udev code does the right thing if select timeouts
<pedronis> it should (in theory)
<mvo> pedronis: I have no strong opinion either way, I pushed the simplest thing but I can iterate on this
<mborzecki> ijohnson: i should probably file an issue with shellcheck about the for loop
 * zyga stops banging the head against the wall and breaks for a quick snack
<mup> PR snapd#8204 opened: data/systemd: improve the description <Created by sergiusens> <https://github.com/snapcore/snapd/pull/8204>
<pedronis> mvo: I'll try something test-wise on top of your PR in a bit
<mvo> pedronis: sure
<mborzecki> ijohnson: https://github.com/koalaman/shellcheck/issues/1847 heh
<zyga> back
<mborzecki> ijohnson: wouldn't be surprised if _ is an actual variable getting assigned to at this point
<zyga> mborzecki: what were you expecting?
<zyga> oh
<zyga> actually
<mborzecki> zyga: nothing ;)
<zyga> I'm surprised now
<zyga> mborzecki: bash and dash disagree
<zyga> mborzecki: _ is ok in dash
<zyga> mborzecki: and a no-op in bash
<zyga> I suspect it is documented somewhere
<mborzecki> zyga: fwiw it's flagged for -s bash too
<pedronis> mvo: not for 2.44 but we should consider using x/sys/unix for a our few syscall needs maybe
<pedronis> mvo: there's a missing import in _other.go
<mup> PR snapd#8199 closed: tests: enable snapd-failover on uc20 <Simple ð> <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8199>
<jwheare> pedronis: probably worth mentioning the force push thing in the contribution guide btw, since different projects have different norms https://github.com/snapcore/snapd/blob/master/CONTRIBUTING.md
<zyga> wl
<zyga> sorry,
<zyga> thunder :)
<zyga> winter is over
<zyga> and hail
<pedronis> mvo: pstolowski: I pushed a fix and one more test (at the cost of some changes) to #8203
<mup> PR #8203: netlink: fix panic on arm64 with the new rawsockstop code <Created by mvo5> <https://github.com/snapcore/snapd/pull/8203>
<pstolowski> pedronis: ok, will rereview
 * pstolowski lunch
<pstolowski> zyga: nb, #8170 is ready for re-review
<zyga> ack
<mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<zyga> looking
<pstolowski> ty
<mborzecki> heh, last minute changes are always a bad idead
<zyga> mborzecki: what did you break?
<zyga> ;)
<mborzecki> zyga: heh little tweaks in the ui before opening the PR
<mborzecki> ofc unit tests are passing ;)
<mup> PR snapd#8196 closed: client: add "Resume" to DownloadOptions and new test <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8196>
<zyga> pstolowski: reviewed
<pstolowski> zyga: thanks!
<zyga> pstolowski: thank you, I just did the last review :)
<mup> PR snapd#8205 opened: tests: just remove user when the system is not managed on create-user-2 test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8205>
<zyga> pstolowski: we should bring barylki
<zyga> they will function both as sweets
<zyga> hand sanitizers
<zyga> and throat sanitizers
<mup> PR snapd#8204 closed: data/systemd: improve the description <Simple ð> <Skip spread> <Created by sergiusens> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8204>
<zyga> I'll take a break to take the dog out
<zyga> brb
<pedronis> mvo: it's a minor thing but it might make sense to backport 8204 to 2.44 if it's what is going into 20.04
<pedronis> and is not too annoying
<mvo> pedronis: +1
<mup> PR snapd#8206 opened: travis.yml: run unit tests on arm64 as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206>
<pstolowski> zyga: i'm actually thinking about some 'stronger' sweets this time ;)
<mborzecki> mvo: for the race with mount units: https://paste.ubuntu.com/p/z7ZpDRmKcW/
<zyga> back
<zyga> my phone just got an ... ubuntu touch update
<mvo> mborzecki: oh, nice!
<zyga> yeah
<pstolowski> zyga: woot!?
<pstolowski> ubuports?
<zyga> yes
<zyga> booting now
<zyga> pstolowski: heh, there's a new UI
 * cachio lunch
<ijohnson> mborzecki: hmm seems the merge went a bit awry on 8169, okay if I push up some changes or are you working on it ?
<pstolowski> zyga: show me a screenshot pls
<zyga> how do I make screenshots on core
<zyga> er
<zyga> phone
<zyga> it's pretty, I"ll bring it
<zyga> you'll see :)
<zyga> back to services
<ijohnson> mborzecki: well I'll just push anyways
<pedronis> zyga: mvo: at this point #7825 targets 2.45, right?
<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> pedronis: yes
<zyga> pedronis: there's one real issue that needs fixing
<zyga> pedronis: and tests to cover it
<pedronis> it's fine, changing the milestone
<zyga> pedronis: it's not critical (not desktop) but needs to be debugged all the way because it's critical path
<mvo> pedronis: +1
<mborzecki> ijohnson: yeah, please do, there were 2 merges, both had conflicts because of related things landing
<ijohnson> mborzecki: ack
<ijohnson> pedronis: I reviewed your essential snaps PR, thanks for that
<ijohnson> pedronis: if you could quick take a look at my question on https://github.com/snapcore/snapd/pull/8185#issuecomment-591193478 that would be appreciated thanks
<mup> PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
<pedronis> ijohnson: thank you
<pedronis> ijohnson: looking (was having a different chat somewhere else)
<ijohnson> pstolowski: should I re-review #8170, seems to have changed a bit since I last reviewed
<mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<ijohnson> pedronis: thanks
<pedronis> ijohnson: ah, that, we always keep 2 or 3 older revisions per snap, so it's normal that the unpacked assets for them would stay around, you need to install 4 kernels before you see assets go away I think
<pedronis> keep 2 or 3 XoldX revisions
<ijohnson> pedronis: ok, not sure if we wanted to keep the assets around on ubuntu-boot
<ijohnson> looks like the unit test is correct then and I'll just remove that last check
<pedronis> ijohnson: that's the logic as is right now, we might want to change it but needs a larger discussion
<pstolowski> ijohnson: i think the changes are very small, not necessary
<ijohnson> pstolowski: ok thanks for confirming
<pstolowski> ijohnson: np, thanks for asking!
<pedronis> ijohnson: that's what we do on uboot devices atm for UC16 UC18
<ijohnson> pedronis: makes sense. today I will work on cross-checking the signing keys in the kernel.efi we booted with in snap-bootstrap vs the ones in the current_kernels kernel snaps and open the other boot robustness PR then
<pedronis> thx
<pedronis> ijohnson: ping me if you need input on something
<ijohnson> sure
<zyga> I'll grab some food, family's back
<pedronis> pstolowski: I reviewed #8190, looks like what I expected, some comments on details
<mup> PR #8190: overlord, taskrunner: exit on task/ensure error when preseeding <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8190>
<pstolowski> pedronis: thanks! i forgot about state lock
<pstolowski> pedronis: nb #8170 is probably close if you can re-review
<mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<pedronis> pstolowski: I don't think #8170 needs a review by me, I think you address my main point, right?
<mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<pedronis> *addressed
<pstolowski> pedronis: that's fine, i wasn't sure if that was all. thanks
<pedronis> pstolowski: actually, I am a bit confused, I thought preseeding worked with core 16 ?
<pedronis> it seems you are blocking that too?
<pedronis> or am I misreading the code
<pedronis> or are you being careful because there is not spread test yet?
<pedronis> pstolowski: to be clear I'm fine, we don't have a strong use case for core atm, especially core 16, just trying to understand
<pstolowski> pedronis: my intent was to allow only classic with core snap or core18+snapd, and consider core systems in followups (with tests)
<pedronis> pstolowski: ok, that's fine
<cmatsuoka> cachio: what was the name of the sb/tpm enabled image again?
<cachio> cmatsuoka, google-tpm is the server
<cachio> backend
<cmatsuoka> ah ok, let me try that... thanks!
<cachio> cmatsuoka, https://github.com/snapcore/snapd/blob/master/spread.yaml#L128
<cachio> you should try something like google-tpm:ubuntu-20.04-64:
<cachio> cmatsuoka, you are the first one using those images
<cachio> cmatsuoka, please tell me if you need any change
<ijohnson> pstolowski: what's the first release that hotplug worked on ? 2.42 ?
<pstolowski> ijohnson: hmm, tough question, i need to dig a bit, one moment
<ijohnson> thanks
<mup> PR snapcraft#2952 closed: spread: introduce appstream parse-info test <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2952>
<pstolowski> ijohnson: 2.39 it seems
<ijohnson> thanks pstolowski
<pstolowski> ijohnson: based on https://forum.snapcraft.io/t/hotplug-implementation-plan/4554/3 cause debian changelog wasn't too helpful
<ijohnson> pstolowski: degville: I made a small edit to https://forum.snapcraft.io/t/hotplug-support/10750 to reflect that snapd edge isn't useful anymore
<ijohnson> err rather isn't needed anymore for enabling hotplug
<degville> ijohnson: thank you!
<pstolowski> ijohnson: thanks, makes sense
<pedronis> mvo: are you building a new 2.43 ?
<pedronis> of snapd
<zyga> mvo, pedronis: snapd is held up in store review
<zyga> types: New type "application" does not match the type of the latest approved revision, r6625 ("snapd")
<pedronis> zyga: that's a 2.43 build, that's why I asked mvo
<zyga> I see
<mvo> pedronis: no plan to re-build 2.43, cherry picked one commit though in this branch just in case, I think we can ignore this
<mvo> uh, looks like master is red - is that because of "tests/main/retry-network" failing?
<mvo> looks like it - oh well
<mvo> something for my morning I guess
<pedronis> mvo: yes, something strange going on with retry-network
<pedronis> lots of red
<pedronis> not just master
<cachio> pedronis, I am testing a fix for the retry-network
<cachio> it is a timing issue
<ijohnson> cachio: what's the timing issue for retry-network?
<cachio> ijohnson, takes some time to NoNetwork: true
<ijohnson> cachio: ah as in the network namespace isn't created immediately?
<cachio> in the output file I see NoNetwork: false
<cachio> but after a time it appears NoNetwork: true
<cachio> ijohnson, I am testing the fix right now
<ijohnson> cachio: cool let me know when/if you want me to review
<cachio> ijohnson, sure, thanks!!
<cachio> there are 2 problems
<cachio> timing issue
<cachio> which is fixed
<cachio> also getent hosts www.ubuntu.com is returning the ipv6 instead of the ip
<cachio> todya I updated the images
<cachio> I think there was a change in a package which is affecting this
<cachio> ijohnson, ~
<ijohnson> cachio: ah I see yeah ipv6 could break things I suppose
<ijohnson> cachio: I need to step out for a while, but feel free to request my review, I'll be back in a hour or two
<cachio> ijohnson, sure, np
<mup> PR snapd#8207 opened: tests: fix retry network test after image update <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8207>
 * cachio afk
#snappy 2020-02-27
<mup> PR snapd#8208 opened: boot_test: add many boot robustness tests for UC20 kernel MarkSuccessul and SetNextBoot <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8208>
<zyga> o/
<abeato> mvo, morning!
<mvo> good morning abeato
<abeato> mvo, one question, which are the bootloader requirements for UC20? is there any documentation on that?
<pstolowski> morning
<mvo> abeato: they are roughly the same as before, ideally the bootloader should be able to chainload but I think we could work without that (it means less robustness though)
<zyga> mvo: good morning
<mvo> hey zyga
<zyga> mvo: I'll be partially off today, need to get haircut and finish that pesky travel thing
<zyga> mvo: my goal for today is to publish what I did for sessions and work on prompting demo
<zyga> mvo: question
<zyga> mvo: last evening pedronis and I noticed a store review block on snapd
<zyga> mvo: due to type
<zyga> mvo: was that the auto-build?
<zyga> mvo: or something new
<abeato> mvo, so, basically the same modifications that we need to do today (for u-boot for instance)?
<mvo> zyga: an auto-build of 2.43
<zyga> ok
<mvo> zyga: but the snap was removed from the queue, no?
<mvo> abeato: yes, why do you ask ?
<zyga> mvo: I didn't check beyond that
<zyga> I'm very tired lately, I try to sleep as much as I can
<mvo> abeato: what loader do you have in mind :)
<abeato> mvo, customers are asking :)
<mvo> abeato: ok
<mvo> zyga: good luck, yeah, I feel also not great currently, very strange
<abeato> mvo, same bootloaders as usual, but I did not know if UC20 required something new
<zyga> abeato: note that core 20 is x86 driven now, arm work will happen later, my suspicion is that for full feature set you may need a better bootloader
<zyga> abeato: but I think it's just speculation at this stage
<zyga> (or more feature integration)
<mvo> abeato: foundations is working on a port of uboot to uc20 currently
<mvo> abeato: we willl discuss in FRA what the status is here
<mvo> abeato: no plans for lk or anrdoidboot so far though
<abeato> sil2100, do you know which is the status of that? ^^
<sil2100> abeato: hey! I don't have a full update on that, waveform is working on the raspi port - but I know there was progress last time I checked
<abeato> mvo, hm, lk (well, a fork of it, but we use lk support in snapd) is used by nvidia boards which seem to be polular
<mvo> abeato: yeah, I'm sure eventually we get lk support it's just not a priority right now
<abeato> mvo, ok, thanks for the info
 * zyga feels the urge to start using slack already
<pedronis> mvo: hi, in #8206 even the amd64 tests, broke ?
<mup> PR #8206: travis.yml: run unit tests on arm64 as well <Created by mvo5> <https://github.com/snapcore/snapd/pull/8206>
<mvo> pedronis: yeah, it's confusing, I thing I got the syntax for the matrix wrong in some way
<mvo> pedronis: I'm looking at the network-retry failure first, then I will get back to this one
<pedronis> mvo: it's fine, to be understand why that one started failing just now ?
<pedronis> s/to be/do we/
<mvo> pedronis: getent hosts www.ubuntu.com returns ipv6 now
<mvo> pedronis: and the script naively uses "http://$ip" which is invalid for ipv6 of course
<pedronis> ah
<pedronis> can't we fix the script ?
<mvo> pedronis: it's still a bit puzzling, we could force it to just use ipv4 but I wonder if ipv6 gives a useful error
<pedronis> yes, same here
<pedronis> I sort would prefer to test with boths
<mvo> pedronis: exactly
<abeato> zyga, do you have a pointer to the grub config that will be used for UC20?
<pedronis> and teach the script to deal with both kind of addresses
<mvo> pedronis: that was what I'm playing with right now
<pedronis> ok, great
<mvo> pedronis: the error for connect ipv6 is different but maybe I'm holding it wrong
<mvo> pedronis: I litterally got there 20s before we started talking :)
<zyga> abeato: I'm not closely involved in uc20 work, sorry
<pedronis> abeato: I can give you pointers, there are two configs involved (they will move inside snapd soon), but at the moment they are in the gadget
<pedronis> one sec
<abeato> k
<mvo> pedronis: meh, it really looks like ipv6 gives a very different net.OpError when it cannot connect, that feels a bit of a rathole "fun"
<pedronis> abeato: here, https://github.com/snapcore/pc-amd64-gadget  grub.cfg-{recovery,boot}, recovery is the first stage,  boot is the 2nd used in run mode (vs the various recovery mode of UC20)
<abeato> pedronis, great, thanks for the links
<pedronis> mvo: the fun never ends
<mborzecki> morning
<mvo> mborzecki: good morning
<mup> PR snapd#8209 opened: tests: use ipv4 in retry-network to unblock failing master <Created by mvo5> <https://github.com/snapcore/snapd/pull/8209>
<mborzecki> mvo: hey, anything interesting going on this morning?
<mvo> mborzecki: master red again but beside this not really
<mvo> 8209 should unbreak us and I'm looking at an equivalent ipv6 test right now
<zyga> mvo: interesting that ipv6 thing
<zyga> for me it shows ipv6 on xenial
<zyga> specifically
<zyga> https://www.irccloud.com/pastebin/etKNfVuq/
<zyga> there are no ipv4 addresses at all
<zyga> is that a change in the system config or a change in our domain name?
<zyga> notably this xenial machine does not have an ipv6 global address
<mborzecki> zyga: same here, ipv6 only ;)
<zyga> mborzecki: it's the future ;)
<mvo> yeah, maybe it's a global change, no idea
<mborzecki> zyga: hm maybe the response for AAAA comes back faster than for A?
<zyga> dunno, I would have expected the whole response
<zyga> it's a DNS query
<zyga> you ask for stuff
<mborzecki> or AAAA are queried first
<zyga> you get stuff
<zyga> (records)
<zyga> https://www.irccloud.com/pastebin/4KWXTfnL/
<zyga> check this out
<zyga> curious
<zyga> dig ANY website-content-cache.canonical.com
<zyga> that's giving me AAAA records
<zyga> but dig ANY ubuntu.com does not
<zyga> but hostent gives both?
<mborzecki> idk
<zyga> er, hosts
<mborzecki> maybe the future is now
<zyga> the future is broken now
<mborzecki> zyga: actually quite broken, those addresses returned by getent are not really usable, i only got private and link local addresses on my interfaces
<zyga> yeah, same here
<zyga> I wonder if IS changed something
<zyga> or if ubuntu changed something in xenial
<zyga> looking at dpkg.log
<zyga> nothing, it's pretty much unchanged except installs of local test packages
<mborzecki> imo it's a problem with glibc
<mborzecki> unless i'm misremembering how things work with ipv6
<mvo> I can ask in #is
<mvo> mborzecki, zyga asking our is folks
<zyga> thank you
<mborzecki> definitely the year of linux desktop ;)
<mborzecki> zyga: btw. try `getent hosts localhost`
<zyga> I get ::1
<zyga> that's so weird
<zyga> feels broken :)
<mborzecki> zyga: wonder where the preference is encoded, at least i can ping ::1
<zyga> offtopic, sun and snow / hail oscillate every 10-15 minutes
<zyga> sunlight with blue sky
<zyga> then dark gray and lots of snow
<zyga> what a day!
<mup> PR snapd#8210 opened: wrappers: add mount unit dependency for snapd services on core devices  <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8210>
<mborzecki> mvo: ^^ do you think this is 2.44 worthy?
<zyga> mborzecki: hmm
<zyga> the patch looks buggy
<zyga> you have [Unit] and then immediately [Service]
<zyga> in the past [Unit] had ExecStart
<zyga> is that expected?
<mborzecki> zyga: yeah, ExecStart is part of [Service], so i updated the tests to make them closer to real unit definitions
<zyga> aha
<zyga> how was it working before?
<zyga> compatiblity in systemd?
<mborzecki> zyga: no, it's just the test data, the actual services under data/systemd are correct and have ExecStart in [Service]
<zyga> ahhh
<zyga> ok, that clears up the mystery ;)
<zyga> thanks!
<mvo> mborzecki: probably, please tag
<mup> PR snapd#8209 closed: tests: use ipv4 in retry-network to unblock failing master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8209>
<mup> PR snapd#8211 opened: tests: run ipv6 network-retry test too <Created by mvo5> <https://github.com/snapcore/snapd/pull/8211>
<mup> PR snapd#8207 closed: tests: fix retry network test after image update <Squash-merge> <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8207>
<mborzecki> mvo: tagged
<mborzecki> hmm new kernel
<mborzecki> brb
<mborzecki> and running 5.5.6 now
<zyga> posh
<zyga> mvo: FYI, 14.04 cnf suggests "snap" for "snap"
<zyga> could lead to some confusioin
<zyga> mvo: what's the state of ESM snapd build?
<zyga> I'm testing on 14.04 as well, could get it to see if anything odd pops up
<mvo> zyga: it's build in staging
 * zyga -> lunch
<zyga> back,
<mborzecki> zyga: can you remind me, when we launch snap-update-ns it's started using fexecve right?
<zyga> correct
<zyga> we launch all our tools this way
<zyga> any issues?
<mborzecki> zyga: trying to update the centos 8 and there's weird selinux denial, let me copy that
<mborzecki> zyga: https://paste.ubuntu.com/p/nDKbryS9tv/
<mborzecki> zyga: i think it's ld.so tryign to poke ld cache
<zyga> mborzecki: yeah
<zyga> I suspect so
 * zyga finds selinux gibberish-y
<zyga> today I learned one cool feature of dbus is not supported in busctl: https://github.com/systemd/systemd/issues/14954
<mborzecki> zyga: ha, weird why busctl doesn't support that
<zyga> it's just not coded
<zyga> there's an error branch and thats's that'
<mborzecki> well, maybe nobody tried it with busctl yet
<mborzecki> zyga: suppose there's limited use case consideing busctl is a command line tool
<zyga> mborzecki: shell is still quite versatile, plus you could open python an pass a fd this way :)
<mborzecki> zyga: you can, but should you?
<zyga> yes :)
<zyga> better than python bindings and in general even bash is sufficient to handle FDs
<mborzecki> zyga: hm why is even snap-update-ns invoked when there's no mount profile?
<zyga> mborzecki: for several years it is used to construct one
<mborzecki> zyga: hm need to go through that code again
<mborzecki> zyga: i keep evicing all state info afer a while :P
<mborzecki> zyga: hm still wodnering why this isn't picked up by the other selinux specific tests, jsut this one
<zyga> mborzecki: probably because that test is fairly limited
<zyga> mborzecki: check out the aggregated denials bug on lauchpad
<zyga> mborzecki: or enable robust mount ns
<mvo> hm, ubuntu-core-18-64:tests/main/revert:remote seems to be failing currently, I wonder if it's a one-off or a new trend :(
<zyga> which exercises the same code
<zyga> mborzecki: there's a PR from me about that, it fails on a dozen issues
<zyga> mborzecki: I bet they are the same
<zyga> mborzecki: they routinely happen in normal use
<zyga> mvo: how does it fail?
<mborzecki> it fails due to unexpected denials in the log
<mborzecki> haaa and those happen on remove
<mvo> zyga: it says snapd wants to reboot the system
<zyga> mvo: huh
 * zyga is overwhelmed by complexity of snapd state handling sometimes
<pedronis> mvo: how does it fail?
<pedronis> we haven't changed anything in that area recently
<mvo> pedronis: yeah, it looks like there is a pc-kernel refresh that happend just now
<mvo> pedronis: so the test runs "snap refresh" and that triggered a pc-kernel refresh :/
<mborzecki> ayy
<pedronis> mvo: ah
<pedronis> fun
<pedronis> all tests doing snap refresh like that are fragile
<mvo> yeah
<pedronis> until we add holding for single snaps
 * mvo is slightly depressed about this and gets lunch
<pedronis> mvo: heh
<pedronis> mvo: anyway we might get some extra test failures when the test snaps get moved as well
<mborzecki> hmmmm
<mborzecki> so when removing a snap and disconnecting the interfaces, we keep recompiling the seccomp profiles on each disconnect
<mborzecki> feels like wasted cpu cycles
<mborzecki> zyga: this also triggers snap-update-ns ^^
<zyga> mborzecki: yeah, I think that's expected in our current design
<zyga> mborzecki: we only have one optimization, for mass auto-connect
<pedronis> mborzecki: we should remember it, but it doesn't sound like something to address right now
<pedronis> (too many other things)
<mborzecki> pedronis: right, i'll collect a some notes and open a forum topic
<cmatsuoka> cachio: it seems that tests with the tpm-enabled branch are successfully running on the google-tpm backend, but it's very, very slow
<jdstrand> pedronis: hey, since there were 2 force pushes in as many days for just reviews that I did, I wonder if it makes sense where when you first submit a PR in the section about the CLA if there should be something about force pushes
<jdstrand> that sentence could've used a couple commas
<cachio> cmatsuoka, ahh, ok
<cachio> do you have a branch to use
<cachio> perhaps I can improve it
<cmatsuoka> cachio: I'm currently testing with the frankfurt-preview-tpm branch in my tree
<cmatsuoka> cachio: it consolidates all encryption-related branches on top of the current master
<cachio> cmatsuoka, nice, thanks
<cachio> cmatsuoka, is it everything slow?
<cachio> or just a specific test?
<cmatsuoka> cachio: I've been running it for something like 1h now and it's still at 100/447
<cachio> cmatsuoka, ok
<cmatsuoka> cachio: also I can't tell if tpm was actually used, if you can shell into the test machine you can check if there's a /writable/system-data/ubuntu-data.keyfile.sealed there. If this file exists the system booted with tpm enabled
<cachio> cmatsuoka, nice
<pedronis> cachio: mvo: the test snaps have been transfered, let's see if something goes wrong with some tests
<mup> PR snapd#8202 closed: cmd/snap-bootstrap,seed: verify only in-play snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8202>
<pedronis> ^ this might speed UC20 install/boot a little bit
<pedronis> *speed up
<pedronis> cmatsuoka: how many machines are you using?
<pedronis> the tpm systems have one worker,  and our runes take 40 minutes with 4-6 workers
<pedronis> s/runes/runs/
<mborzecki> mvo: #8083 should be fine now, i've tagged it with 2.44 since there's a tiny policy update
<mup> PR #8083: spread, data/selinux: add CentOS 8, update policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
<mvo> mborzecki: thank you
<cachio> pedronis, running tests right now
<cachio> cmatsuoka, hey
<cachio> how many workers are you using?
<cachio> because by default the backend is using 1
<cmatsuoka> cachio: oh noes ok
<pedronis> cmatsuoka: our runes take ~40mins with 4-6 workers
<pedronis> runs
<cmatsuoka> cachio: I thought it was using the same number as the rest, but now it's almost finishing
<cmatsuoka> cachio: ah, it finished. With 279 tasks aborted
<zyga> mborzecki: can you check this on your box
<mborzecki> zyga: hm?
<zyga> https://www.irccloud.com/pastebin/N9YISpKV/
<zyga> mborzecki: it should behave like "sudo"
<zyga> mborzecki: it has -u for picking the user
<zyga> mborzecki: it's a bit of a hack
<zyga> hmmm
<zyga> weird
<mborzecki> zyga: https://paste.ubuntu.com/p/pPfN4F34SK/
<zyga> it still has some warts
<zyga> or one annoying one
<mup> PR snapd#8212 opened: tests: updating checks to new test account for snapd-test snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8212>
 * zyga break
<pedronis> mmh, github is having issues for me
 * cachio lunch
<pedronis> yea, status gives degraded hard to do reviews :/
<ijohnson> pedronis: sorry had my 1:1, but I'm editing the docs now, are you okay if I just make the edits directly or do you want me to propose changes with the suggestions thing on the doc?
<ijohnson> (edits for what's no longer 100% accurate)
<pedronis> ijohnson: probably just do the edits, unless there is something you are unsure about, in any case they are not that long, I can re-reread them after. Also remove/resolve any stale discussions/comments bits
<ijohnson> pedronis: ack
<pedronis> thank you
<ijohnson> pedronis: what does the green highlighting mean again? does that mean we already did it? if so perhaps we remove all the green highlighting and just use light red to mean "not done" ?
<ijohnson> or I guess the official name "light green 3"
<cjp256> what are the usual suspects for seeing "broken" in the notes section for a  snap?
<cjp256> i have lxd (stable) installed, but recently it seemed to break (after dist-upgrade?) and I'm getting errors like apparmor="DENIED" operation="exec" profile="snap.lxd.lxc" name="/usr/sbin/aa-exec" pid=5159 comm="lxc" requested_mask="x" denied_mask="x" fsuid=1000 ouid=0.  notes section says "broken"
<ijohnson> pedronis: anyways I made all the edits to update those 2 docs, I'm going to work on a section in the booting"
<ijohnson> I'm going to work on a section "booting" doc to put details about what we discussed this morning about
<ijohnson> cjp256: do you have a "current" symlink in /snap/lxd ?
<cjp256> yeah, rev 13487, which doesn't actually match the "installed" version according to snap info...
<ijohnson> cjp256: also what about the snap mount unit in systemd `systemctl status snap-lxd-*.mount` ?
<cjp256> active, mounted 13487
<cjp256> snap list shows 13522 as being installed though...?
<ijohnson> do you only have 1 mount unit in that command above ?
<ijohnson> For me, I have 2 mount units, 13487 and 13522
<cjp256> yeah snap-lxd-13487.mount - Mount unit for lxd, revision 13487
<ijohnson> hmm so that's why it's broken, snapd wanted to install 13522, but for some reason you never got a mount unit for it
<ijohnson> it -> that revision
<cjp256> so in other news, irccloud also started acting up
<cjp256> apparmor="DENIED" operation="symlink" profile="snap.irccloud.irccloud" name="/home/chris/snap/irccloud/28/.config/ibus/bus" pid=10991 comm="ln" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<ijohnson> what does `snap list lxd --all` show? do you have other revisions listed there (perhaps ones that are disabled) ?
<cjp256> 13487 "disabled" 13522 "broken"
<jdstrand_> cjp256: does irccloud have the desktop-legacy interface connected?
<ijohnson> try `snap revert lxd --revision 13487`
<cjp256> jdstrand: `desktop-legacy            irccloud:desktop-legacy   :desktop-legacy                  -`
<jdstrand> cjp256: oh, that is down in SNAP_USER_DATA anyway. that is probably related to a refresh
<cjp256> ijohnson: that worked like a champ! :D
<jdstrand> cjp256: guessing current is pointing to !28 ?
<ijohnson> now you could try `snap refresh` of lxd again and see how it goes
<cjp256> well that's interesting
<ijohnson> cjp256: do you have experimental.refresh-app-awareness enabled ?
<cjp256> irccloud had a similar problem
<cjp256> --all shows 24 "diabled,broken", and 27 "-"
<pedronis> ijohnson: yes, green meant done afaiu (sorry was in a meeting)
<cjp256> but current is a symlink to 28
<ijohnson> pedronis: thanks
<cjp256> ijohnson: yes!
<pedronis> ijohnson: and yes, if it's mostly done, I would remove it and just use read for missing bits
<ijohnson> cool
<pedronis> s/read/red/
<cjp256> ijohnson/jdstrand: though in irccloud's case, a `snap refresh irccloud --stable` did restore order, current is pointed back to 26
<pedronis> ijohnson: I'll look at docs now, given that reviewing is a bit not working on github atm
<ijohnson> cjp256: what's `snap changes irccloud`?
<cjp256> just `143  Done    today at 11:21 EST  today at 11:21 EST  Refresh "irccloud" snap`
<ijohnson> pedronis: ack there is one thing I'm unsure about is whether there's a modeenv in the image when we build it, I had a comment in the doc from a while ago that we were writing one there but perhaps we aren't and it was something else
<cjp256> ijohnson: i did reboot earlier to see if that resolves the problem, i don't know if changes logs prior boots
<ijohnson> pedronis: the issue that made me write that was that I had a too old `snap prepare-image` and the image I was writing (even though it was writing a newer snapd into the image) wouldn't finish boot
<ijohnson> It got stuck in install mode
<ijohnson> cjp256: no reboots don't clear changes
<ijohnson> cjp256: not sure what caused your problems but it sounded a lot like the ibus input thing jdstrand solved a while ago on irccloud and some bad refresh on the lxd snap
<pedronis> ijohnson: we don't, modeenv exists only in ubuntu-data and there is no ubuntu-data in UC20 images built (at least for now)
<ijohnson> pedronis: right, then I guess I will delete that, not sure what the problem was with my image a while ago but probably was an artifact of many things changing at once
<cjp256> ijohnson: now that I have a good idea of what may be happening I can dig in a bit further next time should it happen again...  thanks!
<ijohnson> np
<pedronis> ijohnson: what are the yellow highlights, were they preexisting?
<pedronis> (me doesn't remember)
<pedronis> I'm looking at bootenvs right now
<ijohnson> pedronis: yes you added those one day
<ijohnson> pedronis: perhaps we should consolidate the info in that highlighted section and unhighlight
<ijohnson> it
<ijohnson> mmm seems I missed some things in the bootenvs doc
<murthy> spotify's UI freezes after sometime
<murthy> does that happen to any of you?
<murthy> I had also tried reinstalling but issue still exists
<murthy> If someone can confirm I can try to downgrade
<pedronis> ijohnson: I made some suggestions, comments and marked some not yet done bits in light red in the boot envs one
<pedronis> ijohnson: please review
<ijohnson> pedronis: ok looking
<cmatsuoka> cachio: the encryption test is failing with google-tpm (/sys/kernel/security/tpm0/binary_bios_measurements: no such file or directory)
<murthy> fellows is there a bug reporting place somewhere for a snap?
<cmatsuoka> cachio: I checked with Chris and the likely cause is secure boot not enabled
<pstolowski> murthy: snap info spotify - the contact field
<cmatsuoka> cachio: are you using the snakeoil nvram file (OVMF_VARS.snakeoil.fd)?
<murthy> pstolowski: checking
<pstolowski> murthy: it seems there is an issue similiar to yours https://community.spotify.com/t5/Desktop-Linux/Spotify-GUI-freezes-in-Ubuntu-19-10/td-p/4900983
<murthy> pstolowski: Ya, I just saw that
<murthy> pstolowski: hope they fix it soon
<murthy> pstolowski: thanks for the help
<pstolowski> yw
<pedronis> ijohnson: I did a pass on half of booting, the update bits need some tidying up still
<pedronis> ijohnson: maybe copy some of the comments from bootstate20.go, not sure
<ijohnson> pedronis: ok doing that now
<pedronis> ijohnson: I left a comment about were I stopped for now
<pedronis> ijohnson: would like to eod a bit earlier today
<pedronis> I will still try to post my reviews later tonight if github behaves
<ijohnson> pedronis: of course, we can look at it all again tomorrow
<pedronis> ijohnson: thank you
<pedronis> ijohnson: to be clear, feel free to accept or tweak my suggestions in the two docs
 * pedronis eods
<ijohnson> yes
<ijohnson> have a good evening pedronis
<mvo> bye pedronis
<cachio> mvo, is it ok https://paste.ubuntu.com/p/HqQP9Pfbhd/ ?
<cachio> mvo, because this is making fail the fix for the create user 2 test
<mvo> cachio: this smeels like a bug
<mvo> cachio: if you run "snap managed" after "snap remove-user", does it report true?
<cachio> mvo, exactly
<cachio> and initially was false
<zyga> cachio: do you have a shell there?
<zyga> cachio: the state has all the info we need to grok that
<cachio> zyga, sure, 1 second
<mvo> cachio: meh, that sounds like a bug, quite annoying
<cachio> mvo, zyga https://paste.ubuntu.com/p/Q4D8nM5Hth/
<zyga> cachio: cool, it's even up front
<zyga> mvo is logged in :)
<cachio> mvo, the good part is that we found it
<zyga> mvo: you own plenty of devices :)
<zyga> mvo: is that master or release?
<mup> PR snapd#6708 closed: tests/main/buildmode: verify usability of PIE hardening for deb packages <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<mvo> zyga: master
<mvo> zyga: delete-user is not released yet
<zyga> good
<mvo> zyga, cachio it's a bit confusing, we have code that should remove the user
 * mvo looks
<zyga> https://www.irccloud.com/pastebin/0ANbDwIR/
<zyga> golang's brilliant array API
<zyga> n = 0
<zyga> I guess authStateData.Users becomes an empty slice
<zyga> is it possible that this is not a snapd bug
<zyga> but a bug in the prepare/restore
<zyga> e.g. we restore a state that has auth
<zyga> cachio: is the test machine backup's copy of state.json also authenticated?
<cachio> zyga, checking
<cachio> zyga, I dont see it https://paste.ubuntu.com/p/2GXmN3dcv8/
<cachio> users":null
<cmatsuoka> cachio: tpm is (or seems to be) working in the google-tpm backend, but secure boot is disabled. are we using the snakeoil ovmf vars?
<zyga> cachio: so that limits the bug
<zyga> cachio: thanks!
<zyga> hmm
<mup> PR snapcraft#2953 closed: meta: remove remaining `__dict__` and key list usage in snap <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2953>
<cachio> zyga, I think the problem comes because
<cachio> userdel --extrausers -r mvo
<cachio> userdel: mvo mail spool (/var/mail/mvo) not found
<zyga> oh
<zyga> is this test failing on core18?
<zyga> perhaps /var/mail/ is not writable
<mvo> cachio: oh, so this command fails and we don't get an snap delete-user error?
<zyga> cachio: does userdel fail?
<mvo> cachio: I need to get dinner now, please either put what you find in the standup doc or sent a mail, I can work on this in my morning
<mvo> (or someone else can tonight of course if someone is around :)
<cachio> mvo, sure
<zyga> uh
<cachio> I'll continue digging
<zyga> mvo: we do something silly
<zyga> 	if output, err := exec.Command("userdel", cmdStr...).CombinedOutput(); err != nil {
<zyga> 		return fmt.Errorf("cannot delete user %q: %v", name, OutputErr(output, err))
<zyga> 	}
<zyga> is err going to be != nil if command were false?
<zyga> or is that buried in cmd?
<zyga> there's ProcessState.ExitCode
<zyga> I don't think we ever check that!!!
<zyga> mvo: I'm in another topic, sorry
<zyga> paging out
<zyga> it could be a dead end, just not digging there more now
<cachio> zyga, np, I'll leave all the findings in the doc
<zyga> thanks!
<ijohnson> zyga: CombinedOutput() will return non-nil err if the exit code is not 0
<zyga> ijohnson: in that case I don't see any obvious bugs in that code
<ijohnson> yeah looks pretty typical code to me
<ijohnson> just the snippet you posted
<ijohnson> cachio: do you want me to take a look at this too? not clear to me if this is blocking the release or what the bug is that folks are looking at now
<cachio> ijohnson, https://paste.ubuntu.com/p/k5wqvYMXKz/
<cachio> userdel --extrausers is breaking everything
<cachio> snap remove-user works well
<cachio> but we have a test which uses userdel --extrausers
<ijohnson> ooh looks like fun
<pedronis> well userdel will not update snapd internal status
<pedronis> for sure
<cachio> and is breaking the next one
<ijohnson> hmm, can we have this test use a different user?
<ijohnson> to add/remove ?
<pedronis> but state restore should bring it back to sane, no?
<ijohnson> that too
 * pedronis going to have dinner
<cachio> ill update the test to do snap remove-user instead of userdel
<cachio> ijohnson, does it make sense?
<ijohnson> cachio: which test is this
<ijohnson> remove-user ?
<cachio> yes
<ijohnson> looking
<cachio> ijohnson, also I updated the create user 2
<ijohnson> cachio: so the problem is that this test in the restore section runs `userdel` and that breaks a different test ?
<ijohnson> specifically the create-user2 test ?
<cachio> ijohnson, yes but there were also another error
<cachio> not sure which was causing that
<cachio> but the create user 2 test needed another fix which I am testing
<cachio> ijohnson, do you think we can use snap remove user instead of userdel?
<ijohnson> cachio: I think it makes sense to have the remote-user test run `snap remove-user` instead of userdel, because as samuele mentioned, `snap create-user` does more than just manipulate extrausers, so to be safe we should undo all of the things that `snap create-user` did and the right way to do that is `snap remove-user`
<ijohnson> sorry s/remote-user/remove-user/
<ijohnson> tldr yes use `snap remove-user`
<cachio> ijohnson, nice
<cachio> I am updating the tests
<ijohnson> great, let me know when there's something for me to review
<cachio> ijohnson|lunch, sure, in few minutes it will be ready, I am still waiting for the tests
<ijohnson> cachio: I see that 8212 failed on opensuse's repos being unavailable
<ijohnson> cachio: do you want me to submit a PR moving opensuse to unstable ?
<cachio> ijohnson, #8205
<mup> PR #8205: tests: just remove user when the system is not managed on create-user-2 test <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8205>
<cachio> ijohnson, trying once and then we try moving to unstable
<ijohnson> Okay
<ijohnson> My internet seems to have gone down just now
<ijohnson> alright I'm back now, dns problem for some reason
<ijohnson> cachio: approved 8205 for you (again)
<pedronis> ijohnson: cmatsuoka: I submitted now a couple of reviews to PRs of yours that I failed before because of github having issues
<ijohnson> pedronis: ack thanks I'll look now
<cachio> ijohnson, thanks!!!
<cmatsuoka> pedronis: ack, thanks
<cachio> ijohnson, still failing on opensuse
<cachio> ijohnson, do you want to move to unstable or I can do it
<ijohnson> cachio: I can do it if you like
<cachio> ijohnson, sure
<cachio> I'll approve it
<ijohnson> cachio: I see that opensuse 15.0 has `manual: true`, do you remember why that is there?
<cachio> ijohnson, it is intentional
<cachio> we are just testing on tumbleweed and leap 15.1
<ijohnson> cachio: https://github.com/snapcore/snapd/pull/8213
<mup> PR #8213: spread.yaml: mv opensuse 15.1 to unstable <Skip spread> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8213>
<mup> PR snapd#8213 opened: spread.yaml: mv opensuse 15.1 to unstable <Skip spread> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8213>
<ijohnson> cachio: are we good to merge that 8213 now then?
<cachio> ijohnson, no
<cachio> https://travis-ci.org/snapcore/snapd/jobs/655836451#L644
<cachio> tumbleweed is also failing
<ijohnson> oh no :-(
<cachio> we need to move both to unstable
<zyga> perhaps merge one
<ijohnson> I'll push an update to my PR and move tumbleweed there too
<zyga> and open the next
<ijohnson> cachio: then we merge my tumbelweed PR and you can merge master into your users PR?
<cachio> yes
<ijohnson> k
<mup> PR snapd#8213 closed: spread.yaml: mv opensuse 15.1 to unstable <Skip spread> <â  Critical> <Created by anonymouse64> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8213>
<cachio> ijohnson, merged and pushed my branch again
<ijohnson> cachio: great, thanks
<cachio> ijohnson, I hope this time it is green
<ijohnson> me too :-)
<mateuszm> Hi guys, are you knowledgeable about Ubuntu 20.04's apparent move from deb to snap for the Software Center, and snap to dev for gnome-{calculator,logs,characters}, by any chance? I had a surprise yesterday when I apt-get updated my 20.04 pre-release install
<mvo> ijohnson, sergiusens : thanks so much for taking care of the test failures!
<mateuszm> Basically, folks who have an up-to-date pre-release install are in the situation where they have two versions of each of the calculator, log viewer, and character apps: the snap version (old) and the deb version (new). I'm wondering if that means I have to manually uninstall the snap version? And reciprocally, if I have to manually install the snap
<mateuszm> version of the Software Center (i.e. the snap store)?
<mvo> mateuszm: best to ask the #ubuntu-desktop people about that, this channel is mostly about the development of snapd itself
<mvo> (and sorry, but I have no real insights here :/
<mateuszm> mvo Ah great, OK, thanks a lot!
<cachio> ijohnson, I'll be afk, I ned to go to the kinesiologist
<ijohnson> cachio: ack I'll merge if your PR goes green / push updates as necessary
<cachio> thanks
<cachio> otherwise I'll do it once I'm back
<mvo> ijohnson: please push a green master to all the 2.44 tagged PRs if you don't mind :)
<ijohnson> mvo: sure
<mvo> thank you!
<ijohnson> have a nice evening mvo
<mvo> ijohnson: have a good day too
 * mvo waves
<ijohnson> cachio: just fyi the ubuntu spread test failed due to a unit test failure from pstolowski's thing that he's working on a fix for, so I restarted it, I think it should probably pass when we re-run it I think
 * zyga has more or less working session-tool, with lots of practical details right
<zyga> kind of late
<zyga> let's move onto testing via spread
<mup> PR snapd#8212 closed: tests: updating checks to new test account for snapd-test snaps <Simple ð> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8212>
#snappy 2020-02-28
<zyga> I'll EODnow
<zyga> tests in spread are more comprehensive
<zyga> tomorrow I'll rebase on master and propose
<cachio> ijohnson, nice, thanks
<zyga> Uh
<zyga> Tired
<mborzecki> morning
<zyga> hey
<zyga> oooh
<zyga> my tests passed
<zyga> mborzecki: I massaged that silly session tool more
<zyga> mborzecki: and learned a few interesting things along the way
<mborzecki> zyga: hey
<zyga> mborzecki: for instance, certain invocations of su/sudo spawn all the session services
<zyga> mborzecki: and that may include pulseaudio, bluetooth, gpg daemon, apt daemon and a hell lot more
<zyga> mborzecki: and they stick around
<zyga> mborzecki: they are shut down asynchronously, roughly 10-20 seconds later
<zyga> mborzecki: I think this could explain some cases of tests seeing weird processes
<mborzecki> hahah
<zyga> what is worse is that this is per-distro
<zyga> it depends on PAM configuration
<mborzecki> how come it evolved to be so complex
<zyga> the upside is I know how to handle that
<zyga> but it's not clear how to handle that for root
<zyga> for non-root that's just loginctl kill-user test
<zyga> for root I think we could enumerate sessions, kill all but the ssh incoming remote session
<zyga> that would reliably shut stuff we run between invocations
<zyga> _except_ if that populates the remote session
<zyga> then we're SOL
<mborzecki> in the meantime i'm trying differnt daily images in hope of triggering https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1865063
<mup> Bug #1865063: snapd package hangs on deb postinst <focal> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1865063>
<zyga> mborzecki: ready for the sprint?
<zyga> oh
<zyga> I remember hearing about it
<zyga> mborzecki: what does postinst do?
<zyga> mborzecki: could this be arm64?
<pstolowski> morning
<zyga> hey
<zyga> is master better
<zyga> I heard some horror stories from yesterday
<mborzecki> hmm nothing super werid about postinst
<zyga> mborzecki: does it interact with snap?
<zyga> as in, run anything that would have it wait for snapd that's panicking
<zyga> I stopped working at 2AM
<zyga> please don't expect me to be around much today
<zyga> I need to prepare for the sprint, specifically the apparmor prompting demo needs some work
<mborzecki> zyga: no not really, there's services started ofc, so unless snapd was stopped it will be started on install and may do things it does on startup, like rebuilding seccomp profiles etc
<zyga> and I have a haircut at 10:30
<mborzecki> wow, haircut? :)
<zyga> mborzecki: anything in autogen postinst?
<zyga> mborzecki: I call it yak shaving
<zyga> hmmm
<zyga> mborzecki: and speaking of PAM
<zyga> mborzecki: my test passed everything but debian
<zyga> both sid and 9 hang
<zyga> time to debug
<zyga> oh well
<zyga> I'll go upstairs and make another coffee
<zyga> I feel so sleepy still
<zyga> daughter woke me up at 6:40 by kicking me in the head
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/8083 ?
<mup> PR #8083: spread, data/selinux: add CentOS 8, update policy <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
<mborzecki> hope we could land it today, as there's some selinux fixes included
<mborzecki> mvo:  hey
<mvo> hey mborzecki
<zyga> mborzecki: yep
<pedronis> hi, #7999 and #8185 need 2nd review.  #8185 shows some problems with test/mock code org, but I don't think it should be blocked on that.
<mup> PR #7999: devicestate: allow encryption regardless of grade <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999>
<mup> PR #8185: tests: add uc20 kernel snap upgrade managers test, fix bootloadertest bugs <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8185>
<pedronis> see my comment here: https://github.com/snapcore/snapd/pull/8185#discussion_r385579873
<zyga> mborzecki: done
<zyga> I'm off for a yak shaving session
<zyga> o/
<zyga> zyga.shave()
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/8083 ?
<mup> PR #8083: spread, data/selinux: add CentOS 8, update policy <Squash-merge> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
<mborzecki> pstolowski: there's some selinux bits in there
<pstolowski> mborzecki: will do
<mborzecki> pstolowski: thanks!
<pedronis> mborzecki: hi, I made an high-level comment in #8191
<mup> PR #8191: [RFC] cmd/snap-recovery-chooser: add a recovery chooser <Needs Samuele review> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8191>
<mborzecki> pedronis: thanks, it's totally up for discussion, we can surely brainstorm in FRA
<pedronis> mborzecki: ok, also to clear we quite likely will need that kind of JSON I described somewhere in snapd, because snapd will a API endpoint to list the recovery systems
<pedronis> *will have
<pedronis> #8187 also needs a 2nd review
<mup> PR #8187: boot: misc UC20 changes <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8187>
<mup> PR snapd#8083 closed: spread, data/selinux: add CentOS 8, update policy <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
<mborzecki> mvo: can you cherry-pick the patch? ^^
<zyga> re
<zyga> I think I know why debian is failing now
<zyga> awk/gawk probably
<mvo> mborzecki: yes, thank you!
<zyga> running a test to confirm
<zyga> I'll take a shower, my face is full of sharp pieces of hair
<mvo> mborzecki: done
<mborzecki> mvo: thanks!
<mup> PR snapd#8214 opened: tests: test that after "remove-user" the system is unmanaged <Created by mvo5> <https://github.com/snapcore/snapd/pull/8214>
<ogra> zyga, sorry, i was at embeddedworld this week, i havent used snapd-docker for a long time, technically it should still work, practically i think some defaults would need updating (IIRC it points to old releases etc)
<pedronis> mvo: hi, still fixing tests issues?  as I mentioned there are UC20 things needing 2nd review, but maybe mborzecki is on those already
<mvo> pedronis: in a meeting right now, was mostly on tests+2.44 cherry-picks today
<mborzecki> pedronis: i've updated 8187, looking at 8185 now
<pedronis> thx
<mborzecki> zyga: so review tools is updated now?
<zyga> mborzecki: dunno, I didn't hear anything about that
<pedronis> mborzecki: updated for which issue?
<pedronis> I think it has been updated for the setgid changes
<mborzecki> pedronis: snapd setgid
<zyga> shall we merge the revert then?
<pedronis> in principle yes,  but really for mvo to decide, I see the PR is running tests atm, #8181
<mup> PR #8181: packaging: revert "work around review-tools and snap-confine" <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8181>
<mborzecki> pedronis: yeah, restated them just now, fwiw the change looks ok
<mup> PR snapd#8215 opened: interfaces: make the network-status interface implicit on classic <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8215>
<mborzecki> pedronis: heh, missed that odd wording thing when i moved the comments around
 * pstolowski early lunch and sprint-related errand
<mvo> pedronis, zyga +1 for reverting the setgid change
<mborzecki> interestin failure with nonce is invalid https://paste.ubuntu.com/p/6F9z9rWZDy/
 * zyga debugs the debian issue
<zyga> easy to repro, just unclear why it hangs in something that passes elsewhere
<mborzecki> heh when POSTing to /api/v1/snaps/auth/sessions there's sometimes 503 service unavailable recived back
<zyga> so it's not mawk vs gawk
<zyga> something more subtle ...
<zyga> huh
<zyga> NOW it works?
<zyga> what did I fix
<popey> https://forum.snapcraft.io/t/error-cannot-communicate-with-server-timeout-exceeded-while-waiting-for-response/15726
<popey> :(
<zyga> popey: that log is cut
<zyga> could you get more with journalctl -u snapd.service please
<zyga> ideally
<popey> ok
<zyga> journalctl -u snapd.service -o ... # e.g. -o cut
<zyga> or something similar
<zyga> this should give you all the logs
<popey> sorry, give me one command
<zyga> sure, one sec
<zyga> sudo journalctl -u snapd.service -o short | cat
<zyga> that ought to work
<popey> i do not believe you will learn more from that output :D
<popey> but okay :D
<zyga> popey: current output is cut
<zyga> but also, memory 1.7G
<zyga> ouch :/
<popey> ok, added to the forum post
<zyga> popey: does snap version now work?
<popey> snap version always worked
<popey> snap refresh didnt
<zyga> ok
<zyga> just checking id daemon is up
<zyga> how many snaps do you have?
<popey> 311
<popey> how many do you have? :)
<mup> PR snapd#8203 closed: netlink: fix panic on arm64 with the new rawsockstop code <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8203>
<zyga> popey: about a dozen per system
<zyga> popey: I think this is a real bug, just one we are not experiencing ourselves :)
<pedronis> we have performance improvements related to systems with many snaps coming this cycle thanks to changes the store is doing, but nothing immediate
<zyga> I guess the client times out, waiting for snapd to compute the response
<popey> oh dear
<zyga> popey: can you snap refresh foo # replace foo with one snap
<mborzecki> zyga: yeah, that'd be my guess, that's the client deadline context bit
<mup> PR snapd#8181 closed: packaging: revert "work around review-tools and snap-confine" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8181>
<mborzecki> iirc the deadline is quite generous though, 10s or so
<pedronis> popey: how big is your state.json for reference
<zyga> but that's weird, everything is async
<zyga> it must be slow to get the ansync response!
<pedronis> mborzecki: for historical and complexity reasons we do some things synchronously in the refresh case, it's an issue, it will improve a bit this cycle
<popey> 1269004
<zyga> popey: if you gzip it, how big would it be?
<zyga> anyway, that's probably not going to help
<pedronis> it's not the problem anyway, not mainly
<pedronis> here
<popey> 183847
<zyga> right, I suppose we block on O(N) requests somehow
<pedronis> zyga: yes, the bulk assert refresh work will help here
<zyga> hmmm
<zyga> I managed to reproduce a hand once on my machine
<zyga> then it's gone
<zyga> reproduces ok in spread
<zyga> ... what am I missing
<zyga> now it breaks on focal
<zyga> ok, feels like it's buffering
<zyga> added fflush
<mup> PR snapd#8173 closed: tests: adding arch-linux execution <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8173>
<popey> I found a workaround
<popey> https://forum.snapcraft.io/t/error-cannot-communicate-with-server-timeout-exceeded-while-waiting-for-response/15726/3
<ogra> popey, sosumi ?!? wow !
 * diddledan sues ogra
<popey> hah
<diddledan> live feed of new snaps as they appear: https://twitter.com/snapstats_org :-)
 * diddledan promotes
<diddledan> it's on a 30minute cycle
<diddledan> so the longest you'll be behind live is 29 minutes :-)
<popey> the day it gets overwhelmed in a 30 min period is a good day :D
<diddledan> aye. usually only one or two snaps per weekday
<popey> rarely zero per day
<popey> there was a day recently when something like 22 landed in the store
<diddledan> wow
<diddledan> the graph is fairly linear: https://snapstats.org/
<diddledan> those are weekly ticks
<zyga> diddledan: what are "developer counts"?
<zyga> number of developers publishing snaps?
<diddledan> the number of developers that have a published snap
<zyga> oh wow
<diddledan> i.e. the number of unique developer names on publicly visible snaps
<zyga> I wished for 2^X but
<mborzecki> diddledan: nice!
<diddledan> thanks :-)
<mborzecki> diddledan: how often is the snap count updated? daily?
<diddledan> every 30 minutes
<diddledan> but then it gets thinned out to one per day
<diddledan> ... at the end of each day
<ogra> hmm, who is admin on the forum ? i would like to edit the pi4 thread to remove the links to my experimental images (and point to the new official ones) but i seem not to be able to edit my own posts there
<zyga> ogra: hmmm
<zyga> not sure
<diddledan> I suspect popey can do that?
<zyga> mvo: ^
<diddledan> mvo would know for sure. good call.
<popey> link?
<diddledan> this one? https://forum.snapcraft.io/t/raspberry-pi-4-chromium-mir-kiosk/15725
<popey> dont think so
<diddledan> oh no. not that one
<diddledan> https://forum.snapcraft.io/t/support-for-raspberry-pi-4/11970/4 ?
<ogra> right ...
<popey> you know what would be better
<popey> put a readme in that folder and move the content out the way
<diddledan> speaking of pis. you see they dropped the 1GB model and reduced the 2GB price?
<ogra> yeah, i wanted to do that additionally
<ogra> but most people might find the thread so i wouldnt want to detour them through people.c.c
<diddledan> https://www.raspberrypi.org/blog/new-price-raspberry-pi-4-2gb/
<popey> but people might find people.c.c too
<ogra> yes, thats why i wanted to do it there additionally :)
<zyga> hey
<ogra> (do it: update readme etc)
<zyga> tests passed!!!
<zyga> awk is such a beast
<ogra> use sed :P
<diddledan> tests? pass? that's unpossible!
<diddledan> there must be something wrong
<ogra> awk is just for people that fear sed :)
<zyga> diddledan: I was telling myself that for a few hours
<popey> i have marked Steve's most recent post as "solution" so it's right at the top
<popey> which should help
<ogra> +1
<ogra> i have never tried to edit such an old post, is it normal that it loses editing capabilities over time ?
<popey> i guess
<popey> discourse be discourse
<ogra> hmpf ..
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8216
<mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
<zyga> I think I cannot believe this really works
 * zyga runs more tests
<mup> PR snapd#8216 opened: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
<ijohnson> pedronis: sorry I didn't finish those docs yesterday, please take a look at the booting doc again I finished the expected kernel mounting section just now
<ijohnson> pedronis: also I went back and move some things that were in yellow in the boot envs doc to actual sentences and such in the "Run /var/lib/snapd/modeenv" section
<mup> PR snapd#8187 closed: boot: misc UC20 changes <UC20> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8187>
<ogra> zyga, https://forum.snapcraft.io/t/requesting-uninstall-reason-via-popup/15655 ... shouldnt the teardown of the namespace on uninstall kill all processes and their kids ?
<zyga> in a call
<zyga> I'll check soon
<zyga> cmatsuoka: that was the bult-in laptop mic
<zyga> cmatsuoka: I often use the external mic
<zyga> cmatsuoka: and I sometimes use the built-in imac mic
<ijohnson> ogra: could be a bug with systemd timers that are created for snaps
<cmatsuoka> zyga: the sound quality was quite good frequency-wise, but it picked some background noise
<mborzecki> https://www.reddit.com/r/linux/comments/fa8ewy/ubuntu_2004_lts_to_revert_gnome_calculator_and/ heh
<diddledan> regarding that link, zyga, and ogra, does snapd not set up a cgroup to collect a snap's processes and kill the cgroup when it removes a snap?
<zyga> diddledan: no
<zyga> diddledan: not yet
<diddledan> aah. that's coming?
<zyga> diddledan: not exactly that
<zyga> diddledan: we cannot kill some
<diddledan> oh, I see
<zyga> diddledan: because of compatibility
<zyga> diddledan: but we can probably kill most (all desktop apps)
<diddledan> bah. compatibility be damned :-p
<zyga> diddledan: what will more likely happen is reverse
<zyga> diddledan: snapd will tell you "you cannot remove this snap because it is still running"
<zyga> diddledan: close "app foo" and try again
<zyga> diddledan: this is compatible and in line with other work
<diddledan> regarding uninstall surveys. if we want to support such a feature we could add a snap.yaml field for "uninstall url" that fires up the system web browser or prints the url on the terminal for non-gui installs
<diddledan> that makes sense. I like that, rather than just killing stuff, give the user the choice
<diddledan> I think uninstall surveys are a bit of an antipattern though
<ogra> as long as there is also a --force option for admins that dont want to give heir users choices ;)
<diddledan> I see them as the developer saying "I've annoyed you enough to make you uninstall my app. let me annoy you even more with this obnoxious survey."
<diddledan> I get that the developer wants to understand what they did wrong. but an uninstall survey is the wrong way IMO
<diddledan> however, snap needs to be pragmatic, and it is a common enough pattern that we might be wise to bend to the will
<ijohnson> IMHO people should be able to uninstall snaps without going through a survey
<ijohnson> OTOH, we should at least enable that use case for developers that want it
<diddledan> that's my view, ijohnson
<ijohnson> yeah agreed diddledan
<ijohnson> not sure what the right technical solution is though
<diddledan> stop stealing my ideas. get your own ;-p
<ijohnson> haha but it's so hard to think on my own
<diddledan> I hear that!
 * diddledan goes to find a sheep to follow
<roadmr> ð
<diddledan> aww, that emoji doesn't work here :-(
<diddledan> looks to be brave-specific failure thouhg
<diddledan> it works fine in my terminal
<roadmr> :(
 * diddledan tries firefox
<ijohnson> diddledan: do you use the lounge snap thing I seem to remember you worked on a while ago?
<diddledan> yes, I do
<ijohnson> seemed really cool but I haven't given it a try yet
<diddledan> I'm chatting in it right now o/
<diddledan> popey and Wimpress did a great job enabling ssl/tls support the other day
<ijohnson> nice
<diddledan> which means that if you access it through a mobile device you can enable push notifications
 * cachio lunch and school
<zyga> re
 * zyga had a bowl of Å¼urek for dinner
<mup> PR snapd#8170 closed: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<pedronis> ijohnson: I made some suggestion and add some bits to the doc
<zyga> ijohnson: thank you for the review!
<ijohnson> thanks pedronis looking now
<ijohnson> yaw yga
<ijohnson> zyga
<mup> PR pc-amd64-gadget#38 opened: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
<zyga> ijohnson: check this out :) https://github.com/snapcore/snapd/pull/8216/files#diff-a8fce2de6a6829d98f798117050b6c93R59
<mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
<ijohnson> zyga: ah much easier to read thanks
<zyga> it's not a heredoc but has the same property
<zyga> just a multi-line value :)
<ijohnson> yes multi-line is what I was after, heredoc was just the first thing I could think of that was multi-line :-)
<zyga> I want to make sure this really works
<zyga> spawned this test across the fleet, with ... -repeat 100
<zyga> it's a quick test
<zyga> but this gives me more confidence
<zyga> brb, coffee
<zyga> back
<zyga> daughter asleep :)
<zyga> so quiet upstairs
<zyga> let's try to solve the issue I've built this for :)
<zyga> holly molly
<zyga> zyga@focal:~/go/src/github.com/snapcore/snapd/tests$ git grep 'su -l' | wc -l
<zyga> 114
<zyga> that's a lot of tests to fix
<zyga> ijohnson: ^
<ijohnson> oh boy
<zyga> there's one interesting thing
<zyga> linger
<ijohnson> linger?
<zyga> https://www.freedesktop.org/software/systemd/man/loginctl.html < check for "linger"
<zyga> Enable/disable user lingering for one or more users. If enabled for a specific user, a user manager is spawned for the user at boot and kept around after logouts. This allows users who are not logged in to run long-running services. Takes one or more user names or numeric UIDs as argument. If no argument is specified, enables/disables lingering for the user of the session of the caller.
<zyga> it means we'd have a "test" user session that we can always hop into
<ijohnson> ah seems cool
<zyga> probably faster than spawning and shutting one for each command
<zyga> I'll explore some more
<zyga> I wonder if this means I can ssh into a system
<ogra> pfft ... ln -s /usr/bin/nohup /usr/bin/linger
<zyga> start a systemd user session
<ogra> :P
<zyga> and log out
<zyga> and log in
<zyga> and it's still there
<zyga> with all dbus stuff and all the other good bits
<zyga> ogra: that's so 90s :-)
<ogra> :D
<zyga> ogra: for context: https://github.com/snapcore/snapd/pull/8216
<mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
<zyga> ogra: you'd be proud of me, it's shell
<zyga> and awk
<zyga> and not even bash
<zyga> and works with mawk
<ogra> well, awk always makes me shudder :)
<mtlsw> hi guys, I have two users, 1 has customizations(my account) and another has no activity(newly created) -- theres' a snap app that runs well on both but only on the first instance.  Is there a "log" for snap?
<pedronis> ijohnson: I don't think I'll get to propose the separation of responsabilities between boottest and bootloadertest today, it's a bit more involved than I had hoped
<ijohnson> pedronis: ok, safe travels, see you on Monday
<NickZ> How do I set up an org on snapcraft.io?
<mup> PR snapd#8205 closed: tests: just remove user when the system is not managed on create-user-2 test <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8205>
<Lukewh> NickZ: orgs don't exist in the snap store. You can create an account, register snaps with that account and add other accounts as collaborators. They will have complete access, but the org will be listed as the publisher
<NickZ> Right, I just figured that out
<Lukewh> :)
<Lukewh> sorry for the late reply
<zyga> https://github.com/snapcore/snapd/pull/8216 is green :)
<mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
<diddledan> zyga, something must be wrong. I don't trust passing tests
<zyga> I ran that new tests across all enabled backends 100 times, it passed
<diddledan> the worst tests are the ones that pass first time out of the box
<zyga> it's so weird
<zyga> (after finding edges that broke in this for the past week)
<zyga> diddledan: this one _eventually_ got to work, I spent far too much time on this tool
<diddledan> :-)
<fundatillus> I have one snap that won't start on my system and I receive no errors.
<fundatillus> The snap is standard-notes, but all others work (atom, chromium, signal, etc).
<fundatillus> I've reverted and also switched to --edge with no luck.
<fundatillus> Any tips on troubleshooting?
<fundatillus> Also removed and reinstalled.
<fundatillus> My Google-fu is failing me...
<mvo> fundatillus: can you check in "dmesg" if you see andthing that looks like "denials"
<diddledan> fundatillus, try running `standard-notes` in the terminal - I'm seeing an error here when I do that
<diddledan> specifically: Error: ENOENT: no such file or directory, open '/home/dllewellyn/snap/standard-notes/4/.config/Standard Notes/user-preferences.json'
<fundatillus> I'm not seeing any denial messages.
<diddledan> oh, the error is only first time - repeated attempts to launch silently fail though
<fundatillus> The last entry having to do with standard-notes is about 5000 seconds (?) ago:
<fundatillus> [34486.619880] audit: type=1400 audit(1582902701.832:432): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.standard-notes.standard-notes" pid=19147 comm="apparmor_parser"
<fundatillus> I've contacted the publisher and they aren't able to duplicate...
<fundatillus> I'm running kubuntu 19.10, if that matters.
<mvo> fundatillus: I just tried on my 19.10 ubuntu system and it's ok here, sorry that this is not helpful. you could try (in a terminal): "snap run --strace standard-notes" and see if there is anything obvious(ish)
<fundatillus> Checking it now... weird, it won't let me redirect it to a file. But there is definitely something going on, exit with code 1
<fundatillus> Lots of errors like this:
<fundatillus> [pid 25508] openat(AT_FDCWD, "/snap/standard-notes/6/gnome-platform/usr/lib/locale/en_US.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
<fundatillus> ll
<fundatillus> [pid 25704] openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
<fundatillus> Looks like it's looking for some locale files?
<fundatillus> I'm seeing en and en_US locale directories, but not the en_US.UTF-8 it's looking for...
<mvo> fundatillus: exit 1 is good, pasting (to e.g. pastebin.ubuntu.com) the last couple of lines before the exit 1 is probably helpful.
<mvo> fundatillus: unfortunately I will have to go to bed soon here in my timezone but hopefully someone else in the channel can help
<fundatillus> Thanks mvo. Appreciate the help.
<mvo> fundatillus: my pleasure, good luck!
<NickZ> jdstrand: did you reserve the freedoom snap name?
<diddledan> NickZ, there's a freedoom package in the Ubuntu repository so, yes, it will have been reserved
<NickZ> ah, I see
<NickZ> I'll just request it
<diddledan> bingo :-)
<diddledan> unfortunately people are seeing the reserved message and assuming that means they're not allowed to claim it
<jdstrand> NickZ: yeah, what diddledan said (and no, I didn't)
<NickZ> ah hah, I saw that you had released a chocolate doom snap and I had guessed :)
<diddledan> how do you like your hellspawn? covered in chocolate, natch
#snappy 2020-02-29
<zyga> I reproduced the case where snapd hangs on focal update
<zyga> root       19671  0.0  0.0   2600  1692 pts/1    S+   15:21   0:00 /bin/sh /var/lib/dpkg/info/snapd.postinst configure 2.43.3+git1.8109f8
<zyga> root       19751  0.0  0.1  20592  3608 pts/1    S+   15:21   0:00 /bin/systemctl start snapd.autoimport.service snapd.core-fixup.service snapd.recovery-chooser-trigger.service snapd.seeded.service snapd.service snapd.snap-repair.timer snapd.socket snapd.system-shutdown.service
<zyga> snapd is not seeded correctly
<zyga> has no changes
<zyga> but I'm also surprised by starting of _all_ of those units here
<zyga> Setting up snapd (2.44~pre1+20.04) ...
<zyga> Installing new version of config file /etc/apparmor.d/usr.lib.snapd.snap-confine.real ...
<zyga> Created symlink /etc/systemd/system/multi-user.target.wants/snapd.recovery-chooser-trigger.service â /lib/systemd/system/snapd.recovery-chooser-trigger.service.
<zyga> snapd.failure.service is a disabled or a static unit, not starting it.
<zyga> snapd.snap-repair.service is a disabled or a static unit, not starting it.
<zyga> seeding never completes, though https://www.irccloud.com/pastebin/CUEBrm6F/
<zyga> state.json from this wonky state https://www.irccloud.com/pastebin/wYgT3mTZ/
#snappy 2020-03-01
<mup> Issue pc-amd64-gadget#20 closed:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 closed: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 closed: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> PR pc-amd64-gadget#35 closed: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
<mup> PR pc-amd64-gadget#37 closed: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> PR pc-amd64-gadget#38 closed: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
<mup> Issue pc-amd64-gadget#20 opened:  GRUB shows "Trying to terminate EFI services again" and blocks boot for a while <Created by zyga> <https://github.com/snapcore/pc-amd64-gadget/issue/20>
<mup> Issue pc-amd64-gadget#30 opened: Git tags and versioning <Created by lopezem> <https://github.com/snapcore/pc-amd64-gadget/issue/30>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<mup> PR pc-amd64-gadget#35 opened: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
<mup> PR pc-amd64-gadget#37 opened: Drop duplicate grub.cfg-* <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/37>
<mup> PR pc-amd64-gadget#38 opened: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
