#snappy 2016-01-11
<dholbach> good morning
<JamesTait> Good morning all; happy Monday, and happy Learn Your Name In Morse Code Day! ð
<zyga> I've pushed some code related to the capability hook system
<zyga> https://github.com/ubuntu-core/snappy/pull/310
 * zyga now focuses on security again
<kyrofa> Good morning
<kyrofa> Grr... Anyone else having trouble getting into the weekly?
<kyrofa> mvo, I see you're in there
<kyrofa> It's telling me "It's taking too long to connect you to this video call." I could have told it that
<kyrofa> sergiusens, I can't seem to be able to get into the weekly
<sergiusens> kyrofa, yeah, it has just been cancelled, no one could
<kyrofa> sergiusens, okay good
<sergiusens> given the issue, I'm going to move today's standup a bit into the future
<kyrofa> sergiusens, fine by me
<sergiusens> my morning has been bad so far, landline and dsl died for a bit, then came back, no this meeting gets cancelled (for which I spend time prepping for), meh
 * sergiusens plans on going for a run now
<sergiusens> kyrofa, lets discuss with elopio then what he found for 1.x
<kyrofa> sergiusens, ah, sorry man. Yeah go run. Sounds like a plan for the meeting
<sergiusens> kyrofa, hey, you already reviewed it all? snap yaml?
<kyrofa> sergiusens, yessir
<kyrofa> sergiusens, my familiarity with the codebase is still obviously growing though, so I'm sure elopio's review will be more helpful
<kyrofa> (I lack some context around these things)
<kyrofa> sergiusens, though the changes reminded me of a question: when I throw exceptions in the plugin it turns into a nice error message and halts the process, which means you must have a catchall somewhere. However, when an exception is thrown in, say, wrap_exe the thing dies with an ugly stack trace. Where is that catchall?
<sergiusens> kyrofa, wrap_exe in the new code base has a catch all
<sergiusens> kyrofa, it is something I want to discuss though
<sergiusens> it doesn't seem to be the best of approaches
<kyrofa> sergiusens, alright we can put that on the docket as well
<sergiusens> kyrofa, it's here now https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/main.py#L92
<sergiusens> kyrofa, but I'd rather we only capture our own exceptions
<kyrofa> sergiusens, and explicitly fail ourselves?
<kyrofa> sergiusens, would certainly make actual errors easier to debug
<sergiusens> kyrofa, I didn't go for a run
<kyrofa> sergiusens, haha, you should!
<sergiusens> kyrofa, lets try a hang out and go over it if you want
<sergiusens> kyrofa, I would melt :-)
<kyrofa> sergiusens, hahaha
<kyrofa> sergiusens, alright let's do it. See if it works. Standup url
<sergiusens> sun is too strong today; it had been overcast these past days so it wasn't a problem to do a noon run, a bit humid, but not too hot :-)
<sergiusens> elopio, if you want to join even though I moved the standup, feel free to join
<elopio> I'm confused :)
<elopio> ahh, ok.
<kyrofa> sergiusens, internet go down again?
<elopio> sergiusens: one small detail I didn't mention. You wanted to get rid of the trusty pep8. I can split the static tests, and tell them to run only on the vivid/xenial lxc.
<sergiusens> kyrofa, elopio internet is back, I should start calling it internetz though
<sergiusens> that said, the handout is dead to me
<sergiusens> but you may have already dropped
<kyrofa> sergiusens, yeah we weren't sure how long you'd be out, so we dropped
<sergiusens> kyrofa, that's fine
 * zyga pushed the initial take on security
<sergiusens> summary is we ave the green light to get 1.0 out
<sergiusens> so lets do that
<zyga> https://github.com/ubuntu-core/snappy/pull/312
<kyrofa> sergiusens, agreed! I'd like to do it with you whenever you're ready
<sergiusens> kyrofa, that said, a webcam with something to demo would be cool; I think olli would allow expensing
<kyrofa> sergiusens, alright I'll see if I can throw something together :)
<olli> sergiusens, kyrofa yep
<olli> rickspencer3 also has an interest in that topic
<rickspencer3> https://code.launchpad.net/~rick-rickspencer3/+junk/rest-cam
<rickspencer3> I have a binary working that takes a shot, am now adding a rest api for it, and then will include a web page
<kyrofa> rickspencer3, I'm going to try and throw a face detector together
<rickspencer3> kyrofa, ok
<rickspencer3> so, what I am trying to do is make a snap that provides the camera part for you, that you can access over local host
<rickspencer3> so, you could do localhost:8082/api/photo and that will provide you a photo from the /dev/video0
<rickspencer3> alternatively, you can just for my project and keep the binary that I have working there already
<rickspencer3> (or you can do your own from scratch, of course, I'm just offering ;) )
<tedg> jdstrand: Is there a list of capability names that are already defined, and their schemas? i.e. for things like networking.
<kyrofa> Thanks rickspencer3, I'll check it out :)
<zyga> tedg: nope
<zyga> tedg: we haven't done that work yet
<zyga> jdstrand: hey, do you have a moment, I'd to get your feedback on something
<tedg> zyga: So then are snaps still having the security caps field in them?
<zyga> tedg: I haven't changed the meta-data yet, we're still working on it
<zyga> tedg: I'm pushing some code to github every day, have a look at that if you want
<zyga> tedg: there are still a few things that need to land before we can start defining new capability types
<sergiusens> zyga, did you seem my PR already? the one with the internal format?
<tedg> zyga: Is there a document that says which caps you're headed to though? Or is it just entirely organic?
<tedg> I mean, there has to be coordination with the security folks for instance.
<zyga> sergiusens: no, not yet, do you have a pointer handy?
<zyga> tedg: there's coordination and agreement on the design, actual capability types are not something we've looked at
<jdstrand> tedg: is there a list of capabilities: yes, they were definied in Brazil. I implemented them, renaming some based on feedback from niemeyer on how things should be named and will seek his approval for them (planned to do that this week)
<jdstrand> tedg: there is a command that can be used on a 1604 device to see them. let me get that for you
<tedg> jdstrand: Cool
<tedg> jdstrand: Where are they defined? In the snappy codebase?
<jdstrand> they are defined in the ubuntu-core-security package that is part of the os snap
<jdstrand> snappy install snappy-debug
<jdstrand> snappy-debug.security list -i
<zyga> jdstrand: can you please have a look at https://github.com/ubuntu-core/snappy/pull/312/files#diff-9cbf3db5a11d15acb53c4e907e03e558R24
<zyga> jdstrand: I'd like to hang apparmor and seccomp delta generators from each capability type using that mechanism
<jdstrand> let me send that email to niemeyer and CC you guys
<zyga> jdstrand: k
<zyga> jdstrand: specifically https://github.com/ubuntu-core/snappy/pull/312/files#diff-70fe37b72a9aa2d6bb98b9a35910a01cR39 adds this feature
<jdstrand> then I read that. give me just a minute
<jdstrand> I'll
<zyga> jdstrand: thanks!
<sergiusens> zyga, https://github.com/ubuntu-core/snapcraft/pull/215
<sergiusens> kyrofa, heh, you found my little change on raise e
<sergiusens> kyrofa, it is one of the reasons I mentioned that this strategy wasn't the best (one is nice for consuming, the other for developing)
<sergiusens> this is missing an env flag
<sergiusens> good catch!
<sergiusens> oh, it was elopio who saw it :-P
<kyrofa> sergiusens, haha, thanks for the props though
<zyga> sergiusens: thanks!
<zyga> sergiusens: ahh, I heard about this merge request :)
<zyga> sergiusens: quick question before reading everything, are hooks copied automatically?
 * jdstrand reads pull requests now
<jdstrand> zyga: fyi, typo in legacySecurtySystem
<jdstrand> should be legacySecuritySystem
<sergiusens> zyga, well, it is declarative in snapcraft; it's a hook in the internal format
<zyga> jdstrand: thanks, add a note so that I can fix it easily please
<elopio> sergiusens: I'm not sure I'm understanding this meta_legacy. So in the end, the snap will have a snap.yaml and a pcakge.yaml?
<sergiusens> elopio, yeah, until snappy fully grasps snap.yaml; once it does, we just rm meta_legacy.py and test_meta_legacy.py and remove on line of code in meta.py
<sergiusens> elopio, https://bugs.launchpad.net/click-reviewers-tools/+bug/1532842
<ubottu> Launchpad bug 1532842 in Snapcraft "New packaging format for 16.04" [High,In progress]
<elopio> sergiusens: got it. On the first pass, the branch looks really good. The code looks nicer.
<sergiusens> elopio, I took the opportunity to fix most of the code that I always said I'd fix later on :-)
<jdstrand> zyga: ok, so I think this all looks fine. basically, you have a list of securitySystems. then, when granting or revoking permissions, you loop through your list of securitySystems and apply anything that the capability defined for that securitySystem (and fail atomically to avoid a half granted/revoked state)
<jdstrand> zyga: today, you are focusing on hwaccess cause it is there, but (soon?) you'll add security capabilities and, additionally, move away from the hwaccess model
<jdstrand> zyga: at that point, it can handle both something like 'firewall-management' which is a pure security capability, and something like 'camera' for hardware access
<jdstrand> zyga: with hardware capability, we will support capability definitions that have lists of accesses, as opposed to just single file rules (ie, I want to define the 'foo' hw capability, so I can say '/dev/foo, some stuff in /sys/devices, this other thing, etc)
<rickspencer3> sergiusens, so, I have a Golang project
<jdstrand> zyga: does that summarize your direction?
<rickspencer3> when I run snapcraft on it, it doesn't rebuild my Go code
<rickspencer3> is there a switch I need to give snapcraft to make it rebuild?
<davidcalle> kyrofa: sorry for the half-baked snapcraft pull request, it's my first time with git/github :)
<sergiusens> rickspencer3, `clean`
<rickspencer3> snapcraft clean? snapcraft -clean?
<kyrofa> davidcalle, oh no worries, you're pretty much there, just missing the bug ref
<sergiusens> rickspencer3, or if still on <1.0 `snapcraft build`
<rickspencer3> sergiusens, how do I see which version I am on?
<rickspencer3> I am in Xenial
<sergiusens> rickspencer3, `snapcraft clean`
<rickspencer3> in classic
<sergiusens> rickspencer3, you will only have more than 1.0 if working from trunk
<kyrofa> rickspencer3, if you're not running from source you're < 1.0
<rickspencer3> ok
<rickspencer3> so, after clean, you just run snapcraft again?
<sergiusens> rickspencer3, our release plan is to release 1.0 today to everything; then 2.0 with all the breaking changes only and only to xenial
<rickspencer3> hmmm
<rickspencer3> ok
<rickspencer3> sergiusens, it is rebuilding a bunch of things that didn't change
<rickspencer3> I only changed one .go file
<sergiusens> rickspencer3, yeah; I can't start complaining enough with the inconsistencies of some of this logic which is why we made it all go away in 2.x and going to engineer something better
<rickspencer3> ok
<sergiusens> rickspencer3, clean is like running 'make clean' it makes everything go away
<rickspencer3> yeah
<rickspencer3> I want "rebuild what changed"
<zyga> jdstrand: yes, that's about right
<rickspencer3> I guess I could be more surgical about rm'ing things from the stage and snap dirs
<sergiusens> `snapcraft build [partname]` can build what you already built for a specific part but it really has a bunch of unworking corner cases
<zyga> jdstrand: I'll try to post initial apparmor work tomorrow
<zyga> jdstrand: to show you how we can stop using hwaccess and use entirely the new thing
<jdstrand> great
<sergiusens> kyrofa, btw, lets not throw away your lamp work and get it into the wiki and have that as an example (eventually)
 * rickspencer3 is dangerously close to having his rest-cam snap working
<kyrofa> sergiusens, agreed
<kyrofa> sergiusens, it's a deliciously complex example
<bellyfeel> is there a way to build a snap without downloading and installing the dependencies on my dev machine?
<rickspencer3> bellyfeel, yes, you can build on your device in the classic shell
<bellyfeel> rickspencer3: could you elaborate?
<rickspencer3> bellyfeel, so, I am writing a snap right now, without having the dependencies on my local machine
<rickspencer3> what I do is I edit on my desktop
<rickspencer3> then I push to my bzr branch
<rickspencer3> then, on my rpi2 I run snappy classic
<rickspencer3> and use snapcraft inside classic to build the snap
<rickspencer3> snapcraft takes care of putting all of my dependencies together for me
<rickspencer3> then, I just exit classic and install the snap to try it
<bellyfeel> forgive me, what do you mean by classic?
<rickspencer3> bellyfeel, so, if you get a very recent image
<rickspencer3> you can enable something called "classic dimension"
<rickspencer3> in there, you can use tools like snapcraft
<rickspencer3> and thus, build on your device instead of your desktop
<bellyfeel> Okay, nice. My image is from over the summer...
<rickspencer3> bellyfeel, oooh
<rickspencer3> yeah, you will find that snappy has changed some
<rickspencer3> and is much easier to use now
<rickspencer3> a lot of rough edges sanded off
<bellyfeel> sounds great, thanks for the help!
 * rickspencer3 proclaims that is web-cam snap kicks all other web-cam snaps in the a**
<rickspencer3> jdstrand, so let's say I want to find out from within my snap if a web cam is ready
<rickspencer3> so I can report status
<rickspencer3> like, test if one is connected
<rickspencer3> what would you suggest?
<rickspencer3> it will be from within a service, so it will have root
<jdstrand> rickspencer3: try to open the device and check the return code. if it failed, log something to stderr (which will show up in 'snappy service logs foo'
<rickspencer3> jdstrand, well, my goal is to return this over the web
<rickspencer3> so, I need to capture the results in my Go code
<jdstrand> is the service a web service?
<rickspencer3> jdstrand, yes
<rickspencer3> but I can run shell commands from in it
<jdstrand> is it the one that would be doing the camera access in the normal case?
<rickspencer3> yes
<rickspencer3> it already is
<rickspencer3> I just want to have an api call to get the status
<rickspencer3> so, you could write a smarter program
<jdstrand> ok, right, so have it try to open the camera-- if that fails, report that back to the user that it doesn't have access to a camera
<rickspencer3> jdstrand, can you give me a hint about a good shell command to try to open the camera?
<jdstrand> you could put that in a loop if you wanted (perhaps trying every 10 seconds, failing after 5 minutes (or something))
<rickspencer3> jdstrand, well, it's on demand
<rickspencer3> easier that way ;)
<jdstrand> you could when the user clicks on the web interface to take a picture check the return code of that
<jdstrand> 'that' meaning the service trying to take a picture but unable to
<jdstrand> in the future capabilities world, there might be a callback when the hardware is assigned (not sure if that is something zyga is thinking about)
<jdstrand> let me see about a shell command if you want to know up front
<jdstrand> rickspencer3: as for an api command to query the status, I don't know of a simple shell command. it sounds like you have a screengrab command. you could use that to try to do a screen grab, throwing away the picture if it was successful, and checking the error code if it was not
<rickspencer3> jdstrand, yeah, or I wonder if I can just tell fswebcam to do something, and see if it works
<rickspencer3> I'll figure something out
<elopio> huh, interesting discussion about packaging: https://lwn.net/Articles/670754/
<LefterisJP> Hey all. Got some questions about framework development. I am developing an Ubunt-Core framework that should always run a specific daemon on the background. Apps that use this framework only need to be able to contact this daemon via JSON-RPC (in the non-ubuntucore world)
<LefterisJP> Now for the framework what should be done to achieve the same? Make a dbus service inside the framework that would be listening for events from other apps and then translate those events to JSON rpc calls to the daemon that is running inside the framework?
<LefterisJP> Are there any nice framework examples for ubuntu-core to look at?
<kyrofa> sergiusens, alright, ready to continue when you get back
<sergiusens> kyrofa, yeah, one lets hop back onto the hangout in 5, sound good?
<kyrofa> sergiusens, sounds good
<bellyfeel> how do I enter the classic dimension
<sergiusens> kyrofa, in
<kyrofa> davidcalle, on your snapcraft PR, the commit message needs to contain the LP: #blah bit
<kyrofa> (your PR description and title were fine)
<jerryG> Chipaca: hi. hows it going?
<jerryG> kyrofa: hello. is there any mir example other than deb2snap with qt?
<jerryG> :{
<kyrofa> jerryG, not that I know of
<kyrofa> jerryG, might be a question for kgunn
<jerryG> kgunn: is there any mir example other than deb2snap with qt?
<kgunn> jerryG: so, before i dive into a convoluted answer, can i ask what your purpose is? like what are you trying to achieve/
<kgunn> ?
<pindonga> kyrofa, sergiusens q: for my PR for snapcraft I need to introduce a new dependency, so I packaged it up for xenial, only to find out now that travis runs tests on trusty
<kyrofa> pindonga, heh, indeed it does
<pindonga> what should I do? get this ported to trusty-backports?
<kyrofa> elopio, ^^ is probably a better question for you
<pindonga> would it be ok to vendorize this dependency?
<elopio> pindonga: wait for it.....
<elopio> ...
<elopio> pindonga: https://github.com/ubuntu-core/snapcraft/pull/202
<pindonga> kyrofa, or install the deps via pip? (though the snapcraft pkg would probably need to have the dep as a deb paackage too)
<pindonga> elopio, nice!
<pindonga> and just in time too :)
 * pindonga can wait for this to land
<pindonga> kyrofa, elopio in the meantime, here's the PR: https://github.com/ubuntu-core/snapcraft/pull/197
<sergiusens> pindonga, if you want to make the necessary changes in a PR to have everything done in travis through pip I will indeed welcome that
<elopio> kyrofa: how do I merge my branch with master? Do I squash the result, or something?
<sergiusens> pindonga, btw, I'm not sure beuno has synced with you with regards to the concept of 'grade' in snapcraft.yaml which might be nice to have (or getting a snap-id on first upload)
<kyrofa> elopio, yeah you can merge then squash, but rebasing is easier
<pindonga> sergiusens, tell me more
<sergiusens> elopio, git rebase -i master (standing on your branch)
<sergiusens> pindonga, I was hoping to have beuno take upon that task :-)
<pindonga> ok, I don't think he has yet
<kyrofa> elopio, the -i is "interactive." You only really need it if you want to alter specific commits (e.g. squashing)
<sergiusens> pindonga, grade in snapcraft is just information; the store and ubuntu core themselve have different logic depending on that
<sergiusens> pindonga, snap-id is a uuid which gets assigned by the store on first upload since name is only 'informational' or a desire of intent
<sergiusens> pindonga, of course there might be a roadmap to this and maybe this is fine, just want to make sure we have a clear road to traverse
<jerryG> kgunn:  I'm trying to get an app working that uses MIR in snappy stable.
<jerryG> kgunn:  using snapcraft
<pindonga> sergiusens, yeah, not sure where it stands
<bellyfeel> how do I enter the classic dimension?
<pindonga> I was working to get the upload bit done and then probably switching tasks
<beuno> pindonga, grade is an easy one
<jerryG> kgunn:  I'm also trying to get a 'test' app running so I can confirm mir should work
<beuno> pindonga, stable or unstable, they stop it from getting published to the wrong channel
<beuno> stable = stale & candidate
<kgunn> jerryG: when you say snappy stable you mean xenial?
<beuno> unstable = edge & beta
<sergiusens> kyrofa, 1.0 ANN is out
<jerryG> kgunn: stable and edge are the two listed here :https://developer.ubuntu.com/en/snappy/start/
<jerryG> kgunn:  do you have examples for a different channel?
<kgunn> brb
<jerryG> kgunn: k
<kyrofa> sergiusens, thanks! :)
<sergiusens> elopio, btw, do you plan to move us to testtools? :-)
<elopio> sergiusens: probably. We already need them for the examples and integration tests.
<elopio> sergiusens: would you like that we use it for the unit tests too?
<sergiusens> elopio, yeah, I love it
<sergiusens> I just kept with the status quo
<elopio> sergiusens: great then. We just need to move it to the build dependencies.
<elopio> sergiusens: I don't understand why do you want to use pip instead of apt. We can't use pip to build the package, right?
<sergiusens> elopio, no, we can't; but I don't want to use trusty packages either
<pindonga> elopio, right, pip would only work for the pure python pkg, not for the deb pkg
<sergiusens> it does make it easier for people wanting to venv as well
<sergiusens> elopio, so the snap_yaml branch is good to land?
<sergiusens> just triple checking
<sergiusens> I can wait, but I have no plans to change any code in there anymore
<elopio> sergiusens: let me just double check I understand everything. Once you land this, the snaps build with snapcraft won't work on snappy until they update the format expected too?
<sergiusens> elopio, everything keeps working
<sergiusens> elopio, thanks to the fact we still create package.yaml and readme.md
<elopio> sergiusens: okay, so go for it whenever you want.
<elopio> I hope that before removing those we will have the install and run tests ready, so things will break if somebody does something wrong.
 * elopio goes to have lunch and to cry listening to david bowie.
<kgunn> jerryG: so the most simple answer is 15.04 core only has the deb2snap mir example, and i've only been focused on what we're going to do with xenial...
<kgunn> also, there are some changes underway wrt frameworks for xenial, so even what i currently have i really don't want to publicize as it'll just end up changing in the end
<LefterisJP> hey all, my questions seem to have gotten no reply so will post them again.
<LefterisJP> I am developing an Ubuntu-Core framework that should always run a specific daemon on the background. Apps that use this daemon only need to be able to contact to it via local JSON-RPC calls(in the non-ubuntucore world)
<LefterisJP> Now for the framework what should be done to achieve the same thing? Make a dbus service inside the framework that would be listening for events from other apps and then translate those events to JSON rpc calls to the daemon that is running inside the framework?
<LefterisJP> Are there any nice framework examples for ubuntu-core to look at? Is DBUS the only way for apps to interact with a framework?
<kyrofa> sergiusens, so shall I go through and set fix released on all those bugs?
<kyrofa> sergiusens, the 1.0 ones, anyway
<sergiusens> kyrofa, sure
<sergiusens> kyrofa, and thanks
<bellyfeel> how do I enter the classic dimension?
<kgunn> bellyfeel: on the mail list snappy-devel@lists.ubuntu.com, there is a thread "classic mode (v1)" you might wanna read
 * sergiusens is off to aikido practice
<sergiusens> bbl
<rickspencer3> jdstrand, slangasek due to your suggestion, I am about to delete like 10 terrible lines of code and replace it with one good one
<rickspencer3> bellyfeel, first, you need to enable it, I think the command might be snappy enable classic (or similar)
<rickspencer3> and then you enter it with snappy shell classic
<bellyfeel> my image (edge) doesn't like the command "sudo snappy enable-classic" -- it gives an uknown command response
<kyrofa> sergiusens, so is there any way on 1.x to have a forking service?
<bellyfeel> there's a thread on askubuntu saying that the 16.04 LTS will have the classic dimension, I only have 15.04
<jdstrand> rickspencer3: nice :)
<rickspencer3> bellyfeel, right, like I said, you need a recent image
<bellyfeel> yea it's from today
<rickspencer3> oh, you need a recent 16.04 image
<bellyfeel> I'm not sure where to get a 16.04 image, there's only 15.04 posted
<rickspencer3> hmmm
<rickspencer3> jdstrand, so, that means I implemented that feature already
 * rickspencer3 brushes dirt from hands
<bellyfeel> rickspencer3, so my next question is... where can I find the 16.04 image?
<rickspencer3> bellyfeel, I'm not sure
<rickspencer3> I'm wondering if I sent you on a snipe hunt because it is not released yet
<rickspencer3> I don't see mvo online
<rickspencer3> bellyfeel, was there a link in the thread that kgunn linked you to
<rickspencer3> ?
<bellyfeel> nope, just info on how to enable it
<rickspencer3> bellyfeel, so, on 15.04, I think the best way to build on the device is by using lxc
<rickspencer3> but classic on 16.04 is much easier
<rickspencer3> hopefully someone who knows where to get the image soon will let you know
<jerryG> kgunn: I'm just trying to get a proof of concept to work.  Can I see what you have for xenial?
<jerryG> kgunn:  do you know of any1 that is using mir on stable?
<LefterisJP> Anyone knows if a framework's service's can be contacted with in ways other than DBUS? I am trying to turn a daemon which uses jsonrpc over a local http port into a snappy framework.
<kgunn> jerryG: i know darren landol (unsure irc nick) was doing something with mir on 15.04 using what was in the store
<kgunn> not sure exactly what
<kgunn> jerryG: for xenial, things are in flux, if you just want to see something run on top of mir there is this ~mir-team/+junk/snapcraft-qml-on-mir
<kgunn> but as i stated, it's not intented for using on a product of any sort, and it will change
<jerryG> kgunn: k thx
<enoch85> kyrofa, hey mate, what about working on the snap tomorrow? my schedule is cleared.
#snappy 2016-01-12
<kyrofa> enoch85, works for me-- I have a working apache
<enoch85> kyrofa, cool! :D
<rickspencer3> arg
<dholbach> good morning
<dholbach> kyrofa: shall I upload snapcraft 1.0 to regular xenial (not the ppa) for you?
<dholbach> mvo: do we want to change our docs on developer.u.c to mention 16.04 at some stage?
<mvo> dholbach: I think so, especially now that some changes are in the pipeline that will appear really soon. the whole system a/b stuff is obsolete and replaced by all-snaps for example. some environment varialbles are simplified
<mvo> etc
<dholbach> mvo: the a/b stuff and the environment variables are part of snappy/docs, right?
<mvo> dholbach: yes, the docs are not updated yet though, I put that on the todo
<dholbach> ok
<dholbach> and for developer.ubuntu.com/snappy/start - what would you suggest?
<dholbach> that we advertise which 16.04 channels?
<dholbach> do you know if 16.04 images for all different "targets" are built by us already?
<dholbach> mvo: ok, let's chat about it in a bit - I'll relocate to the office - brb
<mvo> dholbach: unfortunately not, we are transitioning the images right now and expect to have new images based on the all-snap architecture by the end of the week. at least for rpi2 and amd64
<mvo> dholbach: see you
<dholbach> ok cool - I'll file a bug so we can track the work
<dholbach> thanks
<dholbach> mvo: I filed https://bugs.launchpad.net/developer-ubuntu-com/+bug/1533099
<ubottu> Launchpad bug 1533099 in Ubuntu Developer Portal "Start advertising 16.04 on /snappy/start" [Undecided,New]
<zyga> good morning
 * zyga works on capability type interface, so that everything is an API, not a DSL
 * zyga thinks loudly: cap.Capability refers to cap.Type (iface) which can be a concrete BoolFileType which has interface methods for things like "grant permission(cap, snap)" "revoke permission(cap, snap)", internally the type will also know about snippets of seccomp/apparmor and will hand them out to security systems on demand
<JamesTait> Good morning all; happy Tuesday, and happy Poetry At Work Day! ð
<LefterisJP> Hey guys, is DBUS the only way that a framework's service can listen to requests from the outside world (other snapps)?
<zyga> LefterisJP: you can also use other sockets
<zyga> LefterisJP: but security gets more complicated then
<enoch85> ok kyrofa I'm here now
<LefterisJP> zyga: I have an app that listens on plain unix sockets, which I need to have as the main daemon service of the framework. Are there any examples where such framework communication is achieved?
<zyga> LefterisJP: I think mir would be one
<zyga> LefterisJP: you'll need some extra security to handle other people talking to that socket
<LefterisJP> zyga: Which of these repos is the framework? https://code.launchpad.net/~mir-team/mir/
<LefterisJP> zyga: Any examples of what kind of extra security I would need to take care of, or well .. if the mir guys do that somewhere in code I could just look at that.
<zyga> LefterisJP: you need extra apparmor permissions to let other people talk to your socket
<zyga> LefterisJP: I'm sorry, I'm not sure where the mir snapcraft file is
<LefterisJP> zyga: It's okay. It's already something good to know that I don't need to use Dbus. I thought I would have to make an extra service to read DBUS and write to that unix socket inside the framework. I will try to look at the apparmor documentation to see how to allow for this communication.
<LefterisJP> If anyone has any tips/links I would be more than glad to have them
<zyga> LefterisJP: I suggest looking for anything that uses mir in snappy
<LefterisJP> zyga: Thank you will do and will come back here with more questions if I got any.
<bellyfeel> does anyone have a link to the 16.04 image?
<Chipaca> bellyfeel: which 16.04 image?
<bellyfeel> rolling
<Chipaca> bellyfeel: yeah, but there are a number. Maybe you want https://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/ ?
<bellyfeel> i'll check it out, thanks!
<Chipaca> bellyfeel: or maybe you want to just use: sudo ubuntu-device-flash core rolling --channel edge --oem generic-amd64/stable --enable-ssh --output rolling_edge_amd64.img
<icey> has anybody figured out how to run the maas controller on snappy?
<icey> or thought about it?
<kyrofa> dholbach, yes please!
<kyrofa> enoch85, woo you beat me by a few hours. You still here?
<dholbach> kyrofa: done
<enoch85> kyrofa, yes :)
<enoch85> kyrofa, so you got the apache up and running?
<kyrofa> enoch85, I did. Shall we take this private?
<kyrofa> dholbach, thank you!
<enoch85> kyrofa, ok
<dholbach> anytime
<kyrofa> mvo, what is the state of classic?
<kyrofa> sergiusens, did you ever send out that announcement email?
<sergiusens> kyrofa, yeah, yesterday, it is all over the ubuntu and ubuntudev google plus and twitter accounts ;-)
<sergiusens> kyrofa, and I pinged you here iirc, did I not?
<sergiusens> kyrofa, are you and snappy-app-devel?
<kyrofa> sergiusens, yeah you did, but I must not be on the right mailing list!
<kyrofa> sergiusens, I thought I was. Guess not :P
<kyrofa> sergiusens, now I am *cough*
<sergiusens> kyrofa, https://plus.google.com/107265043789873157543/posts/DBonvXp7nen
<kyrofa> sergiusens, very good :)
<sergiusens> kyrofa, do you mind helping Fazer with a proper rebase?
<kyrofa> sergiusens, love to
<sergiusens> kyrofa, whose untriagle?
<kyrofa> sergiusens, davidcalle
<davidcalle> o/
<sergiusens> davidcalle, mind doing a git commit --amend for https://github.com/ubuntu-core/snapcraft/pull/218 and putting LP: #XXXXX in there?
<sergiusens> davidcalle, asking so you are not forced to rebase once my doc changes land (and I am instead) ;-)
<bellyfeel> is there a way to build a snap using snapcraft without installing the dependencies?
<kyrofa> bellyfeel, which dependencies?
<bellyfeel> I might be getting confused about the snapcraft cycle but I have a list of packages in stage-packages that get downloaded and installed while doing a snapcraft build
<bellyfeel> i only want them to be installed on my device after the snap is built
<kyrofa> bellyfeel, ah
<kyrofa> bellyfeel, but where do they come from on the device?
<kyrofa> bellyfeel, your snap :)
<kyrofa> bellyfeel, which means they must be downloaded and put into the snap to create it in the first place
<davidcalle> sergiusens: git status
<davidcalle> sergiusens: lol, sorry
<davidcalle> Wrong window
<bellyfeel> ok downloading is fine but it looks as if I'm having collisions with packages on my dev machine with packages that should go on my device
<bellyfeel> with aptitude
<kyrofa> bellyfeel, that should definitely not be happening
<elopio> kyrofa: can you help this guy with the rebase? https://github.com/ubuntu-core/snapcraft/pull/217
<kyrofa> bellyfeel, stage-packages are downloaded and unpacked only in parts/<name>/ubuntu and parts/<name>/install
<kyrofa> elopio, yeah I'm typing it out now
<elopio> thanks :)
<kyrofa> bellyfeel, what sort of collisions are you seeing?
<bellyfeel> I think it might have something to do with 32bit dependencies
<bellyfeel> so for instance binutils:i386
<bellyfeel> snapcraft gives me a "failed doing pull for device: binutils:i386"
<bellyfeel> no other output information is given, so I tried running aptitude by itself
<kyrofa> bellyfeel, please pastebin the entire log, let me have a look
<bellyfeel> snapcraft log?
<kyrofa> bellyfeel, yeah, where you see the error
<bellyfeel> ok
<elopio> kyrofa: sergiusens: no standup today?
<kyrofa> elopio, no I'm just slow
<sergiusens> elopio, kyrofa ah, more slots have been added http://ubucon.org/en/events/ubucon-summit-us/schedule/ ; the lightning talk is 15 minutes, probably 10 gven setup and such :-)
<kyrofa> sergiusens, whew
<elopio> sergiusens: maybe 5, to answer questions :)
<davidcalle> sergiusens: I think I've successfully amended the commit, but being new to git, please check I've made no mistakes, I had to try several times before git let me push it :)
<kyrofa> davidcalle, since you amended, you probably had to force push yes?
<bellyfeel> kyrofa, pastebin.com/Vp7uGRgw
<kyrofa> davidcalle, that's normal, since your history and github's history officially "diverged"
<kyrofa> Gahh, rolling is so broken
<davidcalle> kyrofa: ok, just trying to get the hang of the git workflow, which feels a bit alien when coming from bzr :)
<kyrofa> davidcalle, no problem, we understand!
<mvo> kyrofa: rolling is broken in what way?
<kyrofa> mvo, http://pastebin.ubuntu.com/14478142/ . Any thoughts?
<mvo> kyrofa: uh, that should not have been imported
<kyrofa> mvo, hahaha
<mvo> kyrofa: I disabled the importing monday
<mvo> kyrofa: thats really anyoing
<mvo> kyrofa: sorry for this
<kyrofa> mvo, hey, it's rolling. Not supposed to be perfectly stable :)
<kyrofa> davidcalle, looks like you played a merge game of some kind to make git happy
<mvo> kyrofa: well, this change breaks stuff left and right. what kind of image is that? a normal snappy rolling edge or did you copy snappy on it manually or something?
<kyrofa> davidcalle, you should squash up and force push
<mvo> kyrofa: if its not the snappy of the image I will stop panicing
<kyrofa> mvo, it's a canonistack VM created from the rolling edge image
<mvo> kyrofa: hm, thats bad
<kyrofa> mvo, want SSH?
<mvo> kyrofa: no, its fine
<kyrofa> davidcalle, I just walked another PR author through it if you want a reference: https://github.com/ubuntu-core/snapcraft/pull/217
<kyrofa> davidcalle, just remember, if you change history, you'll need to push with --force
<davidcalle> kyrofa: ah, excellent, thanks
<mvo> kyrofa: thanks for letting me know!
<elopio> fgimenez: I have a meeting with Iftikhar and Jibel during our slot. Do you want to move it or cancel it today?
<kyrofa> mvo, no problem!
<fgimenez> elopio, np, i think we can cancel, my report: the jenkins swarm thing is almost done, i hope to have it finished for today
<elopio> fgimenez: yay.
<mvo> kyrofa: could you please try to upgrade your image?
<kyrofa> mvo, just a snappy update?
<kyrofa> mvo, or a new image?
<mvo> kyrofa: I think a snappy update should help, not sure if it is available yet
<mvo> but should be soon
<kyrofa> mvo, trying now, it's applying something anyway
<mvo> kyrofa: yay, lets see if stuff is normal after a reboot
<mvo> kyrofa: is it looking better?
<kyrofa> mvo, oops sorry, it took a minute to reboot and I saw a squirrel
<kyrofa> mvo, yep! All fixed :)
<kyrofa> mvo, thank you!
<mvo> kyrofa: \o/ thanks! sil2100 saved the day with his system-image superpowerz
<kyrofa> mvo, heh, awesome :)
<bellyfeel> is there a way to get more verbose output from snapcraft
<kyrofa> bellyfeel, I'm sorry, I missed your pastebin above
<kyrofa> bellyfeel, my initial assumption is that Snapcraft is not using the i386 sources
<kyrofa> bellyfeel, you should try running this on an i386 host (virtualized is fine)
<renat> Hi all! It's Renat from Screenly. Yes, again me with my questions=)
<kyrofa> Hey renat :)
<renat> kyrofa, hi!=)
<renat> So - the question is Raspberry Pi /dev/vchiq device relateed
<renat> We created a snap which should use that device to display an interface with OpenGL ES. So - I do snappy hw-assign, and then I can run that snap from the root user. It fails when I try to run it from the ubuntu user, or If I try to run it as a service.
<renat> Perhaps, because of /dev/vchiq access rights
<renat> crw------- 1 root root
<renat> Is it right settings for that device? I believe that display devices should be accessible from any snap, if access granted by the hw-assign.
<kyrofa> renat, I'd normally refer you to ogra, but he's out until the 16th
<renat> kyrofa, thanks. I will create a bug report in hope that he will see it.
<kyrofa> renat, yeah good idea
<pindonga> elopio, hi there... got any ETA for when https://github.com/ubuntu-core/snapcraft/pull/202 will get merged?
<sergiusens> pindonga, he needs a review from his QA colleagues last I heard
<sergiusens> kyrofa, did you see elopio's pings to you in the docs review?
<sergiusens> davidcalle, you seem to have forgotten to squash
<kyrofa> sergiusens, oh, no, reading now
<pindonga> sergiusens, care to explain the rationale for squashing all the work into a single commit?
<pindonga> I think I need to do that on my PR
<sergiusens> pindonga, I'll let kyrofa do that since he is better versed in that
<sergiusens> pindonga, I have 2 reasons, easier to cherrypick and easier to revert
<kyrofa> pindonga, are you familiar with `git blame`?
<pindonga> kyrofa, the same as bzr blame right? :)
<kyrofa> pindonga, ah, yeah same purpose. So you get a line-by-line "this is who made this change and why"
<kyrofa> If you didn't squash into a feature commit, some of those "whys" would be "crap, forgot this."
<pindonga> well, but that's the truth :)
<kyrofa> pindonga, hahaha
<kyrofa> But then it would require more digging. "Well, what feature was this a part of?"
<pindonga> k
<kyrofa> pindonga, when you're developing a feature, checkpoint commits and good and healthy
<kyrofa> But when your feature is done, checkpoint commits have no place in a project history
<kyrofa> For the reasons I mentioned as well as cherry-picking and reverting reasons mentioned by sergiusens among others I'm sure
<pindonga> kyrofa, I differ somewhat, but that's not the issue here, I appreciate you explaining me the reasons
<pindonga> am happy to follow the defined process
 * pindonga goes squash his commits
<kyrofa> pindonga, yeah you can imagine how squashing might get out of hand
<kyrofa> pindonga, but that's why we try to keep our features as small as possible
<kyrofa> pindonga, which also lends itself well to the reasons above
<pindonga> kyrofa, also it's mainly due to a limitation of the tool at hand
<pindonga> that doesn't show you the 'merge' commit
<pindonga> as a unit
<kyrofa> pindonga, it does actually, assuming it wasn't a fast forward
<kyrofa> pindonga, but the others are also part of the history
<kyrofa> bzr totally hides that from you
<pindonga> right
<sergiusens> kyrofa, I wished we had ff support on github too :-)
<kyrofa> which is fine, just a different tool
<pindonga> kyrofa, exactly , which is why I'm not ranting here :)
<kyrofa> sergiusens, yeah I'm curious about the justification behind that. Gitlab does that too
 * pindonga just prefers bzr model on this, but understand the reasons in git-world
<kyrofa> pindonga, oh it's not taken as a rant! I'm sorry if what I'm saying is coming off that way :P
<pindonga> no , totally not
 * pindonga was just covering his bases :)
<kyrofa> pindonga, heh. I appreciate your willingness to follow other workflows :) . I know this would be totally weird in bzr
<pindonga> it's also probably bc I'm not that used to it
<kyrofa> pindonga, understandable :)
<kyrofa> pindonga, I came to bzr from a git background, and was frustrated by the inability to easily clean up my work
<kyrofa> dholbach, do the developer.ubuntu.com docs handle ``` correctly?
<dholbach> kyrofa: they should soon
<kyrofa> dholbach, or do you need to indent as in normal markdown?
<kyrofa> dholbach, okay
<dholbach> we're going to use pymdown-extensions in one of our next landings
<kyrofa> dholbach, awesome. Have you synced the 1.x docs since 1.0 was released?
<dholbach> kyrofa: no, it's still manual until we do the landing I talked about
<dholbach> like manual manual
<kyrofa> dholbach, heh. Copy-paste?
<dholbach> and convert some bits and pieces, so links work, etc
<kyrofa> dholbach, blech, poor guy
<dholbach> yes
<kyrofa> dholbach, when is that landing happening?
<dholbach> very soon
<dholbach> we had lots of stumbling blocks along  the way
<kyrofa> dholbach, this week very soon or this month very soon?
<sergiusens> I did that twice on the portal, I felt like dying
<kyrofa> sergiusens, hahaha
<dholbach> kyrofa: I guess the latter
<dholbach> this or next week
<dholbach> fingers crossed and all
<dholbach> it's been quite a bit of work
<sergiusens> dholbach, I think kyrofa asks because of https://github.com/ubuntu-core/snapcraft/pull/221/files
<dholbach> I'm in a hangout on air right now - I'll get back to you in a bit
<sergiusens> dholbach, I am watching you fwiw ;-)
<dholbach> :-)
<dholbach> always watching me
<sergiusens> I don't expect instant replies ;-)
<sergiusens> lol
<sergiusens> 1984 style
<kyrofa> dholbach, okay, and understood! How would you feel about me copy-pasting the ROS docs? So I can point people there? Would that interfere with your landing?
<dholbach> I think the extension I mentioned above should make ```yaml and stuff like that work
<dholbach> if you want to update manually, feel free to
<dholbach> it's not going to interfere
<kyrofa> dholbach, oh sheesh, I'm sorry for interrupting you! When you get a chance, I've not done that before, I'd appreciate it if you could point me in the right direction. I'm not even sure I have permission to do something like that
<sergiusens> kyrofa, dholbach http://stackoverflow.com/questions/7694887/is-there-a-command-line-utility-for-rendering-github-flavored-markdown
<sergiusens> you can probably strips atom's previewer ;-)
<sergiusens> kyrofa, also, pandoc supports github flavored markdown
<dholbach> sergiusens: http://bazaar.launchpad.net/~dholbach/developer-ubuntu-com/rework-importer/view/head:/md_importer/importer/article.py#L50
<dholbach> kyrofa: sure - let me add you and give you links and stuff
<sergiusens> pandoc -f markdown_github
<wxl> hey folks is there a 15.04 amd64 image that i can zsync or torrent? i keep having problems getting one where the checksum matches :/
<kyrofa> sergiusens, by the way, you were spot on regarding why I was asking about that :P
<kyrofa> sergiusens, saved you a comment
<kyrofa> dholbach, thank you!
<sergiusens> kyrofa, I have lost context but good to know I hit a target by accident :-P
<elopio> pindonga: lets say end of the week. I'm fighting coveralls now, I hope that's the last one.
<kyrofa> sergiusens, :D
<elopio> but every change I have to wait for travis to tell me if I made something wrong. So it's slow.
<sergiusens> jdstrand, so what was wrong in snapcraft, security-policy or security-override?
<jdstrand> sergiusens: on 16.04, security-override
<fgimenez> elopio, http://10.55.33.14:8080/ this is the first deployment, all the slaves come from the same xenial container
<fgimenez> elopio, i'll propose the branch in a few minutes, let me know if we need different slaves
<sergiusens> jdstrand, do we have any docs or guidelines so I know what to do? or a snapcraft bug report (I can write one if the info is elsewhere)
<elopio> fgimenez: for snapcraft 1.x, we need vivid or trusty. But for now, I'm more than happy with xenial.
<jdstrand> sergiusens: see docs/security.md in snappy git trunk
<fgimenez> elopio, ok, it's very easy to add them, i'll put hands on it. when we switch to k8s will be even easier, and we don't need to have them around, they'll live while the job that requires them is up
<sergiusens> jdstrand, what is an 'abstraction', have an example handy?
<jdstrand> sergiusens: it is what's in /etc/apparmor.d/abstractions
<sergiusens> jdstrand, the file names or the contents of those files?
<jdstrand> file names
<sergiusens> looks like raw apparmor
<sergiusens> got it
<sergiusens> jdstrand, are all four entries optional?
<rickspencer3> hi all
<rickspencer3> I just uploaded my rest-cam snap to the store
<rickspencer3> I guess I can't install it from there because I am running 16.04?
<kyrofa> rickspencer3, I thought I remembered seeing rolling as a valid channel?
<kyrofa> rickspencer3, or edge or something
<rickspencer3> kyrofa, yeah, I put it there
<kyrofa> rickspencer3, oh. I figure that would have worked
<kyrofa> rickspencer3, you too I suppose :P
<rickspencer3> well, the bug could be between my head and the keyboard ;)
<kyrofa> rickspencer3, I assume you don't even see it as available, correct?
<kyrofa> rickspencer3, and the automated checks have all passed etc.?
<rickspencer3> kyrofa, I was just told that it is not done the checks yet :)
<kyrofa> Ahh
<kyrofa> rickspencer3, you just move too fast. Slow down. Grab a cup of coffee or something
<rickspencer3> kyrofa, turns out I had a bug somewhere so it didn't work
<rickspencer3> I got too used to it "just working" :)
<kyrofa> Heh
<sergiusens> Chipaca, after reading kyrofa's comment about stop-timeout I read the man page and it seems we can make services wait forever to stop if I read it correctly
<sergiusens> should it trigger manual review is my question
<sergiusens> maybe more of a question for jdstrand
<sergiusens> kyrofa, wrt rolling and ros, maybe check the envvars and make sure they are correct
<kyrofa> sergiusens, yeah I will. Working on a demo now though
<sergiusens> demo beats bug :-)
<kyrofa> sergiusens, timelines man, timelines ;)
<jdstrand> sergiusens: if this is a value of stop-timeout that makes the service wait forever, and we don't want to allow that, the review tools can verify the value is within approved parameters and prompt for manual review if it is outside of those values
<jdstrand> Chipaca, sergiusens: if you'd like this change in the review tools, please file a bug
<sergiusens> jdstrand, right, seems 0 disables it, so it is a number we don't want to allow I guess
<kyrofa> sergiusens, what happens if you specify "0min 0s" or something similar?
<sergiusens> kyrofa, value needs to be an int
<sergiusens> it will likely fail in some other place
<kyrofa> sergiusens, oh right, the yaml requires an integer okay
<wxl> sorry for asking again, but does anyone know of a zsync or torrent available for ubuntu-15.04-snappy-amd64-generic.img.xz? i keep getting mismatched checksums
<kyrofa> wxl, I don't know that there are any
<kyrofa> wxl, you could always make the image yourself
<wxl> kyrofa: well sheesh we should have one! i'd seed it bud i need to get the darn thing right, first
<wxl> kyrofa: link me to instructions? i might have not drilled down enough for that
<kyrofa> wxl, install ubuntu-device-flash and run sudo ubuntu-device-flash core 15.04 --channel stable --output ubuntu-15.04-snappy.img
<kyrofa> wxl, ... I think. It's been a while :P
<wxl> kyrofa: i'll grab ubuntu-device-flash and read the man page. thanks for the pointer in the right direction :)
<kyrofa> wxl, sure thing :)
<wxl> ugh sheesh how do i find the device names?
<wxl> i would think these are them but it doesn't seem to be the case http://system-image.ubuntu.com/ubuntu-core/15.04/stable/
<wxl> ubuntu-device-flash query --list-images --channel ubuntu-core/15.04/stable --device generic_amd64 yields several images
<jerryG> is darren landol online?
<wxl> oh i see. even though you use the core command you need to specific the full path of the channel (ubuntu-core/15.04/stable not 15.04/stable or just stable)
<wxl> also, have i386 images stopped getting updated?
<jerryG> Chipaca:  how do i check the mir socket being used?
<sergiusens> jdstrand, and kyrofa care to check https://github.com/ubuntu-core/snapcraft/pull/222/files ?
<sergiusens> kyrofa, I don't understand your question; as in, what you are asking is what I think subtests are for
<sergiusens> kyrofa, removing all but one will make the test fail but validation pass
<kyrofa> sergiusens, yeah I may not understand what's happening here. So it looks to me like you have only one app definition within self.data['apps'], whose definition seems meant to fail all four invalid combinations. No?
<sergiusens> kyrofa, yup
<sergiusens> kyrofa, so first I straight out validate as is in a subTest context expecting to fail
<sergiusens> kyrofa, then I create a real copy of the dict and iterate over the three keywords removing them before a validation expecting them to fail as well
<kyrofa> sergiusens, ahh, tricky, I missed the deletion
<kyrofa> sergiusens, okay ignore me
<sergiusens> it does what you ask for, we can argue about elegance
<kyrofa> sergiusens, no argument from me :)
<sergiusens> but I'd only se testscenarios with testtools
<kyrofa> sergiusens, +1 from me
<sergiusens> kyrofa, \o/
<sergiusens> kyrofa, docs are also updated fwiw
<jerryG> sergiusens: link plz?
<sergiusens> jerryG, for what?
<jerryG> sergiusens: idk. new docs
<jerryG> sergiusens: :}
<sergiusens> jerryG, it is just a PR, feel free to look though https://github.com/ubuntu-core/snapcraft/pull/221#discussion_r49486380
<jerryG> sergiusens: ty
<kyrofa> sergiusens, what is the currently recommended way to create a .snap for an arm device using snapcraft? Is classic in a state to allow that so we can do it on-device? Or a qemu VM?
<sergiusens> kyrofa, classic
<sergiusens> kyrofa, at least rickspencer3 has used it :-)
<kyrofa> sergiusens, excellent. I don't suppose that's available in vivid?
<sergiusens> kyrofa, it only rolls
<kyrofa> sergiusens, alright thanks :)
<kyrofa> sergiusens, rolling edge? Or 15.04?
<kyrofa> Or do I have that backward... rolling stable? :P
<sergiusens> kyrofa, rolling and 15.04 are the releases
<sergiusens> stable and edge are channels
<sergiusens> there is no stable channel on rolling
<kyrofa> sergiusens, ah, so rolling edge is it
<sergiusens> more so; you probably want an all snaps image
<kyrofa> Ah, okay
<sergiusens> kyrofa, maybe build u-d-f out of this branch https://code.launchpad.net/~snappy-dev/goget-ubuntu-touch/all-snaps/+merge/275273
<kyrofa> sergiusens, hmm... does hw-assign need something special in the package name? I'm using the name snappy list is giving me and I'm getting "snappy package not found"
<kyrofa> Oh... .sideload
<kyrofa> Been a while since I used that one
<sergiusens> kyrofa, hah
<kyrofa> sergiusens, alright I have a demo that works outside of snappy, but within snappy I can't get permission to access the webcam, even with hw-assign. Know anything about that?
<sergiusens> kyrofa, snappy install snappy-debug
<kyrofa> sergiusens, I've got it-- no denials
<sergiusens> kyrofa, not even seccomp?
<sergiusens> kyrofa, what about running the binary from within the package and no launcher?
<sergiusens> kyrofa, as in exec /apps/package/version/bin/my-app
<kyrofa> sergiusens, still denied.
<kyrofa> crw-rw---- 1 root video 81, 0 Jan 12 21:10 /dev/video0
<sergiusens> kyrofa, oh, sudo mypackage.myapp
<sergiusens> kyrofa, I assume service all the time
<kyrofa> sergiusens, ROS blows up if you run as sudo :( . This works on my local machine with the same permissions-- must be a group thing?
<kyrofa> sergiusens, I can make it a service though-- I guess it'll need to be anyway
<sergiusens> kyrofa, it is a group thing; we just went over this the other day with jdstrand
<sergiusens> kyrofa, add ubuntu to the video group
<kyrofa> sergiusens, oh heh. Sorry to drag it back up
<sergiusens> kyrofa, oh, didn't mean it like that; just that I had it fresh in my mind
<kyrofa> sergiusens, ah, good :)
<sergiusens> kyrofa elopio, still around? are we good to merge this https://github.com/ubuntu-core/snapcraft/pull/221
<sergiusens> elopio, btw, do you want to have a look at this? https://github.com/ubuntu-core/snapcraft/pull/222
<elopio> sergiusens: I'm good with #221. And you already got 2 reviews for #222, so land it when you want. I'll take a peek later.
<sergiusens> elopio, here's one for you https://github.com/ubuntu-core/snapcraft/pull/225 but lets wait for the tests to finish just in case
<wxl> how do you guys deal with the fact that you seem to primarily do development on github but generally bugs are being reported on launchpad? i know there's no upstream issue tracker for github on lp, so it seems like you have to fight with two totally separate systems
<sergiusens> wxl, to be fair, the tracker in launchpad is much better
<sergiusens> but we just do
<sergiusens> it is not a problem
<wxl> yeah i'm sure you get by but it's interesting, sergiusens :)
 * tsimonq2 spots wxl :)
#snappy 2016-01-13
<elopio> sergiusens: can you add snappy-m-o to snapcraft and give him pull and push requests?
<sergiusens> elopio, sure
<sergiusens> elopio, what does that guy do?
<elopio> sergiusens: trigger the examples tests in jenkins and report back the results.
<sergiusens> elopio, should be there now; same team as us so should be able to do the right stuff
<sergiusens> elopio, nice
<elopio> sergiusens: https://github.com/ubuntu-core/snappy-jenkins/pull/40
<sergiusens> elopio, your bug link should live in the commit https://github.com/ubuntu-core/snapcraft/pull/226/commits
<sergiusens> not the merge commit
<sergiusens> elopio, look at the blue here https://github.com/sergiusens/snapcraft/commit/143579fb4b68c2d79846c9b6de0a837a8f40bb54
<sergiusens> elopio, when compared to here https://github.com/elopio/snapcraft/commit/accb773a7fb46bbaf0d83cd798ee289a592f1872
<elopio> sergiusens: yes, I got it from your last comment. I'm sorry.
<elopio> I can add it when I hit the Merge button.
<sergiusens> elopio, no worries; the merge commit is not the same though
<elopio> sergiusens: I almost got this right: https://github.com/ubuntu-core/snapcraft/commit/5fe67a88ca6c7d35c210758869e0882aae6196c5
<sergiusens> elopio, pergect
<sergiusens> well, if written correctly :-P
<sergiusens> perfect*
<elopio> next time :)
<sergiusens> elopio, I'll check all your PRs later, need to spend some family quality time now
<elopio> sergiusens: don't worry. This will be blocked until tomorrow.
<Armenta> how to make work webdm behind a internet proxy? I do not know how to setup a proxy in ubuntu-core
<sergiusens> elopio, what does 'okay' mean? :-)
<Armenta> Hello people. I have a dimmie question, how to make work webdm behind a internet proxy? I know I need to configure the proxy, I try using  export http_proxy=ht***** in sudo and normal session but only affects the session, don't affect the wide system and the webdm complains: "Error: Get https://search.apps.ubuntu.com/api/v1/search?**** read: connection refused"
<sergiusens> Armenta, I don't think proxies are supported
<sergiusens> not hard to add, maybe log a bug
<sergiusens> ?
<Armenta> Thank you sergiusens, I will try to log a bug
<liuxg> sergiusens, ping
<dholbach> good morning
<wxl> evening dholbach. just got through with a heated game of moon-buggy
<dholbach> :-)
<dholbach> wxl: that was more of a test of snapcraft's features :-)
<wxl> dholbach: i know. still fun. but you should have done nethack XD
<dholbach> see if you can do it :)
<dholbach> for moon-buggy the "packaging" was just:
<dholbach> http://bazaar.launchpad.net/~dholbach/+junk/moon-buggy/view/head:/snapcraft.yaml
<wxl> thankfully ogra_ took care of that
<dholbach> ah, great
<wxl> like really whoa!
<wxl> hm i'll have to snap something up now XD
<dholbach> http://developer.ubuntu.com/snappy/build-apps/
<wxl> yep. working on getting my way over there. had a heck of a time getting the download to get the right image.
<wxl> i need to play with ubuntu-device-flash and create my own
<dholbach> ok
<wxl> it seems there's no ubuntu-core for i386, eh?
<dholbach> somebody asked the question before, but I can't remember the answer
<dholbach> mvo: ^ do you know?
<mvo> wxl: no official release but you can build one using ubuntu-device-flash
<mvo> dholbach: good morning!
<dholbach> mvo: hola muchacho
<wxl> mvo: ubuntu-device-flash query --device generic_i386 --channel ubuntu-core/15.04/stable --list-images â nil
<mvo> wxl: yeah, no stable image, sorry for that, please try "edge" that should be ok, very little churn on the 15.04 channel.
<wxl> ohhh great thanks mvo
<wxl> creating image yay :)
<mvo> :)
<zyga> good morning! :)
 * zyga needs to finish a few tests and push the changes for review
<JamesTait> Good morning all; happy Wednesday, and happy Skeptics Day! ð
<seb128> mvo__, hey, did you notice that ubuntu-snappy was blocked in xenial-proposed because it fails to build on powerpc/s390x? the new snapshot you just upload still has the issue it seems...
<mvo__> seb128: I have a look, but I think it would be good if it could be allowed through even though it fails on these two arches. but let me check what it takes to fix it
<xnox> mvo__, to be allowed through, you should request binaries to be removed for those arches from xenial-release.
<seb128> mvo__, what xnox said
<sergiusens> elopio, kyrofa I need to take the car to the shop for maintenance today; I might barely make it to the standup
<renat> Hi all! Its Renat from Screenly.
<renat> =)
<sergiusens> hello
<zyga> one more test and caps simplification will work :)
<renat> I'm trying to setup a service using a snapcraft tool. Here is the snapcraft yaml.: http://pastebin.com/SnzKHX2n
<renat> But for the some reason - systemd is killing my service
<renat> Here is its output. http://pastebin.com/UDG5ZS5C
<renat> I can't see any reason, why application is killed, in journalctl output.
<renat> Also - no security warnings I get.
<renat> When I export all environment variables from the service file, and then execute ExecStart command - everything goes ok.
<renat> Nothing interesting in dmesg too=(
<renat> And here is the wrapper  script itself. http://pastebin.com/08hSijtW
<renat> One more question. Is it possible to run a snap chrooted?
<kyrofa> sergiusens, no problem :)
<LefterisJP> hey guys click-review tools giving a lint error for a framework with (MANUAL REVIEW) specified basically means that in order to get that approved to be in the store I would need a manual review. I can still siedload and test of course?
<enoch85> kyrofa, online :)
<kyrofa> enoch85, hey there!
<enoch85> kyrofa, how is your day today? I have around 3 hours I can work on the snappy right now
<kyrofa> enoch85, works for me! Let's take it private
<tzununbekov> beuno, hey. We are trying to upload our snap to app store but getting reject "(NEEDS REVIEW) 'security-policy' not allowed security_yaml_policy_present"
<tzununbekov> beuno, could you please explain how can we pass review?
<LefterisJP> I am working on a framework called ethereum. Sideloading it at the moment, and have a single service in it. Using an unconfined apparmor profile and a modified seccomp profile. The service's binary tries to use /root/ as it's home directory. It does so by reading the $HOME variable from what I know. Should it not be set to something like /apps/ethereum/VERSION/ ?
<beuno> jdstrand, ^^
<tzununbekov> according to the https://developer.ubuntu.com/en/snappy/guides/security-policy/ , custom "security-policy" will be manually reviewed, but not rejected :)
<beuno> tzununbekov, jdstrand can tell you more, but in general we don't allow apps to escape confinement
<beuno> a manual review just means you ask a human to make the decision
<beuno> most of the time, the decision is to not allow it  :)
<beuno> but we might have solved whatever you're trying to do differently
<tzununbekov> beuno, our app is working on the top of lxc and we took security profiles from lxd package which is available in store
<LefterisJP> anyone got any ideas about my question posted above?
<tzununbekov> beuno, anyway, our app needs a custom security policy. With whom we can discuss it?
<beuno> tzununbekov, jdstrand, who should be on in a short while
<tzununbekov> beuno, thanks
<dshihovtsev> Hi all, is there any way to read history of this channel somewhere online?
<seb128> dshihovtsev, http://irclogs.ubuntu.com/2016/01/13/%23snappy.html
<dshihovtsev> seb128, thanks
<seb128> yw
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/320 for review
<zyga> capabilities as interfaces and types!
<tzununbekov> jdstrand, hey. What is a requirements for custom security policy to make it acceptable for uploading to store?
<zyga> ls
<sergiusens> kyrofa, but I made it back :-)
<sergiusens> and waiting in the hangout :)
<sergiusens> elopio, hangout?
<rickspencer3> sergiusens, so, here is my snapcraft.yaml: http://bazaar.launchpad.net/~rick-rickspencer3/+junk/rest-cam/view/head:/snapcraft.yaml
<rickspencer3> the snap builds and runs no problem
<rickspencer3> but when I uploaded it to the store, I got this error:
<rickspencer3> Missing required field 'description' snappy-systemd_package_yaml_required_key (rest-cam, description)
<rickspencer3> required description field not specified snappy-systemd_package_yaml_description_present (rest-cam)
<elopio> sergiusens: https://github.com/elopio/snapcraft/commit/eab93d52b4cd5fdca8191b8e25a17285683615f9 yay!
<rickspencer3> any idea what I did wrong?
<kyrofa> rickspencer3, your service needs a description
<rickspencer3> oh!
<kyrofa> sergiusens, should snapcraft catch that? ^^
<sergiusens> kyrofa, 2.0 it is generated automatically
<ogra_> yeah
<kyrofa> sergiusens, ah
<sergiusens> kyrofa, in 1.x it might be a required field
<sergiusens> kyrofa, more so, in 2.0 it is not a required field in the internal format; for backwards compat it is generated automatically for package.yaml
<sergiusens> elopio, well done ;-)
<kyrofa> rickspencer3, are you still running out of master?
<rickspencer3> kyrofa, I was never running out of master so far as I know
<rickspencer3> I am on Xenial
<sergiusens> kyrofa, I don't think he updated or else he would be complaining about 'apps' changing ;-)
<rickspencer3> and I did sudo apt-get snapcraft in classic dimension
<kyrofa> sergiusens, erhm, yes I suppose so
<kyrofa> sergiusens, so it must not be required in 1.0 then
<sergiusens> kyrofa, oh, it certainly isn't; the review tools do capture it though so it is all not that bad
<kyrofa> Okay very good. Yeah rickspencer3 just add the description, you should be good to go
<rickspencer3> thanks kyrofa, I'll get to is asap
<rickspencer3> for our phone SDK, the IDE automatically runs the review tools locally after building a click
<rickspencer3> so you can iterate on your packaging very easily
<rickspencer3> without roundtripping through the store
<rickspencer3> that would be a nice feature of snapcraft, to run those tools
<sergiusens> rickspencer3, in 1.x it is run if installed
<rickspencer3> sweet
<kyrofa> sergiusens, oh cool, I didn't know that either
<rickspencer3> thanks sergiusens and kyrofa
<rickspencer3> I really appreciate your help
<kyrofa> rickspencer3, any time!
 * rickspencer3 hugs snappy community
<rickspencer3> I am loving snappy these days, it is a joy to develop for
<sergiusens> \o/
<kyrofa> rickspencer3, then we're meeting our goal!
<kyrofa> sergiusens, ignoring bug #1531481, I'm trying to understand how one builds part A from source, and then builds part B from source where part B depends upon part A
<ubottu> bug 1531481 in Snapcraft trunk "snapcraft should setup search paths/flags for parts built after parts" [High,In progress] https://launchpad.net/bugs/1531481
<kyrofa> sergiusens, using the `after` key, does that mean part A is staged before B is ever built?
<kyrofa> Ah, yes, okay docs for the win
<elopio> kyrofa: sergiusens: tomcat built on xenial fails to install on rolling: tomcat-webapp-demo_1.0_amd64.snap failed to install: could not find specified cap: networking (&{apparmor /usr/share/apparmor/easyprof})
<kyrofa> sergiusens, which makes you fix make sense, then. And using the `after` key is the official way to do exactly that (my A-B example, I mean)
<kyrofa> Right?
<kyrofa> sergiusens, assuming so, let's say I get to the point where A is built and staged, and now B is building. However, the process of building B not only requires access to headers and libs, but the ability to actually run a binary from A. However, said binary was built with a prefix and a destdir that are both invalid in the stage dir. How do I patch that binary to be runnable?
<kyrofa> sergiusens, the only way I can think of right now is to patch the binary upon install (where it goes to 'parts/foo/install') to actually point to 'stage' so it's runnable when staged. That feels yucky, fragile, and very snapcraft-centric to me, which I think is not ideal
<sergiusens> kyrofa, the latter is the only way I think so without patching upstream to make the script location independent
<sergiusens> kyrofa, which is the other thing that can be done, make the script itself location independent
<kyrofa> sergiusens, true... but yeah I don't see that happening for apache. The way apache modules are built is by calling the apxs binary which sets up all the include paths and stuff, which means it must be pointing to somewhere
<sergiusens> kyrofa, hmm, we might then need and apache plugin :-/
<kyrofa> sergiusens, hmm... yeah maybe. I'll keep that in mind as I continue. For now I'll just continue doing it all in one part
<kyrofa> sergiusens, once I have something working I'll step back and see how complex it turned out to be :P
<sergiusens> elopio, right, caps changed in xenial I think 'networking' is no longer required or not longer exists or changed name; tyhicks or jdstrand care to refresh my feeble mind?
<sergiusens> mvo, does that recently released image have the env var changes too?
<jdstrand> sergiusens, elopio: networking is now network-client
<mvo> sergiusens: yes, sorry, forgot to mention that in the annoucement
<mvo> sergiusens: the existing vars SNAP_* are still there for compatiblity though
<elopio> jdstrand: let me try thtat.
<sergiusens> mvo, yeah, but I'll get a PR now to be completely up to date
<sergiusens> jdstrand, thank you
<sergiusens> mvo, thanks :-)
<mvo> sergiusens: yw!
<tzununbekov> jdstrand, hey, beuno said that you can help with security policies for package
<tzununbekov> what is a requirements for custom security policy to make it acceptable for uploading to store?	
<jdstrand> tzununbekov: if you own your own store, you can upload/accept custom policy for your store. otherwise, the framework author (iirc, you had a question about frameworks) would need to engage with Canonical
<jdstrand> tzununbekov: so, if this is for the public store, it might make sense to bring up your framework on the snappy-devel mailing list (regardless of security policy), especially since the notion of frameworks is changing in 16.04
<tzununbekov> jdstrand, and what if it's not a framework?
<jdstrand> tzununbekov: Canonical policies are such that we don't allow apps into the public store with custom security policy unless the app author has a relationship with Canonical. if the author has a private store, then the author can have whatever policy they want
<jdstrand> tzununbekov: what are the accesses you need?
<jdstrand> perhaps you don't actually need custom policy or there is a bug fix we can add
<fgimenez> elopio, http://10.55.33.17:8080/ PR is on its way
<elopio> fgimenez: cool :)
<tzununbekov> jdstrand, we are running lxc containers and using cgroup manager to change the parent process id. Security profile that was applied for parent process blocks the commands inside the containers
<tzununbekov> does it fit into the application functionality or it's more like framework?
<jdstrand> tzununbekov: fyi, there is already the lxd framework that is in the store
<jdstrand> tzununbekov: but to bundle it yourselves it could be either an app or a framework, but on 15.04 there is no policy that you can specify to allow this (obviously, running containers requires privileged access to the system (though not user containers and we are making those work, but I digress))
<beowulf> hayalp, i can't seem to build an image with u-d-f on vivid: http://pastebin.ubuntu.com/14488444/
<tzununbekov> jdstrand, btw, LXD is unrestricted, it has full access to the root
<jdstrand> yes, but the author is a Canonical employee
<tzununbekov> It would be nice to have a similar security privileges :)
<tzununbekov>  actually, our app is pretty complex package and we have a several security related points to discuss with Canonical. How it's better to do?
<jdstrand> tzununbekov: probably bring it up with manik or mectors or asac
<jdstrand> tzununbekov: asac is here now, he may privmsg you, otherwise you can look for the others
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/229
 * zyga works on a capability type interface 
<tzununbekov> jdstrand, thanks a lot for advise)
<jdstrand> tzununbekov: np
 * zyga -> some scotch and back to hacking
<sergiusens> elopio, do you know what's going on with travis?
<sergiusens> elopio, oh, this https://www.traviscistatus.com/
<bellyfeel> is there a way to get more verbose output from snapcraft pull?
<kyrofa> bellyfeel, still running into i386 issues on amd64?
<bellyfeel> yes sir
<kyrofa> You may have missed me yesterday-- Snapcraft isn't setup that way. It uses the sources for the host arch. Try running on a i386 VM
<sergiusens> kyrofa, did you see my PR btw? seems to be network errors everywhere :-P
<bellyfeel> interesting, thanks
<kyrofa> sergiusens, haha, yeah I keep disconnecting too
<kyrofa> bellyfeel, compiling for i386 on amd64 is cross compiling, just like compiling for armhf from amd64. Snapcraft doesn't support that yet
<bellyfeel> ahh, okay.
<bellyfeel> Yea I'm still learning snappy and understanding my workflow.
<sergiusens> kyrofa, you know why the test is fragile though? They depend on get_arch_triplet :-P
<sergiusens> I'll fix that
<kyrofa> sergiusens, yeah mine do too... :P
<sergiusens> kyrofa, yeah, I'm fixing it in setUp ;-)
<kyrofa> sergiusens, yay!
<sergiusens> done
 * zyga pushed pull request 322
<zyga> https://github.com/ubuntu-core/snappy/pull/322
<zyga> this makes capability types extensible
<zyga> please have a look if you are interested in capabilities
<jerryG> Chipaca: hi
<wxl> how do i debug ubuntu-device-flash complaing about issues when partitioning?
<anpok> sergiusens: hi.. still around?
<sergiusens> anpok, yes
<anpok> do you have a branch for #1531481 i could continue to play with.. and then also fix nfs-utils
<sergiusens> anpok, yes https://github.com/ubuntu-core/snapcraft/pull/229
<elopio> I'm sorry, I had a blackout
<kyrofa> elopio, it really does sound like you're in a jungle :P
<kyrofa> Holy crap fingers. cp != rm -rf
<sergiusens> elopio, did this work for you https://github.com/ubuntu-core/snapcraft/pull/228/files ?
<sergiusens> elopio, no worries, travis died while you were gone
<sergiusens> kyrofa, indeed, be careful
<kyrofa> sergiusens, long day :P
<sergiusens> kyrofa, the ubuntu unpacking needs more work; it isn't making it to the snap dir :-/
<kyrofa> sergiusens, hmm...
<sergiusens> kyrofa, because all matches originate from installdir ;-)
<kyrofa> sergiusens, ah, right yeah. All the catkin env stuff uses the installdir, too
<kyrofa> sergiusens, is that going to matter?
<sergiusens> kyrofa, yes, I have another trick under my sleeve
<sergiusens> kyrofa, too bad python apt doesn't give me a list of downloaded packages
<sergiusens> would of been easier
<rickspencer3> does anyone know if there is a sensible way for a snap to get its own version number?
<sergiusens> rickspencer3, load the yaml from its meta dir
<sergiusens> that's what we do in webdm fwiw
<rickspencer3> just parse the yaml?
 * rickspencer3 shrugs
<sergiusens> yeah
<rickspencer3> sounds straightforward enough
<Chipaca> jerryG: 'sup
<jerryG> Chipaca: Do you know what darren landol's username is on irc?... is he ever online?
<Chipaca> jerryG: no, i don't
<Chipaca> jerryG: i also don't know who darren landol is
<sergiusens> kyrofa, check the branch again
<zyga> I've pushed some more bits to https://github.com/ubuntu-core/snappy/pull/322
<sergiusens> kyrofa, hmm, there are some corner cases to this...
<sergiusens> darn stage-packages...
<tedg> sergiusens: Looking at snapcraft, and when making the squashfs it mentions my uid. Is my UID encoded into the snap?
<elopio> sergiusens: yes, it worked for me.
<amriunix> install RPI2 GPIO API on snappy ?
<rickspencer3> hey all
<rickspencer3> fyi, I got my rest-cam snap into the store today
<rickspencer3> It should be reasonably easy to use
<kyrofa> enoch85, ping
<enoch85> kyrofa, here
<jerryG> Chipaca: k thx
<sergiusens> tedg, now, the snapid is generated by the store, but beuno and friends are still working on that
<tedg> sergiusens, thinking about the uid/guid stuff in the squash fs output https://www.irccloud.com/pastebin/YHD0RJqm/
<tedg> Seems odd that's getting encoded into my snap
<sergiusens> tedg, oh, now I see what you mean
<sergiusens> I guess it needs some fakerooting magic ;-)
<tedg> Yeah, perhaps, or some crazy command line argument. As kernel tools do.
<liuxg> Chipaca, ping
<liuxg> sergiusens, ping
<fazer> sergiusens, Can I have some help squashing my commits? I used git rebase -i master but I wasn't allowed to squash all the commits, so I rebased a couple, but I over rebased and now I have a big mess of commits. This is the pr: https://github.com/ubuntu-core/snapcraft/pull/217
<wxl> anyone know how to debug a partitioning issue with ubuntu-device-flash?
<tsimonq2> wxl: RTFM? :P
<tsimonq2> Â¯\_(ã)_/Â¯
<fazer> elopio, kyrofa ^^
<wxl> tsimonq2: you show me in the manual where that's covered
<tsimonq2> wxl: heheheh, partitioning specifications? :P
<wxl> tsimonq2: ubuntu-device-flash --verbose core --device generic_i386 --channel ubuntu-core/15.04/edge --output mysnappy.img
<tsimonq2> oh
 * tsimonq2 remains silent and waits for the experts XD
#snappy 2016-01-14
<fazer> I'm trying to rebase my branch on git and it says could not apply 'commitxyz'. Does nayone know how I can fix this?
<shuduo> is there any way to specify archive mirror server for snapcraft local plugin using instead of automatically pick up by determined by IP geo?
<zyga> good mornign
<zyga> focus for today: capability security
<JamesTait> Good morning all!  Happy Thursday, and happy Organise Your Home Day! ð
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/324
<zyga> same security aspect of bool file as in one of the earlier merge request
<zyga> s
<zyga> this time based on the type interface patches
<Chipaca> ogra_: https://www.treats4geeks.com/
<Chipaca> ogra_: a quad-core imx6 with wifi+bt+3g+gps+9-axis imu
<Chipaca> not cheap tho
<ogra_> well, it has a lot of stuff on board :)
<persistentstorag> Hi! Where would I write persistent data to? Let's say I ran my seedbox as a collection of snaps. Looking for something similar to docker data volumes, or a home directory.
<ogra_> SNAP_APP_DATA_PATH or SNAP_APP_USER_DATA_PATH point to writable spaces in the snap env (the latter only for binaries a user can execute, the foremer is the writable and persistent package dir)
<ogra_> hmm, probably without "APP", sorry
<persistentstorag> SNAP_APP_DATA_PATH seems to be what I'm looking for, thanks!
<enoch85> kyrofa, let's get to work ;)
<zyga> ogra_: hey :)
<shuduo> is there any way to specify archive mirror server for snapcraft local plugin using instead of automatically pick up by determined by IP geo?
<kyrofa> enoch85, hey there :)
<enoch85> kyrofa, hey :9
<enoch85> :)
<sergiusens_> kyrofa, here's a small present https://github.com/ubuntu-core/snapcraft/pull/230
<sergiusens_> good morning
<kyrofa> sergiusens_, good morning!
<kyrofa> sergiusens, wait... why didn't we hit that before?
<sergiusens> kyrofa, I have no clue; maybe check if /usr/bin/python exists on 15.04
<sergiusens> which it might as well
<kyrofa> Yeah that's what I'm assuming
<kyrofa> It does indeed exist
<kyrofa> But it's been removed on xenial eh?
<sergiusens> hah, there we go; yeah, cloud-init moved to python3 so that might have removed the dep
<sergiusens> kyrofa, it still fails though
<sergiusens> kyrofa, [rosrun] Couldn't find executable named listener below /snaps/ros-example.sideload/IKKNUNfbERGD/opt/ros/indigo/share/beginner_tutorials
<sergiusens> kyrofa, I see talker under lib though (it is looking for it in share)
<sergiusens> kyrofa, this part of ros is black magic to me
<kyrofa> Yeah it shouldn't be looking in there... odd
<sergiusens> kyrofa, any clues where to look?
<kyrofa> sergiusens, no that's never happened to me before
<kyrofa> sergiusens, I do plan on looking into this by the way... just trying to knock out the .snaps first
<kyrofa> sergiusens, I feel like you're procrastinating on those slides... ;)
<sergiusens> kyrofa, sure, maybe we land this PR as is then? It does fix the specific bug :-P
<sergiusens> kyrofa, slides ... right and look at the time
<sergiusens> darn
<kyrofa> sergiusens, hahaha
<kyrofa> ogra_, is this still valid? "Note: the snappy update command will currently not work with Raspberry Pi 2 images. It requires hosting the device tarball on a system-image server, which is not yet available."
<sergiusens> kyrofa, use mvo's recently announce pi2 images (if you are looking into rolling)
<kyrofa> sergiusens, no I'm just trying to figure out if that comment it out of date. People are suggesting not to use Core on the rpi2 due to it
<sergiusens> kyrofa, I suppose with mvo's announcement that is indeed out of date for rolling
<mvo> kyrofa: pi2 in rolling will update just fine
<mvo> kyrofa: well, unless there are nasty bugs of course
<kyrofa> sergiusens, does autopilot automatically update all installed snaps?
<kyrofa> mvo, excellent thank you
<sergiusens> kyrofa, it is of course not production ready, but it is tinkerer ready
<kyrofa> sergiusens, right, of course
<sergiusens> kyrofa, one more https://github.com/ubuntu-core/snapcraft/pull/231
<elopio> kyrofa: so, what I'm thinking is that after you are done with owncloud you would enjoy packaging syncthing ^_^
<kyrofa> elopio, how have I not heard of that?
<elopio> hipster synching.
<kyrofa> Hahaha
<kyrofa> elopio, this has been an excellent experience though. I feel like it's really pushing snapcraft
<peacememories> question: is there an api for snappy that e.g. a framework could use to control it?
<kyrofa> peacememories, control what exactly?
<peacememories> installing .snap files, for example
<kyrofa> peacememories, can you explain what you have in mind?
<kyrofa> peacememories, e.g. you just described webdm. Have you used that?
<peacememories> not yet, no. gimme a second, looking into it
<kyrofa> peacememories, the short answer to your question is yes. The longer answer is that you may be trying to do something that has already been done :)
<peacememories> what i'm trying to achieve: control what version of a software is installed on the device (stereomatching engine on a stereo camera)
<peacememories> remotely, of course
<kyrofa> peacememories, via something other than SSH I assume?
<peacememories> yes
<kyrofa> peacememories, GUI only?
<peacememories> actually without any gui, i guess. there will be a gui, but that will probably be built in house
<kyrofa> peacememories, yeah, look at webdm. You may like that. If it doesn't do exactly what you want consider contributing to it
<kyrofa> peacememories, failing that, yes, there's an API you can use
<kyrofa> peacememories, Chipaca is your best resource regarding that, I think
<kgunn> mvo: i'm sure you have plenty to do, but wondering if you might want to jot down an idea for u-d-f, when i create my core image...i always need to resize afterward (my mir stuff is meaty)
<kgunn> wondering if you might add a size option
<kyrofa> kgunn may be something you want to mention to sergiusens. He's been talking about revamping u-d-f
<peacememories> btw, does snappy support having multiple versions of a software installed, with one being active?
<kgunn> sure
<peacememories> that's definitely neat
<peacememories> still trying to wrap my head around where to put everything and how to manage software on an embedded snappy device
<kgunn> oh peacememories lol, sure @letting sergiusens know
<kgunn> but i suppose the answer is still yes to that
<peacememories> oh^^
<kgunn> peacememories: but i should let the experts speak
<kyrofa> peacememories, kgunn perhaps the better answer is "kinda"? I'm not sure you can have a newer version installed while the older is active
<kgunn> right...
<kgunn> it always takes the latest
<kyrofa> peacememories, but the old versions remain there, yes
<kyrofa> peacememories, to allow for rollbacks
<peacememories> hmm
<kyrofa> Chipaca will know if there's a way around that
<peacememories> maybe what i'm trying to do would be abusing the snappy architecture. seems a bit like it
<peacememories> i'm trying a bit hard to make this work, mainly because i don't know any other small embedded distros with AB-partition update capabilities
<kyrofa> peacememories, what are you trying to accomplish with the multiple versions?
<peacememories> kyrofa, the ability to quickly choose the running version of a software via a management interface
<peacememories> i could do a workaround that saves the .snap files on the system and uses a local install
<mvo> kgunn: hi, there is a --size option :) is it not working?
<kyrofa> peacememories, that may be a better idea
<kgunn> mvo: doh!
<kyrofa> peacememories, I'm afraid anything else may result in trying to fight snappy
<peacememories> our semantics would probably be the same as 'rollback' anyway, but the current idea for the management interface doesn't mesh too well with that :/
<kyrofa> peacememories, there's a problem though
<peacememories> hm?
<kyrofa> peacememories, upgrades copy the old version's data, rollbacks go back to the old version of the data. Uninstalling and installing a new one won't do either-- data would be empty
<kyrofa> peacememories, does the .snap in question have data?
<peacememories> not right now, no. a different snap might, though
<kyrofa> peacememories, something to keep in mind then
<peacememories> i'm assuming a .snap install of a newer version doesn't register as an upgrade?
<kyrofa> peacememories, hmm... good question. Sideloaded I'd say no, but if not sideloaded I'm not sure what happens. You may even get a "already installed" type of error. mvo do you know the answer to that?
<kyrofa> Well, I'm not sure how you'd accomplish what you're trying without sideloading, so perhaps the answer to your question is no
<kyrofa> peacememories, though it's important to point out that copying the data is as easy as cp -r over ssh
<elopio> oh sad day.
<kyrofa> elopio, what's up?
<elopio> stgraber: the lxd import started failing on travis.
<elopio> Image manifest: http://cloud-images.ubuntu.com/server/xenial/20160105/xenial-server-cloudimg-amd64.manifest
<elopio> error: HTTP Error 404: Not Found
<kyrofa> elopio, is that what you're using in the tests?
<elopio> that URL indeed returns a 404. Do I need to update something?
<elopio> kyrofa: I'm just asking for the daily xenial.
<kyrofa> change the datetime to current?
<kyrofa> elopio, datestamp, rather
<kyrofa> elopio, http://cloud-images.ubuntu.com/xenial/current/xenial-server-cloudimg-amd64.manifest
<elopio> kyrofa: I'm not sure where to put the date. The command is "lxd-images import ubuntu xenial --stream daily --alias ubuntu"
<kyrofa> elopio, oh...
<kyrofa> elopio, stgraber question then, I suppose?
<elopio> pindonga: good I gave you an ETA of friday. The branch was all green for a couple of hours, then we had the travis outage, and now this.
<elopio> it's cursed.
<pindonga> :(
<kyrofa> elopio, have you built a cmake part before?
<mvo> kyrofa: uh, sorry, was in a meeting. is the question still open?
<kyrofa> mvo, I don't think so, no worries :)
<elopio> kyrofa: I don't think os.
<elopio> *so
<stgraber> elopio: xenial simple stream is busted, the cloud team is on it
<kyrofa> elopio, how would you feel if we added some sort of installflags option to the autotools/cmake/make plugins?
<kyrofa> elopio, I really want a make -j8 here :P
<kyrofa> elopio, compiling some things single threaded take forrrreeeever.
 * kyrofa looks at mysql
<elopio> stgraber: ah, thanks for the info. I'll wait.
<elopio> kyrofa: I would like that. But if feels weird to hardcode j8 on your yaml.
<kyrofa> elopio, can you think of a better way?
<elopio> kyrofa: it would be really cool to be able to pass command line args from the snapcraft binary to the plugin. But sounds messy too.
<kyrofa> Hmm... yeah that sounds more involved. But I agree
<elopio> maybe something like --plugin-flag autotools:-j8
<elopio> I have the feeling that Sergio will hate this :)
<kyrofa> Me too. I can imagine installflags being useful for things other than things as hardware-dependent as -j though. For instance, the apache installation has a number of "install this elsewhere" type of flags
<kyrofa> Wow that sentence had terrible grammar. I'm sorry
<kyrofa> elopio, so maybe since that gets us part way there, it's a better solution for now?
<elopio> I think I got it. Maybe a config file? I wonder how juju does it.
<elopio> I mean,  I think I got what you meant on that sentence, not that I got the solution.
<kyrofa> Heh
<elopio> kyrofa: if you pass -j8 and you have less than 8, it will just do less parallelization right? So it's not terrible to hardcode it.
<elopio> then you can plug it to a fancier way to receive the value. Config or command line, or smart guess.
<kyrofa> elopio, right, it'll make 8 threads and they just won't be able to work concurrently
<kyrofa> elopio, so you think the installflags sounds okay? If the .snap author wants to hardcode something, it's his problem
<elopio> fgimenez: https://xkcd.com/1629/ That's you explaining your jenkins farm :D
<fgimenez> elopio, not enough tools IMO but accurate anyway :D
<kyrofa> elopio, have you ever listened to explanations of openstack? http://cube-drone.com/comics/c/alien-geometries
<elopio> haha, yes. Swipes left for tinder. lol.
<peacememories> hm, the path to deploy snappy as a 'firmware' is a lot more clear than the path to keep said firmware up to date
<kyrofa> My favorite is "Trove -> Mostly just sits there." I never could figure that thing out
<kyrofa> peacememories, how so?
<kyrofa> peacememories, keeping it up to date is one of the biggest upsides to snappy
<peacememories> to keep my snaps up to date seems to require them being in the official store though
<peacememories> ideally i'd like to have the ability to do a firmware upgrade a la digital cameras
<peacememories> which would basically be "update the oem snap", which doesn't seem to be possible
<kyrofa> peacememories, completely offline?
<peacememories> that's one of the requirements, yes
<peacememories> there's two update modes for us atm: a managment server tells sends the software to the device and tells it to update
<peacememories> or a user plugs in a usb with an update
<kyrofa> peacememories, I know there are ongoing discussions about private stores, but that's something I don't know much about (I'd refer you to bueno, but he doesn't seem to be around at the moment)
<peacememories> our structure is not really set in stone yet, but can't come up with many other ideas
<peacememories> yeah, i've read about private stores being 'on the horizon'
<kyrofa> peacememories, yeah you're not the only person that's looking for that. I'm just not sure what the state of it is exactly
<kyrofa> peacememories, I suggest you send out a snappy-devel mailing list post about it
<kyrofa> peacememories, that way you can be sure the right eyes see it rather than trying to wait until they're on IRC
<peacememories> i'll do that. also i'll need to test whether using snappy install *.snap can upgrade packages
<peacememories> thanks for your help so far =)
<kyrofa> peacememories, no problem, sorry my knowledge is a bit limited :)
<peacememories> i wish there was more info out there about deploying embedded systems^^ this is my first voyage into the field and it's pretty daunting
<kyrofa> peacememories, the problem you often run into is that embedded systems are almost always proprietary
<kyrofa> peacememories, so not a lot on google
<peacememories> indeed
<kyrofa> peacememories, but there are some open-source embedded communities, like the rpi, gumstix, and ubuntu core
<kyrofa> peacememories, lots of "learn by doing" in your future ;)
<peacememories> yep. not sure if i'm looking forward to that^^
<kyrofa> peacememories, not the fastest way to learn, but one of the best
<peacememories> i should probably write a blog about this stuff. add a bit to the information out there, even if it's just 'how not to do it'
<kyrofa> peacememories, definitely
<peacememories> okay, so when i install with --allow-unauthenticated my snap gets installed as sideloaded
<kyrofa> peacememories, right
<peacememories> and i assume the only signatures snappy accepts are from the ubuntu store
 * zyga posted https://github.com/ubuntu-core/snappy/pull/326
<zyga> this lets capability types hand out bits of security for variou security subsystems
<zyga> another approach at the security aspect
<kyrofa> peacememories, indeed, which leads back to the private store
 * peacememories sighs
<zyga> jdstrand: ^^ perhaps you can have a look
<zyga> jdstrand: it's different from the earlier approach
<zyga> jdstrand: but I think this is closer in intent to what hwaccess was doing than before
<zyga> jdstrand: one thing I'd love to know about is how device nodes are pushed to the dev namespace today (who's doing that)
<zyga> jdstrand: because nothing in the design handles that yet
<sergiusens> kyrofa, hey, you are indeed right that there is no shebang; there is although an "embedded shebang"
<kyrofa> sergiusens, huh? :P
<kyrofa> sergiusens, I mean, no #! or anything
<kyrofa> sergiusens, compiling mysql is taking so long I have time to look into this all of a sudden :P
<sergiusens> kyrofa, http://paste.ubuntu.com/14497580/ line 30 there is originally /usr/bin/python
<kyrofa> sergiusens, indeed, and I have more lines than you between 1-3
<sergiusens> kyrofa, which may indicate that I fixed this incorrectly
<kyrofa> sergiusens, with another /usr/bin/python. But still no #!, which means the regex won't catch it... no?
<jdstrand> zyga: I haven't looked at the code yet, but to answer your question: hw-assign creates /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules and /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml
<sergiusens> kyrofa, or maybe is too greedy
<sergiusens> kyrofa, I'll look at it now
<kyrofa> sergiusens, alright. I'm looking into the stupid share thing now
<jdstrand> zyga: then hwaccess updates the profile for what is in /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml
<sergiusens> kyrofa, what share?
<jdstrand> zyga: s/profile/security policy/
<sergiusens> kyrofa, getting rid of the ros plugin altogether? :-)
<kyrofa> sergiusens, ha! I mean launching out of share instead of lib
<sergiusens> kyrofa, k, it might be related
<zyga> jdstrand: oh, thanks I didn't know about the udev rule!
<zyga> jdstrand: I'll add that
<jdstrand> zyga: then on app launch, ubuntu-core-launcher sees if /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules exists. if it doesn't, it just launches the app in the normal way. if it does, it creates a device cgroup and puts the devices in /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules into an app-specific cgroup
<jdstrand> zyga: in this manner, apparmor prevents reading devices when no hardware is assigned, and cgroups allow the device to be used by the app
<zyga> jdstrand: so /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml + /etc/udev/rules.d/70-snappy_hwassign_foo.mvo.rules
<zyga> jdstrand: do we need to run a command to recompile anything after those two are made?
<jdstrand> in an ideal world we wouldn't use a cgroup for this and just rely on apparmor, but that is the parser performance conversation we had before
<jdstrand> zyga: yes, snappy needs to regenerate the apparmor policy if /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml is created/updated/removed
<zyga> jdstrand: how is that done (regenerate)
<jdstrand> zyga: but it shouldn't regenerate the policy if /var/lib/snappy/apparmor/additional/foo.hwaccess.yaml is unchanged
<jdstrand> (the regeneration is the slow (relatively) operation)
<jdstrand> zyga: see AddHWAccess(). it calls regenerateAppArmorRules(snapname)
<zyga> jdstrand: ok, I'll follow that along
<zyga> jdstrand: I'll try to get apparmor support sufficient to blink LEDs on raspberry pi tomorrow
<zyga> (without hwaccess)
<jdstrand> zyga: hwaccess.go should be fairly easy to follow with the above context
<jdstrand> zyga: cool!
<sergiusens> kyrofa, this is what I have in the catkin part originally http://paste.ubuntu.com/14497678/
<kyrofa> sergiusens, yeah, same
<sergiusens> kyrofa, ah, the regex wipes line 4 and 5 :-)
<sergiusens> err 3 and 4
<kyrofa> sergiusens, how is that possible? It looks for # followed by !. The .* is perhaps too greedy, but what about that?
<sergiusens> kyrofa, yeah, it should be a broken file in the end
<kyrofa> sergiusens, no... it shouldn't match lines 3-4 at all!
<kyrofa> sergiusens, right?
<sergiusens> oh because of the !
<kyrofa> Right
<sergiusens> kyrofa, more so, the regex matches nothing on this file ;-)
<kyrofa> sergiusens, exactly!
<sergiusens> kyrofa, the first line says it is autogenerated though; any idea if that is during packaging or during unpack or what?
<kyrofa> sergiusens, I expect it's during compilation
<kyrofa> So during packaging
<sergiusens> kyrofa, of ros itself
<kyrofa> Right
<sergiusens> right
<kyrofa> Figured out the rosrun problem
<kyrofa> More shebangs
<kyrofa> sergiusens, time for a grep... what are we dealing with here now that python2 is no longer on the image...
<elopio> woohoo, lxd working again.
<sergiusens> kyrofa, maybe take over the MP and I'll get to the other things
<sergiusens> elopio, nice
<kyrofa> sergiusens, perhaps instead of patching just _setup_util, the post build step should be one big search/replace. Yeah I got it
<sergiusens> kyrofa, I hope the second sentence was a mid reply and not you writing to yourself ;-)
<kyrofa> sergiusens, :P
<sergiusens> kyrofa, I myself seem to have started out the day with the wrong foot :-)
<kyrofa> sergiusens, hahaha
<kyrofa> sergiusens, you got your car at least?
<sergiusens> kyrofa, yeah, I got there and it seemed there was a screw up on when I was supposed to pick it up
<sergiusens> at least it was all checked up; just missing the final "car wash"
<kyrofa> sergiusens, that sounds annoying
<sergiusens> kyrofa, yeah, and no ranting emails from ogra_ to read on my phone :-)
<sergiusens> kyrofa, now that this passsses (with many s's), care to look https://github.com/ubuntu-core/snapcraft/pull/231 ?
<sergiusens> kyrofa, it will make testing the listener and talker easier
<enoch85> kyrofa, here?
<kyrofa> sergiusens, fixed the bug, though I hit another-- the caps have changed on rolling
<kyrofa> sergiusens, network-listener is no longer default?
<sergiusens> kyrofa, ask jdstrand for the equiv :-)
<kyrofa> jdstrand, on 15.04 if all I use is the network I don't have to do anything regarding caps. That seems to have changed on rolling?
<sergiusens> kyrofa, what error do you get?
<jdstrand> if you want to use the network as a client, you should use network-client
<kyrofa> sergiusens, a bad syscall :P
<kyrofa> sergiusens, bind
<jdstrand> if you want to use the network as a service, use network-listener
<kyrofa> jdstrand, oh interesting-- network-client is the default?
<jdstrand> network-client is given if you don't specify anything
<jdstrand> if you start specifying other stuff, you need to specify it
<jdstrand> too
<kyrofa> jdstrand, what is the difference between the client and listener?
<kyrofa> jdstrand, are you just assuming clients won't bind?
<kyrofa> Oh duh, thinking binaries, sorry
<kyrofa> jdstrand, understood, thanks
<jdstrand> np
<jdstrand> there is also unix-listener if you need to bind to a unix socket
<kyrofa> jdstrand, awesome :)
<jdstrand> (network-listener is for binding to a network socket)
<jdstrand> at this point, they aren't different, but they will be soon
<kyrofa> jdstrand, does network-listener encompass network-client?
<jdstrand> kyrofa: no. there are some apparmor rules that are different
<jdstrand> network-listener might be all you need now, but that is a different question
<kyrofa> jdstrand, hmm. I guess we'll find out
<jdstrand> (ie you may not need the rules that differentiate them)
<jdstrand> in 16.10 and later they will be more different
<kyrofa> jdstrand, is there a reason /proc/pid/status is disallowed in the profile?
<kyrofa> jdstrand, rather, not present
<jdstrand> kyrofa: that's queued for stable, fixed in 16.04.12 on rolling
<kyrofa> jdstrand, ah excellent-- mysql needs it
<kyrofa> jdstrand, any chance we can get that back in 15.04?
<kyrofa> jdstrand, or is that what you meant by stable?
<jdstrand> that is what I meant be stable
<jdstrand> by*
<wxl> so i have problems creating images with ubuntu-device-flash and i greped the entire code for it for the word "partition" since my problem is "issues when partitioning" and there's no result. any clues as to where else i can start looking?
<kyrofa> jdstrand, any ETA for that?
<jdstrand> kyrofa: maybe I can get it in real quick since a stable image is queued to be built
<kyrofa> jdstrand, you would be my hero
<jdstrand> kyrofa: it is in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages. hopefully I got it in in time
<kyrofa> Thanks jdstrand! Sorry for the rush, but I really appreciate it
<jdstrand> I already had it prepared
<jdstrand> I was waiting for feedback on another thing that I would add depending on what they said
<jdstrand> so I just uploaded what I had. no biggie :)
<kyrofa> jdstrand, excellent :)
<jdstrand> I thought it weird that access never came up before last week
 * jdstrand shrugs
<kyrofa> jdstrand, how can I track that so I know when I can snappy update to get it?
<kyrofa> jdstrand, more and more people using it, I would guess
<jdstrand> sure, it just seems like that access was so basic
<jdstrand> anyhoo
<kyrofa> jdstrand, indeed
<jdstrand> well, mvo is doing a stable update for something else
<jdstrand> I think there might be a manifest somewhere for snappy stable images, but I can never seem to remember where it is
<jdstrand> if the images updates, do 'dpkg -l|grep ubuntu-core-security' and see if 15.04.12~ppa15 is installed (that is what I would do if I didn't want to ask anyone)
<kyrofa> jdstrand, alright, thanks :)
<sergiusens> kyrofa, is this what I need http://wiki.ros.org/image_view ?
<kyrofa> sergiusens, yes
<sergiusens> kyrofa, iow, I need a trusty machine, right?
<kyrofa> sergiusens, it's in their repos as well if you want to just setup ROS on an lxc
<kyrofa> sergiusens, that's safest anyway
<sergiusens> kyrofa, does it expose it over the web? I'll setup a trusty lxc
<sergiusens> kyrofa, I just setup a 16.04 ubuntu core laptop to test
<sergiusens> so I am also making your snap 16.04 ready ;-)
<kyrofa> sergiusens, nahh nothing runs by default unless you run it
<kyrofa> sergiusens, ooo, living on the edge!
<sergiusens> kyrofa, of course
<sergiusens> kyrofa, right, I'm confused by this messaging Nodelet version of image_view. Brings up a display window for a sensor_msgs/Image topic.
<kyrofa> sergiusens, the face_detector publishes a sensor_msgs/Image
<kyrofa> sergiusens, so image_view subscribes to that and displays it in a window
<sergiusens> kyrofa, right, I will need my lxc to have knowledge of such windowing system :-)
<kyrofa> sergiusens, I just do reverse-X
<sergiusens> kyrofa, as in ssh -Y or -X ?
<kyrofa> sergiusens, lxc GUIs were too painful for me
<kyrofa> sergiusens, yeah, ssh -X
<rickspencer3> does anyone know which GPIO pins work on the rpi2 "out of the box"?
<rickspencer3> arg, never mind, I was holding it upside down :/
<elopio> rickspencer3: like with the pins facing the table? ;)
<rickspencer3> something like that
<rickspencer3> no, I guess I should have said "I was holding it backwards"
<rickspencer3> the arduino is designed for people like me, they label the pins :)
 * rickspencer3 wonders if getting some dinner might help
<kyrofa> elopio, hahaha, funny image
<elopio> rickspencer3: I got this https://www.adafruit.com/products/2314 and then I realized I had to learn to solder first :)
<kyrofa> elopio, ROS stuff runs on xenial now with this: https://github.com/ubuntu-core/snapcraft/pull/232
<elopio> kyrofa: cool. I just left PITA style comments.
<kyrofa> elopio, thanks! :)
#snappy 2016-01-15
<elopio> sergiusens: kyrofa: would it be ok to add the nodejs version to the yaml?
<elopio> it seems to work to package bonescript with node 0.10.
<sergiusens> elopio, in the schema?
<sergiusens> it does if we have links, yeah
<sergiusens> is this older or newer?
<elopio> sergiusens: older.
<sergiusens> elopio, ah, then maybe test; if it is location indep as the current one it may be all ok
<elopio> you are building the link from a constant. I think we can make that constant the default, and accept a variable from the conf.
<sergiusens> elopio, as long as the semantics for installing are ok, we should be good
<sergiusens> elopio, btw, for running the example tests, can we just download the image from mvo's pcc?
<elopio> the problem is that the only example I have requires beaglebone, and I can't test if the generated snap works because bbb is busted.
<elopio> sergiusens: yes, download it, start it in kvm, and then call ./runtests.sh --ip localhost --port 8022
<sergiusens> elopio, ah, nice
<sergiusens> elopio, I'm no sure about adding the example as an example; since the example is not complete; what do you say?
<elopio> sergiusens: do you mean the one by andreas?
<sergiusens> elopio, yeah
<elopio> sergiusens: yeah, I wasn't thinking about everything he has in there.
<elopio> something more simple that shows the issue.
<elopio> your unit tests are good, so this is not a blocker. But it would be nice to have.
<sergiusens> elopio, something simple mean writing auto.*.ac and Makefile.am though and I am not profficient in that
<sergiusens> let me see if I can find something simple
<elopio> sergiusens: I understood you requested that from andreas.
<fazer> Can anyone take a look at this pull request: https://github.com/ubuntu-core/snapcraft/pull/233 and let me know why it thinks the coverage has decreased?
<fazer> nevermind, ignore my last comment.
<fazer> elopio, kyrofa, sergiusens If possible can you take a look at this: https://github.com/ubuntu-core/snapcraft/pull/233
<raspberrypifan> how does deduplication work
<happyaron> what dedup you mean?
<fgimenez> good morning
<JamesTait> Good morning all! Happy Friday, and happy Hat Day! ð  ð©
<liuxg> Chipaca, ping
<Chipaca> liuxg: pong
<liuxg> Chipaca, I accidentally installed snapcraft by running "python3 setup.py install", now my snapcraft version is totally wrong. do you know if there is any method to remove the installation?
<Chipaca> liuxg: you installed it at the system level, by hand?
<Chipaca> liuxg: ie you actually did "sudo python3 setup.py install"?
<Chipaca> liuxg: or did that install it in your home directory?
<liuxg> Chipaca, by hand, last time, snapcraft did not support the local source code, I reported a bug, and later on, sergiusens asked me to try it. I tried to install it by hand.
<liuxg> Chipaca, I tried the method at  https://stackoverflow.com/questions/1550226/python-setup-py-uninstall , since I pulled down the latest repository, and now my snapcraft version is 2.0. I think it should not be so right for me.
<Chipaca> liuxg: I'm afraid I have no idea in what state you've managed to put your system
<liuxg> Chipaca, yes, I actually did "sudo python3 setup.py install" manually on my PC.
<Chipaca> oh dear
<Chipaca> don't do that
<Chipaca> ever
<Chipaca> your system is now in an unknown state
<liuxg> Chipaca, I know it is too late. I really want to get it back. the snapcraft is totally wrong.
<Chipaca> you have actively decided to take control of your system away from apt and do it manually
<Chipaca> so you will have to clean it up manually
<Chipaca> and hope that that is enough
<Chipaca> liuxg: do you have a log of the installation process?
<Chipaca> liuxg: to know exactly what that setup.py install actually installed?
<liuxg> Chipaca, now, the snapcraft info is like http://paste.ubuntu.com/14503790/ on my PC..
<liuxg> Chipaca, as said, I followed the link https://stackoverflow.com/questions/1550226/python-setup-py-uninstall, and now the files are http://paste.ubuntu.com/14503796/
<liuxg> Chipaca, I have removed the files already, however the snapcraft version still shows 2.0
<Chipaca> liuxg: do you have a log of the installation process?
<liuxg> Chipaca, I do not have that unfortunately, it happened  long time ago. Do you want me to try it again?
<liuxg> Chipaca, the help content is still for 1.0 http://paste.ubuntu.com/14503819/ though the version shows 2.0
<Chipaca> no, do not try it again
<Chipaca> liuxg: pastebin the output of: find /usr/local -ls
<liuxg> Chipaca, http://paste.ubuntu.com/14503836/
<Chipaca> liuxg: ok, i can't guid you through that
<Chipaca> liuxg: what you need to do is remove all traces of snapcraft from your system
<Chipaca> liuxg: and all the dependencies that the manual install installed
<Chipaca> liuxg: but you've got too much other cruft in /usr/local for me to help
<Chipaca> liuxg: so
<Chipaca> liuxg: first, sudo apt-get purge snapcraft && sudo apt-get --purge autoremove
<Chipaca> liuxg: then, manually remove from /usr/local anything your manual install might've installed
<Chipaca> you've got django and npm and who-knows-what-else in there, so good luck with that
<Chipaca> also given you've got npm, you've probably got your system in a screwy state anyway. You're on your own.
<Chipaca> next time you feel the need to install something in your system without using apt-get, use a virtual machine
<liuxg> Chipaca, I have done  sudo apt-get purge snapcraft && sudo apt-get --purge autoremove the command, so I need to reinstall it?
<Chipaca> or tell whatever tool you're using to install stuff to do so in a local environment and not in the system itself
<Chipaca> liuxg: you reinstall *after* cleaning /usr/local
<liuxg> Chipaca, do I need to remove all of the snapcraft related directories manually?
<Chipaca> liuxg: the ones you created manually? yes
<Chipaca> by manually there i mean 'via python3 setup.py' also
<liuxg> Chipaca, in fact, I did not manually create the directories. after running your "remove" command, the directory is like http://paste.ubuntu.com/14503863/
<liuxg> Chipaca, may I just go ahead to manually remove those snapcraft related directoies?
<Chipaca> liuxg: those are the ones you created via 'python3 setup.py'
<liuxg> Chipaca, I think so. I did not manually create those directories and files.
<Chipaca> liuxg: apt-get did not create them; you created them yourself, using setup.py. You did not do 'mkdir', no, but you created them outside of the control of the packaging system
<liuxg> Chipaca, yes, I think the setup.py created them.
<liuxg> Chipaca, so, may I just remove them manually?
<Chipaca> liuxg: I have told you yes twice already. This is the third time. Yes, remove manually those directories which you created using setup.py.
<Chipaca> liuxg: as you have not kept a log of what you did with setup.py, I can't tell which those are. You're on your own.
<liuxg> Chipaca, OK. thanks! I just want to double confirm it :)
<liuxg> Chipaca, thanks for helping. now my snapcraft version become 1.0 :)
<sanong> Help guys. I just download snappy OVA and run it. But default user/pwd  not working
<sanong> https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/
<sanong> cant logon with ubuntu / ubuntu
<sanong> any one ?
<sanong> any know default user/pass other than ubuntu/ubuntu
<zyga> sanong: not that I know
<sanong> i download .OVA and  boot vm
<sanong> cant logon
<mvo> ogra_: so I looked a bit into the multiple initird stuff for snappy - one generic initird from ubuntu-core, one with the kernel specific bits from the kernel. it seems feasible but I will need some help with the uboot stuff, do you think you could give me a hand with that?
<Chipaca> mvo: who creates the ova files?
<mvo> Chipaca: ova files? what does that mean?
<Chipaca> mvo: it's one of the options here https://cloud-images.ubuntu.com/snappy/rolling/core/edge/current/
<Chipaca> mvo: and was blogged about here https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/
<Chipaca> mvo: but i know we don't build 'em
<mvo> Chipaca: oh, I think thats ben howard
<Chipaca> mvo: and sanong above was saying he couldn't log in with u/u
<mvo> Chipaca: with this particular image he can not log in?
<Chipaca> <sanong> cant logon with ubuntu / ubuntu
<mvo> he is no longer in the channel :/ did he/she mention what image?
<beowulf> mvo: i think there's only one, i can try it on vmware now ...
<mvo> thanks beowulf
<sanong> OVA was published  https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/
<sanong> by one of cannocal marketing
<sanong> I think all snappy image will have same password. Any know ?
<beowulf> mvo_: sanong: i see that too, the ubuntu/ubuntu password doesn't work on that image
<beowulf> s/image/ova
<sanong> anyone know password
<mvo_> utlemming: hi, I hope you are the right person to ask - do you know more about the ova images? we got a report from sanong that the login via ubuntu/ubuntu does not work with those. maybe thats intentional because of the cloud nature, but maybe https://insights.ubuntu.com/2015/01/15/snappy-ubuntu-core-now-on-the-hypervisor-of-your-choice-with-ova/ could mention if the login is different
<utlemming> mvo_: that is correct; OVA's are cloud targets
<mvo_> sanong: see above, this is intentional
<beowulf> sanong: is this for virtualbox or vmware or something else?
<utlemming> mvo_, sanong: http://blog.utlemming.org/2015/04/using-snappy-ova-images-when-you-dont.html
<utlemming> sanong: use option 2
<ogra_> mvo_, multiple ?
<ogra_> why multiple
<ogra_> just move the modules into a squashfs and mount them right before anything else
<mvo_> ogra_: one generic one with our scripts and one with kernel modules if you boot your snappy from a remote iscsi target
<utlemming> sanong: cloud image targets need to have security. We can't have every cloud image of Snappy universally accessible by a well-known password
<ogra_> mvo_, well, if you boot from iscsi, your initrd needs to come from somewhere ... just put the modules suqshfs next to it in the same place
<mvo_> ogra_: right, we can do that if everything is in the kernel that is needed to mount root - this won't work right now even for us because of squashfs.ko. but mayb apw can help and make squashfs.ko a buildin for the kernel
<ogra_> and loop mount it
<ogra_> no
<ogra_> you dont need everything to mount root
<ogra_> you only need everything to loop mount the modules squashfs from the same place yoou load your intird from
<mvo_> ogra_: I'm not sure I follow. what if your initird comes from pxe boot?
<sanong> wont work
<ogra_> well, tftp then
<sanong> try that
<sanong> already
<ogra_> if your initrd comes from the net that measn that you have a way to pull the suqashfs the same way
<sanong> will that be the cause ?
<ogra_> i just dont see a need that we have more than /lib/modules|firmware in tthat squashfs
<beowulf> utlemming: i've been using u-d-f and then qemu-img convert to vmdk for vmware ... option 3 :)
<ogra_> mvo_, indeed that requires to have squashfs and loop device support in the kernel itself
<mvo_> ogra_: so our generic initird would fetch (cp, tftp, *) a file right next to the initird img and use that for the modules? and we enforce that the kernel has enough support buildin to get to that place? that works for me
<ogra_> (though i guess we dont necessarily need it to be a squash image)
<mvo_> ogra_: so we just need to convince the kernel people to give us this kernel
<mvo_> ogra_: yeah, it can be anything
<ogra_> right
<utlemming> orgra_: why not an initramfs script?
<mvo_> ogra_: works for me, lets talk about the details on monday
<ogra_> the PXE part will be a bit tricky since we need to do the loading from there ... we cant do it from the initrd, else we'd need all NIC modules
<ogra_> utlemming, ^
<ogra_> :)
<ogra_> mvo_, yeah
<utlemming> ah, right
 * ogra_ is looking forward to finally implement the generic initrd :) 
<ogra_> oh !
<mvo_> ogra_: well AIUI the multiple-initird is really just two initrds concacted so this approach might work for PXE
<beowulf> sanong: if you try option 2 as utlemming outlines in his blog post it will work
<mvo_> (or multiple ones, not just two)
 * ogra_ just noticed that the DSL update on his second DSL line has happened while being at the dentist ... 
<ogra_> WOHOOO !!!
<ogra_> from 2Mbit to 50 !
<mvo_> ogra_: congrats
<mvo_> ogra_: thats a jump
<ogra_> yeah
<shuduo> hi, after I sideload install a snap on snappy, what is its package name? for example, webcam-webui demo of snapcraft-examples
<ogra_> well, i need to reconfig the phone stuff now ... else susie will kill me
<mvo_> ogra_: enjoy, we talk monday. the pxe issue with the nics sounds serious to me though, worth thinking about it more IMO
<stevebiscuit> shuduo: "webcam-webui.sideload" I believe
<ogra_> mvo_, yeah
<shuduo> stevebiscuit: yes, it's . thanks.
<apw> mvo_, there is cirtainly some support for multiple initrds concatentated yes, they all get unpacked
<apw> mvo_, and if you want a generic one and a device specific one ramming them together on the rmeote server sounds like a good plan
<apw> mvo_, not that you can look at them any more with the tooling but hey
<mvo_> apw: cool, we can write new tooling for that - if thats fully supported that sounds like the easiest option.
<mvo_> ogra_: -^
<mvo_> ogra_: if its just a concat but otherwise looks like a normal initrd that seems like its what we want, right?
<apw> mvo_, let me investigate to confirm, i know we use it for cpu firmware, that makes a dual initrfamfs
<mvo_> apw: thanks!
<ogra_> so the added part would have /lib/modules|firmware only ?
<apw> mvo_, i believe you can literally cat A B >initrd and the kernel groks them
<mvo_> ogra_: yeah
<apw> mvo_, if each is in the rigght format
<mvo_> apw: sweet
<ogra_> yeah, thats similar to mounting a squashfs i guess
<ogra_> just earlier
<apw> mvo_, but let me go and confirm that on a VM first
<mvo_> apw: thanks!
<apw> mvo_, the refulting file is just bits from a bootloader point of view
 * mvo_ likes this 
<apw> mvo_, and because we use it for cpu firmware i beleive we know the bootloaders ought to handle it right
<mvo_> apw: yeah, exactly, this is the part I like, pxe, uboot, grub all work as before, the smartz is in the kernel
<apw> mvo_, anyhow leave it with me for a little and i'll report back
<mvo_> apw: and we don't even need to modify anything in our scripts
<mvo_> apw: sure, no rush really
<apw> just the making the initrd needs to change
<mvo_> apw: I was waiting for an image upload and this was nagging in the back of my mind :)
<apw> and ... i assume ninitramfs-tools already knows how becuase it does it for cpu firmwae
<apw> mvo_, if i don't do it now i will forget :)
<mvo_> apw: yeah, well, we just make two initrds with the normal tooling and in the final stage do the cat - sounds easy
<mvo_> (foumous last words)
<mvo_> apw: ha! do it NOW
<mvo_> :)
 * mvo_ gets lunch in the meantime
<mvo_> ogra_: sounds exciting, generic initird afterall :)
<ogra_> \o/
<mvo_> ogra_: but I leave you alone, enjoy your vac
<mvo_> :)
<ogra_> yeah, and my new teeth :)
 * ogra_ just returned from dentist 
<mvo_> ogra_: woah, new dsl, new teeth, the year starts great it seems
<mvo_> (and generic initrd soon)
<ogra_> well, only interim teeth, but yeah ... after 20years the visibla gap is gone :)
<apw> ogra_, nice
<kyrofa> Good morning
<kyrofa> sergiusens, would it be bad if plugins could add apps?
<sergiusens> kyrofa, not at all, but we need to design for it
<sergiusens> kyrofa, as in, lets not just bolt that together and hope for the best passing the full snapcraft yaml dictionary to plugins
<sergiusens> kyrofa, are you thinking of catkin?
<sergiusens> kyrofa, the problem then becomes, is it a daemon, a cli, a desktop icon...
<kyrofa> sergiusens, right, which would need to be handled by the plugin as well. And yeah, catkin and roscore (I'm still trying to think of how to get rid of the roscore plugin :P )
<sergiusens> kyrofa, I don't see why the catkin plugin can't just do everything in there
<kyrofa> sergiusens, only one single reason: When we have the ability to share roscore, what if someone wants to make a shared .snap containing JUST roscore?
<kyrofa> I guess if I updated the catkin plugin to accept building no packages, then they could specify the stage package and the app just like normal
<kyrofa> sergiusens, think that would be good enough?
<apw> mvo_, ok confirmed if you make a second initramfs cpio.gz style image and literally cat play.gz >>initrd.img the kernel will load both and merge them before executing
<apw> mvo_, and from what i can see of the code it literally keeps trying until there is no data, so you can have 10
<sergiusens> kyrofa, I think so
<sergiusens> kyrofa, but lets get this in and work on that next week as I guess it is not a 1 hour task :)
<sanong> updated : OVA option 2 : still cant logon with ubuntu/ubuntu
<sanong> try 2 image now
<sergiusens> ogra_, enjoy some ferocious meat eating then ;-)
<ogra_> haha, i will :)
<kyrofa> sergiusens, agreed. And if we can figure out a good way for plugins to add apps, that would get really slick
<sergiusens> kyrofa, sure, let's brainstorm that a bit next week ;-)
<kyrofa> sergiusens, or the week after, considering where you'll be :P
<kyrofa> sergiusens, I need to miss standup-- I need to watch the kiddo this morning
<sergiusens> kyrofa, no worries
<tsimonq2> mvo_: o/
<tsimonq2> mvo_: I have been here for the past few weeks :)
 * zyga posted https://github.com/ubuntu-core/snappy/pull/329
<zyga> more bool file work around security
 * zyga refreshed https://github.com/ubuntu-core/snappy/pull/324 (merge with trunk, delta minimized)
<mvo_> tsimonq2: haha, sorrry :) there is so much going on, I did not really notice :)
<tsimonq2> :)
<sergiusens> kyrofa, good job on the branch, I just tried it with all the other branches and it works fine :-)
<kyrofa> sergiusens, excellent!
<sergiusens> kyrofa, so the only thing I don't like about squashing is that I can't see what changed between two pushes, any easy way to check from the github ui?
<kyrofa> sergiusens, hmm... there is in gitlab... looking
<zyga> fgimenez, elopio: what does it mean when github says "no test results found" for integration tests?
<zyga> flaky tests? flaky test system? something else?
<kyrofa> sergiusens, it doesn't seem so. If it was just us I'd suggest using --fixup commits in response to PR review, and one autosquash before merge, but I'm concerned about asking the community at large to do that
<sergiusens> kyrofa, maybe we can merge without using github ;-)
<kyrofa> sergiusens, what are you thinking?
<sergiusens> doing it manually
<sergiusens> or maybe an automated task with our merge strategy
<kyrofa> sergiusens, haha, I mean in what situation?
<sergiusens> kyrofa, just random friday thoughts though
<kyrofa> sergiusens, that's what Fridays are for :)
<kyrofa> sergiusens, what should REALLY happen is that github should autosquash upon merge FOR you. That's what I think
<sergiusens> kyrofa, ask jono for that ;-)
<kyrofa> sergiusens, ha! Brilliant!
<kyrofa> sergiusens, I mean, it would always succeed and the commit message is a given because they're fixups
<sergiusens> kyrofa, hmm, you coverage has dropped :-P
<kyrofa> sergiusens, I know... stupid roscore plugin
<kyrofa> sergiusens, I need to bite the bullet and toast it. Next week maybe
<kyrofa> sergiusens, but I think that PR is good to go if you're good with it
<sergiusens> kyrofa, yay for toasting, and yes, I'm merging it before elopio wakes up ;)
 * sergiusens takes a break to run a bit
<kyrofa> mvo_, any idea when the new 15.04 image will be built?
<mvo_> kyrofa: its ready, I am prepareing the pre-build images as we speak
<mvo_> meeting right now
<kyrofa> mvo_, excellent :)
<fgimenez> zyga, that's normally because of a problem before the execution even starts, if you follow the "Details" link in the PR page you can reach the console log page to inspect the cause http://162.213.35.179:8080/job/github-snappy-integration-tests-cloud/344/console
<fgimenez> zyga, it seems that there was a connectivity problem getting the dependencies
 * zyga works on apparmor security module
<zyga> fgimenez: thanks! what's the procedure in that case? Retry/
<mvo_> kyrofa: you should get the new 15.04 via snappy update already (if you haven't already)
<kyrofa> mvo_, nothing yet
<mvo_> kyrofa: what does snappy list show you? and what does snappy info show?
<kyrofa> mvo_, wait... I see a version 12 with the release date of today. Is that it? Must have been done automatically?
<mvo_> kyrofa: yep, magic :)
<mvo_> kyrofa: great, thanks!
<fgimenez> zyga, yes, you can retrigger the execution with a comment "retest this please"
<kyrofa> mvo_, jdstrand ah, 15.04.12~ppa15 of the security packages didn't make it in eh?
<jdstrand> kyrofa: unfortunately not it seems. I just checked myself
<jdstrand> kyrofa: I tried. the builder and mvo were too fast
<kyrofa> jdstrand, haha, that's alright, I can work around it for now :)
<jdstrand> mvo_: context> there is an update to ubuntu-core-security that kyrofa needs that I tried to sneak in last night
<zyga> jdstrand: hello :)
<mvo_> jdstrand: heh, the builders were not exactly fast :) thats unfortunate, but there is always a next image. how urgent is that update?
<jdstrand> mvo_: I'll let kyrofa comment on that
<jdstrand> zyga: hello :)
<sergiusens> elopio, going to be 15' late if you don't mind
<sergiusens> kyrofa, just in case ^
<kyrofa> mvo_, how often are images built? Think another one will come out before Wednesday?
<mvo_> kyrofa: unlikely. we can build anohter one, why wednesday?
<kyrofa> mvo_, deadline for the owncloud stuff, but I can always add permission to the .snap temporarily
<zyga> jdstrand: do you know of any sysfs symlink attacks?
<zyga> jdstrand: just curiosity around how I've structured some bits in the code so far
<zyga> jdstrand: is it a security issue to resolve symlinks in sysfs multiple times vs doing it once and caching the result
<zyga> (for the same path0
<jdstrand> zyga: not otoh but I'd like tyhicks to comment too
<zyga> jdstrand, tyhicks: https://github.com/ubuntu-core/snappy/pull/329/files that's the place
<kyrofa> sergiusens, nothing makes you appreciate mksquashfs like using 1.0
<sergiusens> kyrofa, lol
<jdstrand> mvo_: oh, also, big thank you for the emergency update :)
 * jdstrand hugs mvo_ 
<mvo_> jdstrand: heh, thanks! thank you for fixing it in the first place
<jdstrand> mdeslaur: ^ :)
<mvo_> jdstrand: I read through the details of the cve
<mvo_> interessting stuff and scary
<jdstrand> yeah, it was a really well done investigation
 * jdstrand notes mdeslaur did the update-- he deserves the credit :)
<kyrofa> jdstrand, ooo I'd like to read this
<jdstrand> kyrofa: https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/OpenSSHClientRoaming. at the bottom, see Qualys findings
<kyrofa> jdstrand, ah, that explains why SSH updated on all my servers last night
<jdstrand> indeed :)
<pindonga> elopio, I see your PR passed tests but stalled en coveralls
<pindonga> is that normal?
<elopio> pindonga: ugh, no, it was a lie. Travis playing with my feeligs.
<elopio> Fails with this: call to remove-on-empty (freezer:0) failed: invalid request
<elopio> pindonga: what if you skip your tests if the system is not xenial?
<elopio> I will run them here, and once we get this working they will start running on CI.
<pindonga> elopio, the problem is that my PR introduces a new dependency which currently is only available on xenial
<pindonga> not sure if it's worth playing the backports game here
<pindonga> unless of course we need the latest snappy to work on trusty
<tyhicks> zyga: I'm not aware of any symlink attack possibilities in sysfs
<elopio> pindonga: ah, right. We don't need to backport. So, let me bother stgraber one more time.
<elopio> stgraber: I am now getting "call to remove-on-empty (freezer:0) failed: invalid request". Any pointers about how to fix that?
<sergiusens> elopio, kyrofa mvo_ mind looking at this https://github.com/ubuntu-core/snapcraft/pull/234 it is the envvar replacement one
<sergiusens> I'll run tests in the meantime
<elopio> sergiusens: seems simple enough. And as snappy supports both for now, I won't even have to update my snaps.
<sergiusens> elopio, right; that's why I want it in now; if people start uploading, they might as well have the smallest delta possible
<elopio> agree.
<zyga> tyhicks: thanks
<sergiusens> mvo_, how do I get the latest snappy-debug on 16.04?
<mvo_> sergiusens: build as squashfs and upload to the edge channel with rolling as the target
<mvo_> sergiusens: this way you can only install it via snappy install snappy-debug/edge in 16.04
<mvo_> sergiusens: but at least you can intsall it
<mvo_> and once the store is ready we can make it available without the edge
<sergiusens> mvo_, I don't even know where snappy-debug sources are, I just consume it ;-
<sergiusens> ;-)
<mvo_> sergiusens: neither do I, I would just download, unpack (dpkg-deb -x), repack and reupload :)
<mvo_> sergiusens: thats what I did with docker
<sergiusens> mvo_, ack
<fgimenez> elopio, for the deploy you need also to wait for the images to be built https://hub.docker.com/r/fgimenez/snappy-jenkins/builds/ https://hub.docker.com/r/fgimenez/snappy-jenkins-slave-xenial/builds/ and https://hub.docker.com/r/fgimenez/snappy-jenkins-slave-vivid/builds/
<sergiusens> elopio, green light ahead, just don't go to fast or a red light will get you crashing ;-)
<elopio> sergiusens: do not be hasty, that is my motto.
<elopio> https://i.ytimg.com/vi/8HHVPnvDBlU/maxresdefault.jpg
<elopio> fgimenez: I forgot about this: https://github.com/ubuntu-core/snappy-jenkins/pull/45
<sergiusens> elopio, that IS south america :-P
<elopio> fgimenez: for the cloud provision we are still using nova.
<elopio> should we move that also to openstack?
<fgimenez> elopio, yes we need to update that too, but it's not urgent IMO running from the laptop doesn't give the error, i'll take note of it
<elopio> ack.
<kyrofa> sergiusens, if vivid is EOL next month, what is the official recommendation for what people should be using for Ubuntu Core?
<kyrofa> sergiusens, it can't really be rolling, can it?
<elopio> fgimenez: do you know about this? http://pastebin.ubuntu.com/14505876/
<elopio> ah, that's the openstack bug.
<fgimenez> elopio, yes https://bugs.launchpad.net/ubuntu/+source/python-keystoneclient/+bug/1242992, you are running from a canonistack instance, i forgot
<ubottu> Launchpad bug 1242992 in python-keystoneclient (Ubuntu) "Unable to autolaunch a dbus-daemon without a $DISPLAY for X11" [Undecided,Confirmed]
<elopio> ok, I'll do the update here.
<sergiusens> kyrofa, in theory, mvo_ is working hard to get an alpha channel or similar for 16.04
<sergiusens> but they know the plan better, or maybe olli
<fgimenez> elopio, all the docker images have finished building
<mvo_> kyrofa, sergiusens  my suggestion is to (ab)use the "edge" channel for 16.04 snaps - if that was the question, I lack some context here it seems
<kyrofa> mvo_, vivid EOL is next month. My question was "what should people use between then and 16.04?"
<kyrofa> mvo_, or will vivid Ubuntu Core continue to receive updates?
<mvo_> kyrofa: I think we need to continue to do updates for some weeks
<mvo_> kyrofa: I would love to get an alpha out and delcare it good enough
<mvo_> but there are some gaps still
<kyrofa> mvo_, yeah, okay good I'm glad to hear that
<kyrofa> mvo_, I know that's more work, but I think it'll be appreciated
<elopio> fgimenez: is nova boot --poll the same as openstack server create --wait?
<fgimenez> elopio, yes, but not sure if the output has the same fields/format, maybe our checks needs some tweaking
<elopio> I will know soon.
<elopio> sergiusens: so this 2.0 release should work on all snaps? or also on the rolling edge non-all-snaps?
<sergiusens> elopio, on both, but why?
<elopio> sergiusens: just to see which one to flash.
<sergiusens> elopio, flash all snaps
<sergiusens> elopio, obviously ;-)
<sergiusens> mvo_, bootloader stuff now lives in the kernel, rght?
<sergiusens> or should live there
<mvo_> sergiusens: should, its not done yet, still the gadget that is doing it
<sergiusens> mvo_, right, I'm just in "writing presentation" mode
<kyrofa> sergiusens, can you explain now the tmp stuff works? In the binary wrapper I see `TMPDIR="/tmp/snaps/name/version/tmp"`, but when I look in /tmp I see /tmp/snap.0_name_version/ which contains a file called tmp
<kyrofa> sergiusens, is there some confinement magic happening there?
<sergiusens> cgroups and mounts
<sergiusens> kyrofa, ^
<kyrofa> sergiusens, okay very good, thanks :)
<elopio> sergiusens: the shout port is 9000, right?
<sergiusens> elopio, I will lie if I say yes
<sergiusens> elopio, check with netstat
<elopio> sergiusens: shows only 22 for tcp.
<elopio> I think it's not serving, but the logs show no errors, as far as I can see.
<elopio> fails on rolling edge #320 and on all snaps.
<elopio> sergiusens: kyrofa: can one of you verify if you can access the shout or webchat port from the host?
<sergiusens> elopio, let me check
<sergiusens> kyrofa, I still have /usr/bin/python, can you give it a try?
<kyrofa> sergiusens, yeah one sec
<elopio> One more thing. Latest rolling edge, I get (amd64)ubuntu@localhost:~$ java-hello-world.hello
<elopio> /apps/java-hello-world.sideload/IKNMMGUUJQeN/command-hello.wrapper: 9: exec: /bin/wrapper: not found
<elopio> sergiusens: kyrofa ^
<elopio> it works on all snaps.
<elopio> maybe it doesn't have the short env vars.
<sergiusens> elopio, I guess it is the cap
<sergiusens> elopio, install hello-world.mvo and verify ;-)
<elopio> sergiusens: hello-world.echo from hello-world.mvo works.
<sergiusens> elopio, I mean, run hello-world.env and check the env :-)
<elopio> ah
<kyrofa> sergiusens, to verify: the ros example has stuff rewritten fine?
<elopio> SNAPP_APP_PATH=/apps/hello-world.mvo/2.0
<sergiusens> kyrofa, yeah
<elopio> sergiusens: what cap?
<sergiusens> elopio, network-listener
<elopio> sergiusens: oh, you mean the shout problem.
<kyrofa> elopio, bit me yesterday too
<sergiusens> elopio, yeah, all server things might need that
<kyrofa> elopio, by default the cap is network-client, which doesn't allow binding
<sergiusens> elopio, I don't see apparmor denials though
<kyrofa> sergiusens, I think it's seccomp
<sergiusens> kyrofa, how did you check those again?
<elopio> where are seccomp problems printed?
<kyrofa> sergiusens, I think snappy-debug still pulls them out though... what clued me in initially was an illegal syscall
<kyrofa> sergiusens, i.e. my binary was aborted
<sergiusens> kyrofa, snappy-debug does not work on rolling
<kyrofa> sergiusens, which I believe should happen if it's a seccomp denial
<kyrofa> sergiusens, oh
<jdstrand> sergiusens: it doesn't work on rolling cause it isn't squashfs yet you mean?
<sergiusens> jdstrand, no one asked for the full story ;-)
<sergiusens> in any case I'm dpkg-deb -x'ing it and creating a snap again
<jdstrand> sergiusens: does the store support targeting different releases yet? Ie, can we have snappy-debug as ar for stable and squashfs for rolling?
<jdstrand> I saw in mvo's email that was coming but didn'
<jdstrand> t see a subsequent announcement that it was implemented
<sergiusens> elopio, confirmed * add one of 'firewall-management, network-listener, unix-listener' to 'caps'
<sergiusens> jdstrand, the trick he said to use was to put rolling stuff on the edge channel
<jdstrand> sergiusens: ack. sounds like you are handling the snappy-debug upload for rolling/edge then?
<sergiusens> jdstrand, if you are fine with me unpacking and repacking and it is in the canonical account I forgot the password for, then sure ;-)
<jdstrand> sergiusens: and for future reference, all I need for squashfs snaps is snapcraft 2.0?
<jdstrand> well, I was actually just setting up a new all snaps vm
<sergiusens> jdstrand, yes; which we are trying to get into xenial cleanly
<sergiusens> jdstrand, the all snaps ones are much better than the s-i ones, so much more cleaner albeit you can't hack into the os
<sergiusens> or any other snap for that matter
<jdstrand> sergiusens: snapcraft 2.0 is in what ppa?
<sergiusens> jdstrand, none today; planning on going straight into xenial
<jdstrand> sergiusens: yes, I already have a debugging/development method involving bind mounts for that :)
<jdstrand> sergiusens: ah, so if it isn't available anywhere, I'd prefer you handle the upload
<jdstrand> I'm happy to test it though
<jdstrand> sergiusens: in fact, if you upload it, ping me and I'll test it and approve it
<sergiusens> jdstrand, http://people.canonical.com/~sergiusens/snappy/snappy-debug_0.11_all.snap
<sergiusens> elopio, kyrofa in case you need it for rolling http://people.canonical.com/~sergiusens/snappy/snappy-debug_0.11_all.snap
<kyrofa> Thanks sergiusens
<elopio> sergiusens: kyrofa: network-listener works for shout on all snaps. Not for rolling edge, same error finding binaries.
<elopio> I'll make a branch to add the caps.
<sergiusens> elopio, don't worry about the s-i version of rolling
<sergiusens> it has no new images being created
<sergiusens> kyrofa, what if I just add the roscore part/plugin into facedetector ?
<kyrofa> sergiusens, that won't get you anything
<kyrofa> sergiusens, catkin has the same replacement logic
<kyrofa> sergiusens, I'm building this now
<sergiusens> kyrofa, I just don't understand how one works and the other doesn't
<kyrofa> sergiusens, huh... yeah I can duplicate. What on earth
<kyrofa> sergiusens, investigating now
<bellyfeel> if I made changes to files in the /etc directory would the changes persist after a core kernel update?
<kyrofa> sergiusens, how do my tests pass!?
<bellyfeel> the snappy /etc directory, not the snaps
<sergiusens> kyrofa, the face thing fails, the talker listener works just fine
<sergiusens> bellyfeel, all writable locations should persist, yes
<bellyfeel>  sergiusens, thanks!
<elopio> sergiusens or kyrofa: https://github.com/ubuntu-core/snapcraft/pull/235
<sergiusens> elopio, you are missing gopasted
<kyrofa> sergiusens, I know what it is
<kyrofa> Your stage-packages change
<kyrofa> It's overwriting my customized files
<kyrofa> With the ones from the .debs
<sergiusens> elopio, and tomcat-maven-webapp
<sergiusens> kyrofa, oh, that sucks; but they are migrated twice though
<sergiusens> kyrofa, but you are indeed right
<kyrofa> sergiusens, yeah the replacement happens in parts/
<sergiusens> kyrofa, that's fine
<elopio> sergiusens: tomcat-maven-webapp works with network-client and network-service: https://github.com/ubuntu-core/snapcraft/pull/228/files
<sergiusens> elopio, oh, then ignore me
<elopio> sergiusens: should I replace those two with network-listener?
<kyrofa> sergiusens, but then in stage/ they're definitely from the .debs. I'm not sure what the fix is, though
<sergiusens> kyrofa, maybe shebangs should be taken care of in repo.py
<kyrofa> sergiusens, hmm, yeah maybe that's the best way
<kyrofa> sergiusens, but I'm not sure how comfortable I am with .debs clobbering my files, you know?
<kyrofa> Can't they be staged the other way around?
<kyrofa> Debs then built stuff so I can clobber IT?
<sergiusens> kyrofa, can we hangout? I don't follow
<kyrofa> sergiusens, sure :)
<kyrofa> Let me use the restroom real quick, then standup room
<elopio> kyrofa: sergiusens: I'm left with this one in gopaste: http://pastebin.ubuntu.com/14507643/
<elopio> clues?
<kyrofa> elopio, why would it be using fchown?
<jdstrand> beuno: is there a plan to handle the existing ar format snaps that targeted rolling now that all snaps images can't install them (but they show up in search)?
<elopio> kyrofa: I don't know.
<kyrofa> sergiusens, you're right, that works
<kyrofa> sergiusens, I also noticed no time difference
<kyrofa> sergiusens, want me to propose?
<elopio> jdstrand: do you know anything about http://pastebin.ubuntu.com/14507643/ ?
<jdstrand> sergiusens: fyi, the snap tests fine. there are other bugs in it related to all snaps but I'll fix those after I have an apt-gettable snapcraft
<jdstrand> elopio: I sure do
<jdstrand> elopio: you can't use the chown family of syscalls because of two things: we don't have per-app uids so the chown doesn't make sense under most cases, and for those cases that do make sense, we need syscall argument filtering
<jdstrand> put more simply, do what it suggested and adjust to not use chown
<jdstrand> the hope is we'll have argument filtering for seccomp and can loosen that up a bit
<jdstrand> for 16.04
<sergiusens> kyrofa, sure
<elopio> hum, the chown seems to come from here: https://raw.githubusercontent.com/mattn/go-sqlite3/master/code/sqlite3-binding.c
<sergiusens> elopio, sqlite is not going to work without patching
<sergiusens> kyrofa, this is my lame paste fwiw http://paste.ubuntu.com/14507965/
<sergiusens> elopio, that is a known issue we have with gopasted sadly
<elopio> sergiusens: so, release without gopaste working?
<jdstrand> sergiusens: ok, I uploaded 0.11 to rolling/edge which successfully keeps it out of stable, but 16.04 can't seem to find it
<sergiusens> elopio, it has never ever ever worked
<sergiusens> jdstrand, snappy install snappy-debug/edge iirc
<jdstrand> yes, that's it
<elopio> ok, so this is ready: https://github.com/ubuntu-core/snapcraft/pull/235
<sergiusens> \o/
<sergiusens> elopio, oh, for gopasted we can use the security-override and add fchown to the valid syscalls
<sergiusens> elopio, in case you want to try https://github.com/ubuntu-core/snappy/blob/master/docs/security.md
<jdstrand> one could do that, but that will block autoapprovals in the store
<sergiusens> jdstrand, but it does enhance our examples knowledge base :-)
<jdstrand> sergiusens: which examples? how to get your app require a human review? :P
<sergiusens> jdstrand, exactly :-P
<jdstrand> hehe
<kyrofa> sergiusens, elopio https://github.com/ubuntu-core/snapcraft/pull/236 . Prepare yourself. Don't be overwhelmed
<jdstrand> kyrofa, elopio: fyi, on an allsnaps image: 'sudo snappy install snappy-debug/edge'
<jdstrand> sergiusens: thanks for your help with that ^
<sergiusens> kyrofa, fwiw http://paste.ubuntu.com/14508130/
<sergiusens> kyrofa, progress, but not there yet
<kyrofa> sergiusens, nooo
<kyrofa> sergiusens, that's in /usr/bin
<kyrofa> sergiusens, from the .deb
<kyrofa> sergiusens, maybe repo really should do the shebang
<elopio> https://github.com/ubuntu-core/snapcraft/pull/237
<elopio> it works.
<sergiusens> elopio, there's an existing open bug for gopasted in case you want to link it
<sergiusens> kyrofa, oh, goodie
<elopio> sergiusens: I saw one, but I'm not too sure it's the same one.
<elopio> I'll check.
<sergiusens> elopio, it just says it doesn't work ;-)
<sergiusens> kyrofa, how do we tackle this then?
<sergiusens> kyrofa, what file is it specifically?
<kyrofa> sergiusens,  snap/usr/bin/rosversion
<kyrofa> sergiusens, I guess we should extract the search_and_replace method into a more general place
<sergiusens> kyrofa, into repo.py :-)
<elopio> I need food. And help with gbp that only says:
<elopio> gbp:error: Version 0.6 not found
<elopio> bbs
<kyrofa> sergiusens, well it still needs to be used by the catkin plugin though. Does repo.search_and_replace() make sense in that use case?
<sergiusens> kyrofa, common, where we dump all the things with no home
<sergiusens> kyrofa, do you want to tackle it or should I?
<kyrofa> sergiusens, alright. If it's on your critical path (which it seems it is) please feel free, I'm neck deep in mysql at the moment
<sergiusens> kyrofa, will do
<kyrofa> sergiusens, but I'd be happy to check it out a bit later
<kyrofa> sergiusens, alright
<sergiusens> kyrofa, I don't think it's that (I layman fixed it fwiw) http://paste.ubuntu.com/14509383/
<kyrofa> sergiusens, that still looks the same... ?
<sergiusens> kyrofa, yeah, but shebang is correct. My guess is it is missing a PATH
<kyrofa> sergiusens, I thought the wrappers added usr/bin to the path
<sergiusens> kyrofa, yeah, scratch that, just saw it was in usr/bin
<sergiusens> elopio, does this need rebasing https://github.com/ubuntu-core/snapcraft/pull/237 ?
<sergiusens> kyrofa, so happy to see this Jan 15 20:48:50 localhost.localdomain ubuntu-core-launcher[5196]: [ERROR] [1452890930.938570301]: Webcam: expected picture but didn't get it...
<sergiusens> :-)
<kyrofa> sergiusens, hey! Progress
<kyrofa> sergiusens, do you see all sort of jpeg decoding errors?
<sergiusens> yeah, now to fix the sys devices perms
<sergiusens> kyrofa, not yet, just a repetition of that
<kyrofa> sys devices perms?
<kyrofa> sergiusens, you mean the camera permissions?
<kyrofa> sergiusens, or is this unrelated?
<sergiusens> kyrofa, http://paste.ubuntu.com/14510342/
<sergiusens> yeah
<kyrofa> sergiusens, oh yeah, that's probably necessary, no?
<sergiusens> jdstrand, what's the best path to solve ^
<sergiusens> the paste
<kyrofa> sergiusens, not sue why it's trying to access mounts though
<elopio> sergiusens: kyrofa: are we still planning to release today?
<elopio> can I help you somehow?
<sergiusens> kyrofa, me neither, hopefully harmless
<kyrofa> sergiusens, indeed
<sergiusens> elopio, I think I'll just keep polishing and go for a weekend release
<sergiusens> elopio, just reviews
<elopio> sergiusens: ack. I will be close during the weekend, so ping me on telegram if you need a hand.
<kyrofa> sergiusens, regarding the link stuff... I see those File exists: errors as well but I don't understand what's causing them
<kyrofa> sergiusens, which file exists? :P
<sergiusens> kyrofa, it's the symlink issue
<sergiusens> kyrofa, just copy what I did :-P
<kyrofa> sergiusens, ohh, because os.remove follows a symlink?
<jdstrand> sergiusens: are those denials fatal? we purposefully deny the mounts access cause it is an information leak (I've seen this as harmless in the past)
<jdstrand> sergiusens: the other one I don't think can be solved with hwassign, but the new capabilities work should address that (that is part of why we are doing it)
<jdstrand> it may also be a harmless denial
<kyrofa> sergiusens, try adding them to the profile manually. Does it fix things?
<sergiusens> jdstrand, the devices ones, those can be solved with a read-path, right?
<sergiusens> kyrofa, I am; so close and yet so far :-P
<sergiusens> since it's friday of course
<kyrofa> sergiusens, no kidding
<jdstrand> sergiusens: both of those denials can actually
<sergiusens> kyrofa, https://github.com/ubuntu-core/snapcraft/pull/238
<sergiusens> kyrofa, I took the short path for now
<kyrofa> sergiusens, it was literally only that one file? Sheesh
<kyrofa> sergiusens, or at least usr/bin only
<sergiusens> kyrofa, that file is the only one relevant there; to be fair, in the final snap, all the other ones aren't needed (2to3 is in there)
<kyrofa> sergiusens, gotcha
<sergiusens> kyrofa, now this is weird Jan 15 21:27:40 localhost.localdomain ubuntu-core-launcher[1654]: [camera-2] process has died [pid 1704, exit code -11, cmd /snaps/face-detector.sideload/IKNWUPeRbPPf/opt/ros/indigo/lib/usb_cam/usb_cam_node __name:=camera __log:=/var/lib/snaps/face-detector.sideload/IKNWUPeRbPPf/ros/log/cced8cc4-bbce-11e5-b9c1-0090f5ccd32c/camera-2.log].
<kyrofa> sergiusens, there should be more of a log than that... no?
<sergiusens> nope
<sergiusens> nothing
<sergiusens> jdstrand, can read-paths be full dirs?
<kyrofa> sergiusens, more apparmor/seccomp denials?
<kyrofa> sergiusens, I've never seen it just collapse before
<sergiusens> kyrofa, http://paste.ubuntu.com/14511298/
<sergiusens> kyrofa, I need to stop for a bit, might continue later or early tomorrow; my head is too tired
<sergiusens> and family is requiring attention
<kyrofa> sergiusens, understood :)
<kyrofa> sergiusens, yeah those hw-assign denials might be killing it
<kyrofa> sergiusens, I didn't envision using a usb device would be this difficult. That driver must be going about it in an unusual way?
<jdstrand> sergiusens: with read-paths and write-paths, if you do /foo, that is access to a file. if you do /foo/, that is access to /foo/ and everything under it
<jdstrand> sergiusens: you can also do things like /sys/**/devices/
<jdstrand> which matches /sys/foo/devices/ and /sys/foo/bar/devices/
<kyrofa> jdstrand, any idea why I wouldn't be able to use run-parts from a snap?
<kyrofa> jdstrand, no denials... just a "run-parts: Operation not permitted"
<jdstrand> kyrofa: DAC?
<jdstrand> kyrofa: is the script executable, some other unix perms?
<kyrofa> jdstrand, yeah it works fine if I do it in the terminal
<kyrofa> jdstrand, but if I do it in a shell script launched with u-c-l I get that
<jdstrand> kyrofa: it could be kernel rate limiting. snappy-debug.security tries to make that better, but the kernel has some issues in that area (a reboot and try again might help)
<jdstrand> kyrofa: beyond that, an strace would likely be the way to go. scp strace to the device, then strace -f -o /tmp/trace /apps/bin/your.thing
<jdstrand> (for example)
<jdstrand> kyrofa: I have a very hard stop now though. if you see something wrong with the policy, I do read backscroll
<jdstrand> kyrofa: oh, we also have a few explicit denials in the policy. you could comment out anything that starts with 'deny ...' in the generated policy
<jdstrand> reload it and try again
<jdstrand> they are explicitly denied for a reason-- to silence noisy denials. if you suspect one is the culprit, remove 'deny' from the rule and see if that fixes it for you
<kyrofa> jdstrand, alright will do, and I understand hard stops! :)
<jdstrand> (that turns it into an allow)
<kyrofa> jdstrand, thanks for your help
<jdstrand> np
<jerryG> Chipaca, ping
#snappy 2016-01-16
<zyga> good morning
<vmalep> Hi! I just installed Ubuntu Snappy on my miniSD for the Raspberry Pi2
<vmalep> But when booting the device, after the first kernel messages, the screen switches off and I have no way to interact with the system (neither through the network...)
<vmalep> Any suggestion how to solve the problem?
<vmalep> I followed those instructions: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<vmalep> Hi! I just installed Ubuntu Snappy on my miniSD for the Raspberry Pi2 [12:14] <vmalep> But when booting the device, after the first kernel messages, the screen switches off and I have no way to interact with the system (neither through the network...) [12:14] <vmalep> Any suggestion how to solve the problem? [12:17] <vmalep> I followed those instructions: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
#snappy 2016-01-17
<ubuntu_geek> hello
<ubuntu_geek> is this channel for ubuntu core?
<ubuntu_geek> is this channel for ubuntu core?
<ubuntu_geek> how to install all basic packages in ubuntu core?
#snappy 2017-01-09
<Terces> no idea if I'm right here, but I am trying to install ubuntu core on my raspberrypi 3 and am having problems
<Terces> I go through all the configuration screens, and at the end it tells me I can login through ssh, but it doesn't accept my password
<Terces> I've gone through the steps several times so far and always the same problem.
<mup> PR snapcraft#1030 closed: tests: fix broken delta upload unit test <Created by shawn111> <Closed by shawn111> <https://github.com/snapcore/snapcraft/pull/1030>
<mup> PR snapd#2574 closed: interfaces/docker-support: allow /run/shm/aufs.xeno for 14.04 (LP: #1654590) <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2574>
<mahendrunitin> Hi all... can anybody point to the file which has the function that verifies the signature of a snap downloaded from the store ?
<mahendrunitin> like when i say snap install <>
<mahendrunitin> snapd must download the snap from the store and verify the signature before installing it.
<mup> Bug #1639646 changed: Unable to login for first time <Snappy:Expired> <https://launchpad.net/bugs/1639646>
<mup> PR snapd#2563 closed: cmd/snap-confine: small tweaks to seccomp support code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2563>
<mup> PR snapd#2564 closed: cmd/snap-confine: build non-installed libsnap-confine-private.a <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2564>
<mup> PR snapd#2575 opened: cmd: move snap-discard-ns to dedicated directory <Created by zyga> <https://github.com/snapcore/snapd/pull/2575>
<mup> Issue snapd#2576 opened: snap-confine cannot be setuid root on openSUSE <Created by zyga> <https://github.com/snapcore/snapd/issue/2576>
<mup> PR snapd#2577 opened: tests: improve cleanup for c-unit-tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2577>
<mup> PR snapd#2577 closed: tests: improve cleanup for c-unit-tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2577>
<mup> Issue snapd#2578 opened: race condition when executing interfaceManagerSuite.TestConnectTaskCheckAllowed <Created by zyga> <https://github.com/snapcore/snapd/issue/2578>
<melvster> hi all in the tour it says to type 'snap info'
<melvster> but that gives me
<melvster> error: unknown command "info", see "snap --help"
<melvster> snapcraft v 2.24
<melvster> any ideas if snap info still works?
<mup> PR snapd#2579 opened: many: auto-connect plugs and slots symmetrically <Created by zyga> <https://github.com/snapcore/snapd/pull/2579>
<mup> PR snapd#2560 closed: snap: fix missing sizes in `snap info <remote-snap>` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2560>
<mup> PR snapd#2580 opened: cmd/snap: fix internal naming in snap connect <Created by zyga> <https://github.com/snapcore/snapd/pull/2580>
<mup> PR snapd#2581 opened: debian: remove trusty specific bits <Created by mvo5> <https://github.com/snapcore/snapd/pull/2581>
<mup> PR snapd#2582 opened: tests: restore the missing initialization of iface manager causing race <Created by stolowski> <https://github.com/snapcore/snapd/pull/2582>
<longsleep> Hi folks, i need to somwhere store the mac address on first boot of a snappy device. In classic ubuntu i have systemd service writing to uEnv.txt. With snappy now it would be awesonme if there would be an easy way to add a setting to uboot.env from the prepare-device hook. Anyone has a suggestion?
<longsleep> zyga: Btw i still cannot run any command from a snap because of bind-mount permission denied on current edge. What is the state of the apparmor change you proposed in december to snap-confine?
<mup> PR snapd#2583 opened: debian: merge feature/clean-rules-14.04 changes back to 14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2583>
<mup> PR snapd#2584 opened: snap: use "size" as the json tag in snap.ChannelSnapInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2584>
<ogra_> longsleep, hmm, why do you need to store it ?
<ogra_> (no way to get it from ROM ?)
<longsleep> ogra_: the Kernel usually generates the mac address by md5(serial), but the serial on this particular kernel is always 0, thus i disabled it and always randomize it if a mac address was not passed by kernel commandline
<ogra_> hmm, and you have no way to set a persistent serial ?
<ogra_> we do something similar on the dragonboard
<ogra_>           mkdir -p $(DESTDIR)/firmware/wlan; \
<ogra_>           ln -s /run/macaddr0 $(DESTDIR)/firmware/wlan/; \
<longsleep> ogra_: yeah, sure i could change the kernel to use the serial number from cmdline, but i did what was easiest :)
<ogra_> thats from the dragonboard kernel snap
<longsleep> ogra_: when is that run?
<ogra_> at kernel snap build time
<ogra_> (there are other bits i'm just looking up, one sec)
<zyga> longsleep: hmm, can you please refresh my memory
<ogra_> longsleep, http://paste.ubuntu.com/23769615/ is the matching initrd bit that reads the serial and turns it into a mac
<longsleep> zyga: sure, you had some branch on github for snap-confine chaning something how apparmor is used
<zyga> longsleep: and refer to a bug if you can
<ogra_> longsleep, indeed that only works if your firmware can use /lib/firmware/wlan
<zyga> longsleep: I have plenty of such branches, do you remember the specific one?
<longsleep> zyga: sure, i have this problem http://paste.ubuntu.com/23769518/ and you had me try a branch on github snap-confine, the branch is gone due to the snapd merge - let me see if i can find the link
<longsleep> ogra_: yeah, also the mac address is for ethernet, not for wlan
<zyga> longsleep: hmmm, that's odd
<zyga> longsleep: which version are you on?
<longsleep> zyga: the bug i added then is https://bugs.launchpad.net/snap-confine/+bug/1645457
<mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
<zyga> ah
<zyga> on 3.10 you say
<zyga> longsleep: thanks, I'll check what I can do
<zyga> longsleep: I think it may require 3.10 specific code
<longsleep> zyga: yeah but i got the aa backported, lxd and stuff works
<zyga> okay
<zyga> hmmm
<zyga> is that the m10?
<longsleep> zyga: it was this branch https://github.com/snapcore/snap-confine/tree/use-aa-support
<longsleep> zyga: m10?
<ogra_> heh
<zyga> longsleep: m10 tablet
<longsleep> zyga: nah, Pine64
<zyga> longsleep: ok
<ogra_> zyga, m10 is my domain ;)
<ogra_> (starting with the image this week)
<longsleep> zyga: you had my try the use-aa-support branch which worked, but branch is gone now
<longsleep> s/my/me
<zyga> longsleep: that branch was merged
<zyga> longsleep: which version of snapd are you using?
<longsleep> zyga: root@localhost:~# snap version
<longsleep> snap    2.20
<longsleep> snapd   2.20
<longsleep> series  16
<zyga> longsleep: ok, let me investigate
<longsleep> i build a new image yesterday from edge channel
<longsleep> zyga, ogra_ so the snap-confine issue and the non-persisting ethernet mac are the only two issues - if those are fixed i finally can try to publish pine64 gadget and kernel snap
<ogra_> longsleep, i see you mention uEnv.txt above, you are aware that we dropped support for that quite a while ago ?
<ogra_> snapd expects uboot.env
<longsleep> ogra_: sure, i not use it on snappy
<ogra_> ah, k
<ogra_> (just wanted to make sure)
<longsleep> ogra_: thats what i asked if there is a way to add additional stuff to uboot.env in some hook
<longsleep> ogra_: of course i could make it load both, but i would rather avoid that
<ogra_> you can add a systemd unit in the gadget ;)
<ogra_> calling fw_setenv to set a variable in uboot.env
<longsleep> ogra_: yeah - something like that - i would prefer it to run it in tge perpare-device hook though
<longsleep> ogra_: that hook is run on the device on first boot right?
<ogra_> i think so ... though thats kind of mvo land
<longsleep> ogra_: do you know if fw_setenv is atomic? What happens on powerof while it writes?
<ogra_> hmm, not sure ... it is designed for mtd devices and just toggles bytes ... moght not be atomic at all since it directly writes on the low level
<ogra_> *might
<zyga> longsleep: where do you plan to publish the gadget?
<longsleep> ogra_: in any case the file is writting on vfat - so whenever this file changes it might become broken i would guess
<ogra_> longsleep, but i think uboot.env itself is handled atomic
<longsleep> zyga: the gadget snap you mean? Ubuntu store - where else would i publish it?
<mvo> longsleep: iirc I looked at this and its writing in place
<ogra_> due to the "CONFIG_REDUNDANT_ENVIRONMENT" option
<zyga> longsleep: and the source?
<longsleep> zyga: well i have it all in my building gear at https://github.com/longsleep/build-pine64-image/tree/master/snappy
<zyga> longsleep: did you consider splitting those so that the gadget is separate
<longsleep> mvo: mhm yeah - which is bad - but i guess you so far did not have issues people turning off their devices while that file gets written
<zyga> longsleep: e.g. look at https://github.com/snapcore/pi3-gadget
<ogra_> longsleep, well, no file gets written ... the window in which changes happen is very small since fw_setenv only toggles the byxtes directly
<longsleep> zyga: no - it needs binary blobs from the general repository - i would have to copy those then too
<zyga> longsleep: so blobs need to be in two places?
<ogra_> longsleep, due to the uboot.env setup the filesystem isnt involved at all
<zyga> longsleep: (same blobs?)
<longsleep> zyga: if they are two repos yes
<zyga> longsleep: which blobs are that?
<longsleep> zyga: i need those blobs to build classic images as well
<longsleep> zyga: boot0 and bl31
<longsleep> zyga: also u-boot needs to be built first
<longsleep> zyga: with the building gear in the larger repository
<zyga> longsleep: too bad, it would be great if we could build a hub (on github) with community gadgets and kernels
<longsleep> zyga: all the blobs are in https://github.com/longsleep/build-pine64-image/tree/master/blobs
<ogra_> longsleep, the worst thing that can happen to you is that the variable holding the mac will contain garbage
<ogra_> the env file should stay readable and rthe device should stay bootable
<longsleep> ogra_: really? so it appends bytes only?
<ogra_> it toggles them
<ogra_> the file size never changes
<longsleep> ogra_: ah sure
<longsleep> ogra_: i remember now
<longsleep> ogra_: the size is fixed - thanks for remembering me
<ogra_> so on that side you should eb safe
<ogra_> *be
<ogra_> and for the firstboot job... as i said, mvo should be able to help
<longsleep> zyga: yeah - i am not sure about how feasible that is as the gadget and kernel snaps usually require extra stuff like bootloaders and device trees
<zyga> longsleep: two ways of doing that: building everything in the repo or commiting binaries into the repo and just using snapcraft to pull it from other places
<zyga> longsleep: you can build many things in the gadget snap
<longsleep> zyga: but i agree that a central place to find stuff would be great, but i think the store would be better suited and have meta data to point to the source repo
<ogra_> longsleep, our gadgets moved to https://github.com/snapcore/ and are fully built by snapcraft now
<ogra_> you can easily add a makefile part to build your upstream uboot
<zyga> longsleep: yeah but github org to hold this would look nice even if store supports this
<longsleep> zyga: yes
<ogra_> zyga, i think we need an example gadget that builds from upstream uboot trees ...
<longsleep> ogra_: why only the gadget snaps? what about kernel snaps?
 * ogra_ adds to TODO
<zyga> longsleep: I poked the kernel team about this
<zyga> longsleep: they were supposed to evaluate this
<zyga> longsleep: I didn't hear back yet
<ogra_> longsleep, the kernel snaps are maintained by the kernel team now
<ogra_> longsleep, and they have their own workflow not using github
<zyga> longsleep: I'd love the kernel team to take this decision and help them along the way
<longsleep> ogra_: right, thats possible for things which actually have a sane kernel
<zyga> ogra_: (just keeping a mirror on github would be 100% better though)
<ogra_> since they have a centra git server since forever where akll their trees live
<ogra_> zyga, sure
<ogra_> zyga, but dont forget that the official kernel snaps are always built from debs, so that wont help external users much
<zyga> ogra_: sure, but it would help in visibility
<zyga> ogra_: and unofficial snaps won't be this way
<ogra_> indeed
<zyga> ogra_: I bet more and more people will use sources to build the kernel
<zyga> ogra_: and those examples will be valuable
<ogra_> i hope all external people will ;)
<ogra_> the use of debs is really a special case
<zyga> indeed
<longsleep> zyga: to build everything with snapcraft, it would need to build atf (bl31) from a git tree, u-boot from a git tree, some tools, then combine u-boot a device tree and bl31, and then use blob boot0 and the resulting combined u-boot-with-dtb-and-atf binary
<zyga> longsleep: you still build those, right?
<ogra_> longsleep, well, you can start with a tree with prebuilt binaries
<ogra_> and then piece by piece add parts that build the stuff
<zyga> yes, exactly!
<longsleep> zyga, ogra_: the rest of my classic ubuntu build gear builds those
<ogra_> longsleep, https://github.com/snapcore/pi3-gadget
<ogra_> thats what we do here
<longsleep> ogra_: ah ok, prebuilt folder
<ogra_> right
<longsleep> ogra_: sure i can do that
<ogra_> over time this will go away
<zyga> longsleep: start prebuilt, over time you can use launchpad to build your snap
<zyga> longsleep: and this lets people report bugs nicely
<zyga> longsleep: repo == bugs
<longsleep> zyga: yeah sure i think about it once things start working :)
<zyga> woot, great :)
<longsleep> mvo: Quick question, the prepare-device hook of the gadget snap is run on first boot on the device?
<longsleep> zyga: so any clue about the apparmor issue?
<zyga> longsleep: not yet
<longsleep> zyga: just fyi - i compared kernel patches for aa to the ones from roseapple pi and they seem to be the same, not sure if they copied from me or something though :)
<zyga> longsleep: maybe from the ref 3.10 kernel with ubuntu aa?
<mvo> longsleep: yes, pedronis implemented the prepare-device hook and its used in production
<longsleep> zyga: yeah - maybe - so i think the same issue shold be on roseapple pi as well - if not then something else is a miss on my kernel tree
<ogra_> i think ondra worked on that one, he might know
<mup> PR snapd#2585 opened: debian: move systemd files out of ./debian and into ./data/systemd <Created by mvo5> <https://github.com/snapcore/snapd/pull/2585>
<longsleep> This reminds me, i still cannot register a key with snapcraft: Key registration failed: The account-key-request assertion is not valid.
<mup> PR snapd#2582 closed: tests: restore the missing initialization of iface manager causing race <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2582>
<mardy> kyrofa: when running snapcraft from master on a project of mine, I key a KeyError on build-attributes
<mardy> kyrofa: is this a known bug?
<mup> PR snapd#2586 opened: daemon: make 201 and 202 responses have a Location header as per doc <Created by chipaca> <https://github.com/snapcore/snapd/pull/2586>
<shuduo> ppisati: hi
<mup> PR snapcraft#1034 closed: rust plugin: respect fetch parameters <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1034>
<mardy> kyrofa: pls ignore my message above, the error was mine (launching snapcraft/main.py instead of the bin/snapcraft wrapper)
<mup> Issue snapd#2578 closed: race condition when executing interfaceManagerSuite.TestConnectTaskCheckAllowed <Created by zyga> <Closed by stolowski> <https://github.com/snapcore/snapd/issue/2578>
<longsleep> ogra_: to build the gadget snap with snapcraft.yaml i need hook support which has been merged 4 days ago .. is there a ppa for snapcraft where i can get that / nightly builds or something?
<ogra_> longsleep, i think sergiusens has one, yes
<ogra_> (now dont ask me where :P)
<longsleep> ogra_: mhm the one i found has not seen updates since a while
<ogra_> well, wait for sergiusens, if there is one he will know where
<ogra_> but its python, i bet you could just branch it from github and run ./snapcraft or some such
<mup> PR snapd#2584 closed: snap: use "size" as the json tag in snap.ChannelSnapInfo <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2584>
<jdstrand> roadmr: hi! one more small commit to support the new 'daemon: notify': can you pull r816?
<roadmr> jdstrand: sure! btw we haven't really deployed the laste few changes :/ sorry about that, we should have a deployment this week I reckon
<roadmr> (but hey, they look great on staging ;)
<jdstrand> hehe
<jdstrand> thanks!
<popey> sergiusens: I'm building a python app snap, but it needs a parameter after "python3 setup.py ", I don't think we support that (yet?). Any plan to? Should I file a bug?
<mup> PR snapd#2587 opened: interfaces/mount: add snippet types <Created by zyga> <https://github.com/snapcore/snapd/pull/2587>
<mup> PR snapd#2580 closed: cmd/snap: fix internal naming in snap connect <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2580>
<mup> PR snapd#2588 opened: cmd/snap: add shell completion to connect <Created by zyga> <https://github.com/snapcore/snapd/pull/2588>
<zyga> Son_Goku: hey
<Son_Goku> zyga: hi
<zyga> Son_Goku: I put together a wiki page that describes distro status
<zyga> Son_Goku: and file a few more bugs describing where we are on blockers
<Son_Goku> oh?
<zyga> Son_Goku: I replied to the thread you just replied to
<Son_Goku> I'm guessing you saw my reply to the email
<Son_Goku> have you? I don't see it...
<zyga> yes, though i worked on the wiki for a few days now
<Son_Goku> ah, apparently it's not in the ML yet
<zyga> Son_Goku: https://github.com/snapcore/snapd/wiki/Distributions
<zyga> Son_Goku: can you check if the status describing fedora is accurate?
<Son_Goku> for CentOS, it's "EPEL7"
<zyga> ah, can you correct that
<zyga> sorry, I always get that wrong :)
<Son_Goku> fixed
<zyga> thanks :)
<mup> PR snapd#2589 opened: tests: test for auto-aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2589>
<Son_Goku> playing whack-a-mole with snapd is exhausting though
<Son_Goku> zyga: oh, and openSUSE supports both apparmor and selinux
<Son_Goku> apparmor is just the default there
<Son_Goku> there's also go bindings to libselinux, I think
 * ogra_ recommends a whack-a-mole script 
<Son_Goku> you would :P
<ogra_> :)
<zyga> Son_Goku: that field describes what is available in snapd, not the distro
<Son_Goku> ah
<Son_Goku> well, you have "dependencies" listed
<Son_Goku> oh, you already pulled in libselinux go bindings into snapd?
<Son_Goku> anyway, bbs, have to go to work
<kyrofa> elopio, are we still publishing daily builds of snapcraft to a PPA?
<mup> PR snapcraft#1040 opened: [WIP] Run the rust test in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1040>
<jdstrand> zyga: hey, looking at https://github.com/snapcore/snapd/wiki/Distributions you list Elementary in 'Linux Distributions' but not under 'Support Matrix'. I'm not sure if 'Support Matrix' is supposed to have everything, but if not, 'Support Matrix' should probably say 'Ubuntu 16.04 LTS and Ubuntu derivatives' (or something)
<jdstrand> zyga: also, bug #1653487 is addressed (seccomp) for 14.04
<mup> Bug #1653487: seccomp argument filtering not working on trusty amd64 <verification-done> <libseccomp (Ubuntu):Fix Released> <libseccomp (Ubuntu Trusty):Fix Committed by jdstrand> <https://launchpad.net/bugs/1653487>
<jdstrand> I'll update the wiki for that seccomp
<longsleep> kyrofa: i am looking for daily snapcraft builds too, did you find them?
<kyrofa> longsleep, heh, I was asking for you
<kyrofa> But he must not be in just yet
<kyrofa> longsleep, have you tried running snapcraft from source, as ogra_ suggested?
<longsleep> kyrofa: no - i have not - thats a bit too cutting edge and i would rather wait before merging my pr to build the gadget snap with snapcraft until there is a package available
<longsleep> kyrofa: in the past i was using https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily - but that is not updated since a while
<kyrofa> longsleep, fair enough. I'll continue to look into why that's no longer updated
<longsleep> kyrofa: nice thanks!
<longsleep> kyrofa: any chance you know something about snapcraft key registration too? i have an issue there and i cannot register any key with my account
<kyrofa> longsleep, maybe, what's happening?
<longsleep> kyrofa: take a look here: http://paste.ubuntu.com/23770867/
<longsleep> kyrofa: i looked a bit at the data, and seems that the remote API returns this error message - so i figured there might be a problem with my account or something
<kyrofa> longsleep, huh, yeah no kidding. cprov, any idea what "Key registration failed: The account-key-request assertion is not valid" might imply?
<zyga> jdstrand: hey
<zyga> jdstrand: it's not supposet do have everything (as it says just above the table); I like the derivatives idea, I'll try to do something like that
<zyga> jdstrand: oh, nice, does it mean 14.04 is good now?
<zyga> jdstrand: thanks!
<zyga> jdstrand: btw, long time no see
<zyga> jdstrand: I was busy with some other things but this and next week my focus is to complete mount namespace mutation for existing mount namespaces
<zyga> jdstrand: so connect/disconnect will go and change what is there in practice without restarting apps
<zyga> jdstrand: I've started some work towards that, if you want I can sync with you on this
<jdstrand> zyga: you'd have to talk to tvoss for the most up to date info, but aiui, installing snapd on 14.04 desktop is fixed in ppa (and likely moving to trusty-proposed), but there remains a cgmanager issue (ie, if it is installed, systemd (and therefore snapd) fails to start
<jdstrand> zyga: at some point a sync would be good, but I'm still trying to clear my plate to help you with snap-confine testsuite
<zyga> jdstrand: I see, I'll wait until it is out of proposed
<tvoss> zyga: let me know if you need anything specifically
<zyga> jdstrand: thanks!, after your earlier suggestion only i386 is failing
<jdstrand> cool
<zyga> jdstrand: I'll try to fix the remaining issue, I think it is well undertood now :)
<zyga> tvoss: monitor the issue and update the wiki once it is green :)
<tvoss> zyga: works for me
<jdstrand> zyga: oh, you don't need me to help for i386? ok, then I'll not plan on looking at it unless you come back
<zyga> jdstrand: so far no, I just need a second to tweak one more thing and it should land
<zyga> jdstrand: I will come around to it in a few hours today
 * zyga documents live modificationto mount namespaces now
<kyrofa> davidcalle, you around?
<mup> Bug #1655060 opened: snapcraft doesn't support the dbus daemon type <Snapcraft:New> <Snappy:New> <https://launchpad.net/bugs/1655060>
<zyga> jdstrand: my initial idea on how to implement modification of the mount namespace: https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces
<mup> PR snapd#2550 closed: interface hooks: connect plug slot hooks (step 2) <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2550>
<mup> PR snapcraft#1041 opened: Document `notify` daemon type <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1041>
<jdstrand> zyga: ok, thanks
<jdstrand> tvoss: fyi, I merged the docker aufs change last night
<elopio> nessita or ev: could you please allow Matthew from matrix to use the synapse snap name?
<zyga> jdstrand: what does that bring?
<zyga> jdstrand: I'm not sure I recall
<nessita> elopio, checking!
<nessita> elopio, did he fill name request/dispute?
<elopio> nessita: he said: i mailed ubuntu-folks for guidance on killing off the previous snap, or getting control of it so i could replace it with the proper one
<elopio> I'm not sure if it was through the form. Should I tell him to fill it?
<nessita> elopio, the only snap I see is matrix-synapse owned by kyrofa
<nessita> well, name, not snap yet
<elopio> nessita: I think it was reserved because there is a deb binary called synapse
<nessita> elopio, then can you please ask him to file a name dispute?
<elopio> yes, I'm trying
<nessita> thanks!
<lazyPower> When i declare a bin as a daemon, is snappy creating an intermediary systemd unit file on my snaps behalf?
<ogra_> yes
<lazyPower> ah found it in /etc/systemd/system, thanks
<lazyPower> say i'm using a snap in a juju charm, I suppose I just stuff the generated config bits I need the snap to read from in /var/snap/$snap/common and inform the systemd service it needs to restart?
<jdstrand> zyga: what does what bring? the docker fix? it was a trivial policy update to the docker-support interface since trusty mounts shm on /run instead of /dev
<zyga> jdstrand: ah, I see
<tvoss> thx for the update
<BrownMit> Good afternoon folks, I have a kind of weird situation with snap on a couple of my Ubuntu servers.  Google has not been helpful so I'm hoping someone here can help me out.  On most of my ubuntu servers (16.04.1) I have no issues with snap.  However, on two servers, it works but I can only seem to find a subset of the available applications.  For example, "snap find vlc" reports error: no snaps found for vlc
<ogra_> BrownMit, "snap version" would be interesting ... and "snap list|grep core" ...
<BrownMit> ~> snap version
<BrownMit> snap    2.20.1ubuntu1
<BrownMit> snapd   2.20.1ubuntu1
<BrownMit> series  16
<BrownMit> ubuntu  16.04
<ogra_> the same on all servers ?
<BrownMit> ~> snap list|grep core
<BrownMit> core  16.04.1  712  canonical  -
<ogra_> same question ...
<BrownMit> yes to snap version
<BrownMit> on one server snap cdore is at rev 714
<ogra_> thats a different arch i guess
<BrownMit> ahhhhhh
<ogra_> i think vlc is only available on amd64 â¦ so that might explain why you dont find it there
<BrownMit> and that would be it
<ogra_> :
<ogra_> :)
<BrownMit> yup, those are my only 32 bit implementations
<BrownMit> thank you!!!
<ogra_> np :)
<mup> PR snapd#2589 closed: tests: test for auto-aliases <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2589>
<anewman> Hi all. I'm looking to build a snap that has a user-extensible plugin interface with no build process (so perl scripts for plugins). Is there a good snap in existence I can use as a model for this?
<anewman> In short, should plugins end up in data or should they be separate snaps?
<kyrofa> mhall119, I seem to remember you having similar experience with geany and its plugins
<mhall119> kyrofa: I did! anewman I have an example that might help you, let me get a link
<anewman> Thanks!
<mhall119> anewman: so here's the snapcraft.yaml for the app (geany): https://github.com/ubuntu/snappy-playpen/blob/geany/geany/snapcraft.yaml
<mhall119> it will use a local directory called "plugins" to be the mount-point for the sharing
<mhall119> so /snap/geany/current/plugins
<mhall119> upstream geany provides the plugins all from one project, so I was able to built a single geany-plugins snap that has them all
<mhall119> which is this: https://github.com/ubuntu/snappy-playpen/blob/geany/geany-plugins/snapcraft.yaml
<anewman> alright, that makes sense to me.
<mhall119> so in the first I define a "plug" using the content interface, with the target of ${SNAP}/plugins/
<anewman> And one assumes that a less monolithic plugin set could end up with a set of package-plugin-pluginname snaps?
<kyrofa> mhall119, how would you have done that if the plugins weren't all available in one package?
<mhall119> anewman: when I did this work, that wasn't possible, but it might be now
<anewman> Alright, interesting. Because I wouldn't want to have to whitelist the plugins in the head package.
<mhall119> kyrofa: zyga and I discussed it, and the plan was to allow snap-namespaced mount points under the target itself
<mhall119> IIRC
<kyrofa> mhall119, i.e. the plug could be connected to multiple slots?
<mhall119> kyrofa: no, the geany snap would provide one plug, that could be connected to multiple slots
<kyrofa> mhall119, haha, isn't that what I just said?
<kyrofa> mhall119, do you know of a bug that represents that?
<mhall119> I thought you meant multiple slots per snap, so slot-a, slot-b, slot-c, etc
<kyrofa> Nah, same page
 * mhall119 checks
<mhall119> kyrofa: I can't find one, I'm not sure we ever made a bug for it
<kyrofa> mhall119, alright. zyga, did that plan ever progress?
<mhall119> we discussed it in den haag
<mhall119> is zyga in cape town this week?
<kyrofa> Probably. You might consider making a bug for him, he has a lot going on
<kyrofa> mhall119, does bug #1655125 properly describe the issue?
<mup> Bug #1655125: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125>
<mup> Bug #1655125 opened: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125>
<zyga> mhall119: I'm not in cape town
<zyga> mhall119: there's ongoing work on the "overmount" interface, I'm not sure that's what you were discussing but that helps people with some bits
<kyrofa> zyga, does that cover bug #1655125?
<mup> Bug #1655125: Missing interface: content sharing in the other direction <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1655125>
<zyga> kyrofa: no
<zyga> kyrofa: this is more store side and assertion work
<zyga> kyrofa: if feels in scope but not in the list of things I'm going to focus on this week
<zyga> kyrofa: this week it is https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces
<kyrofa> zyga, ah, excellent
<mwhudson> zyga: hey, should we request removal of the snap-confine source package from debian unstable?
<mwhudson> zyga: it isn't going to get autoremoved because it built on lots of arches where snapd does not
<mwhudson> aiui
<mup> PR snapcraft#1042 opened: Add documentation for hooks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1042>
<zyga> mwhudson: hey
<zyga> mwhudson: I think this is sensible, unless mvo disagrees
<zyga> mwhudson: what does that do to snapd source package, nothing I presume?
<davidcalle> kyrofa: around now
<mup> Bug #1607748 changed: Ability to use two registered names for the same snap <lxd> <Snappy:Fix Released> <https://launchpad.net/bugs/1607748>
<mup> PR snapd#2590 opened: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2590>
<davidcalle> kyrofa: now that I've seen two examples, it's a bit more clear how to use scriptlets, now I'm mostly curious about 1) when do scriptlets run and if the install one is the only one supported atm 2) dash or bash? 3) any restrictions or notable boundaries on what can happen there? 4) where can I find the list of snapcraft specific env vars ($SNAPCRAFT_*)?
<mwhudson> zyga: yeah, no impact on anything else i think
<kyrofa> davidcalle, sure! (1) should be answered by https://github.com/snapcore/snapcraft/blob/master/snapcraft/__init__.py#L228, I think?
<kyrofa> davidcalle, (2) /bin/sh, so dash in most cases I suspect
<kyrofa> (3) no known restrictions
<kyrofa> davidcalle, (4) there's actually no list, but they're SNAPCRAFT_PROJECT_NAME, SNAPCRAFT_PROJECT_VERSION, SNAPCRAFT_STAGE, and SNAPCRAFT_PART_INSTALL
<jdstrand> diddledan: hi! fyi, https://github.com/snapcore/snapd/pull/2590 has the xdg-open fix
<mup> PR snapd#2590: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2590>
<davidcalle> kyrofa: do you know the use case for project_version?
<kyrofa> davidcalle, I assume so that you can use it in `source` URLs
<davidcalle> kyrofa: got it, thanks
<Pharaoh_Atem> zyga: why does classic mode depend specifically on /snap?
<diddledan> thanks jdstrand
#snappy 2017-01-10
<mwhudson> hm
<mwhudson> i get the classic confinement requires the core_dynamic_linker to be set message trying to build a classic confinment snap on launchpad
<mwhudson> apparently that's code for "you need the core snap installed"
<mwhudson> but how do i get the builder to install the snap?
<mup> PR snapcraft#1040 closed: Run the rust test in armhf <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1040>
<mup> PR snapcraft#1041 closed: Document `notify` daemon type <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1041>
<mup> PR snapcraft#1042 closed: Add documentation for hooks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1042>
<mup> PR snapd#2590 closed: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2590>
<mup> PR snapd#2591 opened: wrappers: add DBusActivatable to the allowed values for desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/2591>
<zyga> o/
<longsleep> Is the gadget snap actually installed on the device? I am wondering where i find the hooks or how to debug a prepare-device hook.
<zyga> longsleep: it is, but it is not updated in the same way as other snaps
<zyga> longsleep: look at /snap/$SNAP_NAME/current, as usual
<palasso> Hey there, sorry for the newbie question but by reading the docs in snapcraft.io I am confused on the types of snaps that exist
<longsleep> zyga: /snap/ is emtpy
<zyga> longsleep: empty?
<palasso> So I understand there's a focus in app and gadget snaps but there's more types being mentioned
<zyga> longsleep: that's odd
<zyga> palasso: there are kerenl snaps, gadget snaps and app snaps
<longsleep> zyga: i only see the stuff from the gadget snap in /boot/uboot
<palasso> There's a mention of kernel and OS snaps and also in the snap store I can see there's OEM and framework snaps
<zyga> palasso: and there's the one os/core snap
<zyga> palasso: framework snaps are no more, oem snap is no more
<zyga> longsleep: did the device finish booting?
<zyga> longsleep: snapd installs snaps on first boot
<palasso> alright ty zyga :)
<longsleep> zyga: yes it boots and works just fine
<longsleep> zyga: i finished the stup via serial console subiquity prompts and sshd in
<zyga> longsleep: no idea then, maybe ogra_ has some ideas?
<palasso> zyga: so the OEM and framework snaps in the store are there for archival purposes or being used from devices having old versions of snapd?
<longsleep> zyga: if i install hello-world snap  then it also first downloads the core snap which i find odd too
<longsleep> zyga: and then of course the hello-world snap does not work because of the mount aa deny
<palasso> zyga: also I'm wondering, since it seems docker was the reason for the framework snaps, is there some inherent difficulty in snapping docker as an app snap? And if it goes away is there some suggestion of having a way to use docker in an all-snap distro?
<zyga> palasso: those are 15.04 concepts, they are gone in 16.04
<zyga> longsleep: that looks like a bug
<zyga> longsleep: can you please report this
<palasso> zyga: also I'm wondering whether the proper name for the software that does the confinement is "snapd-confine" or "snap-confine"
<zyga> palasso: framework snaps had more permissions, in 16.04 permissions are based on interfaces so any snap can get additional permissions by using appropriate interface
<zyga> palasso: snapd defines confinemenet, snap-confine applies it
<palasso> Ok thank you zyga I think there's a typo in the docs because it mentions it as snapd-confine
<longsleep> zyga: sure
<longsleep> zyga: after i install hello-world, i now have bin, core and hello-world in /snap - before it was empty
<zyga> palasso: can you point me to it
<palasso> zyga: core/snapd
<longsleep> zyga: and it scheduled a reboot because it updated core?
<zyga> longsleep: sanity check, this is not a classic system, this is a core system?
<longsleep> zyga: yeah, created by ubuntu-image with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 ubuntu-image -c stable --image-size 2G --extra-snaps pine64_16.04-2_arm64.snap --extra-snaps kernel/pine64-kernel_3.10.104-2_arm64.snap -o test2.img pine64.model --debug
<longsleep> except that this boot i used edge channel
<palasso> zyga: also in the same page there seems to have been a mistake in bullet points. Read part "A store where developers can easily make their" I think it shouldn't be a sub bullet point
<zyga> palasso: sorry, can you give me a URL please?
<palasso> http://snapcraft.io/docs/core/snapd
<longsleep> zyga: where should i file that bug - https://launchpad.net/ubuntu-image sounds good?
<longsleep> zyga: i got ubuntu-image 0.12+real1
<zyga> longsleep: how did you install ubuntu-image?
<zyga> longsleep: AFAIK today it is only installable as a snap
<zyga> longsleep: I don't know how well it supports other platforms, apart from what we can build officially
<longsleep> zyga: yes installed as snap on my xenial dev system - ubuntu-image  0.12+real1  44    canonical  devmode
<mup> Bug #1655262 opened: driver doesn't support ap mode <Snappy:New> <https://launchpad.net/bugs/1655262>
<palasso> zyga: also a few more typos, not important but I happened to notice: In http://snapcraft.io/docs/core/install correction of branding: OpenSuse --> openSUSE (also notice it'll be consistent with the URL of the repo that's been specified in the command)
<palasso> zyga: and I think in http://snapcraft.io/docs/core/updates "Snapd systems employ a method of transactional update" shall have a plural for "update" thus being replaced with "updates"
<palasso> zyga: Here's a pastebin for the typos: https://paste.ubuntu.com/23775246/
<zyga> palasso: thanks!
<palasso> you're welcome :)
<palasso> btw and sorry for bugging you the old OEM snaps have been replaced functionality-wise with the kernel snaps or the OS snap or is it more complicated than that?
<zyga> palasso: I'm not sure what the OEM snaps were doing, I think it is now the (single) core snap
<palasso> I'm still in the reading process so it's not like I understand everything. I also noticed Lennart talking about Portable system services within systemd and using squashfs images (seems very similar to the snap format) https://lwn.net/Articles/706025/
<zyga> yes, it seems that this is a clone from the idea of snaps
<palasso> He said if he were to create systemd today, he would have started with portable system services being the norm but since it's been there for so long he has to keep compatibility by keeping the "native" type
<palasso> And here's the talk: https://www.youtube.com/watch?v=DUUbFGNZ1vI
<palasso> zyga: I have no idea what the OEM snaps are, I barely read in the past the old documents that weren't in the snapcraft.io domain name (those that were in the ubuntu.com domain name before the launch of snapcraft.io) but looking at the OEM snaps I think they're custom images for ARM boards.
<zyga> palasso: hey, I just realized that snapcraft.io is a github project, can you please try to fix those typos directly? https://github.com/ubuntudesign/snapcraft.io/
<zyga> palasso: I think OEM may have been just current kernel snaps
<palasso> zyga: yeah sure I'll make a PR :)
<zyga> palasso: awesome, thank you :)
<davidcalle> palasso: over here https://github.com/CanonicalLtd/snappy-docs/ :)
<palasso> davidcalle: thnx I just found it myself by looking at the code :P
<davidcalle> palasso: also, thank you
<palasso> this part helped me find it: https://github.com/ubuntudesign/snapcraft.io/blob/master/import-docs.sh
<davidcalle> palasso, zyga: OEM snaps -> Gadget snaps
 * zyga nods
<mup> PR snapd#2592 opened: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<vigo> ogra_, ping
<mup> PR snapd#2593 opened: Mount backend <Created by zyga> <https://github.com/snapcore/snapd/pull/2593>
<ogra_> vigo, yes ?
<vigo> ogra_, I'm following the steps you told me but when I try to connect to my wifi it is not listed
<vigo> I mean I can see other wlans listed but not mine :S
<ogra_> weird, works here
<ogra_> oh
<ogra_> i thought you cant see the device
<ogra_> hmm
<vigo> makes me wonder about wifi compatibility, I scan for new networks and give it time to show me a complet list
<vigo> but my network is still missing while dragonboard workd great
<ogra_> longsleep, this sounds a bit like the old rtc issues we used to have does your cmdline have fixrtc set ? the device setup doesnt work if the clock is completely off
<vigo> I'll change the wifi channel and try
<vigo> again
<ogra_> vigo, well, probably a driver bug, not sure ... i never had probs here, WPA2 and channel 12
<ogra_> (thats what my network uses)
<vigo> ogra_, it was the channel
<ogra_> ah
<vigo> I was using channel 13
<vigo> eheh
<ogra_> so the pi driver rspects regulations and the dragonboard doesnt i guess :)
<vigo> now I see my wifi printer too
<ogra_> cool
<mup> Issue snapd#2594 opened: Please add "install" hook <Created by jacekn> <https://github.com/snapcore/snapd/issue/2594>
<longsleep> ogra_: yes i have fixrtc in cmdline
<ogra_> longsleep, well, check your syslog and dmesg ... i'm sure there is an error somewhere with the firstboot setup
<longsleep> ogra_: ok, will do - preparing a new image now
<ogra_> (if it is not the clock it must be something else ... but there should be a log entry for it in any case)
<longsleep> ogra_: any chance you can point me to some docs how i can make it load an extra kernel module on boot?
<ogra_> you should eb able to ship /etc/modules in the gadget ... i know there are plans for a core config interface to set this but i'm not sure where this stands
<ogra_> beyond this, /etc/modules.d is writable so you can dump a file in there
<ogra_> er
<ogra_> nowadays it is /etc/modules-load.d
<longsleep> ogra_: ok cool will try that thanks
<vigo> ogra_, pi3 has wifi n only
<vigo> and db b/g/n
<ogra_> ah, right
<vigo> that's why 12 and 13 won't work
<vigo> so it's legal :)
<ogra_> yeah
<ogra_> thanks for researching that :)
<vigo> ogra_, np, I like it :)
<longsleep> ogra_: there are plenty of errors in syslog but nothing really obvious to me - http://paste.ubuntu.com/23775585/ has the full syslog after the first boot
<longsleep> ogra_: i guess everything related to /usr/bin/snap is relevant
<ogra_> longsleep, and dmesg output ?
<ogra_> (the bit before rsyslogd starts is interesting too)
<longsleep> ogra_: http://paste.ubuntu.com/23775592/ has the dmesg
<ogra_> long term you also want to drop "rootfstype=ext4 rootwait"
<longsleep> ogra_: sure i can easily remove those, copied some u-boot stuff from classic ubuntu
<ogra_> hmm, no failed messages there
<ogra_> do you see any systemd errors in the serial console when booting ?
<longsleep> ogra_: yeah all  systemd units report fine
<longsleep> ogra_: none
<ogra_> strange
<ogra_> Jan 10 10:34:53 localhost /usr/lib/snapd/snapd[1171]: booted.go:81: cannot get info for "pine64-kernel": cannot find snap "pine64-kernel"
<ogra_> Jan 10 10:34:53 localhost /usr/lib/snapd/snapd[1171]: booted.go:81: cannot get info for "core": cannot find snap "core"
<longsleep> yeah - those snaps are not there
<ogra_> it is definitely this ... but there should be a more descritive error above ...
<ogra_> how did you build the image ?? do you use a properly signed model assertion with a valid key ?
<longsleep> ogra_: so the question is where do those snaps go / why are they not found - i mean ubuntu-image should use/install them during imafge creation
<longsleep> ogra_: no model assertion is not signed
<ogra_> ah
<ogra_> well, thats your issue then
<longsleep> really, i thought it still would be fully functional without it except that i cannot update
<ogra_> nope
<longsleep> ogra_: i still cannot sign anything as i cannot register the key with the store
<ogra_> though ubuntu-image should still have put the snaps into /var/lib/snapd/snaps/
<ogra_> and you should eb able to find them
<longsleep> ogra_: nope, that folder is empty on the device
<longsleep> ogra_: so how do i get the "The account-key-request assertion is not valid." error fixed, so far nobody has been able to help me with that
<longsleep> i unfortunately cannot sign anything as i cannot register a key with my account :/
<ogra_> your assertion needs to be signed
<ogra_> i dont think there is a way around ...
<ogra_> https://docs.ubuntu.com/core/en/guides/build-device/image-building
<ogra_> point 2 and 3
<longsleep> ogra_: ok let me try to use a signed assertion without having the key registered with my account
<ogra_> well, i think ubuntu-image checks the key ... so that might not work either
<longsleep> ogra_: because step 2 of these instructions fail for me - http://paste.ubuntu.com/23770867/
<ogra_> well, thats a question for the store people i fear
<longsleep> ogra_: you are right, i cannot build with the signed assertion unless the key is registered
<longsleep> ogra_: error: cannot fetch and check prerequisites for the model assertion: account-key (BBZk-RcyZ-tJN9eRJTW-pwcHg7r2ME-Bm9kUn5qOKyRQMJ9SPyrham_UHoSNnrAJ) not found
<longsleep> :(
<ogra_> yep
<longsleep> so i already asked about this here in december - so far no luck in getting anyone from the store people :/
<ogra_> zyga, do you know whom longsleep could poke to get this working ?
<mvo> longsleep: what version of snapcraft are you using?
<longsleep> mvo: 2.24
<zyga> mmm
<zyga> no idea
<mvo> longsleep: that should be ok - maybe pedronis has an idea about the error in http://paste.ubuntu.com/23770867/ "Key registration failed: The account-key-request assertion is not valid." ?
<mvo> longsleep: he is at lunch right now though
<ogra_> iirc key management starts working after 2.17 ... so this should be fine
<longsleep> ogra_: i thought so, its the version from xenial-updates repository
<longsleep> mvo: ok thanks, lets hope to get a reply from pedronis when he is back
<ogra_> yeah, 2.24 is definitely good
<longsleep> i also tried with a new key, same error - so i think something is wrong with my account - it is very old and has probably gone through some migrations
<ogra_> try creating a longsleep-test account ;)
<longsleep> ogra_: yeah i might do that as last resort, but its kind of shitty to use two different accounts
<ogra_> just for this test indeed
<longsleep> ogra_: yeah let me setup an lxd container for that
<longsleep> ogra_: right, new account worked instantly :/ Done. The key "longsleep-test1" (KWRSCGwv7tVtZW8GpAHajvBIuWr0lfBBjmi4VPj6amYeeyzSmmG4Rf6uDrHT--Yc) may be used to sign your assertions.
<ogra_> well, now roll an image with it ;)
<longsleep> ogra_: currently building :)
<longsleep> or not ..
<longsleep> i guess the snaps are signed too or something?
<longsleep> error: cannot fetch and check prerequisites for the model assertion: cannot add assertion model (pine64; series:16 brand-id:IcQdq5akLGfjzZ15kmONNRvA8ORuNbAa): error finding matching public key for signature: found public key "KWRSCGwv7tVtZW8GpAHajvBIuWr0lfBBjmi4VPj6amYeeyzSmmG4Rf6uDrHT--Yc" from "d0VlBe971cyBTYMdulEfu4cyzUgJWiva" but expected it from: IcQdq5akLGfjzZ15kmONNRvA8ORuNbAa
<ogra_> the store snaps are ... is your gadget/kernel local or in the store ?
<longsleep> local
<ogra_> if they are local you should use them in --extra-snaps
<longsleep> yes thats what i am doing
<ogra_> hmm
<mup> PR snapd#2595 opened: daemon: re-enable reexec <Created by mvo5> <https://github.com/snapcore/snapd/pull/2595>
<ogra_> i thought they only get signed when you upload ... seemingly not ...
<longsleep> ogra_: http://paste.ubuntu.com/23775798/ is what i am doing, and the model assertion is signed with the new key which is registered to longsleep-test store account via snapcraft
<pedronis> mvo: longsleep: I have no idea tbh, cjwatson might be a better bet
<ogra_> longsleep, and you run this in the same container you created the key in ?
<ogra_> (the key must indeed be available to ubuntu-image)
<longsleep> ogra_: ah this is my fauilt, i need to change the key ids in the model json
<longsleep> then it should work
<mup> PR snapd#2596 opened: tests: parameterize kernel snap channel <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2596>
<ogra_> yeah
<longsleep> ogra_: this is really picky, timestamp outside of signing key validity
<ogra_> oh my
<ogra_> date -Iseconds --utc
<longsleep> ogra_: now it builds
<ogra_> and replace it with the output
<ogra_> yay
<longsleep> pedronis: would you mind poking them so i can use my real ubuntu account to sign snaps
<pedronis> longsleep: do you have the LPÂ bug you submitted at hand
<pedronis> found it
<longsleep> pedronis: sorry i had to switch location, https://bugs.launchpad.net/snapcraft/+bug/1652302 is the one you found i suppose?
<mup> Bug #1652302: Key registration failed: The account-key-request assertion is not valid. <Snapcraft:New> <https://launchpad.net/bugs/1652302>
<cjwatson> longsleep: digging
<longsleep> ogra_: looks much better with the signed model - now snaps are how they should be after first boot
<cjwatson> longsleep: could you modify your local version of snapcraft something like http://paste.ubuntu.com/23775926/ and send me the output when you try again?  Please try with your non-test account.
<longsleep> cjwatson: sure hold on
<cjwatson> longsleep: I don't think the output should be *very* private, but maybe send it in a private message just in case
<ogra_> longsleep, YAY !
<ogra_> \o/
<longsleep> ogra_: ah and now i also see the mount aa denies on boot, i guess thats why the hooks do not run - now it finds the snaps at least
<longsleep> ogra_: Jan 10 11:48:02 localhost kernel: [   65.153519] type=1400 audit(1484048882.620:9): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/pine64.mnt/" pid=1640 comm="snap-confine" srcname="/" flags="rw, bind"
<longsleep> ogra_: so i guess i am down to one issue now with snappy, the key problem seems to be a problem with my account
<ogra_> longsleep, hmm, never seen that one
<longsleep> ogra_: yeah, its the same i reported earlyier - happens for any command run through snap-confine - i am waiting on zyga for feedback
<ogra_> might be a kernel issue
<ogra_> (something missing in the namespace config ? )
<longsleep> ogra_: yeah, though i have looked and i seem to have all the aa patches
<ogra_> well, might not be the patches but just a config option
<longsleep> ogra_: might be, though lxd works with this kernel (thats why i backported the stuff in the first place)
<longsleep> ogra_: yes, any suggestions how to find out which?
<ogra_> apart from comparing to a working config ? not really
<longsleep> ogra_: could you pastebin a working /proc/config.gz
<ogra_> http://paste.ubuntu.com/23776040/
<ogra_> thats what i get for NS
<ogra_> plus CONFIG_NAMESPACES indeed
<zyga> longsleep: I didn't have time to inspect this yet
<zyga> longsleep: sorry :/
<longsleep> ogra_: looks different for me - http://paste.ubuntu.com/23776045/
<longsleep> zyga: no problem, i continue to investigate myself - but any pointers would be helpful
<zyga> longsleep: try to edit the apparmor profile of snap confine
<zyga> you can copy it from /etc/
<zyga> and edit it
<zyga> and recopile it with apparmor_parser -r
<zyga> try to add some rules related to the capture of the bind mount
<zyga> that would be in the hat-profile, at the bottom of that file
<zyga> (the name is /etc/apparmor.d/usr.lib.snapd.snap-confine)
<zyga> there are comments there
<zyga> if you have questions, ask
<zyga> but I cannot reproduce that here and you stand a better chance
<longsleep> zyga: yes i looked into that before, it has mount options=(rw bind) / -> /run/snapd/ns/*.mnt,
<longsleep> zyga: which should match this
<zyga> looks like a bug in apparmor
<longsleep> zyga: but i have no idea on what to change
<zyga> technically that's not what we are doing
<mup> PR snapd#2597 opened: vet: fix for unkeyed fields error on aliases_test.go <Created by stolowski> <https://github.com/snapcore/snapd/pull/2597>
<zyga> try to change the initial /
<zyga> the file we bind is /proc/self/ns/mnt
<zyga> but ... bugs bugs bugs
<zyga> and thank you!
<longsleep> zyga: yes it has # NOTE: the source name is / even though we map /proc/123/ns/mnt as comment
<zyga> :D
<longsleep> i have not much a clue about what aa is doing or why this might be like the NOTE says
<zyga> longsleep: looks like a bug to me, try a super broad rule like
<zyga> longsleep: mount options (rw, bind)
<zyga> longsleep: mount options (rw, bind), # <- don't miss the comma
<zyga> longsleep: try with one or both arguments on either side of the -> "bind" mount arrow
<longsleep> zyga: adding a broad rule "mount options=(rw, bind)." just works
<longsleep> zyga:  mount options=(rw, bind) /, works as well while mount options=(rw, bind) / -> /run/snapd/ns/*.mnt, does not
<longsleep> zyga: mount options=(rw, bind) / -> /run/snapd/ns/hello-world.mnt, does not work either
<ogra_> longsleep, any chance that you could use some newer kernel ?
<ogra_> might be that 3.10 simply misses namespace features there
<longsleep> ogra_: well, mainline is under way for that board but is not ready
<ogra_> hmph
<longsleep> ogra_: i can backport stuff if i would know which
<longsleep> ogra_: i did backport some fixes already to get lxd running
<mup> PR snapd#2597 closed: vet: fix for unkeyed fields error on aliases_test.go <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2597>
<Kaleo> what's the difference between the core snap and the ubuntu-core snap?
<ogra_> Kaleo, the name
<Kaleo> ogra_, I see
<ogra_> (not sure if snapd reacts any different based on the name but i think it doesnt)
<Kaleo> ogra_, when trying to use the classic confinement mode it needs to have the core snap installed; the ubuntu-core snap won't do; unpractical (especially that it's hard to install the core one when the ubuntu-core snap is installed)
<ogra_> eventually ubuntu-core will go away
<Kaleo> ogra_, thanks
<mup> PR snapd#2593 closed: Mount backend <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2593>
<ogra_> zyga, mvo ^^^ do we really still need that differntiation now that the content is identical ?
<ogra_> (classic snaps refused)
<Kaleo> ogra_, the differentiation is in snapcraft (at build time)
<ogra_> ah, k
<Kaleo> snapcraft/internal/project_loader.py
<ogra_> the prob is that we currenbtly have no proper upgrade path from the obsolete ubuntu-core to core
<ogra_> the only thing that works is to remove everything and re-install snapd afterwards ... then core will be the default
<ogra_> but that would make you lose all existing snaps
<Kaleo> not great
<mhall119> sergiusens: does the latest snapcraft in xenial support hooks?
<cjwatson> longsleep: can you retry register-key?  should work for you now thanks to nessita
<nessita> \o/
 * cjwatson repurposes https://bugs.launchpad.net/software-center-agent/+bug/1652302 for this
<mup> Bug #1652302: Unhelpful error from AccountKeyHandler if account assertion does not exist <Software Center Agent:New> <https://launchpad.net/bugs/1652302>
<Kaleo> ogra_, ever seen that? http://pastebin.ubuntu.com/23776495/
<zyga> ogra_: yes
<zyga> ogra_: blame linker
 * ogra_ blames linker 
<ogra_> Kaleo, hmm, nope
<ogra_> (specifically the french :P )
<ogra_> Kaleo, did you manually tinker with it ?
<Kaleo> ogra_, nah, and I'm starting to figure that it has to do with plugs being defined
<ogra_> or slots you dont have for the plugs ... yeah
<Kaleo> ogra_, the classic environment has slots?
<ogra_> dunno, i'm just learning about it too
 * ogra_ hasnt used classic yet ... just starting to look at it for the classic mode 
<Kaleo> ogra_, I had to remove network, network-bind, and platform
<Kaleo> ogra_, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1655369
<mup> Bug #1655369: cannot use the platform plug with a snap in 'classic' confinement <snapd (Ubuntu):New> <https://launchpad.net/bugs/1655369>
<ogra_> Kaleo, that might be on purpose though
<Kaleo> ogra_, perhaps
<Kaleo> ogra_, I was excited to use classic confinement for the terminal :)
<ogra_> well, it will be pretty much like a deb as i understand it
<ogra_> but only in context with core, not with other snaps
<pmcgowan> Kaleo, although classic is supposed to be short term solution I thought?
<Kaleo> pmcgowan, no idea
<zyga> jdstrand: hey
<zyga> jdstrand: do you have a moment
<jdstrand> zyga: hey, what's up?
<zyga> jdstrand: remember when we talked about new style interfaces
<zyga> jdstrand: well, they are happening
<zyga> jdstrand: I wanted to show you how things look like now
<zyga> jdstrand: I didn't get a review from gustavo yet so take it with a pinch of salt
<zyga> (perhaps some go-ness can be made nicer)
<mup> Bug #1655376 opened: Add support for android/touch type images <personal> <Snappy:New for ogra> <https://launchpad.net/bugs/1655376>
<zyga> jdstrand: I ported mount backend and the content interface over
<jdstrand> zyga: can you add something simple, like 'network' too? if you give me the PR then I can take a look
<jdstrand> likely today, possibly tomorrow
<zyga> jdstrand: not before gustavo acks the design
<zyga> jdstrand: network would require me to do apparmor which is by far the most complex one
<longsleep> cjwatson, nessita: yay thanks a lot - confirmed working!
<ogra_> yay
<jdstrand> zyga: can you show me what you are asking Gustavo to review?
<zyga> jdstrand: yup, just a second
<cjwatson> longsleep: \o/
<cjwatson> pedronis: ^-
<longsleep> \o/
<pedronis> cjwatson: thanks
<mup> PR snapd#2598 opened: snap-confine: allow snap-confine to re-exec too <Created by mvo5> <https://github.com/snapcore/snapd/pull/2598>
<mup> PR snapd#2599 opened: interfaces: add new-style interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/2599>
<zyga> jdstrand: ^^
<zyga> jdstrand: that thing
<zyga> jdstrand: note that this is just a proposal
 * jdstrand nods
 * jdstrand adds to list
<zyga> jdstrand: so both the implementation and design are just an example
<jdstrand> thanks
<stokachu> anyone know what this means:
<stokachu> [adam:~/Code/conjure-up/snapcraft] master(+15/-23) Â± sudo snap install ./conjure-up_2.1.0_amd64.snap
<stokachu> error: cannot find signatures with metadata for snap "./conjure-up_2.1.0_amd64.snap"
<zyga> stokachu: you are installing a snap but snapd knows nothing about it
<zyga> stokachu: try --dangerous
<stokachu> ok
<stokachu> zyga, thanks that worked
<zyga> stokachu: I assume you are hacking on this snap
<zyga> stokachu: normally this should never happen
<stokachu> yea i want to update it in the store
<stokachu> once i work out some kinks
<zyga> stokachu: and assertions are coming from the store :)
<stokachu> zyga, nice, i haven't gotten there yet
<stokachu> ran into this again though http://paste.ubuntu.com/23776803/
<stokachu> i dont remember what i did awhile ago to get around it
<zyga> mmm, no idea :/
<zyga> maybe set locale to C.UTF-8
<zyga> all snaps should have that
<stokachu> ok
<mup> PR snapd#2598 closed: snap-confine: allow snap-confine to re-exec too <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2598>
<popey> sergiusens: bug 1654721 is odd. It doesn't seem to copy to populate the build dir at all..
<mup> Bug #1654721: build directory empty with rust plugin <Snapcraft:Incomplete by sergiusens> <https://launchpad.net/bugs/1654721>
<mup> Bug #1655394 opened: First snap install of a local snap with devmode doesn't actually use devmode <Snappy:New> <https://launchpad.net/bugs/1655394>
<nuclearbob> how do I add a new user on ubuntu core? adduser fails when trying to create a group
<mup> PR snapd#2600 opened: tests: remove the snapd dirs last (should fix error on ppc64el) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2600>
<jdstrand> roadmr: hi! sorry, I have one more trivial fix (for iio and i2c path attribute) in the tools. can you pull r817?
<roadmr> jdstrand: sure! I'm doing my best to rall all this out this week
<roadmr> s/rall/roll/
<mup> Bug #1655394 changed: First snap install of a local snap with devmode doesn't actually use devmode <Snappy:Invalid> <https://launchpad.net/bugs/1655394>
<mup> PR snapd#2601 opened: overlord, store: move confinement filtering to the overlord (from The Store) <Created by chipaca> <https://github.com/snapcore/snapd/pull/2601>
<jdstrand> roadmr: cool, thanks! I don't have anything else planned. just fixing bugs as they come in :)
<zyga> jdstrand: I pushed to the new-interfaces branch with 2nd backend converted
<zyga> jdstrand: I have some (one) doubt left but I really love how this is progressing
<zyga> jdstrand: I'll look for a way to do a stab at seccomp/apparmor tomorrow that would not require a tedious flag day
<zyga> jdstrand: I want to be sure that what I did can model per-app/hook interfaces
<jdstrand> zyga: ack
<pmcgowan> zyga, jdstrand where can I read about install hooks
<jdstrand> pmcgowan: I didn't implement these and haven't used them myself. https://github.com/snapcore/snapd/wiki/Snap-format#hooks is supposed to document it, but it says TODO. I don't know if install hooks have been implemented yet (I know the configure hook is implemented). I'll point you at kyrofa
<jdstrand> I'm not sure if kyrofa is doing anything with install hooks, but he implemented configure hooks
<pmcgowan> jdstrand, maybe configure would do
<pmcgowan> when does it run?
<kyrofa> jdstrand, pmcgowan an install hook has been nixed, at least for now, since configure runs at all the times necessary
<pmcgowan> kyrofa, great then need ptr to docs
<kyrofa> pmcgowan, https://github.com/snapcore/snapd/wiki/hooks still seems to say that `configure` only runs with snap set, so it looks like it hasn't been updated in a while
<kyrofa> pmcgowan, but I can walk you through it, if you like
<pmcgowan> kyrofa, I am looking for a way to conditionally set an export
<kyrofa> pmcgowan, an export == environment variable?
<kyrofa> pmcgowan, what is the condition?
<pmcgowan> yes
<pmcgowan> we want to tell qtubuntu what environment it is in
<pmcgowan> and set its backend
<kyrofa> (jdstrand, I'm back on snapcraft nowadays, but hooks haven't changed too much since I was involved)
<pmcgowan> probably based on which snaps are on the system
<pmcgowan> kyrofa, for exmaple, I am either in a kiosk tye environment with just mir or a full personal with unity8
<jdstrand> kyrofa: thanks. I came to you cause of the docs. it seems that there are some issues with the wiki. let me try to fix them since that page isn't in the TOC
<kyrofa> pmcgowan, does the snap in question have permission to list the snaps installed, first of all?
<pmcgowan> kyrofa, prolly not
<kyrofa> jdstrand, yeah, not sure what the deal is there
<kyrofa> jdstrand, I wrote that hooks doc before the wiki existed
<kyrofa> pmcgowan, so the first thing we need to figure out is how to determine this
<kyrofa> pmcgowan, if you need to change the environment somehow, can I assume you've got content sharing going on?
<kyrofa> pmcgowan, can you determine what you need to determine using that?
<pmcgowan> kyrofa, could do that
<pmcgowan> hmm
<kyrofa> See if there are contents in this directory, or crawl it if necessary
<pmcgowan> kyrofa, right and if its not there then I default otherwise set the export
<kyrofa> Exactly. Think that'll work?
<pmcgowan> think so
<kyrofa> Okay let's go with that for now
<pmcgowan> I still want to lean about configure hooks :)
<jdstrand> kyrofa: ok https://github.com/snapcore/snapd/wiki/Snap-format is in the TOC and lists https://github.com/snapcore/snapd/wiki/Snap-format#hooks. I updated https://github.com/snapcore/snapd/wiki/Snap-format#hooks to refer to https://github.com/snapcore/snapd/wiki/hooks
<kyrofa> pmcgowan, so now the question is: are you sure this is something you only want to determine at install time?
<kyrofa> pmcgowan, because interfaces can be disconnected
<pmcgowan> kyrofa, in this case I think checking at runtime is ok
<kyrofa> pmcgowan, you might consider putting such a check in the app itself
<kyrofa> Yeah, okay
<kyrofa> So it sounds like your problem can be solved outside of hooks? I'm of course happy to show you hooks anyway
<pmcgowan> I am interested, you implied configure hooks run at other times?
<kyrofa> pmcgowan, indeed, this might be helpful: https://kyrofa.com/posts/snap-updates-automatic-rollbacks
<kyrofa> pmcgowan, the configure hook runs at install time, upon upgrades, and of course with `snap set` (to change the configuration)
<pmcgowan> gotcha
<kyrofa> pmcgowan, the difficulty comes when trying to determine why the hook is running
<kyrofa> Which is why I'd still like standalone install/upgrade hooks, but I digress
<pmcgowan> kyrofa, ok I think I grok it, not sure that works in this case though
<pmcgowan> as the hook wont be able to figure things out
<kyrofa> Well it would, but then it would have to have some way to tell apps what it learned
<kyrofa> In which case... you might as well just have the apps figure it out
<kyrofa> Especially considering that the outcome depends upon interfaces which can be disconnected/connected at any time
<pmcgowan> kyrofa, does a snap know if an interface is connected?
<kyrofa> pmcgowan, not right now, though last I heard there was ongoing work on interface hooks (i.e. run this hook when the interface is connected, that one when it's disconnected, etc.)
<pmcgowan> right
<pmcgowan> ok we already have a content interface here which will be there or not so still think I am set
<pmcgowan> hmm kyrofa is the content iterface available to the wraper script that runs the app?
<mwhudson> hello
<mwhudson> can you build classic confinement snaps on launchpad?
<kyrofa> pmcgowan, you mean is the shared content bind-mounted by the time the wrapper runs?
<kyrofa> pmcgowan, as long as the wrapper is called by something exported in the YAML as an app, yes
<kyrofa> (or if it's an app itself)
<pmcgowan> ok cool
<kyrofa> pmcgowan, ignoring bug #1645731, of course
<mup> Bug #1645731: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Confirmed for zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
<kyrofa> mwhudson, I assume so-- are you running into issues?
<pmcgowan> kyrofa, yeah like to get that fixed
<pmcgowan> bites me always
<kyrofa> pmcgowan, same here, every time
<mwhudson> kyrofa: yeah, i get the message from bug 1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1650946>
<kyrofa> pmcgowan, I haven't been able to recommend it to anyone as a result
<mwhudson> per https://launchpadlibrarian.net/301869726/buildlog_snap_ubuntu_xenial_amd64_go-17-mwhudson_BUILDING.txt.gz
<kyrofa> mwhudson, oh interesting-- they must have ubuntu-core installed instead of core?
<mwhudson> kyrofa: apparently i need the core snap to be installed while building but i don't know how to do that
<mwhudson> kyrofa: oh, so maybe it's a lp-side problem?
<kyrofa> mwhudson, oh wait-- they probably don't have _any_ snaps, eh?
<kyrofa> mwhudson, yeah, they need the core snap
<mwhudson> kyrofa: i don't really see why they would
<mwhudson> cjwatson: hey, if you're around, do you know anything about building classic confinement snaps on launchpad?
<mwhudson> cjwatson: it seems they need the core snap to be installed
<mwhudson> kyrofa: there's no way for a snap to depend on snaps for building?
<kyrofa> mwhudson, not in snapcraft anyway
<mwhudson> hm
<mwhudson> hard to believe i'm the first person to try this...
<kyrofa> mwhudson, to be fair, it was just released
<mwhudson> true
<kyrofa> And I'm not sure how many people use LP just yet
<cjwatson> mwhudson: even at build time?  anyway, I know nothing
<kyrofa> cjwatson, mwhudson I sent out an email involving concerned parties
<cjwatson> feel free to try to fix it in launchpad-buildd if you get to it before me
<cjwatson> assuming that it's even possible to do in a chroot
<kyrofa> cjwatson, ooo, that might be problematic indeed
<cjwatson> all builds happen in a chroot
<kyrofa> cjwatson, I haven't tried snaps in a chroot before, but I'd be willing to bet they don't work
<kyrofa> jdstrand, do you know anything about snaps in a chroot?
<mwhudson> ah yeah i bet that's fun
<mwhudson> iirc it only reads something fairly simple out of the core snap, maybe we can just hard code that on ubuntu
<mwhudson> er
<mwhudson> on launchpad
<kyrofa> mwhudson, or snapcraft could just download it and use what it needs out of it, like building a kernel
<mwhudson> oh eh
<mwhudson> it's not very simple
<mwhudson> but pedantically i don't think it needs the core snap to be installed
<mwhudson> just present on disk
<kyrofa> Agreed
<cjwatson> where's the code that uses it?
<mwhudson> i.e. you could download it and unsquashfs it to /snap/core/current
<kyrofa> cjwatson, https://github.com/snapcore/snapcraft/blob/master/snapcraft/_options.py#L170
<mwhudson> cjwatson: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/project_loader.py#L328-L349
<cjwatson> right, so quite a few things
<cjwatson> and conceivably more as time goes on
<kyrofa> Possibly
<mwhudson> hmm
<mwhudson> this also points to the fact that classic confinement isn't quite working for the thing i am snapping :)
<mwhudson> (go)
<mwhudson> $ readelf -d /snap/go-17-mwhudson/current/bin/go | grep -e 'RPATH|RUNPATH'
<mwhudson>  -> nothing
<mwhudson> also the interpreter is the host one, etc
<jdstrand> kyrofa: snaps in a chroot? depending on what you are asking, I suspect there will be a number of policy issues
<cjwatson> if anyone wants to find out if it works in a chroot, you could try using https://jujucharms.com/u/launchpad/launchpad-buildd/ (you need to log in to see that, for some reason)
<cjwatson> jdstrand: just installing the core snap
<cjwatson> we don't actually use that charm in production as such, but it's a quick way to run up a builder node for testing
<cjwatson> if you're using the lxd provider then you also get to test whether it works with snap in chroot in lxd :-)
<jdstrand> I suspect that there are going to be quite a few issues for snap-confine and running snaps. snapd itself might start
<cjwatson> jdstrand: it doesn't really have to run anything meaningful, just put the files in /snap/core/current/
<cjwatson> we could do that by hand as suggested above, but I'd really prefer not to have to reimplement the acquisition code by hand
<jdstrand> ok, I am missing a lot of context
 * jdstrand tries to read backscroll
<mwhudson> if i tried to upload a snap to the store that contained binaries that did not use the right elf interpreter, would something shout at me about it?
<kyrofa> mwhudson, I doubt it
<mwhudson> kyrofa: sadface
<cjwatson> jdstrand: tl;dr: in order to build classic snaps on LP, the core snap has to be installed so that snapcraft can poke about in /snap/core/current/ at build time.  All LP builds (snap or not) take place in a chroot
<cjwatson> the base system outside the chroot is guaranteed to be at least xenial, but will not necessarily match the release of the chroot
<mwhudson> kyrofa: actually i guess it's only classic snaps that need this check
<kyrofa> mwhudson, indeed
<jdstrand> cjwatson: if snapcraft only needs the files, then an unsquashfs in the right place (or a mount) should work fine
<cjwatson> jdstrand: will "snap install core" work?
<jdstrand> maybe?
<cjwatson> heh
<cjwatson> of course snap install has its own issues in this context
<cjwatson> we'd have to clean up at the end of the build
<jdstrand> I mean, snapd needs to be running. it isn't confined. installing core won't trigger snap-confine or anything
<kyrofa> cjwatson, you don't just toast the chroot?
<cjwatson> kyrofa: we do, but we have to unmount everything inside it first which snapd might not totally like
<euodeionomedeusu> hello, world!
<kyrofa> Ah, sure
<cjwatson> jdstrand: running ... inside the chroot or outside?
<jdstrand> so snapd might start in the chroot. snapd is usually started via systemd
<jdstrand> inside
<cjwatson> will snap do that on demand or do we need to do it separately?
<cjwatson> also that implies we need to make sure it stops, which is also possibly a little complex
<kyrofa> cjwatson, it's socket activated
<cjwatson> kyrofa: that won't help, systemd will be listening to the socket outside the chroot
<kyrofa> Hmm, indeed
<jdstrand> you might be able to just start it manually (but again, yeah, you'd have to start it
<cjwatson> maybe a manual mount would be easier than all that
<jdstrand> if you were going to do a start and stop command, you might just do an unsquashfs and rm command
<cjwatson> "snap download core" into a tmpdir, mount core_*.snap /snap/core/current
<cjwatson> we already clean up mounts
<jdstrand> or that
<kyrofa> Alright I'll update the email thread so sergio knows where it stands, we'll make this work one way or another
<kyrofa> Sorry for the wall mwhudson :)
<cjwatson> oh, "snap download core" will require snapd to be running, right?
<kyrofa> cjwatson, yeah, but snapcraft has code to talk to the store too
<cjwatson> does it have a download command?
<cjwatson> I don't see one
<mwhudson> kyrofa: it's ok, i can ignore hundreds of emails a day :)
<kyrofa> cjwatson, oh, do you think the ideal fix is in the builder?
<kyrofa> cjwatson, I was thinking snapcraft needed to do this
<cjwatson> hmm
<cjwatson> so I won't be sad if snapcraft does it, but I wasn't sure you'd be up for the "snapd can't be assumed to be running" constraint
<kyrofa> cjwatson, although now that I think about it, I don't think it's using anonymous access
<kyrofa> cjwatson, yeah I think that's okay, but sergio will know better
<cjwatson> and presumably if snapd *is* running then you don't want to just go mounting stuff under its feet
<cjwatson> also, anonymous access raises another question, did we ever actually settle on "core snap will never require authentication to download"?
<kyrofa> cjwatson, great question, and I suspect not
<cjwatson> I was pushing for that but I have a vague memory that I may have lost
<kyrofa> cjwatson, me too, but I lost track of the discussion
<cjwatson> so um that would be really sad for builders
<kyrofa> Hmm...
<kyrofa> All of the people who know are likely at the sprint :P
<cjwatson> quite
<cjwatson> OTOH this is a great argument for the core snap not to require auth :P
<kyrofa> Hahaha
<cjwatson> and it's easy to imagine that we might end up needing some other snaps for classic builds - something to do with build-dependencies perhaps?
<kyrofa> cjwatson, yeah, I'm not quite up to speed on the classic snap stuff
<kyrofa> Hmm... looking closer at how snapcraft uses it, it seems it would indeed have to be mounted to /snap/core, since it injects rpaths
<kyrofa> Which makes me waffle a little on snapcraft doing it, since in most scenarios it wouldn't have permission
<kyrofa> Yuck.
<mwhudson> i don't suppose anyone would like to do the rpath injection by providing wrappers for gcc/ld rather than environment variables? :)
<mwhudson> bash quoting is eating my head
#snappy 2017-01-11
<richtera> Does sudo snap install snap-codelabs no longer work or do I have something setup incorrectly.
<hangun> hi
<hangun> I am porting snappy to bubblegum96  board, the Soc has a fixed layout that the bootloader.bin âs offset is at 2097664 and the u-boot is at 3145728.It works when I  use https://github.com/uCRDev/Bubblegum96-Snappy/blob/master/gadget/gadget/meta/gadget.yaml and ubuntu-image version 0.10.
<hangun> Since the ubuntu-image is updated to version 0.12,  it may cause the error like this:
<hangun> sudo /snap/bin/ubuntu-image --channel stable --image-size 2G --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model
<hangun> Fetching core
<hangun> Copying "bubblegum96-kernel_3.10.0_arm64.snap" (bubblegum96-kernel)
<hangun> Copying "bubblegum96-gadget_16.04-1.1_arm64.snap" (bubblegum96-gadget)
<hangun> bubblegum96-gadget already prepared, skipping
<hangun> bubblegum96-kernel already prepared, skipping
<hangun> gadget.yaml parse error: mbr structures cannot be larger than 446 bytes.
<hangun> Use --debug for more information
<hangun> ubuntu-image had fixed a bug so that causes my issue   https://bugs.launchpad.net/ubuntu-image/+bug/1630769
<mup> Bug #1630769: part with role='mbr' should be stricter about its parameters <Ubuntu Image:Fix Released by barry> <https://launchpad.net/bugs/1630769>
<zyga> good morning
<mup> PR snapd#2602 opened: overlord/snapstate: remove restriction on ResetAliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2602>
<mup> Issue snapd#2603 opened: Disk free space left check <Created by cyberb> <https://github.com/snapcore/snapd/issue/2603>
<mup> PR snapd#2604 opened: interfaces: add classic-dimension interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2604>
<mup> PR snapd#2605 opened: overlord,overlord/snapstate: have UpdateMany retire/enable auto-aliases even without new revision <Created by pedronis> <https://github.com/snapcore/snapd/pull/2605>
<mup> PR snapd#2498 closed: interfaces: add new upower-control interface <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2498>
<mup> Issue snapd#2557 closed: interfaces: connect tun-based serial port <Created by mrsinghgit> <Closed by niemeyer> <https://github.com/snapcore/snapd/issue/2557>
<mup> Issue snapd#2503 closed: chattr code (tests/main/chattr/task.yaml) fails on ppc64el <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/issue/2503>
<mup> Issue snapd#2504 closed: interfaces-upower-observe snap test fails on ppc64el <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/issue/2504>
<mup> Bug #1655592 opened: interfaces-upower-observe snap test fails on ppc64el <Snappy:Triaged> <https://launchpad.net/bugs/1655592>
<mup> Bug #1655593 opened: chattr code (tests/main/chattr/task.yaml) fails on ppc64el <Snappy:New> <https://launchpad.net/bugs/1655593>
<mup> Bug #1655594 opened:  expect based tests fails on ppc64el <Snappy:New> <https://launchpad.net/bugs/1655594>
<mup> Issue snapd#2502 closed: expect based tests fails on ppc64el <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/issue/2502>
<icey> sergiusens: trying to do my classic snap, I added the .desktop file to the snap and suddenly snapcraft hates me again with: 'classic confinement requires the core_dynamic_linker to be set'
<liuxg> ogra_, ping
<ogra_> hey
<liuxg> ogra_, yesterday, thanks for answering my question regarding the slow build. do you mean to replace all of strings "http://ports.ubuntu.com/ubuntu-ports/ " in the source.list to " http://localhost:9999/ubuntu-ports"?
<liuxg> ogra_, currently the sources.list file is like http://paste.ubuntu.com/23780838/
<ogra_> liuxg, yep ... then you need to use apt update once to initialize the proxy db ...
<ogra_> hmm
 * zyga feels spring in the air :)
<liuxg> ogra_, how to initialize the proxy db? once it is installed, it is initialized?
<ogra_> that sources.list misses all basic entries
<ogra_> no, it is initialized with the first apt-get update
<ogra_> (just means it downloads the index files once from the archive)
<mup> Bug #1639284 changed: Cant start any snap application on Xenial <snapd:Incomplete by zyga> <https://launchpad.net/bugs/1639284>
<liuxg> ogra_, ok.. thanks. this is the default sources.list file in my pi device. http://paste.ubuntu.com/23780856/ do you mean I need to add more stuff there?
<Odd_Bloke> I'm trying to remove the ubuntu-core snap (so I can install the core snap), and I can't work out how to do so.  `sudo snap remove ubuntu-core` gives "error: cannot remove "ubuntu-core": snap "ubuntu-core" is not removable".
<ogra_> liuxg, no, that one looks fine .,.. your first one was missing the top part
<Odd_Bloke> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1589210 suggests that running snap disable first allows removal, but that also doesn't work.
<mup> Bug #1589210: snap remove failed ubuntu-core snap package <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1589210>
<liuxg> ogra_, I think your solution is very useful since a lot of developers could not compile their target due to the slaggish network on-site.
<stub> Odd_Bloke: Just doing that myself. I think you are stuck 'apt purge snapd', trashing all your snaps and their data, then 'apt install snapd'
<liuxg> ogra_, yeah, I just cut some of part of it, it is my fault. thanks for clarification.
<icey> why is snapcraft.io not served with SSL?
<stokachu> sergiusens, this python encodings error makes me sad
<Odd_Bloke> stub: Aha, fair enough; I knew I'd have to trash all snaps, didn't realise snapd itself had to go.  Thanks!
<sergiusens> stokachu we can skip lunch and fix it :-) Have you tried removing the stage/prime entries in your parts?
<icey> sergiusens: see my ping above?
<icey> also, can classic snaps access the system clipboard?
<stokachu> sergiusens, yea i cleared those out
<sergiusens> icey nope, just logged on to irc after 6 days
<stokachu> sergiusens, we can look after lunch :)
<icey> sergiusens: it was 10 minutes ago :-P
<icey> how about this: sergiusens: trying to do my classic snap, I added the .desktop file to the snap and suddenly snapcraft hates me again with: 'classic confinement requires the core_dynamic_linker to be set'
<sergiusens> icey you need the core snap installed
<icey> rather than the  ubuntu-core snap, I'm going to have to do that uninstall dance aren't I?
<sergiusens> icey yeah
<stub> I just filed https://bugs.launchpad.net/snappy/+bug/1655599 since this is technically a dataloss bug (if people have production data in their snap containment)
<mup> Bug #1655599: No migration of ubuntu-core to core <Snappy:New> <https://launchpad.net/bugs/1655599>
<icey> sergiusens: after removing everything, how do I replace ububtu-core with core
<mup> Bug #1655599 opened: No migration of ubuntu-core to core <Snappy:New> <https://launchpad.net/bugs/1655599>
<icey> oh really, uninstall snapd!?
<stub> https://bugs.launchpad.net/snapcraft/+bug/1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1650946>
<liuxg> ogra_,  one more question, do I need to change the sources.list in the ubuntu core snap or in the classic snap? sorry
<ogra_> in classic, i dont think it is even writable in the core side
<icey> sergiusens: :-/ '[Errno 2] No such file or directory: '/mnt/Media/projects/alacritty/parts/desktop/install/meta/gui''
<liuxg> ogra_, ok. I got it.. yeah, that is currently what I am doing now :)
<sergiusens> icey wait, let me get back to you on this, this is not how setup/gui works
<liuxg> ogra_, this is currently how sources.list looks like in my classic snap  http://paste.ubuntu.com/23780885/
<icey> sergiusens: sure, I'll grab you in a bit, copying the original source on it :)
<ogra_> that shoudl work fine
<liuxg> ogra_, thanks. I am now trying to apt-get, it is still slow. the first time apt update is slow, right? after that, it should be fine.
<stokachu> how do you clean a specific part again?
<stokachu> thought it was snapcraft clean pull
<ogra_> liuxg, yeah, it only pays off the second time you access a package indeed
<ogra_> liuxg, but from then on it will only download packages that are newer in the archive
<icey> stokachu: `snapcraft clean {STAGE}` just worked for me
<stokachu> ah stage
<stokachu> icey, thanks
<liuxg> ogra_, this is awesome. You saved the world:)
<ogra_> :)
<ogra_> liuxg, under  http://localhost:9999/ you can also see some very basic statistics
<ogra_> (or rather http://<ip-address>:9999/ since you need a browser fro this indeed)
<liuxg> ogra_, this is what I am building now http://imgur.com/a/6UqDY, is it downloading some new packages? I have already done the apt-get update.
<ogra_> liuxg, it will have to download the index files every time to compare if something was updated
<ogra_> also, if it is your first build it indeed has to download the packages once, like i said above
<liuxg> ogra_, ok. thanks. I will check it. yeah, the first time build seems to  be slow anyway. now, it says 30 mins
<ogra_> it needs to pull all debs into the proxy once indeed ...
<liuxg> ogra_, still, I think this is cool. for hackathon event, it is very needed. sometimes a single line change takes the build for 20 mins, basically, it makes the event useless.
<ogra_> well, on a hackathin i'D set up a dedicated machine and have everyone else point to it
<ogra_> *hackathon
<ogra_> and if you knwo what you are building you can do one build in advance and fill the proxy cache ahead of time
<liuxg> ogra_, but for developers, they may not know what are needed. Last time, I saw a developer using nodejs, the package took years to get downloaded.
<ogra_> yeah
<liuxg> ogra_, do you know how to set up a machine like what you said so that everyone can point to the machine?
<ogra_> you just do the same you just did above ;) and have people use the ip instead of localhost
<liuxg> ogra_, oh, you mean a Pi device? so everyone changes the sources.list to point to the same pi device?
<ogra_> or a laptop
<liuxg> ogra_, but a laptop is x86, right? most people work on arm.
<ogra_> whatever you have around ... the point is to use one central machine instead of everyone having his own proxy
<liuxg> ogra_, I got it. May I will have a try
<ogra_> the underlying arch doesnt matter ... packageproxy works on all arches ;)
<ogra_> and for all arches ... i.e. for x86 packages you would simply point to http://localhost:9999/ubuntu ... instead of /ubuntu-ports
<liuxg> ogra_, how does a x86 provides the debian packages for the arm architecture.
<ogra_> you are aware that the ubuntu archive is just a webserver ?
<liuxg> ogra_, yeah
<ogra_> the packageproxy just copies the content ... doesnt matter what arch
<liuxg> ogra_, ok. I got it. so it archives all of the debian packages whenever it is used to download from the archieve
<ogra_> for the main archive it serves them under /ubuntu ... for poirts.ubuntu.com it serves them under /ubuntu-ports
<liuxg> ogra_, so the proxy snap should be installed on the laptop machine, right?
<ogra_> yep
<ogra_> or on a central rpi if you have one spare ... or on a PC at home if you have proper bandwith to serve the archive from there ...
<ogra_> (or in the office if you have an external IP for the machine)
<ogra_> wherever you like ;)
<liuxg> ogra_, thanks. I got what you mean. this is truly useful for events. I had headaches to let developers develop onsite.. most of the time, they go home to finish the work.
<mup> PR snapd#2606 opened: overlord/snapstate: share code between Update and UpdateMany, so that it deals with auto-aliases correctly <Created by pedronis> <https://github.com/snapcore/snapd/pull/2606>
<foxrider83> hello all
<rvr> ogra_: I'm building an image with edge, and I get snap 2.20.1, is that equivalent to 2.21?
<ogra_> obviously not
<ogra_> 2.20.1ubuntu1 is the latest release
<rvr> ogra_: I see
<rvr> ogra_: So when 2.21 is available, will it be in both edge and candidate channels?
<ogra_> yep
<ogra_> well, edge first, but it will move to candidate eventually indeed
<rvr> Ok
<mup> PR snapd#2607 opened: many: move interface test helpers to ifacetest package <Created by zyga> <https://github.com/snapcore/snapd/pull/2607>
<zyga> ogasawara: hey, do you remember the conversation about putting kernel snap projects on github.com/snapcore/snapd similar to how the gadget snaps are there now?
<zyga> ogasawara: did you have a chance to discuss that in the kernel team?
<ogasawara> zyga: yep, did you not see the email I sent you about it?
 * ogasawara will resend
<ogasawara> zyga: sent
<mup> PR snapd#2608 opened: don't install govendor each  time <Created by zyga> <https://github.com/snapcore/snapd/pull/2608>
<zyga> ogasawara: thanks, I got it now
<mup> PR snapd#2555 closed: many: implement 'snap aliases' <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2555>
<liuxg> ogra_, when I build my project for the second time, I get the error like http://paste.ubuntu.com/23781469/, what could be the reason for it? thanks
<popey> sergiusens: elopio the "build dir is empty" bug.. I'm seeing similar with nodejs plugin, not just rust. Plausibly same bug or new one?
<ogra_> hmm
<ogra_> liuxg, can you ping localhost ?
<liuxg> ogra_, yes http://paste.ubuntu.com/23781476/
<ogra_> weird, works fine here
<liuxg> ogra_, inside classic http://paste.ubuntu.com/23781481/
<ogra_> and if you just call apt update in classic ?
<ogra_> does it update ?
<mup> PR snapd#2608 closed: don't install govendor each  time <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2608>
<ogra_> or install a random package
<liuxg> ogra_, the snap is there
<ogra_> that wasnt my question
<ogra_> does apt update inside the classic env work
<ogra_> or can you apt install some random package
<liuxg> ogra_, it is like http://paste.ubuntu.com/23781493/
<ogra_> looks like the proxy isnt running ... could it be that you ran out of diskspace or some such ?
<liuxg> ogra_, http://paste.ubuntu.com/23781496/
<liuxg> ogra_, http://paste.ubuntu.com/23781501/, I have a 16G disk
<ogra_> systemctl status snap.packageproxy.approx.service
<ogra_> ?
<ogra_> (outside of classic obviously)
<liuxg> ogra_, http://paste.ubuntu.com/23781511/, it is running. I just disable and enable it again.
<ogra_> well, i have never seen it not work and i use it since about two years on various machines ... pretty weird
<liuxg> ogra_, http://paste.ubuntu.com/23781527/
<ogra_> anything in syslog about why it fails ?
<ogra_> (thats an extremely dumb app, it can not fail, this is super strange)
<mup> PR snapd#2609 opened: store: request no CDN via a header using SNAPPY_STORE_NO_CDN envvar <Created by pedronis> <https://github.com/snapcore/snapd/pull/2609>
<ogra_> is 9999 taken by anything else ?
<liuxg> ogra_, no, I do not think it is taken. no other software uses the port
<ogra_> do you perhaps have a stale lockfile in /var/snap/packageproxy/3/lockfile.lock ?
<liuxg> ogra_, I am now doing it again.
<ogra_> doing what again ?
<liuxg> ogra_, http://paste.ubuntu.com/23781554/
<liuxg> ogra_, you are right.
<ogra_> remove it
<ogra_> thought this is extremely odd ... it is really a very dumb script, i havent seen it fail in years
<ogra_> the only thing i could imagine is that you either run out of diskspace (which you dont) or ram to make it fall over
<liuxg> ogra_, how could that happen? I must win the first prize :)
<liuxg> ogra_, now, it seems to be right. it starts to snap ...
<liuxg> ogra_, thanks.. this time, the build is really fast :)
<liuxg> ogra_, we should let the rest of the developers know this trick!
<ogra_> are you building something that could use a lot of ram during the build process?
<liuxg> ogra_, I do not think so. it is just dump plugin and compile some c files.
<ogra_> liuxg, well, if you see anything like the above again, please let me know
<liuxg> ogra_, by the way, if someday I do not want to have the cached files, how can I remove them?
<liuxg> ogra_, sure, I will observe it.
<ogra_> either snap remove packageproxy ... or just rm -rf /var/snap/packageproxy/3/var/cache/approx/*
<liuxg> ogra_, alright. many thanks
<ogra_> if you want to toggle it dynamically, just use a default sources.list and copy them back and forth as you need
<liuxg> ogra_, yeah, that makes sense. In fact, i did not keep the old one :) I will find it back.
<ogra_> it is in the core env ... if you exit classic
<ogra_> remember ? it is readonly there
<didrocks> ogra_: is there any kind of autoclean of the cache?
<liuxg> ogra_, yeah, it is the same.
<ogra_> ogra@pi3:~$ cp /etc/apt/sources.list .
<ogra_> ogra@pi3:~$ sudo classic
<ogra_> (classic)ogra@pi3:~$ sudo cp sources.list /etc/apt/
<ogra_> and you are back on the default sources.list ;)
<ogra_> didrocks, there is /var/snap/packageproxy/3/config.yaml ... you can adjust such stuff if needed
<didrocks> nice!
<liuxg> ogra_, right. I got it. thanks
<ogra_> didrocks, i didnt port all config options yet but largely http://manpages.ubuntu.com/manpages/xenial/man5/approx.conf.5.html applies
<didrocks> ogra_: good work! thanks for the reference :)
<ogra_> old stuff ... i need to update it again so that snap set and get work ;)
<ogra_> i created it in 15.04 snappy originally ... :)
<ogra_> adjusted it for newer changes)
<ogra_> *(only adjusted it...
<mup> PR snapd#2607 closed: many: move interface test helpers to ifacetest package <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2607>
<mup> PR snapd#2601 closed: overlord, store: move confinement filtering to the overlord (from The Store) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2601>
<rvr> fgimenez: ping
<rvr> fgimenez: Hey. Do you have a doc/spec or any good description about re-exec? It's planned for 2.21, want to be prepared to check it.
<mvo> rvr: give me some minutes and I send you something
<rvr> mvo: Thanks
<fgimenez> hey rvr, nope sorry, none that i know, thx mvo!
<mup> PR snapd#2610 opened: interfaces/browser-support: add @{PROC}/@{pid}/fd/[0-9] w and misc /run/udev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2610>
<mup> PR snapd#2599 closed: interfaces: add new-style interfaces <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2599>
<mup> PR snapd#2602 closed: overlord/snapstate: remove restrictions on ResetAliases <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2602>
<mup> PR snapd#2611 opened: interfaces: use fewer dot imports <Created by zyga> <https://github.com/snapcore/snapd/pull/2611>
<elopio> popey: can you share your nodejs snapcraft.yaml ?
<elopio> I've been playing a lot with nodejs and haven't seen anything like the error on the rust one.
<popey> elopio: it's super basic. http://paste.ubuntu.com/23782053/ - output http://paste.ubuntu.com/23782054/
<elopio> popey: agh, seems like exactly the same rust issue :( Can you please report a bug? I'll fix it for tomorrow's release.
<ryebot> is the snap store accepting classic confinement snaps, yet?
<zyga> ryebot: I believe it should but I heard that people had some issues
<ryebot> zyga: ack, thanks
<popey> elopio: ok
<mup> PR snapd#2612 opened: cmd/snap, daemon, overlord/snapstate: tests and fixes for "snap refresh" of a classic snap <Created by chipaca> <https://github.com/snapcore/snapd/pull/2612>
<popey> elopio: https://bugs.launchpad.net/snapcraft/+bug/1655678
<mup> Bug #1655678: nodejs plugin fails to build - empty build dir <Snapcraft:New> <https://launchpad.net/bugs/1655678>
<elopio> thank you.
<mup> PR snapd#2611 closed: interfaces: use fewer dot imports <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2611>
<mup> PR snapd#2613 opened: interfaces: add new interface API <Created by zyga> <https://github.com/snapcore/snapd/pull/2613>
<zyga> jdstrand: ^^
<zyga> jdstrand: take two on the idea
<zyga> jdstrand: hey
<zyga> jdstrand: debugging those i386 seccomp failures on xenial (for the old tests)
<zyga> jdstrand: I get killed by lack of 201, looking at libseccomp source code that is geteuid32
<zyga> jdstrand: what was that tool that resolves syscalls to numbers?
<zyga> jdstrand: I'm asking because this cannot be right, we allow that specific syscall in the common.sh profile
<zyga> ah
<zyga> found it
<zyga> sorry :)
<morphis> kyrofa, sergiusens: somehow the dependency handling for my snap is really different when using snapcraft to build and switching between classic and devmode confinement
<morphis> kyrofa, sergiusens: my app depends on libboost which I pull in a build-depends via libboost-system-dev for example but with classic confinement libboost-system doesn't end up in prime
<morphis> with devmode or strict it does
<morphis> is there some fundamental difference other than that confinement is disabled with classic?
<kyrofa> morphis, hmm... there is a difference, but I wouldn't expect it to cause that
<kyrofa> morphis, it uses the linker of the core snap and uses rpaths to the libs within, but that shouldn't stop boost from getting in
<morphis> kyrofa: so classic snaps are still running against the core snap or not?
<zyga> and fixed it :)
<kyrofa> morphis, you're on the verge of my knowledge here, but zyga will know more
<morphis> zyga: any ideas?
<kyrofa> I suspect that since snapcraft uses the rpaths, all those bind mounts don't happen
<kyrofa> So while the core snap is not its execution context, it still runs reliably
<kyrofa> But I'm making stuff up
<morphis> kyrofa: possible, lets see what zyga says
<zyga> morphis: classic and devmode are not just confinement, the snap is built entirely differently
<zyga> morphis: all the code in your snap needs to be built from source
<zyga> morphis: and it is built against what is in the core snap
<morphis> zyga: means if I use boost, I have to build boost on my own?
<zyga> morphis: all the executables are linked with stuff from /snap/core/current
<zyga> morphis: yes
<morphis> so I can't reuse any deb packages?
<zyga> morphis: the dynamic linker is also used from the core snap
<zyga> morphis: not that I know of
<morphis> so if I have a app which depends on mesa, sdl, boost, protobuf, sdl, alsa, ... I have to build all of them manually?
<zyga> yes
<morphis> wow
<morphis> that makes it a knockout thing
<zyga> I don't think anyone tried it against gui apps
<zyga> since core doesn't contain anything GUI-ish it is a difficult task I think
<morphis> so what is the reason for this?
<zyga> what is the reason for what?
<zyga> that they need to be built?
<zyga> because they are linked against the core snap
<morphis> zyga: when I don't use classic confinement I use the linker from the core snap too, correct?
<zyga> morphis: no
<zyga> morphis: not directly
<zyga> morphis: it depends on where you run
<morphis> true
<morphis> so on Ubuntu Core I do but on desktop I don't
<zyga> morphis: if you want to understand the details I can discuss this with you but believe me when I say this is the only way it can work
<zyga> morphis: you have to build it
<morphis> zyga: I believe you, just trying to understand
<zyga> morphis: ok
<zyga> morphis: build this and ldd it
<zyga> https://git.launchpad.net/checkbox-converged/tree/build-me
<zyga> hmm
<zyga> wrong link
<zyga> https://github.com/zyga/hello-classic
<zyga> morphis: ^^
<zyga> morphis: ldd this and look at what the elf file contains
<zyga> morphis: this is the only way to make it work without controling the mount namespace
<morphis> hm
<morphis> I see
<zyga> morphis: yeah, I bet it is going to be tough; I would love to see better support in snapcraft where one can lessen the cost of those builds
<zyga> morphis: smarter caching
<zyga> morphis: distcc/ccache
<zyga> morphis: and working complex examples
<morphis> zyga: its quite of useless if you have to rebuild everything and add it to your snapcraft.yaml
<morphis> which makes it kind of complex for not tiny applications
<zyga> morphis: well, not useless
<zyga> morphis: just time consuming
<zyga> morphis: sergio built a lot of nice things (git, vim) this way
<zyga> morphis: and this is not a design choice, just technical challenge
<zyga> morphis: this is a hard problem
<zyga> morphis: you can cheat
<morphis> yeah it is
<zyga> morphis: you can build it to look for big libraries in /usr/lib
<zyga> morphis: but that's not guaranteed to work
<zyga> morphis: only /snap/core is guaranteed
<zyga> morphis: btw, I could use a review on the new interface API if you have some time
<morphis> zyga: sure!
<morphis> zyga: but not today
<mup> PR snapd#2587 closed: interfaces/mount: add snippet types <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2587>
<elopio> popey: could you try with snapcraft from master?
<popey> elopio: uhm, where's that?
<elopio> popey: git clone https://github.com/snapcore/snapcraft
<elopio> and then instead of running just snapcraft, use the full to the bin/snapcraft that you cloned from that repo.
<popey> ok
<popey> elopio: ok, fails differently now :)
<elopio> popey: let me see...
<popey> elopio: http://paste.ubuntu.com/23782441/
<mup> PR snapd#2573 closed: snap: add information about tracking channel (not just actual channel) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2573>
<stokachu> trying to get around a apparmor issue: http://paste.ubuntu.com/23782447/
<stokachu> wanting to systemctl start my custom bridge
<elopio> popey: ok, I think you should use cleanbuild, because it might be having a conflict with your local npm stuff.
<popey> ah
<stokachu> heres my snapcraft http://paste.ubuntu.com/23782451/
<popey> elopio: trying..
<roadmr> jdstrand: hello! so the store is updated to tools r817 finally \o/ (also heads up - the controls for plugs/slots, classic and others have moved to the snap level (rather than upload level). Let me know if you have any trouble finding them now
<popey> elopio: fails in the old way in cleanbuild... http://paste.ubuntu.com/23782468/
<stokachu> also ubuntu-core doesn't seem to have the firewall-control anymore
<stokachu> nm was called core
<elopio> oh, right, cleanbuild installs the released one.
<elopio> so, hum, I don't think there's a way for you to test it.
<popey> i can just make a deb
<elopio> instead of a snap? :)
<popey> lulz
<elopio> popey: no, you can get a lxc container, or a clean vm. Clone snapcraft, and try there.
<mup> PR snapd#2609 closed: store: request no CDN via a header using SNAPPY_STORE_NO_CDN envvar <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2609>
<popey> making a deb is quicker
<elopio> or delete your local npm stuff.
<popey> hm, might do that too
<elopio> popey: hum, but you need to install that deb in a clean environment.
<popey> yeah, just realised that :D
<elopio> we have a few bugs about using unclean containers for cleanbuild. That would make testing easier, despite the contradiction.
<elopio> and it might be a bug that npm fails if you have some local stuff. I'm not sure about that, npm is confusing altogether.
<popey> yeah, nuking my ~/.npm helped
<mup> Bug #1655711 opened: typo in Ubuntu Core documentation - Ubuntu Core Images <Snappy:New> <https://launchpad.net/bugs/1655711>
<popey> elopio: built! :D
<pstolowski> ratliff, hello! I noticed you were looking at my notes re per-snap context implementation; just a heads up, I
<pstolowski> ratliff, I've added two sentences regarding the use of snap-confine and the behavior on missing context
<elopio> popey: yay! so the bad news is that I spent a couple of hours trying to fix a bug that was already fixed, wondering why I couldn't reproduce it here.
<zyga> jdstrand: can you please +1 https://github.com/snapcore/snapd/pull/2433
<mup> PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433>
<zyga> jdstrand: it's tiny and I wanted to land it when green
<zyga> jdstrand: the tests were okay, just common.sh needed more i386 specific syscalls
<popey> hah, sorry el
<popey> *elopio
<elopio> popey: no, thanks a lot for your help. I also found a couple of things that are not nice, and a mistake in my rust PR.
<popey> sweet! good to hear
<mup> Issue snapd#2559 closed: seccomp tests fail on Ubuntu 16.04 in when running in qemu or linode <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2559>
<mup> PR snapd#2521 closed: interfaces: allow read/write access of real-time clock with time-control interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2521>
<jdstrand> zyga: I'll add it to my list
<jdstrand> roadmr: thanks!
<jdstrand> stokachu: I think that may be bug #1655369. if you have time, it would be great if you could comment in the bug and provide more info
<mup> Bug #1655369: cannot use the platform plug with a snap in 'classic' confinement <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1655369>
<jdstrand> zyga: the tool that resolves syscalls both ways is scmp_sys_resolver
<lazyPower> so, i know that snapcraft has a daemon key you can set to have snapcraft generate a systemd unit file. Say i want to deliver a custom systemd unit file + defaults with my daemon, would the proper path forward be to write a wrapper that does the systemd unit install + configuration, and invoke that bash script manually, or is there a tuneable unit file template syntax?
<lazyPower> Sorry if this has been covered elsewhere, i've been in/out of this conundrum for a few days now and have been split-attention with it, so any pointers are welcome.
<kyleN> I'd like to include a LOCAL (non-published) gadget snap in a model assertion for use with ubuntu-image.  I tried the full gadget snap file name in the model assertion ("gadget": "pi2kyle_16.04-0.17_armhf.snap",) but the ubuntu-image command does not find it. is there a way to do this?
<kyleN> put another way, is it a requirement that the gadget snap is published to stable for ubuntu-image to find it?
<mup> PR snapd#2614 opened: interfaces: allow getsockopt by default since it is so commonly used <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2614>
<mup> PR snapd#2615 opened: make patch4 robust against in-progress install changes <Created by pedronis> <https://github.com/snapcore/snapd/pull/2615>
<pedronis> kyleN: no, the model assertion just needs the name, you pass the local snap to ubuntu-image with --extra-snaps
<kyleN> pedronis, thanks. I did not know you could do that with the gadget snap.
<pedronis> kyleN: the option name is a bit unclear but is both extra or local overrides
<kyleN> ack
<mup> PR snapd#2612 closed: cmd/snap, daemon, overlord/snapstate: tests and fixes for "snap refresh" of a classic snap <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2612>
<mup> PR snapd#2614 closed: interfaces: allow getsockopt by default since it is so commonly used <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2614>
<stokachu> jdstrand, yea i can provide my snapcraft etc to that bug
<ryebot> As part of my snapcraft.yaml, I'm pulling a binary from an upstream source and using the dump plugin. Problem is, the binary isn't marked executable. Is there a pattern for dealing with this?
<ryebot> I tried writing a wrapper that sets the executable bit, but of course the fs is readonly, so.
<stokachu> jdstrand, updated that bug #1655369
<mup> Bug #1655369: cannot use the platform plug with a snap in 'classic' confinement <snapd (Ubuntu):New> <https://launchpad.net/bugs/1655369>
<Skuggen> ryebot: Newer snapcraft have keywords for parts that let you execute shell statements as part of the build process. Maybe you can use that to set the executable bit during the build?
<ryebot> Skuggen: excellent, thanks, I'll take a look
<Skuggen> Can't actually find it in the online docs, but if you run snapcraft help plugins it's mentioned, I think. I've used the prepare: keyword to run a script that stages files to use in the build
<mup> Bug #1655369 opened: cannot use content interface with a snap in 'classic' confinement <Snappy:Triaged> <https://launchpad.net/bugs/1655369>
<jdstrand> stokachu: I responded in the bug
<stokachu> jdstrand, thank you! testing now
<stokachu> jdstrand, in theory if i do a classic snap can i just include other binaries i need to run my app?
<stokachu> i realize it isn't confined and im interested in getting updates out quicker than a ppa
<mup> PR snapd#2424 closed: interfaces/builtin: add physical-memory-* and io-ports-control <Created by tonyespy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2424>
<jdstrand> stokachu: you can put whatever you want in your snap
<stokachu> plus i want to eventually control the versions of juju/lxd that go into it
<stokachu> at least until there is a sense of snap dependencies i guess
<jdstrand> stokachu: note that if this is going to be officially supported by Canonical, you'll want to talk to ratliff and tyhicks about best practices and tracking. this is work that is being discussed at the sprint
<stokachu> jdstrand, ok yea ive spoke to tyhicks today, i wanted to get this at least running so he could see what im trying to accomplish
<jdstrand> but in terms of what is possible with snapd, you can put anything in your snap
<stokachu> then iterate from there
<jdstrand> cool
<lazyPower> OP: :	so, i know that snapcraft has a daemon key you can set to have snapcraft generate a systemd unit file. Say i want to deliver a custom systemd unit file + defaults with my daemon. The generated unit file clearly states at the top its auto-generated, and editing is highly discouraged. How can I provide these extra bits to my daemon?
<jdstrand> stokachu: also, I'll be adding a check to the review tools to alert when specifying 'confinement: classic' with 'plugs' (in general, there is one possible use case with the content interface)
<stokachu> jdstrand, ok awesome
<stokachu> lazyPower, i think you can do like templating in the yaml
<stokachu> lazyPower, believe i saw it in some of the openstack snaps jamespage was writing
<lazyPower> stokachu ah good info, thanks for the pointer
<lazyPower> stokachu - i think this is what  i was looking for under config
<lazyPower> https://github.com/javacruft/snap-openstack-compute-controller/blob/master/snapcraft.yaml
<mup> Bug #1594919 changed: Require a method to ship udev rules independent of apps and slots <snapd-interface> <Snappy:Won't Fix> <https://launchpad.net/bugs/1594919>
<mup> PR snapd#2615 closed: make patch4 robust against in-progress install changes <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2615>
<kyrofa> jdstrand, do the review tools break on _any_ symlinks pointing outside of the snap?
<jdstrand> kyrofa: no. there are exceptions based on snapcraft and one other for symlinks from the SNAP dir into SNAP_DATA
<jdstrand> well, /var/snap/SNAP_NAME/...
<kyrofa> jdstrand, alright, I just noticed that snapcraft leaves dangling symlinks if they're pointing to libs contained in libc
<kyrofa> I didn't realize that was ever done on purpose
<jdstrand> kyrofa: yes. that is intentional and the review tools make exceptions for those
<mup> PR snapd#2610 closed: interfaces/browser-support: add @{PROC}/@{pid}/fd/[0-9] w and misc /run/udev <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2610>
<kyrofa> jdstrand, can you imagine any downside to snapcraft simply deleting those links and letting the snap use the one directly from core?
<jdstrand> kyrofa: I don't recall the details, but sergiusens left those on purpose cause things were crashing if they used a different libc than what was on core
<kyrofa> jdstrand, but the libs they link to (/lib/<arch>/blah) _come_ from core, do they not?
<kyrofa> Ever since snap-confine reversed the mounts I've not been able to keep track of what's mounted where :P
<jdstrand> kyrofa: I'm not sure they are guaranteed to. Like I said, I sergiusens did this very specifically. probably best to ask him cause the details are foggy for me
<kyrofa> jdstrand, alright will do, thanks :)
<jdstrand> sure thing
<stokachu> is there a way in --classic to run the systemctl command to start a service i need within my snap?
<stokachu> automatically after snap install
<stokachu> similar to the postinst in a deb package
<kyrofa> You might be able to do that in the configure hook
<seshu> kyrofa: Do you have any references to configure hook? documentation or example?
<kyrofa> seshu, https://github.com/snapcore/snapd/wiki/hooks
<seshu> kyrofa: Thanks much!
<stokachu> where would i put this in snapcraft?
<kyrofa> stokachu, https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md but note that what's documented there has not yet been released
<kyrofa> You can run out of master if you need it
<stokachu> cool thanks, yea i run master
<seshu> kyrofa: I don't see snap get <snapname> <key> example. Is it still under development?
<kyrofa> seshu, `snap get` should work
<kyrofa> Does it not?
<seshu> kyrofa: it works, kind of...
<kyrofa> seshu, what's wrong?
<snappy_irc> We are trying to build kernel snap from a binary .deb, it's not working, want to know if it is supported. We get the following error after executing '$ snapcraft'
<seshu> kyrofa: two things. 1. I'm trying to see how I can implement get and set for my snap
<snappy_irc> $ snapcraft
<snappy_irc> "confinement" property not specified: defaulting to "strict"
<snappy_irc> "grade" property not specified: defaulting to "stable"
<snappy_irc> Use of build-properties in the schema is deprecated.
<snappy_irc> Plugins should now implement get_build_properties
<snappy_irc> Skipping pull kernel (already ran)
<snappy_irc> Preparing to build kernel
<snappy_irc> Building kernel
<snappy_irc> make -j1 defconfig
<snappy_irc> make: *** No rule to make target 'defconfig'.  Stop.
<snappy_irc> Command '['/bin/sh', '/tmp/tmp_gqzcokn', 'make', '-j1', 'defconfig']' returned non-zero exit status 2
<kyrofa> snappy_irc, please utilize http://pastebin.ubuntu.com/
<seshu> kyrofa: 2. Trying to get key:value pairs network-manager supports...apparently, without knowing key there is no way to use snap get command
<kyrofa> seshu, you don't have to do anything special to support `snap get/set`
<kyrofa> seshu, as for trying to obtain all keys, or defining a schema, indeed that functionality doesn't exist today
<seshu> kyrofa: got it. Thanks for clarification.
<kyrofa> seshu, `snap set` will result in your configure hook being called (if you wrote one), where you can handle the configuration change. `snap get` doesn't use your hook at all, it just returns whatever was previously set (either by snap set or by snapctl set, in your hook)
<seshu> kyrofa: ah! okay!
<stokachu> someone mind looking at https://github.com/conjure-up/conjure-up/blob/snapcraft-updates/snapcraft.yaml and why my conjure-up.sh script isn't replacing the conjure-up command?
<nacc> stokachu: is conjure-up.sh correctly placed in the snap's squashfs?
<stokachu> nacc, do i use like snapcraft try to see that?
<nacc> stokachu: i tend to use `unsquashfs -l /path/to/whatever.snap`
<stokachu> ah nice
<nacc> stokachu: there might be a more 'official' snapcraft way , though :)
<stokachu> here's the output squashfs-root/bin/conjure-up.sh
<stokachu> err
<stokachu> http://paste.ubuntu.com/23783977/
<stokachu> looks like both are there
<nacc> stokachu: the other thing to look at, might be to see if you can add a shell app (I don't know if that has been added as default boilerplate or not), so you can drop to a shell in the snap and see what's where
<nacc> stokachu: and in this case, I guess, what is pointing to where :)
<stokachu> ah ok, ill add bash toit and see
<nacc> stokachu: ah there is 'snap run --shell <app>`
<nacc> stokachu: that *might* be all you need
<stokachu> lemme try that
<nacc> stokachu: sorry for the vagueness, i'm not a snapping expert by any means :)
<stokachu> all good, the tips help :)
<stokachu> bah need to sleep, sergiusens im needing some help tomorrow :)
<mup> PR snapcraft#1035 closed: rust plugin: use the part source path <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1035>
<kyrofa> stokachu, what do you mean "replacing" ?
<kyrofa> nacc, note that whatever is in `prime` will end up in the snap, so it's easier to just look in there
<stokachu> kyrofa, so i have a conjure-up.sh file and i want that to be used instead
<kyrofa> stokachu, instead of what?
<stokachu> instead of the conjure-up script that gets created from the python setuptools
<stokachu> i need to pass in some custom snap paths
<kyrofa> stokachu, ah, is the one from python the bin/conjure-up (no .sh) ?
<stokachu> yea
<kyrofa> stokachu, it's not replacing it because it's named `conjure-up.sh`
<kyrofa> What are you expecting exactly?
<kyrofa> stokachu, do you want to exclude bin/conjure-up completely?
<stokachu> so i want conjure-up.sh to be called from the cli as 'conjure-up' but that script is just a wrapper around the real 'conjure-up' with some additional options
<kyrofa> Ah, then you should be fine on all counts
<kyrofa> You don't want bin/conjure-up replaced
<kyrofa> You just want it callable via `conjure-up`, which is should be thanks to your app
<stokachu> ah ok
<kyrofa> stokachu, if bin/conjure-up.sh replaced bin/conjure-up... you wouldn't be wrapping anything!
<stokachu> so the error i get is fatal: could not create work tree dir '/snap/conjure-up/x8/spells': Read-only file system
<kyrofa> stokachu, might I recommend a better naming convention though
<stokachu> should i not be using $SNAP/spells
<stokachu> kyrofa, yea ill take all the help i can get
<kyrofa> stokachu, just name the wrapper something more obvious, like conjure-up-wrapper.sh, or run-conjure-up.sh, etc
<kyrofa> (note that you don't even need the .sh if you don't want it)
<stokachu> ah ok
<kyrofa> stokachu, is that error at runtime, then?
<stokachu> kyrofa, yea
<kyrofa> Yeah, $SNAP is the squashfs image, which is always read-only
<kyrofa> You'll want to use one of the writable areas
<stokachu> SNAP_USER_DATA persists through upgrades, is that the best place to put it?
<stokachu> or i think it used too
<kyrofa> stokachu, all writable areas persist through upgrades, but do so slightly differently
<kyrofa> stokachu, see https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data for more information
<stokachu> thanks will take a look
<stokachu> kyrofa, \o/ yay that worked
<stokachu> now i can just bug sergiusens about the hooks tomorrow :D
<stokachu> kyrofa, thanks again
<kyrofa> stokachu, sure thing. Note that sergiusens is sprinting this week and likely won't be very responsive
<stokachu> kyrofa, yea im at the same sprint :D
<kyrofa> Ah :)
<stokachu> i tend to stalk him, he's popular at these things
<kyrofa> stokachu, yeah he's a popular dude. I can help you with the hooks if you need some pointers
<stokachu> ok cool, i read the snapcraft hook doc it wants me to place the hooks in a snap dir, should i just put everything inside there?
<stokachu> ive been keeping it all in snapcraft dir
<kyrofa> stokachu, "everything" meaning what, exactly?
<stokachu> oh i see the demo
<stokachu> i create a part for the hook and then manually copy over a script I need to run after an install into $SNAPCRAFT_PART_INSTALL/snap/hooks?
<stokachu> i guess $SNAPCRAFT_PART_INSTALL/snap/hooks/<trigger>
<kyrofa> stokachu, that's the second of the two supported methods
<kyrofa> stokachu, if your hook is coming from a part, you do it that way. If instead your hook is maintained in the repo along with the snapcraft.yaml, you can put it in the snap directory
<kyrofa> (like the other demo)
<stokachu> ah
<stokachu> kyrofa, is configure the write hook to use?
<kyrofa> stokachu, for what?
<kyrofa> stokachu, note that, according to the snapd docs, that's really the ONLY hook to use
<stokachu> ok
<stokachu> it's just for installing a network bridge and doing it via systemd once
<stokachu> and on any reboots
<kyrofa> stokachu, it won't run on reboot, just install, upgrade, and `snap set`
<kyrofa> stokachu, so you might want to do it from the wrapper itself
<stokachu> ah ok just check before hand for the interface and bring it up that way
<kyrofa> Yeah
<stokachu> yea that makes sense as the app isn't running a long standing process
<stokachu> so my snap contains lxd daemon, does that get started at all prior to me running the actual conjure-up script?
<kyrofa> stokachu, yes, daemons contained within the snap are fired up as part of the installation
<stokachu> kyrofa, what happens on reboot will they be started again?
<kyrofa> stokachu, indeed, they're systemd units (check /etc/systemd/system)
<stokachu> ah nice
<stokachu> kyrofa, i think that covers everything then :D
<stokachu> ill give this a run in the morning
<kyrofa> stokachu, very good
<stokachu> cya
<mup> PR snapcraft#1043 opened: [DO NOT MERGE] check the cla exception <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1043>
#snappy 2017-01-12
<mup> PR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1043>
<mup> PR snapcraft#1043 opened: tests: fix the CLA launchpadlib install in travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1043>
<snappy_irc> anybody know the localhost login details for ubuntu snap core ?
<snappy_irc> I downloaded the ova from here http://cloud-images.ubuntu.com/snappy/devel/core/current/devel-core-amd64-cloud.ova?_ga=1.214375895.1790561723.1484162457
<mup> PR snapcraft#1043 closed: tests: fix the CLA launchpadlib install in travis <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1043>
<mup> PR snapcraft#1044 opened: tests: use python2 to check the CLA <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1044>
<mup> Bug #1655834 opened: Support factory reset <Snappy:New> <https://launchpad.net/bugs/1655834>
<mup> PR snapd#2544 closed: interfaces: implement login-control interface <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2544>
<zyga> o/
<zyga> hey mvo
<mvo> hey zyga
<mup> PR snapd#2554 closed: tests: add end-to-end store test for classic confinement <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2554>
<mup> PR snapd#2605 closed: overlord,overlord/snapstate: have UpdateMany retire/enable auto-aliases even without new revision <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2605>
<mup> PR snapd#2469 closed: interfaces: upower-observe: refactor to allow snaps to provide a slot <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2469>
<mup> PR snapd#2616 opened: tests: test classic confinement `snap list` and  `snap info` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/2616>
<mup> PR snapd#2617 opened: tests: switch more tests to MATCH <Created by zyga> <https://github.com/snapcore/snapd/pull/2617>
<sergiusens> stokachu https://github.com/snapcore/snapcraft/blob/master/snaps_tests/__init__.py#L180
<stokachu> sergiusens, https://github.com/juju/juju/blob/staging/snapcraft.yaml
<mup> PR snapcraft#1038 closed: misc: delete bzr ignore <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1038>
<sergiusens> icey https://bugs.launchpad.net/bugs/1655832
<mup> Bug #1655832: App name in snapcraft.yaml must match case of .desktop file <Snapcraft:New> <https://launchpad.net/bugs/1655832>
<icey> yeah sergiusens?
<mup> PR snapd#2618 opened: tests: run all spread tests with SNAP_REEXEC={0,1} <Created by mvo5> <https://github.com/snapcore/snapd/pull/2618>
<mup> PR snapd#2606 closed: overlord/snapstate: share code between Update and UpdateMany, so that it deals with auto-aliases correctly <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2606>
<icey> sergiusens: I think I got the linker flags in
<mup> PR snapcraft#928 closed: Add missing dependencies to install_requires <Created by javacruft> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/928>
<zyga> jdstrand: FYI, snap-alter-ns won't be setuid root, it will just be started by snapd (like snap-discard-ns)
<zyga> jdstrand: we can choose to confine it but I wanted to make sure you know this
<mup> PR snapd#2567 closed: debian: skip snap-confine unit tests on nocheck <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2567>
<mup> PR snapd#2619 opened: many: update 14.04 branch to top of master <Created by zyga> <https://github.com/snapcore/snapd/pull/2619>
<mup> PR snapd#2616 closed: tests: test classic confinement `snap list` and  `snap info` output <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2616>
<mup> PR snapd#2620 opened: store: export userAgent. daemon: print store.UserAgent() on startup <Created by chipaca> <https://github.com/snapcore/snapd/pull/2620>
<stokachu> how do i get into the shell of a snap again?
<stokachu> snap run --shell conjure-up doesn't seem to do what i need
<Chipaca> stokachu: `snap run --shell the-snap` should do what you need
<Chipaca> stokachu: how is it not?
<Chipaca> that is, what do you need, and what are you getting?
<stokachu> so im building juju inside my snap but I think the problem is hte juju binary isn't getting copied into the snap
<stokachu> still working that out
<Chipaca> stokachu: that gives me more questions, but doesn't answer mine :-D
<stokachu> yea sorry still trying to understand what im doing
<stokachu> Chipaca: http://dpaste.com/361CKWW basically trying to expose the juju binary alongside conjure-up
<morphis> mvo: do you know if there is a clear reason why every systemd service unit snapd generates wants the network-online.target?
<Chipaca> stokachu: you did "snap run --shell conjure-up"
<stokachu> Chipaca, yea
<Chipaca> stokachu: what did that do? and what did you expect it to do?
<stokachu> it brought me into a new shell and i was looking for the juju binary that wasn't there
<Chipaca> stokachu: i'm missing somemething, i fear
<stokachu> Chipaca, sorry, i built my conjure-up snap while pulling in the juju part from the wiki, in the end i want to be able to run both conjure-up and juju binaries from that single snap
<Chipaca> stokachu: "snap run --shell conjure-up" is giving you a shell in the environment that apps in the conjure-up snap would see
<Chipaca> stokachu: (modulo connections)
<stokachu> Chipaca, ok, now im trying to figure out why that juju one isn't showing up in the file list
<stokachu> Chipaca, using --classic
<mvo> morphis: no clear reason
<mvo> morphis: if that is a problem we can kill it
<Chipaca> stokachu: when you say "in the file list", you mean in the snap?
<stokachu> Chipaca, yea
<stokachu> should it be conjure-up.juju as the command name?
<Chipaca> yes
<stokachu> how can i make it just juju? with an alias?
<Chipaca> stokachu: yes
<Chipaca> stokachu: but: is juju in conjure-up something users are expected to interact with?
<stokachu> Chipaca, yea, juju needs to talk to the agent installed inside that snap
<mup> PR snapd#2619 closed: many: update 14.04 branch to top of master <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2619>
<morphis> mvo: not a urgent thing to fix but it conflicts with network-manager when I add a Alias=NetworkManager.Service in the generated unit file
<morphis> as it then has a cycle of dependencies
<stokachu> trying to get this juju binary include but hitting http://dpaste.com/2XNXGRW
<stokachu> the part im pulling in is https://github.com/juju/juju/blob/juju-2.0.2/snapcraft.yaml
<morphis> zyga: any idea about https://paste.ubuntu.com/23786689/? I am using a 3.4 kernel here so could be something not well supported by that ancient kernel but would like to understand this a bit more
<mup> PR snapd#2620 closed: store: export userAgent. daemon: print store.UserAgent() on startup <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2620>
<zyga> morphis: looking
<zyga> morphis: 3.4
<zyga> morphis: mount namespaces
<zyga> morphis: do you see /proc/self/ns ?
<zyga> morphis: if not then 3.4 is too old
<zyga> I honestly don't expect 3.4 to work
<morphis> https://paste.ubuntu.com/23786828/
<mup> PR snapd#2618 closed: tests: run some spread tests with SNAP_REEXEC={0,1} <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2618>
<zyga> morphis: there's no mnt entry there
<zyga> morphis: the error is confusing but 3.4 is too old
<zyga> morphis: and there's no way to solve it easily without a major feature in snap-confine
<zyga> (I discussed this a while ago but this is 2-3 weeks to do)
<zyga> morphis: what is the HW if you can disclose this?
<morphis> zyga: I see
<zyga> morphis: if I end up writing this I'd like to know if I have it on my desk
<morphis> zyga: see PM
<zyga> morphis: got it now
<zyga> morphis: if we chat on rocket I get better notification
<stokachu> zyga, snapstore supports delta downloads now right?
<mup> PR snapd#2617 closed: tests: switch more tests to MATCH <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2617>
<morphis> zyga: :-)
<zyga> stokachu: yes but the client needs a special variable to enable that
<stokachu> zyga, when will that get enabled by default?
<zyga> stokachu: I don't know, that's a question to chipaca (not on IRC now) and nessita
<stokachu> ok thanks
<Chipaca> zyga, no, *you're* not on irc
<zyga> oh
<zyga> odd
<zyga> tab tab gave me nothing, sorry about that
<zyga> :)
<Chipaca> we don't have delta downloads enabled by default
<Chipaca> because of the xdelta3 dependency
<stokachu> Chipaca, is that something that is in the works to be done soon?
<Chipaca> stokachu, it's paperwork
<Chipaca> but afaik it's moving forwards
<Chipaca> so it'll get done in time
<Chipaca> i mean: the code is there
<stokachu> Chipaca, ah ok awesome
<Chipaca> and you can even use it if you set the right env var
<stokachu> cool is it documented anywhere?
<Chipaca> dunno. SNAPD_USE_DELTAS_EXPERIMENTAL=1 in snapd's environ will do it
<stokachu> cool thanks
<Chipaca> and, you need xdelta3
<zyga> jdstrand: hey
<zyga> jdstrand: did you read about the new BFP attachments to cgroups?
<jdstrand> zyga: yes. I assume you are refering to the comment in the 'ip netns' PR. I just commented there
<zyga> jdstrand: actually no, I read the article on LWN
<zyga> jdstrand: I'll check the PR
<jdstrand> zyga: the pr doesn't mention bpf, but it was talking about network mediation, so I thought you were going there
<stokachu> hi could i get someone to take a look at https://myapps.developer.ubuntu.com/dev/click-apps/5479/rev/26/?
<jdstrand> stokachu: I will
<stokachu> jdstrand, ty!
<mup> PR snapd#2621 opened: osutil.GetenvBool now takes an extra, optional, argument <Created by chipaca> <https://github.com/snapcore/snapd/pull/2621>
<jdstrand> stokachu: done. you need to press the release button
<stokachu> jdstrand, perfect ty, do i need to worry about getting additional reviews if i need to push a new snap?
<jdstrand> stokachu: not now (I granted that). check your email
<stokachu> jdstrand, ok great, thank you again
<jdstrand> np
<stokachu> jdstrand,  sudo snap install conjure-up --edge --classic <- am i missing anything here?
<stokachu> says snap isn't found
<stokachu> oh isee
<stokachu> release button at the bottom
<stokachu> hmm not sure what im missing now
<stokachu> maybe there is a delay
<stokachu> http://paste.ubuntu.com/23787291/ snap info does show it in the edge channel as well
<pedronis> stokachu: some confusion but installing classic snaps from the store doesn't work in 2.20 or before (we are fixing it in 2.21)
<stokachu> pedronis, ah
<stokachu> pedronis, np i can just work with the blob itself for now
<pedronis> stokachu: the workaround to try it is to use "snap download   snap-name"   "snap ack *.assert" "snap install *.snap"
<stokachu> pedronis, ah perfect, that'll work
<pedronis> sorry for the incovenience
<stokachu> np i know it's very new
<jdstrand> stokachu: there is an issue with snapd and the store when using --classic. I don't recall the details. I think sergiusens has a workaround
<jdstrand> ah, I see you already got an answer to that :)
<stokachu> jdstrand, :D
<stokachu> i can still corner sergiusens tomorrow unless he's hiding from me
<jdstrand> roadmr: hi! can you pull r824 of the tools? this is just updates to data/ for 2.21 interfaces and whitelisting some approved kernel and gadget snaps
<roadmr> jdstrand: sure thing
<jdstrand> roadmr: thanks! I *think* this will be it for a while (famous last words)
<mup> PR snapd#2520 closed: many: fix abbreviated forms of disconnect <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2520>
<mup> PR snapd#2622 opened: asserts: Improve error message when key is not valid at the given time <Created by mvo5> <https://github.com/snapcore/snapd/pull/2622>
<Cust0sLim3n> hi
<Cust0sLim3n> when will rhel/centos be supported
<mup> PR snapd#2621 closed: osutil.GetenvBool now takes an extra, optional, argument <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2621>
<ogra_> Cust0sLim3n, perhaps SamYaple or zyga know if thats actually planned ... fedora is surely supported (with limitiations in the confinement)
<elopio> hello Cust0sLim3n: https://github.com/snapcore/snapd/wiki/Distributions
<Cust0sLim3n> thanks elopio
<zyga> Cust0sLim3n: hey
<zyga> Cust0sLim3n: CentOS needs some packaging work
<zyga> Cust0sLim3n: Fedora has two blocking issues that we've struggled with
<zyga> Cust0sLim3n: both are on the backlog but I expect ~1-2 weeks before I start working on that
<Cust0sLim3n> zyga, is there some repo with stuff for CentOS / Fedora builds ?
<zyga> Cust0sLim3n: please have a look at http://www.opera.com/pl/computer/neon
<zyga> er
<zyga> paste fail
<zyga> http://github.com/snapcore/snapd/wiki/Distributions
<zyga> Cust0sLim3n: there was COPR but it is no longer used as development moved to Fedora git
<Cust0sLim3n> zyga, cool thanks
<zyga> Cust0sLim3n: CentOS should be easier (no selinux on services by default) but it needs separate packaging permissions
<zyga> Cust0sLim3n: if you are interested we could work together to revive copr and build a centos package there
<zyga> Cust0sLim3n: I cannot commit 100% of my time to it this or next week but I will help you out
<Cust0sLim3n> zyga, don't really have time - really need it for RHEL though - but I think in meantime I will just use software collections on rhel or something - still have to see
<Cust0sLim3n> zyga, just thought it would be nice to use snappy instead of SCL
<zyga> Cust0sLim3n: what software are you most interested in?
<zyga> Cust0sLim3n: we'll get there, it's just a busy schedule all the time
<Cust0sLim3n> zyga, its for commercial use with our C/C++ software on linux that I want it
<Cust0sLim3n> zyga, but its not critical enough for us to dedicate allot of time to it - so it was mainly just if I somehow missed it being available it would have been nice - but otherwise we will just use SCL or package directly
<zyga> Cust0sLim3n: how do software collections help you?
<zyga> jdstrand: hey - new interfaces API: https://github.com/snapcore/snapd/pull/2613/files
<mup> PR snapd#2613: interfaces: add new interface API <Created by zyga> <https://github.com/snapcore/snapd/pull/2613>
<zyga> jdstrand: with initial review from gustavvo
<zyga> jdstrand: I think it is likely to land soon
<zyga> jdstrand: once it does expect a flag day where all the interfaces and backends are ported to provisional APIs like spec.AddSnippet() (that directly replaces returning a snippet)
<jdstrand> I'll be looking at that in a little bit
<zyga> jdstrand: and then dedicated changes to backends like mount, kmod, systemd that are well defined and have just a few interfaces
<zyga> jdstrand: then we can discuss apparmor/seccomp
<zyga> jdstrand: I think there's no rush on aa/sc but we can see what we'd like to do by porting one or two interfaces over to more semantic APIs
<zyga> jdstrand: e.g. in seccomp we could do spec.Allow(seccomp.open) rather spec.AddSnippet("open")
<zyga> jdstrand: in apparmor we could do (but in short cases IMHO) spec.Allow("/path/to/file", "r") or even spec.Allow("/path/to/file", apparmor.Read)
<zyga> jdstrand: thanks!
<Cust0sLim3n> zyga, makes it easier to work with multiple library and application versions and allows us to be less dependent on library versions shipping with OS - so if we want newer boost version for building with than is available on RHEL by default we can package it with SCL
<jdstrand> zyga: keep in mind, I've not looked at this at all yet, but please, please, please keep in mind that the resulting security policy needs to be auditable. that means policy, structure and comments all need to be in place. I maintain my concerns that this will impede security audits since the review will have to do profile dumps to see what is happening
<zyga> jdstrand: I keep this in mind and keep reminding everyone about it :-)
<jdstrand> tyhicks: fyi ^
<mup> PR snapd#2623 opened: tests: add test ensuring manual pages are shipped <Created by zyga> <https://github.com/snapcore/snapd/pull/2623>
<jdstrand> ogra_: hi! I noticed that the bbb kernel is a few versions behind the most recent USNs
<jdstrand> ogra_: is your automated script not working right?
<ogra_> jdstrand, that one isnt automated ...  i'll kick off a new build
<jdstrand> ogra_: fyi, you can automate it if you want. I just added an exception for it in the review tools (though this upload will need a review, when the store syncs it won't any more)
<ogra_> ok
<mup> PR snapd#2624 opened: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<zyga> tyhicks: good news, I think I know what the kernel bug is about :)
<zyga> (the one with oops on one thing I did a while ago)
<zyga> well, fingers crossed
<zyga> at the very least I can give you a way to reproduce easily
<zyga> jdstrand, jjohansen:  ^^
<zyga> (oops in apparmor)
<zyga> on the up side it is *not* Friday yet
<kgunn> ogra_: thanks for the pi image...one question, anyway we could change pi3 console config to not require ethernet cable?
<kgunn> i set up wifi fine, but then it loops back and demands i set up via ethernet
<ogra_> kgunn, i think there is an old bug open for this ...
<kgunn> ah
 * kgunn thot pi2 didn't have wifi chip
<kgunn> and that was the reason
<ogra_> you can set it up initially with eth0, then reboot, ssh in and run "sudo console-conf" and disabe eth0 and switch to wlan0 ... that works fine for me
<ogra_> it is only the very first boot where it fails
<davmor2> ogra_: out of interest why are we use pi2 kernel on pi3 are there phyiscally no differences between then?
<ogra_> (but indeed you need network on the very first boot to set up the user)
<zyga> ogra_: you can use the serial console
<zyga> ogra_: on a pi :)
<ogra_> davmor2, the kernel is identical ... but th ebootloaders are not (namely there is a different u-boot.bin )
<jdstrand> jjohansen: this is not what we talked about yesterday, but zyga is seeing an oops with https://github.com/snapcore/snapd/pull/2624. I have a feeling many of your concerns about changing the mount namespace would apply to this pr
<mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<ogra_> zyga, for what ?
<zyga> ogra_: to do the 1st boot dance
<zyga> jdstrand: that branch is buggy but perhaps this is causing the oops
<ogra_> zyga, and that magically pulls the login data via serial ?
<zyga> jdstrand: testing again with the fix
<zyga> ogra_: oooooho
<ogra_> :D
<zyga> ogra_: I should have gotten that beer
<ogra_> you need network to be able to finish console-conf once
<ogra_> hah
<zyga> jdstrand: anything I should know about?
<ogra_> once it is finished, switching networks is easy
<jdstrand> zyga: you should wait for jjohansen. he had concerns regarding changing namespaces and open fds and likely some other concerns
<zyga> jdstrand: will he be around today?
<jdstrand> zyga: this came up in the context of snap-alter-ns, but I think they would apply to this
<zyga> jdstrand: hmm hmm, can you tell me how would snap-alter-ns be affected? we could presumably do all the open() calls after we re-associate
<zyga> (just worried if I should be worried)
<jdstrand> zyga: he should be. he has been sick though. not sure when he'll be online
<jdstrand> zyga: need to wait for jjohansen. we were going to chat today. may as well make it all 3 of us
<jdstrand> (or maybe tomorrow)
<zyga> jjohansen: I'm sorry to hear that, I hope you get better
<zyga> jdstrand: if he's around can you please PM me on telegram (I get notifications on my phone this way)
<zyga> I'd like to listen to understnad this problem better
<jdstrand> zyga: you can listen to irc then?
<zyga> jdstrand: if the converstation is on IRC then that's much easier :)
<jdstrand> zyga: it will be, yes
<zyga> jdstrand: somewhat offtopic, I think there's a separate bug, kernel doesn't let me bind() the mount namespace FD if I don't run as root despite having all the capabilities; I will need to investigate that in ~10 days. Do you know if this is by design (by any chance)?
<jdstrand> zyga: I don't, sorry
 * zyga will dig through the kernel then
<alvarolb> hi there! How I can submit a snap package both for armhf and amd64? I have both snaps already built.
<zyga> alvarolb: just send them to the store
<zyga> alvarolb: you can use snapcraft for that
<zyga> alvarolb: or use the web UI
<zyga> alvarolb: both snaps need to have the same snap name / snap id
<zyga> alvarolb: and (hopefully) different architecture entries
<alvarolb> yes, but if I upload the amd64
<kyrofa> alvarolb, they will both be assigned different revisions and the store will know what arch they are. And snapd won't let a snap for the wrong arch be installed
<alvarolb> then it replaces the armhf
<zyga> alvarolb: it doesn't really replace them
<zyga> alvarolb: just try it, you will have to publish each one
<zyga> alvarolb: then you should be able to install them :)
<alvarolb> Ok, so I upload both versions to the same snap package, and it should work
<kgunn> ogra_: re eth, ack...except i don't have eth cable access here at my communal office space :-P
<alvarolb> it does not show that the snap is available for both platforms
<kyrofa> alvarolb, then run `snapcraft status <snapname>` and you'll see where each arch has its own channel map
<ogra_> kgunn, ah, damned
<ogra_> kgunn, well, we dont have a solution beyond this yet
<ogra_> you could try a wifi dongle, perhaps that works better
<alvarolb> ok, thanks for the support!
<mup> PR snapd#2433 closed: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2433>
<mhall119> jdstrand: can you take a look at this error for me? http://paste.ubuntu.com/23788349/
<mhall119> I suspect that it's not really a problem with the limits, but rather the snap's inability to check what the limits are, due to confinement
<zyga> mhall119: Jan 12 14:31:59 mhall-thinkpad snap[5671]: /snap/couchbase-server-community/x1/couchbase-server-snap: line 166: exec: erl: not found
<zyga> mhall119: limits seem to be a separate issue
<zyga> mhall119: look at dmesg | DENIED please
<zyga> er
<zyga> dmesg | grep DENIED
<mhall119> zyga: nothing from couchbase there, I have another issue with it not finding the 'erl' binary that I need to fix
<stokachu> so in a classic snap how would i copy a file to my HOME dir?
<zyga> mhall119: then I'd say it dies on that problem now
<stokachu> not the home dir of the snap
<zyga> stokachu: classic snap or in the classic confinement of some snap/
<stokachu> zyga, in the classic confinement
<zyga> stokachu: snaps that have confinement: classic don't get HOME redirection
<zyga> stokachu: HOME is real :)
<zyga> stokachu: try it,
<stokachu> hmm so if i do a cp file ~/test from the snap it doesn't show up in my HOME dir
<zyga> stokachu: https://github.com/snapcore/snapd/wiki/Environment-Variables#home
<zyga> stokachu: can you use "snap run --shell $SNAP_NAME.appname" and go to $HOME
<zyga> stokachu: or just echo $HOME
<zyga> stokachu: if that's a bug I can (still) fix it
<stokachu> zyga, hmm ok $HOME shows my user (ubuntu) /home/ubuntu when i do a snap run --shell conjure-up
<stokachu> need to check out my code then, because things like os.expanduser in python should work as normal correct?
<stokachu> yea must be something in my code
 * stokachu back to drawing board
<AlbertA> ogra_: this may be a different bug (wifi), I ran console-conf after first boot like you mentioned but
<AlbertA> wlan0 option dissapears
<zyga> stokachu: I hope so, we don't change anything else
<AlbertA> ogra_: I guess a reboot fixed that :)
<stokachu> zyga, hah
<zyga> jdstrand: hey, so I made some progress but got stuck; I don't see any apparmor denials (the process is in devmode), I don't see anything in the kernel log but when I open /proc/1/ns/mnt I get EACCES
<zyga> jdstrand: I did an experiment where I just nsenter around and this worked OK
<zyga> jdstrand: I suspect apparmor is causing this
<zyga> jdstrand: can you please have a look at https://github.com/snapcore/snapd/pull/2624/files#diff-5f1642833244a655796f5f4230f68fdbR207
<mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<zyga> jdstrand: and tell me if I need to adjust the apparmor profile in some special way (in the same pull request)
<mup> PR snapcraft#1045 opened: Handle parser errors better <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1045>
<zyga> jdstrand: note, I *don't* get a DENIED anywhere :-(
<zyga> jdstrand: (thinking about it now I want to point out that while the process running snap-confine is in devmode, snap-confine itself is obviously confined)
<zyga> jdstrand: perhaps my change is not applied to the snap-confine I'm runnning from the (repackaged) core snap?
<zyga> jdstrand: still thinking aloud, looking at /sys/kernel/security/apparmor/profiles I see
<zyga> http://paste.ubuntu.com/23788499/
<zyga> jdstrand: should snap confine reset the policy (maybe this should be done in the base apparmor template, running snap confine doesn't inerhit the profile but replaces it with the profile for snap-confine)
<zyga> jdstrand: insight appreciated, I'll check back later
<zyga> jdstrand: I've added some more facts here: https://github.com/snapcore/snapd/pull/2624#issuecomment-272270130
<mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
 * zyga EODs
<ogra_> AlbertA, yeah, wla0 is there and you can even attempt to configure it but it will always fail in the end
<ogra_> second attempt is stable
<roadmr> jdstrand: you got lucky and we had a clear store deployment pipeline; tools r824 is now in production
<jdstrand> \o/
<jdstrand> roadmr: thanks :)
<lazyPower> o/ heyo, trying to use snapcraft from MASTER. My tests pass save for some subclass issues (about 7 failures that seem unrelated) - however when attempting to use snapcraft, i get the following message: Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path
<kyrofa> lazyPower, how are you running snapcraft?
<lazyPower> kyrofa - i followed the hacking guide to install it (isolated in a lxd container)
<lazyPower> kyrofa - after the predep steps, python setup.py install && cd $my-snaps-path && snapcraft
<lazyPower> s/python/python3/
<kyrofa> lazyPower, the hacking guide only discusses dependencies, not snapcraft itself
<kyrofa> lazyPower, when it comes time to run it, simply run bin/snapcraft (or add it to your PATH)
<jdstrand> mhall119: your system seems to have 'nofile' set somewhere. you can see your limits by typing 'ulimit'. I did just now on classic, in hello-world on classic and hello-world on all snaps and they all say 'unlimited'. see man limits.conf and /etc/security/limits.conf
<jdstrand> mhall119: are you seeing any security denials?
<jdstrand> zyga: re https://github.com/snapcore/snapd/pull/2624/file if there is no denial, it shouldn't be apparmor. the kernel might be telling you EACCES for another reason. that said, I think we should ask jjohansen about it
<mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<jjohansen> looking
<jdstrand> zyga: when you use nsenter, are you doing it from within snap-confine at the point that it is getting the EACCES? ie, nsenter from global namespace to pid 1 namespace is one thing, some snap app running anohter snap app that triggers snap-confine to have it go to pid 1 is another thing
<jdstrand> jjohansen: ^ that is the summary of the issue
<jjohansen> right
<jdstrand> jjohansen: let's wait for zyga to respond on that. do you have time to discuss snap-alter-ns? (what we discussed yesterday)
<jjohansen> we discusssed it?
<jdstrand> well
<jdstrand> we referenced it?
<jdstrand> the thing from yesterday :)
<jjohansen> right
<jdstrand> (which isn't the same thing as the above pr)
<jdstrand> jjohansen: you have time now?
<jjohansen> sure, I guess
<jdstrand> jjohansen: ok. so let me give you the problem and a simple description of what the propsed solution is, then the url for the din depth description of the fix
<jdstrand> jjohansen: today snaps can ship multiple commands. those commands may be daemons or manually started. all commands within a snap share the same mount namespace, so the all see the same /tmp and things that snapd might mount into the namespace
<jdstrand> jjohansen: this is done by when a snap command is first started, a nsfs magic file is checked. it is isn't magic, the full mount namespace is setup, then the magic file is saved. the next command that runs see the magic file and snap-confine enters that mount namespace instead of generating it anew
<jdstrand> jjohansen: on top of that, there is an interface called 'content'. this allows a providing snap to 'export' something in its area so that another snap may 'import' it. this is done via a file that maps the export dir to the import dir that snap-confine reads and it will perform a mount of the exported dir into the calling snaps mount namespace
<jdstrand> jjohansen: iirc, things work fine if the interfaces are connected (ie, snap-confine is supposed to do this mount operation) and the mount namespace is not setup (eg, after a reboot). there have been some issues with if the mount namespace is setup already iirc and adding it after the mount namespace is already setup. (eg, start the command, then connect the interface, etc)
<jdstrand> jjohansen: so zyga came up the the idea of 'live modification of mount namesapces'
<jdstrand> jjohansen: in essence, that is meant to robustly perform the mount of the imported directory on a namespace that is already setup, and remove mounts that have been disconnected
<jdstrand> jjohansen: I mentioned that removing mounts will cause problems with daemons most likely-- I think he will counter that they'll lazy umount.
<jdstrand> jjohansen: the live modification will be done by 'snap-alter-ns', a command that snapd will call when a 'snap connecnt' or 'snap disconnect' is performed. it is meant to mount missing connected imports and unmount ones that are no longer connected
<jdstrand> jjohansen: here is the larger proposal: https://github.com/snapcore/snapd/wiki/Live-Modification-Of-Mount-Namespaces
<jdstrand> jjohansen: <I'm done>
<jdstrand> jjohansen: well, I have one final thought. revocation aside, I thought that simply adding mounts would not be problematic since that isn't really any different than say plugging in a usb key and having it show up. that said, there are many layers of mounts here and that may be a naive way of looking at it
<jjohansen> okay, removing mounts can be problematic for any open fd, but it is probably something that isn't a blocker
<zyga> re
<zyga> hey
 * zyga watched 2nd episode of 4th season of Sherlock
<zyga> jdstrand: replied on your comment
<zyga> jdstrand: according to my experiment this only happens when apparmor is in the loop, I could have made a mistake, I was tired already
<zyga> 22:26 < jdstrand> zyga: when you use nsenter, are you doing it from within snap-confine at the point that it is getting the EACCES? ie, nsenter from global namespace to pid 1
<zyga>                   namespace is one thing, some snap app running anohter snap app that triggers snap-confine to have it go to pid 1 is another thing
<jjohansen> additions at first glance look safer, but have the potential to create aliases and rewrite subtree. If tightly controlled it should be okay, if not it is an attack vector
<zyga> jdstrand: to reply to this: when I use nsenter I was doing it from the mount namespace created by snap-confine
<zyga> I'm happy to discuss anything
<jdstrand> zyga: let's pause on 2624 for a moment and get through snap-alter-ns
<zyga> ok
<jjohansen> zyga: can you turn on apparmor debug messages
<jjohansen>   echo 1 > /sys/modules/apparmor/parameters/debug
<jjohansen> and see if that turns anything up, also turn off printk rate limiting to make sure printk isn't dropping something
<jjohansen>   echo 0 > /proc/sys/kernel/printk_ratelimit
<zyga> jjohansen: ack, I'll do that
<jdstrand> jjohansen: wrt aliases and rewrite subtree, how would one trigger that? right now, the snap declares a dir and that is it. is it a malformed dir? a symlink? something in the dir that could trigger it?
<jdstrand> oh I forgot rate limiting
<jjohansen> apparmor shouldn't be denying something without logging it, hmmm unless explicitly told not to log it, better turn off quieting as well
<jjohansen> echo -n noquiet > /sys/module/apparmor/parameters/audit
<jdstrand> jjohansen: we don't actually explicitly much in the snappy policy (I think there are two rules otoh)
<jdstrand> but noquiet never hurts
<jjohansen> just trying to make sure all potential reasons not to log are out of the way
<zyga> ok, test in progress
<zyga> let's talk about snap-alter-ns
<jdstrand> (fyi, you need sys_admin for entering the namespace and snap-confine has that)
<zyga> correct
<jdstrand> jjohansen: did you see my last question?
 * zyga finishes reading backlog
<jjohansen> jdstrand: you mount over an existing dir/tree location that isn't a leaf
<jjohansen> it just has to be controlled is all
<jdstrand> jjohansen: like, twp exported dirs mounted onto the same import dir?
<zyga> I'm fine with limiting this so that we can guarantee no "funny" layouts are possible
<jdstrand> jjohansen: it is rather tightly controlled right now. I want to make sure we make sure we get all the bits
<zyga> you should also be aware with one more thing we're trying to introduce that may complicate this
<zyga> the 'overmount' interface, that within the snap's mount namespace, allows it to almost freely do bind mounts from $SNAP to various places across the fileystem; the use case is shoving stuff into /usr/share so that pre-compiled binaries feel more at home
<jdstrand> zyga: can you add to your list a check to make sure that you can't mount on an already mounted location? ie, no layering at all
<zyga> jdstrand: so essentially the target directory cannot itself be a mount point
<jdstrand> zyga: that is how I took jjohansen's comment. let's get his feeback
<zyga> jdstrand: will this restriction cause any issues to users?
<zyga> ok
<jdstrand> zyga: I think blocking that is a good thing despite this. it would be weird to have two content exports mounted over each other. which would win? poor user experience
<zyga> agreed
<zyga> are we considering *any* mount points or just those that interfaces created?
<jdstrand> jjohansen: ^
<zyga> /bin/bash: line 44: /sys/modules/apparmor/parameters/debug: No such file or directory
<jjohansen> jdstrand: well sure that is one, doesn't really matter any non-leaf mount can result in weirdness, as you have a shadowing affect
<zyga> hmm
<jjohansen> ie. alias
<zyga> ah, module vs modules
<jdstrand> with the content interface I think this is ok
<zyga> jjohansen: can you give me an example of a mount that would be problematic
<jjohansen> whether its good or bad depends on what you are trying to achieve, but it adds to the complexity of what needs to be analyzed and opens the potential for attacks that you don't see. I think you probably okay, the mounts are being done by snapd not the application
<zyga> jjohansen: I'd like to understand what to avoid better
<jdstrand> we are mounting into a dir that shouldn't have any mounts (well, could be on a dir in a squashfs)
<jdstrand> jjohansen: gotcha
<jjohansen> zyga: that is a good question, and the answer is it depends
<jdstrand> zyga: I think we are ok cause the content interface is mounting into a very specific place-- either in SNAP, SNAP_COMMON or SNAP_DATA. there shouldn't be anything else in there if we employ the outlined restriction
<jjohansen> some of it, I just don't know. Aliasing attacks via links etc have been pulled off in the past. I think we largely don't have that problem with snappy
<jjohansen> the other thing to worry about the interaction between the different mechanisms providing your policy, which is a combination of namespaces, dac, apparmor, and seccomp
<jdstrand> (snaps can't mount (excepting a few super restricted interfaces that are only allowed to trusted apps))
<zyga> jdstrand: if the overmount interface lands that comfort will go away, e.g. I can connect overmount and then content and then disconnect overmount, given the right (or evil) interfaces that could do some things we weren't expecting
<jdstrand> zyga: I have quite a few concerns with the overmount interface
<jjohansen> they each have their own set of expectations, I think the interaction between apparmor path mediation and mount namespacs is the most problematic
<jjohansen> again its just a matter of making sure your policy is right for the changes
<jdstrand> based on what we said here, I think we are good. we can deal with overmount if/when it comes up for review
<zyga> can you wait 5 more minutes, I will have that debug data
<jdstrand> it is too difficult to think about the policy ramifications of what it could someday do ("it can do anything!" I can't evaluate the impact on policy for 'anything' :)
<zyga> I was looking at loaded profiles and I saw that there were "//null" in the profile names, that made me worries somewhat, are those expected? I don't quite understand how profiles stack or what to make of the profile name
<zyga> (after the reassociation test failure)
<jdstrand> jjohansen: wrt revocation with snap-alter-ns. today we don't revoke so there isn't an issue. with snap-alter-ns, I suspect that zyga will use a lazy umount. do you see problems there?
<jdstrand> zyga: //null is normal when you are in complain mode
<jjohansen> zyga: //null should only ever showup for profiles that are auto-generated during complain mode
<jjohansen> they will either be //null-#### where #### is unique, or //null-executable name
<zyga> dmesg http://paste.ubuntu.com/23789099/
<zyga> kern.log http://paste.ubuntu.com/23789105/
<jdstrand> we got back to talking about two things at once
<zyga> this is the same test with the extra debugging
<jdstrand> we can finish snap-alter-ns if the revocation question is answered
<zyga> ah, sorry, I'm always too impacient
<zyga> [  498.595560] apparmor: clearing unsafe personality bits. /usr/lib/snapd/snap-confine label=snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine
<jjohansen> zyga: so I don't see apparmor directly causing the failure but, it is possible that clearing the unsafe personality bits could lead to an EACCES
<zyga> actually
<zyga> [  498.616822] audit: type=1400 audit(1484259403.009:67): apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> isn't this exactly what I saw?
<zyga> I got errno 13
<zyga> jjohansen: I was reading the log in order, this is the last message
<jdstrand> can we put that on hold? I have a question regarding it that will require discussion
<zyga> sure
<jdstrand> there is but one question remainging...
<jdstrand> jjohansen: wrt revocation with snap-alter-ns. today we don't revoke so there isn't an issue. with snap-alter-ns, I suspect that zyga will use a lazy umount. do you see problems there?
<jjohansen> oh, hrmmm, if there is an ALLOWED it should be toggling the error to 0, the logging does report the initial error
<jjohansen> I am not ruling out that there is a bug around complain mode and disconnected paths
<jjohansen> jdstrand: sure, lazy unmount tringgers disconnected paths
<jdstrand> ah
<jdstrand> zyga: so I'm not sure we can do live revocation well with snap-alter-ns
<zyga> jdstrand: hmm hmm
<jdstrand> zyga: daemons or anything already running in the mount namespace are going to be unhappy
<jjohansen> jdstrand: with that said, if the fd label is cached it should be fine
<zyga> jdstrand: we could ignore that and just carry on (to some extent)
<zyga> jdstrand: we could fail the operation and say "gee, cannot disconnect this thing now" (bad UX perhaps, need to re-do some mounts)
<jdstrand> zyga: I think snap-alter-ns will make connect more robust
<jjohansen> the issue would rear its head if new lookups (openat, ...) are done based off of it, or policy is replaced
<jdstrand> policy gets replaced on connect/disconnect
<jjohansen> jdstrand: well, then we are going to have to spend some time looking at it
<jdstrand> zyga: I like the idea of trying to umount non-lazy. if it fails, it just doesn't get unmounted. it gets removed from the saved file. eventually it is gone
<jjohansen> jdstrand: it will depend on several things, and stacking opens up some avenues that might make it not a problem
<jdstrand> zyga: I think more than that will require tyhicks or ratliff in on the conversation so that scope and priority can be discussed
<jdstrand> jjohansen: ack
<zyga> jdstrand: we could also consider saying "this doesn't work" and having snapd shutdown all the stuff that runs there
<zyga> jdstrand: so in the nice case it just works
<jdstrand> I'm ready to move past revocation if you guys are
<zyga> jdstrand: in the non-nice case it just reliably gets closed
<zyga> I think we need to try it and meet again to discuss what kind of warts remain
<zyga> jjohansen: what do you think?
<jdstrand> zyga: well-- restarting a daemon wouldn't be too bad, but there is no way to restart a non-daemon command that is running
<zyga> jdstrand: ah, correct
<zyga> jdstrand: I didn't consider this
<zyga> jdstrand: we could use cgroups to do this though
<zyga> freeze and kill
<jdstrand> zyga: that said, snap-alter-ns and its way of managing the saved file sounds fine and will make the connect more robust. we can ponder disconnect and defer
<jjohansen> zyga: yeah, meeting again sounds good
<jdstrand> eh
<zyga> jdstrand: sounds good, I think most people will struggle with connect more :)
<jdstrand> I'd be pretty miffed if I lost all my state
<jdstrand> zyga: I do too
<zyga> jdstrand: connect is interactive
<zyga> jdstrand: we could do something smart like "are you *really* sure you want this?"
<jjohansen> zyga: so if you add attach_disconnected to your profile, and test again that should tell us whether the failure is a bug in how apparmor is handling disconnected paths wrt complain mode
<zyga> jjohansen: this is attach_disconnected already I think
<zyga> jjohansen: there are only two profiles at play: (and a hat): snap-confine, base policy all snaps get and the hat in snap-confine
 * zyga checks
<zyga> I have a debug shell so I can experiment if you have ideas
<jjohansen> zyga: nope, you won't get info="Failed name lookup - disconnected path"
<jjohansen> well not unless that is a bug too ...
<jdstrand> zyga: ok, so now my question-- why is snap-confine calling snap to call snap-confine from within the profile? I think the snap command needs to be the thing that sets everything straight. ie, snap can talk to snapd which can notice if the comamnd is running under confinement, then check if the confinement allows calling the command, then fork/exec to call snap itself
<jdstrand> you are focusing on devmode, but I don't know how this is expected to work in strict mode policy-wise
<zyga> jjohansen: snap-confine has that, looking at the generated profile now
<jdstrand> so snapd is a trusted helper
<zyga> jdstrand: this is a feature for CE, in devmode only they need to be able to run a snap command from another snap command, before mount namespace tricks it use to work so they treat it as a regression
<jdstrand> I know that has problems with fds, etc, etc, but so does this method
<zyga> jdstrand: this is only expected to work in devmode (for them)
<zyga> jjohansen: I confirmed that all profiles are attach_disconnected
<zyga> I can pastebin them if you like
<zyga> qemu:ubuntu-16.04-64 .../tests/regression/lp-1644439# cat /sys/kernel/security/apparmor/profiles |pastebinit
<jjohansen> zyga: does /sys/kernel/security/apparmor/policy/raw_data/ exist?
<zyga> http://paste.ubuntu.com/23789168/
<zyga> checking
<zyga> yes
<jdstrand> looking at line 91 and the lines after, I feel like maybe snap-confine is trying to transition to the hat but can't find it
<zyga> but empty
<zyga> jdstrand: note that this is _before_ the hat
<jjohansen> gah, never mind. I've got it. The null child profile is not picking up the flags of the parent, so it is not attach_disconnected
<zyga> jdstrand: the reassociation is done before we even attempt to fork
<jjohansen> zyga: can you open a bug
<zyga> jjohansen: sure, just tell me where
<jdstrand> this is a funky denial: apparmor="ALLOWED" operation="open" info="Failed name lookup - disconnected path" error=-13 profile="snap.test-snapd-tools.cmd//null-/usr/bin/snap//null-/usr/lib/snapd/snap-confine" name="" pid=25299 comm="snap-confine" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<jdstrand> name=""?
<zyga> jjohansen: I can boot other kernels, test anything, this is easy to reproduce
<zyga> well, it doesn't know what the name is
<jjohansen> zyga: drop your failure and log in the bug, open it again linux or apparmor it doesn't really matter
<jdstrand> zyga: do you have a reproducer for jjohansen that doesn't involve spread?
<jjohansen> zyga: name="" means that its going to attach to /
<zyga> jdstrand: spread just runs those few shell commands, all you need to do is to build s-c from that branch and then you can do it easily
<zyga> jjohansen: I'll file one shortly
<jjohansen> disconnected paths don't have a leading / and currently the only connection point is /
<zyga> jdstrand: and this is in qemu,
<zyga> (pretty easy to set up)
<jdstrand> zyga: can you make sure that the bug has very clear instructions for reproducing and building s-c?
<zyga> jdstrand: sure
<zyga> jdstrand: I'll try to simplify it if I can
<zyga> but this is pretty robust, just clone that branch and run spread with a given argument
<jdstrand> zyga: jjohansen is trying very hard to hit a merge window for upstreaming apparmor and he doesn't hack on snap-confine or snapd :)
<zyga> and you have shell in the qemu box :)
<zyga> point taken
<zyga> btw, how is that progressing?
<jjohansen> zyga: I don't need the reproducer, just the bug. I should have a kernel for you in a few hours
<jdstrand> zyga: yeah, don't expect that to be fast for him :) he doesn't have any of that setup. a shell script or .c file demontrating the problem is way better than bootstrapping the snapd dev environment
<zyga> jjohansen: looking forward to that
<jdstrand> sounds like jjohansen has it under control and I've said my bits, so I'm out
<zyga> I'll report the bug now
<zyga> thanks guys, it was good to talk to you again :)
<jdstrand> np
<jdstrand> jjohansen: thanks for all your time! :)
<wililupy> Question: I have a user that built a custom kernel and they are trying to install it with the snap install command but it fails saying it is not signed. They used the --dangerous and equivilent options to no avail. Is there any other command line flags to use when trying to do this?
<zyga> wililupy: you need to build an image with this but I don't believe this option is supported in ubuntu image yet
<kyrofa> zyga, is there no way to use a custom kernel, then?
<wililupy> zyga: Thats what I thought. I told them that and sent them instructions on building a custom image but I also told them I would get a difinitive answer on this as well. Thanks.
<zyga> jmm
<zyga> maybe I'm confusing building an image with devmode snaps and building with a unsigned kernel
 * zyga doen't know
<kyrofa> barry, help?
<wililupy> kyrofa: when I build custom images, I use custom kernels and it works. I never tried snap install kernel.snap but they did and told me what happened.
<kyrofa> wililupy, ah, so ubuntu image _does_ support this?
<kyrofa> wililupy, was the install attempted on classic ubuntu, or in ubuntu core?
<wililupy> kyrofa, yes. in the assertion I use my custom kernel's name value and then use --extra-snaps and the kernel.snap and it builds and runs no problems.
<wililupy> kyrofa: ubuntu-core.
<kyrofa> wililupy, okay good, glad to know that works. barry unping
<kyrofa> wililupy, I kinda feel like you should be able to install --dangerous on core though... otherwise testing a custom kernel is rough, no?
<kyrofa> I wonder about the reason behind that
<wililupy> kyrofa, thats what I thought as well, but they came back saying it didn't work.
<kyrofa> zyga, can you think of why that wouldn't work?
<zyga> sorry, I'm semi off now
<zyga> kyrofa: you probably cannot install a kernel now, not sure
<zyga> you may need to build an image with it
<zyga> but I'm just throwing ideas at 4 minutes past midnigth
 * zyga postpones filing the bug till tomorrow
<zyga> jjohansen, jdstrand: https://bugs.launchpad.net/apparmor/+bug/1656121
<mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:New> <https://launchpad.net/bugs/1656121>
<zyga> please tell me if I should provide more data
<jjohansen> zyga: thanks, I'm just kicking off a kernel build
<mup> PR snapcraft#1046 opened: godeps plugin: work when GOBIN is set <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1046>
#snappy 2017-01-13
<wililupy> This is the specific error they are seeing: http://pastebin.ubuntu.com/23789609/
<nikhilg> Hi, I'm trying to generate 'ubuntu-img' with my kernel-snap
<nikhilg> sudo ubuntu-image -o cumulus-snappy.img --extra-snaps snappygenerickernel_4.4.0_amd64.snap pc-amd64-model.assertion
<nikhilg> I get the following error
<nikhilg> error: unknown flag `extra-snaps'
<nikhilg> COMMAND FAILED: snap prepare-image --extra-snaps=snappygenerickernel_4.4.0_amd64.snap pc-amd64-model.assertion /tmp/tmpm30zktj9/unpack
<nikhilg> any suggestion would be really helpful
<jjohansen> zyga: http://people.canonical.com/~jj/lp1656121/
<mup> PR snapcraft#1046 closed: godeps plugin: work when GOBIN is set <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1046>
<mup> PR snapcraft#1047 opened: meta: support core libraries <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1047>
<zyga> jjohansen: thank you for the kernel, I'm trying it as we speak
<mup> Issue snapd#2625 opened: feature request: ability to talk to sysctl <Created by battlemidget> <https://github.com/snapcore/snapd/issue/2625>
<Matthias___> Hi guys! Just playing around with snappy core on my Raspberry Pi3.
<seb128> zyga, mvo, hey, did you notice that snap-confine has a xenial SRU stucked since novembrer waiting on a bug verification?
<Matthias___> I have an issue with plugs and slots in combination with the snap hugo (or even in general). Is there someone out there to help a bit?
<davmor2> Matthias___: I would describe your issue and then see if anyone is able to help
<mvo> seb128: I wasn't aware of this but its probably superseeded by name, no?
<mvo> seb128: the binary snap-confine is now build by snapd itself
<seb128> mvo, oh ok, so maybe that SRU should be deleted?
<mvo> seb128: yes
<seb128> mvo, zyga, can one of you let the SRU know about that then?
<morphis> ogra_, mvo: was there any movement recently on getting groups like lxd created on Ubuntu Core systems?
<mup> PR snapd#2626 opened: interfaces: relax path requirments for serial <Created by jocave> <https://github.com/snapcore/snapd/pull/2626>
<mup> PR snapcraft#1048 opened: bdocs: update deprecation links <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1048>
<ogra_> morphis, i worked on it and then got distracted by the GLES stuff
<ogra_> (see the bug, i attached a first patch)
<ogra_> morphis, i'll move on with it next week if thats ok for you
<morphis> ogra_: hm, currently don't find the bug anymore, you have a link handy?
<Matthias___> I have an issue: I am using Ubuntu Core 16.04.1 on a Raspberry Pi3.
<Matthias___> I am also using the hugo snap 0.18.1 on this system
<Matthias___> With hugo installed I am not able to access my home directory where my web site should be generated.
<Matthias___> Because the interfaces hugo is using are: Slot           Plug :network-bind  hugo,nextcloud,snapweb -              hugo:home
<Matthias___> Sofar so good. Now I thought that I just need to connect the slot home of my core system with the plug of hugo:home.
<Matthias___> snap connect hugo:home core:home
<Matthias___> The interfaces situation changed to: Slot           Plug :home          hugo
<Matthias___> But still hugo can not do anything on my home location.
<Matthias___> Any idea?
<oSoMoN> if I claimed a reserved name in the store, how can I check the status of my request? who reviews and makes decisions?
<mup> PR snapcraft#1047 closed: meta: support core libraries <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1047>
<mup> PR snapcraft#1048 closed: bdocs: update deprecation links <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1048>
<ogra_> morphis, bug 1647333
<mup> Bug #1647333: adduser misses extrausers support for group management <patch> <Snappy:New> <adduser (Ubuntu):Confirmed> <shadow (Ubuntu):In Progress by ogra> <https://launchpad.net/bugs/1647333>
<morphis> ogra_: thanks
<morphis> ogra_: and how would this be triggered from a snap?
<ogra_> it wouldnt
<ogra_> no idea how a user/grooup management interface would look like, i just make sure the low level works at all ... the rest is interface stuff in snapd
<ogra_> building such an interface today would simply not work, the extrausers setup has no concept of group mgmt at all today (only at user creadion a user group gets created, adding, removing and managing is not implemented)
<ogra_> (we simply never needed it on phones)
<ogra_> at least gpasswd and adduser itself still need additional patches for this to work
<Matthias___> Ok guys, I found my mistake. The command to connect the home directory needs to be:
<Matthias___> snap connect hugo:home :home
<Matthias___> I thought I had to put "core" infront of home. Now it works.
<Matthias___> Still a bit strange.
<mup> PR snapcraft#1049 opened: Release changelog for 2.25 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1049>
<mup> PR snapd#2627 opened: daemon: make activation optional <Created by chipaca> <https://github.com/snapcore/snapd/pull/2627>
<mardy> is it possible to use stage-packages but avoid installing all dependencies?
<ogra_> hard dependencies are always installed i dont think you can get around this
<ogra_> likewise recommends are always suppressed
<Matthias___> Have a nice day, I am leaving for today.
<mardy> ogra_: thanks
<mardy> oSoMoN: hi! In your post about the snapification of webbrowser-app you mentioned that there's a known bug in snapcraft where ldd is used to fetch dependencies regardless of the libs provided by ubuntu-app-platform; do you have a bug number?
<mup> PR snapd#2628 opened: many: (mis)feature/no more snapd.socket <Created by mvo5> <https://github.com/snapcore/snapd/pull/2628>
<oSoMoN> mardy, https://bugs.launchpad.net/snapcraft/+bug/1587358
<mup> Bug #1587358: Pack wrong libraries into snap <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1587358>
<oSoMoN> mardy, thatâs not quite as IÂ initially reported it, but my issue was folded into that bug report
<oSoMoN> mardy, however thereâs a reliable workaround for the issue:Â add back stage packages for the libs that snapcraft chooses to add, and exclude their files
<oSoMoN> mardy, this way snapcraft will acknowledge that the libs are being included (even though you can still exclude them from the resulting snap), so it wonât force their addition
<mardy> oSoMoN: to make sure I understood it right: I should explicitly list all the stage-packages dependencies in stage-packages, and then use exclude rules to remove their files?
<oSoMoN> mardy, yes, although you donât need all the stage packages, only the one that contain the libs that otherwise would be pulled in by snapcraft
<oSoMoN> the ones*
<oSoMoN> mardy, typically you donât need packages for qml modules, are those are loaded dynamically, not linked to your executables
<mardy> oSoMoN: ah, got it!
<mardy> thanks!
<oSoMoN> yw
<oSoMoN> popey, do you know who handles the requests to claim a reserved name in the snap store?
<mup> PR snapcraft#1049 closed: Release changelog for 2.25 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1049>
<mup> PR snapd#2629 opened: interfaces: allow reading installed files from previous revisions by default <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2629>
<jdstrand> ogra_: hey-- thanks for the upload of linux-generic-bbb to edge. I notice that r8 is in edge, r7 in beta and r6 in stable. do you recommend I follow edge?
<ogra_> jdstrand, ah, sorry, i havent pushed it to the other channels yet
<jdstrand> ogra_: I promise I'm not trying to be a pest. it seems that the review tools allowed it (there was a fast turn around on the store pull yesterday)
<ogra_> it is definitely in ...
<jdstrand> it is in. I just don't know if you poked someone or if it was automatic
 * jdstrand checks the log
<ogra_> i triggered the build ...
<ogra_> thats all
<jdstrand> OK (override 'linux-generic-bbb' for 'type: kernel') lint-snap-v2_snap_type_redflag
<jdstrand> and it is at r824. cool
<ogra_> the rest seems to have been automatic ..
<jdstrand> 'it' being the review tools
<jdstrand> perfect. that was the goal :)
<ogra_> and i just pushed it to all channels
 * jdstrand hugs ogra_ :)
<ogra_> well, thanks for the ping, i would have forgotten about it
<jdstrand> :)
<mup> PR snapd#2549 opened: cmd/snap-confine: add shutdown helper <Created by chipaca> <https://github.com/snapcore/snapd/pull/2549>
<Trevinho> jdstrand: hey, shouldn't this be the case https://bugs.launchpad.net/snap-confine/+bug/1620442/comments/9 ?
<mup> Bug #1620442: snap fails because XDG_RUNTIME_DIR is set to /run/user/1000 <snapd-interface> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1620442>
<zyga> Trevinho: this was reverted
<zyga> Trevinho: the fix was partially incorrect, I'll get back to it after some other snap-confine work
<Trevinho> zyga: mhmhmhmhmmh, soooooo.... I should expect that var not to be set again?
<Trevinho> zyga: That's on xenial's snapd
<Trevinho> and I'd like to use that path for some temporary data that the classic os should be able to read
<zyga> it's not going to exist, it will be set but should be unusable for now
<rvr> mvo: Have you seen anything similar to this errors before? http://paste.ubuntu.com/23792712/
<Trevinho> zyga: When creating it it currently works...
<zyga> Trevinho: right, the part that was reverted was the mkdir-like code that created the directory on app startup
<Trevinho> zyga: ah, ok.. and is that going to be readded, though... Right?
<jdstrand> Trevinho: it should be. zyga removed the PR to snap-confine (before 2.20 release) that did that since he was changing some other bits and wanted to get those sorted first. AIUI, he was going to add it back at some point
<jdstrand> ah, heh
<zyga> jdstrand: yes, we'll add it back after snap-alter-ns I suspect
<Trevinho> so... I'm opening a bug and assignging that to zyga then :-)
<zyga> jdstrand: I'm doing small clean-ups and I wanted to resurrect the improved mkdir code and then use it it
<zyga> yep, thank you
 * jdstrand nods
<snappy_beginner> Hi all
<jdstrand> zyga: note that bug #1656289 is being discussed on the list. I assigned to you so you'd see the bug email, but feel free to adjust
<mup> Bug #1656289: [Regression] 2.20.1ubuntu1 breaks snaps that use ALSA <regression-update> <snapd (Ubuntu):New for zyga> <https://launchpad.net/bugs/1656289>
<mup> PR snapd#2627 closed: daemon: make activation optional <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2627>
<mup> PR snapd#2629 closed: interfaces: allow reading installed files from previous revisions by default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2629>
<snappy_beginner> I would like to ask a question regarding plugging into a specific interface. I've read few papers about ubuntu core/apparmor/seccomp
<snappy_beginner> but I'm stuck with connection to specific interface
<zyga> jdstrand: thanks, I'll check it out soon
<snappy_beginner> which is: "kernel-module-control"
<zyga> I was out most of the day, my laptop needed to be delivered to a service center and I took some time off to walk aroudn
<jdstrand> zyga: this only just came up
<snappy_beginner> do you know guys if it is super prohibited interface ? I'm unable to install app that plugs into this i-face
<jdstrand> so, no worries
<jdstrand> snappy_beginner: it is super-privileged
<snappy_beginner> Ok.
<snappy_beginner> sudoer could install such app then?
<zyga> jdstrand: ALSA lib conf.c:3759:(snd_config_update_r) Cannot access file /usr/share/alsa/alsa.conf -- this looks like core snap change if nothing else
<jdstrand> snappy_beginner: as such it needs something called a snap declaration in the store to allow installation via the store. however, newer snapd (I think 2.20) allows local installs to work when installing with --dangerous
 * zyga looks at email
<jdstrand> zyga: the core snap should never have had that file
<Trevinho> zyga: I can't assign it to you it seems, but... here it is https://bugs.launchpad.net/snapd/+bug/1656340
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <snapd:Confirmed> <https://launchpad.net/bugs/1656340>
<jdstrand> zyga: but perhaps it did...
<snappy_beginner> jdstrand: yes, I'm trying to install it locally with devmode and dangerouse switches
<snappy_beginner> :)
<jdstrand> snappy_beginner: what version of snapd do you have installed?
<ogra_> zyga, there has never been any alsa in the core snap
<ogra_> (and there likely wont be)
<snappy_beginner> 2.16
<snappy_beginner> (jdstrand: 2.16
<jdstrand> snappy_beginner: upgrade to 2.20 and it will be installable with --dangerous
<snappy_beginner> Oh yeah
<snappy_beginner> thanks jdstrand
<snappy_beginner> btw: I would have another question then.
<snappy_beginner> suppose I'm device owner and it has already kernel module up and running - I can connect to it and it is operable.
<snappy_beginner> Is it a great effort to create the interface from a scratch?
<snappy_beginner> I mean, it would be similar to 'tpm' which is already ready to use
<jdstrand> snappy_beginner: no. look at the recent openvswitch-support interface
<jdstrand> snappy_beginner: all it does is ask snapd to load the openvswitch module
<snappy_beginner> ok
<jdstrand> snappy_beginner: I might point out a coupel of things. many modules autoload when you try to access the kernel functionality, so you don't need an interface like this. a few do, like openvswitch and ip6table_filter and iptable_filter, so there are interfaces for those
<snappy_beginner> ok ok
<snappy_beginner> jdstrand: last question
<jdstrand> snappy_beginner: 2nd, depending on what your project is, you might be able to have your own kernel snap. I think (perhaps this is a future thing), the gadget snap will allow you to have certain modules loaded (ogra_, do you know otoh?)
<snappy_beginner> this module is already there
<snappy_beginner> on the snappy ubuntu
<ogra_> well, you could ship an /etc/modules-load.d file in the gadget
<snappy_beginner> thats why I want from my app to plug into kernel-module-control i-face
<jdstrand> ah, there you go
<snappy_beginner> and if I;m understanding this correctly, my app will get access over apparmor and seccomp to specific device which requires privileged access?
<ogra_> through an interface, yes
<snappy_beginner> great
<snappy_beginner> it is awesome.
<snappy_beginner> really
<jdstrand> snappy_beginner: kernel-module-control gives device ownership to the snap since it can modify how the kernel behaves, including disabling all security policy. its use is strongly discouraged which is why the other methods exist. having an interface that asks snapd to load it is safe. having the gadget ensure it is loaded is safe. letting a snap load any modules into the kernel places ultimate trust in that snap
<snappy_beginner> it sounds logic
<jdstrand> some things obviously need kernel-module-control. eg, a livepatch snap
<snappy_beginner> jdstrand: so anyway. the ultimate conclusion is: I should provide new interface over a gadget that can send i/o to this specific kernel module right?
<jdstrand> so snapd regulates kernel-module-control. unsigned installs (ie, using --dangerous) you're free to do what you want of course
<jdstrand> snappy_beginner: the gadget doesn't need an interface. the gadget is there to configure things for the system/device. ogra_ mentioned it is allowed to drop a file in /etc/modules-load.d. put the name of your module in there and create an image using your gadget and install on the device and your set
<snappy_beginner> ah ok
<snappy_beginner> understand
<jdstrand> snappy_beginner: an interface is only needed if you want an 'app snap' to ask snapd to load the module for you
<ogra_> well, you can define interfaces in the gadget.yaml file too
<jdstrand> snappy_beginner: and how snapd does that is dropping a file into /etc/modules-load.d
<jdstrand> ogra_: fair point
<snappy_beginner> Ok
<jdstrand> if an interface is defined, the gadget could use it. if it isn't, it can put a file in /etc/modules-load.d
<jdstrand> snappy_beginner: mind saying which module it is?
<ogra_> you can even do both ;)
<snappy_beginner>  it is /dev/mei :)
<ogra_> force the module to be permanently loaded ... use an interface for device access management
<snappy_beginner> and this one requires the accessing process to be privileged
<jdstrand> snappy_beginner: that sounds like it would be good for an interface actually. you create a PR that loads the kernel module, and then add accesses to allow using it in the security policy
<jdstrand> snappy_beginner: see openvswitch-support for the former and io-ports-control for the latter
<snappy_beginner> So I'm thinking on how it should be implemented in the new security fashion of ubuntu core
<snappy_beginner> the module is already loaded
<jdstrand> if you are implementing this, reference https://www.kernel.org/doc/Documentation/misc-devices/mei/mei.txt. we can iterate on the contents of the security policy in the pr
<mup> Issue # closed: snapd#2484, snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2568, snapd#2569, snapd#2572, snapd#2576, snapd#2594, snapd#2603, snapd#2625
<mup> PR # closed: snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2277, snapd#2302, snapd#2328, snapd#2347, snapd#2359, snapd#2360, snapd#2368, snapd#2392, snapd#2397, snapd#2407, snapd#2411, snapd#2416, snapd#2417, snapd#2421, snapd#2448, snapd#2449, snapd#2475, snapd#2477,
<mup> snapd#2482, snapd#2488, snapd#2513, snapd#2515, snapd#2524, snapd#2528, snapd#2529, snapd#2542, snapd#2545, snapd#2546, snapd#2549, snapd#2558, snapd#2570, snapd#2575, snapd#2579, snapd#2581, snapd#2583, snapd#2585, snapd#2586, snapd#2588, snapd#2591, snapd#2592, snapd#2595, snapd#2596, snapd#2600,
<mup> snapd#2604, snapd#2613, snapd#2622, snapd#2623, snapd#2624, snapd#2626, snapd#2628
<genii> hm
<mup> Issue # opened: snapd#2484, snapd#2514, snapd#2541, snapd#2552, snapd#2553, snapd#2568, snapd#2569, snapd#2572, snapd#2576, snapd#2594, snapd#2603, snapd#2625
<mup> PR # opened: snapd#2226, snapd#2230, snapd#2236, snapd#2251, snapd#2256, snapd#2277, snapd#2302, snapd#2328, snapd#2347, snapd#2359, snapd#2360, snapd#2368, snapd#2392, snapd#2397, snapd#2407, snapd#2411, snapd#2416, snapd#2417, snapd#2421, snapd#2448, snapd#2449, snapd#2475, snapd#2477,
<mup> snapd#2482, snapd#2488, snapd#2513, snapd#2515, snapd#2524, snapd#2528, snapd#2529, snapd#2542, snapd#2545, snapd#2546, snapd#2549, snapd#2558, snapd#2570, snapd#2575, snapd#2579, snapd#2581, snapd#2583, snapd#2585, snapd#2586, snapd#2588, snapd#2591, snapd#2592, snapd#2595, snapd#2596, snapd#2600,
<mup> snapd#2604, snapd#2613, snapd#2622, snapd#2623, snapd#2624, snapd#2626, snapd#2628
<snappy_beginner> hey folks once again
<snappy_beginner> I do have last question.
<qengho> Ask.
<snappy_beginner> supousedly I will have my own interface in snapd
<qengho> Like this? http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
<snappy_beginner> sorry, got disconnected
<snappy_beginner> so the question was - how to deliver modified snapd to this system abeato when it is read only?
<qengho> Like this? http://www.zygoon.pl/2016/08/creating-your-first-snappy-interface.html
<snappy_beginner> thanks :P
<snappy_beginner> oh
<zyga> snappy_beginner: merge it upstream
<zyga> snappy_beginner: that's the only way
<zyga> snappy_beginner: we will happily take contributions
<zyga> I should write a 2nd version of that blog post soon
<qengho> sorry, zyga.
<snappy_beginner> zyga: I will be more than happy to contribute ;)
<zyga> qengho: about what?
 * zyga was referring to the new interface APIs that are slowly happening next week
<qengho> zyga: for referring someone to something you feel you must rewrite.
<zyga> qengho: that blog post is accurate for now
<zyga> qengho: I just realized that with the patches I've been working on this week it will get out of date
<qengho> Ah.
<zyga> qengho: I'll document it on the wiki so that it is easier to keep up-to-date
<zyga> and I cannot wait to see the new APIs in place, it will be much easier to write an interface :)
<mup> PR snapd#2595 closed: daemon: re-enable reexec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2595>
<mhall119> zyga: does the configure hook get run before or after the daemons are started?
<zyga> mhall119: after
<zyga> AFAIK
<mhall119> is there anything that runs before? I need to create a config file before the service starts
<mhall119> zyga: or is there a way to restart the daemon from within the hook?
<zyga> mhall119: no
<zyga> mhall119: no
<zyga> sorry :/
<mhall119> zyga: hey, so this is fun: http://paste.ubuntu.com/23793926/
<mhall119> jdstrand: this one's for you, the snappy-debug scanlog advises me to use plugs I'm already using: http://paste.ubuntu.com/23793938/
<zyga> mhall119: is there any apparmor or seccomp denial?
<zyga> mhall119: the hook is not using those
<mhall119> zyga: the apparmor denials in that second pastebin
<jdstrand> mhall119: are they connected?
<jdstrand> mhall119: snap interfaces
<mhall119> jdstrand: not sure, the install fails because of what I pasted to zyga
<jdstrand> mhall119: I really doubt transmission would need 'network-control'
<zyga> mhall119: I bet that the hook doesn't have those (see snapcraft.yaml) and thus cannot work
<jdstrand> mhall119: mount-observe and network-control are not auto-connected
<mhall119> zyga: ah, snapcraft doesn't like the hooks: section, I'll try adding it to snap.yaml
<zyga> mhall119: I don't know about that, sorry
<zyga> mhall119: and there's also a bug in golang that causes all the hooks to require network-bind
<zyga> mhall119: it's tracked but I don't recall the URL now
<zyga> mhall119: and because snapctl is implemented in golang all the hooks are affected
<kgunn> ogra_: it's still correct that pulse audio doesnt' work right?
<kgunn> re kodi, it'd only be good for silent movies atm :)
<mcphail> Hmm. I thought I had PA working in a game I snapped a while ago, in dosbox...
<mup> PR snapd#2630 opened: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
 * zyga EODs
<mup> PR snapd#2631 opened: releasing package snapd version 2.21 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2631>
<mhall119> zyga: jdstrand: anything I can do about this:
<mhall119> = Seccomp =
<mhall119> Time: Jan 13 15:56:45
<mhall119> Log: auid=4294967295 uid=0 gid=0 ses=4294967295 pid=25360 comm="transmission-da" exe="/snap/ubuntu-desktop-seed/x3/usr/bin/transmission-daemon" sig=31 arch=c000003e 179(quotactl) compat=0 ip=0x7f301989b0ca code=0x0
<mhall119> Syscall: quotactl
<jdstrand> there is a bug on that. for transmission in particular
 * jdstrand finds it
<jdstrand> mhall119: https://bugs.launchpad.net/snappy/+bug/1626359. See comment #1. I'm actually working on seccomp arg filtering policy as we speak and this is one of the things I'm going to fix
<mup> Bug #1626359: Cannot authorise quotactl syscall for Q_GETQUOTA <snapd-interface> <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1626359>
<jdstrand> mhall119: to work around it, add quotactl to /var/lib/snapd/seccomp/profiles/snap.your.thing
<jdstrand> mhall119: if yoy install/remove/refresh you will have to add it back
<mhall119> thanks jdstrand, that fixes my last issue
<skri> hi
<skri> I am looking for help: how can I provide multiple executibles in a snap?
<skri> executables*
<mhall119> skri: the apps: section of your snapcraft.yaml can have multiple entries, one for each executab;e
<mhall119> skri: see "Apps and commands" section here: http://snapcraft.io/docs/build-snaps/syntax
<mhall119> http://snapcraft.io/docs/build-snaps/metadata has some examples of doing this
<skri> mhal119: thank you, but I am missing something because I get an error: Issues while validating snapcraft.yaml: The 'apps' property does not match the required schema: Additional properties are not allowed
<mhall119> skri: sounds like a simple syntax error somewhere, can you put your snapcraft.yaml on paste.ubuntu.com?
<skri> mhall119: I uploaded it to pastebin http://pastebin.com/8mRk0A1W
<mhall119> skri: hmmm, you may not be able to have periods in your app name
<skri> oooh
<skri> that is not so good news :-(
<mhall119> also, python and pip aren't going to do much for you in strict confinement, are you aware of the new "classic" interface?
<skri> thanks for your help, mhall119!
<skri> no, I am not
<skri> I am still learning snappy
<mhall119> ok, so "classic" was introduced to support things that don't make sense to run in strict confinement
<skri> I wanted to have an easily deployable python build
<mhall119> I'm not sure the new documentation for "classic" has even been published yet...
<skri> I was imagining that I could tell pip to use the workspace provided by snappy somehow
<mhall119> snaps are usually aimed at "leaf" applications, which can be confineed and self-contained
<mhall119> but in confinement they can't read or write to the rest of the filesystem, which python and pip would certainly need to do
<mhall119> classic confinement will let them do that
<mhall119> I *think* all you have to do is switch your line 4 to confinement: classic
<mhall119> but zyga (already off for the day) can give more info tomorrow if you're around earlier
<mhall119> ah, we did published the new docs: http://snapcraft.io/docs/reference/confinement
<skri> sounds like a simple change, thanks :-)
<skri> I wanted to move in small steps and get some i/o error from python or something
<skri> it seems from the confinement docs that even in strict confinement the global path /var/snap/<snap>/common and the user-specific path /home/$USER/snap/<snap>/common are both writable in strict confinement
<kyrofa> skri, indeed, SNAP_DATA and SNAP_USER_DATA are always writable, even in strict comfinement
<kyrofa> As are SNAP_COMMON and SNAP_USER_COMMON
<skri> so, I managed to finally create a simple python snap
<skri> lessons learnt: 1. no points in identifiers 2. plugins != plugin
<skri> the second one took a while
<skri> I can start the python interpreter in strict confinement
<skri> maybe this'll be enough
<skri> thanks for the help from mhall119 and kyrofa
#snappy 2017-01-14
<mup> PR snapcraft#1050 opened: repo: add multiarch support for stage packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1050>
<stokachu> if i want to include a remote part without making any changes whats the right syntax for that?
<stokachu> like i want to include the juju part from https://wiki.ubuntu.com/snapcraft/parts as is
<stokachu> does it need like a plugin: false or something similar?
<stokachu> ah maybe 'after' is what i want?
<stokachu> will try that
<DonAlex> Hey all.
<DonAlex> Anyone knows how I can get things like other filesystems into ubuntu core? It is missing both xfs and btrfs. There does not seem to be any way to do it via snaps so...?
<ogra_> the kernel should care on its own if you access a disk with such a filesystem
<ogra_> and beyond that ....
<ogra_> ogra@pi3:~$ sudo modprobe btrfs
<ogra_> ogra@pi3:~$ dmesg|grep Btrfs
<ogra_> [ 7123.194582] Btrfs loaded
<ogra_> ogra@pi3:~$
<stokachu> if you echo $HOME inside a classic snap it doesn't point to the users $HOME but to $HOME/snap/<application>/x7
<stokachu> is that expected?
<mup> Issue snapd#2632 opened: classic snap $HOME reported incorrectly <Created by battlemidget> <https://github.com/snapcore/snapd/issue/2632>
<stokachu> zyga, im online to re that classic snap $HOME bug
<Quacky2200> Hey guys, I have an error when trying to build a 32 bit snap on 64 bit with electron-builder "Building for a different target architecture requires a plugin specific implementation in the 'desktop-glib-only' plugin"
<mup> Issue snapd#2632 closed: classic snap $HOME reported incorrectly <Created by battlemidget> <Closed by battlemidget> <https://github.com/snapcore/snapd/issue/2632>
<mup> Issue snapd#2632 opened: classic snap $HOME reported incorrectly <Created by battlemidget> <https://github.com/snapcore/snapd/issue/2632>
<Frigid_Cryotank> If someone here is doing work on an Intel Joule, I've got a couple of questions.  Like... if you're using the i2c interface, which library are you using to access it?
<mup> Issue snapd#2632 closed: classic snap $HOME reported incorrectly <Created by battlemidget> <Closed by battlemidget> <https://github.com/snapcore/snapd/issue/2632>
<DonAlex> Yes.. but how do I install or access btrfs-tools then?
<DonAlex> or xfs-tools?
#snappy 2017-01-15
<mup> Bug #1641960 changed: Unable to locate package snapd in Debian RPi <Snappy:Expired> <https://launchpad.net/bugs/1641960>
<mwhudson> zyga: ayt?
<olympionex> according to the online documentation at snapcraft.io, it looks like the new standard for defining a custom plugin is to use the x-plugin.yaml to define the options for the plugin.  This does not seem to be working for me with snapcraft v 2.24. I get a 'properties failed to load' error.
#snappy 2018-01-08
<mborzecki> morning
<mup> PR snapcraft#1852 opened: Added a missing step in Hacking.md <Created by Tanesh1701> <https://github.com/snapcore/snapcraft/pull/1852>
<zyga-ubuntu> o/
<mvo> hey zyga-ubuntu, good monring
<zyga-ubuntu> hey :)
<mup> PR core#68 closed: hooks: fix shellcheck complains <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/68>
<mborzecki> zyga-ubuntu: mvo: morning guys
<zyga-ubuntu> good morning
<kalikiana> morning, zyga-ubuntu
<zyga-ubuntu> hey :)
 * zyga-ubuntu had a fsck-initramfs-based-morning 
<zyga-ubuntu> but all is good now, I hope
<kalikiana> not how you wanna start your day... :-(
<mup> PR snapd#4449 opened: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4449>
<mvo> hey mborzecki - good morning and good morning kalikiana
<mborzecki> kalikiana: morning
<kalikiana> mborzecki: mvo o/
<zyga-ubuntu> gconstpointer ?
<zyga-ubuntu> why do we need that over, apparently, bool?
<zyga-ubuntu> ah, could be the limitation of the test protocol
<mborzecki> zyga-ubuntu: just following gtest declarations and didn't want the compiler to scream at me
<zyga-ubuntu> I think I would have preferred a debug library but this change is smaller, +1
<mborzecki> zyga-ubuntu: thanks
<mborzecki> zyga-ubuntu: have you seen this? https://forum.snapcraft.io/t/on-arch-snaps-show-broken-after-switch-from-snapd-to-snapd-git/3427/4
<mborzecki> pstolowski: morning
<zyga-ubuntu> mborzecki: no, I just had a look now - my bet is it's a mount from some directory that dones't exist on arch in default install, maybe /usr/src or something like
<zyga-ubuntu> ...that
<zyga-ubuntu> if you can strace it you will get the answer
<zyga-ubuntu> mborzecki: btw, does it work for you?
<mborzecki> zyga-ubuntu: hm but what fails is: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory
<zyga-ubuntu> mborzecki: or also no?
<mborzecki> yes, it does
<zyga-ubuntu> that's odd, is the source/target present?
<mborzecki> it would be off for /dev not to exist
<mborzecki> lookign at snap-confine source code, we create the destination directory
<mborzecki> aah, w8, we create the destination only it's it's bidirectional
<mup> PR snapcraft#1853 opened: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
<zyga-ubuntu> hmm
<zyga-ubuntu> that feels like a bug
<zyga-ubuntu> but
<zyga-ubuntu> .. /dev should be in the core snap
<mvo> zyga-ubuntu: it is
<haisheng-from-ch> Hi, I met a question about snapd. I make a pc.img which use ubuntu-img command. But when i log into the system. the snap can't mount, ant the syslog print:'Jan  5 08:10:49 localhost snapd[889]: 2018/01/05 08:10:49.391477 stateengine.go:101: state ensure error: devicemgr: cannot mark boot successful: cannot determine bootloader' many times. what should i do. Thanks.
<zyga-ubuntu> haisheng-from-ch: hey, which gadget/kernel/model did you use?
<haisheng-from-ch> also when start the system . the screen print 'Mounting Mount unit for core.Mounted Mount unit for core. Unmounted Mount unit for core. ' many times.
<mborzecki> i'll try to spin a manjaro vm locally and check what's happenning there
<ackkk> mvo, hi! wrt that changes to base-18 you made on Fri, are they available in the latest build yet?
<mvo> ackk: I checked https://code.launchpad.net/~mvo/+snap/base-18 this morning - and it still has not build :( so we probably need to ask in #launchpad what is going on
<ackk> I guess the few builders availble are hammered
<zyga-ubuntu> ackk: what's wrong with the build farm?
<haisheng-from-ch> kernel is 1604. gadget is the sample which provided in website.the model is customized by myself.
<haisheng-from-ch> the model is '{
<haisheng-from-ch>   "type": "model",
<haisheng-from-ch>   "authority-id": "9go0hDakgpo17fYGy06ZguLT8Ly0Ma9F",
<haisheng-from-ch>   "brand-id": "9go0hDakgpo17fYGy06ZguLT8Ly0Ma9F",
<haisheng-from-ch>   "series": "16",
<haisheng-from-ch>   "model": "kylin-test",
<haisheng-from-ch>   "architecture": "amd64",
<haisheng-from-ch>   "gadget": "kylin-gadget",
<haisheng-from-ch>   "kernel": "pc-kernel",
<haisheng-from-ch>   "timestamp": "2018-01-08T06:23:22+00:00"
<haisheng-from-ch> }
<haisheng-from-ch> '
<ackk> zyga-ubuntu, it was shutdown because of meltdown/spectre, only whitelisted projects are built
<ackk> zyga-ubuntu, so no PPA and snap builds
<zyga-ubuntu> aaah
<zyga-ubuntu> makes sense
<mvo> ackk: maybe we are not in that whitelist
 * zyga-ubuntu uses his GPU to heat up the room
<ackk> mvo, yeah you should ask about it, I know other teams did
<zyga-ubuntu> darn it's a cold day today
<haisheng-from-ch> hi, zyga-ubuntu, any info can be provieded for me about this error?
<zyga-ubuntu> haisheng-from-ch: not immediately, I work on core snapd but how it combines with reference gadgets and ubuntu image is complex; perhaps ask ogra_ as he's closer to that layer
<zyga-ubuntu> it's best to open a forum topic
<zyga-ubuntu> include all the details: which ubuntu-image you've used, how did you boot it, etc
<haisheng-from-ch> ok thanks.
<mup> PR snapd#4450 opened: snap: support `command-not-found` symlink for `snap advise-command` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4450>
<ackk> mvo, so with your latest changes you were able to get a working maas snap installed, right?
<mvo> ackk: yeah, it was not getting past "intializing" though
<mvo> ackk: fwiw, I ask on #launchpad about the build but I guess tricky TZ wise currently
<mvo> ackk: to get answers
<ackk> mvo, cool. could you pass me the snap for the base so i can try locally (see if I can actually get maas to work)
<mvo> ackk: sure, let me try a cleanbuild for you
<ackk> mvo, you might want to try #launchpad-ops
<zyga-ubuntu> hey Chipaca
<Chipaca> zyga-ubuntu: o/
<Chipaca> zyga-ubuntu: over the weekend i might've gone all "here's a nickel, kid" on somebody's distro
<zyga-ubuntu> Chipaca: sorry, the analogy eludes me
<Chipaca> zyga-ubuntu: http://assets.amuniversal.com/6b08abb09fbb012f2fe600163e41dd5b
<zyga-ubuntu> Chipaca: are you saying you tried a bunch of distros?
<zyga-ubuntu> haha
<Chipaca> zyga-ubuntu: in particular, https://forum.snapcraft.io/t/cannot-comunicate-with-server-mx-linux-17/3455/2
<kalikiana> elopio: you're awake?
<mup> PR core#70 opened: hooks: use symlink to run `snap advise-command` <Created by mvo5> <https://github.com/snapcore/core/pull/70>
<Chipaca> kalikiana: it's 3am in .cr
<kalikiana> Chipaca: Well, it didn't seem to stop him from pushing code to GitHub, that's why I'm asking
<Chipaca> ah
<Chipaca> kalikiana: i read it as a "are you awake", not as "wtf you awake"
<Chipaca> :)
<kalikiana> :-D
<kalikiana> English is so ambiguous when you don't use properly foul language
<Chipaca> well i could've also been unambiguouss without being lazy, but i'm lazy
 * zyga-ubuntu crosses fingers
<mborzecki> TIL manjaro has a user friendly installer
<zyga-ubuntu> is it just me or has the lower temperature brought much higher pressure
<zyga-ubuntu> I don't feel sleepy like I did all last week
<Chipaca> mvo: you around?
<mvo> Chipaca: yes, good morning!
<Chipaca> mvo: good morning! what are my chances of you finishing your review of #4394?
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<mvo> Chipaca: *cough* I let you wait long enough - I do that now as in right now
<Chipaca> :-D
 * kalikiana coffee break
<Chipaca> note fedora tests are disabled again
<mborzecki> btw. i actuallt hit the same problem as the spread tests did when updating my wife's fedora on friday
<Chipaca> mborzecki: which problem?
<Chipaca> mborzecki: or rather, which of the problems? :-)
<mborzecki> Chipaca: failure to downlaod from updates repo
<Chipaca> ah
<Chipaca> mborzecki: i've also seen (in the tests) fedora not having 'snap' in the path, and fedora's systemd not knowing about snapd.service
<Chipaca> that's the point i disabled the test again
<Chipaca> (after re-running them ~6 times because of the repo thing)
<mborzecki> that's interesting, was it reproducible?
<Chipaca> something's very broken, needs fixing, but beyond me atm
<Chipaca> mborzecki: afaik it was just the once, but it was just the breaking point
<mborzecki> haha ok :)
<Chipaca> that is, i had about 6 runs of it breaking because of the repo thing
<Chipaca> then it didn't break because of the repo and instead didn't know about snapd
<Chipaca> or the service
<Chipaca> (different instances of fedora in the same run)
<mborzecki> well f26 was to be switched to manual anyway, hoping we could get the f27 PR merged soon
<Chipaca> so, (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<Chipaca> ok, off to physio for me
 * Chipaca bbi1h
<mborzecki> hmm installed snapd-git on clean manjaro .. and it's broken, seems like snap mount dir is /var/lib/snapd/snap, but there's only /snap in the system, /var/lib/snapd/snap does not exist
<mborzecki> zyga-ubuntu: any idea who i can talk to about this?
<zyga-ubuntu> mborzecki: so which of the two layouts would manjro prefer?
<mborzecki> idk, seems like they're undecided
 * kalikiana moving to coffee shop, brb
<mborzecki> so i managed to get:
<mborzecki> Name         Version  Rev   Developer  Notes
<mborzecki> core                  3748  canonical  broken
<mborzecki> hello-world           27    canonical  broken
<mborzecki> on manjaro
<zyga-ubuntu> mborzecki: what's the configuration there/
<zyga-ubuntu> mborzecki: did it reexec
<zyga-ubuntu> mborzecki: is it using /snap or /var/lib/snapd/snap?
<mborzecki> yeah, it's using /var/lib/snapd/snap
<mborzecki> looks like the manjaro `community` repo pacakaes do not do a proper cleanup when removing
<zyga-ubuntu> ahh
<zyga-ubuntu> that's not catastrophic
<mborzecki> there's bits and pieces left behind, one of those is mounted snaps
<mborzecki> and for some reason i ended up having `hello-world` in /var/lib/snapd/snap but there's no core
<mborzecki> uhh, taje that back, there's 'hello-world' in /snap but no 'core'
<zyga-ubuntu> mborzecki: what if you start from scratch on a clean manjaro system
<zyga-ubuntu> is it still broken then?
<mborzecki> i had a clean system, then installed snapd-git, but apaprently they have snapd-git in community repo (?) and it was broken like i described earlier
<zyga-ubuntu> aha, I see
<zyga-ubuntu> mborzecki: they accept PRs there so I guess we need to update it
<mborzecki> then i removed that package and tried to install snapd-git from aur, ran into multiple issues with files left behind by their community package and finally got into the 'broken' state :)
<ackk> mvo, any luck on the build?
 * kalikiana having lunch earlier today
 * zyga-ubuntu burns spread cycles on iteration with apparmor
<mvo> ackk: not yet, I can give you a manually build one, for some reason "snapcraft cleanbuild" fails for me in artful, maybe deboostrap is doing things that are not supported, I get https://paste.ubuntu.com/26346220/ ( kalikiana may know more). I can give you a hand-hacked one instead
<ackk> mvo, that would be helpful, thanks
<mup> PR snapd#4451 opened: cmd/snap-update-ns: improve mocking for tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4451>
<niemeyer> Good morning!
<zyga-ubuntu> niemeyer: hello
<zyga-ubuntu> long time no see!
<niemeyer> Indeed!
<mvo> ackk: please try http://people.canonical.com/~mvo/tmp/base-18_very-unstable_amd64.snap
<niemeyer> Just learning how to type again..
<ackk> mvo, thanks
<mvo> hey niemeyer - welcome back! we missed you
<niemeyer> mvo: Heya, thanks!
<niemeyer> Missed you all too.. was a bit hard to put myself away from all action :)
<mborzecki> niemeyer: hey, how was your vacation?
<niemeyer> It was great being so offline for a few days
<ackk> mvo, still getting https://paste.ubuntu.com/26346261/ when trying my snap
<kalikiana> mvo: you get that error with cleanbuild? I've never seen that. Would you mind filing a bug?
<pstolowski> niemeyer, hi! welcome back!
 * kalikiana getting food now, biab
<mup> PR snapd#4452 opened: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4452>
<zyga-ubuntu> wow, the bot is instant
<zyga-ubuntu> when I opened this PR the latency was << 1s
 * zyga-ubuntu food break
<Chipaca> zyga-ubuntu: i think you just happened to open the PR at :59 :-)
<mvo> kalikiana: sure
<mvo> ackk: could you please try in clean vm? I can't reproduce this error
<zyga-ubuntu> Chipaca: hehe, maybe :)
<mvo> Chipaca: you have a first bit of review, I will continue in a little bit, its fine don't get me wrong, just tiny ideas/nitpicks
<zyga-ubuntu> mvo: I'll do two more PRs on hole-poking and layouts and then look at LXD mount issue
<Chipaca> mvo: ah then i'll wait (i already added your suggestion, was about to push)
<Chipaca> mvo: if you consider them nitpick-level, i can address them in the followup instead of here
<Chipaca> mvo: let me know :-)
<mborzecki> the AUR snapd package does not build :(
<mvo> Chipaca: interessting idea, we could merge and then do a follwup indeed
<Chipaca> mvo: i mean, i have a followup -- but it's not small
<Chipaca> so maybe it's a _bad_ idea :-)
<Chipaca> but it's certainly an idea
<mvo> Chipaca: the dirstack is used instead of recursion because you want to keep the open file handles low?
<mvo> Chipaca: heh :)
<Chipaca> mvo: and the call stack
<mvo> Chipaca: *nod*
<Chipaca> mvo: better to have a stack of string than a stack of stacks
<mvo> +1
<Chipaca> at least that's what i was taught in uni, back when i paid attention
<mvo> Chipaca: was just wondering as the recursive version is easier to read but its fine, your reasoning is sound
<mvo> Chipaca: when you apply the "readOneDir" idea, maybe "readOneDirN()" and we add the "100" to the readOneDirN() call?
<Chipaca> mvo: what for?
<mvo> Chipaca: mostly clarity, readOneDir() is really read100ItemsFromOneDir :)
<mvo> (as it is today/in that pastebin)
<Chipaca> mvo: maybe i should rename it babySteps()
<Chipaca> as in Walk() -> babySteps()
<Chipaca> :-)
<mvo> Chipaca: heh, yeah, something like this, seriously, just to avoid our future selfs using it assuming it would read *all* of that dir
<mvo> (or my future self that has a limited memory span)
<Chipaca> I'll rename it something super obvious, like twiddle()
<Chipaca> doThing()
<Chipaca> oh, i know! doProcessThing()
<zyga-ubuntu> just go all the way and call it all twinky, twonky, twooty, twoo, calling each other with one global variable as help
<Chipaca> zyga-ubuntu: and the global variable should be literally 'help'
<pstolowski> Chipaca, hey, there are rumours you have a lot on your plate and might want some help? for example with warnings, or free disk check?
<zyga-ubuntu> Chipaca: bonus point if it's a function pointer initialized to a XKCD strip
<Chipaca> pstolowski: warnings comes before free disk check warnings, but free disk computation coud come before that
 * zyga-ubuntu prepares oatmeal, the O(1) complexity food for software developers
<zyga-ubuntu> water, flakes, heat, eat
<Chipaca> zyga-ubuntu: this is go, you can't do `var help func() = "http://..."`
<zyga-ubuntu> Chipaca: function printing that or sensible-browser opening that would do
<zyga-ubuntu> https://xkcd.com/1513/ is fine
<Chipaca> zyga-ubuntu: is it bad that somewhere on my other computer is a javascript page that edits itself until it compiles
<Chipaca> pstolowski: i've got a branch with part of warnings, i think? but not sure if it'd still work as it's from two sprints ago
<pstolowski> Chipaca, perhaps I could take free disk computation?
<Chipaca> pstolowski: disk usage shares some of the issues with snapshots for which i wanted to fix user iteration, but i wasn't able to get to the bottom of those failures
<Chipaca> pstolowski: actually perhaps that's a good place to poke: want to see if you can figure out the failures?
<Chipaca> pstolowski: if you take #4299 and then
<mup> PR #4299: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <https://github.com/snapcore/snapd/pull/4299>
<Chipaca> pstolowski: spread  -seed=1512088627 -shell linode:ubuntu-14.04-64:tests/main/{interfaces-browser-support,abort}
<Chipaca> pstolowski: but with -debug instead of -shell
<Chipaca> pstolowski: you'll see the failures i mean (or you should)
<pstolowski> Chipaca, ack, will see if I can find something
<Chipaca> pstolowski: the failure is the whole thing dying (spread says something about EOF)
<Chipaca> pstolowski: good luck
<pstolowski> Chipaca, ahh, that failure
<mup> PR snapd#4453 opened: Update README.md <Created by popey> <https://github.com/snapcore/snapd/pull/4453>
<Chipaca> pstolowski: indeedly
<mup> PR snapcraft#1854 opened: Update README.md <Created by popey> <https://github.com/snapcore/snapcraft/pull/1854>
<greyback> hey, any easy way to re-run CI on this? https://github.com/snapcore/snapd/pull/4365
<mup> PR #4365: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
<zyga-ubuntu> greyback: as in restart?
<Chipaca> greyback: by CI you mean travis?
<zyga-ubuntu>  just did
<greyback> zyga-ubuntu: Chipaca yes and yes
<Chipaca> greyback: merge master first
<zyga-ubuntu> aww
<Chipaca> zyga-ubuntu: fedora will fail :-/
<zyga-ubuntu> sorry for wasting cycles
<zyga-ubuntu> cancelled
<greyback> ah, the fedora thing still not fixed
<greyback> ok
<Chipaca> greyback: well, if you merge master, they're disabled
<greyback> Chipaca: aha, ok
<greyback> will do
<Chipaca> so no, but yes
<greyback> :)
<Chipaca> greyback: note if people have looked at it already we ask you merge instead of rebasing
<greyback> Chipaca: good to know, thank you
<mvo> Chipaca: ok, finished the rest, I get some lunch now
<ackk> mvo, I'm testing in a container, not a vm
<ackk> I can try a clean one, though
<mvo> ackk: if its not too much hassle that would be great.
<ackk> sure
<mvo> ackk: I couldn't reproduce the issue, but I was testing using a vm :/
 * mvo lunch
<ackk> mvo, https://paste.ubuntu.com/26346467/ in a clean LXD
<mvo> ackk: thanks, puzzling
<ackk> the first error I 've seen randomly happen, but usually it's just the first time
<kalikiana> re
<pstolowski> Chipaca, interfaces-browser-support from your branch passed here. i'm running 16.04, could this be a factor?
<Chipaca> pstolowski: i'm running 16.04 as well
<Chipaca> pstolowski: note it only fails together with another test
<pstolowski> Chipaca, aha!
<Chipaca> pstolowski: that's why the command was as i typed
<pstolowski> I should treat your command literally.. yes
<Chipaca> niemeyer: standup?
<kalikiana> popey: Hey! Can you provide an example that triggers this bug? https://bugs.launchpad.net/snapcraft/+bug/1741752
<mup> Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:Incomplete> <https://launchpad.net/bugs/1741752>
<popey> kalikiana: done
<kalikiana> popey: Thanks! Will try to reproduce here
<pstolowski> Chipaca, and it passed https://pastebin.ubuntu.com/26346695/
<pstolowski> Chipaca, you said it was failing every time for you?
<mborzecki> Chipaca: i can look into fedora issues later today/tomorrow
<popey> kalikiana: are we going to get stacktrace spam turned off sometime soon?
<kalikiana> popey: There were some fixes for that already. Have you tested with the --beta snap?
<popey> kalikiana: I'm on edge
<kalikiana> popey: If that isn't a Freudin slip :-P Can you paste any recent example? We might not have caught all of them
<popey> kalikiana: how about the bug you just asked me to put an example on? :)
<kalikiana> popey:  Ah, right. So in this case you see the trace because it's not a known failure case. It's a genuine bug so this will need a proper exception code path.
<kalikiana> We don't generally try to hide those
<popey> I don't ever want to see them
<diddledan> me too
<popey> unless I pass some kind of -show_me_the_python_nonsense_I_dont_care_about
<diddledan> only devs need to see those
<diddledan> just say "we dun goof'd" on unknown errors and leave it there
<popey> SNAPCRAFT_VERBOSE=1 would do
<popey> i would set that on build.snapcraft.io or travis, but never on my laptop
<kalikiana> We could make them `--debug` only and something like `Please re-run with --debug to get a full trace`.  The most important aspect to my mind is that there's a clear path to knowing how to get the error and report it if desired.
<popey> that'd work
<diddledan> even better: --file-bug; that runs through until the failure and then gets all the useful debug info and posts it to launchpad similar to ubuntu-bug does
<diddledan> or maybe call it "--create-bug"
<diddledan> something like that anywho
<diddledan> then we don't need to even work out which bits we need to copy
<kalikiana> That might need some discussion on what that info is... although that's a nice idea
<diddledan> or rather than being explicit when it hits a failure it just prompts "do you want to create a bug? (Y/n)" which you can disable with a `--quiet` flag
<diddledan> bonus points for finding duplicates
<kalikiana> That would've been awesome for codein...
 * kalikiana won't have time to look into the anytime soon
<diddledan> pop it on the backlog :-)
<kalikiana> diddledan: Mind filing a bug for it?
<diddledan> roger that
<popey> there is one
<popey> i filed it iirc
<kalikiana> For "file a bug"?
<popey> no, for stfu
<popey> https://bugs.launchpad.net/snapcraft/+bug/1740265
<mup> Bug #1740265: Stack trace makes it hard to discern real errors <Snapcraft:New> <https://launchpad.net/bugs/1740265>
<popey> Please don't push that back until after we have bug reporting built in though :(
<kalikiana> popey: Aye, this one is pretty straightforward. I'll bring it up later in our weekly meeting
<popey> thanks
<diddledan> bug #1741900
<mup> Bug #1741900: Add file-a-bug functionality on errors <Snapcraft:New> <https://launchpad.net/bugs/1741900>
<kalikiana> diddledan: Thanks!
 * pstolowski lunch
 * zyga-ubuntu quick break to catch up with kids
 * mborzecki is off to pick up the kids
<ogra_> cyphermox, i have the next wlan module that doesnt support unbind ... given how big that block in netplan already is i wonder, cant we get away without unbinding the dirvers at all ?
<ogra_> cyphermox, ath6kl_sdio this time ...
<cyphermox> not afaik
 * ogra_ will file a bug and patch as usual ... but all these SRUs get tiring 
<Chipaca> pstolowski: indeed. Can you run the whole suite?
<Chipaca> pstolowski: also, what's your PROMPT_COMMAND? :-)
<ogra_> cyphermox, https://code.launchpad.net/~ogra/netplan/+git/netplan/+merge/335824 .. do you need a separate MP for the xenial branch or will you just backport it ?
<mup> PR snapd#4454 opened: snap: fix gadget.yaml parsing for multi volume gadgets <Created by mvo5> <https://github.com/snapcore/snapd/pull/4454>
<mup> PR snapd#4455 opened: store, daemon/api: Rename MyAppsServer, point to dashboard.snapcraft.io instead <Created by sparkiegeek> <https://github.com/snapcore/snapd/pull/4455>
<zyga-ubuntu> back to work
<ogra_> cyphermox, https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1741910
<mup> Bug #1741910: ath6kl_sdio does not support unbinding <netplan:New> <nplan (Ubuntu):New> <nplan (Ubuntu Xenial):New> <https://launchpad.net/bugs/1741910>
<cyphermox> ogra_: it's fine as-is,thanks!
<ogra_> awesome !
<elopio> hello!
<elopio> kalikiana: I am awake now :)
<kalikiana> elopio: :-D
<kalikiana> elopio: Actually there's something I'd like your input on. Can you have another look at snapcraft#1847 and tell me your thoughts on conditional `sudo` in `_container_run`? kyrofa wasn't very happy with it, so I changed it twice now. I figure a third opinion would help figure out the best path
<mup> PR snapcraft#1847: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1847>
<kalikiana> elopio: Also in case you haven't seen it, I made some comments on snapcraft#1853
<mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
<elopio> yup, thanks for the review.
<elopio> kalikiana: I find that clear, if user != 'root': prepend sudo.
<kalikiana> elopio: first I had heuristics, then I had user=False... if you like this version I'm hoping kyrofa will also like it, but otherwise I'm out of ideas :-P
<kyrofa> kalikiana, haha, I'm sorry to be causing pain. user=False was way better
<kalikiana> kyrofa: :-|
<elopio> that's easy to fix, ask kyrofa for what will make him happy, instead of guessing :D
<kyrofa> kalikiana, I mean way better than the heuristics
<elopio> lol
<kyrofa> kalikiana, haven't looked at the new way yet
<kalikiana> kyrofa: Oh, hah, okay
<kalikiana> I'm actually liking the latest one a lot more myself now than what I did before
<kyrofa> Alright I'll take a look soon. I have oodles of codein reviews
<kalikiana> The good kind of spam ;-)
<kalikiana> kyrofa: We can also have a quick chat about it in/after the weekly, might be easier at this point
<kyrofa> kalikiana, we can do that if I haven't been able to review by then, I know you go *poof* shortly after
<kalikiana> Yeah. I'm weird like that. As if the sun somehow goes down earlier where I'm at :-P
<mup> PR snapcraft#1854 closed: Update README.md <Created by popey> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1854>
<kyrofa> kalikiana, yeah, let's chat about this in a few
 * zyga-ubuntu runs new tests and goes to update the forum on the progress towards layouts
<Chipaca> pstolowski: sorry if i missed your reply, were you able to run the full suite?
<pstolowski> Chipaca, no, I got a bunch of EOFs, but not on the tests in questions
<pstolowski> *in question
<Chipaca> pstolowski: that's fine
<Chipaca> pstolowski: those test were not the problem, the EOFs were
<pstolowski> ah, ok
<Chipaca> just that with those two i was always able to reproduce, but it's weird enough that i'm not surprised it's moved
<pstolowski> Chipaca, re my command prompt, I use zsh and oh-my-zsh dot files ;)
<Chipaca> booh :-) ok
<pstolowski> who uses bash anyway? ;)
<Chipaca> o/
<ogra_> hey !
 * Chipaca hides before ogra_ goes nukular
<ogra_> lol
<mup> PR snapcraft#1855 opened: storeapi: add docstrings for _snap_index_client.py <Created by konrad11901> <https://github.com/snapcore/snapcraft/pull/1855>
<brunosfer> Hi guys, does anyone knows how can I install the exact version of a snap on ubuntu core?
<zyga-ubuntu> brunosfer: what do you mean by exact version of a snap?
<pstolowski> Chipaca, so it appears I need to run multiple spread tests to trigger EOF, that matches your observations right?
<Chipaca> pstolowski: yuup
<brunosfer> zyga-ubuntu: e.g. snap discord has older versions. the current version is 0.0.3, however it has an older version 0.0.2, if I remove this snap from my OS, can I make something like sudo snap install discord --version=0.0.2 ?
<brunosfer> Not exactly a rollback to the previous version, but rather a version in particular, however in this case such thing does not apply.
<zyga-ubuntu> brunosfer: not quite like that, versions are meaningless, you can install appropriate revision (see snap install --help)
<ogra_> you can do that if you own the snap
<ogra_> but only then
<zyga-ubuntu> brunosfer: you can list the revisions you have on your machine
<zyga-ubuntu> brunosfer: you can switch between any revisions that are published (by switching channels)
<zyga-ubuntu> brunosfer: and between any revisions on your machine that you already had (by using -r)
<ogra_> ... and between random revisions from the store if you are the owner (developer)
<ogra_> (unless that got disabled since i used it last)
<zyga-ubuntu> ogra_: no, it's a desired feature
<ogra_> right
<kyrofa> kalikiana, test failures on snapcraft#1847
<mup> PR snapcraft#1847: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1847>
<kalikiana> kyrofa: Eh. Lemme check those quickly before I leave. Those all passed locally...
<kalikiana> Thanks
 * Chipaca hugs mvo 
<Chipaca> mvo: thank you for asking me for more tests
<kalikiana> Meh, I was missing a mock geteuid there
<sparkiegeek> is there a way of telling 'snap set' to not show progress (because I'm running it from a script)?
<zyga-ubuntu> Chipaca: ^
<Chipaca> sparkiegeek: </dev/null
 * zyga-ubuntu goes to fix a quick oversight in the new mimic code
<Chipaca> sparkiegeek: although it should already do that if stdin is not a tty
<zyga-ubuntu> well, not in minic but around it
<sparkiegeek> Chipaca: thanks
<Chipaca> sparkiegeek: just checked, and in 2.30 at least, if stdin is not a tty, you should get the nonverbose noninteractive "progress bar"
<Chipaca> it'll just print success
<Chipaca> and that sort of thing
<sparkiegeek> Chipaca: confirmed with 2.30, stdin=open('/dev/null') does what I want
<sparkiegeek> I was trying to find a --quiet/--non-interactive option
<sparkiegeek> this is fine though, cheers
<zyga-ubuntu> sparkiegeek: if this is python, use subprocess.DEVNULL
<mup> PR snapcraft#1856 opened: remote_parts: Use hashed folder based on parts URI <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1856>
<kalikiana> Alrighty, pushed the remote parts fix out, now I'll call it a day
 * zyga-ubuntu will work for a little while longer to get all of the mimic branches merge-worthy and fully functional
<zyga-ubuntu> and tomorrow, layouts
<sparkiegeek> zyga-ubuntu: good shout
<kyrofa> Hey ogra_, do you know anything about the kernel on the nvidia Jetson boards? Can they run snaps?
<ogra_> no idea
<ogra_> but i doubt that
<kyrofa> Me too
<sparkiegeek> is there a way of getting snapd version information in a parseable format (e.g. JSON/YAML/..)?
<sparkiegeek> or should I just do "^(.*)\s+(.*)$" style parsing?
<zyga-ubuntu> sparkiegeek: talk to the socket
<zyga-ubuntu> there's a whole API there
<zyga-ubuntu> (talking json)
<brunosfer> zyga-ubuntu: sudo snap discord -r 0.0.2 ? Would be something like this?
 * Chipaca wraps up his day, at least for now
<zyga-ubuntu> brunosfer: no, revisions are always integers
<zyga-ubuntu> brunosfer: this looks like a version
<zyga-ubuntu> brunosfer: try snap list --all
<zyga-ubuntu> brunosfer: you will see various revisions of each snap on your system
<zyga-ubuntu> brunosfer: again, unless you had a revision you want to go to, you cannot do that
<zyga-ubuntu> brunosfer: only the owner of that snap can
<zyga-ubuntu> brunosfer: snaps should have sensibly defined channels and not rely on their users pinning a specific revision
<brunosfer> zyga-ubuntu: Thanks, for clarifying. I want to go to the revision 32, how can I switch to an older revision? Because I have tried the -r flag and it didn't work.
<zyga-ubuntu> brunosfer: do you have that revision on your system (snap list --all)
<brunosfer> zyga-ubuntu: Yes
<brunosfer> zyga-ubuntu: discord          0.0.3        41    snapcrafters  -
<brunosfer> discord          0.0.2        32    snapcrafters  disabled
<brunosfer> discord          0.0.3        38    snapcrafters  disabled
<brunosfer> zyga-ubuntu: I want to switch to the revision 32
<zyga-ubuntu> snap refresh discord -r 32 OR snap revert discord
<zyga-ubuntu> refresh will go there but will keep updating
<zyga-ubuntu> and revert will skip 38
<zyga-ubuntu> AFAIK
<brunosfer> zyga-ubuntu: Thanks, I was using the switch for that. Now that you explained it makes indeed more sense to use the refresh to a specific revision. Thank ;)
<brunosfer> zyga-ubuntu: It's giving me the error: unknown flag 'r'
<brunosfer> zyga-ubuntu: It's working... no '-' was needed... just the 'r' as a flag.
<ogra_> that sounds a bit buggy
<zyga-ubuntu> maybe try --revision
<ogra_> short options should use a -
<brunosfer> zyga-ubuntu: sudo snap refresh discord --revision=50
<brunosfer> zyga-ubuntu: it works like this... With the short option doesn't work.
<ogra_> ah, the --help also doesnt list any short options at all
<zyga-ubuntu> sorry it must have been my rusty memory then
 * zyga-ubuntu still debugs one issue
<kyrofa> elopio, if you feel like taking circle ci for a spin: https://github.com/canonical-websites/tutorials.ubuntu.com/pull/618
<kyrofa> Hey niemeyer, are you around today? Or are you still out on vacation?
<kyrofa> Oh, back today, it seems. Okay, I'll catch you tomorrow then :)
<kyrofa> Hey there cratliff, good to see you around
<cratliff> Hey, yeah, the holidays can keep you busy sometimes.
<mup> PR snapcraft#1847 closed: lxd: Use user in container when mounting remote via sshfs <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1847>
<kyrofa> Boy no kidding
<niemeyer> kyrofa: I'm fully back already
#snappy 2018-01-09
<mborzecki> morning
<mwhudson> https://buildd.debian.org/status/fetch.php?pkg=snapd&arch=i386&ver=2.30-3&stamp=1515462684&file=log <- is deviceMgrSuite.TestDoRequestSerialErrorsOnNoHost known flaky?
<mup> PR snapd#4453 closed: Update README.md <Created by popey> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4453>
<mborzecki> mwhudson: sort of, the test is supposed to use an invalid domain name, though there's been some back and forth on what an invalid domain name that would not be resolved is
<mwhudson> hmm
<mwhudson> time to remember how to retry builds on debian buildds i guess
<mborzecki> mwhudson: i think there might be something special here though, we've used *.invalid, then some bogus name.com and finally settled with nowhere.test, but it seems like the resolver is actually trying to resolve it :/
<mwhudson> mborzecki: it only failed on i386
<mwhudson> but maybe that builder is different somehow
<zyga-ubuntu> good morning
<mwhudson> morning zyga-ubuntu
<mborzecki> zyga-ubuntu: hey
<mvo> hey zyga-ubuntu and mwhudson and mborzecki
<mborzecki> mvo: morning
<mwhudson> launchpad's "click a button" certainly seems clearer than https://release.debian.org/wanna-build.txt
<mup> PR snapd#4451 closed: cmd/snap-update-ns: improve mocking for tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4451>
<zyga-ubuntu> I'll be here soon, just finishing breakfast for kids
 * zyga-ubuntu finishes coffee checking maikl
<mborzecki> doing any text transformation in `snap_confine_snap_confine_debug_LDADD = $(something .. $(snap_confine_snap_confine_LDADD))` results in `snap_confine_snap_confine_debug_DEPENDENCIES = $(something .. $(snap_confine_snap_confine_LDADD))`, so the DEPENDENCIES includes -ludev -lfoo now :/
<kalikiana> good mornin
<mborzecki> kalikiana: morning
<mvo> mborzecki: 4449 fails with a link error on debian, could this be related to your makefile changes or is that an unrelated issue?
<mborzecki> mvo: related, i'm working on it, one fugly workaround for automake :/
<mvo> mborzecki: uff, ok. good luck!
<mborzecki> mvo: pushed just now, feel free to take a look and review :)
<mvo> great
<mborzecki> pstolowski: morning
<pstolowski> good morning!
<mvo> good morning pstolowski !
 * pstolowski reboots
<mborzecki> mvo: there's a conflict in #4356
<mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
<mborzecki> is #3998 actionable now?
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<zyga-ubuntu> mborzecki: I think it should be in the kernel by now
<zyga-ubuntu> mborzecki: but we need to connect the dots
<mvo> zyga-ubuntu, mborzecki iirc the problem is/was that fedora has no updated libseccomp
<zyga-ubuntu> mvo: indeed, we may need to always allow an older version of the library to stay realistically deployable
<mborzecki> ok, let me quickly ccheck what's the latest version in updates
<mvo> zyga-ubuntu: yeah, iirc that is the missing bit
<mborzecki> by the looks of it, it's 2.3.2 in f26 and f27
<mborzecki> unless there's some specific patch that's missing
<zyga-ubuntu> mvo: altough having said that we should not differ in behaviour for apps, we should switch to EPERM universally, just enable logging if that is implemented
<zyga-ubuntu> mborzecki: ^
<mborzecki> right, makes sense
<mup> PR snapd#4456 opened:  snap: rename `snap advise-command` to `snap advise-snap --command`  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4456>
<mup> PR snapd#4444 closed: tests: use "quiet" helper instead of "dnf -q" to get errors on failures <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4444>
 * kalikiana coffee
 * zyga-ubuntu tries to untangle an abstraction
<zyga-ubuntu> sigh
<zyga-ubuntu> so close yet a bit frustratingly not there
<Chipaca> zyga-ubuntu: another security issue just to brighten your day: https://twitter.com/chris__martin/status/950518574589923331
<zyga-ubuntu> what!
<zyga-ubuntu> LOL!
<zyga-ubuntu> beautiful
<Chipaca> :) you're welcome
<mup> PR snapd#4457 opened: spread: trying to re-enable tests on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4457>
<mborzecki> Chipaca: you mentioned that you ran into some non-dnf related issues on fedora, can you describe what that was?
<Chipaca> mborzecki: "snap: command not found", and systemctl saying snapd.service was not found
<Chipaca> mborzecki: IOW something that looked suspiciously like snapd not being installed
<mborzecki> interesting, i ran some tests on fedora today, haven't observed anything like this, maybe it will come up in the PR i just opened ^^
<mborzecki> duh. wonder what conditions would have to be met to get a latex error message that makes sense
<Chipaca> mborzecki: maybe the conditions need to exist in the observer's mind
<mborzecki> randomly hitting x
<Chipaca> maybe latex was all about psychoquantumdynamics
<mborzecki> half of the 'exploit' was getting your latex toolchain to work with proper fonts and language
<ackk> mvo, hi, do you have any suggestion on how to debug those errors on my snap install?
<zyga-ubuntu> coffee
<mvo> ackk: not right now, do you see apparmor or seccomp denials when you run the install? maybe zyga-ubuntu has an idea about the issue. another thing to try is see if using maas without base-18 gives the same error (removing the base: line)
<zyga-ubuntu> hmm hmm hmm hmm
<ackk> mvo, no, nothing
<ackk> mhm, so there's this thing: the first time I snap try I get this error: https://paste.ubuntu.com/26352275/
<ackk> but now I have the prime directory mounted
<ackk> /dev/sda3 on /snap/maas/x1 type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@home/ack/canonical/src/maas/build/dev-snap/prime)
<ackk> and I can't unmount it
<ackk> I suspect that's messing up snapd
<zyga-ubuntu> oh
<zyga-ubuntu> btrfs
<mvo> ackk: ohh, that is indeed interessting and a useful clue
<zyga-ubuntu> I don't know if eve ever test that it works with snapd
<mvo> and it would explain why I was not able to reproduce!
<ackk> zyga-ubuntu, I've always used it
<ackk> with no issue so far
<zyga-ubuntu> ackk: sure but we never (AFAIK) use it and it's an extra layer of complexity
<mvo> ackk: does "systemctl  status snap-maas-x1.mount" and "journalctl  -xe"" give you anything useful why it fails?
<ackk> $ umount /snap/maas/x1
<ackk> umount: /snap/maas/x1: umount failed: Operation not permitted
<zyga-ubuntu> ackk: I'm not saying it doesn't work, just that it is an extra variable
<zyga-ubuntu> ackk: anything in audit log:?
<ackk> Process: 20922 ExecUnmount=/bin/umount /snap/maas/x1 -c (code=exited, status=32)
 * zyga-ubuntu waits for people to try snaps on ZFS
<ackk> but status is active (mounted)
<ackk> mvo, nothing relevant in journalctl, just ^^ in status output
<ackk> I'll try to reboot the container
<zyga-ubuntu> oh,. it's a container?
<zyga-ubuntu> ackk: wait
<mvo> ackk: hm, exit status 32 just means "mount-failure" not very helpful, especially without any extra info
<zyga-ubuntu> ackk: cat /proc/self/mountinfo
<zyga-ubuntu> mvo: is it not just the "snapd fails in containers or places without rshare /" case?
<mvo> zyga-ubuntu: it might be, I thought we had this under control :(
<zyga-ubuntu> no, it's not fixed yet
<zyga-ubuntu> mvo: after several attempts it's still broken
<zyga-ubuntu> mvo: sorry about that :/
<ackk> oh, after reboot /var/lib/snapd/snaps/maas_x1.snap became a dir :)
<ackk> zyga-ubuntu, mvo ok, after reboot I don't have that mountpoint anymore, but same error
<mvo> zyga-ubuntu: no worries, thanks for remembering more than I do - yeah, then its probably this
<ackk> fwiw that error from the paste is totally reproducible the first time I "snap try"
<ackk> zyga-ubuntu, https://paste.ubuntu.com/26352304/
<mvo> ackk: and from installing, right? not just try?
<ackk> mvo, snap try
<mvo> ackk: so just try?
<ackk> mvo, correct
 * mvo nods
<ackk> zyga-ubuntu, so that mountpoint was left behind somehow
<zyga-ubuntu> -
<zyga-ubuntu> so not shared
<zyga-ubuntu> so proably that's the same cause as before
<zyga-ubuntu> ackk: I cannot explain how maas_x1.snap became a directory
<ackk> so the thing that makes me thing that snapd is confused by that mountpoint is "2018/01/09 10:23:35.075389 task.go:303: DEBUG: 2018-01-09T10:23:35Z ERROR cannot find installed snap "maas" at revision x1"
<ackk> there's no installed maas snap
<ackk> but it seems snapd thinks it's actually updating it
<zyga-ubuntu> ackk: I think this is https://bugs.launchpad.net/snapd/+bug/1712930
<mup> Bug #1712930: snap-confine: mounts happen in the wrong order <snapd:Confirmed for zyga> <https://launchpad.net/bugs/1712930>
<ackk> ah the old issue with snap in lxd
<zyga-ubuntu> ackk: indeed
<zyga-ubuntu> ackk: can you (perhaps) try if this goes away without the container in place?
<zyga-ubuntu> ackk: it woudl re-affirm where we are
<zyga-ubuntu> ackk: and I promise to attack that bug again later today
<ackk> zyga-ubuntu, sure, lemme test
<ackk> zyga-ubuntu, ah! so, somehow now umount worked on that dir
<ackk> and snap try went further along
<ackk> so that seems to be the issue
<ackk> (I'm still testing in the container)
 * zyga-ubuntu makes some progress actually
<ackk> zyga-ubuntu, so there's something weird, there
<ackk> $ mount | grep snap/maas
<ackk> /dev/sda3 on /snap/maas/x1 type btrfs (rw,relatime,space_cache,subvolid=263,subvol=/@home/ack/canonical/src/maas/build/dev-snap/prime)
<ackk> zyga-ubuntu, ^ that's not actually a btrfs subvolume
<ackk> is snap being confused by the underlying btrfs and trying to mount it as such?
<zyga-ubuntu> ackk: I doubt it, snapd doesn't mount that, this is systemd, systemd is not confused either (probably); mount is confusing, this is a bind mount and mount cannot represent those
<zyga-ubuntu> look at mountinfo
 * kalikiana more coffee
<zyga-ubuntu> this is a bit annoying about bind mounts, they suck for UX
<zyga-ubuntu> nobody can make heads or tails about what's where
<zyga-ubuntu> (and how)
<zyga-ubuntu> because bind mount history is logical to humans but not preserved
<zyga-ubuntu> and bind mount effects are highly confusing but that's what the kernel models and stors
<zyga-ubuntu> *stores
<ackk> zyga-ubuntu, so /snap/maas/x1 is a bind-mount?
<zyga-ubuntu> ackk: look at mountinfo
<zyga-ubuntu> ackk: and we'll see
<zyga-ubuntu> ackk: but 99% yes
 * zyga-ubuntu will design a bind mount t-shirt one day
<ackk> zyga-ubuntu, https://paste.ubuntu.com/26352351/
<Chipaca> is it bad that last night i learned how to use a package-private function from outside the package, in go?
<Chipaca> this will make testing some things a lot simpler :-D
<zyga-ubuntu> so /snap/maas/x1 is actually a btffs filesystem from /dev/sda3, specifically the fragment located at /@home/ack/canonical/src/maas/build/dev-snap/prime relative to that filesytem
<zyga-ubuntu> yep, that's a bind mount
<zyga-ubuntu> at some point I think mount stopped being useful for humans
<jamesh> Chipaca: without modifying the package?
<Chipaca> jamesh: yes
<jamesh> Chipaca: care to share then?
<Chipaca> jamesh: https://pastebin.ubuntu.com/26352358/
<zyga-ubuntu> jamesh: hey! sorry for lagging; I'd like to arrange a call later this week between you me and gustavo; I need to do some prep work but I think we can try the day after tomorrow (assuming schedule allows)
<zyga-ubuntu> jamesh: do you have preference for your evening vs your morning?
<zyga-ubuntu> jamesh: gustavo and I will adapt
<Chipaca> jamesh: the only caveat is that the package from which you do this needs to have a .s file (it can be empty)
<Chipaca> and you need to import unsafe even if you don't use it, otherwise go:linkname refuses to woork
<Chipaca> and you need to import the package, even if you don't use it :-)
<jamesh> zyga-ubuntu: my evening is probably going to be the easiest to cover Australia, Europe, and Brazil
<mup> PR snapd#4458 opened: overlord/snapstate: no refresh just for hints if there was a recent regular full refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4458>
<Chipaca> jamesh: (if you want to run that as is, note modeFromTriplet isn't in master yet; grab #4394 for that)
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<zyga-ubuntu> jamesh: ok, so today I'm trying to wrap up last year's PRsr and will jump into LXD issue but we can do day after tomorrow because I could focus on getting in-depth understanding of your work tomorrow
<ackk> zyga-ubuntu, I get https://paste.ubuntu.com/26352371/ at the first install on the physical machine
<ackk> actually, every time
<zyga-ubuntu> jamesh: gustvo would like to get better understanding of where we are in anticipation of the upcoming sprint next week
<jamesh> okay
<zyga-ubuntu> ackk: interesting, is /var/snap present?
<zyga-ubuntu> maybe it's a packaging issue
<zyga-ubuntu> snap-confine doesn't create that directory
<ackk> zyga-ubuntu, yes it is, i have also other snaps installed
<Chipaca> mvo: i've added some tests to #4394, i think you'll like it now
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <https://github.com/snapcore/snapd/pull/4394>
<zyga-ubuntu> ackk: bummer, no idea then :/
<ackk> zyga-ubuntu, FTR this is on artful
<zyga-ubuntu> ackk: noted
<zyga-ubuntu> ackk: ahh wait
<zyga-ubuntu> ackk: this is with the base 18 snap, right?
<ackk> yeah
<zyga-ubuntu> ackk: so can you quickly look in /snap/base-18/current/var/snap
<ackk> I get the same error on the first try on bionic, so maybe that's the root cause?
<zyga-ubuntu> does that exist?
<zyga-ubuntu> if no that's the problem
<zyga-ubuntu> (needs to be in the base snap)
<ackk> nope
<ackk> bingo :)
<zyga-ubuntu> good catch!
<ackk> mvo, ^^
<ackk> zyga-ubuntu, so just creating var/snap inside the base should work?
<zyga-ubuntu> yes
<zyga-ubuntu> well
<zyga-ubuntu> one step forward
<zyga-ubuntu> but yes
<mup> PR snapd#4459 opened: snap: add support for `snap advice-snap pkgName` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4459>
<mvo> ackk: thanks! a shame that LP building is not working, master is ok https://github.com/snapcore/base-18/blob/master/hooks/20-extra-files.chroot#L18 :/ I can give you an updated snap or you can hack it yourself?
<zyga-ubuntu> woot
<zyga-ubuntu> progress
<zyga-ubuntu> 5 errors, but the code builds and has good structure
<zyga-ubuntu> and errors look like string tweaks I did don't match errors in tests
<ackk> mvo, if you have an updated one that'd be great
<ackk> mvo, have you asked for whitelisting?
<mvo> ackk: I asked but maybe not forceful enough. I was told things will be reenabled today once the kernel is updated
<mvo> ackk: I updated http://people.canonical.com/~mvo/tmp/base-18_very-unstable_amd64.snap to include the dirs from master
<mup> PR snapd#4455 closed: store, daemon/api: Rename MyAppsServer, point to dashboard.snapcraft.io instead <Created by sparkiegeek> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4455>
<ackk> mvo, thanks, will try that one
<ackk> mvo, there's no /var/snap inthat snap
 * zyga-ubuntu sees green tests
<mvo> ackk: meh, I'm sorry, pushed the wrong one :/ I repushed the right one to the same location: https://paste.ubuntu.com/26352614/
<ackk> mvo, mvo thanks
<zyga-ubuntu> let's see coverage]
<BjornT_> zyga-ubuntu: if you have some time, i added some more information to bug #1741463
<mup> Bug #1741463: Failure to install maas snap in a container on a host using nvidia drivers <Snappy:New> <https://launchpad.net/bugs/1741463>
<ackk> mvo, next error I got is: - Run configure hook of "maas" snap if present (run hook "configure": cannot perform operation: mount --bind /snap/base-18/current//etc/alternatives /tmp/snap.rootfs_9Cushn/etc/alternatives: Permission denied)
<zyga-ubuntu> BjornT_: thanks, this looks like a simple apparmor profile tweak
<zyga-ubuntu> BjornT_: looking now
<zyga-ubuntu> hmmm
<zyga-ubuntu> BjornT_: so looking at snap-confine.apparmor.in I see a rule that looks like this:
<zyga-ubuntu>     # Vulkan support
<zyga-ubuntu>     /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/* w,
<zyga-ubuntu>     mount fstype=tmpfs options=(rw nodev noexec) none -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
<zyga-ubuntu>     mount options=(remount ro) -> /tmp/snap.rootfs_*/var/lib/snapd/lib/vulkan/,
<zyga-ubuntu> can you look into /etc/apparmor.d/ for snap-confine.real (there may be a few) and see if those rules exist there?
<zyga-ubuntu> (I want to check if this code is released)
<mup> PR snapd#4460 opened: daemon: store email, ID and macaroon when creating a new user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4460>
<mvo> ackk: aha, let me fix that and update
<mvo> ackk: updated on the same location as before, please let me know if that gets you further
<ackk> thanks
<ackk> mvo, it takes me a whilte to test since that mountpoint prevents me from reinstalling the maas snap, so i have to purge snapd, reboot and reinstall every time
<mvo> ackk: that sounds really painful :(
<zyga-ubuntu> ackk: inside a container or in general?
<ackk> zyga-ubuntu, inside a container
<ackk> because of that mount bug
<ackk> if I try to remove a snap it's pending forever
<zyga-ubuntu> ok
<BjornT_> zyga-ubuntu: there's nothing about 'vulkan' in usr.lib.snapd.snap-confine.real
<zyga-ubuntu> BjornT_: are you on 2.30/
<zyga-ubuntu> BjornT_: that file may be older but you should be getting reexec from the core snap
<zyga-ubuntu> so snap.core.*.usr.lib.snapd.snap-confine should have those rules
<BjornT_> zyga-ubuntu: i'm on xenial, so 2.29.4.2
<zyga-ubuntu> BjornT_: that's ok, but you should see 2.30 in snap version (because of core snap)
<zyga-ubuntu> BjornT_: as a sanity check, can you switch to edge
<zyga-ubuntu> BjornT_: and see if that fixes it
<zyga-ubuntu> BjornT_: I believe this is fixed in master but may just not be released yet
<mup> PR snapd#4461 opened: snap: fix missing error check when multiple snaps are refreshed <Created by mvo5> <https://github.com/snapcore/snapd/pull/4461>
<BjornT_> zyga-ubuntu: ah right, yes 2.30. i'll try the edge version
<ackk> mvo, progress, I'm hitting that ubuntu.csv issue now, do you still have the change to snapcraft.yaml handy?
<ackk> I think it's just adding distro-info-data to stage-packages
<BjornT_> zyga-ubuntu: same error with edge core snap. or do i have to restart apparmor as well?
<zyga-ubuntu> BjornT_: no, you shouldn't have to restart anything
<ackk> mvo, or actually, wasn't that added to the base?
<zyga-ubuntu> BjornT_: hmm
<zyga-ubuntu> info="failed flags match"
<zyga-ubuntu> this is curious
<zyga-ubuntu> perhaps (just perhaps) the system is buggy and remount is not a real flag that works
<zyga-ubuntu> BjornT_: can you please edit the /etc/apparmor.d/snap.core.$LATEST.usr.lib.snapd.snap-confine file
<zyga-ubuntu> BjornT_: go to the line that describes the three vulcan entries
<zyga-ubuntu> BjornT_: and remove the "ro" there from (remount ro)
<zyga-ubuntu> to just (remount)
<zyga-ubuntu> BjornT_: then use: sudo apparmor_parser -r /etc/apparmor.d/snap.core.$LATEST.usr.lib.snapd.snap-confine
<zyga-ubuntu> and see if that fixes it
<mvo> ackk: it was not added, there is a open pr, I can add it for you right after lunch for this one test snap
<ackk> mvo, thanks, and enjoy lunch :)
 * zyga-ubuntu keeps fingers crossed
<zyga-ubuntu> and...
<zyga-ubuntu> YESSSS
<zyga-ubuntu> :D
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4452 enables all of the mechanics of layouts
<mup> PR #4452: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4452>
<zyga-ubuntu> now to rebase the new content interface syntax PR
<zyga-ubuntu> and to open a new PR that takes use of the layout yaml syntax and puts it into use
<zyga-ubuntu> at just 310 new lines and 63 removed lines
<zyga-ubuntu> jamesh: ^^ this should be directly applicable to themes now
<zyga-ubuntu> jamesh: I'll focus on the source syntax for content because it also enables the new union mechanics where many entries can contribute to one (spool like) directory
<zyga-ubuntu> mvo: I added 4452 to 2.31, it's my most important addtion now
<kalikiana> popey: ping wrt bug 1741752
<mup> Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:New> <https://launchpad.net/bugs/1741752>
<zyga-ubuntu> there are some unit tests missing but spread tests cover everything and I'll fill the gaps quickly (just a few lines)
<ackk> mvo, I hacked the image adding distro-info, it works now
<zyga-ubuntu> BjornT_: any luck, I can help if you don't know what to change
<ackk> zyga-ubuntu, can you depend on a base from a specific channel? like base: base-18/edge?
<mup> PR snapd#4313 closed: timeutil: refresh timer take 2 <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4313>
<zyga-ubuntu> ackk: no
<mup> PR snapd#4373 closed: snap: app startup after/before validation <Created by bboozzoo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/4373>
<BjornT_> zyga-ubuntu: i removed the 'ro', but i still get the same error
<zyga-ubuntu> BjornT_: I assume you re-compiled the apparmor profile
<zyga-ubuntu> BjornT_: and that the revision in the file name matches the revision of the core snap
<zyga-ubuntu> BjornT_: can you remove all of (remount, ro) next?
<BjornT_> zyga-ubuntu: yeah, using apparmor_parser -r
<zyga-ubuntu> ok, just checking
<mup> PR snapd#4462 opened: progress: switch ansimeter's Spin() to use a spinner <Created by chipaca> <https://github.com/snapcore/snapd/pull/4462>
<Chipaca> niemeyer: mvo: just for you guys ^-^
<zyga-ubuntu> ok, feels like moment to make some food
<zyga-ubuntu> I'll see you at the standup
<BjornT_> zyga-ubuntu: still the same error
<zyga-ubuntu> BjornT_: I wonder how I can test this, what setup do you use
<zyga-ubuntu> BjornT_: if I could reproduce this locally I could fix it easier
<BjornT_> zyga-ubuntu: the host is xenial and i've tried with both xenial and bionic containers. not sure if having the nvidia drivers is enough trigger it, though
<zyga-ubuntu> BjornT_: which drivrs are you on ?
<zyga-ubuntu> BjornT_: I have an artful system with old nvidia (without vulcan) but I can fake some things (perhaps) to trigger it
<zyga-ubuntu> BjornT_: are you on xenial kernel or on some newer one?
<BjornT_> zyga-ubuntu: i have the nvidia-384 package installed. still xenial kernel
<zyga-ubuntu> I could use a single slot non-outdated nvidia GPU
<zyga-ubuntu> could use it for testing
<zyga-ubuntu> I'm all AMD on my desktop
<mvo> ackk: updated
<mvo> ackk: aha, reading backlog you added it already
<mvo> ackk: and it all works? maas init too?
<ackk> mvo, does base-18 have timezone information?
<ackk> mvo, no, I get the following error at maas init: psycopg2.DataError: invalid value for parameter "TimeZone": "UTC"
<ackk> mvo, still investigating if that could be caused by something missing in the base
<ackk> mvo, are zoneinfo data there?
<ackk> mvo, ok "SET TIME ZONE 'UTC'" fails in postgres
<mvo> ackk: indeed, no zoneinfo
<ackk> oh
<ackk> so that's why
<ackk> mvo, could those be added as well?
<ackk> mvo, I'm sorry for this back-and-forth...
<mvo> ackk: sure, one minute
<mvo> ackk: please try now, I added tzdata - I have a meeting now so replies might be a bit slow
<ackk> mvo, thanks a lot
<mvo> ackk: thanks for all your feedback!
<greyback> jdstrand_: hey, when you get time could you look at https://github.com/snapcore/snapd/pull/4365 - hopefully it's good to go
<mup> PR #4365: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <https://github.com/snapcore/snapd/pull/4365>
<ackk> zyga-ubuntu, out of curiosity, is it known what's the fix for the mount order issue causing the snap removal bug?
<zyga-ubuntu> ackk: yes, very quite so
<ackk> zyga-ubuntu, ah cool, can't wait to have that fixed :)
<mvo> ackk: how are things looking with the updated base?
<zyga-ubuntu> ackk: we iterated on that issue a few times (well, I did) and we are zeroing on something that both works and is security sane
<Chipaca> mvo: so, i'll grab title and summary and put it in a bucket indexed by snap name, ok? (anything else you want in there?)
<ackk> mvo, reinstalling now (had to break for lunch)
<zyga-ubuntu> ackk: I added an action item for myself to look at that with some urgency, we should have some time next week as many people get locked at the sprint and I can work on that
<ackk> zyga-ubuntu, great
<mvo> Chipaca: iirc that is already (well, summary) done in my latest pr, no?
<Chipaca> mvo: ah, i missed that, perfect
<mvo> Chipaca: i.e. it should work end-to-end (except it does not spelling fixes yet)
<Chipaca> mvo: yep, looks fine (almost exactly what i would've done)
<Chipaca> i'll review in depth in a bit
 * Chipaca -> break, first
<zyga-ubuntu> sun is about to set and I dind't have lunch yet
<zyga-ubuntu> tomorrow I'll schedule a walk while it's still bright
<zyga-ubuntu> and move lunch to post-call
<zyga-ubuntu> now food :)
<ackk> mvo, success! init works
<zyga-ubuntu> great work guys!
<ackk> maas doesn't, but that's another issue
<zyga-ubuntu> :-)
<ackk> mvo, zyga-ubuntu, thanks for the support :)
<zyga-ubuntu> first base-18 snap that almost runs ;)
<ackk> mvo, do you think you can push to edge once the distro-info and zoneinfo changes are merged?
<ackk> zyga-ubuntu, yeah :)
<ackk> is /sbin/ip in the xenial snap?
<zyga-ubuntu> no
<mborzecki> guys, is there a valid case when a local client is doing a POST to /v2/login with user data *and* sets an Authorization header?
<zyga-ubuntu> hmmm
 * zyga-ubuntu doesn't know what authorization header does
<zyga-ubuntu> maybe to login as someone else?
<mborzecki> pedronis: mvo: that's probably for you ^^
<pedronis> that's how we send the local macaroon
<pedronis> it would help detect a re-login
<pedronis> IÂ suppose
<mborzecki> hmm then the user.Email from state should be the same as in body login data, right?
<mborzecki> some context maybe, so the user is logging in, there's a macaroon, username and an email, say foo@bar.com in ~/.snap/auth.json, then the user does snap login --email bar@bar.com, gets a macaroon, but the email in the response is foo@bar.com instead of bar@bar.com
<pedronis> that can happen I suppose if one doesn't use their main SSOÂ email
<pedronis> matiasb might tell more about that
<matiasb> mborzecki, pedronis, right, I think the email in the response is the preferred SSO email address
<ackk> zyga-ubuntu, is something different WRT /bin and /sbin if you use a base?
<ackk> zyga-ubuntu, what I see in the /sbin and /bin in my snap (from the prime dir) is not there if I snap run --shell
 * pstolowski lunch
<zyga-ubuntu> ackk: /bin and /sbin should come directly from the designated base snap (here base-18)
<zyga-ubuntu> ackk: what do you see?
<zyga-ubuntu> ackk: more precisely
<ogra_> if it is in your prime dir it sould be in Â§SNAP/bin and $SNAP/sbin
<zyga-ubuntu> ackk: / should be from your base snap
<ackk> zyga-ubuntu, but can a snap add stuff to them?
<zyga-ubuntu> ackk: with layouts, that's coming soon but not in master yet
<ogra_> god forbid !
<ogra_> :)
<zyga-ubuntu> ackk: https://forum.snapcraft.io/t/layouts-re-mapping-snap-directories/1471
<ackk> so what we have for xenial can't work with the base :/
<zyga-ubuntu> ackk: can you expand/explain?
<zyga-ubuntu> ackk: you get to choose the base you want
<zyga-ubuntu> ackk: you switched to bionic, is that not good?
<mvo> yeah, curious as well what is missing in base-18
<zyga-ubuntu> mvo: I suspect ackk will want /sbin/ip
<ackk> zyga-ubuntu, mvo yes, the maas snap installs/symlinks a lot of stuff in /bin/ and /sbin, which works in xenial
<mborzecki> matiasb: pedronis: sorry, i probably didn't make that clear, i have a local macaroon, id and email in ~/.snap/auth.json (local for snapd), now i login with a different email address assigned to a different sso account, what I see in snapd is the local email not getting updated for the user with that ID in state.json and thus the ~/.snap/auth.json email does not get updated either
<zyga-ubuntu> ackk, mvo: note that the base apparmor template and all the interfaces don't care (know) about bases yet so we may need to do more work to allow -18 specific or -16 specific functionality
<zyga-ubuntu> ackk: how can it work in xenial and not in bionic based snap (I assume it's still a snap and not something else)
<ogra_> classic ?
<ackk> zyga-ubuntu, xenial without base and bionic with base yes
<zyga-ubuntu> ackk: is it a classic snap?
<ackk> no, it's --devmode
<zyga-ubuntu> ackk: in devmode /usr/bin is still a read only squashfs
<zyga-ubuntu> ackk: can you show me what you do?
<ackk> zyga-ubuntu, https://git.launchpad.net/~ack/maas/tree/snap/snapcraft.yaml?h=snap-bionic-fixes
<zyga-ubuntu> ackk: and where do you put anything in /usr/bin or /bin?
<pedronis> mborzecki: well,   updating makes sense only if you have a valid ID as determined by the local macaroon
<ackk> zyga-ubuntu, stage-packages: does (specifically because iproute2)
<zyga-ubuntu> ackk: stage packages are unpacked to $SNAP/ no to /
<zyga-ubuntu> ackk: that hasn't changed at all
<ackk> zyga-ubuntu, https://paste.ubuntu.com/26353268/ (from the prime/ dir)
<zyga-ubuntu> ackk: maybe some path settings are wrong, this should not behave any different than base-18-based snap
<zyga-ubuntu> ackk: but all of the prime dir is mounted at $SNAP (/snap/maas/1234)
<zyga-ubuntu> ackk: you cannot add anything to real /usr/bin
<pedronis> mborzecki: otherwise updating has no clear target
<pedronis> but IÂ don't know how that code looks like at all
<zyga-ubuntu> ackk: all I'm saying is that you don't have any new limitations
<ackk> zyga-ubuntu, mhm, then it might be a path issue
<zyga-ubuntu> ackk: look at $PATH
<ackk> zyga-ubuntu, I see, then I'll dig further
<zyga-ubuntu> ackk: maybe snapcraft did something before and now you need to do it manualyl
<zyga-ubuntu> *manually
 * ackk checks the xenial snap
<ackk> zyga-ubuntu, /sbin/ip *is* there in  xenaial core
<zyga-ubuntu> ackk: indeed, my find was ... weird?
<ackk> zyga-ubuntu, I get permission denied trying to run it with snap run --shell hello-world, but maas can since it's a devmode snap
 * zyga-ubuntu wonders why: find /snap-core-current -name ip 
<zyga-ubuntu> didn't see it
<zyga-ubuntu> wehh
 * zyga-ubuntu wonders why: find /snap/core/current -name ip 
<sergiusens> hello
<ackk> zyga-ubuntu, I guess we should really use $SNAP/bin/ip
<zyga-ubuntu> yes
<ackk> zyga-ubuntu, IOW prepend $SNAP/sbin $SNAP/bin to our paths
<zyga-ubuntu> ackk: until you can splay $SNAP/bin/ip to /bin/ip with layouts that is
 * mborzecki off to pick up the gkids
<kalikiana> sergiusens: o/
 * kalikiana going on lunch break shortly
<matiasb> mborzecki, after taking a look, I see your point: it seems the local/state email information is not updated when you switch to a different SSO account without logout, only the auth bits are updated (ie. the macaroons); pedronis, fyi too <-
<mup> PR core#71 opened: live-build: make /lib64/ld-linux-x86-64.so.2 a relative link <Created by mvo5> <https://github.com/snapcore/core/pull/71>
<elopio> good morning
<mborzecki> matiasb: right, i've made a change to update the users's email, the whole diff is something in the lines of https://paste.ubuntu.com/26353503/
<mup> PR snapd#4460 closed: daemon: store email, ID and macaroon when creating a new user <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4460>
<mup> Issue snapcraft#1816 closed: snapcraft update won't fetch from `SNAPCRAFT_PARTS_URI` <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1816>
<mup> PR snapcraft#1856 closed: remote_parts: Use hashed folder based on parts URI <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1856>
<ackk> zyga-ubuntu, mvo  after fixing hardcoded path issues with /sbin/ip, maas works!
<ackk> quick, ship base-18! :)
<matiasb> mborzecki, yeah, makes sense to me
<mvo> ackk: ha! lets hope the builders get back online soon
<mborzecki> matiasb: thanks
<zyga-ubuntu> ackk: ahead of 18.04
<zyga-ubuntu> that'd be a first
<zyga-ubuntu> good work :)
<mvo> ackk: yeah, nice job!
<tedg> Hmm, okay. I guess builders being down is why the discord snap isn't getting built.
<kalikiana> re
<zyga-ubuntu> I need a break, I'm so sleepy
<zyga-ubuntu> 16:30 - night
<zyga-ubuntu> I hate north
<kalikiana> zyga-ubuntu: never go to Finland :-P
<zyga-ubuntu> kalikiana: or just in the summer
 * kalikiana likes Finland but struggled with the lack of sun in winter
<sergiusens> zyga-ubuntu come to South America; this was my weeked -> https://www.instagram.com/p/BdpvFoUFBVH/?taken-by=sergiusens
<zyga-ubuntu> sergiusens: I would never leave and my wife would hate my and my kids would cry
<Chipaca> mvo: that progress spinner doesn't look too good on a linux vt :-(
<zyga-ubuntu> Chipaca: linux vt is a bit limited
<zyga-ubuntu> Chipaca: you get to have 256 characters in two sets
<Chipaca> zyga-ubuntu: i know
<Chipaca> zyga-ubuntu: looks like if it's important, it needs to be ascii for the terminal
<Chipaca> vt i mean
 * Chipaca unsure what to do
<zyga-ubuntu> Chipaca: curious, can you tweet a photo please?
<zyga-ubuntu> Chipaca: one more question is "how do you know where you are" (which is super hard to answer actually)
<mup> Issue snapcraft#1712 closed: Tutorial for circle-ci <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1712>
<mup> PR snapcraft#1857 opened: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<Chipaca> zyga-ubuntu: it depends on what font you're using on the terminal; you might get a square, *or*, a rhombus
<zyga-ubuntu> Chipaca: but my recommendation is to forgo any fanciness
 * Chipaca takes his bowtie off
<zyga-ubuntu> Chipaca: yes, though on the terminal we could actually ask and even load the right font
<Chipaca> zyga-ubuntu: there is no font with braille :-)
<zyga-ubuntu> Chipaca: ioctl_console(2)
<zyga-ubuntu> Chipaca: my pet project desires me to explore that man page
<Chipaca> zyga-ubuntu: console_ioctl but yes
<zyga-ubuntu> Chipaca: no, it's actually ioctl_console, I have it open
<Chipaca> zyga-ubuntu: in xenial it's console_ioctl(4)
<zyga-ubuntu> oh, interesting
<Chipaca> zyga-ubuntu: and there is no ioctl_console(2)
<zyga-ubuntu> I wonder if that's just a rename
<zyga-ubuntu> at some point systemd wanted to provide a KMS based console with real support for everything
<zyga-ubuntu> but I think that died or at least isn't deployed
<kalikiana> kyrofa: elopio FYI snapcraft#1639 is green now, with the revert - also snapcraft#1857 is the next piece of the puzzle for updated "on" semantics
<mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<kyrofa> kalikiana, so you don't see the weird test waffling locally anymore?
<Chipaca> zyga-ubuntu: we could make snapd require jfbterm
<zyga-ubuntu> Chipaca: a hard sell for servers
<kalikiana> kyrofa: Neither locally nor on Travis (both hit it before)
<zyga-ubuntu> Chipaca: can we just do /|\- style animation?
<Chipaca> zyga-ubuntu: i prefer .oOo, but, yes
<Chipaca> (mostly because it bothers me how / and \ don't have the same width)
<zyga-ubuntu> Chipaca: the consequence of that 7 bit space with one bit of unspecified glyphs
<zyga-ubuntu> Chipaca: I wonder if the B-set is populated?
<Chipaca> zyga-ubuntu: showconsolefont
<Chipaca> zyga-ubuntu: answer: yes, but `dpkg-reconfigure console-setup` is all about changing that second half
<zyga-ubuntu> Chipaca: second half as in 9th bit?
<zyga-ubuntu> Chipaca: I don't mean 128..255
<zyga-ubuntu> but 256..512
<zyga-ubuntu> I meant greetings BTW
<Chipaca> zyga-ubuntu: it depends on what font you're loading, if you have that or not
<zyga-ubuntu> hmm
<Chipaca> zyga-ubuntu: but showconsolefont shows you
<zyga-ubuntu> I'm confused now
<zyga-ubuntu> look at the thing I tweeted
<sergiusens> Chipaca zyga-ubuntu we took a lot of criticism for our progress bar not working correctly on emacs
<mup> PR snapcraft#1858 opened: Import run so bin/snapcraft can work <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1858>
<Chipaca> sergiusens: whose progress bar? when?
<Chipaca> sergiusens: in the emacs terminal, or the emacs shell?
<zyga-ubuntu> sergiusens: interesting, so more limitations of the vty thing that emacs supplies
<kalikiana> elopio: Hey! Can you have a look at snapcraft#1858 ? I found myself very confused to find integration tests don't run against git anymore
<mup> PR snapcraft#1858: Import run so bin/snapcraft can work <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1858>
<Chipaca> zyga-ubuntu: i did test ansimeter in emacs :-)
<zyga-ubuntu> it's good that we don't have to test it in vim ;-)
<Chipaca> ah, dunno how to do that :-)
<zyga-ubuntu> Chipaca: since I'm not a emacs person, how do I run emacs and open a terminal to test my stuff?
<Chipaca> zyga-ubuntu: in emacs, M-x term opens a terminal
<Chipaca> zyga-ubuntu: M-x shell runs a shell
<sparkiegeek> zyga-ubuntu: snap install emacs-tealeg
<mborzecki> M-x eshell ftw
<sparkiegeek> TMTOWTDI :)
<mvo> ogra_: thanks for your suggestion about arm64, what does the ld symlink looks like there?
<zyga-ubuntu> mvo: I think snapcraft has a list of those
<Chipaca> mborzecki: ouch, the ansimeter doesn't fare too well in eshell
<Chipaca> it chooses to do reverse as a colour instead of reverse
<sergiusens> zyga-ubuntu mvo linkers? yes indeed
<zyga-ubuntu> yes
<zyga-ubuntu> sergiusens: and learned the hard way for each arch
<ogra_> mvo, ogra@dragonboard:~$ ls -l /lib/ld-linux-aarch64.so.1
<ogra_> lrwxrwxrwx 1 root root 28 Jun 16  2017 /lib/ld-linux-aarch64.so.1 -> aarch64-linux-gnu/ld-2.23.so
<ogra_> ogra@dragonboard:~$
<sparkiegeek> show_fancy_progress = False if 'EMACS' in os.environ else show_fancy_progress
<Chipaca> mborzecki: eshell also doesn't respect the "turn off the cursor" escape
<sergiusens> zyga-ubuntu mvo https://github.com/snapcore/snapcraft/blob/master/snapcraft/_options.py#L31
<Chipaca> mborzecki: booo
<Chipaca> (neither does eterm, fwiw)
<Chipaca> ANYhow
<sergiusens> zyga-ubuntu mvo and here is the logic to unpack it https://github.com/snapcore/snapcraft/blob/master/snapcraft/_options.py#L226
<zyga-ubuntu> man, I'm running emacs
 * Chipaca hugs the braille spinner, and sends it into the void
<mvo> ogra_: oh, this link is already relative?
<sparkiegeek> zyga-ubuntu: you think you're running emacs, in reality, emacs is running you
<mborzecki> well, it does have some killer features, org-mode, magit, elisp
<mborzecki> wish it was more stable with ediff though, sometimes it just starts spinning and takes 100% cpu :/
<sparkiegeek> mborzecki: not forgetting the builtin psychotherapist, and  M-x butterfly
<zyga-ubuntu> what is that, I just ran it
<Chipaca> zyga-ubuntu: it randomizes your files, for extra productivity
<Chipaca> the butterfly effect and all that
<elopio> kalikiana: yes, weird. I will try to bisect it to see what caused the problem.
<mup> PR snapcraft#1859 opened: adding option to decompress tar.lzma cleanly <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1859>
<kalikiana> elopio: Thanks!
 * kalikiana wrapping up for today
<ackk> mvo, I'm getting a "setlocale: No such file or directory" error message when I run virsh (although the program itself seems to works)
<ackk> mvo, is it something that also needs adding to the base?
<zyga-ubuntu> ackk: base snaps don't ship any locale
<zyga-ubuntu> ackk: I'd ignore that _for now_; it's a big topic for us to explore IMO
<zyga-ubuntu> ackk: with no (apparently) easy answers
<ackk> I see
<zyga-ubuntu> Pharaoh_Atem: selinux-policy now builds straight from github
<zyga-ubuntu> maybe we could merge the snapd policy there and only keep the package for any unmerged TODOs
<Pharaoh_Atem> maybe
<Pharaoh_Atem> but it has to work first
<Pharaoh_Atem> and it doesn't
<Pharaoh_Atem> snapd still needs SELinux awareness
<zyga-ubuntu> well, little by little, most software isn't selinux aware even if there's a selinux policy covering it
<zyga-ubuntu> I think those are orthogonal
<Pharaoh_Atem> in most cases, they are
<Pharaoh_Atem> in this case, no
<Pharaoh_Atem> snapd itself does security things itself
<Pharaoh_Atem> my hope was that the selinux policy would be augmented by snapd itself generating policies to apply with the defined labels
<zyga-ubuntu> yes but not with selinux so it's not a blocker in my eyes
<zyga-ubuntu> Pharaoh_Atem: apart form the policy we need to figure out FS relableling and nobody is working on that
<zyga-ubuntu> Pharaoh_Atem: lots of things to explore
<Pharaoh_Atem> well, I can talk to Lukas about it
<zyga-ubuntu> worth a try
<zyga-ubuntu> not saying we have to
<zyga-ubuntu> but looks like one less thing to package (eventually)
 * Pharaoh_Atem shrugs
<Pharaoh_Atem> we'd have to keep it for CI testing anyway
<zyga-ubuntu> yes, I suppose so
<zyga-ubuntu> Pharaoh_Atem: I'm feeling excited today
<zyga-ubuntu> Pharaoh_Atem: my eternal task looks close to being done
<zyga-ubuntu> Pharaoh_Atem: I actually wonder what I'll do next (plenty of things to do but not sure as I haven't discusse that yet0
 * Chipaca <- stupid poo-face
<zyga-ubuntu> what happened?
<mup> PR snapd#4450 closed: snap: support `command-not-found` symlink for `snap advise-command` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4450>
<Chipaca> zyga-ubuntu: twice i brought up an ubuntu-core in linode to test something, before realising that the reason it was failing in a different place than in travis was because i had some stuff lying around here that wasn't in git
<zyga-ubuntu> doh ;)
<Chipaca> quite
<zyga-ubuntu> it's good that we lave linode though
<zyga-ubuntu> imagine doing that on our laptops 24/7
<Chipaca> zyga-ubuntu: http://i.imgur.com/eVNrdel.gifv
<mup> PR snapd#4462 closed: progress: switch ansimeter's Spin() to use a spinner <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4462>
<zyga-ubuntu> lol
<zyga-ubuntu> I wonder if movie designers have a meme-ist among permanent staff
<zyga-ubuntu> ok, I should _probably_ break now
<zyga-ubuntu> ttyl
<Chipaca> zyga-ubuntu: I know that a lot of regulars on /r/HighQualityGifs work in the industry
<zyga-ubuntu> I'm glad I don't do reddit
<zyga-ubuntu> if I did I would have even less live
<zyga-ubuntu> life
<zyga-ubuntu> man, see what kind of mistakes I make
<zyga-ubuntu> Chipaca: question, do you have any magic command that shows me coverage in a browser and that updates as I edit code?
<zyga-ubuntu> I run: ls *.go | entr -c go test
<zyga-ubuntu> but I'd like that to do live coverage updates
<zyga-ubuntu> I also have an alias: ggg
<zyga-ubuntu> go test -cover -coverprofile=coverage.out && go tool cover -html=coverage.out
<zyga-ubuntu> but that opens new tab in firefox
<zyga-ubuntu> ideally it'd overlay in $editor (but that's fancy)
<Chipaca> zyga-ubuntu: uh
<Chipaca> zyga-ubuntu: maybe? not very magic though
<Chipaca> zyga-ubuntu: go test -coverprofile .coverage/profile.out -v ./snap/squashfs/ && GOPATH=~/canonical/snappy go tool cover -o /tmp/coverage.html -html=.coverage/profile.out
<Chipaca> zyga-ubuntu: and then i open /tmp/coverage.html in the browser
<zyga-ubuntu> yeah but what would keep it live?
<Chipaca> zyga-ubuntu: "keep it live" no, but it's usually fast enough
<Chipaca> and because i'm explicitly telling it to write to that file it doesn't open a new page every time, which means it stays on the same file
<Chipaca> beyond that, no
<Chipaca> zyga-ubuntu: maybe goland does that?
<Chipaca> zyga-ubuntu: (snap install goland?)
<zyga-ubuntu> oh
<zyga-ubuntu> I'll look, just curious
<Chipaca> zyga-ubuntu: https://www.jetbrains.com/go/features/ says "If you run your code with a coverage instruction, the IDE collects the data and displays it in both the aggregated view and per statement in the Editor."
<zyga-ubuntu> ooooh
<zyga-ubuntu> man
<zyga-ubuntu> I will probably sell vim
<zyga-ubuntu> and get into one of those
<Chipaca> pedronis: hah! i was wondering about that failure
<Chipaca> pedronis: couldn't you also have fixed it by feeding jq from stdin instead of asking it to open the file?
<zyga-ubuntu> Chipaca: which failure?:
<sergiusens> kyrofa elopio hey, I have updated snapcraft#1850 can you please take another look?
<mup> PR snapcraft#1850: pluginhandler: patch and handle elf files on glibc mismatch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1850>
<pedronis> Chipaca: yes, but we do install with --devmode elsewhere
<pedronis> what I see true is that given the change I could have simplified some other lines
<pedronis> Chipaca: prepare.sh ,  auto-refresh/task.yaml and this have that choice to make
<sergiusens> elopio would be nice if you follow up on snapcraft#1849
<mup> PR snapcraft#1849: tests: add snap not found tests <codein> <Created by daniellimws> <https://github.com/snapcore/snapcraft/pull/1849>
<nacc> should /var/lib/snapd/hostfs have contents, generally?
<zyga-ubuntu> nacc: it dpeends on one's perspective
<zyga-ubuntu> nacc: on your regular host it should be empty
<zyga-ubuntu> nacc: from a snap's POV it should contain your hosts' root filesystem (with some exceptions)
<zyga-ubuntu> nacc: naturally confinement is in the way so you won't see that unless in devmode
<zyga-ubuntu> nacc: but some things are "brought over" from there (notably fonts)
<nacc> zyga-ubuntu: got it
<zyga-ubuntu> nacc: :-)
<kyrofa> sergiusens, I'm testing out this libc branch
<sergiusens> kyrofa great; I tried with https://pastebin.ubuntu.com/26355121/ from bionic
<kyrofa> And I'm realizing is_linker_compatible isn't quite doing what I thought it was doing. It's comparing the version of the linker against the glibc version, which is vastly different, is it not?
<sergiusens> kyrofa the linker is part of glibc
<kyrofa> I ran it on zesty, which uses gcc 2.4, and it compared that against 2.23 and decided it was happy with it
<kyrofa> Not gcc, sorry
<kyrofa> I expected it to grab the newer glibc, but it didn't
<sergiusens> kyrofa zesty didn't bump the glibc requirement, that's why all our adt tests still pass there :-)
<sergiusens> you need artful or bionic to trigger this
<kyrofa> Argh
<sergiusens> kyrofa 2.23 linker is still good for the linker in zesty (even if the version is greater).
<sergiusens> kyrofa if everything is correct, adt for bionic and artful will pass with glaring colours
<kyrofa> Man, my connection to the image server is brutal today. I'm getting like 20k
<zyga-ubuntu> curious, I saw uber-slow 90K to archive.u.c
<sergiusens> kyrofa tough luck I guess; hope you like my approach to testing with runnables btw; I think I want us to move down that path for every other thing we have
<kyrofa> Seems python-apt requires libdpkg-perl on artful
<kyrofa> sergiusens, I do indeed. More work upfront, but definitely testing more
<sergiusens> kyrofa heh, that dep rings a bell; oh, when installing from debs; probably a bad dep as well; I saw that too
 * sergiusens will bbl later in the evening
<kyrofa> sergiusens, I was using a venv, so we'll just need to add it to HACKING.md
<kyrofa> Seems that it needs to access /usr/share/dpkg/no-pie-compile.specs
<sergiusens> kyrofa yes; I ran into that as well, I recall now
 * sergiusens decided to not leave
<sergiusens> kyrofa the only reason I didn't move it into fixtures_setup is because it is so big and I believe it has the wrong name
<sergiusens> kyrofa I suspect travis has kernel patches for Meltdown and is the reason for the timeouts we see now?
<kyrofa> sergiusens, hmm, you think it has that much of an impact? That would suck
<kyrofa> I didn't anticipate that it would be much
<kyrofa> Also... WE don't even have mitigation yet. How do they?
<sergiusens> kyrofa I thought GCE already patched and java took the biggest hit; coincidentally we timeout while building with ant in one task and dotnet in another (which I suspect would take a similar hit)
<sergiusens> I haven't done any deep analysis or anything though so refuting what I say should be rather easy ;-)
<kyrofa> Innnteresting...
<mup> PR snapcraft#1858 closed: Import run so bin/snapcraft can work <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1858>
<mup> PR snapcraft#1859 closed: adding option to decompress tar.lzma cleanly <Created by heesen3> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1859>
<nacc> i forget who suggested it to me, but the idea of bind-mounting writable directories over a classic snap's filesystem is going to speed up debugging incredibly for me
<mup> PR snapcraft#1860 opened: setup: simplify bin/snapcraft and correct tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1860>
<sergiusens> kyrofa elopio ^
<sergiusens> kyrofa snapcraft.tests.integration.plugins.test_ant_plugin.AntPluginTestCase.test_build_ant_plugin takes 15 minutes for me locally. Mind checking?
#snappy 2018-01-10
<seyeongkim> hello, is there a way to install older revision of core?
<mup> PR snapcraft#1861 opened: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861>
<mborzecki> morning
<zyga-ubuntu> o/
 * zyga-ubuntu is tad sleepy
<zyga-ubuntu> hacking till 2AM
<zyga-ubuntu> I'll go back to bed
<mborzecki> zyga-ubuntu: hey
<mborzecki> mvo: morning
<mup> PR snapd#4458 closed: overlord/snapstate: no refresh just for hints if there was a recent regular full refresh <Reviewed> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4458>
<mvo> hey mborzecki - good monring
<mup> PR snapd#4456 closed:  snap: rename `snap advise-command` to `snap advise-snap --command`  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4456>
<mup> PR snapd#4463 opened: client, daemon: update user's email when logging in with new account <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4463>
<kalikiana> good morning
<mborzecki> kalikiana: morning
<mup> PR snapd#4394 closed: snap: give the snap.Container interface a Walk method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4394>
<zyga-ubuntu> hey
<zyga-ubuntu> back now, I think I owe everyone some reviews
<zyga-ubuntu> I took 4452 and went wild on unit tests
<zyga-ubuntu> found an obscure bug with symlinks (and fixed it)
<zyga-ubuntu> but grew the branch to a big extreme sizes
<zyga-ubuntu> I will probably double back and propse all the unit test changes separately, though not sure if that will help
<zyga-ubuntu> I'll get a coffee and start chopping
<zyga-ubuntu> all right
<mup> PR snapd#4464 opened: overlord/snapstate: add validateContainer, that uses snap.Container's <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>
<Chipaca> mvo: thank you for merging #4394! As a recompense, here's 4464 ^-^
<mup> PR #4394: snap: give the snap.Container interface a Walk method <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4394>
<Chipaca> oh dear, commit message murder
 * Chipaca tidies
 * kalikiana coffee
<mvo> Chipaca: thanks for the code update. it was very nice
<pedronis> Chipaca: hi, did you see my comment last night?  we install jq with --devmode in other tests,  do you have a preference for not doing that everywhere?
<Chipaca> pedronis: it seems tidier to me to not use devmode for that -- we disrecommend devmode for good reasons, but if at the first problem _we_ switch to devmode, â¦ :-)
<pedronis> Chipaca: well, not these days people publish as classic instead
<Chipaca> pedronis: same argument there though
<Chipaca> pedronis: but just to be clear, it's merely a sense of tidiness, nothing more
<pedronis> IÂ found our tests not very tidy in general, but maybe it's just me
<Chipaca> pedronis: that's fair
<pedronis> IÂ mean, I feel when writing spread tests that my tidniness setting is medium
<zyga-ubuntu> pedronis: hehe, how does that materialize?
<Chipaca> zyga-ubuntu: I'm assuming if it were higher than that there'd be infinite PRs from samuele trying to beat our spread suite into submission
<pedronis> Chipaca: either way, switching away from --devmode for jq would be a PR, as I said it's done in a couple of places, starting with prepare.sh
<Chipaca> pedronis: no worries
<pedronis> Chipaca: if we do that it become tempting to introduce some kind of jq_modify_state helper (but maybe we already have too many obscure helpers we don't remember about)
<mvo> Chipaca: you have a review
<mvo> Chipaca: nice job btw
<mvo> a second review for 4454 would be nice, should be trivial
<mup> PR snapd#4454 closed: snap: fix gadget.yaml parsing for multi volume gadgets <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4454>
<mvo> pedronis: I think https://github.com/snapcore/snapd/pull/4356 is ready for a re-review
<mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
<pedronis> I'll look at it today
<mvo> ta
 * Chipaca -> bbiab (physio)
<kalikiana> woot, --ammend wouldn't have been my choice of name, but nice to see this
<mvo> kalikiana: not too late for suggestions :)
<mvo> kalikiana: in the PR please, they will need sign off from gustavo
<kalikiana> Aye, will comment there
<mvo> popey: hey, we 1742247> what version of snapd did you use to make this workaround work?
<mvo> popey: fwiw, the message got improved to be ambiguous, it now says "snap foo is no longer tracking %s"
<mvo> (in master)
<popey> mvo: I'm on core from candidate
<mvo> popey: ta, let me try to reproduce with that
<mvo> mborzecki: https://travis-ci.org/snapcore/snapd/builds/327128264#L1541 is probably something you want to look at
<mvo> mborzecki: (context is 4463)
<mborzecki> mvo: thanks, looking now
<mvo> also 4461 is tiny and needs a second review
<zyga-ubuntu> hmm, github is not responding here
<kalikiana> popey: ping wrt bug 1741752
<mup> Bug #1741752: yaml.constructor.ConstructorError: could not determine a constructor for the tag '!ExtractedMetadata' <Snapcraft:New> <https://launchpad.net/bugs/1741752>
<popey> kalikiana: hello
<kalikiana> popey: Hey. How are you this morning?
<popey> Super, how are you? :)
<kalikiana> Very well. There's a little bit of sun today so that"s rare and awesome :-D
<zyga-ubuntu> https://status.github.com/messages
<zyga-ubuntu> it's down
<kalikiana> popey: I'd just like to clarify what you wrote in the bug if possible. In the description you said `usually if I re-run or clean, it goes away` but later replied `definitely didn't do lxc delete, and don't believe I did snapcraft clean`
<popey> that's right
<popey> what I do is run snapcraft, the thing needs rebuilding so I re-run snapcraft. Then the error appears
<kalikiana> popey: Maybe the expected behavior isn't very clear. When you do `snapcraft clean`with persistent containers enabled, that equates to deleting the container if you don't pass more arguments.
<popey> Yes. That's what I expect. But as I said, I didn't clean. But I _have_ to clean to get past this error
<kalikiana> eg. `snapcraft clean mypart` would *not* delete it
<kalikiana> popey: You mean if you do `snapcraft clean` the error goes away?
<popey> Yes
<kalikiana> popey: Okay, now that makes sense. I was a bit lost in your wording, sorry :-D
<popey> Ah sorry. Will try harder with my words next time :)
<kalikiana> popey: So, as I said in the comment, re-using an existing container wouldn't pull in a new snapcraft if the revision changed or it's a local build. Can you tell me what might have expected? Maybe we should print a message like `Btw your snapcraft is on a different channel, you may wanna refresh the container`
<popey> Wait, what?
<popey> I don't want to pull in a new snapcraft revision
<popey> I just wanted the software to rebuild, that's all
<popey> and I got smacked in the face with python backtrace and an error at the bottom. I am not trying to update anything, *just* rebuild like a normal developer would as they iterate over a build
<kalikiana> popey: Example, you have snapcraft from beta, build stuff in a container, do `snap refresh snapcraft --channel=edge`, and now your new snapcraft has different expectations
<kalikiana> I think that's what happened, simplified
<popey> I didnt do that
<popey> i just ran snapcraft and then ran snapcraft again
<popey> you're saying snapd refreshed in the minute or two between running snapcraft and running it again?
<mup> PR snapd#4457 closed: spread: trying to re-enable tests on Fedora <Reviewed> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4457>
<kalikiana> popey: So you were using edge the whole time?
<kalikiana> Please bear with me, I'm just trying to get the exact situation
<popey> yes
<kalikiana> popey: So then it must've been snapd refreshing out of sync on your host vs. container
<kalikiana> Which is possible since we don't force that
<popey> kalikiana: tell you what, lets park that bug, and I will try and re-produce it.
<popey> And get a better "steps to reproduce" okay?
<popey> because it's all a bit muddy now :)
<popey> (unless you fully understand it now and know what to fix) :D
<mup> PR snapd#4461 closed: snap: fix missing error check when multiple snaps are refreshed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4461>
<zyga-ubuntu> mvo: 1st of the easy branches: https://github.com/snapcore/snapd/pull/4465/files
<mup> PR #4465: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465>
<mup> PR snapd#4465 opened: cmd/snap-update-ns: new test features <Created by zyga> <https://github.com/snapcore/snapd/pull/4465>
<sparkiegeek> mvo: anything I can do to help #1735344 along?
<mup> Bug #1735344: [SRU] 2.30 <snapd (Ubuntu):Confirmed> <snapd (Ubuntu Trusty):Confirmed> <snapd (Ubuntu Xenial):Confirmed> <snapd (Ubuntu Zesty):Confirmed> <snapd (Ubuntu Artful):Confirmed> <https://launchpad.net/bugs/1735344>
<mvo> niemeyer: hey, for late, do the strings in 4441 look good to you ? this pr is mostly a tiny string change
<mvo> sparkiegeek: a good question, it is still in unapproved. I assume apw is just super busy with spectre/meltdown and all this madness
 * sparkiegeek nods
<apw> i am cirtaonly that, plus it won't build even if i accept it
<mvo> apw: aha, indeed, that is the other issue :)
 * mvo hugs apw for tireless work to protect us again
<sparkiegeek> mvo: just to confirm, to get 2.30 in the meantime, I should use  ppa:snappy-dev/edge ?
 * sparkiegeek joins mvo in hugging apw
<sparkiegeek> on systems that don't have core installed and need ... configuration
<kalikiana> popey: Yeah, I think I know what's going on now. Incompatible `snap/.snapcraft/state`. I'll figure something out with elopio
<mvo> sparkiegeek: the stable core got updated so you should have it via re-exec. if you prefer the deb you can add "apt-add-repository ppa:snappy-dev/image"
<mvo> sparkiegeek: its there for xenial,zesty,artful
<kalikiana> popey: Thanks for clarifying the missing pieces of the puzzle!
<mvo> sparkiegeek: and I think trusty but I doubt you care about that
<mup> PR snapd#4436 closed:  snap: do not leak internal errors on install/refresh etc  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4436>
<popey> kalikiana: awesome
<mvo> niemeyer: if you have a bit of time (hard I know) double checking the strings in 4382 and 4441 would be great. just to make sure everything is consistent
<zyga-ubuntu> mvo: 2nd and tiny trivial PR: https://github.com/snapcore/snapd/pull/4466
<mup> PR #4466: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466>
<mup> PR snapd#4466 opened: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <https://github.com/snapcore/snapd/pull/4466>
<zyga-ubuntu> mvo: 3rd trival PR: https://github.com/snapcore/snapd/pull/4467
<mup> PR #4467: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467>
<mup> PR snapd#4334 closed: tests: ensure snap-confine apparmor profile is parsable <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4334>
<mup> PR snapd#4467 opened: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <https://github.com/snapcore/snapd/pull/4467>
<zyga-ubuntu> mvo: 4th: ^
<mup> PR snapd#4468 opened: cmd/snap-update-ns: we don't want to bind mount symlinks <Created by zyga> <https://github.com/snapcore/snapd/pull/4468>
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> now the main dish, this will take a little longer to prepare
<mup> PR snapd#4452 closed: cmd/snap-update-ns: enable writable mimic, allow content sharing to $SNAP <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4452>
<zyga-ubuntu> mvo: I have the rest but I need this batch to land, I'll switch to review to help others now
<zyga-ubuntu> mvo: if you can review 4465, 4466, 4467 and 4468 it will help me a lot, they are all small
<mvo> zyga-ubuntu: ok
<niemeyer> mvo: Thanks, will look at that next
<zyga-ubuntu> hey niemeyer, good morning :)
<mvo> niemeyer: thanks! really just a quick ack/nack on the strings
<mvo> niemeyer: and good morning :)
<niemeyer> Moin!
<pstolowski> morning!
 * Son_Goku rises from the dead
<zyga-ubuntu> Son_Goku: hey
 * zyga-ubuntu hands Son_Goku a coffee
<zyga-ubuntu> mborzecki: you have a review on 4449
 * Son_Goku stares at the coffee
<mborzecki> zyga-ubuntu: thanks
<niemeyer> mvo: What's the background for #4441?
<mup> PR #4441: snap: add usage hints in `snap download` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4441>
<mvo> niemeyer: a bugreport
<mvo> niemeyer: it should be referenced in the PR - its fine if this is a won't-fix of course
<niemeyer> mvo: I'm asking because it felt curious to just throw the --help in this case, when this is the normal workflow for download and the vast majority of cases people using download won't be interested in these pages
<niemeyer> mvo: What was the report? People lacking ack?
<mvo> niemeyer: yeah, people did not know apparently that "snap ack" exists/can be used to import the assertion
<niemeyer> mvo: Okay, maybe we can be more direct then and give the command names
<niemeyer> command lines
<niemeyer> mvo: I'll suggest something for your consideration there
<mvo> niemeyer: +1
<mvo> niemeyer: thank you!
<mvo> zyga-ubuntu: re 4449> what I am missing here is why the tests test for *both* messages - the "use debug build" and in the same test also with debug enabled it tests for the real message. or am I reading it incorrectly?
<zyga-ubuntu> mvo: not sure, I think it's not relevant to the issue that mborzecki wanted to fix (building with debug actually getting a debug binary)
<zyga-ubuntu> mvo: in the debug binary those will be visible
<zyga-ubuntu> mvo: I think the 2nd part is not strictly needed
<mvo> zyga-ubuntu: right, but still, why are the tests expecting two lines now, one with "hidden" and then "the real thing"?
<zyga-ubuntu> mvo: I don't know :)
<mborzecki> zyga-ubuntu: mvo: there are 2 parts, one is getting a debug binary, the other is incorrect error message from a failed [u]mount when SNAP_CONFINE_DEBUG is enabled
<niemeyer> mvo: np, please have a look to see what you think
<mborzecki> basically when you have a non-debug build and run with SNAP_CONFINE_DEBUG you'll see `cannot perform operation: (disabled) use debug build to see details`
<zyga-ubuntu> mborzecki: that's the desired behavior
<mborzecki> zyga-ubuntu: ok, but then but if you turn SNAP_CONFINE_DEBUG off you'll see `cannot perform operation: mount -t blah blah`
<mvo> mborzecki: lol, really?
<mborzecki> yes, that's what the PR is fixing
<zyga-ubuntu> mborzecki: hmmm :)
<mvo> mborzecki: ok, then I just don't understand the test in https://github.com/snapcore/snapd/pull/4449/files#diff-70758630224dcb7ba3963d1fa05bb69aR234 - it seems to check for both message on stderr, no?
<mup> PR #4449: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4449>
<zyga-ubuntu> mborzecki: that's probably confusing, are you sure we render the messages in non-debug builds?
<zyga-ubuntu> mborzecki: I've seen the disabled message countless times
<zyga-ubuntu> mborzecki: some messages are hardcoded and not formatted on the fly
<mborzecki> zyga-ubuntu: take a look here: https://forum.snapcraft.io/t/on-arch-snaps-show-broken-after-switch-from-snapd-to-snapd-git/3427, specifically the first message and then the debug log
<mborzecki> popey got:
<mborzecki> [alan@manjarovm ~]$ snap run brave
<mborzecki> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory
<mborzecki> and then when running with SNAP_CONFINE_DEBUG:
<zyga-ubuntu> mborzecki: that particular one may be hardcoded
<zyga-ubuntu> mborzecki: they look the same but come from different places
<mborzecki> cannot perform operation: (disabled) use debug build to see details: No such file or directory
<zyga-ubuntu> mborzecki: DEBUG: performing operation: (disabled) use debug build to see details
<zyga-ubuntu> mborzecki: that's the disabled one
<zyga-ubuntu> mborzecki: I still don't see what's wrong there
<mborzecki> zyga-ubuntu: no SNAP_CONFINE_DEBUG, `cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_gwR9tX//dev: No such file or directory`
<mborzecki> zyga-ubuntu: with SNAP_CONFINE_DEBUG `cannot perform operation: (disabled) use debug build to see details: No such file or directory`
<mborzecki> same binary
<zyga-ubuntu> mborzecki: devil is in the details :) but I see how this is confusing (for me too)
<zyga-ubuntu> mborzecki: it depends on who prints what
<zyga-ubuntu> mborzecki: anyway, I'll look again, thank you for explaining that
<mborzecki> zyga-ubuntu: we're hitting this path: https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/mount-opt.c#L266 then this check https://github.com/snapcore/snapd/blob/master/cmd/libsnap-confine-private/mount-opt.c#L280 neve succeeds so you end up printing the `(disabled) ..` message whem mount/umount fails
<zyga-ubuntu> ohh
<zyga-ubuntu> that's wrong
<zyga-ubuntu> it should not be there
<zyga-ubuntu> that whole thing should go away
<zyga-ubuntu> ah
<zyga-ubuntu> no
<zyga-ubuntu> sorry
<zyga-ubuntu>  :D
<zyga-ubuntu> I just read the comment above it
<zyga-ubuntu> sorry, my mind is rusty about this
<mborzecki> Chipaca: i'm playing with gometalinter and vet tool just raised this: 'advisor/backend.go:178::error: literal copies lock value from *db: github.com/boltdb/bolt.DB contains sync.Pool contains sync.noCopy (vet)'
<mup> PR snapcraft#1831 closed: cli: add expiration option to export-login <enhancement> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1831>
<mup> PR snapcraft#1849 closed: tests: add snap not found tests <codein> <Created by daniellimws> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1849>
 * Chipakeitor looks takes careful aim at Chipaca
<zyga-ubuntu> mborzecki: nice find!
<Chipaca> mborzecki: i'm not sure i understand
<niemeyer> mvo: On the second one, a typo and a suggestion
<mvo> niemeyer: \o/ thank you
<mborzecki> Chipaca: looking into it now, might be false positive
 * zyga-ubuntu goes to cook something, ttyl
<niemeyer> mvo: Thank you!
<Chipaca> mborzecki: I don't mind making boltFinder embed a *bolt.DB instead of a bolt.DB if it makes the liter happy
<Chipaca> linter*
<mborzecki> Chipaca: i guess the tool cannot detect if the pool was used and raises a warning
<Chipaca> mborzecki: and it's fair; there's no guarantee the DB didn't start a maintenance goroutine
<mborzecki> then i think it's fair to embed *botl.DB rather than a copy
 * Chipaca nods
<Chipaca> thanks, metalinter! <plastic grin> <cut to commercial>
 * Chipaca -> dentit
<mup> PR snapd#4469 opened: tests: add hard-coded fully expired macaroons to run related tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4469>
<Chipaca> i might be a few minutes late to the standup
 * Chipaca returning from dentistist
<mborzecki> gometalinter running from run-checks --static https://paste.ubuntu.com/26359996/
<mup> PR snapd#4470 opened: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4470>
<mup> PR snapcraft#1860 closed: setup: simplify bin/snapcraft and correct tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1860>
<mvo> kyrofa, sergiusens what happend to https://github.com/snapcore/snapcraft/pull/1420/files ? I tried to build a snap using that with snapcraft 2.34 and I got an error that "adapter" is unknown. is my snapcraft too old?
<mup> PR snapcraft#1420: add new "no-wrapper" property to apps <enhancement> <Created by mvo5> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1420>
<zyga-ubuntu> Chipakeitor: can you look at 4465-4468 quickly, I'd like to land them to propse the intersting changes that will take longer to review
 * Chipaca looks
<mup> PR snapd#4463 closed: client, daemon: update user's email when logging in with new account <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4463>
<Chipaca> zyga-ubuntu: neat-o
 * kalikiana going to have lunch, back in a bit
 * pstolowski lunch
<mup> PR snapd#4467 closed: cmd/snap-update-ns: untangle upcoming cyclic initialization <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4467>
<mup> PR snapd#4466 closed: interfaces/mount: test OptsToCommonFlags, filter out x-snapd. options <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4466>
<mup> PR snapd#4468 closed: cmd/snap-update-ns: we don't want to bind mount symlinks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4468>
<jamesh> zyga-ubuntu: hi.  Yesterday you mentioned having a chat about user-mounts some time tomorrow  with niemeyer.  Should we set a time?
<zyga-ubuntu> jamesh: hey, yes the plan is to do it tomorrow, you mentioned someting about your morning being preferred
<zyga-ubuntu> let's look at the calendar now
<jamesh> zyga-ubuntu: I thought my evening might be easier
<zyga-ubuntu> ah I must have rembembered wrong then, sorry
<jamesh> I think the biggest time difference is between WA and Brazil
<mborzecki> off to pick up the kids
<zyga-ubuntu> I wish google calendar could show the local time for each participant
<zyga-ubuntu> jamesh: when it's 10AM here (CET+1) what is it for you?
<Chipaca> zyga-ubuntu: i thought you were on CET
<zyga-ubuntu> Chipaca: I never remember if its' CET or +1
<zyga-ubuntu> Chipaca: DST and that
<Chipaca> zyga-ubuntu: your DST is in march
<Chipaca> starts in march, i mean
<jamesh> zyga-ubuntu: WA is UTC+8, so 10AM in UTC+1 would be 5 PM
<zyga-ubuntu> jamesh: that's reasonable for you I think
<zyga-ubuntu> Chipaca: ah, I remembered UTC+1=CET, now it makes sense
<zyga-ubuntu> jamesh: ok I think 10AM it is
<jamesh> zyga-ubuntu: sounds great.
<zyga-ubuntu> hmm, the new calendar has arrived
<zyga-ubuntu> no idea how to add a hangout link
<jamesh> zyga-ubuntu: maybe move it forward a day?
<Chipaca> HAH! a bunch of spread tests failed because the snaps don't pass validation
 * sergiusens ran out to run some errands
<zyga-ubuntu> doh :D
<jamesh> zyga-ubuntu: you've got it scheduled for 5 hours ago
<zyga-ubuntu> sorry, the UI is totally confusing at first sight, I saw vertical stripes which I assumed were days, it's updated now
<zyga-ubuntu> (it were people, not days)
<sergiusens> mvo is your PR tagged with a greater number?
<mvo> sergiusens: it says "milestone: 2.35"
<zyga-ubuntu> jamesh: realistically I think we'll see a lot of mount features ladning next week
<zyga-ubuntu> jamesh: I'm close to enabling layouts, the new content interface will likely land this week
<mvo> sergiusens: hrm, but apparently I only have 2.34 - sorry, let me figure out where I can get 2.35
<zyga-ubuntu> jamesh: your work is also looking very good
<zyga-ubuntu> jamesh: we can look at enabling themes soon, though I don't really know if my I know what your plans for that are
<jamesh> zyga-ubuntu: If there is time, I'd also like to discuss how we could support the dbus app container socket feature
<zyga-ubuntu> I'm not familiar with that, can you share a link so that I can prepare
<jamesh> zyga-ubuntu: https://forum.snapcraft.io/t/interacting-with-dbus-daemons-app-container-feature/3245 has a summary I prepared, plus links to the upstream bugs
<zyga-ubuntu> thank you, I'll read that today
<jamesh> zyga-ubuntu: I've been talking with upstream to try and make sure the feature takes a form we can use, but properly supporting it will require some changes to the way we construct the mount namespaces
<jamesh> since we'd want to inject a new unix socket
<zyga-ubuntu> jamesh: do you have a specific plan (I haven't read everything yet)
<zyga-ubuntu> jamesh: where would it be injected? into the per-user mount ns?
<jamesh> zyga-ubuntu: no specific plan yet.  From that thread, I had some ideas that were shot down.
<zyga-ubuntu> ok
<jamesh> zyga-ubuntu: for the session bus, we probably need to have "snap run" ask some user process to set up the socket in $XDG_RUNTIME_DIR/snap.$pkgname/dbus
<jamesh> zyga-ubuntu: It's less obvious what to do about the system bus
<zyga-ubuntu> jamesh: do you see this as something apps can use transparently or will this be a transition that can break existing snaps?
<jamesh> zyga-ubuntu: apps connect to whatever $DBUS_SESSION_BUS_ADDRESS tells them to connect to.
<zyga-ubuntu> right but I presume the point of this exercise is to put something new at the other end
<jamesh> zyga-ubuntu: this would mainly offer a way for unconfined trusted helpers to identify confined apps in a confinement system independent way
<zyga-ubuntu> some proxy probably
<jamesh> zyga-ubuntu: so e.g. rather than xdg-desktop-portal having code to separately identify when it is talking to a snap or a flatpak, it would check for an app container ID
<jamesh> zyga-ubuntu: the dbus feature also offers a new message filtering ACL system, but we can continue to rely on the existing AppArmor mediation
<zyga-ubuntu> jamesh: how does the container ID thing work?
<jamesh> zyga-ubuntu: some process creates a new listening unix domain socket, and passes it to dbus-daemon along with some metadata (containment system, application identifier, etc).  dbus-daemon will then listen on that socket in addition to its main one, and any connections accepted on the new socket will be tagged with that info
<zyga-ubuntu> ah
<zyga-ubuntu> cool
<zyga-ubuntu> essentially a trusted way to introduce a new socket to dbus
<zyga-ubuntu> is that shipping today?
<zyga-ubuntu> (anywhere)
<zyga-ubuntu> if we roll this out how hard will it be to push it to 14.04
<jamesh> the initial work is in dbus master.  I don't think it's in bionic yet
<jamesh> and some things are in flux
<zyga-ubuntu> jamesh: do you see this as a feature we only enable on some releases/distros?
<zyga-ubuntu> jamesh: and can we easily identify if dbusd has it?
<jamesh> zyga-ubuntu: ideally I'd use it everywhere.  But it will need some kinks worked out
<zyga-ubuntu> jamesh: but we cannot ship it to, say, fedora 26
<jamesh> zyga-ubuntu: the feature is controlled via method calls on the bus daemon: if those method calls are missing, then the feature isn't available.
<zyga-ubuntu> jamesh: I see, that is enough to identify I guess
<jamesh> zyga-ubuntu: this isn't just a feature for snapd though.  It sounds like this is something flatpak wants too, which might help with getting the patches out
<zyga-ubuntu> jamesh: indeed, especially since otherise, my understanding is that dbus filtering in selinux and flatpak in general is not very rich
<jamesh> zyga-ubuntu: I'd like to have some plans about how we'll handle it early, rather than waiting and have it solidify in a form that works for flatpak but is unusable to us
<zyga-ubuntu> (not at all available in flatpak)
<jamesh> zyga-ubuntu: flatpak currently uses a dbus proxy to do its filtering, so this feature lets them get rid of that
<zyga-ubuntu> ah, I see
<zyga-ubuntu> is the new ACL language something you see us adopt in snapd? another securty backend (perhaps part of the existing dbus backend)
<jamesh> zyga-ubuntu: I believe we can mostly ignore the filtering side by installing a wide open ACL and continue to rely on the LSM hooks
<zyga-ubuntu> is there any advantage for us to use it as compared to apparmor
<zyga-ubuntu> jamesh: it could boost our cross distro support
<zyga-ubuntu> jamesh: I wonder if the language is similar enough to let us generate appropriate things automatically
<zyga-ubuntu> either ACLs for dbus-daemon or apparmor profiles
<jamesh> zyga-ubuntu: there are things that dbus's filtering could help us with.  For instance, dbus won't let a process see bus names its ACL doesn't allow
<jamesh> so there could be room for us to include some filtering there.
<elopio> sergiusens: that ant test takes here 3 minutes.
<popey> sergiusens: how can I "unrelease" a snap using snapcraft?
<popey> I need to pull a specific revision from the store. Not all, just one.
<jamesh> zyga-ubuntu: the upstream info about the ACL language is here: https://bugs.freedesktop.org/show_bug.cgi?id=101902 -- I've made some comments there about what I think I'd need (mainly a way to replace the base ACL after the container was created)
<jamesh> zyga-ubuntu: anyway. It's late here, so I'll talk to you tomorrow.
<zyga-ubuntu> jamesh: certainly, thank you for keeping me int the loop! very interesting things
<kalikiana> re
<sergiusens> popey I think that would be accomplished by a  release of the previous revision
<popey> sergiusens: nope, I don't want it released
<popey> I want to *un* release it, not revert it
<sergiusens> We don't have API semantics for unrelease
<sergiusens> close the channel?
<popey> nope
<popey> I want to unrelease one arch
<popey> one revision
<popey> not the entire application/channel
<popey> I'll file a bug if we don't have a way to do it.
<sergiusens> popey I don't think you can and I am not aware of an API that would allow us to do so
<popey> ok, ta :)
<sergiusens> noise][ ideas ^
<noise][> yeah, i don't think we currently cover that use case
<popey> https://bugs.launchpad.net/snapstore/+bug/1742464  here you go then :)
<mup> Bug #1742464: Not obvious how to 'un-release' a revision <Snapcraft:New> <Snap Store:New> <https://launchpad.net/bugs/1742464>
<noise][> thx popey
<popey> noise][: is there some way a store person can ninja this?
<mup> PR snapd#4470 closed: overlord/snapstate: fix gofmt -s -l <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4470>
<sergiusens> elopio hey, about those tests, try with my branch as it does a lot more crawling on files
<elopio> sergiusens: ack.
<noise][> popey: ping in #snapstore, probably can work something out
<popey> ok
<mup> PR snapd#4465 closed: cmd/snap-update-ns: new test features <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4465>
<zyga-ubuntu> Chipaca: FYI https://github.com/snapcore/snapd/pull/4464/files#r160714920
<mup> PR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>
<zyga-ubuntu> mvo: https://github.com/snapcore/snapd/pull/4471
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<mup> PR snapd#4471 opened: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<zyga-ubuntu> mvo: that's the essence of the PR we spoke about in the morning
<zyga-ubuntu> mvo: everything else are just extra tests added on top
<Chipaca> hmmm
<Chipaca> zyga-ubuntu: cannot snap-exec: cannot exec "/snap/snap-hooks/x1/true": exec format error
<Chipaca> zyga-ubuntu: i suspect there's a trivial case not accounted for somewhere :-)
<Chipaca> zyga-ubuntu: the trivial /bin/true is an empty file with the executable bit set
<Chipaca> zyga-ubuntu: looks like we don't support that :-)
<zyga-ubuntu> Chipaca: that's odd, it should be done by the kernel
<zyga-ubuntu> the kernel should invoke /bin/sh
<zyga-ubuntu> anyway
<flexiondotorg> apol: Welcome!
<zyga-ubuntu> Chipaca: can you please look at 4471, just some sanity review on the structure of changePerform
<apol> o/
<Chipaca> zyga-ubuntu: in a mo'
<zyga-ubuntu> Chipaca: I tried hard to make that sane but then ran into a but that caused some extra logic in unexpected places
<zyga-ubuntu> Chipaca: sure, thank you!
<Chipaca> hmmmmmm
<zyga-ubuntu> mm?
<Chipaca> zyga-ubuntu: is the way snap-exec interprets commands intentional? documented?
<zyga-ubuntu> Chipaca: haha, no
<zyga-ubuntu> Chipaca: probably just an evolutionary result of hacking
<Chipaca> zyga-ubuntu: in particular the way it interpolates variables (i think?) and splits on spaces
<Chipaca> (it might not be the one doing the interpolation)
<zyga-ubuntu> "we require more bugfixes" with the starcraft 2 voice
<Chipaca> yes it is snap-exec doing the whole thing
<mup> PR snapd#4472 opened: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
<pstolowski> niemeyer, dang, re plug/slot.DynamicAttrs(), I can get rid of it in policy, and that eliminates one use case, but I've two more uses cases that are slightly problematic (but i've an idea); do you have a moment to discuss before I dive into changing it?
<Chipaca> zyga-ubuntu: https://github.com/snapcore/snapd/blob/master/cmd/snap-exec/main.go#L178 :-)
<niemeyer> pstolowski: Sure
<zyga-ubuntu> Chipaca: not sure what to think about it
<Chipaca> zyga-ubuntu: 's fine
<Chipaca> zyga-ubuntu: i just need to handle it in the validator as well :-)
<pstolowski> niemeyer, standup ho?
<niemeyer> pstolowski: On my way
<mup> PR snapd#4473 opened: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4473>
<mvo> zyga-ubuntu: thanks sorry was distracted mostly by spectre and a bit by the recent pr
<zyga-ubuntu> mvo: sure, no worries :) anything new about spectre?
<mvo> zyga-ubuntu: we have an updated kernel snap
<mvo> zyga-ubuntu: for meltdown, I asked slangasek to build a new image for release.u.c - but there is more work to do
<zyga-ubuntu> mvo: the image is for everything? AFAIK the pi is not affected
<mvo> zyga-ubuntu: thats up to steve, we need an update to at least i386/amd64
<zyga-ubuntu> and then the clouds reboot
<roadmr> hey folks is jdstran-d on vacation maybe?
<kalikiana> kyrofa: Arg, just noticed I hadn't finished my commit for snapcraft#1857 ... pushed it now. Please let me know if you like the revised way of testing. Or if it needs more discussion
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<mvo> roadmr: yeah, he is on vac
<roadmr> mvo: ok, thanks :)
<Chipaca> zyga-ubuntu: which was the pr you wanted me to shake a stick at?
<Chipaca> roadmr: and there are photos to prove it
<brunosfer> Hi guys, I'm trying to make a go application to further embed in a snap. However I do need to know in Go how can I get the list from the snaps installed without throwing a command such as "snap list" and then parse the info.
<Chipaca> brunosfer: you want a snap that can list snaps?
<nacc> brunosfer: or are you trying to depend on other snaps?
<zyga-ubuntu> re, sorry was paying taxes
<zyga-ubuntu> Chipaca: the one that makes changePerform do magic...
<brunosfer> I wanted to reuse the code that exists in the cmd_lists.go to retrieve the list of snaps
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4471
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<zyga-ubuntu> brunosfer: I don't know if you can access that from a snap
<brunosfer> but since that code is private, I will use the cmd line and parse the output with awk and so on...
<zyga-ubuntu> brunosfer: you cannot run "snap" from your snap
<zyga-ubuntu> brunosfer: or it won't do what you would normally be allowed to do
<brunosfer> zyga-ubuntu: yeah, I just got that now after reaind the source code...
<zyga-ubuntu> roadmr: hey, yes, he's off all week AFAIK
<Chipaca> brunosfer: sorry to intrude, but why do you want to list the snaps installed?
<zyga-ubuntu> Chipaca: actually reading my own diff I see some of the comments are stale
<zyga-ubuntu> Chipaca: and could use some facelift
<brunosfer> Chipaca: because I want to check if they need updates with no internet available.
<Chipaca> brunosfer: there are (privileged) interfaces that let you query the snapd api directly
<zyga-ubuntu> brunosfer: are you writing some management software? typically snapd does that
<brunosfer> Chipaca: what are the interfaces?
<Chipaca> brunosfer: so if your snap has snapd-control, you can talk to snapd and ask it (if your lcient is go, you could use the code in client/)
<Chipaca> brunosfer: snapd-control is the name of the interface that gives your snap that permission
<Chipaca> brunosfer: if you want to see what's available, one tool i found very useful is the 'http' snap
<brunosfer> Chipaca: Thank you very much, I will give a look to that.
<Chipaca> brunosfer: the http snap has snapd-control, so it can talk to snapd, and
<brunosfer> Chipaca: I already used the HTTP Flag, but that's for REST requests to the API
<Chipaca> brunosfer: http snapd:////v2/snaps
<Chipaca> brunosfer: lists all the snaps installed
<brunosfer> Chipaca: Awesome. I will check that out
<zyga-ubuntu> good luck :)
<brunosfer> Chipaca: Thanks!
<Chipaca> brunosfer: i don't know what "HTTP Flag" is, but good luck :-)
<brunosfer> zyga-ubuntu: Thanks!
<zyga-ubuntu> Chipaca: the PR goes in tandem with this one https://github.com/snapcore/snapd/pull/4472
<mup> PR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
<zyga-ubuntu> it's a tiny tiny diff that shows you what's new
<brunosfer> Chipaca: I was talking about this "sudo SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=3 /usr/lib/snapd/snapd"
<Chipaca> ah :) yes
<Chipaca> zyga-ubuntu: given your comments about the comments, should i wait before looking at 4471?
<zyga-ubuntu> Chipaca: no, they are not that wrong
<zyga-ubuntu> just a bit weirdly worded
<zyga-ubuntu> Chipaca: and I'm on a clock
<zyga-ubuntu> Chipaca: this cannot be proposed yet but a spread test for this is here; https://github.com/zyga/snapd/commit/617739eee69faf483dee8cad3ae241a1c5b08b57
 * kalikiana calling it a day
<brunosfer> Chipaca: Do you know how can I query directly the API locally?
<Chipaca> brunosfer: it depends exactly what you mean by 'directly' and 'locally' :-)
<Chipaca> brunosfer: from inside the snap?
<Chipaca> brunosfer: or do you mean from a script?
<zyga-ubuntu> brunosfer: talk to the same socket, if you have the right interface it can be done from the snap
<zyga-ubuntu> brunosfer: if not you need to be unconfined (outside)
<zyga-ubuntu> brunosfer: but should be enough to let you code
<brunosfer> right now I'm doing it in golang but the idea is to make a snap out of it, so I would need to make my yaml file with those previledges, but I'm also quite noob in Go as well as in the Snaps =P
<zyga-ubuntu> brunosfer: you cannot grant the permission yourself, the interface that you'd have to request is sensitive, it would have to be a decision agreed upon in the forum and reviewed by the security team
<brunosfer> Chipaca: And what do you mean by priviledged? --devmode?
<zyga-ubuntu> brunosfer: some interfaces can be accessed instantly as they are considered safe
<zyga-ubuntu> brunosfer: but with this interface you can equally remove and install snaps
<Chipaca> brunosfer: i'm sorry if i'm not fully following what you need
<Chipaca> brunosfer: curl -s --unix-socket /run/snapd.socket http://localhost/v2/snaps
<Chipaca> brunosfer: ^ is that what you're asking?
<pedronis> mvo: test lxd seems to have failed here:  https://travis-ci.org/snapcore/snapd/builds/327212657?utm_source=github_status&utm_medium=notification
<brunosfer> Chipaca: That's exactly what I was looking for! Perfect answer! Thank you so much for the command line. It works perfectly.
<brunosfer> Chipaca: But for me to perform that command line do I need to have a special permission? Using it from my snap?
<Chipaca> brunosfer: yes, the snap needs snapd-control to accss the socket
<brunosfer> Chipaca: That's perfect. You helped me a lot ;)
<mvo> pedronis: hm, you restarted by now I guess? was it just a slow download? that happens sometimes unfortunately
<popey> flexiondotorg: https://bugs.launchpad.net/snapcraft/+bug/1742504
<mup> Bug #1742504: magic.mgc, 1: Warning: offset `' invalid <Snapcraft:New> <https://launchpad.net/bugs/1742504>
<popey> kyrofa: ^ New and interesting ways to break snapcraft
<kyrofa> Oh how fun!
<kyrofa> Oh dang
<kyrofa> popey, and that didn't happen in 2.35?
<popey> nope
<popey> flexiondotorg: just hit the same
<popey> he's in an i386 vm, I'm on an i386 VPS
<kyrofa> popey, you didn't read the changelog? Snapcraft does abstract art now. It's a feature
<popey> lulz
<popey> Nice try!
<flexiondotorg> I'm running snapcraft from the beta channel on a i386 VM.
<flexiondotorg> Same issue.
<kyrofa> i386, huh?
<kyrofa> Have either of you tried on amd64?
<flexiondotorg> Doesn't happend of metal amd64.
<popey> lemme switch my amd64 laptop to beta to reproduce
<popey> oooh
<popey> got it to do it and not screw fonts up
<popey> so i have a readable stacktrace now
<popey> kyrofa: there you go, comment #2
<kyrofa> popey, any chance the snap you're building is public so I can poke at what's happening there?
<popey> I'll attach the yaml
<popey> kyrofa: attached, and had the same issue on armhf and not amd64
<popey> You're wecome! :D
<kyrofa> Thank you! We'll have a look
<Chipaca> santa cachucha, so many special cases
<flexiondotorg> Looks like elf patching is not working on 32-bit binaries.
<popey> Looks like we need more test cases on more architectures! :D
<ogra> or just drop support for some :P
<flexiondotorg> Yeah, armhf ;-)
<ogra> booo
<Chipaca> let's drop armel and nubus-ppc
<kyrofa> popey, flexiondotorg we have test cases on other arches, but they're adt
<lundmar> so, the build.snapcraft.io is currently down?
 * zyga-ubuntu looks at slashdot story
<zyga-ubuntu> https://news.slashdot.org/story/18/01/10/1634215/meltdown-and-spectre-patches-bricking-ubuntu-1604-computers
<mup> PR snapcraft#1810 closed: [WIP] i18n support <Created by m4sk1n> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1810>
<lundmar> man, for some work loads the performance degradation of spectre/meltdown fix is quite a blow.
<cwayne> zyga-ubuntu: that's fixed with -109 which is already out
<zyga-ubuntu> yeah, I read that
<zyga-ubuntu> just was caught by the headline
<roadmr> zyga-ubuntu: "bricking" should not be used to mean "left unbootable and needing recovery and/or factory reset". Bricking means "it became a useless brick and had to be thrown into trash"
<zyga-ubuntu> lundmar: can you elaborate please? I'm curious
<roadmr> also hi :)
<zyga-ubuntu> roadmr: yeah, it's just clickbait journalism
<sergiusens> kyrofa popey if it is magic that is breaking I think I can fix that
<roadmr> zyga-ubuntu: well I've seen "bricking" used to mean a recoverable situation very frequently. I think people are just confused and/or have never actually had a bricked device
<lundmar> zyga-ubuntu: some workloads seem to degrade by as much as ~30%
<kyrofa> sergiusens, yeah, seems so
<roadmr> zyga-ubuntu: but anyway I'm just whining :)
<zyga-ubuntu> roadmr: hey, that's my spare time activity ;)
<sergiusens> kyrofa might as well get rid of magic completely, that python module is a mess
<kyrofa> sergiusens, can we? It's always so hard to find documentation for it as well
<sergiusens> I wish we could also get rid of python-apt, that would also be a blessing :-)
<sergiusens> kyrofa yes, I will replace it with readelf, then it is also one call
<lundmar> zyga-ubuntu: you might find this interesting: https://www.phoronix.com/scan.php?page=news_item&px=KPTI-Retpoline-Combined-Ubuntu
<lundmar> anyone know what is going on with build.snapcraft.io - it seems to be down but https://status.snapcraft.io is all green?
<kyrofa> lundmar, yeah, the build farm is down pending mitigation for meltdown/specre
<kyrofa> noise][, were you going to put something about that on status.snapcraft.io?
<lundmar> the status page should show red then :)
<kyrofa> No argument from me. I sent an email about this last week
<noise][> sorry, we added a notice in the Incident History on status.snapcraft.io and it was pinned to the top for a time but has now drifted down
<lundmar> it's been down for a while? I only just noticed.
<kyrofa> lundmar, about a week now
<lundmar> ok
<lundmar> hopefully it will be up again soon
<kyrofa> lundmar, https://twitter.com/launchpadstatus/status/948688233029881856
<kyrofa> My hope as well
<kyrofa> Mitigations started rolling last night, so I expect it to come back up any time
<lundmar> great
<noise][> yes, hopefully all back over the next 2 days
<lundmar> this whole spectre thing is quite a big deal - amazing such a simple mechanism has gone unnoticed until now.
<kyrofa> noise][, I kinda feel like something should be big and red, there
<kyrofa> build.snapcraft.io is a pretty decent thing that we should consider tracking there
<noise][> for various reasons we don't have access to check the status of the actual build farm in that status dashboard
<noise][> just that the store side and build.snapcraft.io website are up
<kyrofa> Even just something that could be toggled by hand, seeing that we know the build farm is down would be handy
<noise][> well that was the incident notice, which i will re-pin now
<kyrofa> noise][, I doubt people will scroll down that far once they see everything is green
<kyrofa> Just sayin
<lundmar> I almst missed the pinned incident pop up notice.
<lundmar> almost*
<zyga-ubuntu> I'm a bit exhausted, time to sleep
<zyga-ubuntu> I'll wake up earlier tomorrow
<mup> PR snapcraft#1862 opened: zip: support extracting non-unix zip files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1862>
<kyrofa> sergiusens, that's for you ^^
<sergiusens> actually for ogra ^ ;-)
<kyrofa> Ha!
<ogra> well, i'm also just proxying
<sergiusens> ogra if you want to give the snap a spin, go to the travis build and search for the transfer.sh file upload ;-)
<ogra> it is for that mythical "customer" guy :)
<kyrofa> Yeah, like to keep those happy and non-mythical
<sergiusens> kyrofa btw, was snapcraft#1639 supposed to be approved?
<mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<kyrofa> sergiusens, I'm re-reviewing now. elopio and I didn't like the tests, but kalikiana's fix for that seemed to introduce weird test problems
<kyrofa> sergiusens, so the tests have been reverted
<kyrofa> I'm kinda meh on the tests. I'd rather see real integration test snaps like we do for the other pieces of the grammar
<kyrofa> But in the interest of time they may be okay
<sergiusens> kyrofa if they are not good, then they are not good.
<sergiusens> kyrofa what about snapcraft#1857 ?
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<kyrofa> sergiusens, it's next on my queue
<kyrofa> Had some testing questions there on the last pass
<kyrofa> elopio, what are your thoughts on snapcraft#1639? Do you like that better than putting more snaps in tests/integration/snaps ?
<mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<popey> sergiusens: yay!
<kyrofa> sergiusens, while I'll pass snapcraft#1639 assuming elopio is okay with it, snapcraft#1857's tests aren't right yet
<mup> PR snapcraft#1639: grammar: to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1639>
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<kyrofa> Should be an easy change though, hopefully
<sergiusens> kyrofa so now only snapcraft#1853 is left?
<mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
<kyrofa> Yep
<elopio> kyrofa: yes, I think we have too many snaps in tests/integration/snaps
<kyrofa> sergiusens, although we should consider snapcraft#1861 as well
<mup> PR snapcraft#1861: extractors: also support appdata.xml appstream files <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1861>
<elopio> I'm ok with the tests. Not super happy, but I think we can later make a better filter of the ones that require to be in snaps. And get all the others to consistently use the fixture
<kyrofa> elopio, sounds good
<sergiusens> elopio kyrofa fwiw I am seriously considering removing the buffering and let tests print everything they need to
<kyrofa> sergiusens, we kinda tried that already, things slow waaay down
<sergiusens> kyrofa not for unit, for integration
<sergiusens> I don't like the current travis hack I had to do
<kyrofa> sergiusens, yeah, that's what I'm talking about. Let me find the PR...
<sergiusens> oh, bummer :-/
<sergiusens> ok, for the past to months every other week we've had to stop and deal with something new with travis; let's consider some alternatives
<kyrofa> sergiusens, oh wait, nevermind-- things might slow down a little, but we closed it because it ended up not being necessary for what we were doing. You might like it: https://github.com/snapcore/snapcraft/pull/1591
<mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
<kyrofa> sergiusens, that's just a subset of the integration tests, but you get the idea
<kyrofa> I wonder how hard it would be to port to circle CI. They seem to innovate faster, and have longer runtimes
<kyrofa> Oh wait, no-- you only get one instance. Nevermind
<kyrofa> That'll slow things down
<sergiusens> kyrofa so, instead of printing to stdout/stderr we opted to just skip the test? :-/
<sergiusens> kyrofa we are at a point where if we do not print we need to skip all the tests
<kyrofa> Hahahaha
<kyrofa> It wasn't an "instead" so much as a "well, that didn't actually help us solve the problem"
<kyrofa> We thought the issue was that travis was timing out before we could print, but once we fixed that the test still took waaay to long to be in the suite
<kyrofa> But I agree that printing would be useful as long as we didn't suffer too much of a slowdown
<mup> PR snapcraft#1639 closed: grammar: to statement <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1639>
<mup> PR snapcraft#1861 closed: extractors: also support appdata.xml appstream files <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1861>
<sergiusens> elopio you now have conflicts
<sergiusens> kyrofa we should print a `.` for every line of progress or something like that
<sergiusens> kyrofa I still think we need to migrate away from travis, the free tier isn't cutting it
<kyrofa> sergiusens, then I only see two options: non-free tier, or self-hosting
<kyrofa> (which is also non-free)
<sergiusens> kyrofa yeah we will probably go back to adt
<kyrofa> elopio, one more comment on snapcraft#1853, but I suspect it's good
<mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
<elopio> kyrofa!
<elopio> sorry
<elopio> kyrofa: so are you OK with every get to return Union[str, List[str]]?
<elopio> It's easy to change, just want to double check I got your comment
<kyrofa> elopio, seems better than Any
<kyrofa> elopio, note that mypy will barf if you end up handing it off to something that expects a str though, so you can cast if you know for sure it is (and need it to be)
<popey> kyrofa: for some reason I picked up from a thread on the forum that $SNAP_ARCH_TRIPLET was a thing I could use in environment:
<popey> kyrofa: seems not :(
<popey> Any plan to add it, so we don't have to add if elif elif elif else fi nonsense?
<kyrofa> popey, SNAPCRAFT_ARCH_TRIPLET, and only in 2.36 and later
<popey> oh!
<popey> in environment?
<popey> e.g. if I have an environment setup for a command, will snapcraft fill it in at build time?
<kyrofa> popey, I'm not 100% sure what you're asking, but it's like SNAPCRAFT_PART_INSTALL if you've used that
<kyrofa> It is an environment variable
<popey> but it's an environment varibale at snapcraft runtime, not snap runtime
<popey> so for example if i have a command that needs a path set to a lib directory, setting environment: PATH: "$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/foo" gonna work?
<kyrofa> popey, ahh, right, I see where you're coming from now
<kyrofa> popey, no, that won't work
<popey> :(
<popey> I end up needing 3 yamls, one per arch
<kyrofa> popey, I really wish snapd would add that, but I added a remote part for it if you want to use that instead
<popey> yeah, i found that :)
<kyrofa> THAT will give you SNAP_ARCH_TRIPLET
<kyrofa> popey, and it literally just does the elif elif elif vi nonsense for you :P
<kyrofa> Huh. I type that command too much
<popey> :D
<kyrofa> So yeah, you can use SNAPCRAFT_ARCH_TRIPLET at snap build time, but at runtime all snapd gives you is SNAP_ARCH, so you either need to write the elif stuff or use that remote part
<popey> This feels like it needs a bug
<popey> having a bunch of shell script attached to a hundred snaps makes no sense
<kyrofa> I could have sworn we had one against snapd at some point, but I suspect it was lost between snappy/snapd/etc.
<kyrofa> I agree
 * popey files
<kyrofa> popey, sorry I got your hopes up. I pictured your childish joy at learning this was possible only to have crushed it
<popey> hahah
<kyrofa> er, childlike is probably what I wanted there
<popey> https://bugs.launchpad.net/snapd/+bug/1742565
<mup> Bug #1742565: snapd should provide SNAP_ARCH_TRIPLET <snapd:New> <https://launchpad.net/bugs/1742565>
<popey> kyrofa: snapcraft really craps the bed if you switch from beta to stable
<popey> i.e. from 2.38 back to 2.35
<kyrofa> popey, because of the state tracking?
<kyrofa> Yeah, that was written well before snaps were a possibility. We should start accounting for that
<popey> https://paste.ubuntu.com/26363030/
<kyrofa> Handle it well, say 'hey yo, I don't recognize this state stuff at all. Clean, man."
<popey> i have no idea what to do at this point ^
<kyrofa> popey, wait, that's different
<kyrofa> popey, are you on i386 again?
<popey> yes, same on armhf
<kyrofa> stable channel?
<popey> yes
<popey> i reverted back from beta to stable to rebuild something and avoid the magic bug from earlier
<kyrofa> popey, https://bugs.launchpad.net/snapcraft/+bug/1733922
<mup> Bug #1733922: âsnapcraft initâ crashes on 32-bit Ubuntu <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1733922>
<kyrofa> popey, the fix is in 2.36, I'm afraid
<popey> uhm
<kyrofa> That never made it to stable
<popey> so 2.35 is broken, 2.36 is fixed (but never released) and 2.38 (released) is broken.
<popey> Which version should I use? :)
<kyrofa> popey, hold on, let me give you 2.36
<popey> i wonder if I can refresh --revision?
<kyrofa> popey, you're not a collaborator. But you don't need to be, I'll make a hotfix channel for ya
<popey> oh, i dont think you need to be a collaborator to --revision ninja
<popey> I did this earlier with another snap ;)
<kyrofa> Hmm, okay. I thought that was the idea, anyway
<kyrofa> popey, you're on armhf? Try rev 878
<kyrofa> popey, let me know if it doesn't work and I'll create a hotfix
<popey> it wont let me
<kyrofa> Oh good, I'm not insane
<popey> i think the deb works
<popey> (I used the deb earlier successfully, but only moved to snap to test some of these environment variables)
<kyrofa> Indeed, the deb should work for that bug anyway
<popey> ok, lemme test that
<kyrofa> popey, feel free to use the edge/2-36 channel as well, if you like
<popey> thanks
<popey> they're all building now
<kyrofa> popey, edge/2-37 is open as well, if you find you need it
<popey> you're a star
<kyrofa> Remember they only live for a month, but easy to re-create if necessary
<popey> I'm sure all the bugs will be fixed in a month, so won't need it ;)
#snappy 2018-01-11
<popey> kyrofa: 2.35 deb worked for now, thanks! :D
<mup> PR snapcraft#1862 closed: zip: support extracting non-unix zip files <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1862>
<Mert> Hi guys
<Guest80198> Is core_3748 bugged?
<Guest80198> On manjaro i can't mount core-3748.=
<Guest80198> if you know the solution, can you email me? d_mert@hotmail.com
<Guest80198> have a good day
<mup> Issue snapcraft#1668 closed: Bring in newer ld-linux and glibc libraries <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1668>
<mup> Issue snapcraft#1669 closed: patchelf with ld-linux from the future <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1669>
<mup> PR snapcraft#1850 closed: pluginhandler: patch and handle elf files on glibc mismatch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1850>
<mborzecki> morning
<letmutx> is xfce available through snaps? i tried uappstore but couldn't find it.
<zyga-ubuntu> re
<mborzecki> zyga-ubuntu: morning
<mvo_> good morning zyga-ubuntu and mborzecki
<mborzecki> mvo_: hey, you have earned a _ :)
<mborzecki> seems like fedora prepare is failing again
<zyga-ubuntu> yes, consistently so
<mvo> :(
<mvo> time for manual again then
<mborzecki> mvo: will you do it or should i?
<mvo> mborzecki: please go ahead
<mborzecki> ok
<mvo> ta
<zyga-ubuntu> mvo: idea
<zyga-ubuntu> mvo: actually, scratch that idea :/
<mvo> zyga-ubuntu: that was a quick ide
<mvo> a
<zyga-ubuntu> yeah, nothing like talking to oneself to notice something is wrong
<mvo> :)
 * mvo hugs zyga-ubuntu 
<mup> PR snapd#4474 opened: spread: switch fedora-26-64 back to manual <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4474>
<zyga-ubuntu> mborzecki: bonus points if you collect the log and talk to #linode people on the other IRC network
<zyga-ubuntu> (OFTC)
<kalikiana> good morning, snappy
<mborzecki> kalikiana: morning
<zyga-ubuntu> mvo: ok, I finished other prep work and I'm setting up tests on dragon now
<mvo> zyga-ubuntu: ta
<zyga-ubuntu> mvo: all tests or just main?
<zyga-ubuntu> mvo: just to be clear, from release/2.30, run all the tests
<mvo> zyga-ubuntu: yeah, correct
<zyga-ubuntu> started
<mvo> zyga-ubuntu: some failures are know, iirc security-device-cgroups-serial-port fails because there is not the right serial port on some boards. cachio would know for certain
<mup> PR snapd#4469 closed: tests: add hard-coded fully expired macaroons to run related tests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4469>
<pstolowski> mornings!
<zyga-ubuntu> hey o/
<zyga-ubuntu> mvo: 141 tests to go, that's not that many
<mvo> zyga-ubuntu: yeah, but each takes ~1min or so :/
<mvo> zyga-ubuntu: at leat on the pi it takes a couple of hours
<letmutx> is xfce available through snaps? i tried uappstore but couldn't find it.
<mborzecki> and probably 1h just for automake & configure in cmd :)
<zyga-ubuntu> so far so good, 6th test in progress
<zyga-ubuntu> hmm
<zyga-ubuntu> has anyone created a google calendar and tried to add a hangout to it
<zyga-ubuntu> it seems this option is gone now
<pedronis> mvo: hi, I reviewed #4356  (yesterday got a bit distracted)
<mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
<zyga-ubuntu> mvo: ~~12 tests out of 141, each test really takes minutes
<zyga-ubuntu> I'll grab a coffee
<zyga-ubuntu> jamesh: around?
<jamesh> zyga-ubuntu: hi
<zyga-ubuntu> jamesh: we'll probably jump into a standup HO as I cannot add HO to the event anymore
<zyga-ubuntu> jamesh: I'll share the link in a moment
<mvo> pedronis: thank you, I have a look as soon as I have some spectre releated stuff under control
<zyga-ubuntu> niemeyer: we're going to use the standup HO
<mborzecki> btw. feel sorry for the kernel team: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1742323 it's on HN: https://news.ycombinator.com/item?id=16118858
<mup> Bug #1742323: Meltdown Update Kernel doesnt boot <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Confirmed for jsalisbury> <linux (Ubuntu Xenial):Confirmed for jsalisbury> <https://launchpad.net/bugs/1742323>
<Chipaca> mborzecki: i guess 10 retries wasn't enough for the fedora thing
<Chipaca> Â¯\_(ã)_/Â¯ i wanted to push another commit anyway
<mvo> pedronis: thanks, review looks very good
<mvo> Pharaoh_Atem: hey, a while ago you mentioned fedora using a more fine grained architecture description. can you point me somewhere where I can learn more about this?
<Chipaca> mvo: why am i not making 'snap pack' run validateContainer?
<mvo> Chipaca: indeed, why don't you? as a warning and with an option to disable, right?
<pedronis> Chipaca: indeed :)
<mvo> Chipaca: I mean, it will not make snap pack fail, right?
<Chipaca> mvo: why wouldn't it?
<pedronis> we might have some tests that abuse stuff
<Chipaca> *shocked*
<pedronis> but IÂ don't think it should be just a warning
<pedronis> it should be error
<pedronis> or nothing
<mvo> Chipaca: hm, right, it won't even install so â¦ +1 for fail
<mvo> lets see if tests survive this ,)
<Chipaca> mvo: maybe in a separate PR though :-)
<mvo> again +1
 * Chipaca is adding a spread test to 4464 and then hopes to land it
<seyeongkim> hello, is there a way to install older revision of core snap?
<mborzecki> haha so the snap store is returning 418 'I'm a teapot'?
<Chipaca> mborzecki: and does GET give you coffee, as per spec?
<mborzecki> just the teapot, the rest is DIY
<mup> PR snapd#4475 opened: overlord/snapstate: for Enable's tasks refer to the first task with snap-setup, do not duplicate <Created by pedronis> <https://github.com/snapcore/snapd/pull/4475>
<pedronis> small PR cleaning up an oddity IÂ noticed recently  ^
<Chipaca> pedronis: a space oddity?
<pedronis> Chipaca: silly you :)
 * Chipaca nods
<Chipaca> pedronis: in my defense, i'm learning it on the guitar :-)
<pedronis> Chipaca: it's fine, it would have been funnier if it was indeed a space problem, but alas we use go fmt
<pedronis> though there is always shell  and yaml to commit space sins
<Chipaca> pedronis: :-)
<zyga-ubuntu> re
<zyga-ubuntu> mvo: we're at 59/141 now
<zyga-ubuntu> mvo: no issues yet
<mup> PR snapd#4474 closed: spread: switch fedora-26-64 back to manual <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4474>
<brunosfer> Chipaca: could you tell me how can I make curl requests to the snapcraft API the same way you told me on the localhost?
<brunosfer> Chipaca: I want to make a "snap find" to the public API...
<mvo> zyga-ubuntu: great, pi3 is finished here, I'm doing p2 now
<zyga-ubuntu> mvo: cool, I'll let you know when something changes
<Chipaca> brunosfer: it's a little out of date, but https://github.com/snapcore/snapd/wiki/REST-API might be a good place to start
<brunosfer> Chipaca: Thanks!
<mborzecki> mvo: how long did it take?
 * kalikiana taking a break, too much staring at a screen :-/
<mvo> mborzecki: oh, sorry, didn't see the question - pi3 took around 2.5h
<Chipaca> mborzecki: mvo: could one of you mark my #4464 as 'changes requested' please so it doesn't get merged for a bit?
<mup> PR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>
<Chipaca> i just realised something needs fixing, but i don't want to close it and lose the spread test run
<Chipaca> i'm going to go take a break, bbiab
<mborzecki> Chipaca: marked
<Chipaca> thanks
<zyga-ubuntu> error: cannot list snaps: cannot list local snaps! cannot find installed snap "classic" at revision 26
<zyga-ubuntu> mvo: that was
<zyga-ubuntu> 2018/01/11 12:14:55 Error executing external:ubuntu-core-16-arm-64:tests/main/listing :
<zyga-ubuntu> mvo: it's still going, 81/141 now
<mvo> zyga-ubuntu: hm, that looks strange, we may need to re-run this one test
<mvo> zyga-ubuntu: cachio told me the board tests are not always 100% reliable, we don't run them often enough :/ he apparently has to re-run them sometimes
<ogra> mvo, did you notice that your copre snap build failed ?
<ogra> rm: cannot remove '/var/lib/apt/lists/': Is a directory
<ogra> rm: cannot remove '/var/lib/apt/lists/partial': Is a directory
<ogra> E: config/hooks/12-add-foreign-libc6.chroot failed (exit non-zero). You should check for errors.
<ogra> seems your -print 0 re-ordering isnt liked
<zyga-ubuntu> mvo: sure, I can re run
<mvo> ogra: meh, sucks. I have a look
<zyga-ubuntu> mvo: FYI I'm talking with linode operators about fedora issues and I'm using spread 70 to test
<mvo> ogra: slightly strange on my artful this shows the right result. I guess I need to double check on xenial
<ogra> yeah, it really shouldnt do any harm
<ogra> (but if it does, the manpages and docs removal will have the same issue
<ogra> )
<mvo> ogra: yeah, the "funny" part is that i386 build fine
<ogra> heh
<ogra> well, then it seems to work with the docs at least
<ogra> other topic ... do we have auto-connecting of interfaces from the gadget already ... and do we have it documented somewhere)
 * ogra bets pedronis would know such stuff ^^
<zyga-ubuntu> mvo: fedora uses a random mirror from a redirectory
<zyga-ubuntu> *redirector
<zyga-ubuntu> mvo: I'm running a test that shows what's going on, I already saw some mirrors not responding (and being switched over to another one)
<zyga-ubuntu> mvo: but a bad sequence will probably explain the set of failures we've seen
<zyga-ubuntu> mvo: probably spectre/meltdown result
<zyga-ubuntu> mvo: we can pin to a specific mirror if we want
<zyga-ubuntu> mvo: I'm also asking if linode plans to offer one
<mvo> ta
<zyga-ubuntu> https://pastebin.ubuntu.com/26365704/
<zyga-ubuntu> we'll need gustavo to open a ticket
<zyga-ubuntu> I'll prepare the contents
<mvo> hu? what checksum is that
<mvo> aha, its just 3
<zyga-ubuntu> mvo: https://forum.snapcraft.io/t/issues-with-fedora-mirror/3489 for tracking
<zyga-ubuntu> Son_Goku: ^
<Son_Goku> zyga-ubuntu: what happens when you try to curl the URL from within the Linode system?
<zyga-ubuntu> Son_Goku: it's random, it works most of the time in a loop
<zyga-ubuntu> Son_Goku: it jut doesn't _always_ work
<zyga-ubuntu> Son_Goku: I'll try curl in a sec
<zyga-ubuntu> Son_Goku: running a test with "dnf install -y -4" now
<zyga-ubuntu> Son_Goku: over ipv4 only
<Son_Goku> ah
<Son_Goku> metadata fetching is done by a library called librepo
<Son_Goku> https://github.com/rpm-software-management/librepo
<Son_Goku> if there's a bug in mirror selection for metadata fetching, that's where to look
<Son_Goku> also, it's not _random_ per se
<zyga-ubuntu> Son_Goku: did you see https://pastebin.ubuntu.com/26365704/ ?
<Son_Goku> the Fedora MirrorManager returns a list of valid, fast, nearby mirrors based on the location it derives from the initial request
<Son_Goku> yeah
<Son_Goku> those mirrors come from the metalink
<zyga-ubuntu> *all mirrors tried* sounds bad when it doesn't work
<Son_Goku> something fishy is going on
<Son_Goku> makes me think there might be an issue in librepo
<Son_Goku> but *shrugs*
<Son_Goku> btw, you can look in /var/log/dnf.librepo.log, too
<zyga-ubuntu> thanks, I'll check
<Son_Goku> even when DNF isn't in verbose mode, all the output for metadata fetching is there
<mup> PR core#72 opened: live-build: fix order of -print0 in find <Created by mvo5> <https://github.com/snapcore/core/pull/72>
<zyga-ubuntu> -4 seems to have helped
<mup> PR snapd#4475 closed: overlord/snapstate: for Enable's tasks refer to the first task with snap-setup, do not duplicate <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4475>
<mup> PR snapd#4382 closed: cmd/snap: show header/footer when `snap find` is used without arguments <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4382>
<mup> PR snapd#4423 closed: snap: provide more meaningful errors for installMany and friends <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4423>
<mup> PR snapd#4476 opened: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476>
<zyga-ubuntu> mvo: another test failed, I'm at 110/141 now)
<pedronis> ogra: we don't , but  it should get prioritized soon (for value of soon), is a prereq for other work we need to do
<ogra_> pedronis, ack ... and helps to get rid of some hacks in products too :)
<pedronis> ogra_: topic is here:  https://forum.snapcraft.io/t/interface-connection-from-gadget-in-firstboot/1431
<ogra_> yeah, i just found it too :)
<pedronis> ogra_: to be fair it was also conflicting with interface hooks work, but that is getting close to done
<matiasb> niemeyer, sergiusens, o/ for when you get a few minutes, it would be great if we can agree on the field name/format for the appstream id in snap.yaml (https://forum.snapcraft.io/t/support-for-appstream-id/2327/)
<matiasb> happy to schedule a call if that helps too, we need some definition to get that started server-side
<zyga-ubuntu> Pharaoh_Atem: is there any official non-mirror archive I can hit?
<sergiusens> matiasb I agree. I am fine with Robert's proposal
<matiasb> sergiusens, that would be having an optional 'appstreeam_id' field, per app entry, right? the extractors would handle setting that value? or would it be a manual thing? (just curious)
<mvo> zyga-ubuntu: ok, if you could pastebin the full run that would be great. some failures (bluetooth for example) or "ok" as the device just does not have the hardware
 * kalikiana going for lunch in ~10
 * kalikiana trying to finish these tedious grammar test cases til then...
<zyga-ubuntu> mvo: https://pastebin.ubuntu.com/26366173/
<zyga-ubuntu> still running
<pedronis> Chipaca: you could use -ls and -lls together (it gets silly)
<Chipaca> pedronis: yes
<brunosfer> Hi guys, does anyone knows how can I change the default path when downloading a snap?
<zyga-ubuntu> mvo: it's done
<zyga-ubuntu>     - external:ubuntu-core-16-arm-64:tests/main/listing
<zyga-ubuntu>     - external:ubuntu-core-16-arm-64:tests/main/prepare-image-uboot
<zyga-ubuntu> those two failed
<zyga-ubuntu> brunosfer: when you snap install or when you snap download?
<zyga-ubuntu> brunosfer: this is not configurable AFAIR
<zyga-ubuntu> brunosfer: what's the background, what are you trying to, maybe we can do something else
<zyga-ubuntu> mvo: ok, I'll grab some water and let's talk
<zyga-ubuntu> mvo: shall I re-run those two? the failure logs are in the pastebin
<mvo> zyga-ubuntu: this looks not too bad, please re-run the two just for kicks and pastebin the full run
<zyga-ubuntu> mvo: sure, full run (1st try) is here now: https://pastebin.ubuntu.com/26366247/ -- i'll start the two tests and get back to you with results
<Son_Goku> zyga-ubuntu: the main fedora URL is dl.fedoraproject.org
<Son_Goku> download.fedoraproject.org is a redirector for things that don't support mirrorlists or metalinks
<brunosfer> zyga-ubuntu: When I snap download.
<mvo> zyga-ubuntu: thank you
<brunosfer> zyga-ubuntu: The problem is that I want to run a cmd line downloading a snap and I want to save it in a specific directory rather than a default one.
<zyga-ubuntu> Son_Goku: thanks, that's useful
<zyga-ubuntu> brunosfer: AFAIR it just downloads to the current directory,
<zyga-ubuntu> Son_Goku: that's working, I'll run a small loop to see if that stays operational
 * pstolowski lunch
<mup> PR core#72 closed: live-build: fix order of -print0 in find <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/72>
<brunosfer> zyga-ubuntu: I think it downloads for some environment default value to home, because even when I make the "cd" command before it just keeps downloading to the home folder.
<niemeyer> matiasb, sergiusens: Will catch up with that discussion this afternoon..
<niemeyer> matiasb, sergiusens: We can then have a call if necessary and you are available
<matiasb> niemeyer, sergiusens, sure, I'm available today/tomorrow, just let me know
<pedronis> niemeyer: I was thinking, if we use these just as defaults we consume them at clear points (install, or seed), so IÂ don't think we need to keep track of timestamps
<niemeyer> pedronis: That's easier to reason about, and also makes the seed more even with other behavior.. nice
<mborzecki> off to pick up the kids
<kalikiana> re
<mup> PR snapcraft#1864 opened: debian/control: Add patchelf to Depends: <Created by flexiondotorg> <https://github.com/snapcore/snapcraft/pull/1864>
<mup> PR snapd#4441 closed: snap: add usage hints in `snap download` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4441>
<Chipaca> brunosfer: are you talking about 'snap download'?
<zyga-ubuntu> mvo: same failures
<elopio> hello.
<mvo> zyga-ubuntu: could you flash the image again? the listing one is confusing, I'm checking the prepare-image one now
<zyga-ubuntu> sorry, I fell asleep
<zyga-ubuntu> mvo: sure, working
<mvo> zyga-ubuntu: ta!
<mvo> zyga-ubuntu: both failures are odd, the second less so but the first one very much so
<mvo> zyga-ubuntu: as the first test does not install classic
<zyga-ubuntu> mvo: I just realized I didn't actually flash the image earlier, it was running on edge core/kernel
<zyga-ubuntu> mvo: I need to build an image for it and the copy it over
<mvo> zyga-ubuntu: please use the image from http://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/
<mvo> zyga-ubuntu: thats the image we need to test
<zyga-ubuntu> mvo: sure thing
<mvo> zyga-ubuntu: thank you!
<zyga-ubuntu> sorry for the confusion, I'll hook it up ASAP
<mvo> zyga-ubuntu: sorry that I take up your time :(
<zyga-ubuntu> mvo: no worries :) feels like a good time to use the board once in a while
<mup> PR core-build#11 closed: remove cruft from the writable-paths <Created by mvo5> <https://github.com/snapcore/core-build/pull/11>
<mup> PR # closed: core#38, core#67, core#69, core#70, core#71
<mup> PR # closed: core#38, core#67, core#69, core#70, core#71
<mup> PR # closed: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4326, snapd#4329, snapd#4336, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357, snapd#4358, snapd#4365, snapd#4369, snapd#4380,
<mup> snapd#4387, snapd#4399, snapd#4401, snapd#4416, snapd#4418, snapd#4419, snapd#4424, snapd#4425, snapd#4440, snapd#4443, snapd#4448, snapd#4449, snapd#4459, snapd#4464, snapd#4471, snapd#4472, snapd#4473, snapd#4476
<kalikiana> sergiusens: to hangout or not to hangout? which will it be? :-)
<mup> PR # opened: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4326, snapd#4329, snapd#4336, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357, snapd#4358, snapd#4365, snapd#4369, snapd#4380,
<mup> snapd#4387, snapd#4399, snapd#4401, snapd#4416, snapd#4418, snapd#4419, snapd#4424, snapd#4425, snapd#4440, snapd#4443, snapd#4448, snapd#4449, snapd#4459, snapd#4464, snapd#4471, snapd#4472, snapd#4473, snapd#4476
<mup> PR # closed: snapd#3963, snapd#3998, snapd#4049, snapd#4063, snapd#4068, snapd#4073, snapd#4103, snapd#4140, snapd#4285, snapd#4299, snapd#4307, snapd#4326, snapd#4329, snapd#4336, snapd#4342, snapd#4349, snapd#4351, snapd#4356, snapd#4357, snapd#4358, snapd#4365, snapd#4369, snapd#4380,
<mup> snapd#4387, snapd#4399, snapd#4401, snapd#4416, snapd#4418, snapd#4419, snapd#4424, snapd#4425, snapd#4440, snapd#4443, snapd#4448, snapd#4449, snapd#4459, snapd#4464, snapd#4471, snapd#4472, snapd#4473, snapd#4476
<mup> Issue # closed: snapcraft#100, snapcraft#1438, snapcraft#1440, snapcraft#1441, snapcraft#1449, snapcraft#1450, snapcraft#1451, snapcraft#1455, snapcraft#1456, snapcraft#1458, snapcraft#1459, snapcraft#1460, snapcraft#1461, snapcraft#1463, snapcraft#1465, snapcraft#1467, snapcraft#1468,
<mup> snapcraft#1469, snapcraft#1476, snapcraft#1477, snapcraft#1502, snapcraft#1658, snapcraft#1659, snapcraft#1660, snapcraft#1665, snapcraft#1670, snapcraft#1671, snapcraft#1672, snapcraft#1673, snapcraft#1674, snapcraft#1675, snapcraft#1676, snapcraft#1677, snapcraft#1678, snapcraft#1679,
<mup> snapcraft#1680, snapcraft#1681, snapcraft#1682, snapcraft#1683, snapcraft#1684, snapcraft#1685, snapcraft#1688, snapcraft#1689, snapcraft#1690, snapcraft#1691, snapcraft#1692, snapcraft#1696, snapcraft#1697, snapcraft#1701, snapcraft#1704, snapcraft#1705, snapcraft#1706, snapcraft#1707,
<mup> snapcraft#1708, snapcraft#1714, snapcraft#1715, snapcraft#1751, snapcraft#1753, snapcraft#1794, snapcraft#1819, snapcraft#1828
<mup> PR # closed: snapcraft#1564, snapcraft#1617, snapcraft#1649, snapcraft#1720, snapcraft#1746, snapcraft#1769, snapcraft#1800, snapcraft#1836, snapcraft#1844, snapcraft#1846, snapcraft#1852, snapcraft#1853, snapcraft#1855, snapcraft#1857, snapcraft#1864
<zyga-ubuntu> mvo: github down
<zyga-ubuntu> mvo: I'll get you the results later today, I need a fresh SD card (in ~40 minutes)
<kalikiana> hrm... 503 not allowd on GitHub?! this is weird
<kalikiana> I guess GitHub is really kinda broken today
<mvo> zyga-ubuntu: ta
<mvo> zyga-ubuntu: yeah github down makes me unhappy
<zyga-ubuntu> mvo: coudn't github be down when I was sleeping
<zyga-ubuntu> couldn't*
<kalikiana> mvo: it's not completely down. it's more like launchpad on a normal day ;-)
<kalikiana> try a few more times and it kinda works
<zyga-ubuntu> I will file a github bug report
<zyga-ubuntu> the unicorn could use a few more images
<zyga-ubuntu> it would make reloading funnier
<zyga-ubuntu> "see the world they said"
<kalikiana> haha, I was thinking the same actually
<mvo> kalikiana: haha
<mup> PR snapd#4477 opened: snapenv: add SNAP_ARCH_TRIPLET <Created by mvo5> <https://github.com/snapcore/snapd/pull/4477>
<zyga-ubuntu> mvo: nice
<zyga-ubuntu> mvo: question
<zyga-ubuntu> mvo: are those values areally "universal"
<zyga-ubuntu> mvo: I was thinking that this should be a function that takes a snap info as argument
<kalikiana> wooot, arch triplet! awesome!
<zyga-ubuntu> mvo: so that we can return the right values for say, debian and fedora
<kalikiana> kyrofa: ^^
<zyga-ubuntu> mvo: if for any reason they actually don't mean the same thing
<mvo> zyga-ubuntu: I was asking Son_Goku earlier about the fedora arch triplets but maybe he missed the message
<zyga-ubuntu> mvo: and at the place where you call it you can easily pass the info
<mvo> zyga-ubuntu: its tricky, in theory these triplets are whatever you tell your compiler they should be
<zyga-ubuntu> mvo: then you can still use $SNAP_ARCH_TRIPLET all the time
<zyga-ubuntu> and it just matches your base
<zyga-ubuntu> mvo: right exactly that's why I think it should be base-bound
<mvo> zyga-ubuntu: yeah, making them base-bound would probably the best, I need to learn more about the fedora world
<zyga-ubuntu> mvo: it could even be a meta-data on base snap somewhere
<zyga-ubuntu> mvo: but for now it's enough if this is the value we return for base-16 and base-18
<zyga-ubuntu> mvo: I suspect ikey might want to chime in too
<mvo> zyga-ubuntu: +1
<mvo> zyga-ubuntu: yeah, getting input on this from more distros would be great, I wonder if they use /usr/lib/$arch at all (we only added this for multi-arch support for dpkg/apt)
 * mvo is so ignorant :(
<zyga-ubuntu> mvo: not all
<zyga-ubuntu> mvo: solus doesn't AFAIR
<zyga-ubuntu> mvo: I have a swarm of VMs to check if you want to know
 * zyga-ubuntu wishes to be exactly as ignorant as mvo ;-) 
<mvo> zyga-ubuntu: I just checked with rpmfind.net and it seems like fedora uses /usr/lib/*.so which is interessting. so they really won't need SNAP_ARCH_TRIPLET anyway AFAICT
<mvo> zyga-ubuntu: anyway, not important, please don't let me distract you
<Son_Goku> mvo: hm?
<mvo> Son_Goku: you told me at some point fedora is using more detailed architecture defintions - where can I read more about this
<Son_Goku> https://github.com/rpm-software-management/rpm/blob/master/platform.in + https://github.com/rpm-software-management/rpm/blob/master/rpmrc.in
<mvo> thanks Son_Goku
<Son_Goku> also, insofar as debian-style multiarch deps, I've also got a PR proposed for rpm to support those fully: https://github.com/rpm-software-management/rpm/pull/360
<mup> PR rpm-software-management/rpm#360: elfdeps: Add full multiarch deps support <Created by Conan-Kudo> <https://github.com/rpm-software-management/rpm/pull/360>
<Son_Goku> mvo: in Fedora, we do /usr/<triple> for foreign architectures for cross targets
<Son_Goku> and the triple is defined as the triple coming from the compiler (gcc)
<mvo> Son_Goku: sweet - will it be the same triple as the ones that debian/ubuntu uses (which are really just noramlized gnu ones)?
<Son_Goku> mostly the same
<Son_Goku> I think there's some differences w.r.t. ppc64 triples
<Son_Goku> but it's been a while
<mvo> Son_Goku: cool, that sounds very promising
<mvo> Chipaca: thanks for your suggestion I think I call it normalizedGnuTriplet
<Son_Goku> you can actually query this on rpm using 'rpm --target <arch> --eval "%_target_platform"'
<Son_Goku> not sure if it triggers the correct mappings w.r.t. isa aliasing, but it gets you close
<Chipaca> $ rpm --target amd64 --eval "%_target_platform"
<Chipaca> rpm: --target: unknown option
<Son_Goku> :)
 * popey hugs mvo for https://github.com/snapcore/snapd/pull/4477 ( cc kyrofa ^) :D
<mup> PR #4477: snapenv: add SNAP_ARCH_TRIPLET <Created by mvo5> <https://github.com/snapcore/snapd/pull/4477>
<Son_Goku> what version of rpm is there?
<Son_Goku> (it worked on my Fedora 27 system with rpm 4.14, so...)
<mvo> Son_Goku: what does it output for amd64,i386,armhf,arm64 on rpm (out of curiosity)?
<Son_Goku> x86_64-redhat-linux-gnu, i386-redhat-linux-gnu (though fedora uses i686-redhat-linux-gnu), <notvalid>, <notvalid>
<Son_Goku> I suppose I should add an arm64 -> aarch64 alias at some point
 * zyga-ubuntu hands mvo his green tea for the evening
<Son_Goku> and armhf is not a real thing
<Son_Goku> for Fedora, we have armv7hl-redhat-linux-gnu for our 32-bit arm arch
<mvo> Son_Goku: hm, its using the vendor so they are not quite the same but close, we use x86_64-linux-gnu and i386-linux-gnu but I think thats ok
<Chipaca> Son_Goku: I get that on 4.12.0.1 on ubuntu xenial, and 4.13.0-rc1 on fedora 24
<mvo> Son_Goku: woah, that one is totally different - do you have a 32bit arm with hardware float?
<Son_Goku> iirc, debian never defined the vendor field, and it's easy enough to chop out when scanning triple
<Son_Goku> mvo: yep
<Son_Goku> armv7hl is our hardware float arch
<Son_Goku> we've had armv6hl in the past
<Son_Goku> we bumped to armv7hl about five years ago?
<Son_Goku> we've also had armv5tl for non hfp before
<zyga-ubuntu> mvo: you need to accept info argument
<zyga-ubuntu> mvo: case closed
<Son_Goku> mvo: rpm doesn't do basearches
<Son_Goku> we have a map of those in DNF because we use it to organize our repos in Fedora: https://github.com/rpm-software-management/dnf/blob/master/dnf/rpm/__init__.py#L76-L102
<mvo> Son_Goku: aha, for those we use arm-linux-gnueabihf
<Son_Goku> mvo: let me check our arm compiler triple
<mvo> Son_Goku: sounds very much like this has to be base specific
<Son_Goku> I think the arm-linux-gnueabihf is what our compiler says though
<zyga-ubuntu> I'm waiting for a fresh SD card (alredy bought, will be here in 15 minutes)
<zyga-ubuntu> and I fixed the fedora archive thing to point to dl....
<mvo> Son_Goku: that would be fantastic - does the compile include "redhat" in x86_64-linux-gnu ? or is that just for the rpms?
<Son_Goku> no redhat in the triple on the filesystem
<mvo> zyga-ubuntu: you got it delivered directly to you on the same day? nice
<mvo> Son_Goku: yay
<zyga-ubuntu> mvo: we should get some opensuse poeople
<mvo> Son_Goku: so I think we the triplets are compatible, thats cool
<zyga-ubuntu> mvo: yes, my wife's office is right next to a shopping centre with electronics store inside ^_^
<zyga-ubuntu> mvo: what would I do without her :-)
<Son_Goku> rpm can query without vendor by doing `rpm --target <arch> --eval "%{_target_cpu}-%{_vendor}-%{_target_os}"`
<Son_Goku> grr
<Son_Goku> rpm can query without vendor by doing `rpm --target <arch> --eval "%{_target_cpu}-%{_target_os}"`
<Son_Goku> %_target_platform is defined as "%{_target_cpu}-%{_vendor}-%{_target_os}"
<mvo> zyga-ubuntu: hahaha, give her a *hug*
<mvo> Son_Goku: cool, I think we are good then, thanks for all your input
<Son_Goku> no problem
<Son_Goku> we do need a more granular scheme for architectures in snaps itself
<Son_Goku> but the on-filesystem thing is way simpler ;)
<Son_Goku> mvo: looks like our compiler has arm-linux-gnueabi for hf
<Son_Goku> not sure why the hf suffix is left off
<Son_Goku> but otherwise identical
<zyga-ubuntu> it's all a big mess
<mvo> Son_Goku: yeah, thats slightly unfortuante
<zyga-ubuntu> it'd be 100x better if we asked a homeless guy *consistently* instead of letting a crowd of technical people decide
<mvo> Son_Goku: but that might indicate actually that the fedora arm is using soft float
<ogra_> SNAP_ARCH_TRIPLET !!!
<ogra_> oh i love that !
<brunosfer> Chipaca: Yes I was talking about download. I solved the problem by sending an output cmd using go "cd /home/user/myfolder && snap download snapname"
<mvo> zyga-ubuntu: thinking about what Neal said, this might indicate a bigger problem, at least with arm. if fedora uses soft-float and we use hard-float we might actually ship arm snaps build on ubuntu with hard-float to fedora software-float device that will not work
<Chipaca> brunosfer: ah, i was going to say, it always downloads to the current directory
<brunosfer> Chipaca: However I intended to use a cleaner solution...
<zyga-ubuntu> mvo: will the kernel emulate that?
<zyga-ubuntu> mvo: note that fedora arm is not widespread popular
<mvo> ogra_: heh, it my most popular branch so far ;)
<zyga-ubuntu> mvo: so maybe it's a temporary issue
<brunosfer> Chipaca: Yeah, when zyga told me it would always download to the current directory I did the workaround...
<Chipaca> brunosfer: i guess nobody has needed this, which is why it doesn't have an --output-dir=<...> option
<mvo> zyga-ubuntu: may well be, its nothing new, we just may need to keep it in the back of our heads
<zyga-ubuntu> ack
<brunosfer> Chipaca: Yeah, It would be a nice to have ;)
<ogra_> mvo, feaodra "arm" is equivalent to armel i think ... while they use "armhfp" a name for v7 and that should be hardfloat
<ogra_> *as name
<mup> PR snapd#4478 opened: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4478>
<mvo> ogra_: ah, cool. that explains it
<mborzecki> iirc armv7 already supports vfp, that should make the non -m variants hf
<kyrofa> elopio, alright, had a quick call, but now I'm settled
<zyga-ubuntu> mborzecki: updated
<elopio> kyrofa: I think I replied to all your comments, but I was left thinking about the metadata.
<kyrofa> elopio, come up with any brilliant thoughts?
<elopio> kyrofa: (maybe you thought about this before but) what if we move the map from desktop_file_id to desktop_file_path earlier, rigth after the id is read from the xml?
<elopio> so, what we will have in the metadata object are paths. If there are other types of sources, they have to convert their representation to paths too
<mborzecki> zyga-ubuntu: i'd leave the retries there, but otherwise +1
<kyrofa> elopio, that seems more generic indeed
<zyga-ubuntu> mborzecki: let's see if this passes
<kyrofa> Was your thought to make it scale better across different metadata extraction methods (beyond appstream)?
<zyga-ubuntu> mborzecki: I think the retries didn't really work
<zyga-ubuntu> mborzecki: and they were there for the precisely same reason I'm hacking this now
<elopio> kyrofa: well, not to leak the details of the extractor to the metadata object.
<kyrofa> elopio, yeah, I agree
<elopio> kyrofa: should I do it before merge, or as a follow up?
<kyrofa> elopio, let me think for a sec, /me take another look at the PR
<kyrofa> Man it's hard to think here, I got so used to my quiet office
<kyrofa> okay elopio what's in the appstream data is stuff like "com.example.test-app.desktop"
<elopio> yes, a launchable of type desktop-id, is what they call it.
<kyrofa> elopio, in meta, we assume that the desktop file ends up installed in /usr/share or /usr/local/share
<elopio> kyrofa: that's what the xdg specification says.
<kyrofa> If we do that mapping sooner, you'll need to contend with the fact that your extractor is run multiple times, from different roots
<elopio> on pull it will probably always fail, because the desktop file won't be on a usr/share dir on the repo
<kyrofa> It's run during pull, in src/, and twice in build
<elopio> but on build, it will find it most likely
<kyrofa> Yeah that's what I'm driving at-- so far we've extracted actual data, this is the first time we're extracting paths
<kyrofa> elopio, would it be ridiculous to embed the desktop file in the metadata?
<elopio> kyrofa: an alternative would be to blindly build the two paths. Do not check if it exists, add the two possible locations, and leave the check to meta.
<elopio> kyrofa: not ridiculous, but not nice. Our snapcraft.yaml takes paths, so the closer we get to that, the better IMO.
<kyrofa> elopio, I want to be careful about subsequent steps reaching back into preceding steps, it breaks the lifecycle
<kyrofa> But I feel like we're making some assumptions that the desktop file is actually installed and available in prime once we do the conversion
<elopio> kyrofa: isn't that what the desktop keyword assumes too?
 * kalikiana wrapping up for the day
<kyrofa> elopio, fair point
<kyrofa> Yes
<elopio> bye kalikiana
<kyrofa> I'm stuck on the darn meta/gui ones for some reason
<elopio> The icon implementation mapped nicely to the icon keyword on snapcraft.yaml. Not so much to the icon.png in snap/gui.
<kalikiana> kyrofa: btw would be awesome if you could feast your eyes on https://github.com/snapcore/snapcraft/pull/1857#discussion_r160959367 and hopefully we're on the same page now. these tests are really tedious to go through :-D
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<elopio> I think that's ok for desktop too.
<elopio> kyrofa: another alternative would be to run "find", instead of assume that it will be in /usr/share or /usr/local/share
<kyrofa> kalikiana, what is this change? https://github.com/snapcore/snapcraft/pull/1857/files#diff-0f81cfd5e83dc1988a457bf45d0da9e1R103
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<elopio> the problem here though is the crazy handling of - by desktop_file_id. They are turned into /, for some reason, so now to find the name we have to check also the parent dir.
<elopio> or dirs, I guess you can have multiple -.
<kyrofa> elopio, no, let's back up to our metadata
<kyrofa> If we leave it as-is, no extraction method will ever be able to say "here's my desktop file." It'll have to put it in a predictable place (like /usr/share) and return an ID, which I think not everything will do
<kyrofa> elopio, so I like the idea of mapping to paths for appstream earlier
<kyrofa> And then assuming they're in prime once we're creating the snap.yaml seems the best we can do (of course, we can check and bail if necessary)
<elopio> kyrofa: well, my idea was not to force the extractors to use desktop_file_id, but to add another attribute on metadata. But, I also like the idea of making appstream fit in the general case.
<kyrofa> Then, the appstream extractor can look in /usr/share on its own to convert to a path
<kyrofa> So all the appstream specific stuff is in the extractor instead of leaking, like you said
<kyrofa> elopio, yeah, I say we define the metadata we want to use, and make appstream fit in there
<kyrofa> elopio, but I also think it can be a follow-up
<elopio> kyrofa: here's a thought. What if we extend the prime desktop step, to first search for whatever is in the desktop keyword. Then prepend usr/share and check again, and then prepend usr/local/share, and make a last check.
<elopio> then on appstream, we only have to translate desktop_file_id to desktop_file_path_relative_to_xdg
<elopio> that would be com.example.test-app.desktop -> com.example.test/app.desktop, easy.
<kalikiana> kyrofa: hmmm did I flip the values? I guess I can check that
<kyrofa> kalikiana, there should be no reason to change the tests other than making them change the host arch instead of the target arch (thank you for that)
<kyrofa> elopio, wait, the desktop keyword is a path, is it not?
<kalikiana> kyrofa: I don't see how that sentence can be true. The behavior isn't the same
<elopio> kyrofa: yes. But I'll let you talk with kalikiana first.
<kyrofa> kalikiana, the on statement works exactly the same way, but instead of using target arch, it now uses the host arch. No?
<kalikiana> kyrofa: consider this example. changing just target to host will not work https://github.com/snapcore/snapcraft/pull/1857/files#diff-0f81cfd5e83dc1988a457bf45d0da9e1R141
<mup> PR snapcraft#1857: grammar: make on statement work with host arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1857>
<kyrofa> Why?
<kyrofa> kalikiana, it's okay, I know you're EOD, I'll clone it and see if I can reproduce what you're talking about
<kyrofa> elopio, anyway, the desktop key doesn't accept just a file name-- it doesn't search directories. Right?
<kyrofa> (honest question, this is a feature with which I'm not terribly familiar, but I don't see that in the code)
<zyga-ubuntu> hmm
<zyga-ubuntu> http://cdimage.ubuntu.com/ubuntu-core/16/stable/pending/ubuntu-core-16-dragonboard.json is 404 but I see the link in the file index
<kalikiana> kyrofa: I found two more that I apparently reversed unnecessarily... I guess I've been staring at these for too long to notice those.
<elopio> kyrofa: currently, it accepts a path relative to prime.
<elopio> what I said is to accept a path that's relative to prime, prime/usr/share or prime/usr/local/share
<kalikiana> kyrofa: I hope it's fine now. See ya tomorrow
<zyga-ubuntu> mvo: fresh image flashed, setting up now
<zyga-ubuntu> (on that fresh card; no less)
<kyrofa> kalikiana, sounds good, thanks!
<ogra_> why the heck do we put the json files there ....
<kyrofa> elopio, right, okay same page then
<kyrofa> elopio, ah, then we could take stuff straight from appstream and put it in there
<kyrofa> Hmmmmmm
<elopio> not straight, but no checking for file existence.
<kyrofa> elopio, I dunno, it seems unnecessary when the appstream extractor could just use a path relative to prime
<kyrofa> elopio, that makes the metadata api pretty strict and simple
<kyrofa> Otherwise we'd need to document "this needs to be a path either relative to prime, relative to prime/usr/share, or prime/usr/local/share"
<kyrofa> Seems more complicated than it needs to be to me
<elopio> kyrofa: so, if we have this in appstream: com.example.test-app.desktop, we will add to the metadata object desktop_file_paths = ['usr/local/share/com.example.test/app.desktop', 'usr/share/com.example.test/app.desktop'], and it's the task of the prime step to find if one of the exists
<zyga-ubuntu> mvo: the image is broken
<elopio> kyrofa: is that right? I'm not totally sure we are on the same page :)
<kyrofa> elopio, bah, this whole desktop thing has no nice solutions :D
<kyrofa> I just read your responses to my other comments
<elopio> kyrofa: no, I think it won't be pretty or simple ever :)
<elopio> it could be a little more consistent.
<kyrofa> elopio, let's pause this conversation. I want to think through this and write something down. I'll share it with you in a few. There must be a way that my eyes don't twitch when I see this
<kyrofa> elopio, regardless, I think that PR is good
<zyga-ubuntu> mvo: ok, worked on 2nd try - just time server being slow, the UI doesn't wait for time sync
<zyga-ubuntu> mvo: I'm running the listing test now
<elopio> kyrofa: take your time, and thanks.
<kyrofa> elopio, I think we can improve it in pieces
<kyrofa> You did a great job, of course-- I hope you know that
<elopio> <3
<kyrofa> elopio, we actually need to chat about something else, if you wouldn't mind switching gears?
<elopio> kyrofa: go for it
<zyga-ubuntu> mvo: listing passed, I'll run all tests now
<kyrofa> elopio, 2.38 requires patchelf 0.9, but 0.8 is the one in xenial. We dynamically add a build-snap in some cases to work around this
<zyga-ubuntu> Chipaca: around?
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4478
<mup> PR #4478: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <https://github.com/snapcore/snapd/pull/4478>
<Chipaca> zyga-ubuntu: O
<zyga-ubuntu> this passed, I'd like to land it
<kyrofa> elopio, however, this does not work for docker, which as you're well aware, is what's used in pretty much every CI
<kyrofa> And the snapcraft snap can't be used either, for the same reasons
<kyrofa> Currently the only option is for folks to use the deb, which is currently 2.35 for I suspect exactly this reason
<zyga-ubuntu> thank you!
<elopio> kyrofa: we can install a newer patchelf on the docker container, can't we?
<mup> PR snapd#4478 closed: spread,tests: use main fedora archive, re-enable tests <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4478>
<kyrofa> elopio, however, some folks (cc: popey flexiondotorg) need the newer snapcraft (with ELF patching)
<Chipaca> zyga-ubuntu: ð
<kyrofa> elopio, that's where I'm going with this-- how would that best be done?
<kyrofa> elopio, right now, people are using the daily PPA to get 2.38
<kyrofa> But they're still using patchelf 0.8, not 0.9
<kyrofa> elopio, would it be terrible to get 0.9 into our PPA to support those people while we figure out how we're going to actually get our deb back into xenial?
<elopio> kyrofa: add a patchelf ppa to the docker file, I think.
<zyga-ubuntu> Pharaoh_Atem: fedora re-enabled
<kyrofa> elopio, oh, is there one?
 * kyrofa looks
<Pharaoh_Atem> zyga-ubuntu: awesome
<kyrofa> I don't see any
<elopio> kyrofa: https://launchpad.net/ubuntu/+source/patchelf It would need an update for xenial. But I would prefer to use that one than to use ours, we are trying to move people from our ppa to the snap.
<zyga-ubuntu> Pharaoh_Atem: thank you for helping, the dl. URL nailed it
<kyrofa> elopio, in this case, people _can't_ use our snap
<Pharaoh_Atem> sounds like the mirrors around the Linode IP block are semi-broken
<elopio> we need to SRU 2.39 everywhere
<popey> +1
<elopio> kyrofa: yes, they are using the PPA for the wrong reason. We missed a few SRUs.
<roadmr> ey folks! I'm trying to build a snap on an lxc container, I get this when running snapcraft: subprocess.CalledProcessError: Command '['/bin/sh', '/tmp/tmpgmot5awf', 'npm', '--cache-min=Infinity', 'install']' died with <Signals.SIGSEGV: 11>.
<elopio> the right solution for this, obviously, is to make docker support snaps.
<elopio> if we can't have that, I'd say SRU 2.39, and update the patchelf PPA.
<kyrofa> elopio, how do you anticipate that we'll SRU 2.39 in such a way that ELF patching will work in docker (i.e. no build-snaps)?
<kyrofa> elopio, wait... that's not a PPA, that's the source package, no?
<kyrofa> elopio, we can't SRU a newer patchelf
<elopio> ahh, right, we would have to make a patchelf PPA
<elopio> kyrofa: I suppose we could.
<popey> or add patchelf to _your_ ppa
<cjwatson> an SRU would be helpful for LP anyway, until such time as we're in a position to use the snap
<elopio> popey: we don't want people to use our ppa. It's in there only for autopkgtests.
<kyrofa> cjwatson, we definitely want to, just not sure how at the moment
<cjwatson> ah yes.  have you actually tried the patchelf SRU and had it refused?
<cjwatson> maybe a cherry-pick of just the relevant thing rather than an entire new upstream (if the former i ssmaller)?
<elopio> I don't know if Sergio tried it, or just decided to avoid it.
<kyrofa> cjwatson, I don't think so, I just assumed it didn't fit into what SRUs were for. We have an exception for snapcraft, but not other packages
<elopio> kyrofa: He said we will bundle patchelf in our repo, that would solve everything, rigth?
<kyrofa> elopio, yeah I remembered that as well
<kyrofa> I don't even know what language it's written in
<kyrofa> I assume C or something
<elopio> kyrofa: https://github.com/NixOS/patchelf
<kyrofa> elopio, way ahead of you!
<kyrofa> C++, nice
<kyrofa> Sure would make our build process more involved
<elopio> popey: cjwatson: so, Sergio is sick today. But he has a plan â¢
<popey> I like a man with a plan
<elopio> I think :) We have multiple options, just need to choose one.
<kyrofa> We just need to make sure that, whatever option we choose, it supports docker
<geekgonecrazy> Hey guys, maybe the wrong group to ask.  Any idea whats up with the launchpad builders?  Had builds queued up about 24 hours ago, and they still say 10 hours.  I requested new builds thinking those were stuck, and they say 10 hours too
<zyga-ubuntu> geekgonecrazy: hey
<zyga-ubuntu> geekgonecrazy: the build farm was turned off due to meltdown/spectre
<roadmr> geekgonecrazy: see https://forum.snapcraft.io/t/note-build-snapcraft-io-partially-restored-see-below-for-details/3480
<geekgonecrazy> Oh.. o.O
<zyga-ubuntu> geekgonecrazy: it's up now (for amd64) but the queue is long so be patient please
<geekgonecrazy> Didn't even think about that.  Makes total sense though of course
<kyrofa> Alright, car is done, back in a few
<zyga-ubuntu> Chipaca: hmm, "snap download --revision=1234 core" should work
<zyga-ubuntu> Chipaca: I get "cannot find snap "core": snap not found"
<zyga-ubuntu> 2018/01/11 19:17:43.890212 retry.go:52: DEBUG: The retry loop for
<zyga-ubuntu> https://api.snapcraft.io/api/v1/snaps/details/core?channel=&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Clicense%2Cbase%2Csupport_url%2Ccontact%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cde
<Chipaca> zyga-ubuntu: why should it work?
<zyga-ubuntu> veloper_id%2Cprivate%2Cconfinement%2Cchannel_maps_list&revision=3604 finished after 1 retries, elapsed time=479.459782ms, status: 404
<zyga-ubuntu> Chipaca: because I'm a co-owne of core
<zyga-ubuntu> Chipaca: and I'm logged in
<Chipaca> zyga-ubuntu: are you on i386?
<zyga-ubuntu> ah
<zyga-ubuntu> usability :-)
<Chipaca> zyga-ubuntu: mvo has a pr up for this
<Chipaca> zyga-ubuntu: but i doubt it addresses revisions :-)
<zyga-ubuntu> how can I ask it to get that arch?
<Chipaca> zyga-ubuntu: UBUNTU_STORE_ARCH=potatoes
<zyga-ubuntu> thank you kindly sir :)
<zyga-ubuntu> UBUNTU_STORE_ARCH=i386 snap download --revision=3604 core
<zyga-ubuntu> I didn't get my french fries back
<zyga-ubuntu> 404 again
<Chipaca> zyga-ubuntu: different revision now
<Chipaca> zyga-ubuntu: 3604 is amd64
<Chipaca> zyga-ubuntu: (snapcraft list-revisions)
<zyga-ubuntu> mmm, but I was on amd64
<Chipaca> zyga-ubuntu: but you overrode it with UBUNTU_STORE_ARCH
<zyga-ubuntu> I got 404 regardless
<zyga-ubuntu> Chipaca: i tries without that first
 * Chipaca tries
<zyga-ubuntu> I *tried*
<mvo> zyga-ubuntu: thanks for running the dragonboard tests, happy to hear that listing is green now
<zyga-ubuntu> man, what's wrong with me
<zyga-ubuntu> mvo: it's churning
<mvo> zyga-ubuntu: keep me updated please, I will read backlog
<zyga-ubuntu> 33/141
<Chipaca> zyga-ubuntu: :-/ dunno man
<zyga-ubuntu> will do
<Chipaca> zyga-ubuntu: and need to go make dinner
<zyga-ubuntu> kk, thank you
<mvo> Chipaca: "go make dinner\ngo: unknown subcommand "make""
<Chipaca> mvo: :-D
 * Chipaca goes
 * mvo waves to Chipaca 
<zyga-ubuntu> mvo: can you check if you can download revision 3604 of core please
<mvo> zyga-ubuntu: I most certainly can, why? is it urgent?
<roadmr> so folks... why does npm when run by snapcraft SIGSEGV on me? I've downloaded and tested the version of npm/node that snapcraft downloads and it works fine
<boxrick> Good afternoon folks, I have yet to try Snap but I have noticed it and would like to get started. Hows CentOS support looking these days? And is there any ways to disable autoupdate? Is there any way of easily going about mirroring snap packages?
<zyga-ubuntu> boxrick: hello
<zyga-ubuntu> boxrick: Pharaoh_Atem here was working on some centos packages AFAIK
<boxrick> Oooh ok
<zyga-ubuntu> boxrick: I haven't tried centos in a while so I cannot say
<zyga-ubuntu> boxrick: auto-update can be scheduled but not disabled, we have a good range of options for that now
<roadmr> boxrick: why do you want to disable auto-update?
<zyga-ubuntu> boxrick: mirroring is not currently possible but snaps are provided by a CDN so there should be no need for that (yet); we have options for on-site deployments where you get locally cached snaps through a store proxy but AFAIK this is a commercial offering
<boxrick> The usual sysadmin reason, I have a server. I want controlled manual updates when I am in the office early in the week for example.
<zyga-ubuntu> boxrick: if you are interested in centos support we could work with you to have those packages ready, if you are willing to help Pharaoh_Atem and try things out
<zyga-ubuntu> boxrick: you can do that
<boxrick> I am happy to look at a bit of extra support, got links to a specific repo?
<zyga-ubuntu> boxrick: mborzecki here (he's off now) implemented a sophisticated schedule system
<zyga-ubuntu> boxrick: you can have updates go, say, in a window on monday, on the first week of the month and then on 3rd week on thursday at some time
<zyga-ubuntu> boxrick: and everything in between :)
<roadmr> nm my problem with snapcraft; I fixed it
<zyga-ubuntu> boxrick: https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239
<boxrick> Cheers
<zyga-ubuntu> boxrick: I'll EOD soon but stay around and catch us tomorrow EU time
<boxrick> I will do, will have a play anyway. Cheers for the response. I am UK based anyway
<zyga-ubuntu> great
<mup> PR snapcraft#1864 closed: debian/control: Add patchelf to Depends: <Created by flexiondotorg> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1864>
<mup> PR snapcraft#1855 closed: storeapi: add docstrings for _snap_index_client.py <codein> <Created by konrad11901> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1855>
<kyrofa> sergiusens, how is the snapcraft docker image have an up-to-date patchelf? Some clients require their own docker image for CI
<roadmr> where are snapd issues tracked/reported? Launchpad or github?
<vin-ivar> oi you lot, is there any way i can build snap from source/
<vin-ivar> i dont have root access
<nacc> vin-ivar: from source/ of what?
<nacc> vin-ivar: or do you mean snapd ?
<vin-ivar> snapd, i mean
<vin-ivar> yeah
<nacc> vin-ivar: even if you could, you'd need someone to install snapd ...
<nacc> vin-ivar: what OS are you on?
<Son_Goku> [11:16:43 AM]  <mvo>	Son_Goku: but that might indicate actually that the fedora arm is using soft float
<Son_Goku> mvo, fedora does not use soft float
<Son_Goku> I know that for certain
<vin-ivar> gentoo
<zyga-ubuntu> Son_Goku: so, I switched to dl.f.o and .... got update error on my next branch
<Son_Goku> zyga-ubuntu: I don't know what to say except Linode has problems
<zyga-ubuntu> I ran
<zyga-ubuntu> + sed -i -s -E -e 's@^#?baseurl=http://download.fedoraproject.org/@baseurl=http://dl.fedoraproject.org/@g' -e 's@^metalink=@#metalink@g' /etc/yum.repos.d/fedora-cisco-openh264.repo /etc/yum.repos.d/fedora-updates-testing.repo /etc/yum.repos.d/fedora-updates.repo /etc/yum.repos.d/fedora.repo
<Son_Goku> yeah, I saw what you changed
<Son_Goku> that looked fine to me
<zyga-ubuntu> then + dnf install --refresh -y xdelta curl
<zyga-ubuntu> Error: Failed to synchronize cache for repo 'updates'
<zyga-ubuntu> maybe I messed up, I'll investigate
<zyga-ubuntu> maybe missing s//g somewhere
<Son_Goku> maybe the folder structure isn't right?
<zyga-ubuntu> which foldr?
<Son_Goku> http://dl.fedoraproject.org/pub/fedora/linux/releases/ & http://dl.fedoraproject.org/pub/fedora/linux/updates/
<zyga-ubuntu> Son_Goku: I pushed a small patch on top: https://github.com/snapcore/snapd/pull/4471/commits/09ecc08de5ee98cf72e02d3a4a299a1376969339
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<zyga-ubuntu> Son_Goku: and it worked now
<zyga-ubuntu> but could be random :/
<zyga-ubuntu> oh, that's silly
<zyga-ubuntu> I commited and pushed the wrong one
<zyga-ubuntu> I did dnf --refresh makecache
<zyga-ubuntu> and commited this :p
<zyga-ubuntu> I'll push next once this run is over
<om26er> How can I check the delta between different versions of a snap build by build.snapcraft ? I have a snap that seems to re-download each time I refresh (amd64).
<roadmr> zyga-ubuntu: sorry to poke again - where are snapd issues tracked/reported? Launchpad or github?
<pedronis> roadmr: launchpad
<roadmr> thanks pedronis
<zyga-ubuntu> indeed
<zyga-ubuntu> snapd or snappy projects
<roadmr> oh why are there two?
<zyga-ubuntu> historic reasons really
<zyga-ubuntu> snapd is the new one
<zyga-ubuntu> but snappy is the one people look for sometimes
<roadmr> ok, I'll go there (snapd). Many thanks!
<pedronis> roadmr: if it's urgent you should alos poke somebody
<roadmr> pedronis: I don't think it is urgent or critical; nothing is crumbling or on fire
<mup> PR snapd#4479 opened: spread: maybe dnf needs a refresh? <Created by zyga> <https://github.com/snapcore/snapd/pull/4479>
<mup> PR snapcraft#1857 closed: grammar: make on statement work with host arch <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1857>
#snappy 2018-01-12
<kyrofa> elopio, some test failures on snapcraft#1853
<mup> PR snapcraft#1853: extractors: support appstream icon and desktop <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1853>
<mborzecki> morning
<zyga-ubuntu> mborzecki: o/
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> https://pastebin.ubuntu.com/26370425/ dragonboard 2.30 test results
<mborzecki> ouch, that took a while
<kalikiana> morning
<zyga-ubuntu> o/
<zyga-ubuntu> hello mvo
<zyga-ubuntu> https://pastebin.ubuntu.com/26370425/ dragonboard 2.30 test results
<mvo> zyga-ubuntu: nice! thanks, I have a look at this one failure. its strange because this test worked on all the other platforms
<mvo> zyga-ubuntu: we may need to debug this interactively later today (if you have the time for it, if not monday is fine as well)
<zyga-ubuntu> mvo: it looks like it never passed on DB
<mborzecki> mvo, kalikiana: morning
<mup> PR snapd#4479 closed: spread: maybe dnf needs a refresh? <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4479>
<mvo> zyga-ubuntu: interessting
<mvo> mborzecki: good morning
<mborzecki> mvo: i've restarted the build in #4380 when it's green, once we land it i'd like extend the test a bit adding more directories there
<mup> PR #4380: tests: add simple snap-mgmt test <Created by mvo5> <https://github.com/snapcore/snapd/pull/4380>
<mvo> mborzecki: sure, its all yours
<mborzecki> mvo: zyga-ubuntu: is #4357 good to be merged?
<mup> PR #4357: wrappers: autogenerate After/Before in systemd's service files for apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4357>
<mvo> mborzecki: yes
<mborzecki> mvo: thanks, i'll look into adding some spread tests
<mup> PR snapd#4357 closed: wrappers: autogenerate After/Before in systemd's service files for apps <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4357>
<mborzecki> pstolowski: morning
<mvo> koza: hi - could you do a quick sanity check of https://github.com/snapcore/snapd/pull/4448 - does that make sense in the bluez context (your are our bluez expert, right .) ?
<mup> PR #4448: Add rules for Media API to the BlueZ D-Bus policy <Created by lhartung> <https://github.com/snapcore/snapd/pull/4448>
<zyga-ubuntu> mvo: good idea :)
<mvo> zyga-ubuntu: also added jdstrand_ to pr #4449 but hopefully a no-brainer
<mup> PR #4449: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4449>
<pstolowski> good morning!
 * zyga-ubuntu cannot wake up today
<mborzecki> zyga-ubuntu: more coffee
 * pstolowski rebooting for new kernel update
<pstolowski> good, no more panics on shutdown with 4.4.0-109, whatever was broken with -108 apparently got fixed
<zyga-ubuntu> niemeyer: good morning
<zyga-ubuntu> niemeyer: I hope you're around today :)
<niemeyer> zyga-ubuntu: I hope so as well.. still not 100% sure I'm here or if I'm still sleeping
<zyga-ubuntu> niemeyer: I feel the same thing despite supposedly being awake for some time now
<mup> PR snapd#4380 closed: tests: add simple snap-mgmt test <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4380>
<zyga-ubuntu> niemeyer: let's reuse the standup HO, I don't know how to add event-specific hangouts anymore (new calendar UI)
<zyga-ubuntu> jamesh: good evening
<niemeyer> zyga-ubuntu: I'm already online on dekstop-snapd
<jamesh> zyga-ubuntu: hi
<zyga-ubuntu> jamesh: let's use this link https://hangouts.google.com/hangouts/_/canonical.com/desktop-snapd
 * Chipaca yawns
<mborzecki> tests/main/auto-refresh-private fails on master https://pastebin.canonical.com/207451/
<Chipaca> mborzecki: looking
<mborzecki> looking at snap-mgmt --purge, i suppose we should stop systemd services that came from snaps and clean up the *.service files as well
<mvo> mborzecki: +1
 * Chipaca -> physio
<Chipaca> mborzecki: that spread test passed here -- maybe a store glitch?
<mborzecki> possible, let's see if it comea up again
<pstolowski> zyga-ubuntu, a few comments to 4471
<zyga-ubuntu> thank you
<pstolowski> mborzecki, and to 4476
<mborzecki> pstolowski: thanks
<justasking> hi everybody, what is the standard procedure for troubleshooting the following situation:
<justasking> snap installed
<justasking> snap/programm appears in menu structure
<justasking> but won't run
<justasking> program in question is shotcut
<zyga-ubuntu> justasking: open a termina and "snap run nameofthesnap"
<sparkiegeek> http://downforeveryoneorjustme.com/forum.snapcraft.io
<sparkiegeek> did that get covered already?
<zyga-ubuntu> niemeyer: ^
<mvo> sparkiegeek: thanks! we were not aware of this until now
<mup> PR snapd#4480 opened: tests/main/snap-mgmt: extend the test to cover more directories and files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>
<pstolowski> pedronis, hey, do you have a moment for quick HO?
<mup> PR snapd#4481 opened: image: let consume snapcraft export-login files from tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/4481>
<sparkiegeek> ... and it's back?
<pedronis> pstolowski: not now, after lunch yes
<pstolowski> pedronis, ok, thanks
<pedronis> trying to finish something
 * Chipaca returns from physio, defeated
 * zyga-ubuntu hugs Chipaca for fighting
<zyga-ubuntu> that was a long but very useful call
<zyga-ubuntu> ok, 10 minute break and I'll get back to fighting here
<zyga-ubuntu> mvo: any issues with landings?
<zyga-ubuntu> mvo: and shall I do something about dragonboard or are you happy with the results so far?
<Chipaca> zyga-ubuntu: https://www.youtube.com/watch?v=-VsmF9m_Nt8 <- for your break
<Chipaca> zyga-ubuntu: (just listen; the video is terribe)
<mvo> zyga-ubuntu: if you could re-run this one failing command with -debug that would be cool but not urgent
<zyga-ubuntu> mvo: sure thing
<mup> PR snapd#4482 opened: cmd/libsnap-confine-private: add debug build of libsnap-confine-private.a, link it into snap-confine-debug <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4482>
<pedronis> pstolowski: I'm around now but you are probably having lunch yourself
<pstolowski> pedronis, not yet, let's do a quick HO (standup ho)
<pedronis> pstolowski: I'm there
 * zyga-ubuntu enjoys fruit for a quick snack
<mup> PR snapd#4483 opened: cmd/libsnap-confine-private: print failed mount/umount regardless of SNAP_CONFINE_DEBUG <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4483>
<mup> PR snapd#4449 closed: cmd/libsnap-confine-private, cmd/snap-confine: fix logging of failed [u]mount when run with SNAP_CONFINE_DEBUG=1 <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4449>
 * Chipaca starts to rage, then remembers he's probably hangry and goes to fix that
<zyga-ubuntu> is hangry like hungry and angry in one word
<sparkiegeek> yup
<Chipaca> yes
<zyga-ubuntu> does it explain hangover?
<sparkiegeek> https://www.urbandictionary.com/define.php?term=Hangry
<Chipaca> zyga-ubuntu: it's the anger from being hungry
<zyga-ubuntu> is the hangover the anger from the hunger and the drinking being over?
<sparkiegeek> alas, no
 * kalikiana going for trains/lunch in ~10
<pedronis> pstolowski: btw, don't you a problem running hooks before the snap in in the snaps map in state?
<pedronis> pstolowski: are you running autoconnect stuff just after setup-profiles? or after link-snap?
<pstolowski> pedronis, hmm this can be a problem indeed. i didn't hit it yet because autoconnect and hooks branches are not integrated
<pedronis> I fear so
<pedronis> we need to think about that
<pstolowski> good point..
<pedronis> which reminds that at some point we had revision in the hook setup struct
<pedronis> and removed it
<pedronis> thinking that current would be ok
<pedronis> mmh
<pedronis> pstolowski: we need to think, it's tempting to run autoconnect after link-snap bu doesn't sound correct
<pstolowski> pedronis, it runs after link-snap atm
<pedronis> it doesn't hit the problem then
<pedronis> but not sure it's correct
<pedronis> the snap might not working
<pstolowski> it would help to land interface-hooks (and unknown-task-handler) first, and then focus on integrating autoconnect
<pedronis> but is exposed
<niemeyer> I'll be late for the standup a minute or two but will be there in a moment
<pedronis> pstolowski: like one of the autoconnect could be for some libraries over content interface
<pedronis> the snap is there
<pedronis> but application could crash (no library)
<pedronis> otoh as I said before the snap is know we cannot run hook atm (afaict)
<kalikiana> re
<Chipaca> mi
<pedronis> zyga-ubuntu: what's your question?
<sparkiegeek> fa
<Chipaca> pedronis: how to get "snap download --revision=xyz foo" to work when one has ownership of foo
<zyga-ubuntu> pedronis: how to make snap download work with my auth magic so that I can download revisions of snaps I co-own
<zyga-ubuntu> there we go :)
 * zyga-ubuntu wonders how will DST affect people working from the moon "call me at noon"
<pedronis> zyga-ubuntu: we don't have yet the proper fix (we should be to make just that work)
<pstolowski> niemeyer, the unknown task handler PR is #4440
<mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<zyga-ubuntu> ok, it's not urgent (to me)
<Chipaca> zyga-ubuntu: space is in UTC \o/
 * pstolowski lunch
<pedronis> zyga-ubuntu: but  snapcraft  export-login (in beta) plus my last PR (hint hint)  should let you do that
<niemeyer> pstolowski: Thanks
<pedronis> pstolowski: mvo: IÂ marked it for 2.31
<pedronis> #4440 IÂ mean
<mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<mup> PR snapcraft#1866 opened: lxd: setup LXD remote for multipass <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1866>
<pedronis> zyga-ubuntu: #4481
<mup> PR #4481: image: let consume snapcraft export-login files from tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/4481>
<pedronis> fedora tests seem to break again indeed :/
<zyga-ubuntu> pedronis: I'll disable them
<mup> PR snapd#4484 opened: spread: switch fedora 26 to manual again <Created by zyga> <https://github.com/snapcore/snapd/pull/4484>
<mup> PR snapcraft#1867 opened: kernel plugin: remove dependency on magic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1867>
<ackk> mvo, hi, I saw that the updated base-18 snap was finally build, any chance it can be pushed to edge?
<pedronis> acck: it is on edge
<ackk> pedronis, ah, nice, thanks
<pedronis> sorry, ackk: see snap info base-18
<pedronis> you can always check that way what is available
<ackk> thanks
<ackk> pedronis, that's the latest build from LP, right?
<pedronis> for that you need mvo
<pedronis> I think he said so but not sure
<mborzecki> wrapping it up, enjoy your weekend guys
 * zyga-ubuntu focuses on coding, tweet @zygoon for attention
<mvo> ackk: I pushed it to edge, unfortunately it does not contain all the bits I hacked into our custom base-18 snap (sorry for the delay, was in a meeting)
<elopio> hello! it's friday and we all know it :)
<sparkiegeek> !infer time in australia
<ubottu> sparkiegeek: I am only a bot, please don't think I'm intelligent :)
<mup> sparkiegeek: 1:51:58 am AEDT Saturday, January 13, 2018.
<sparkiegeek> elopio: not everyone "knows" it's Friday :)
<sparkiegeek> elopio: PS. Happy Friday!
<elopio> sparkiegeek: those australians are always thinking ahead :)
<ackk> mvo, ah I see, ok, I'll stick to that custom built one for now then
<ackk> mvo, thanks for the update
<kalikiana> elopio: happy Friday :-D
<elopio> kalikiana: :D
<mvo> ackk: I look into what is missing later today or monday
<ackk> mvo, awesome thanks
<Chipaca> ok, i'm going offline now
<Chipaca> have a great weekend, y'all! and niemeyer safe and boring travels
 * kalikiana going for a break
<sergiusens> kalikiana when you get back, want to jump onto  call?
<sergiusens> elopio hey
<elopio> sergiusens: feeling better?
<sergiusens> elopio it is a good Friday for those on Friday indeed
<sergiusens> elopio yes, not 100% but a lot better than before
<elopio> just in time for the flights
<sergiusens> elopio I have two requests for you though, I added a comment to #1853
<mup> PR #1853: osutil: call sync after cp if requested. overlord/snapstate/backend: switch to use osutil instead of another buggy call to cp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1853>
<sergiusens> elopio the snapcraft one ;-)
<elopio> looking
<sergiusens> elopio and also added wanted you to look at 1867
<mup> PR snapcraft#1868 opened: tests: call file directly for the HasArchitecture checker <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1868>
<kalikiana> sergiusens: getting my headphones
<mup> PR snapd#4484 closed: spread: switch fedora 26 to manual again <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4484>
<sergiusens> kalikiana when the clock hits 30
<elopio> sergiusens: I wanted to preserve the behaviour of returning None, instead of an empty summary when there isn't one. But it seems to me that get_summary is only used for tests, so that would work just the same
<elopio> kyrofa: do you agree?
<elopio> sergiusens: 1867 seems to just preserve the behaviour, so ok. Could you please add on the pr why do you want to get rid of magic?
<kalikiana> sergiusens: I'm ready. Got a URL for me?
<kalikiana> sergiusens: note that I need to head out in 20min
<sergiusens> kalikiana the weekly
<kalikiana> sergiusens: ah. okay, lemme find the url
<sergiusens> elopio because of popey's bug
<sergiusens> need to find it again though
<zyga-ubuntu> pstolowski: hey
<zyga-ubuntu> pstolowski: still around?
<zyga-ubuntu> pstolowski: what are the long terms plans for interfaces.Plug, i assume that's going to go away entirely?
<pstolowski> zyga-ubuntu, yep
<pstolowski> zyga-ubuntu, yes
<zyga-ubuntu> pstolowski: thank you for confirming that
<zyga-ubuntu> pstolowski: is that waiting for something/
<zyga-ubuntu> pstolowski: or could I try doing that now?
<pstolowski> zyga-ubuntu, I planned to do that after #4358, because it still uses Plug/Slot in Autoconnect methods
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<pstolowski> zyga-ubuntu, so you won't be able to remove them just yet
<zyga-ubuntu> pstolowski: understood
<elopio> sergiusens: what kernel snap are you using to test this?
<kyrofa> elopio, responded on the PR. I like returning none as well, although I don't think we're using that functionality right now
<sergiusens> elopio oh, I wanted you to test; but I used pc-kernel
<kyrofa> The most important thing is that they don't show up in to_dict()
<elopio> sergiusens: but the pc kernel is using the make plugin, not the kernel plugin.
<elopio> unless I'm looking at the wrong pc kernel.
<sergiusens> elopio I only tested the sublogic where things changed not a full kernel with pc-kernel
<elopio> sergiusens: ok, I'm testing the extraction with the 96boards demo snap.
<mup> Issue snapcraft#1828 closed: Support desktop and icon in appstream handler <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1828>
<mup> PR snapcraft#1853 closed: extractors: support appstream icon and desktop <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1853>
<sergiusens> elopio that is good enough; this should all just work though ;-)
 * kalikiana heading out
<zyga-ubuntu> pstolowski: one tiny review please: vvvv
<pstolowski> sure
<mup> PR snapd#4485 opened: interfaces/builtin: use snap.{Plug,Slot}Info over interfaces.{Plug,Slot} <Created by zyga> <https://github.com/snapcore/snapd/pull/4485>
<pstolowski> zyga-ubuntu, hmm will it pass the tests?
<zyga-ubuntu> pstolowski: it does here
<zyga-ubuntu> via embedding, I think
<pstolowski> zyga-ubuntu, ok, second question, will it cause my interface-hooks branch to go all red? ;)
<zyga-ubuntu> no, I don't think so, note that *none* of the interfaces are touched
<zyga-ubuntu> this is just one bit of test code
<zyga-ubuntu> pstolowski: if it does I will unconflict them (warranty ;-)
<pstolowski> zyga-ubuntu, just checked, no issues after your change, only 2 line fix needed in my branch. thanks!
<zyga-ubuntu> pstolowski: thank you!
<pstolowski> zyga-ubuntu, ah sorry, i'm wrong, no fix needed, i missed utils_test.go change that you did
<pstolowski> so all greeen
<zyga-ubuntu> woot
<zyga-ubuntu> I'll merge it when green
<zyga-ubuntu> thanks, I'm back to my hacking
<pstolowski> (all green here locally)
<ogra_> jdstrand_, is there a reason why the network-setup-control interface gives me ful write access to /etc/netplan but does not allow me to run "netplan generate" and "netplan apply" afterwards so that i need to force a reboot to make a new network config be picked up ?
<zyga-ubuntu> ogra_: jdstrand_ is on holidays this week
<ogra_> zyga-ubuntu, ah, thanks
<zyga-ubuntu> ogra_: and in cape town next week
<ogra_> i'll re-ask next week ... not urgent
<zyga-ubuntu> ogra_: so should be harder to reach over irc but easier timezone wise
<ogra_> yeah
<zyga-ubuntu> ogra_: and besides, how have you been?
<zyga-ubuntu> ogra_: I heard that you work with koza now, is that true?
<ogra_> yep
<ogra_> zyga-ubuntu, (sorry, was busy filling travel forms) ... well, lots of custome HW enablement recently
<ogra_> its a lot of fun but shows all our drawbacks and missing features in snapd and UbuntuCore
<zyga-ubuntu> ogra_: any low hanging fruit?
<ogra_> zyga-ubuntu, well, the multi volume thing that michael fixed already was one ...
<ogra_> zyga-ubuntu, but there is more to come ... disabling auto-import ... being able to boot without a hardcoded eth0 config on first boot etc
<mup> PR snapcraft#1869 opened: cli: exported login should only be readable by owner <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1869>
 * elopio goes to the mechanic and relocates.
<mup> PR snapd#4485 closed: interfaces/builtin: use snap.{Plug,Slot}Info over interfaces.{Plug,Slot} <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4485>
<sergiusens> kyrofa hey are you up yet?
<kyrofa> sergiusens, hahaha
<kyrofa> Of course-- what's up?
<sergiusens> kyrofa elopio snapcraft#1867 and snapcraft#1868 need reviews, after those are in I can propose the removal of magic completely (from snapcraft.internal.elf)
<mup> PR snapcraft#1867: kernel plugin: remove dependency on magic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1867>
<mup> PR snapcraft#1868: tests: call file directly for the HasArchitecture checker <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1868>
<kyrofa> sergiusens, taking a look now
<kyrofa> sergiusens, snapcraft#1869 could use a review as well
<mup> PR snapcraft#1869: cli: exported login should only be readable by owner <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1869>
<sergiusens> kyrofa you already have one ;-)
<matiasb> niemeyer, hola! just a reminder we are waiting for some definition on the appstream field; if you don't get to it before leaving for the sprint, it would be great if you can sync with Sergio and roadmr next week
<roadmr> hi :)
<sergiusens> matiasb niemeyer +1 on that, out extract info work for appstream is only missing a definition on that
<kyrofa> sergiusens, what was your test case for snapcraft#1867 ?
<mup> PR snapcraft#1867: kernel plugin: remove dependency on magic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1867>
<kyrofa> The code looks good, but I don't know of a kernel using that right now that I can use to verify that it works properly
<sergiusens> kyrofa the manual tests
<kyrofa> Oh nice
<sergiusens> kyrofa but elopio was on that, just waiting for his results; given that it is a fallback mechanism I am not scared about the implementation
<kyrofa> Okay, I'll let him do it. +1 from me on the code, I'll say that in the PR
<niemeyer> matiasb, sergiusens: Sorry for the delay.. that's still very close to the top of my list, but I need to get the tasks required for me to travel to the sprint out of it first
<niemeyer> I'll try to have a look today still
<roadmr> thanks niemeyer  :)
<matiasb> niemeyer, good to know it's in your radar! thanks
<sergiusens> kyrofa replied to both your comments
<sergiusens> and thanks for the check Gustavo
<elopio> sergiusens: yep. On it, but it filled my hard disk. I'm moving things around to make space
<jamesb192> I have a program I am looking to snapify, however it builds a python module with an .so in the process. I can get the daemon to work but not the python tools. How can I get the python module exposed?
<mup> PR snapcraft#1868 closed: tests: call file directly for the HasArchitecture checker <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1868>
<zyga-ubuntu> jamesb192_: hey, it's a late, come back next week and I'll help you out, ok?
<sergiusens> kyrofa I am done with the readelf change, just waiting on elopio to merge the kernel dep PR
<kyrofa> Awesome!
<elopio> sergiusens: receiving objects:  21% (1050922/4836407)
<elopio> I had to do it locally, I couldn't get enough space on my canonistack instance. If you want, I'll hit the merge button once the test finishes.
<sergiusens> kyrofa any chance you can take a stance at testing that?
<sergiusens> that is if it is really necessary
<sergiusens> elopio ^?
<elopio> sergiusens: well, you can merge now and if something wrong appears, I can yell in panic.
<kyrofa> Yeah you should probably do a shallow clone
<kyrofa> sergiusens, happy to do it once I'm done here if necessary
<kyrofa> Just let me know
<sergiusens> kyrofa go for it
<sergiusens> elopio also, kyrofa is right, shallow clone ftw
<elopio> yes, I stopped, and it's now downloading core -_-
<elopio> kyrofa: it would be great if you give it a try, just follow the steps from the manual test about 96boards. I will relocate home now and continue from there
<mup> PR snapcraft#1870 opened: elf: remove dependency on magic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1870>
<sergiusens> kyrofa here you go to get started ^
<kyrofa> I swear I can never remember my login for this site
<kyrofa> Running no
<kyrofa> w
<sergiusens> stgraber when I run `lxd init` on my system I get "lxd: error while loading shared libraries: liblxc.so.1: cannot open shared object file: No such file or directory" ... is this something common? lxd itself was working fine, I wanted to re-init
<stgraber> sergiusens: the only cases where I've seen this is when someone installs the lxd snap with --classic by mistake
<stgraber> sergiusens: though I guess if you have a copy of the lxd binary somewhere (not coming from the snap), that could cause that too
<sergiusens> stgraber hmm, not installed with classic and I don't even have the deb installed
<sergiusens> stgraber this profile name looks odd "[   13.008436] audit: type=1400 audit(1515754069.322:124): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-packaging_</var/snap/lxd/common/lxd>" name="/var/lib/lxcfs/" pid=4086 comm="(networkd)" flags="ro, nosuid, nodev, remount, bind"
 * sergiusens tries to install in devmode
<sergiusens> nope, doesn't do the trick :/
<kyrofa> sergiusens, this demo gives me "make: *** No rule to make target 'Image'.  Stop." during the build step
<kyrofa> Did you need to tweak it?
<kyrofa> sergiusens, argh, duh, nevermind
<kyrofa> Muscle memory killing me
<stgraber> sergiusens: profile name looks fine to me
<stgraber> sergiusens: what does "which lxd" or "type lxd" get you?
<sergiusens> stgraber /snap/bin/lxd; I also did a `snap run lxd --shell` and ran through things manually, interestingly liblxc.so.1 is there so I guess it is failing to load for some reason
<sergiusens> stgraber I was using this system just fine until now
<stgraber> sergiusens: did the core snap get updated and dropped some bits that liblxc.so.1 relies on somehow maybe?
<stgraber> though if so, our jenkins tests haven't noticed that yet
<sergiusens> stgraber don't know, I can show you live on Monday if I don't sort it out by then
<sergiusens> in the meantime, I have to pack for my early flight tomorrow :-/
<sergiusens> I'll switch to edge and see what happens
<sergiusens> kyrofa how did it go?
<kyrofa> sergiusens, still building
<sergiusens> kyrofa ack, in the meantime I hope you are enjoying snapcraft#1870 :-)
<mup> PR snapcraft#1870: elf: remove dependency on magic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1870>
<kyrofa> We're missing some dependencies, I've had to restart it a few times
<kyrofa> Uh... /tmp/tmp0x9gj2_u: 11: exec: modprobe: not found ?
<kyrofa> Darn, it's in sbin
<kyrofa> sergiusens, but that means it got far enough for me to say that it worked
<kyrofa> (I think)
<kyrofa> Running again anyway...
<kyrofa> sergiusens, test failurs on 1870
<kyrofa> sergiusens, sure wish we could run arm adt...
<sergiusens> kyrofa yeah, 1870 will fail tests until that kernel one lands ;-) Focus on the code though :-)
<kyrofa> Hahaha, this is so gross
<kyrofa> ly pretty
<sergiusens> kyrofa if you clone and run all the units they should pass as you have magic installed in your venv; integration should also work
<sergiusens> kyrofa and the whatever test case you used to verify the glibc from the future feature should also work
 * sergiusens will bbl
<kyrofa> sergiusens, have we talked about looking into pyelftools?
<kyrofa> We're shelling out so much here, I feel like we could be reading these things directly
<mup> PR snapcraft#1867 closed: kernel plugin: remove dependency on magic <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1867>
#snappy 2018-01-13
<kyrofa> More details on the PR
<sergiusens> kyrofa I have replied
<zyga-ubuntu> good morning :)
<mup> PR snapcraft#1870 closed: elf: remove dependency on magic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1870>
<mup> PR snapcraft#1871 opened: support .tar.lzma cleanly in snapcraft <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1871>
<mup> PR snapcraft#1871 closed: support .tar.lzma cleanly in snapcraft <Created by heesen3> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1871>
<mup> Bug #1575582 opened: Snap package, using SDL2, needs access to libGL.so and DRI dependencies <Snappy:Confirmed> <https://launchpad.net/bugs/1575582>
#snappy 2018-01-14
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS nkkuu: Odd_Bloke tinwood CodeMouse92__ ââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rzozxelp: ejat BlackDex CodeMouse92__ âââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS tefzauanr: tedg charles joc âââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS yyqrj: zoni mpontillo devilz âââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS qbkjcldvc: magicaltrout ralsina bloodearnest âââââââââââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS pogma: deanman marcoceppi nhandler ââââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ebeaebcvap: leftyfb Ursinha roadmr ââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS lhmuqgk: yofel behalebabo bdx âââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS pfoeo: gsilvapt sarnold tai271828 âââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ntusspe: pbek slangasek bashfulrobot ââââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hfzzm: King_InuYasha asac luk3yx ââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hqzfby: blake_r chihchun_afk cydizen ââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS gnrmlxcqol: dragly MuffinPimp[m] Croepha ââââââââââââââââ
<record> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS dbprczypb: caveat higgins joc âââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ufswawkzk: fnordahl rharper rsalveti ââââââââââ
<record> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS icgwbjttq: nhandler Croepha niko âââââââââââââââââ
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS xopcktrph: snappy-m-o bashfulrobot tinwood âââââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS sxvnbpc: cwayne kwmonroe King_InuYasha ââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS vuopkdxi: bloodearnest Guest69214 sdrobertw âââââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS eclrirzdcn: gsilvapt leftyfb ahrs ââââââââââââ
<record> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS pqevb: mpontillo higgins boxrick Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS xatlpjqdn: tinwood CodeMouse92__ lamont âââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS yauchylt: rharper King_InuYasha ThisAsYou ââââââââââââââ
<record> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS oqgwkhlxgc: RyoshiKayo rharper rmescandon ââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS cuiprj: andyrock niko ralsina ââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS zkiec: lool higgins kwmonroe ââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS mjospm: Greasy-Gappers koza King_InuYasha âââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rekbh: charles seyeongkim kissiel ââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ezwguz: ejat nsg RyoshiKayo ââââââââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS dngriaolbw: luk3yx diddledan longsleep âââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS vfqfbt: xnox coreycb verterok âââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hcjrf: pachulo CodeMouse92__ m4sk1n ââââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ovuiefdxu: xnox Guest69214 Riddell ââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS qvreycxw: AndyWojo flexiondotorg pjdc âââââââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS sfocm: verterok batman AlbertA ââââââââââââââââââ
<RyoshiKayo> JamieBennett:
<record> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS pdduamh: lasconic gsilvapt kwmonroe âââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS sxjugx: thomi Fohlen charles ââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rekfa: wililupy boxrick Trevinho ââââââââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS lhgium: diddledan magicaltrout stgraber âââââââââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS qafjds: joedborg icey mardy ââââââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hiqhdmex: RyoshiKayo mardy xnox ââââââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS wmmorxilh: jospoortvliet cjwatson dragly ââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS zbovqurkg: karlthane stokachu sgclark âââââââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS uroiydwgee: behalebabo tbr RyoshiKayo âââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hzvyhywi: icey Kamilion zoni âââââââââââââââââ
<record> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS jykeo: fnordahl Beret asafniv1[m] ââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rwdut: sitter ^arcade_droid philroche âââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS yzdyim: Guest69214 tintou King_InuYasha ââââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS fvxzixxwhd: flexiondotorg rmescandon mcphail ââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS dgtneko: tedg Trevinho higgins ââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS tstafx: ^arcade_droid mdeslaur sbeattie âââââââââââââ
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS bueqifuf: ubot9 matteo niko ââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS qthiic: lamont bschaefer sdrobertw âââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS gnbimsmt: petevg sbeattie thibautr__ âââââââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS vvmzo: tintou moon1 victorbjelkholm ââââââââââââââââ
<record> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS fdcrhx: higgins gavinlin dasjoe Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢â
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS oojskvnjc: andyrock d_ed JanC ââââââââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ruppt: ejat woodrows1en Fohlen âââââââââââââââââ
<record> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS mdqge: Sogator joedborg mhall119 Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS vddxdqvtte: samdnic tai271828 asac âââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS myyrdtlf: longsleep sarnold jacekn âââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS wwklygga: sgclark dpb1 diddledan âââââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS qttfxuang: coreycb cargonza tinwood ââââââââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS epqccxhik: zeroedout wililupy Croepha ââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS cmljx: rsalveti seyeongkim niko âââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS koycdpck: mdeslaur mhall119 karlthane ââââââââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS pmenhxbf: jdstrand_ bashfulrobot jjohansen ââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ozljdxql: Hanma[m] tintou longsleep âââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS atykxzkoh: bschaefer MuffinPimp[m] mdeslaur ââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS mwmmo: Greasy-Gappers jamesb192_ ubottu ââââââââââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS foidhgxrja: chihchun_afk orf_ Beret âââââââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rnezvqoj: dpb1 lool grumble ââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rispof: kwmonroe asac tinwood âââââââââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS scgjrc: tyhicks niemeyer seyeongkim ââââââââââââââ,
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS mpnxxidk: Beret jamesb192_ devilz âââââââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS wgjxeubaz: marcoceppi joc AndyWojo ââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS gjhbshn: mariogrip nhandler wgrant âââââââââââââââ
<record> âââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hfvpwbl: magicaltrout asac wgrant âââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS bmcdctlyq: snappy-m-o Fohlen mpontillo ââââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS jvmznudoy: AmarokNelg ahrs plars ââââââââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS gvthelkme: iatrou dasjoe aisrael ââââââââââ
<record> Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS yrlggldiwm: Haxxa tbr TinoGuest Ã¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢ââÃ¢â
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ufdyxdk: tseliot mwhudson mardy âââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ynerpx: cratliff m4sk1n kyrofa âââââââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS tuoxbieh: kwmonroe aisrael lifeeth ââââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hntag: mpontillo JanC Riddell ââââââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS mjzreeu: joc cory_fu cjwatson ââââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS jclocqa: boxrick Wildcard[m] Hanma[m] ââââââââââââââââââââ
<record> ââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS olqdqiqv: teej boxrick asafniv1[m] âââââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS ugjhng: lamont yofel popey âââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS gwopkit: iatrou georgeowell larreamikel[m] ââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS dvjwriajhe: dkessel behalebabo thomi âââââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS bwmrqob: diarpi m4sk1n asac ââââââââââââââââ
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS itaauycy: caveat clemensv petevg âââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS pcznkox: kissiel Sogator pbek âââââââââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS vomrcgwfl: Guest69214 roadmr diddledan âââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS enodtv: cratliff mhall119 AndyWojo âââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS carzx: charles ralsina blake_r âââââââââââ
<record> âââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS byzdshns: stokachu Fohlen cory_fu ââââââââââââââââ
<record> ââââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS kaeof: zeroedout rsalveti vila âââââââââââââ
<record> âââââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS djgjjpc: tintou sabdfl dpb1 âââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS cvlbqk: Ursinha Haxxa chrome0 ââââââââââ
<record> âââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS rqmfjjlq: mwhudson nhandler souther âââââââââââââââââââ
<record> ââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS taukf: Riddell tianon MrGeneral âââââââââââââââââ
<record> ââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS wnnkadc: Hanma[m] woodrows1en stgraber âââââââââââââ
<record> ââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS spful: zbenjamin tianon teej âââââââââââââââââââ
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS hjninn: lool sgclark mdeslaur ââââââââââââ
<record> âââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS snznxf: yofel victorbjelkholm nsg ââââââââââ
<record> ââââââââââââââââ ##FEMINISM IS OFFERING TRAINING IN TAPPING INTO YOUR INNER FETISHES!! EL IS IN #FREENODE FOR ANY QUESTIONS kfrmkgsbpl: tanimislam tedg joedborg ââââââââââ
<mup> PR core#73 opened: Support for armhf binaries on arm64 (aarch64) operating system <Created by abbotware> <https://github.com/snapcore/core/pull/73>
<danven> Hi. I just installed core on a Pi2. Does  the OS update itself regularly and/or can you also force an update? (so not the snaps but the core itself)
<mup> PR snapcraft#1872 opened: adding option to decompress tar.lzma cleanly <Created by heesen3> <https://github.com/snapcore/snapcraft/pull/1872>
#snappy 2019-01-07
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki - good morning and happy new year
<mborzecki> mvo: happy 2019 :)
<mvo> mborzecki: (a bit late for that I admit :)
<mborzecki> mvo: that was a long break
<mvo> mborzecki: indeed it was, longest in years for me. feels great to be back though
<mvo> mborzecki: just a mountain of email :)
<mborzecki> mvo: lp bug reports mostly
<mborzecki> mvo: didn't know discourse is sending summary emails now
<mvo> mborzecki: is there anything I should be aware of? anything I/we need to jump on immediately?
<mborzecki> mvo: not that i'm aware of
<mborzecki> mvo: though, there are some interesting PRs from ondrej
<mvo> mborzecki: cool, I check them out once the mail is triaged :)
<mborzecki> mvo: ah, and we're going to have 5.0 kernels soon(ish), wonder if there are any assumptions in the test suite that will break
<mvo> mborzecki: interessting and good point. I *hope* we don't have any but it will be an interessting test to run it on such a kernel
<mborzecki> mvo: are we doing 2.37 this week?
<mvo> mborzecki: that was my plan, yes
<zyga> good morning
<zyga> defer happyNewYear()
<zyga> -9 outside and not much warmer in the office, I've set up the heater and will work upstairs for some time
<mborzecki> zyga: hey
<mborzecki> zyga: i'm reading -13 outside here
<zyga> lovely :)
<zyga> I do envy you there, winter in the city is just smog and loads of salt to melt the ice
<zyga> this must have been the longest winter break at canonical ever
<zyga> I don't remember what I was doing before
<mvo> hey zyga! great to "see" you. good morning and happy 2019
<zyga> hey mvo :)
<zyga> hmm, launchpad is timing out for me (on writes)
<zyga> we seem to have a new wave of static analyzer failures
<zyga> the lot https://www.irccloud.com/pastebin/Z29lszu7/
<zyga> this breaks all Prs
<zyga> I'll jump into that to unbreak master
<mvo> zyga: nice, thank you
<pstolowski> morning everyone! happy new year!
<zyga> good morning
<zyga> happy new year indeed :)
<mvo> hey pstolowski good morning and happy new year!
<mborzecki> pstolowski: heya
<zyga> quick reboot for new kernel
<pedronis> happy new year!
<zyga> happy new year pedronis :)
<pedronis> hi
<jamesh> looks like staticcheck doesn't understand cgo (among other things)
<zyga> indeed
<zyga> I'm working through those
<pedronis> zyga: if it give us trouble is also ok to disable it until we actually switch to 1.9/1.10
<pedronis> (me is not a fan of tests that fail over an unchanged codebase)
<zyga> pedronis: I will disable some tests, fixing some others
<zyga> this did find a lot of dead code
<pedronis> zyga: I understand but removing dead code is not a high priority either
<pedronis> my point stand
<zyga> ack
<pstolowski> hey pedronis! happy new year!
<jamesh> could you build a particular release of staticcheck rather than whatever is latest?
<pedronis> jamesh: yea, that's my point about waiting to use something that has it included
<pedronis> pstolowski: hi
<mvo> hey pedronis - happy new year
<mvo> and hello sil2100 - happy new year to you as well :)
<mup> PR core18#110 opened: hooks: add support for `.test` files and add some initial tests <Created by mvo5> <https://github.com/snapcore/core18/pull/110>
<pedronis> mvo: hi, thanks
<zyga> mvo: some comments
<mvo> zyga: thank you! looks great
<mvo> zyga: core18#110 a bit of an RFC right now mostly for pedronis and sil2100 but I think the point that this tree needs more tests is very valid
<mup> PR core18#110: [RFC] hooks: add support for `.test` files and add some initial tests <Created by mvo5> <https://github.com/snapcore/core18/pull/110>
<sil2100> Happy new year everyone o/
<zyga> sil2100: indeed :) welcome back
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6328
<mup> PR #6328: run-checks: stop running HEAD of staticcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/6328>
<zyga> brb, coffee
<sil2100> mvo: thanks for the PRs, will try having a look once I'm done with my SRU shift :)
<mvo> sil2100: thank you!
<mup> PR snapd#6328 opened: run-checks: stop running HEAD of staticcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/6328>
<pedronis> zyga: thx
<zyga> and  back
<popey> mvo: https://snapcraft.io/core no longer shows distros or maps
<popey> is this intentional?
<popey> (i know that can be turned off now)
<jamesh> zyga: I filed https://github.com/dominikh/go-tools/issues/384 about the cgo issue with staticcheck
<zyga> jamesh: thank you! that's great
<zyga> I made a batch of removals to unused code where I feel comfortable saying it's meant to go
<jamesh> with a two line example program :-)
<zyga> but it can wait until master is green
<Chipaca> moin moin
<zyga> hello Chipaca :)
<pedronis> Chipaca: hi
<Chipaca> zyga: pedronis: how's things?
<mvo> popey: good morning! let me check but I did not turn this off
<popey> Interesting.
<mvo> hey Chipaca - good morning and happy new year
<ogra> you can turn it off ?
<popey> yes, it's optional now
<ogra> ah, interesting
<mvo> popey: hm, this is "funny". the boxes for "display public popularity" are checked
<popey> oooh, interesting
<mvo> popey: so I guess that is a bug that its not visible
<popey> this sounds like a bug :)
<mvo> popey: I can try to turn it on and off again (i.e. uncheck/check the boxes)
<popey> good idea
<ogra> and wiggle the cable too !
<mup> PR snapd#6329 opened: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<mvo> popey: done, does it change anything?
<ogra> zyga, whats the status of snaps on chromeos ? https://forum.snapcraft.io/t/tried-to-install-quelea-presentation-software-from-chrome-linux-beta/9247
<popey> no, i still don't see it
<mvo> :(
<zyga> ogra: I don't know anything about chromeos
 * ogra bets one of the numbers is just too big
<popey> mvo: would you mind filing a bug?
<mvo> popey: do you have an example of a snap that displays the map still?
<popey> mvo: spotify
<ogra> turning on firefox's debugger (shift ctrl c) shows a javascript type error
<ogra> (in the debugger tab when you reload the page)
 * Chipaca hugs git's diff-highlight
<zyga> mborzecki: some feedback on https://github.com/snapcore/snapd/pull/6329/files
<mborzecki> zyga: thanks
<mup> PR #6329: cmd/snap-confine, packaging: support SELinux <SELinux> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6329>
<zyga> public service announcement: master is broken until we land https://github.com/snapcore/snapd/pull/6328
<mup> PR #6328: run-checks: stop running HEAD of staticcheck <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6328>
<mup> PR core18#111 opened: [TEST] snapcraft.yaml: find and save snapcraftctl before unsetting PATH <Created by mvo5> <https://github.com/snapcore/core18/pull/111>
<mup> PR snapd#6328 closed: run-checks: stop running HEAD of staticcheck <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6328>
<Chipaca> zyga: it's not true that you can't override the .desktop files of snap apps ("by design" or otherwise); you just need to start with the right desktop files :-)
<zyga> Chipaca: well, we don't want that, by design, it may be technically possible but that's not the point :)
<Chipaca> zyga: I don't think it's true that we don't want that
<Chipaca> if users want to tune (or break) things, more power to them
<mborzecki> Chipaca: if you drop a desktop file with the same name uder ~/.local/share/applications gnome will use that right?
<Chipaca> mborzecki: I'm not sure if it's the file name, or whether there are more heuristics, but yeah
<mborzecki> X-GNOME-magical-key
<Chipaca> I do know that if you copy /var/lib/snapd/desktop/applications/foo_bar.desktop into XDG_DATA_DIR, it will override
<Chipaca> ${XDG_DATA_DIR}/applications/ bah
<zyga> Chipaca: I mean that we have explicitly designed things to be harder to attack by instructing the user to do something "innocent" looking, e.g. you cannot snap connect powerful interfaces without assertions. Editing desktop files, which allows trivial sandbox escape, feels like part of that choice
<mborzecki> Chipaca: mhm, so if one starts with a desktop file that snapd dropped under /var/lib they should be able to tweak it to their liking
<Chipaca> zyga: yes a user can shoot themselves in the foot with this
<Chipaca> mborzecki: exactly
<mborzecki> btw. i feel sorry for this guy, wonder if it's v4l broken in his case or skype just being skype
<Chipaca> skype is a classic snap still i think
<zyga> pstolowski: 6330 is +0, -445
<zyga> I didn't remove any unused hotplug stuff
<mup> PR snapd#6330 opened: many: remove unused interface code <Created by zyga> <https://github.com/snapcore/snapd/pull/6330>
<pstolowski> zyga: a lot of dead code, interesting. will take a look thx
<zyga> mvo: quick look on https://github.com/snapcore/snapd/pull/6318/files please
<mup> PR #6318: release-tools: display self-help <Created by zyga> <https://github.com/snapcore/snapd/pull/6318>
<zyga> brb
<popey> kk
<mvo> zyga: cool, thanks, looking
<mvo> popey: https://bugs.launchpad.net/snapstore/+bug/1810762
<popey> thanks
<mup> Bug #1810762: No worldmap on "core" snap <Snap Store:New> <https://launchpad.net/bugs/1810762>
<mvo> zyga: nice
<popey> mvo: sorry, i think that should be at https://github.com/canonical-websites/snapcraft.io/issues
<popey> (also, it doesn't even render the footer, which has the link to the bug tracker)
<mvo> popey: interessting
<popey> the site maintainers are on it, they'll comment, thanks
<mvo> popey: great, thank you
<mup> PR snapd#5982 closed: interfaces/many: use 'unsafe' with docker-support change_profile rules <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5982>
<Chipaca> hm, staticcheck seems to have gotten pickier over the break
<niemeyer> Good morning snapcrafters
<pedronis> Chipaca: yes
<pedronis> niemeyer: hi
<niemeyer> ... and welcome back
<mvo> hey niemeyer! good morning and happy new year
<zyga> hey niemeyer :)
<zyga> Chipaca: indeed
<zyga> Chipaca: it's disabled now
<Chipaca> zyga: is it? where?
<zyga> Chipaca: in master
<zyga> it landed a few hours ago
<Chipaca> ah, just missed it
<mvo> sil2100: (for later) I pushed core18#111 which should fix the missing snapcraftctl issue that caused travis builds to fail. would be nice to look at this too when you have time :)
<mup> PR core18#111: snapcraft.yaml: update PATH so that snapcraftctl is still found <Created by mvo5> <https://github.com/snapcore/core18/pull/111>
 * Chipaca goes for coffee
<mup> PR snapd#6330 closed: many: remove unused interface code <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6330>
<zyga> thanks!
<mvo> zyga: thank you, really nice PR
<mup> PR snapd#6243 closed: systemd: allow only a single daemon-reload at the same time <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6243>
<Chipaca> FWIW I now have access to a pure nvidia laptop running 18.04 ubuntu mate
<Son_Goku> mvo, I can feel it in my bones... 2019 is the year we'll get full SELinux based confinement/sandboxing :D
<zyga> Son_Goku: that's unlikely
<Son_Goku> you're a debbie downer
<Son_Goku> boo
<mup> PR snapd#6323 closed: snap: give Epoch an Equal method <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6323>
 * Chipaca ~> lunch, probably
<mborzecki> off to pick up the kids
<mvo> Son_Goku: heh - happy new year!
<mup> PR snapd#6331 opened: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6331>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
 * zyga -> afk for walking the dog
<pedronis> mvo: when do we plan to branch 2.37 ?
<mup> PR snapd#6025 closed: Add go.mod files <â Blocked> <Created by ryanjyoder> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6025>
<pedronis> Chipaca: do we have a bug where we don't consider stable and latest/stable the same (atm)?  https://forum.snapcraft.io/t/channel-latest-stable-for-core-is-closed-temporarily-forwarding-to-stable/9169
<mborzecki> zyga: think we can reenable fedora-29 ?
<Chipaca> pedronis: i don't think we have a bug #
<Chipaca> pedronis: AFAIK the bug is only in snap, not in snapd, fwiw
<mvo> pedronis: early this week, ideally today but I think there is still stuff tagged 2.37 that is not merged
 * cachio lunch
<mup> PR snapd#6332 opened: spread: make Fedora 29 auto again <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6332>
<zyga> re
<zyga> sorry, the walk turned out to be walk + cooking for kids
<zyga> mborzecki: if the underlaying issue was resolved, sure why not
<mup> PR core18#111 closed: snapcraft.yaml: update PATH so that snapcraftctl is found <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/111>
<kyrofa> Hey ogra, do we have an up-to-date Ubuntu Core porting guide that you know of?
<mup> PR snapcraft#2430 closed: extractors: better appstream support for descriptions <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2430>
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5845, snapd#5887, snapd#5915, snapd#5962, snapd#6016, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6113, snapd#6121, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6280, snapd#6281,
<mup> snapd#6286, snapd#6294, snapd#6313, snapd#6317, snapd#6318, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6326, snapd#6327, snapd#6329, snapd#6331, snapd#6332
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5845, snapd#5887, snapd#5915, snapd#5962, snapd#6016, snapd#6034, snapd#6079, snapd#6098, snapd#6106, snapd#6108, snapd#6111, snapd#6113, snapd#6121, snapd#6162, snapd#6177, snapd#6238, snapd#6252, snapd#6258, snapd#6270, snapd#6280, snapd#6281,
<mup> snapd#6286, snapd#6294, snapd#6313, snapd#6317, snapd#6318, snapd#6320, snapd#6322, snapd#6324, snapd#6325, snapd#6326, snapd#6327, snapd#6329, snapd#6331, snapd#6332
<zyga> re :)
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<mup> Bug #1810858 opened: Default Snapd installation with SELinux causes AVC failures <Snappy:New> <https://launchpad.net/bugs/1810858>
#snappy 2019-01-08
<mborzecki> morning
<zyga> good morning
<Faults> Goood morning!
 * zyga got a power plug adapter for south africa
<mup> PR snapd#5845 closed: interface: add new `{personal,system}-files`  interface <Reviewed> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5845>
<pstolowski|afk> mornings
<mborzecki> zyga: pstolowski: hey
<t1mp> hello
<t1mp> is this the place for questions relating to snap packaging problems?
<zyga> t1mp: hey, for various kinds of topics related to snaps
<t1mp> I created a snap package, which has a python+qt app inside (using PySide2, and PyInstaller). It works on most systems, but when the host is running Wayland, it fails as follows:
<t1mp> https://pastebin.ubuntu.com/p/whWXk2drjW/
<t1mp> greyback is already helping me with it :)
<t1mp> for reference, my snapcraft.yaml is here: https://pastebin.ubuntu.com/p/KN9qsVRdJ8/
<Chipaca> morning all
<popey> Good day
<popey> t1mp: hey! don't you also need the 'wayland' plug?
<popey> I have seen some options where you use x11 and wayland plug but disable wayland in the environment which triggers it to use xwayland
<t1mp> popey: hello :)
<t1mp> I have no idea. Is there documentation about the wayland plug somewhere?
<t1mp> I thought all was working, but now when testing on different systems I found that the snap doesn't work on systems with wayland.
<mup> PR snapd#5915 closed: interfaces/network-setup-control: allow calling netplan generate/apply <Created by ogra1> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5915>
<popey> https://forum.snapcraft.io/t/wayland-crash-with-electron-2/5752/4?u=popey
<popey> t1mp: theres a similar thread, where they use DISABLE_WAYLAND=1 in the environment to force xwayland
<popey> (I *think* that's how it works)
<popey> The documentation for the wayland interface is somewhat lean https://docs.snapcraft.io/the-wayland-interface/7784
<popey> https://github.com/notepadqq/notepadqq/blob/master/snap/snapcraft.yaml#L16
<popey> someone else using that method
<t1mp> shouldn't those kind of things be included in the desktop-helpers?
<t1mp> I could try the DISABLE_WAYLAND env var
<popey> possibly
<t1mp> plugs are irrelevant as long as I'm using --devmode right?
<popey> yes
<popey> (I think)
<popey> you can use "snappy-debug.security scanlog" to learn what's failing apparmor
<popey> leave that running in another terminal when you run the app
<popey> might be enlightening
<zyga> brb
<t1mp> greyback: interesting, if I run the app (packaged with PyInstaller), but outside of the snap, it works fine. But if I set QT_QPA_PLATFORM=wayland, then it starts but without window decoration or images in the app.
<mup> Issue core18#93 closed: i386 support missing on core18-amd64 <Created by mmtrt> <Closed by sil2100> <https://github.com/snapcore/core18/issue/93>
<t1mp> The missing images looks familiar. I think I had the same on X when I missed some files to have GLSL support
<zyga> quick coffee to raise the pressure
<zyga> it's so sleepy today
<mup> PR snapd#6333 opened: daemon: intrduce /v2/connections snapd API endpoint <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
<t1mp> greyback, popey: https://github.com/notepadqq/notepadqq/blob/master/snap/snapcraft.yaml#L16 made the snap work for me
<t1mp> I don't know if it is the most elegant solution, but the package works now, which is what I need
<t1mp> thanks for the help :)
<t1mp> I still need to test it on some PCs though
<greyback> t1mp: ok, glad you got it working
<greyback> it appears wayland support still needs work in desktop-helpers
<popey> (bug reports welcome) :D
<diddledan> bug reports? https://www.youtube.com/watch?v=S-s4lEk91ng
<zyga> brb again
<popey> diddledan: I'm doing my part!
<pstolowski> mborzecki: hey, #6332 can land right?
<mup> PR #6332: spread: make Fedora 29 auto again <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6332>
<mborzecki> pstolowski: let me run the spread job again, sample of 2 is better than 1 ;)
<mup> PR snapd#6318 closed: release-tools: display self-help <Simple ð> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6318>
<pstolowski> ok
<zyga> thanks pawel!
<zyga> running some spread tests, I will go for a walk with the dog
<zyga> it's snowing like crazy here
<zyga> I don't want to miss this ;0
<zyga> :-)
<MattJ> Where is $here? I want to come!
<MattJ> (wait, that sounded creepy)
<zyga> it's all bound to melt away, it will be +2 soon
<zyga> but for now it's close to -1 so the view is very nice
<zyga> (in Warsaw)
<pedronis> mborzecki: hi, are you mostly blocked waiting on various reviews at this point?
<mborzecki> pedronis: i'm advancing respective pieces in private branches and working on a small fontconfig fix for fedora, but yeah, opening new PR is blocked until some of the current ones land
<pedronis> mborzecki: ok, I will get to your PRs but there are even older PRs that needs some attention too, I can point at some of the "small" cards I mentioned yesterday in the standup
<mup> PR snapd#6334 opened: dirs, interfaces/builtin/desktop: system fontconfig cache path is different on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6334>
<mborzecki> ^^ maybe a bit late for .37 but we could squeeze it in .37.1
<mup> PR snapd#6332 closed: spread: make Fedora 29 auto again <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6332>
<mborzecki> off to pick up the kids
<t1mp> greyback: yeah. Is any OpenGL stuff not working with Wayland now? That seems quite important ;)
<t1mp> or is it just Qt? Or something specific that I'm using
<greyback> t1mp: it has worked for me in the past. I don't know what broke for you, sorry
 * Chipaca â lunch
<zyga> re
<zyga> t1mp: it probably depends
<t1mp> okay, thanks. :) For me it just matters that it works for my snap now ;) I'm sure the snap is optimal, but I'll see if I can work on it again in the near future.
<t1mp> *I'm sure my snap is NOT optimal :)
<pedronis> Chipaca: hi, could you review #6121 when you have a bit of time?
<mup> PR #6121: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6121>
<Chipaca> pedronis: yes
<Chipaca> I guess the current test that creates snapshots for root + testuser isn't enough?
<pedronis> Chipaca: I suppose, it's  question for cachio
<pedronis> mborzecki: btw, did you see the request for tweaks to #6317 ?
<mup> PR #6317: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6317>
<mborzecki> pedronis: yup, saw that, it's in my queue
<pedronis> ok
<mup> Bug #1810948 opened: Internal Watcher Error <Snappy:New> <https://launchpad.net/bugs/1810948>
<mup> Bug #1810948 changed: Internal Watcher Error <Snappy:Invalid> <https://launchpad.net/bugs/1810948>
<cachio> zyga, https://travis-ci.org/snapcore/spread-cron/builds/476263240#L9952
<zyga> looking
<cachio> that should be fixed with the update in the repo?
<zyga> so
<zyga> you need to update & reboot
<zyga> let me check that locally
<cachio> zyga, I did that
<zyga> in that case the fix is not out yet
<zyga> let's wait and see, I'll check the bug report in suse
<zyga> thanks for trying!
<cachio> np
 * cachio lunch
<pedronis> jdstrand: thanks for adding the docs about personal/system-files, shouldn't the doc mention somehow that even just installation requires the snap-declaration ?
<pedronis> (Not sure how we did this for other interfaces with the same requirement)
<mborzecki> feels like we should parse /etc/fonts/fonts.conf to figure out fontconfig locations rather than use hardcoded ones
<mborzecki> fedora/rhel/centos all use /usr/lib/fontconfig/cache, but amzn2 is behind with updates and uses /var/cache/fontconfig and obviously has ID_LIKE=".. fedora.."
<zyga> mborzecki: how hard is it to parse?
<mborzecki> zyga: rather easy, it's xml, encoding/xml should do just fine
<zyga> oh, that's good
<zyga> is the location easy to extract?
<mborzecki> zyga: yes, it's quite trivial :)
<mborzecki> zyga: btw. wonder if we shuld also use ~/.local/share/fonts and ~/.fonts, we're only using system locations now
<zyga> it depends if the code runs in user contetxt
<mborzecki> zyga: we setup those mounts in the desktop interface, i'd guess it does
<zyga> but who would run the parser?
<mborzecki> zyga: snapd could parse /etc/fonts/fonts.conf in destkop iface mount connected plug
<jdstrand> pedronis: probably, yes. we don't do that elsewhere that I can see but that is no reason not to do it here
<jdstrand> pedronis: I'll adjust
<zyga> mborzecki: can we discuss this tomorrow morning?
<zyga> I'm adding some tests still
<jdstrand> pedronis: done. fyi, I also updated snapd-control and kernel-module-control similarly. maybe that will reduce some questions
<pedronis> jdstrand: thanks
<pedronis> pstolowski: I left a comment in the hotplug-connect PR, we can talk about it tomorrow
<pstolowski> pedronis: ok, thanks
<mborzecki> zyga: sure
<t1mp> kenvandine: hello :)
<t1mp> I just saw your comment on https://github.com/ubuntu/snapcraft-desktop-helpers/issues/172
<kenvandine> hey t1mp
<t1mp> the way I understand it, plugs don't make a difference if the snap runs with --devmode (or as classic). Is that correct?
<kenvandine> oh
<kenvandine> right
<t1mp> hmm. I'm rebuilding my snap and (automatically, with jenkins) pushing it to the snap store, but I keep getting a 502 error
<t1mp> Snap Store encountered an error while processing your request: bad gateway (code 502).
<t1mp> The operational status of the Snap Store can be checked at https://status.snapcraft.io/
<t1mp> script returned exit code 2
<t1mp> I can see the revision though when I log in on snapcraft.io
<t1mp> ah no, I cannot. It is a different revision number
<t1mp> (just two digits swapped that's why I thought it is the same)
<kenvandine> t1mp: try added QT_QPA_PLATFORM=wayland
<kenvandine> i haven't  trying anything qt/qml with wayland myself
<t1mp> kenvandine: I tried that. Still gives the same error.
<t1mp> I will add a comment to the issue
<kenvandine> greyback: ^^ do you have any ideas?
<kenvandine> greyback: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/172#issuecomment-452388662
<t1mp> greyback: was already helping me with it :) So he is aware. For me the problem is solved with the DISABLE_WAYLAND: 1.
<t1mp> That's enough for me, I have a working snap. But I guess it is still a workaround.
<kenvandine> that's not a solution though :)
<kenvandine> that makes it fall back to XWayland
<t1mp> true
<t1mp> but I need to release my snap this week :)
<kenvandine> yeah... so probably good enough :)
<kyrofa> Hey pedronis, you still around?
<greyback> kenvandine: hey, yes I looked into it. I noticed the glvnd config was missing - $SNAP/usr/share/glvdn/egl_vendor.d/50_mesa.json - (stracing the binary, it was not opening any DRI drivers). When I hacked that file into the snap, the app worked for me on my wayland. So I recommended adding "libegl0-mesa0" to the stage packages, but that didn't help t1mp
<kenvandine> hmm
<greyback> kenvandine: I didn't try further tbh
<kenvandine> understand
<popey> cjwatson: do we have an eta for core18 builds in LP via build.snapcraft.io ?
<cjwatson> popey: not yet
<diddledan> is that the eta is "not yet" or the eta on the eta is "not yet"?
<diddledan> kenvandine: I've done a lot of work yesterday and today on the gnome-extension POC that I created: https://github.com/snapcore/snapcraft/pull/2398
<mup> PR snapcraft#2398: gnome extension <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2398>
<mup> PR snapd#6335 opened: NOT-REVIEW: tests: fix "No space left on device" issue on amazon-linux <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6335>
<kenvandine> diddledan: I noticed!
<diddledan> it finally works
<kenvandine> oSoMoN and I will look at it tomorrow
<diddledan> :-p
<kenvandine> Woot
<diddledan> I've done a test build locally with my gnome-twitch snap which successfully built the snap and when installed it runs correctly
<kenvandine> Excellent
<diddledan> including libwebkitgtk!
<diddledan> (I put a layout definition to fix that)
<kenvandine> diddledan: thanks for that
<diddledan> it also uses the gnome-3.xx-1x04 platforms
<diddledan> I couldn't publish my test build of gnome-twitch to the store, though, because it rejected the `command-chain:` block because it doesn't believe such a config exists :-)
<cjwatson> diddledan: yes
<diddledan> :-)
#snappy 2019-01-09
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey
<zyga> good morning :)
<zyga> I'm staying away from the office till spring
<liuxg1> hi, did anyone make the bluetooth working on ubuntu core, raspberry pi3b+ board? I have a problem in getting it working
<zyga> I have that board but I've never tried using BT yet
<liuxg1> zyga, thanks for your reply. https://bugs.launchpad.net/snappy/+bug/1674509 this seems the bug. I tried to power on it, however, after reboot, the setting is going.
<mup> Bug #1674509: Unable to find bluetooth device on RPi3 running Ubuntu Core 16 <snapd-interface> <Snappy:Confirmed> <linux-raspi2 (Ubuntu):Invalid by p-pisati> <https://launchpad.net/bugs/1674509>
<zyga> seems like that bug is well under way
<liuxg1> I used the steps described in the link https://docs.ubuntu.com/core/en/stacks/bluetooth/bluez/docs/reference/pairing/introduction. I used to connect it with bluetooth long long time ago. I do not know why it was broken.
<mborzecki> maybe something bluez related
<liuxg1> zyga, are you able to pair a bluetooth device using your device? yes, it is related to the bluez.
<zyga> as I said I have never tried
<zyga> the device is on a shelf now, I'm powering them down to avoid cable mess and power drain when unused
<mborzecki> liuxg1: can you run bluetootctl devices? is the paired device listed there?
<liuxg1> I see. when you are free, would you please have a try if it is OK with you. I need to use the bluetooth to connect a device. thanks
<liuxg1> mborzecki, there is nothing there.
<mborzecki> liuxg1: and bluetootctl list?
<liuxg1> I have to run this command: sudo /snap/bin/hciattach /dev/ttyAMA0 bcm43xx 921600 noflow - to see something there.
<liuxg1> otherwise, there is no controller for it.
<liuxg1> also, it seems that I have to install the bluez in --devmode to get it working.
<mborzecki> intersting, looking at some rspi3 block diagrams, bt contoller is indeed wired over uart
<mborzecki> liuxg1: anything related to apparmor in dmesg?
<pstolowski> mornings
<mborzecki> pstolowski: hey, while you're here got some questions about pre and post refresh hooks, figured you might know :)
<mborzecki> pstolowski: pre refresh runs before the previous revision has been disabled, so the services will be up at this point?
<liuxg1> mborzecki, these are the errors I got from dmesg. I am not sure whether they are related.  https://paste.ubuntu.com/p/kXhssPJnSH/
<pstolowski> mborzecki: yes, pre-refresh runs before stopping the services; stop-snap-services is next
<mborzecki> pstolowski: great, then post-refresh is run before the services are started, so I could snapctl stop --disable a service inside?
<pstolowski> mborzecki: yes you could. we don't have spread tests for something like this though..
<mborzecki> pstolowski: i'm asking bc ijohnson had some issues with services getting enabled after a snap refresh, and I suggested using {pre,post}-refresh hooks to grab the current state and restore it
<mborzecki> pstolowski: relevant post: https://forum.snapcraft.io/t/how-to-manage-services-with-sockets-timers/7904/3
<mborzecki> pstolowski: i think snapd cannot second guess whether a service name is true across revisions of a snap, so it falls down to snap creator to figure this out
<pstolowski> mborzecki: i'll take a look at this in a bit and get back to you, need to prepare for the meeting i've soon
<mborzecki> pstolowski: thanks
<zyga> hey pawel
<mborzecki> zyga: fontconfig fonts.conf parser https://paste.ubuntu.com/p/2KJDd6xdff/
<mup> Bug #1811063 opened: "snap refresh" does not report failure to update because snap switched to classic confinement <Snappy:New> <https://launchpad.net/bugs/1811063>
<mborzecki> zyga: wrote a little tool to dump my local config, no more guessing: dirs: &{SystemFonts:[/usr/share/fonts /usr/local/share/fonts] SystemCache:[/var/cache/fontconfig] UserFonts:[$XDG_USER_DATA_DIR/fonts $HOME/.fonts] UserCache:[$XDG_USER_DATA_DIR/fontconfig $HOME/.fontconfig]}
<mup> Bug #1811063 changed: "snap refresh" does not report failure to update because snap switched to classic confinement <snapd:New> <Snappy:Invalid> <https://launchpad.net/bugs/1811063>
<mup> PR snapd#6336 opened: snap-confine: fix incorrect use "src" var in mount-support.c <Created by mvo5> <https://github.com/snapcore/snapd/pull/6336>
<pedronis> mvo: hi, I commented on #6331
<mup> PR #6331: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6331>
<mvo> pedronis: excellent, thank you!
<Chipaca> o/
<pedronis> Chipaca: hi
<Chipaca> pedronis: 'sup
<mvo> Chipaca: good morning!
<pstolowski> pedronis: 1 sec, i'm coming, have little touble with google meet
<mvo> Chipaca: oh is the released-at stuff coming along :) ?
<Chipaca> mvo: good morning boss
<Chipaca> :-)
<mvo> Chipaca: *cough* I need to think about the right kind of title - maybe MASTER is appropriate?
<pedronis> pstolowski: I added a meet to the event btw
<mvo> Chipaca: I guess we need to discuss while having a beer in malta ;)
<Chipaca> mvo: https://i.imgur.com/x846GwL.png
<Chipaca> pedronis: also ^
<Chipaca> that's me playing with some other stuff as well
<mvo> Chipaca: \o/ so cool
<Chipaca> because in the sample output  requesting this data, there's no up arrows
<Chipaca> it's all compacted
<pedronis> Chipaca: anyway I still have the feeling that we maybe should go with just the iso dates for this
<Chipaca> but i don't know if that was just for didactic reasons or not
<Chipaca> pedronis: yeah, i think so
<Chipaca> pedronis: and use the human date or full iso date in verbose
<mvo> pedronis: thanks for the review on the systemd workaround - I will expand the unit tests, sorry I should have mentioned this in the PR actually. I wanted to make sure we are happy with the general approach before spending too much time on this. I will do so today
<zyga> mborzecki: nice
<Chipaca> pedronis: there's a problem with released-at currently in the store, where it's not the right format
<Chipaca> pedronis: easy to work around, but the fix is on master of the store already
<Chipaca> pedronis: dunno if i should propose without the workaround and mark blocked, or not
<mvo> Chipaca: when will the store release the fix? like roughly?
<Chipaca> mvo: A fair question and one that in recent [days] 'as been much on my mind.
<Chipaca> mvo: yesterday somebody was off sick, so it didn't happen
<mvo> Chipaca: aha, but that sounds like "really-soon" (i.e. days not weeks?)
<Chipaca> yeah
<mvo> cool
<Chipaca> yeah
<Chipaca> right now I have the workaround because I like poking at things, but I think I'll drop it before proposing the PR
<mborzecki> zyga: want to chat quickly about the fontconfig thing?
<zyga> sure
<zyga> here or HO?
<mvo> Chipaca: we want this for 2.37 so if the store does not release the fix by tomorrow I think we should add the workaround. or 2.37 will be late for CPT :/
<mborzecki> zyga: https://meet.google.com/koc-gdjf-qve
<mvo> Chipaca: or we just drop it from 2.37 :)
<mvo> Chipaca: but I really like the feature so that would be a bit sad
<Chipaca> mvo: I'd rather add the workaround than have the feature slip
<mvo> Chipaca: *nod*
<mborzecki> zyga: let's try again https://meet.google.com/dwz-hyza-nwc?authuser=1
<Chipaca> pedronis: mvo: https://forum.snapcraft.io/t/upcoming-change-to-the-output-of-snap-info/9368 fwiw
<Chipaca> pedronis: mvo: or should I say https://forum.snapcraft.io/t/upcoming-change-to-the-output-of-snap-info/9368?u=chipaca
 * Chipaca hoards the fake internet points
<pedronis> Chipaca: was in a meeting with pawel
<Chipaca> pedronis: poor pawel
 * Chipaca hides
<pedronis> Chipaca: heh
<pedronis> Chipaca: I think we want the workaround, we can backport dropping it if that makes sense
<Chipaca> I'm told the fix will land before EOD today
<Chipaca> s/will/should/
<pedronis> Chipaca: ok
<Chipaca> but as i say, the workaround exists already :-)
<Chipaca> anyway, fixing the tests and should have it up before standup
<pedronis> yea
<pedronis> Chipaca: do you have a PR for the other change?  (unicode off if no tty)
<Chipaca> pedronis: not yet, do you want that one first?
<pedronis> Chipaca: not first, but would like them to go out together somehow
<pedronis> (disrupt things in one go)
<Chipaca> :-)
<Chipaca> I could stack 'em
<Chipaca> but reviewers hate that :-)
<mvo> Chipaca: \o/
<Chipaca> mvo: does a 2.37 branch exist already?
<mvo> Chipaca: not yet, will be created today
<Chipaca> 'cause if so i could get the individual things on master, and stack them for 2.37
<mvo> Chipaca: if all goes well :)
<Chipaca> there's also the alignment change
<Chipaca> bah
<Chipaca> I could do this: add released-at in one pr, but use it in the same pr as the other two
<Chipaca> seems messy conceptually tho
<pedronis> does this rings any bells https://forum.snapcraft.io/t/installation-fails-as-core-snap-not-found/9367/3 ?
<pedronis> mvo: do snaps that require core18 actually also need core ? but we install only the former automatically
<pstolowski> mborzecki: re "i think snapd cannot second guess whether a service name is true across revisions of a snap, so it falls down to snap creator to figure this out": we know the service names of the old revsion, and services of the new revision, no?
<mborzecki> pstolowski: we know the names, but we don't know whether A rev 1 is the same as A rev 2
<mborzecki> pstolowski: all we know is that the names are the same
<mvo> pedronis: snaps that require core18 do not need core, there was a bug a while ago though where it was confused about this but we fixed that, let me look at the git history
<mborzecki> pstolowski: that's why i think just looking at name is fragile
<pedronis> mvo: that bug is probably still in 18.04 I suppose because no SRU yet?
<mvo> pedronis: that is possible, is this about the forum post you mentioned earlier?
<pedronis> mvo: no, see PM but maybe also
<pedronis> mvo: where do we mount snapctl from for those?  the host until there is a core snap available?
<Chipaca> pedronis: fwiw, it's snap-confine
<mvo> pedronis: aha, yes, I think this is the SRU :/
<Chipaca> in 2.34.2
<pstolowski> mborzecki: ah, because it's about knowing what to keep enabled/disabled?
<mborzecki> pstolowski: yup
<pedronis> Chipaca: yes, that's why me asking these questions
<mvo> pedronis: yeah, the host (95% certain)
<pedronis> Chipaca: does juju-db has base: core18 ?  or is there something else going on in the forum case
<pedronis> I could check myself, but need to go have lunch
<Chipaca> pedronis: I mean, the forum says it's core18
<pedronis> ah
<pedronis> yes
<Chipaca> pedronis: and the snap does say base:core18
<pedronis> yea, ok
<pedronis> so it's fixed bug
<pedronis> but no SRU
<Chipaca> if they installed the core snap, they'd re-exec, and get the fix
<mvo> yeah, I need to chase the SRU, let me do that now
<pedronis> (also this will be saner when we have snapd snap on classic but also means more work)
<pstolowski> mborzecki: i see, right. i agree with your assesment and the idea of using post-refresh hook
<zyga> re
<mup> PR snapd#6337 opened: store, snap, cmd/snap: channels have released-at <Created by chipaca> <https://github.com/snapcore/snapd/pull/6337>
<Chipaca> pedronis, mvo: ^
<mvo> Chipaca: cool!
<Chipaca> whoops, forgot to undo a for-testing change i'd made
 * Chipaca pushes
<mup> PR snapd#6286 closed: release: support probing SELinux state <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6286>
<mup> PR snapd#6338 opened: cmd/snap: right-align revision and size in info's channel map <Created by chipaca> <https://github.com/snapcore/snapd/pull/6338>
<pedronis> Chipaca: I moved the card about this to doing
<Chipaca> pedronis: thank you
<Chipaca> sergiusens: does snapcraft have a homebrew plugin? 1.9.0 supports Linux, and it's been out for _hours_ already!
<sergiusens> Chipaca: a homebrew plugin to build from brews and make them snaps?
<Chipaca> sergiusens: clearly
<sergiusens> meta meta meta
<Chipaca> :-)
<sergiusens> I guess with overlays it could work
<sergiusens> probably worth looking into when more man power becomes available ð
<Chipaca> also 1.9.0 drops support for intel 32 bits
<mup> PR snapd#6336 closed: snap-confine: fix incorrect use "src" var in mount-support.c <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6336>
<Chipaca> dunno if that affects zyga's lab
<zyga> Chipaca: not much
<zyga> Chipaca: you mean go 1.9 is x86_64 only?
<zyga> Chipaca: I have one 32bit (strict) machine left
<zyga> as in i386
<Chipaca> zyga: "Homebrew 1.9.0 no longer runs on 32-bit Intel CPUs."
<zyga> ah
<zyga> nah that's ok
<zyga> that entry point is not using macos :)
<Chipaca> from https://brew.sh/2019/01/09/homebrew-1.9.0/
<zyga> there are no 32bit only macs left really
<zyga> even the watch is 64 bit
<Chipaca> it isn't 4 bits emulating 8?
<zyga> :D ?
<zyga> quick coffee break
<zyga> btw, working from the kitchen has one clear advantage :)
<Chipaca> nice tweak to travis' ui there
<Chipaca> zyga: just keep your jitters under half of your keycap size and you'll be fine
<mup> PR snapd#6339 opened: cmd/snap: don't auto-enable unicode to a tty <Created by chipaca> <https://github.com/snapcore/snapd/pull/6339>
<Chipaca> mvo: three PRs up, that should be it for 2.37 from me :-)
<pedronis> Chipaca: you mean non-tty there?
<Chipaca> gah
 * Chipaca checks
<Chipaca> gahÂ²
<Chipaca> I had it right the first time :-)
<Chipaca> and â¦ "fixed" it
<Chipaca> pedronis: where it says don't, read only
<Chipaca> :-)
<Chipaca> i'll fix it right back
<mborzecki> off to pick up the kids
<cachio> niemeyer, hello, a new change pushed for the spread reboot PR
<cachio> pstolowski|lunch, hey, if you have time could you please take a look to #5887 ?
<mup> PR #5887: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
<mup> PR snapd#6337 closed: store, snap, cmd/snap: channels have released-at <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6337>
<niemeyer> cachio: Thanks!
<pedronis> Chipaca: the description seems also wrong
<pedronis> I mean the PR description
<Chipaca> pedronis: yes
<Chipaca> https://www.dell.com/en-uk/work/shop/cty/pdp/spd/precision-17-7720-laptop/xctop7720emea
<Chipaca> guess what laptop won't be my next laptop
<zyga> ouch
<zyga> Starting at Â£7,001,726.28
<zyga> Chipaca: but hey, it's a "bargin"
<zyga> Original Price
<zyga> Â£10,002,466.11
<ogra> oh, is dell already establishing the post-brexit pricing ?
<mborzecki> Intel Core i5-6300HQ with Thunderbolt 3 is super expensive
<mborzecki> must be that thunderbolt 3
<ogra> "delivery by row-boat to the continent ..."
<ogra> .. "included"
<Chipaca> mborzecki: the HQ stands for high quality, it's the audiophile edition
<mborzecki> intelophile
<zyga> mborzecki: wait, is that really i5-6300HQ? :)
<zyga> oh my
<zyga> that's garbage :D
<zyga> (for that price)
<pedronis> Chipaca: could you push master into those PRs to reduce the diff?
<Chipaca> pedronis: I could, but that'd kick off another travis run :-)
<Chipaca> pedronis: should I?
<pedronis> not immediately
<Chipaca> pedronis: it's two commits, one of which is on master :-)
<mborzecki> zyga: standup
<zyga> joining!
 * pedronis break
 * zyga goes for lunch
<pedronis> mvo: can we answer something here https://forum.snapcraft.io/t/installation-fails-as-core-snap-not-found/9367/3 ?
<mup> PR snapd#6340 opened: store: undo workaround for timezone-less released-at <Created by chipaca> <https://github.com/snapcore/snapd/pull/6340>
<mvo> pedronis: yes
<Chipaca> SIGH
 * Chipaca fixes things
<zyga> Chipaca: found something fun?
<Chipaca> spread tests looking for unicode output in things that no longer produce unicode output :-)
<Chipaca> fun level 3.72
<zyga> quick coffee
 * genii 's ears perk up momentarily at the mention of coffee
<zyga> the coffee machine is warming up
<pedronis> Chipaca: reviewed #6338
<mup> PR #6338: cmd/snap: right-align revision and size in info's channel map <Created by chipaca> <https://github.com/snapcore/snapd/pull/6338>
<Chipaca> pedronis: thanks
<Chipaca> pedronis: info is a lovely mess
<Chipaca> pedronis: I'll see if I can't clean it up a bit after epochs
<Chipaca> meanwhile, probably not worth it for this change
<pedronis> Chipaca: as I said, mostly wondering, because of the passing things in and out, and also formatting concerns are all a bit mixed up now
 * cachio lunch
<pedronis> mvo: will you write there?  you are probably the most familiar with the state, also afaik you did the fix :)
<mvo> pedronis: yes, I will write in the forum, sorry for hte delay, just finished the unit tests for protocol-error PR (6331)
<mvo> pedronis: feedback welcome (as always :)
 * mvo goes and writes about " Installation fails as âcore snapâ not found "
 * zyga goes to read that 
<zyga> namespaces and more namespaces
<pedronis> mvo: thank you
<pedronis> mvo: need to go for a walk, but will do more 2.37 reviews afterward
<mvo> pedronis: \o/
<mvo> pedronis: I will also make a cup of tea and look at the next steps
<pedronis> jdstrand: hi, I finally got to look and comment on #5644 ,there are some questions there
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<pedronis> jdstrand: also, could you look at #6334 ?
<mup> PR #6334: dirs, interfaces/builtin/desktop: system fontconfig cache path is different on Fedora <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6334>
<jdstrand> pedronis: yes, I saw the emails for both
<zyga> brb
<zyga> back to work :)
<zyga> tests looking good, writing some commit message for the PR
<zyga> some spread IO issues
<zyga> but restarted now
 * mvo hugs pedronis for his tireless reviews
<pedronis> I think I looked at most 2.37 things, they need 2nd reviews and/or passing tests
<mup> PR snapd#6340 closed: store: undo workaround for timezone-less released-at <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6340>
<mup> PR snapd#6341 opened: cmd/snap-update-ns: persist per-user mount namespace profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6341>
 * zyga EODs
<mup> PR snapcraft#2431 closed: rust plugin: update to use latest rustup command options <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2431>
<mup> PR snapcraft#2434 opened: rust plugin: refactor to use the latest rustup <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2434>
#snappy 2019-01-10
<mborzecki> morning
<mborzecki> mvo: hi, pushed a small shellcheck fix to #6331 hope you don't mind
<mup> PR #6331: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6331>
<mvo> mborzecki: thanks for this!
<mvo> mborzecki: nice fix
<mborzecki> mvo: shoould have gotten it right when i suggested the change :/
<mvo> mborzecki: no worries
<mup> PR snapd#6335 closed: tests: fix "No space left on device" issue on amazon-linux <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6335>
<mborzecki> great start of the year: http://seclists.org/oss-sec/2019/q1/54
<zyga> Hello
<mborzecki> zyga: hey
<mup> PR snapd#6334 closed: dirs, interfaces/builtin/desktop: system fontconfig cache path is different on Fedora <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6334>
<mup> PR snapd#6342 opened: use major() and minor() in <sys/sysmacros.h> instead of MAJOR and MINORâ¦ <Created by timchen119> <https://github.com/snapcore/snapd/pull/6342>
<pstolowski> morning
<zyga> Hey hey
<zyga> Iâll be around shortly, just finishing coffee
<mup> PR snapd#6338 closed: cmd/snap: right-align revision and size in info's channel map <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6338>
<zyga> interesting thing with major/minor
<zyga> mvo: the approval email arrived now (both of them :)
<mvo> zyga: oh, let me see
<mvo> zyga: got them now
<zyga> thank you!
<mvo> zyga: I approved the first one and will reject the other two
<zyga> thank you
<zyga> brb
<pedronis> mvo: hi, anything blocking #6331 ?
<mup> PR #6331: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <https://github.com/snapcore/snapd/pull/6331>
<mvo> pedronis: not really, was just running some tests to see what a sensible number of runs is to trigger the bug (when I revert the fix). but thats not blocking it
<mup> PR snapd#6331 closed: systemd: allow only a single daemon-reload at the same time <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6331>
<mup> PR snapd#6339 closed: cmd/snap: only auto-enable unicode to a tty <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6339>
<pedronis> mvo: I was interested in the answer about test for 6339, I don't see John around yet tough
<pedronis> is he off?
<mvo> pedronis: probably just starting a bit later, I don't think he is off
<mvo> pedronis: I would also really like to poke a bit at the displayChannel revLen, sizeLen thing to see if there is a nice way to disentangle this a little bit
<pedronis> mvo: heh
<pedronis> mvo: doesn't sound like a task you should take on :) but you are the boss
<mvo> pedronis: I know! OCD I guess
<mvo> pedronis: I will need to learn a lot :)
<mup> PR snapd#6343 opened: overlord/configstate/configcore: support - and _ in cloud init field names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6343>
<mvo> mborzecki: nice one - is this something we need for 2.37 ?
<mborzecki> pedronis: how urgent is this change? ^^
<mvo> mborzecki: I think I missed the background for this one (sorry!) - where does the original report come from?
<mup> PR snapd#6344 opened: cmd/snap-confine: join freezer only after setting up user mount <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6344>
<pedronis> mvo: it's from a mail thread
<mborzecki> mvo: not sure there is one, there's a trello card though :)
<mborzecki> mvo: ah, there you go
<mvo> pedronis, mborzecki thanks!
<pedronis> mvo: I can forward you the thread
<mvo> pedronis: how urgent? it looks like a nice drive-by for 2.37
<mvo> pedronis: I'm inclined to take it if we get reviews in time (happy to do one now)
<pedronis> mvo: about 6339, we lost tests indeed (at least afaict playing locally)
<mvo> pedronis: meh, thats a bit sad
<mvo> pedronis: so we need a followup
<mup> PR snapd#6345 opened: cmd/libsnap: pass --from-snap-confine when callingsnap-update-ns as user <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6345>
<pedronis> mvo: is not urgent in the same that I don't think they can drop '-' for a long while,  it would be good to have it in 18.04.02, which is supposed to happen Feb 7 ?
<pedronis> s/same/sense/
<mvo> pedronis: if 18.04.2 we better have it in, 2.38 is not going to be there in time
<mvo> pedronis: or we could do a 2.37.1 for it but that seems wasteful if we can have it now. I do a review
<pedronis> mvo: mborzecki: anyway it needs a spread test
<pedronis> (now we should be able to have one)
<mup> PR snapd#6346 opened: osutil: add helper for loading fstab from string <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6346>
<pedronis> mvo: I forwarded you the mail for context
<mup> PR snapd#6347 opened: many: allow snap-update-ns to write user mount profile <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6347>
<mvo> pedronis: thanks
<pedronis> Chipaca: hi, #6339  was merged but afaict we lost a bit of testing about the unicode formatting cases?  it seems only CanUnicode tests consider the true case
<mup> PR #6339: cmd/snap: only auto-enable unicode to a tty <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6339>
<mup> PR snapd#6348 opened: snap: split alignment calculation and display for channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/6348>
<pedronis> Chipaca: otoh I removed the blocked on #6280
<mup> PR #6280: cmd/snap: make 'snap warnings' output yamlish <Created by chipaca> <https://github.com/snapcore/snapd/pull/6280>
<Chipaca> pedronis: ah, i was just replying to the first of those
<Chipaca> pedronis: There's a test with --unicode=always, and there's a test that --unicode=auto does the right thing
<pedronis> mvo: not a fan of the structuring of #6348, still prefer what I proposed to John
<mup> PR #6348: snap: split alignment calculation and display for channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/6348>
<mborzecki> mvo: i should have the spread test for #6343 up shortly
<mvo> pedronis: maybe I misunderstood your original suggestion. in general I like to split data gathering from the display processing, I feel this makes things easier to read. but maybe that is not your concern?
<mup> PR #6343: overlord/configstate/configcore: support - and _ in cloud init field names <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6343>
<pedronis> mvo: I proposed to encapsulate much more into a struct
<mvo> mborzecki: oh, nice. if its shortly we can take that one too. I just reviewed 6343
<mborzecki> mvo: mhm, saw that, thanks!
<pedronis> mvo: I think John got what I proposed he can comment further, pick it up
<mvo> pedronis: sounds good, reading your comment again I see what you have in mind (I think). that sounds even better. like I said, mostly my OCD to split it a bit more but more encapuslation would be even better of course
<pedronis> mvo: anyway as I said, not sure you should be working on this :)
<mvo> pedronis: do you think a spread test for 6343 is required? I see you added blocked, is that because of the missing spread test?
<pedronis> mvo: yes
<mvo> pedronis: yeah, I shouldn't
<mvo> pedronis: ok
<mvo> pedronis: I will start working on 2.37 now, if 6343 looks good, I can cherry pick it, we need a 2.37~pre1 in any case to see if autopkgtest is happy
<pedronis> mvo: anyway, it needs work
<pedronis> I mean #6343
<mup> PR #6343: overlord/configstate/configcore: support - and _ in cloud init field names <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6343>
<pedronis> now that I'm looking at it
<pedronis> mborzecki: some comments to 6343
<mborzecki> pedronis: thanks
<zyga> I posted some simple branches for qucik review
<mup> PR snapd#6349 opened: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6349>
<zyga> as well as one branch I will work with jdstrand on
<zyga> jdstrand: could you please review https://github.com/snapcore/snapd/pull/6347 -- it is a part of larger pull request https://github.com/snapcore/snapd/pull/6341 broken out for reviewabiliy
<mup> PR #6347: many: allow snap-update-ns to write user mount profile <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6347>
<mup> PR #6341: cmd/snap-update-ns: persist per-user mount namespace profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6341>
<mup> PR snapd#6350 opened: cmd/snap-confine: don't preemptively create .mnt files <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6350>
<mborzecki> pedronis: just to be clear about your coment, you're suggesting to use the fields in pairs, i.e. cloud_name is set, then we'd use availability_zone regardless of it being set or not (or the value of availability-zone), did i get that right?
<pedronis> mborzecki: yes
<mborzecki> ack
<mborzecki> pedronis: updated, pushed a spread test too
<mborzecki> it seems that only ubuntu and amazon linux images have instance data set properly, others either do not use cloud-init or instance data is empty/unset
<mup> PR snapd#6351 opened: tests: review/fix the autopkgtest failures in disco <Created by mvo5> <https://github.com/snapcore/snapd/pull/6351>
<pedronis> mborzecki: that's fine, as long as we have at least ubuntu
<mborzecki> also, gce sets both - and _ names, while amazon only sets _ ones
<pedronis> interesting
<mborzecki> maybe a diferent version of cloud-init
<pedronis> suspect so
<pedronis> but I thought they didn't drop yet producing both
<pedronis> anyway
<pedronis> that's why I was very keen of having the spread test
<mborzecki> iirc it's set at boot time, i suspect that the engine hands an image that has just _ but cloud-init sets _ and - for compatibility with whatever might be runnning in the image
<pedronis> mborzecki: you are saying there's no cloud-init on the amazon linux one?
<pedronis> but the file is there?
<mborzecki> pedronis: there is
<pedronis> anyway I need to go have lunch
<pedronis> I'll look again and we can finesse this then
<pstolowski> pedronis: i've just pushed updates to hotplug-connect branch
<mborzecki> mixed that up, amazon uses -, not _, gce does both
<greyback> zyga: hey, can I book a minute to discuss https://github.com/snapcore/snapd/pull/6281#discussion_r241718332 ?
<mup> PR #6281: interfaces/builtin: add Multipass interfaces <Created by gerboland> <https://github.com/snapcore/snapd/pull/6281>
<zyga> hey!
<zyga> looking
<zyga> greyback: I was thinking about using the kmod backend
<zyga> greyback: where snapd does the modprobe fore you
<zyga> *for
<greyback> zyga: oh, this is new to me.
<zyga> let me show you an example
<greyback> please
<zyga> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/firewall_control.go#L156
<greyback> that simple, huh? nice
<zyga> you just declare the modules you want when an interface is connected
<zyga> presto
<zyga> yep
<greyback> sweet, I'll use that
<greyback> thanks!
<zyga> great, thank you :)
<zyga> whee
<zyga> I reproduced this dreaded issue:
<zyga> https://www.irccloud.com/pastebin/WAm6nIiD/
<zyga> https://www.irccloud.com/pastebin/HfXBv3XJ/
<zyga> indeed!
<pstolowski> mvo: hey, can you take a look at #6113 when you have some time?
<zyga> there's no /var/snap in core16!
<zyga> hmmm
<mup> PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
<mvo> pstolowski: I put it on my mlist
<Chipaca> zyga: in which core 16?
<zyga> Chipaca: inspecting
<pedronis> pstolowski: thank, will look again at thos hotplug PRs once done with 2.37 stuff
<zyga> we just get core16 from edge
<Chipaca> ah, actual core16
<zyga> it's failing randomly all day for me
<pstolowski> pedronis: sure, thanks
<mvo> zyga: hm, core16 should have that, let me double check
<Chipaca> zyga: hmm
<zyga> mvo: I have a snap that does not
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/6350#issuecomment-453075903 ?
<mup> PR #6350: cmd/snap-confine: don't preemptively create .mnt files <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6350>
<mborzecki> ah, i see you already noticed
<mvo> zyga: which version?
<mvo> zyga: I mean which rev and version?
<zyga> https://www.irccloud.com/pastebin/fA0Okwbn/
<zyga> is that expected? 2018 september is kind of old
<mvo> zyga: looking
<Chipaca> confirmed
<Chipaca> i386 core16 on edge has no /var/snap
<mvo> zyga: I triggered a new build from edge
<zyga> http://paste.ubuntu.com/p/yyq8FFKPnY/
<zyga> mvo: thank you
<zyga> how come this ever passed?
<zyga> this is the list of files in that snap
<Chipaca> amd64 is fine tho
<mvo> zyga, Chipaca the versions are all a bit inconsistent, I triggered a new build with that they should be all in sync again
<zyga> thank you
<zyga> was it built recently?
<zyga> revision is kind of low
<zyga> but perhaps/
<zyga> I'm trying to understand why it fails
<pedronis> mborzecki: +1 for #6343 with a comment about the spread test tough
<mup> PR #6343: overlord/configstate/configcore: support - and _ in cloud init field names <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6343>
<mvo> zyga: I looked at this earlier today as it failed in autopkgtest on s390x, I think while trying to make sure all versions are vaguely correct I promoted the wrong one
<mvo> zyga: but looking at the versions there is no right one right now :(
<zyga> aha so you were changing the published revision?
<zyga> I wish snapcraft had publishing history like git
<mborzecki> zyga: left a litle comment under #6349
<mup> PR #6349: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6349>
<zyga> mvo: I don't understand why it only sometimes failed
<Chipaca> zyga: mvo: pedronis: https://pastebin.ubuntu.com/p/Z2BJDqjVRS/
<pedronis> Chipaca: :)
<Chipaca> those all seem very recent
<zyga> Chipaca: I like the idea, can nitpick on the syntax
<mborzecki> Chipaca: nice
<mborzecki> Chipaca: is it still valid yaml?
<zyga> Chipaca: how about channels:\n\t<arch>\n\t\tlatest/stable: ...
<Chipaca> this was a quick hack just to see what was released where :-)
<Chipaca> mborzecki: probably :-)
<pedronis> zyga: yea, I expect some back and both on the options and the output
<pedronis> *back and forth
<Chipaca> mborzecki: http://yaml-online-parser.appspot.com/ thinks it is
<Chipaca> zyga: mvo: strangely enough the released-at is all today, but the version numbers are all over the place
<mvo> Chipaca: yeah, I tried to publish a consistent set today
<mvo> Chipaca: which did not work well, so the released-at is correct
<mvo> Chipaca: and its such a nice feature!
<Chipaca> heh
<Chipaca> you can thank sabdfl for that one :-)
 * mvo thanks him
 * Chipaca thinks you can probably thank him for the whole thing, while you're at it
<mvo> Chipaca: which reminds me, did you update the bug to fix-commited yet :) ?
 * mvo thanks him some more
<pedronis> he did
<Chipaca> I did :-)
<pedronis> mborzecki: does my comment on the spread test make sense?
<mborzecki> pedronis: wonder how much it depends on the cloud provider, nonetheless, the file is there in 16.04+ instances, so ensuring the test runs actually somewhere sgtm
<pedronis> mborzecki: yea, but the cloud provider we nail with backend check
<pedronis> s/backend check/the backend constraint/
<mborzecki> pedronis: it's pinned to backends: [google] atm
<pedronis> yes, that's what I mean
<pedronis> so my hope is that  google  x ubuntu (classic)  should work
<pedronis> at a minimum
<mborzecki> pedronis: instance data is also set in core-16 images too, only 14.04 is missing out
<pedronis> mborzecki: ok, should also be on core18
<pedronis> but anyway
<pedronis> let's indeed do all ubuntus where it seems to work
<pedronis> mborzecki: also the red tests is because of a typo apparently
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6349 :)
<mup> PR #6349: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6349>
<mborzecki> zyga: thanks, will take a look
<mborzecki> off to pick up the kids
<jdstrand> zyga: yes, I plan to go through that and the others I've been asked to look at today/tomorrow
<zyga> thank you
<mup> PR snapcraft#2434 closed: rust plugin: refactor to use the latest rustup <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2434>
<mup> PR snapd#6352 opened: many: remove .user-fstab files from /run/snapd/ns <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6352>
<Chipaca> pedronis: would a spread test be enough to cover the rererefresh case?
<Chipaca> :-|
<pedronis> Chipaca: we need to talk, I'm in a meeting
<Chipaca> pedronis: ok
<Chipaca> i'll go have lunch
<mup> PR snapd#6353 opened: cmd/snap-update-ns: move existing code around, renaming some functions <Created by zyga> <https://github.com/snapcore/snapd/pull/6353>
<zyga> I pushed one long but simple branch that just splits bigger file into focused chunks
<mborzecki> hm, under spread, jq is available in core-18 images but not in core-16
<mborzecki> or am i missing something there?
<pedronis> mborzecki: it's installed as a snap under core afaik
<pedronis> you can find the installation in some prepare code I think
<pedronis> maybe the code checks core but not core 18 atm
<pedronis> or the reverse
<mborzecki> and now travis seems to be slow to start spread jobs https://travis-ci.org/snapcore/snapd/builds/477815742?utm_source=github_status&utm_medium=notification heh
<mvo> mborzecki: yeah, quite a bit of delay in spread right now :/
<mvo> (well travis to be fair)
<Chipaca> zyga: https://forum.snapcraft.io/t/tried-to-install-quelea-presentation-software-from-chrome-linux-beta/9247?u=chipaca dunno if you're the right person to answer here but ogra seems to think so :)
<ogra> Chipaca, well, sorry ... zyga already told  me he has no idea about chromeos support ... i didnt forward that to the forum post
<ogra> but yeah, zyga being the "foreign distro ambassador" in the team, i thought he might know :)
<zyga> I don't have a chromebook anymore
<zyga> and AFAIK only some recent chromebooks can run lxd
<zyga> and thus run snaps
<zyga> but I have 0 knowledge about how that works
<zyga> or what's the nesting story
<ogra> even then i bet it is doubtful becase of lacking kernel features
<zyga> dunno :)
<zyga> jdstrand: replied on the permission topic
<zyga> jdstrand: it's really about go vs c logic
<zyga> jdstrand: one thing we might do is to open the fd while still in C
<zyga> jdstrand: but I don't really think that warrants the extra logic today
<Chipaca> zyga: even replying "I don't know and this is why I don't know" would be helpful
<zyga> mvo: so based on what you said, can we merge https://github.com/snapcore/snapd/pull/6294 now?
<mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
<mvo> zyga: yeah, maybe early next week but in theory we could do so *now*
<Chipaca> zyga: missing on that PR: move the travis unit tests to run with 1.9 instead of 1.6
<Chipaca> zyga: I can push that change
<zyga> Chipaca: oooh, indeed
<zyga> Chipaca: if you can please do
<mborzecki> can't wait to get rid of the 1.6 gofmt wrappers that I have now
<Chipaca> mborzecki: next you'll be wanting generics or whatever they're getting called
<mborzecki> haha :P
<mborzecki> Chipaca: wouldn't mind pattern matching in go 2 tho
<Chipaca> are we getting pattern matching as well? i missed that bit
 * cachio lunch
<pedronis> I think the improvements to error wrapping are probably the most interesting bit for us
<mborzecki> Chipaca: afaik no
<mborzecki> pedronis: we could use github.com/pkg/errors for this now
<pedronis> mborzecki: it's not about our errors usually
<pedronis> more about the std lib ones
<pedronis> especially networking ones
<mborzecki> mhm
<pedronis> mborzecki: I'm talking about the contorsions our retry code does for example
<mborzecki> btw. did they sort out the context for io interfaces?
<mborzecki> mvo: about jq https://paste.ubuntu.com/p/YGPvF65wFJ/
<mvo> mborzecki: hm, interessting
<mborzecki> mvo: changes: https://paste.ubuntu.com/p/GphB7jj8Gd/ up to change 8 it's all prepare, change 9 is caused by prepare section of the cloud-init test
<zyga> mvo, mborzecki we install jq in prepare
<mborzecki> zyga: but it's removed later on
<zyga> mborzecki: grep for jq in the tests/lib section
<zyga> disable_refreshes needs it
<zyga> hmm
<zyga> i see now
<mborzecki> zyga: right, but it's removed just below
<zyga> indeed
<zyga> no idea now
<pedronis> mborzecki: mvo: fwiw I just double checked, there is no jq in core18 itself
<pedronis> at least not in stable
<mborzecki> pedronis: not in edge either
<mborzecki> waiting for vanilla core18/16 instances to boot and will check there
<mborzecki> hm no clue
<mup> PR snapcraft#2435 opened: Appstream desktop <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2435>
<mup> PR snapcraft#2436 opened: snap: add build-package for xml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2436>
<zyga> mborzecki, mvo: can I please get a review for https://github.com/snapcore/snapd/pull/6353
<zyga> it will let me propose the rest once merfed
<mup> PR #6353: cmd/snap-update-ns: move existing code around, renaming some functions <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6353>
<pedronis> degville: I posted some comments to the doc update PR
<pedronis> thanks for working on that
<degville> pedronis: no problem - thanks, just looking at the comments now.
<pedronis> mvo: you probably want to give it a pass too
<plars> ogra: hi! Do you think there's any chance the pi core images could ever work booting from USB (at least on pi3b+)? I know they don't currently, and I saw the previous discussion about this with a hacked uEnv.txt that would work temporarily, but I was looking for something that wouldn't break once kernels get updated over time
<pedronis> Chipaca: did you see cachio answer here? #6121
<mup> PR #6121: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6121>
<Chipaca> pedronis: I'll look now
<Chipaca> pedronis: meanwhile, am I holding it wrong, in https://pastebin.ubuntu.com/p/dtZJJhshkS/ ?
<Chipaca> pedronis: the coutner task isn't run and I'm wondering why
<mvo> pedronis: yeah, I have a look in a wee bit, just one more 2.37 push
<mup> PR snapd#6121 closed: tests: new test for snapshots with more than 1 user <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6121>
<pedronis> Chipaca: you do only one Ensure, why should it run?
<pedronis> anyway doing just one Ensure is what you probably
<pedronis> and just check the task is there, not run
<pedronis> s/probably/probably want/
<Chipaca> pedronis: rerefresh does a 		st.EnsureBefore(0)
<pedronis> Chipaca: that's relevant only if run Loop
<pedronis> if you run Loop
<pedronis> or Settle
<pedronis> indeed usually it explodes
<pedronis> if you don't do one of those
<pedronis> though if usually mock it because of that
<Chipaca> I guess I'll look at the tasks then :-)
<pedronis> Chipaca: yes
<pedronis> Chipaca: the auto-connect tests in ifacestate are probably a good inspiration
<pedronis> I think
<pedronis> in case
<pedronis> (similar kind of task that creates more tasks)
<ogra> plars, this should work since ages (if you turned usb booting on in the firmware)
<plars> ogra: I didn't think anything should be needed on b+, but it doesn't work for me there. What else would I need to do? It does work to boot a usb stick with something like raspbian, but on core 18 and 16 images it does not. So I know the device is capable of it
<ogra> well, thats a bug then ... it should definitely work on core 16 ... i forgot when abeato did the PR for USB boot, but thats surely already a year in there
<abeato> ogra, yes, it has been there for a while. I tested it with an rpi3, no idea if something has changed in the b+
<ogra> shouldnt
<zyga> break now, feeling sleepy
<ogra> as long as you did the HW switching to enable USB it should just work ... if not, thats a bug
<plars> abeato: and you didn't need anything on an sd card to make it work? Just the core image written to a usb stick?
<plars> I will double-check with my b+ and try on the earlier pi3 also
<ogra> plars, right, thats the purpose of the HW hack
<abeato> plars, yes, the raw image on the stick should work
<ogra> USB becomes a normal boot device permanenently once you toggled it ... and you cant revert that
<plars> neato, if that works, I have another possibility for getting some better provisioning working
<ogra> plars, let me know if it doesnt, then we can research
<plars> usb toggle it how? with program_usb_boot_mode=1 in config.txt?
<ogra> yes, and then turning that off again after one boot ... it burns a fuse on the board and makes it permanently boot from USB alongside SD
<abeato> plars, to force the toggle (HW fuses I guess) I had to install raspbian and follow the intructions that are around
<ogra> plars, thats the code that should make it work: https://github.com/snapcore/pi-gadget/blob/master/uboot3.patch#L19
<plars> ok
<ogra> (oh, thats the universal gadget that works on all pi's ... the pi3 specific one (which core16 still uses i think) is at https://github.com/snapcore/pi3-gadget/blob/master/uboot.patch#L21 )
<thresh> hmm the visual distinction in the store metrics page isnt very good: http://thre.sh/stuff/vlc-stats-snap-weird.png
<pstolowski> te
<pstolowski> re
<pedronis> mvo: did you see my question about 18-cm3 vs 18-pi3 ?
<mvo> pedronis: let me check
<mvo> pedronis: replied
<pedronis> mborzecki: it's a bit strange to add /connections end point that return something that has just top-level  plugs and slots
<mup> PR snapd#6354 opened: overlord: drop old v1 store api support from managers test <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6354>
<Chipaca> ^ i'm rebasing rerefresh on this as it simplifies the added complexity of epochs in the managers test
<pedronis> mborzecki: we should brainstorm a bit
<mvo> 6351 and 6342 need a second review
 * mvo dinner
<pedronis> mvo: #6343 is green, you might want to re-look tough because it has changed a bit
<mup> PR #6343: overlord/configstate/configcore: support - and _ in cloud init field names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6343>
<pedronis> mvo: youd didn't actually vote on #6342
<mup> PR #6342: use major() and minor() in <sys/sysmacros.h> instead of MAJOR and MINORâ¦ <Created by timchen119> <https://github.com/snapcore/snapd/pull/6342>
<pedronis> degville: there is still a place that needs s/-cm3/-pi3/, left a comment
<degville> pedronis: ah, got it. thanks - sorry I missed it.
<pedronis> Chipaca: +1, thank you
<zyga> mvo: I pushed more to https://github.com/snapcore/snapd/pull/6342#pullrequestreview-191328298
<mup> PR #6342: use major() and minor() in <sys/sysmacros.h> instead of MAJOR and MINORâ¦ <Created by timchen119> <https://github.com/snapcore/snapd/pull/6342>
<zyga> https://github.com/snapcore/base-18/issues needs gardening
<zyga> seems like we never touched the set of issues I made after we started working on core18
<zyga> https://github.com/snapcore/snapd/pull/6349 needs a 2nd review
<mup> PR #6349: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6349>
<zyga> https://github.com/snapcore/snapd/pull/6350 also needs a 2nd review
<mup> PR #6350: cmd/snap-confine: don't preemptively create .mnt files <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6350>
<mup> PR snapd#6354 closed: overlord: drop old v1 store api support from managers test <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6354>
<mvo> pedronis: thanks, re-reviewed and also updated the tests PR
<mvo> zyga: thanks for the extra grep and fixing!
<zyga> :)
<mborzecki> pedronis: let's meet in the morning, i tried to reuse much of the code that was there, but there's definitely room for improvements
<zyga> mvo: +1 to merge https://github.com/snapcore/snapd/pull/6294 now?
<mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
<mvo> zyga: if it helps you now then yes, otherwise I would prefer monday
<zyga> mvo: monday then :)
<zyga> mvo: if you have a moment I would love to land https://github.com/snapcore/snapd/pull/6353 as I can then propose the refactoring
<cachio> mvo, do you know when sru will be ready?
<mup> PR #6353: cmd/snap-update-ns: move existing code around, renaming some functions <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6353>
<cachio> mvo, can I help?
<mvo> cachio: probably not today :( still waiting for two PRs to run through travis
<mvo> cachio: so you can relax and work on something else, no need to wait for this
<cachio> mvo, ok
<cachio> thank
<pedronis> mvo: we can merge 6343 then, right?
<mvo> pedronis: yes, I can have a second look but yes, thats fine, I will cherry pick
<pedronis> mvo: I let you merge it
<pedronis> I approved the tests one
<mvo> pedronis: you had one question (exit 0 vs exit 1) in there, should we do this via a follwup?
<pedronis> mvo: where?
<mvo> pedronis: https://github.com/snapcore/snapd/pull/6343/files#r246737708
<mup> PR #6343: overlord/configstate/configcore: support - and _ in cloud init field names <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6343>
<pedronis> mvo: it was addressed, it's just github confused
<mvo> pedronis: ok
<pedronis> because the line I commented on is still there
<pedronis> mvo: see line 20-  in the test
<mvo> pedronis: +1
<mup> PR snapcraft#2436 closed: snap: add build-package for xml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2436>
<mup> PR snapd#6342 closed: use major() and minor() in <sys/sysmacros.h> instead of MAJOR and MINORâ¦ <Created by timchen119> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6342>
<mup> PR snapd#6351 closed: tests: review/fix the autopkgtest failures in disco <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6351>
<mup> PR snapd#6343 closed: overlord/configstate/configcore: support - and _ in cloud init field names <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6343>
<mup> PR snapd#6355 opened: release: 2.37~pre1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6355>
<teward> is there someone who can field a concern about snapcraft store, malware, security, and privacy?
<teward> off-channel.
<popey> teward: wassup?
<teward> popey: PM?
<popey> sure
#snappy 2019-01-11
<mup> PR snapcraft#2437 opened: repo,baseplugin: support trusting repo keys <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2437>
<zyga> Good morning
<mborzecki> morning
<zyga> hey mborzecki  :)
<mborzecki> zyga: hey hey
<zyga> I'd love to land some boring stuff today
<zyga> most blocked by https://github.com/snapcore/snapd/pull/6353
<mup> PR #6353: cmd/snap-update-ns: move existing code around, renaming some functions <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6353>
<mborzecki> zyga: which pr should i start with first?
<zyga> I think this one is the only one I really need
<zyga> though all the <simple> ones should be a moment to review
<mborzecki> ack
<mup> PR snapd#6355 closed: release: 2.37~pre1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6355>
<mborzecki> zyga: one suggestion under #6349, other than that it's +1
<mup> PR #6349: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6349>
<zyga> looking
<zyga> nice :)
<zyga> pushed
<zyga> I prepared another branch but I will need https://github.com/snapcore/snapd/pull/6346 as well
<mup> PR #6346: osutil: add helper for loading fstab from string <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6346>
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6346 based on your comment
<mup> PR #6346: osutil: add helper for loading fstab from string <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6346>
<mborzecki> zyga: regarding #6345 none of the patches that start to make use of FromSnapConfine in s-u-n user mounts are up yet, right?
<mup> PR #6345: cmd/libsnap: pass --from-snap-confine when calling snap-update-ns as user <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6345>
<mborzecki> zyga: same for freezer
<zyga> mborzecki: the main branch is
<zyga> mborzecki: the only use of --from-snap-confine is to lock/freeze
<zyga> but that is arguably one of the last patches in this pile
<mborzecki> zyga: mhm
<mborzecki> btw. have dropped codecov?
<mborzecki> s/have/have we/
<zyga> I ... don't remember we did
<zyga> but perhaps?
<mborzecki> idk, haven't seen any coments being added to the new PRs
<pstolowski> morning
<mborzecki> pstolowski: heya
<zyga> hey Pawel
<zyga> pstolowski: hey, could you do a 2nd review for https://github.com/snapcore/snapd/pull/6353
<pstolowski> zyga: sure
<mup> PR #6353: cmd/snap-update-ns: move existing code around, renaming some functions <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6353>
<Chipaca> moin moin
<zyga> hey chipaca :)
<zyga> Chipaca: can I bug you for one little review in the morning please? https://github.com/snapcore/snapd/pull/6346
<mup> PR #6346: osutil: add helper for loading fstab from string <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6346>
<Chipaca> zyga: you can bug me all you want
 * Chipaca adds zyga to his ignore list
<mborzecki> Chipaca: hey
<zyga> re
<Chipaca> should I have another coffee?
<Chipaca> I should have another coffee.
 * Chipaca obeys
<zyga> Chipaca: I hear you
<zyga> coffee is good
<mup> PR snapd#6356 opened: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<Chipaca> pedronis: ^_^
<pedronis> Chipaca: thx
<Chipaca> pedronis: and good morning
<pedronis> we'll see if I get to it today
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6353#issuecomment-453438414
<mup> PR #6353: cmd/snap-update-ns: move existing code around, renaming some functions <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6353>
<pstolowski> zyga: sure
<zyga> thanks!
<zyga> I didn't notice 2017 :)
<mup> PR snapd#6353 closed: cmd/snap-update-ns: move existing code around, renaming some functions <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6353>
<zyga> Chipaca: the pic in your response is lovely
<zyga> feels like the way to spend time :)
<Chipaca> zyga: :-)
<mup> PR snapd#6346 closed: osutil: add helper for loading fstab from string <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6346>
<pedronis> Chipaca: next on your list, I think, is snapshot user docs?  and maybe picking up/rework #6348? does that sounds right?
<mup> PR #6348: snap: split alignment calculation and display for channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/6348>
<Chipaca> pedronis: I'd like to know what to do about #6034 also
<mup> PR #6034: many: save media info when installing, show it when listing <â Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<Chipaca> pedronis: but, yes, snapshot user docs, info refactor, then maybe per-architecture info
<pedronis> Chipaca: yes, I'm aware of 6034, but indeed needs discussion so it's blocked atm
<Chipaca> pedronis: we're not going to have time to have that discussion before the town of capes, right?
 * Chipaca hopes everybody packed capes
<pedronis> likely not but we'll see
<pedronis> Chipaca: also next week sprint is organized a bit differently, with lots of everybody sessions all in the morning, so I might not be busy all the time, just almost all the time
<Chipaca> pedronis: also I notice you removed the block on #6280, does that mean it's gtg (pending 2nd review)?
<mup> PR #6280: cmd/snap: make 'snap warnings' output yamlish <Created by chipaca> <https://github.com/snapcore/snapd/pull/6280>
<Chipaca> pedronis: you're going to a sprint, and think you might not be busy all the time
<Chipaca> *giggle*
<pedronis> Chipaca: I should probably look at it again (6280) but is not blocked about the --unicode oddities vs non-ttys
<Chipaca> pedronis: ah :-) ok
<pedronis> Chipaca: mvo asked for gustavo's input but if I understand it is something that was discussed with him, no?
<Chipaca> pedronis: yep
<Chipaca> at the london sprint (!)
<pedronis> also the general principle, if too wide for tabular/naive output, be yaml-like/parsable
<niemeyer> Heya
<pedronis> niemeyer: hi
<zyga> brb
<pedronis> Chipaca: can you remind me how to poke at the API with http ?
<Chipaca> pedronis: http snapd:///v2/find name==go
<Chipaca> pedronis: or, http --pretty=all snapd:///v2/find name==go | less -R
<pedronis> Chipaca: thank you
<Chipaca> huh, I thought snapshots were in 2.36
<Chipaca> just had a user on 2.36.3 tell me it didn't work there
<pedronis> Chipaca: no, they are not, not they client bits
<pedronis> they are in 2.37
<Chipaca> 2.37 is going to be a big'un
<pedronis> pstolowski: hi, btw I started yesterday looking again at the hotplug-connect PR but didn't finish, we'll try to do so today
<pstolowski> pedronis: ack, thanks
<zyga> pedronis: added one suggestion to the doc you just shared, it was something on the back of my mind for several interfaces (e.g. optical drive is the same)
<Chipaca> why isn't architecture in `snap version`?
<pedronis> zyga: add it "all" to what?
<pedronis> the plug, the slot?
<zyga> to the interface, I will clarify my comment
<zyga> well, to the slot side
<zyga> if you have "all" you are the old legacy camera
<zyga> if you don't have that you are a precise camera
<zyga> either hotplug or gadget
<pedronis> I was basing that on having a path or not
<pedronis> but we can do both
<pedronis> on the slot side, anyway this is a discussion to have
<pedronis> those were just jumping points
<zyga> that's good, it's the same idea
<zyga> ah, I see it's on the following line
<zyga> I'll retract my suggestion
<mborzecki> any clue if we'll be merging master to 2.37 again?
<zyga> master to 2.37?
<zyga> never?
<zyga> I think it is cherry picking from now on
<mborzecki> hm ok
<zyga> proxy leaking from test to test? https://www.irccloud.com/pastebin/cw3P0RWp/
<zyga> soliciting 2nd review for https://github.com/snapcore/snapd/pull/6349
<mup> PR #6349: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6349>
<zyga> pstolowski: do you have a moment?
<pstolowski> zyga: ok
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6352#discussion_r
<mup> PR #6352: many: remove .user-fstab files from /run/snapd/ns <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6352>
<mborzecki> zyga: yup
<mborzecki> zyga: wonder if that should use rm -f {} \: instead, so that find does not stop if there's a failure to remove
<zyga> those are plain files
<zyga> should remove fine
<zyga> pushed
<zyga> I think we only had -f to "fix" rm -f *.foo expanding to "*.foo"
<mborzecki> it'd be good if Chipaca could take a look too
<zyga> +1
<zyga> I added him to the review now
<zyga> +4, -16
<zyga> :)
<pedronis> pstolowski: +1 with a comment still, also would be good if you got reviews from mborzecki and mvo for it
<mborzecki> hehe :)
<pstolowski> pedronis: k
<zyga> re
<zyga> some kitchen emergency, all good now
 * pstolowski lunch
<zyga> I'm seeing one test fail often today;
<zyga> tests/main/xdg-open-compat fails with ERROR 503 while talking to launchpad.nett https://www.irccloud.com/pastebin/74kd9yef/
<Chipaca> zyga: .nett?
<zyga> no, .net, just a typo
<Chipaca> zyga: launchpad might be sad today
<mup> PR snapd#6357 opened: cmd/snap-update-ns: make freezer mockable <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6357>
<mup> PR snapd#6358 opened: cmd/snap-update-ns: close internal lock on error <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6358>
<zyga> mborzecki, pstolowski: I would love a review for the two above, this would make the refactor purely a refactor with 0 new features or fixes
<zyga> I broke the two patches out to make that true
<zyga> they are both really tiny
<mup> PR snapd#6349 closed: cmd/snap-update-ns: move XDG code to dedicated file <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6349>
<diddledan> is the store api down (snap find foo isn't working) or just my system having issues?
<diddledan> aha. it's gone through now
<diddledan> transient
<diddledan> ignore me
<cmatsuoka> working for me
<diddledan> :-)
<zyga> re
<diddledan> the knights who say "re"?
<mup> PR snapd#6359 opened: tests: use double quotes for regex on listing test to match \\* <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6359>
<diddledan> :-p
<zyga> store down and wonky errors https://www.irccloud.com/pastebin/pj7DG1v2/
<zyga> Chipaca: ^
<pedronis> Chipaca: standup?
<Chipaca> agh, yes
<Chipaca> was distracted by CVEs
 * Chipaca goes
<ali1234> how do i tell my snapcraft.yaml that i want to stage-packages from 16.04?
<diddledan> if you don't tell it you want `base: core18` it will use 16.04 by default (you are using multipass, right?)
<ali1234> i don't know
<zyga> diddledan: I don't think that's true
<zyga> diddledan: if you use base: core18 you will use the new base and the new multipass builder
<zyga> diddledan: but in absence of that I think you will build the old way
<zyga> diddledan: I may be wrong, but that's what I think was the approach
<ali1234> "Issues while validating snapcraft.yaml: The 'version' property does not match the required schema: 0 is not a valid snap version string."
<diddledan> zyga: yes, which is why I caveated my comment with the multipass
<zyga> right but multipass is not on uless you use base: *
<zyga> but there's no published core16 base
<ali1234> what is a valid version string then?
<zyga> ali1234: perhaps "1"
<zyga> not sure why 0 is rejected
<ali1234> nope, 1 also does not work
<diddledan> if you aren't knowingly using multipass then you'll use the old build which builds against your host. if you specify `base: core18` then you will use multipass
<ali1234> i want to use 16.04 as base when building on 18.04
<diddledan> the solution to use multipass correctly is `env SNAPCRAFT_BUILD_ENVIRONMENT=multipass snapcraft`
<ali1234> yeah what happens is if you don't have "base:" in snapcraft.yaml it builds against the host
<diddledan> not if you tell it to use multipass
<ali1234> if you have "base" it installs multipass for you, then fails to work because it won't accept any version string
<diddledan> the only `base` value that is accepted is `core18`. don't set it but tell snapcraft to use multipass
<ali1234> if i set base: core18 then it still fails to accept the version string. but doing it your way works
<ali1234> it is now launching a VM
<ali1234> it seems to be stuck...
<mup> PR snapd#6358 closed: cmd/snap-update-ns: close internal lock on error <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6358>
<zyga> ali1234: quick question, is there a reason you don't want to just say "base: core18"
<ali1234> yes, the package isn't available in ubuntu 18.04, if it was i'd just install it normally
<ali1234> "launch failed: timed out waiting for instance to respond"
<ogra> instance failed instantly :)
<zyga> ali1234: I'm not sure I understand
<ali1234> which part?
<zyga> ali1234: using base: core18 will just build your project against ubuntu 18.04 build system
<zyga> ali1234: is that breaking your software?
<ali1234> i dont have any software
<diddledan> o_O
<zyga> ali1234: which package is not available in 18.04?
<ali1234> eagle
<zyga> eagle?
<ali1234> yes, eagle
<zyga> and is it advailable in 16.04?
<zyga> https://packages.ubuntu.com/search?keywords=eagle&searchon=names&suite=all&section=all
<ali1234> yes
<ogra> the CAD tool ?
<ali1234> yes, the CAD tool
<zyga> aaah
<ali1234> which is non-free
<zyga> well
<zyga> that's not from the ubuntu archive :)
<zyga> what are you trying to build?
<ali1234> eagle
<zyga> an eagle snap?
<ali1234> yes
<ali1234> specifically an eagle 6.6 snap
<zyga> I think you can use base: core18 just fine, you need to teach your snapcraft.yaml about where to get eagle from
<ali1234> the version that is available for ubuntu 16.04
<zyga> unless eagle just plainly doesn't work on any other version of ubuntu
<ali1234> it isn't available any more
<ali1234> the only place it is available is the ubuntu package
<diddledan> eagle isn't available for ubuntu 16.04 specifically - you download it from autodesk as a tarball
<zyga> I think the error  you are seeing is unrelated to core18 or eagle and it would be the best to migrate to core18 for your software, integrate fetching the eagle .deb (however legal is that)
<zyga> I'm not just saying this because core18 is better
<ali1234> diddledan: no, it is available as an ubuntu package for 16.04
<diddledan> nope
<zyga> but because the old build model (building natively) is going away
<zyga> snapcraft switched to build with multipass-managed virtual machines
<ali1234> https://launchpad.net/ubuntu/+source/eagle/6.6.0-2
<mborzecki> or migrate to kicad :)
<diddledan> that's not available in xenial
<zyga> i386?
<ali1234> yes it is: https://launchpad.net/ubuntu/+source/eagle/
<zyga> Eagle is a powerful IM client designed to fit in perfectly in an enterprise environment.
<ali1234> yes, it's i386 only
<zyga> weird
<zyga> anyway, I'm back to coding
<mup> PR snapd#6357 closed: cmd/snap-update-ns: make freezer mockable <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6357>
<zyga> pstolowski: could you do a 2nd review for https://github.com/snapcore/snapd/pull/6345
<mup> PR #6345: cmd/libsnap: pass --from-snap-confine when calling snap-update-ns as user <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6345>
<ogra> ali1234, regarding your version issue, i can build just fine here using "version: 0" in a snap
<ali1234> yes, here it won't accept any version string at all
<ogra> did you put any quotes areound the version string or some such ?
<ali1234> no
<ogra> *around
<ogra> very weird
<ali1234> what is the most simple possible snapcraft.yaml that should always be guaranteed to build?
<ogra> what snapcraft version isthat ?
<ogra> $ snap info snapcraft|grep installed
<ogra> installed:   3.0.1                (2374) 28MB classic
<ali1234> whatever you get with 18.04
<ogra> you dont use the snap ?
<mup> PR snapd#6345 closed: cmd/libsnap: pass --from-snap-confine when calling snap-update-ns as user <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6345>
<zyga> \o/
<zyga> thanks!
 * ogra has long stopped using snapcraft from the archive ... never had issues 
<ali1234> snapcraft, version 3.0.1
<diddledan> I try to use a snap if one is available unless I hit issues with it that I can't fudge
<ogra> well, then i dont get why it doesnt work the same way as mine
<ali1234> actually i do have it installed through snap: installed:   3.0.1                (2374) 28MB classic
<ogra> probably some other typo in the snapcraft.yaml ? (and the version thingie just being fallout)
<ali1234> this is my entire snapcraft.yaml: http://paste.ubuntu.com/p/cQZFmSnm49/
<ogra> i doubt thats valid
<ogra> better use snapcraft init and modify the created file then
<mup> PR snapd#6360 opened: cmd/snap-update-ns: refactor of profile application <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6360>
<ogra> you are surely missing a lot of required fields
<ogra> (description, confinement ... not sure but probably also grade)
<diddledan> `version: 0` is actually invalid because snapcraft (or rather the python yaml parser) reads it as a number when it's expecting a string
<ogra> diddledan, it doesnt for me
<diddledan> replacing it with `version: '0'` works
<ogra> i just took one of my snaps changed version to 0 and called snapcraft ... no errors for me
<ali1234> okay i did "snapcraft init" and then "snapcraft" - it's hanging at launching the VM again
<diddledan> ogra: with ali1234's yaml: https://www.irccloud.com/pastebin/OeZVLYOb/
<ali1234> "snapcraft init" also generates a quoted version field
<zyga> niemeyer: the wikipedia reference on that bug is fantastic
<zyga> "That looks great. Just one thing: get rid of the duck."
<zyga> :"D
<ogra> diddledan, well, but that snapcraft.yaml is generalyl broken
<diddledan> the rest of the brokenness is besides the point though. snapcraft _expects_ a string.
<diddledan> if you managed to get a working build with a number then you've hit a bug
<ali1234> i just tried removing the quotes from the generated snapcraft.yaml and it produces the same error
<ali1234> the error message could be more helpful.
<ali1234> is multipass using docker?
<diddledan> no, kvm
<ali1234> "multipass launch" works, it is actually doing something
<ali1234> i can see qemu using CPU, it's still spinning though
<ali1234> nope, failed
<ogra> how ?
<ogra> (surely different than before ?)
<ali1234> nope, identical. it spins for about 8 minutes then says "launch failed: timed out waiting for instance to respond"
<ali1234> now running it with verbose
<ogra> have you tried a reboot ... or logout/login cycle, after installing multipass ?
<ali1234> no
<ogra> (did you wiggle the cable ?) :P
<ali1234> https://paste.ubuntu.com/p/26DQgRrWKQ/
<ogra> wow
<ogra> classic snaps ... the pain ...
<ogra> looks like it is somehow clashing with your deb-installed qemu
<ali1234> i have qemu arm installed
<ogra> there is a #multipass channel
<ali1234> okay so multipass works now. how do i tell it to stage i386 packages?
<ali1234> i tried "--target-arch=i386" but it had no effect. dpkg still only supports amd64 inside the instance
 * cachio lunch
<ali1234> ah there we go. run snapcraft with --debug, then run "sudo dpkg --add-architecture i386" inside the instance, then exit and run snapcraft again
<zyga> I found a bug in go :)
<zyga> but that's for next week
<zyga> I'm happy I also found a workaround
<Crocodillian> I'm trying to install spotify from snap, when it tries to download a core it says x509: certificate has expired or is not yet valid
<Crocodillian> is ssl just broken on my system
<zyga> Crocodillian: is the time set correctly?
<zyga> perhaps some certs *are* invalid though
<Crocodillian> no, it looks like my timezone is wrong
<Crocodillian> thanks!
 * cmatsuoka creates his first wine-based snap package
<cmatsuoka> lots of room for improvements tho
 * zyga takes a small break
<mup> PR snapd#6361 opened: kvm: load required kernel modules if necessary <Created by gerboland> <https://github.com/snapcore/snapd/pull/6361>
<zyga> mwhudson: hey
<zyga> not sure if you are the person to go to
<zyga> but I'm pretty much hopeless now :)
<zyga> https://github.com/golang/go/issues/29689
<mup> PR snapd#6362 opened: cmd/snap-update-ns: explicitly check for return value from parse_arg_u <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6362>
<mup> PR snapd#6363 opened: cmd/snap-update-ns: save errno from strtoul <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6363>
<mup> PR snapd#6364 opened: cmd/snap-update-ns: let the go parser know we are parsing -u <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6364>
<mup> PR snapd#6365 opened: cmd/snap-update-ns: manually implement isspace <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6365>
<zyga> Chipaca: ^ (that last one is cool0
 * Chipaca is suspicious of C code being called  "cool0"
<Chipaca> zyga: is the C string being passed zero-terminated?
<zyga> Chipaca: yes
<Chipaca> zyga: does it still crash if you -O0?
<zyga> look at https://github.com/zyga/go-bug-29689
<zyga> isspace doesn't care
<zyga> calling issspace(0) is enough
<zyga> or whatever
<zyga> ideas welcome :)
<zyga> you can also shrink the reproducer even more if you want
<Chipaca> zyga: yeah that's not a "minimal" reproducer
<mborzecki> zyga: that go bug, doesn't crash here
<Chipaca> still, strange
<Chipaca> mborzecki: 1.10?
<zyga> wait, you mean you can run my reproducer
<zyga> and not crash>
<mborzecki> 1.11.4
<zyga> I triied on 1.10 and 1.11.4
<zyga> and my keyboard seems to have some repeat issues sometimes, weird
<zyga> mborzecki: go build && ./go-bug 1000
<zyga> that doesn't crash for you?
<zyga> maybe depends on locale/
<mup> Bug #1000: There are too many bug reports in Malone <lp-foundations> <NULL Project:Invalid> <https://launchpad.net/bugs/1000>
<mborzecki> uh, ok, that crashes
<mborzecki> haven't passed any args before :P
<zyga> :D
<zyga> README
<zyga> but that's good
<zyga> it's just broken
<mborzecki> hm, idk why but it doesn't crash under dlv, or maybe i'm not passing the command line args again
<Chipaca> hm
<Chipaca> zyga: if I remove the __attribute__ bit it no longer crashes
<zyga> because that code doesn't run anymore
<zyga> add printf to check
<mborzecki> zyga: must be some weird libc interaction, when built statically it doesn't crash
<zyga> perhaps the problem is related to how isspace is implemented
<zyga> it uses a lookup table
<zyga> perhaps that code runs before various relocations are applied?
<zyga> but meh
<zyga> not fun
<zyga> and makes me think we should split out the C code to snap-run-in-namespace --user --snap-name
<mborzecki> zyga: that's from s-u-n right?
<zyga> yes
<mborzecki> zyga: i recall having some issues with code crashing in isalpha in s-u-n back when i was working on parallel instances
<mborzecki> would crash unless i build the binary statically
<Chipaca> building it statically has it not working again
<zyga> ha
<zyga> interesting
<Chipaca> zyga: what is it that calls bootstrap()?
<zyga> not working?
<zyga> Chipaca: the dynamic linker
<Chipaca> zyga: as in it isn't called
<zyga> look at main.go
<zyga> er
<zyga> bootstrap.go
<zyga> it's explained there
<zyga> *MAGIC*
<mborzecki> zyga: looking at glibc implementation, macro black magic f****ery, but it looks liek there's an array of points to actual functions that implement each op
<zyga> you mean issspace/
<zyga> isspace?
<mborzecki> zyga: yeah
<zyga> it looks like a single function call + array lookup on the result
<mborzecki> zyga: right, so it's a LUT indexed by char, the table is in thread specific data (?), and that's set up by some early locale init
<mborzecki> zyga: wonder what would hapend if i  add setlocale(LC_ALL, "") somewhere early
<mborzecki> zyga: and it works now :P
<mborzecki> zyga: https://paste.ubuntu.com/p/X2vgcX5Fr8/
<Chipaca> zyga: so
<Chipaca> zyga: you got a reply :-)
<mborzecki> hah, makes sense
<mup> PR snapcraft#2435 closed: Appstream desktop <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2435>
<mborzecki> zyga: something to keep you busy on the flight, dump .preinit_array and .init_array and see where bootstrap ends up and where locale tables are set up
<mup> PR snapcraft#2438 opened: rust plugin: new link for rustup <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2438>
<zyga> Chipaca, mborzecki: so we were just lucky so far
<mborzecki> zyga: and built statically, cause we had to
<zyga> I think I will write a snap-lowlevel-exec
<mborzecki> haha
<zyga> I'm serious
<zyga> this sucks
<zyga> we can drop the c code from snap-update-ns this way
<mborzecki> zyga: srsly, maybe we should take a look at what podman/docker/crio
<zyga> we did
<zyga> they do setns the same way
<mborzecki> same preinit_array trick?
<zyga> at least AFAIK
<zyga> I can be wrong
<mborzecki> zyga: otoh, there's no pressing need to fix it right away, so we can take time and research
<zyga> yeah
<zyga> as long as we don't need to call more functions :)
<zyga> can you review https://github.com/snapcore/snapd/pull/6365 please
<mup> PR #6365: cmd/snap-update-ns: manually implement isspace <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6365>
<zyga> I'm still pushing out the user-mount patches
<mup> PR snapd#6352 closed: many: remove .user-fstab files from /run/snapd/ns <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6352>
<mborzecki> zyga: even if you drop isspace, there's still islower & isdigit in the code
<zyga> but it doesn't crash
<zyga> perhaps doesn't need a table the same way?
<zyga> I'm after getting fixes in place :)
<mborzecki> zyga: i suppose you need to use a snap name with instance key
<zyga> oh
<zyga> I see
<mborzecki> wrapping it up
<mborzecki> zyga: pedronis: save travel
<zyga> thank you!
<mborzecki> s/save/safe/ :)
<mborzecki> enjoy the summer
<zyga> HAHA
<zyga> I think I will :)
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR snapd#6366 opened: cmd/snap-discard-ns: fix name of user fstab files <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6366>
<mup> PR snapd#6367 opened: cmd/snap-update-ns: allow switching to user mount namespace <Created by zyga> <https://github.com/snapcore/snapd/pull/6367>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#98 closed: Add force_turbo rpi option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/98>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#98 opened: Add force_turbo rpi option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/98>
<diddledan> is mup ok?
<diddledan> 4 successive "this was closed.. oh no, psych! it's open really :-p" messages
<mup> PR snapcraft#2439 closed: snap: add xslt dependencies for lxml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2439>
<mup> PR snapcraft#2439 opened: snap: add xslt dependencies for lxml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2439>
<mup> PR snapd#6368 opened: tests: check denials considering all the log lines instead of last 100 lines <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6368>
<om26er> popey, ping
<mup> PR snapd#6369 opened: Add check for snap binaries dir not being in path <Created by liamg> <https://github.com/snapcore/snapd/pull/6369>
#snappy 2019-01-12
<mup> PR snapd#6370 opened: interfaces/builtin/opengl: allow access to NVIDIA VDPAU library <Created by cgutman> <https://github.com/snapcore/snapd/pull/6370>
<mup> Bug #1811534 opened: snap - install skype warning - main.go: should be wrapped in (i18n) <i18n> <Snappy:New> <skype (Ubuntu):New> <https://launchpad.net/bugs/1811534>
#snappy 2019-01-13
<murthy> hardware acceleration is not working with vlc snap package
#snappy 2020-01-06
<mup> PR snapd#7954 opened: changelog: fix typos <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7954>
<sdhd-sascha> Hi, is there any newer docs to setup an snapstore, like this: https://ubuntu.com/blog/howto-host-your-own-snap-store ?
<Chipaca> sdhd-sascha: not that I am aware of
<sdhd-sascha> Chipaca: How can i build my own ubuntu-core and add my own kernel and gadget.
<sdhd-sascha> In the store it needs a review and i have to wait
<Chipaca> sdhd-sascha: I'd expect ubuntu-image to let you use a local (unasserted) snap
<sdhd-sascha> Chipaca: thank you :-) yesterday i already cloned ubuntu-image, because i'm looking for an error message :-)
<sdhd-sascha> sudo ubuntu-image -c beta -O rk3318-test rk3318.model
<sdhd-sascha> Warning: for backwards compatibility, `ubuntu-image` falls back to `ubuntu-image snap` if no subcommand is given
<sdhd-sascha> error: model with series "18" != "16" unsupported
<sdhd-sascha> COMMAND FAILED: snap prepare-image --channel=beta rk3318.model /tmp/tmpdh568a0l/unpack
<jamesh> sergiusens: a little Christmas present for you: https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930
<sergiusens> hello jamesh, thanks!
<sdhd-sascha> jamesh: +1
<Chipaca> sdhd-sascha: series 18??
<pedronis> sdhd-sascha: that's correct, series is fixed to 16, there is nothing like series 18
<pedronis> even if you use core18
<pedronis> as your base
<sdhd-sascha> ?
<pedronis> we thought we would have a series 16, 18, 20 etc
<pedronis> but in the end it's not what happened
<sdhd-sascha> https://www.irccloud.com/pastebin/RwdFllwF/
<pedronis> it might change at some point in the future if something changes is an very incompatible
<pedronis> way
<jamesh> sdhd-sascha: different values for series imply incompatible platforms.  You can mix snaps built for core and core18 on a single system
<pedronis> but hasn't so far
<pedronis> so series: 16 is fixed everywhere atm
<sdhd-sascha> i copied the linux raspi
<Chipaca> sdhd-sascha: change series:18 to series:16 in that model and it'll be better
<Chipaca> sdhd-sascha: there is no series 18
<Chipaca> sdhd-sascha: there never has been, and never will be
<sdhd-sascha> What is "series" for ?
<Chipaca> sdhd-sascha: resetting the universe
<sdhd-sascha> :-D
<Chipaca> sdhd-sascha: if we find a fundamental problem with the way we do snaps, and have to restart from scratch in an incompatible way
<pedronis> sdhd-sascha: the idea was that at each lts we could have completely disjoin sets of snaps, but we didn't proceed that way atm. it's just a format version number at this point
<pedronis> whose change would represent a non-backward compatible change
<pedronis> to a lots of things
<sdhd-sascha> i understand - thank you :-)
<sdhd-sascha> Is there a way, to store my passphrase with "snap sign" ? Currently i only can sign if i call "register-key" again
<Chipaca> sdhd-sascha: I'm not sure I understood your question
<sdhd-sascha> Chipaca: "snap sign" says: `error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key 0x.... --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n") `
<ogra> you dont have the key ;)
<sdhd-sascha> Then i call "snap register-key" again. Then it works for a moment.
<sdhd-sascha> "register-key" ask me for my passphrase of the key
<Chipaca> sdhd-sascha: there is no register-key
<ogra> thats a snapcraft option...
<sdhd-sascha> Oh, sorry "snapcraft register-key" from https://docs.ubuntu.com/core/en/guides/build-device/image-building#image-building
<sdhd-sascha> In this documentation on step 2 is "snap sign", which only works after "snapcraft register-key"
<sdhd-sascha> Did i need some "gpg-agent" or something?
<ogra> does "snapcraft list-keys" list your key ?
<sdhd-sascha> ogra: yes, "default" key
<ogra> and you are calling register-key with "default" as option ?
<sdhd-sascha> https://www.irccloud.com/pastebin/a7OgLbOb/
<sdhd-sascha> And going to 2FA site https://login.ubuntu.com/device-list
<sdhd-sascha> i get a 404 page
<ogra> well, and you get a 500 error in that paste
<sdhd-sascha> yes
<sdhd-sascha> the first time it works.
<sdhd-sascha> but i need to call "register-key", that "snap sign" works for a moment
<sdhd-sascha> https://www.irccloud.com/pastebin/TOfRf5RN/
<sdhd-sascha> and snapcraft:3.8
<ackk> hi, I have a (go-based) snap which has been failing for a while on BSI, but I can't reproduce the issue locally. https://build.snapcraft.io/user/albertodonato/h2static/785325 is an example of a failing build
<ackk> I tried both with and without go-importpath, they both work locally but both fail over there
<sdhd-sascha> ackk: is this a local path in the log? `go get -t -d ./github.com/albertodonato/h2static/...`
<ackk> sdhd-sascha, yeah that's based on go-importpath
<ackk> sdhd-sascha, https://github.com/albertodonato/h2static/blob/master/snap/snapcraft.yaml is the config
<sdhd-sascha> ackk: i try it here on my machine and will report, what happens here
<ackk> sdhd-sascha, I assume something has changes either with snapcraft or with the building env on launchpad, as I also had to add gcc as build-packages, which wasn't needed before
<ackk> sdhd-sascha, thanks
<sdhd-sascha> ackk: it works here, too
<sdhd-sascha> but i build it with multipass + vm
<sdhd-sascha> I will test it now with: `snapcraft build --use-lxd --debug`
<ackk> sdhd-sascha, yeah I did --use-lxd, worked for me
<sdhd-sascha> ackk: you are right about the env or something. --use-lxd runs without problem here
<ackk> I wonder if it's running the right "go" binary on LP
<ackk> actually, it doesn't seem it's running "go mod download", which looking at the plugin source code shoud do when go.mod is presente
<ackk> *present
<ogra> if i call snapctl from within an app, it does properly set the value for a key but doesnt run the configure hook at all ... is that a known issue ?
<ackk> ogra I think I've encountered that issue before, ISTR it was intentional (probably to avoid infinite loops?)
<ackk> sdhd-sascha, oddly, I get that error if I build with --destructive-mode
<ogra> ackk, well, sadly thats not helpful if you need to force-restart an app to make it pick up the new configuration ... :)
<ogra> (even worse if the configure hook actually re-writes a config file ... then the app config and snap values get completely out of sync)
<ogra> pedronis, ^^^ is that true (not running hooks for snapctl calls when they come from inside an app) ?
<ackk> ogra, yeah I agree it should call the hook, maybe it could either detect when it's being run inside a hook and not call it just in that case, or have a flag to do so
<pedronis> ogra: yes, that's by design, there has been discussions to support snapctl set --configure to get the other behavior
<ogra> ah, thanks ...
<ogra> very confusing behaviour :)
<ackk> sdhd-sascha, oh, it seems the stable snapcraft doesn't handle go.mod
<sdhd-sascha> ackk: oh
<sdhd-sascha> i can't use snapcraft:3.9 because of https://github.com/snapcore/snapcraft/pull/2840
<mup> PR snapcraft#2840: plugs: plugs can have no element <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2840>
<sdhd-sascha> i use snapcraft:3.8
<sdhd-sascha> stable
<zyga> hey mvo
<zyga> are we supposed to work today or did I get my dates messed up?
<sdhd-sascha> ackk: i need to ask again. I didn't understand the error cause. What's wrong and in which case?
<mvo> zyga: isn't there a public holiday in .pl today?
<zyga> yeah, I think so
<zyga> ah, but not in .de?
<ackk> sdhd-sascha, I get the same error as the build on LP if I run "snapcraft --destructive-mode"
<mvo> zyga: not in .de
<zyga> ah, that explains everything, I was worried seeing the release that I should be in the office for hours :)
<mvo> zyga: well, my understanding is that you guys have a public holiday but you should know better than me :)
<Chipaca> mvo: https://mobile.twitter.com/qikipedia/status/1213731861660413952 :)
<Chipaca> pedronis: reviewed #7935, i think i'll hold off going on down the stack for a bit
<mup> PR #7935: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7935>
<mvo> Chipaca: haha - good one
<ackk> sdhd-sascha, ah, I think I got it. it seems that the stable snapcraft doesn't handle go modules, but since it's using go1.13 by default now, go tried to pull them. if I remove go.mod it builds.
<sdhd-sascha> ah, ok
<ackk> so it probably broke for me when go1.13 snap was pushed to stable
<ackk> is there a way to extend the environment for pull/build steps? it doesn't seem that exporting a var in override-* works
<Chipaca> ackk: do you need to compute the value?
<Chipaca> otherwise the environment block should work
<ackk> Chipaca, no, it's afixed one. basically a workaround for the issue above ^ would be to set GO111MODULE=off for pull
<ackk> Chipaca, can I use "environment" in a part?
<Chipaca> ackk: build-environment IIRC
<ackk> ah, TIL
<ackk> Chipaca, out of curiosity, why is that a list of dicts rather than a dict like the app environment?
<Chipaca> ackk: hmm?
<Chipaca> ackk: I don't know
<Chipaca> ackk: question for sergiusens maybe
<ackk> disabling modules via build-environment worked, thanks sdhd-sascha and Chipaca
<pedronis> Chipaca: thx for the review
<Chipaca> pedronis: i change-requested it because of the error, if i goofed just holler :)
<pedronis> Chipaca: no, I think you are right, but need to do some other things before going back to those Prs
<pedronis> mvo: Chipaca: what should we do with this bug, it's not clear to me which bits are snapd and which are lubuntu? https://bugs.launchpad.net/snapd/+bug/1858303
<mup> Bug #1858303: Snaps don't work unless pre-installed or user logs out and logs back in <snapd> <snapd:New> <https://launchpad.net/bugs/1858303>
<mvo> pedronis: hmhm, interessting, looking
<mup> PR snapd#7955 opened: tests: remove "test-snapd-tools" in smoke/sandbox on restore <Created by mvo5> <https://github.com/snapcore/snapd/pull/7955>
<mup> Bug #1555140 changed: unit test apiSuite.TestGetOpInfoIntegration fails when building the deb in jenkins <Snappy:Won't Fix by chipaca> <https://launchpad.net/bugs/1555140>
<mup> PR snapd#7956 opened: packaging: ship var/lib/snapd/desktop/applications in the pkg <Created by mvo5> <https://github.com/snapcore/snapd/pull/7956>
<Chipaca> pedronis: that was figured out in the forum
<Chipaca> mvo: ^
<Chipaca> ah, mvo spotted that already
<Chipaca> anyway it's https://forum.snapcraft.io/t/snapd-required-dependencies-to-start/14904
<mup> Bug #1611068 changed: 401 when trying to install any snap due to invalid credentials in ~/.snap/auth.json <amd64> <apport-bug> <xenial> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1611068>
<mvo> Chipaca: yeah, 7956 should address it
<Chipaca> mvo: ah, nice
<mup> Bug #1665756 changed: environment variable setting issue <Snappy:Fix Released> <https://launchpad.net/bugs/1665756>
<mup> PR snapd#7948 closed: spread: drop copr repo with F30 build dependencies <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7948>
<Chipaca> degville: turing tumble is aweseme (only ever seen it in video -- i assume it's as good as it looks?)
<degville> Chipaca: yes! it's really good! :)
<mvo> degville: woah, that looks fun!
<degville> it's brilliant actually seeing and trying to physically work out how to solve the problems.
<sdhd-sascha> ogra: i think i found the problem with "snap sign". The passphrase wasn't shown because of the stdin-pipe.
<ogra> ah, ouch
<sdhd-sascha> Now i want to refactor the "snap sign"
<sdhd-sascha> But can i break backward-compatibility or not
<ogra> (i always use a dedictaed "build" or "image" key for my models that goes witjout passphrase)
<ogra> (snapcraft allows to give them names at creation time)
<sdhd-sascha> ogra: normally, i too ... but this time ...
<sdhd-sascha> i'm looking for a "snap delete-key" command, yesterday. Or how can registered keys be deleted ?
<ogra> i dont think they can easily
<sdhd-sascha> Ok, no delete
<ogra> (ask in the forum, i might be wrong ... i know they couldnt a year ago)
<sdhd-sascha> Then how about to make "snap sign -k default <filename>"
 * cachio lunch
<mup> PR snapcraft#2844 closed: Add punctuation rule for comments <Created by hellsworth> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2844>
 * Chipaca wonders at what time he should stop with the coffee
<ijohnson> grr the snapcraft forum seems even slower this year
<ogra> ijohnson, just append "?slow=false" to the url !
<ogra> ... and happy new year :)
<ijohnson> can I just do ?speed=plaid instead ? :-)
<ijohnson> happy new year ogra!
<mup> PR snapcraft#2837 closed: remote-build: gpg-signing and usability fixes <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2837>
<pedronis> Chipaca: I updated #7935
<Chipaca> pedronis: tks
<mup> PR #7935: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7935>
<Chipaca> pedronis: I presume the dropping of the NoState error is because it's umpossible :)
<Chipaca> unpossible*
<pedronis> Chipaca: yes, it should not happen, if we have kernel, we should have a model
<pedronis> and we check whether we have a kernel just before
<Chipaca> yep
<Chipaca> +1, thank you
<mup> PR snapd#7957 opened: snap-bootstrap: mount the correct snapd snap to /run/mnt/snapd <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7957>
<mup> PR core20#18 opened: static: try using /run/mnt/snapd first in run-snapd-from-snap <Created by mvo5> <https://github.com/snapcore/core20/pull/18>
<cachio> mvo, hey, having troubles to login into the uc20 instnace as root
<cachio> using your branch
<cachio> did you change anything today?
<pedronis> Chipaca: I reviewed your channel PRs
<pedronis> thank you
<mvo> cachio: I don't think I did - stange
<Chipaca> pedronis: thank you!
<Chipaca> pedronis: you're right about InstallPath, i'll fix that in a bit
<Chipaca> need to pop some state first :)
<Chipaca> also, need to reboot for a new kernel, and go to the shops and stuff. So AFK for a bit.
<cachio> mvo, np, I'll continue researching
<mvo> cachio: thank you
<mvo> cachio: s/stange/strange/ :)
<mvo> cachio: there were some core20/gadget changes over the break, maybe something there broke it, but AFAICT the spread test itself is still working on the uc20 tests
<cachio> mvo, with your branch didnt work today, the system reboots and it seems to be ok but I cant connect using root
<cachio> I was using a branch with my chnges and it was manually adding a access for the users
<cachio> and restarting ssh
<cachio> I just restarted the travis job to cehck it is wotking after the break
<mvo> cachio: oh, ok
<mvo> cachio: interessting, so something did change :/ please keep me update!
<mvo> updated
<cachio> mvo, sure
<mup> PR snapd#7958 opened: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
<mup> PR snapcraft#2849 closed: rust plugin: split RUSTUP_HOME and CARGO_HOME <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2849>
<mup> PR snapcraft#2833 closed: catkin: remove rospack workaround <Created by Arnatious> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2833>
<J_C> Hi there. Upon installing chromium-browser - which in my current version of Ubuntu (Kubuntu 19.10) subsequently installs the snapd version - the cursor theme is different to the one I currently use (Breeze theme) whilst it hovers over Chromium's contents. I have gtk-common-themes installed via snapd. Is there a way to force the snap to use the appropriate cursor theme? Thanks.
<ijohnson> J_C: you might try asking in #ubuntu-desktop or on the forums, I think most folks here who would be able to help you with that are offline due to TZ's
<J_C> ijohnson: Heh, I was actually suggested to ask in here from #ubuntu. No worries.
<ijohnson> J_C: ah ok, well anybody else in #snappy is free to speak up but I myself don't know :-)
<J_C> ijohnson: It's nothing too urgent anyway, just a small vidual quirk and nothing that impacts functionality at the very least. :)
<mup> PR snapd#7956 closed: packaging: ship var/lib/snapd/desktop/applications in the pkg <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7956>
<Chipaca> J_C: that will happen for any themes not included in the gtk-common-themes snap
<J_C> Chipaca: I was under the impression that both Breeze and Breeze Dark were in gtk-common-themes.
<Chipaca> J_C: cursor themes are separate though
<Chipaca> and I don't see anything under Breeze/cursors
<J_C> That's a shame. At least I know why the cursor isn't showing properly now. Thanks.
<mup> PR snapd#7959 opened: tests: fix classic-ubuntu-core-transition-two-cores after refactor of MATCH -v <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7959>
<Chipaca> J_C: what this says to me is that the cursor you're seeing is not of the theme but of some kde default
<Chipaca> J_C: if you figure out where it's from, maybe see about getting it included?
<Chipaca> if it is the default kde one, we should probably include it :)
<Chipaca> kenvandine: does that ^ sound sane to you? (about where the cursor is coming from)
<thiras> hello
<J_C> Chipaca: Sure, I'll have a look into it :) Should I submit a ticket to the gtk-common-themes repo or elsewhere? Would you like a screenshot as to what the current cursor looks like?
<thiras> is there a way to give local filesystem permission to snap package?
<Chipaca> thiras: not in general no. What are you trying to do in particular?
<thiras> specifically dbeaver package. it needs to access native mysql client installed on my system through apt
<Chipaca> J_C: i wouldn't know what to do with the screenshot other than agree with you, and i already believe you :)
<Chipaca> thiras: that sounds wrong
<thiras> you cannot use it's internal drivers to dump a database. it needs native mysql client to do that
<thiras> https://github.com/dbeaver/dbeaver/issues/1361
<thiras> obviously package maintainer seems be missed that detail. so the current package is totally isolated
<thiras> to be*
<Chipaca> thiras: there isn't a way of doing that, no
<thiras> too bad
<thiras> should i open a bug report to package maintainer?
<thiras> i guess some of the snap packages can have access to filesystem (like vscode)
<Chipaca> classic snaps can, yes
<Chipaca> but i don't think it's a bug, this seems more like working as intended
<Chipaca> thiras: what is the snap name by the way?
<thiras> Chipaca, dbeaver-ce
<thiras> maintainer is the dbeaver company itself
<thiras> then how modern snaps handles if they need to access to the filesystem?
<Chipaca> thiras: 'access to the filesystem' is one thing, what you're wanting is being able to run arbitrary things
<Chipaca> thiras: the short answer is that you don't, you can't, that's not how it's supposed to work
<Chipaca> anyway, EOD for me
<thiras> so i assume that snap package should contain native client within?
<Chipaca> ð
<thiras> thanks for help
<Chipaca> thiras: exactly, yes
<Chipaca> bye!
<mup> PR snapd#7960 opened: tests: use unbuffered python output for daemons, misc formatting <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7960>
<sdhd-sascha> Where is the place to ask question about "ubuntu-image" ? `error: cannot use kernel "linux-generic-allwinner" published by "QfOqF7d2M1Pk2O0SbEKqTdB9Ry2aI0BP" for model by "go2ddtVdG0SlCsLDKX7cd9IWiZoEbSym"`
<sdhd-sascha> Oh, sorry. This is a "snap sign" error
<sdhd-sascha> (revert last line)
<mup> PR snapd#7961 opened: cmd: sign: add filename param <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7961>
<mup> PR snapcraft#2852 opened: wstool: don't rely on host git <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2852>
#snappy 2020-01-07
<mborzecki> morning
<mborzecki> starting a bit later, need to drive the kids to school
<mup> PR snapd#7954 closed: changelog: fix typos <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7954>
<mup> PR snapd#7959 closed: tests: fix classic-ubuntu-core-transition-two-cores after refactor of MATCH -v <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7959>
<mup> PR snapd#7962 opened: tests: cherry-pick fixes for  snap-set-core-config/ubuntu-core-config-defaults-once <Created by mvo5> <https://github.com/snapcore/snapd/pull/7962>
<mup> PR snapd#7949 closed: cmd/snap, daemon: stop over-normalising channels <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7949>
<zyga> good morning!
<zyga> hey mvo
<zyga> mvo: anything to keep in mind regarding yesterday?
<mborzecki> re
<zyga> hey mborzecki :)
<mborzecki> one kid at school, the other sick at home
<mvo> hey zyga, good morning
<mborzecki> zyga: mvo: hey
<zyga> mborzecki: two at school, one still sleeping
<mvo> mborzecki: good morning and happy new year
<mvo> zyga: yesterday> nay, all good
<mborzecki> mvo: happy new year to you too! that was a looong break
<mvo> mborzecki: yeah, long and refreshing I hope :)
<mvo> (it was for me!)
<zyga> I must admit that after about a week of anxiety I really started resting
<zyga> and ended up not touching coding for most of the time
<mborzecki> mvo: thanks for uploading release tarballs to github releases!
<mvo> mborzecki: my pleasure, sorry that I was a bit late
<mborzecki> updated arch package to 2.42.5
<mborzecki> hm arch switched to zstd compression for packages, but i don't see any changes to makepkg.conf in https://git.archlinux.org/pacman.git/log/etc/makepkg.conf.in looks like they didn't push it yet
<mup> PR snapd#7955 closed: tests: remove "test-snapd-tools" in smoke/sandbox on restore <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7955>
<pstolowski> morning
<zyga> hey pawel
<mvo> hey pstolowski !
<pstolowski> hey hey
<mborzecki> pstolowski: hey
<mvo> a quick sanity-check of 7951 and 7962 would be nice, pedning 2.43 PRs
<pstolowski> mvo: there is one file less in 7951 than it was in the original PR, not sure if it's intentional?
<mvo> pstolowski: let me look to refresh my memories, it might be that this file is not in 2.43 yet
<abeato> mvo, hey, happy new year! I have been told that snapd does not yet support default tracks, when will that happen?
<zyga> re
<mvo> abeato: it's very close to land in edge, chipaca is landing PRs as we speak
<mvo> abeato: he should be here in ~1h or so - my (probably wrong) estimate is EOW but please double check with him on that :)
<abeato> mvo, awesome! mind pointing me to the MPs?
<mvo> abeato: this is edge, it missed the boat for 2.43 so most likely in stable for 2.44 unless it's crtitical
<pstolowski> mvo: tests/main/parallel-install-remove-after/task.yaml missing in 7951 if that helps
<mvo> abeato: sure, one sec
<mvo> pstolowski: I just checked, it seems like this test does not yet exist in 2.43
<pstolowski> mvo: good
<mvo> abeato: https://github.com/snapcore/snapd/pull/7950 and there is one more needed AIUI
<mup> PR #7950: overlord/snapstate: tracks are now sticky <Created by chipaca> <https://github.com/snapcore/snapd/pull/7950>
<abeato> mvo, thanks - and no, not critical for the moment, but we plan to use the feature from some snaps when available
<abeato> s/from/for/
<mvo> abeato: ack
<mup> PR snapd#7951 closed: tests: use test-snapd-sh snap instead of test-snapd-tools - Part 3 (2.43) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7951>
<zyga> I think https://forum.snapcraft.io/t/snap-layouts/7207/37?u=zyga should be split into a separate thread
<zyga> it's less about layouts and more about troubleshooting snapcraft and containers
<jamesh> mvo: do you think there is any interest in adopting the Github action I wrote as an official project?
<Chipaca> zyga: I can do that
<Chipaca> zyga: tell me what to do tho :-)
<zyga> thank you Chipaca :)
<Chipaca> zyga: is it all following?
<zyga> Chipaca: split it after the first message where the reporter is debugging snapcraft
<zyga> I think so
<zyga> based on my quick reading
<Chipaca> zyga: ok. SUggestions for title of the new thread?
<zyga> hmmm
<zyga> Building with snapcraft in docker?
<zyga> brb
<zyga> I was about to go upstairs for tea
<Chipaca> upstairs-tea sounds fancy
<mvo> jamesh: in a meeting right now, I will get back to you. do you have a link with more information?
<Chipaca> zyga: https://forum.snapcraft.io/t/building-with-snapcraft-in-docker/14946
<jamesh> mvo: https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930
<zyga> Chipaca: thank you :)
<zyga> jamesh: hey, happy new year :)
<jamesh> hi zyga
<Chipaca> jamesh: that's probably more a sergiusens Q than an mvo Q
<Chipaca> jamesh: unless mvo is becoming our Ã¼ber-manager
 * Chipaca mangles languages for fun and/or profit
<zyga> Chipaca: we have a cat now
<jamesh> Chipaca: I wasn't quite sure who was in charge of projects under the "snapcore" org
<zyga> Chipaca: it wandered in when it was cold and doesn't want to leave
<Chipaca> jamesh: it might still be our CTO
<Chipaca> zyga: we have developers like that also
<zyga> hahaha
<Chipaca> jamesh: in any case mvo is in a better place to help than I am :-)
<Chipaca> also he's awake, which is an advantage over sergiusens
<Chipaca> (sergiusens might be technically awake but given it's 6am for him, I wouldn't trust it)
<Chipaca> sdhd-sascha: duuude
<Chipaca> sdhd-sascha: what do you mean they are not optional
<Chipaca> sdhd-sascha: I'm telling you they are optional
<Chipaca> I'm not asking :)
<Chipaca> sdhd-sascha: most people don't even know 'list' can take positional arguments
<sdhd-sascha> Chipaca: oh, sorry. Good morning ;-)
<Chipaca> sdhd-sascha: non-required is the default
<sdhd-sascha> Chipaca: i look further. Because i never worked with reflection in golang, did you know where the tags behind the arguments are parsed?
<Chipaca> sdhd-sascha: https://godoc.org/github.com/jessevdk/go-flags
<Chipaca> sdhd-sascha: it sounds like you're digging too deep for what you're wanting to do
<Chipaca> which is alright, if you intend to learn a lot from it
<Chipaca> if you're wanting to get things done, then you've gone too far -- if it's educational you're doing great :-D
<sdhd-sascha> Chipaca: you are right. Often i'm annoyed to have asked a question shortly after. Because the answer was obvious. I want to improve myself there.
<sdhd-sascha> I can postpone learning that later. Most of the things in go are very simple - only my memory is sometimes not persistent enough ...
<Chipaca> heh
<Chipaca> sdhd-sascha: BTW, don't make it a string
<Chipaca> use a flags.Filename
<mvo> jamesh: back from the meeting, reading your post now, I need to check if I have enough privs to enable github actions
<jamesh> mvo: this is more about where to host the repo.  My action is usable by anyone right now, but I don't know if we'd want to be recommending people create workflows referencing "jhenstridge/snapcraft-build-action@v1"
<Chipaca> jamesh: flashbacks of jhbuild
<jamesh> Chipaca: jhbuild was hosted in a CVS repo that any GNOME dev could commit to
<Chipaca> jamesh: I meant about having your name immortalised in the build recipes :)
<Chipaca> the way those things are cargo-culted, it's never going away :D
<jamesh> Chipaca: I guess I could add other contributors to the repo under my personal user account, but I'm not sure that's the best way forward
<Chipaca> agreed, i think snapcore would be a better place
<Chipaca> jamesh: mvo: FWIW I can create the repository if there's agreement (mvo can also do so)
<zyga> mborzecki: help me out
<Chipaca> jamesh: you might be able to too, dunno
<zyga> mborzecki: I just don't get it and I must be missing something utterly obvious
<Chipaca> jamesh: https://github.com/organizations/snapcore/repositories/new
<mborzecki> zyga: hmm?
<zyga> mborzecki: I have a .c file that uses O_PATH, I defined _GNU_SOURCE, I included the required files
<zyga> yet it's not defined
<zyga> what could I be missing?
<jamesh> Chipaca: I don't have that permission, and if I did I wouldn't want to use it unilaterally
<Chipaca> jamesh: with you on that
<mborzecki> zyga: defined _GNU_SOURCE too late? canyou pass it to gcc -D_GNU_SOURCE?
<zyga> it's on the first line in the .c file
<Chipaca> zyga: mborzecki: what's O_PATH got to do with _GNU_SOURCE?
<zyga> Chipaca: you have to get it to get the other
<zyga> Chipaca: it's a linux thing
<zyga> Chipaca: so the headers don't give it unless you ask for it
<mborzecki> Chipaca: manpage says _GNU_SOURCE must be defined for O_PATH
<Chipaca> ah
<Chipaca> zyga: how are you defining it?
<jamesh> If you're building with e.g. -std=c18, it disables some non-standard features from headers by default
<zyga> Chipaca: I tried #define _GNU_SOURCE in the 1st line in .c
<jamesh> unless you define _GNU_SOURCE
<zyga> Chipaca: tried -D_GNU_SOURCE just now
<zyga> it's odd
<zyga> with -D_GNU_SOURCE it compiles
<zyga> with this and the #define it says it's already defined
<zyga> but without -D_GNU_SOURCE it doesn't define O_PATH
<zyga> what am I missing:
 * zyga rechecks
<Chipaca> zyga: did you read what james said?
<zyga> Chipaca: yeah but I do define it, that's the point
<zyga> Chipaca: I'm not building with std=c18
<Chipaca> zyga: fwiw both work here (on 16.04)
<zyga> and it finds it in other .c files
 * zyga must be missing something
<zyga> I'm using it in every other file we have
<zyga> doh
<zyga> I get it
<zyga> I misread
<zyga> thanks guys!
<Chipaca> zyga: maybe you wrote Î_Î¡ÐÎ¤Ð instead of O_PATH
<zyga> it's -test.c that combines .c and .h that didn't work
<zyga> the .c file built fine
<Chipaca> heh
<Chipaca> zyga: (that was omicron, under, rho, cyrillic a, tau, cyrillic en)
<zyga> hahaha
<zyga> nice
<zyga> I'm happy C is so old-school
<jamesh> modern C supports unicode identifiers
<zyga> jamesh: we are doomed then ;)
<Chipaca> zyga: but now you can have O_Pá´á´Ê!
<jamesh> using small caps makes your code less shouty
<zyga> Chipaca: I won't be satisfied until C allows ansi-escape codes in identifiers so that we can call all variables var just with varying colors
<Chipaca> zyga: and D_ðð¢ð­ð¯ð¢ð ðð±ð¢ð¡
<Chipaca> zyga: I'd be very disappointed if that didn't exist already
<Chipaca> like brainfuck but with colours
<zyga> Chipaca: cc -nyan
 * zyga gets back to work 
<jamesh> the standard lists particular code point ranges, so probably no ANSI escapes
<mup> PR snapd#7963 opened: xdgopenproxy: forward requests to the desktop portal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7963>
<mborzecki> jamesh: hi, can you take a look ^^ ?
<jamesh> mborzecki: sure!
<zyga> I was about to say the same
<zyga> interesting
<zyga> I didn't know the portal handled URLs
<mborzecki> jamesh: thanks!
<zyga> but if so let's use it :)
<jamesh> mborzecki: it's actually something I had on my todo list to investigate, so I'm very interested
<mborzecki> zyga: yeah, we can move all bugs to the portals package then :P
<zyga> at least the list will be consistent
<mvo> mborzecki: very cool stuff
<mborzecki> duh, forgot to add fixes: https://bugs.launchpad.net/snappy/+bug/1857128 in the commit message
<mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:Confirmed> <https://launchpad.net/bugs/1857128>
<mvo> can someone on fedora quickly check if "brave" installs/runs ? context is bug 1759219
<mup> Bug #1759219: Brave browser fails to launch on fedora <snapd:Triaged> <https://launchpad.net/bugs/1759219>
<zyga> mvo: checking
<zyga> mvo: last time I tried it did not but even firefox has issues
<Chipaca> it's brave, but not brave enough for fedora
 * Chipaca hides
<zyga> mvo: it actually runs
<zyga> I opened it from a terminal with "snap run brave"
<mvo> zyga: nice
<zyga> mvo: on x86_64 fedora 31
<mvo> zyga: I guess we can close this bug then :)
<zyga> mvo: I read some reports that indicate it may be different via launcher
<zyga> one sec
<zyga> let me try that
<zyga> mvo: that also worked
<zyga> I logged out to be sure
<zyga> so ... yeah
<zyga> close it
<zyga> WFM on
<zyga> snapd 2.42.2
<zyga> brb, I need a short break
<mvo> cachio: hey, good morning. just fyi - I fixed an issue with core20-spread-2, this should fix that you couldn't login anymore
<cachio> mvo, hi, yes I am checking that
<cachio> yesterday I was tryin to make that work but I couldn't
<cachio> mvo, thanks for the fix
<mvo> cachio: yeah, sorry for that, it was complicated :/ the pc gadget changed and part of the snapd code needed an update
<cachio> mvo, yes, I supposed that was something else that changed asn was affecting the uc20 boot
<cachio> I'll continue enabling tests now
<mvo> cachio: \o/ thank you
<mvo> cachio: if you could review the updated 7943, that would be great
<cachio> mvo, sure
<mvo> pedronis: how do you feel about 7963 for 2.43? a bit of risk but a really nice improvement from a UI perspective (and 2.43 will be in beta/candidate for ~2 weeks still)
<mvo> ^- (cc mborzecki )
<Chipaca> #7961 could use a second +1 (and then I'll push tests as a separate PR)
<mup> PR #7961: cmd: sign: add filename param <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7961>
<mup> PR snapd#7961 closed: cmd: sign: add filename param <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7961>
<Chipaca> mvo: tks
<mvo> Chipaca: thank you!
<mborzecki> jamesh: thanks for the feedback, i'm runnig the spread test now
<Chipaca> maybe we should thank sdhd-sascha also :-D
 * mvo hugs sdhd-sascha 
<Chipaca> tests coming up (re-running them locally just to make sure)
<sdhd-sascha> Chipaca: and i have thank you too
<mborzecki> jamesh: btw. I do not see the OpenDirectory() method in dbus api docs https://flatpak.github.io/xdg-desktop-portal/portal-docs.html#gdbus-org.freedesktop.portal.OpenURI was it dropped at some point?
<mborzecki> heh, Ping was blocked by apparmor :/
<mup> PR snapd#7950 closed: overlord/snapstate: tracks are now sticky <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7950>
<pedronis> mvo: sorry, missing something, is there a bug related to it?
<Chipaca> pedronis: yep (linked from there)
<Chipaca> pedronis: https://bugs.launchpad.net/snappy/+bug/1857128
<mup> Bug #1857128: Missing configuration option to allow a snap to openFile without prompting <Snappy:Confirmed> <https://launchpad.net/bugs/1857128>
<pedronis> ok
<pedronis> still doesn't feel like something we should add late to 2.43
<pedronis> 2.43 is big enough at it is
 * zyga goes afk 
<zyga> we managed to catch the cat
<zyga> going to the vet to see if it is chipped
<mup> PR snapd#7964 opened: tests/main/snap-sign: add test for non-stdin signing <Created by chipaca> <https://github.com/snapcore/snapd/pull/7964>
<mup> PR snapd#7935 closed: boot,overlord: introduce internal abstraction bootState and use it for InUse/GetCurrentBoot <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7935>
<pedronis> Chipaca: I rebase and force pushed 7937 but your +1 didn't have any punctual comments so shouldn't be too much of a problem. I didn't change anything in the commits of that PR itself
<Chipaca> tsk, tsk
<Chipaca> :)
<Chipaca> pedronis: I reviewed the delta, anyway
<Chipaca> opensuse is a mystery to me -- https://forum.snapcraft.io/t/opensuse-snap-repository-missing-primary-xml-gz-file/14951
<mborzecki> zyga: ^^ something you need to poke obs for?
<mborzecki> zyga: though it'd expect the repo setup to be automatic
 * Chipaca hunts for lunch
<zyga> In a moment
<pedronis> mborzecki: mvo: I made a review pass on #7947 with some suggestions
<mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
<zyga> Back home, Iâll be in the office in a minute
<zyga> snapcraft.io is down?
<zyga> or rather, the forum is down
<roadmr> zyga: it's being worked on :)
<roadmr> (yes it's down)
<zyga> cool, thank you Daniel :)
<roadmr> ð
<cachio> mvo, hey, do you know if the snapd.snap-repair.timer should be active in uc20?
<mvo> pedronis: thanks
<mvo> cachio: it should, sounds like a bug if it's not
<cachio> mvo, good
<mvo> cachio: I think I know what the issue is, will push a fix in a wee bit
<zyga> niemeyer: hello
<zyga> niemeyer: happy new year :)
<zyga> niemeyer: could you please let me know when would be a good time to chat/call about the output of snap run --explain?
<zyga> niemeyer: it doesn't have to be now, just wanted to plan something for the week
<Chipaca> zyga: if you cat is chipped, call it 'fish'
<zyga> Chipaca: I think after calling the dog Bit my wife will have some opinions on animal names :)
<zyga> Chipaca: she was not happy about the name "edge"
<zyga> as in "edges and nodes'
<zyga> graphs and all that
<degville> forum is back up.
<Chipaca> zyga: cat is part of coreutils
<Chipaca> zyga: jus' sayin'
<ogra> you called the dog bit ? you should really have called it byte !
<Chipaca> ogra: it's a really small dog
<Chipaca> ogra: you need for of them to even nibble
<zyga> yeah
<zyga> *exactly* :D
<zyga> brb, lunch and tea
<ogra> even chihuahuas can cause bad ankles ;)
<ogra> oh, the forum seems back \o/
<mup> PR snapd#7952 closed: snap-bootstrap: trigger udev after filesystem creation <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7952>
<vidal72[m]> I just saw wierd glitch: firefox suddenly got downgraded to 68esr, after snap refresh it went back to 71
<vidal72[m]> fat finger at mozilla?
<niemeyer> zyga: Heya
<niemeyer> zyga: Tomorrow afternoon would be nice as there are plenty of meetings already
<zyga> sounds great
<zyga> at around 14:00 ?
<zyga> I'll ping you in the afternoon to see when it will work perhaps
<cachio> mvo, I see the state.json file does not contain the last-refresh-hints value
<cachio> is it intentional?
<mup> PR snapcraft#2740 closed: crystal plugin: add flags to use during shards build <Created by mamantoha> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2740>
 * zyga goes for lunch
<mvo> cachio: that's a good question - in uc20?
<cachio> yes
<mvo> cachio: hm, that should work, maybe something network related is not quite right, I did not expect this to break, interessting!
<cachio> mvo, all the refreshes are failing btw
<mvo> cachio: aha, interessting - anything in the logs that might give us a hint?
<cachio> mvo, the only error I see is this https://paste.ubuntu.com/p/Rk4CfZdPpk/
<sdhd-sascha> Chipaca: do i see that correctly? `snap prepare-image` has no option to for local kernel and/or gadget ?
<cachio> I think refresh is not done when serial cannot be set
<Chipaca> sdhd-sascha: --snap=....?
<cachio> mvo, in that case it should automatically be fixed once we have the actual model, right?
<pedronis> cachio: to be precise, if we cannot get a serial we will refresh but only after some tentatives
<sdhd-sascha> Chipaca: thank you, i will try it later
<Chipaca> sdhd-sascha: but in general 'snap prepare-image' isn't something you yourself call directly
<cachio> pedronis, ah, ok, and is there any workaround for that?
<pedronis> not really
<pedronis> it's the expected behavior if the model doesn't let us get a serial
<pedronis> in the future the latter will be easier
<pedronis> but not atm
<cachio> pedronis, ok, I'll skip those tests in that case
<pedronis> cachio: you can set something in the state if you really want but not sure it's worth it or it
<cachio> for uc20
<sdhd-sascha> Chipaca: i have called it directly, like ubuntu-image it does. To see better understand
<cachio> pedronis, do what?
<cachio> set manually the time fot the refresh?
<pedronis> no, actually is internal state of snapd
<pedronis> at runtime
<pedronis> so the only way would be a debug command
<pedronis> a new debug command
<sdhd-sascha> `snap prepare-image --channel=beta rock.model /tmp/tmpzojkf7e2/unpack`
<cachio> pedronis, ah, ok, it is already implemented?
<pedronis> no
<cachio> pedronis, ok, np
<pedronis> cachio: mvo: if we have a problems with the model we should fix it
<mvo> pedronis: yeah, irrc we have no grade: dangerous official model and there was the question if we should have that or not
<pedronis> mvo: for a while it sounded like we should have only a dangerous model, but then we went the other way around
<pedronis> mvo: we probably need one though,  because even if we allow to set channels for signed models
<pedronis> it still not enough for our tests I suppose
<pedronis> I mean the spread tests
<pedronis> mvo: something to talk about with foundations
 * mvo nods
<pedronis> mvo: but I'm missing something we use a self signed image also for core18
<pedronis> what's the difference?
<mvo> pedronis: I think we just ignore the registration errors in the spread test
 * mvo is also in a meeting
<pedronis> ah, no
<pedronis> we use the real model
<pedronis> (we just have a copy in-tree)
 * cachio lunch
<om26er> How to know if a snap name is already taken without a name registration attempt ?
<zyga> om26er: hmm, I don't think there's a way
<ogra> well, you can surely check if a snap has been uploaded under that name by simply searching the store ... but not if the name has been claimed without any uploaded package
<om26er> yeah in some cases people just "claim" the name but never upload anything
<ogra> right, in that case you can only try to claim it yourself and wait for the resolution i guess
<ogra> note also that most .deb package names are auto-blocked without an actual person having claimed them
<ogra> (to avoid peope from just grabbing such names)
<mup> PR snapd#7964 closed: tests/main/snap-sign: add test for non-stdin signing <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7964>
<Chipaca> mvo: pstolowski: thanks for the reviews
<pstolowski> yw
<mvo> my pleasure
<cachio> mvo, I see the permissions for the snaps on /var/lib/snapd/seed/snaps/ are 0700 instead of 0600
<cachio> mvo, on uc20
<zyga> one more test run
<zyga> then commit, push and EOD
<zyga> or maybe that and one more fixup to another PR
<ijohnson> pedronis: I assume that #7939 is based on top of #7937, correct?
<mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
<mup> PR #7937: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7937>
<ijohnson> pedronis: 7937 has 2 +1's also shall I merge 7939 and then merge master into 7937? that would make the diff easier to review I think
<zyga> this gid handling is such a rabbit hole
<zyga> as soon as it passes I'll EOD, patches tomorrow
<zyga> I need to split them,
 * zyga gives up
<zyga> ttyl
 * Chipaca EODs
<Facu> Hello! From any given snap, how can I tell which "start points" or "scripts" it installed? like, for example installing `foobar` but to run it I need to do `foo`
<zyga> Facu: snap info --verbose foovar
<zyga> it will tell you about the commands that are defined for that snap
<zyga> Facu: you can also run "snap aliases" to see if any commands are aliased as other commands
<Facu> zyga, under which title? I'm trying with `snap info --verbose mosaic`
<zyga> Facu: some snaps come with aliases out of the box
<zyga> Facu: look for "commands" in the output of snap info --verbose
<Facu> zyga, and if no commands at all?
<zyga> then you probably have not installed it
<zyga> the output of info varies if the snap is installed or not
<zyga> for me it printed: commands (newline) - mosaic
<Facu> zyga, oh, thanks!
<zyga> good luck :)
 * zyga runs upstairs to do homework with kids
<mup> PR snapd#7937 closed: boot,o/snapstate: SetNextBoot/LinkSnap return whether to reboot, use the information <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7937>
<pedronis> #7939 is ready for review (I merged master into it)
<mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
<ijohnson> thanks pedronis, will review this afternoon
<mvo> cachio: aha, interessting, I wonder why this is
<mvo> cachio: does the changed permissions make a test fail?
<cachio> mvo, yes
<cachio> mvo, install-sideload test
<cachio> mvo, also something interesting is snap set core proxy.https=http://localhost:3128
<cachio> error: cannot perform the following tasks:
<cachio> - Run configure hook of "core" snap (run hook "configure": open /etc/environment: read-only file system)
<mvo> cachio: aha, nice
<cachio> I am writing all the findings in the standup doc
<mvo> cachio: the /etc/environment sounds like a potentially low-hanging fruit
<cachio> mvo, yes
<mvo> cachio: the dir permission too, it's just a bit annoying to track down where it is set incorrectly :)
<cachio> and it breaks more than 1 test
<cachio> mvo, if you push a fix just tell me so I can merge it with my branch
<mvo> cachio: cool, will probably look into it tomorrow
<cachio> mvo, nice, thanks
<mvo> cachio: thank you for all these findings!
<cachio> mvo, yaw
<mup> PR snapcraft#2853 opened: meta: do not set snapcraft-runner when adapter is "none" <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2853>
<mup> PR snapcraft#2836 closed: meta: fix command-chain handling when Application adapter == "none" <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2836>
 * ijohnson takes a break
<mup> PR snapd#7965 opened: tests: enabling main and regression test suites for core20 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7965>
<mup> PR snapcraft#2850 closed: hooks: enable command-chain <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2850>
<mup> PR snapcraft#2846 closed: base plugin: use shlex quoting for logged command in run() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2846>
<sdhd-sascha> Today I started to build my first snap command. I have copied the cmd_sign.go. Then I fell into shock-freeze. All definitions and functions of a command are visible in the complete main scope?! What if i misspell the Execute function, or something else?
#snappy 2020-01-08
<ijohnson> sdhd-sascha: that's expected since if you copy cmd_sign.go to cmd_foo.go, then you're really just adding a `snap foo` command rather than a new command like `foo bar`
<ijohnson> sdhd-sascha: as for what if you misspell something that's what code review is for :-)
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: good morning!
<zyga> good morning!
<mvo> zyga: good morning
<zyga> just finishing my morning sandwich here
<zyga> how are you guys?
<zyga> I spent most of yesterday afternoon debugging issues related to gid dropping
<zyga> (so snap-confine can stop being setgid root)
<zyga> found a few things after sorting out the initial wave of mkdir problems
<zyga> the spread test that finds wrong permissions on directories and files was invaluable
<mvo> zyga: nice
<zyga> one issue still remains, in snap-update-ns, it also creates some files
<zyga> oh well :)
<zyga> but today I should get through all of that
<mvo> zyga: cool! I'm cleaning up boring spread tests :)
<zyga> great
<zyga> updating them to current standards?
<mvo> zyga: nah, just updating the uc20 test so that it gets pass the review feedback :)
<zyga> I see :)
<zyga> well, not anywhere less noble :D
<sdhd-sascha> good morning
<zyga> hey sdhd-sascha, how are you doing?
<mborzecki> zyga: 'standards'?
<zyga> mborzecki: some tests are really quaint
<zyga> the older the more likely you would rewrite it just after looking at it
<mborzecki> hah i can imagine
<sdhd-sascha> zyga: i'm fine. thank you :-) Hope you, too
<mborzecki> something not right with apparmor spec in the desktop interface
<mborzecki> Jan 08 07:35:17 jan080727-593014 dbus-daemon[18726]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/freedesktop/portal/desktop" interface="org.freedesktop.portal.OpenURI" member="OpenURI" mask="send" name="org.freedesktop.portal.Desktop" pid=18835 label="snap.test-snapd-desktop.cmd"
<zyga> mborzecki: did you change anything or can I just look at master?
<zyga> mborzecki: (to look at the rules)
<mborzecki> zyga: master is fine
<zyga> huh
<zyga> so
<mborzecki> zyga: i mean looking at the code in master is fine, not that it works on master ;) the relevant bit https://github.com/snapcore/snapd/blob/master/interfaces/builtin/desktop.go#L189-L194
<zyga> I wonder if this works at all
<zyga> notice that we don't say member=...
<zyga> maybe that means member=""
<zyga> try adding that
<zyga> member=OpenURI
<zyga> and if this fixes it let's look at what else needs to be there
<zyga> mborzecki: also check the confinement on the portal
<zyga> maybe, by chance, it has a non-snap apparmor label
<mborzecki> zyga: portal didn't even start, the request got blocked earlier
<zyga> mborzecki: can you check that the relevant rule is really there in the apparmor profile?
<mborzecki> zyga: unfortunately the rule is in the profile :/
<zyga> hmm
<zyga> so
<zyga> I wonder if this is this:
<zyga>     path=/org/freedesktop/portal/{desktop,documents}{,/**}
<zyga> this can expand to path=/org/freedesktop/portal/desktop/**
<mborzecki> zyga: as i udnersdtand, not specifying a member means to allow all members of the interface
<zyga> what if that doesn't match /org/freedesktop/portal/desktop
<zyga> mborzecki: try changing that regexp
<zyga> mborzecki: to say path=...{,/,/**}
<zyga> though perhaps I'm wrong
<zyga> because it would probably match the plain expansion
<zyga> without /**
<mborzecki> hmm we have other spread tests for portals too and those are passing afaik, wonder what makes this one special
<zyga> mborzecki: are you testing interactively or is there a spread test?
<zyga> mborzecki: ha
<zyga> mborzecki: one more idea
<zyga> is this really true?
<zyga> interface="org.freedesktop.portal.OpenURI"
<mborzecki> zyga: spread test for snapctl user-open going to a desktop-portal rather than snap userd
<zyga> is the interface really interface="org.freedesktop.portal.OpenURI"
<zyga> or is OpenURI the method now (member)
<zyga> if so the expression won't cover it
<zyga> it requires portal.*
<mborzecki> zyga: we have interface=org.freedesktop.portal.*
<zyga> right
<zyga> but what if the audit message is not really what it seems
<zyga> I would say that the interface is org.freedesktop.portal - full stop there
<zyga> and the member is OpenURI
<zyga> see what I mean?
<zyga> interface="org.freedesktop.portal.OpenURI"
<zyga> er
<zyga> https://www.irccloud.com/pastebin/As3p4zI1/
<mborzecki> Jan 08 07:58:31 jan080727-593014 dbus-daemon[18726]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/org/freedesktop/portal/desktop" interface="org.freedesktop.portal.OpenURI" member="OpenFile" mask="send" name="org.freedesktop.portal.Desktop" pid=19338 label="snap.test-snapd-desktop.cmd"
<zyga> try this
<mborzecki> opening a file gets blocked too :/
<zyga> is this on arch?
<mborzecki> 19.10
<jamesh> zyga: there are multiple interfaces under org.freedesktop.portal
<zyga> jamesh: hey :-)
<zyga> jamesh: do you know if the OpenURI method is on the interface called OpenURI
<jamesh> zyga: yes.  It is an OpenURI method on the o.f.p.OpenURI interface
<zyga> aha
<zyga> in that case I have no idea why there is a denial
<pstolowski> mornings. i need to run an errand, will start for real a bit later (in ~1h)
<zyga> good morning Pawel
<mup> PR core-build#58 opened: initramfs: add neccessary modules for rockchip emmc and sdcard <Created by JeffyCN> <https://github.com/snapcore/core-build/pull/58>
<jamesh> mborzecki: one idea: does it work if you manually start xdg-desktop-portal from outside of confinement first?
<jamesh> I'm wondering if this is a "missing AssumedAppArmorLabel" problem
<zyga> mmmm
<zyga> good hunch
<mborzecki> jamesh: good catch, yeah, it's different now, not getting blocked
<zyga> ha
<zyga> I wonder if we didn't notice that before
<zyga> because snap run activates one of the portals on startup
<zyga> so it would be activated by an unconfined program
<jamesh> I am surprised we aren't hitting that denial in the other desktop-portal-* tests
<jamesh> I don't see anything that would start it before hand
<mborzecki> jamesh: not entirely sure, but test-snapd-portal-client activated the portal, but doing the same via xdg-open gets blocked
<jamesh> mborzecki: the problem is that we don't know the AppArmor label xdg-desktop-portal will run with prior to it starting.  So the AppArmor rule allowing communication with peer=(label=unconfined) doesn't match
<jamesh> mborzecki: are the interface plugs of test-snapd-portal-client different to whatever snap you're using to call xdg-open?
<mborzecki> jdstrand: nope, they're the same, only desktop plug
<mborzecki> jamesh: ^^
<jamesh> mborzecki: is there any difference in the order of operations in preparing the test?
<zyga> mborzecki: which other portal test passes?
<jamesh> zyga: tests/main/desktop-portal-*
<zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap/cmd_run.go#L691
<mborzecki> zyga: that's document portal
<zyga> those tests are interesting
<zyga> they set up fake portals up front
<zyga> so the portal is never activated
 * zyga checks to be sure
<zyga> I take that back
<zyga> the portal is fake
<jamesh> if xdg-document-portal causes xdg-desktop-portal to start, then we wouldn't hit the activation problem
<zyga> but seems to be activated
<jamesh> hmm.  If portalsUnavailableFile has leaked from a previous test using the snap in mborzecki's test, then we might not try to start the document portal
<zyga> where is that file stored?
<jamesh> nothing outside of the desktop-portal-* tests use test-snapd-portal-client
<jamesh> it would be $XDG_RUNTIME_DIR/snap.$SNAP_NAME/.portals-unavailable
<zyga> I doubt we clean that up
<zyga> perhaps we ought to
<jamesh> and that would be XDG_RUNTIME_DIR for  uid 1000
<mborzecki> jamesh: don't think it's the cause, i stop the deskto portal, then run test-snapd-portal-client open-uri and it gets activated, but doing the same with test-snapd-desktop.cmd xdg-oopen gets blocked
<jamesh> uid 1234, even
<mup> PR snapd#7943 closed: tests: add core20 tests <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7943>
<sdhd-sascha> zyga: hey, what are you testing. And how can i reproduce it? Seems to be interresting for wayland-server snaps too
<jamesh> mborzecki: does /run/user/1234/snap.test-snapd-desktop/.portals-unavailable exist?
<zyga> sdhd-sascha: it's mborzecki, not me
<zyga> sdhd-sascha: xdg portals and some apparmor interactions
<sdhd-sascha> i see, is `test-snapd-desktop` in the store?
<sdhd-sascha> or, in the tests?
<mborzecki> jamesh: nope
<zyga> sdhd-sascha: most of the snaps are in the snapd repo
<jamesh> zyga: also: the tests are running against the real xdg-desktop-portal service: they're just faking the UI service that the snap doesn't communicate with
<zyga> and only some are in the store, usually if they 1) require compilation 2) require being from the store
<zyga> jamesh: I see
<sdhd-sascha> Can i ask, if we could merge this #7927 ?
<mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
<pstolowski> re
<zyga> aha
<zyga> I know what fails now
<zyga> man
<zyga> such a complex sooup
<zyga> soup
<mborzecki> jamesh: so it looks to me that the python dbus client actually starts the service https://paste.ubuntu.com/p/42ZWnBHwxN/
<mborzecki> jamesh: looking at apparmor profile, sending org.freedesktop.DBus.StartServiceByName is allowed via included dbus-session-strict abstraction
<jamesh> mborzecki: interesting.  That kind of makes the whole AssumedAppArmorLabel thing a bit pointless if you can arbitrarily start services anyway
<mborzecki> jamesh: i've updated #7963, the spread test will fail atm until we figure out what's wrong
<mup> PR #7963: xdgopenproxy: forward requests to the desktop portal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7963>
<jamesh> cool.  I'll have a look
<zyga> brb
<zyga> re
<zyga> sdhd-sascha: it needs to be reviewed by jamie
<zyga> and after xmas break we have a larger backlog of things to catch up with
<zyga> expect maybe mid next week
<zyga> perhaps earlier but I cannot speak for jamie's timetable
<sdhd-sascha> zyga: it's not urgent. just saw the many PRs and thought this one, could be simple
<zyga> sdhd-sascha: anything involving interfaces is tricky and needs to have a review from jamie
<sdhd-sascha> ok
<mvo> 7953 needs a second review (and is pretty trivial now)
<zyga> let me look quicky
<zyga> I resolved my blocker and now need to just code the solution
<zyga> so good time to switch gears for a second
<zyga> mvo: is that the right number? it has two +1s already
<zyga> mvo: the commit and service name don't match
<zyga> mvo: personally I prefer the shorter name (snapd.spread-tweaks.service)
<zyga> mvo: but I think it's fine to just change the commit message to talk about snapd.spread-tests-run-mode-tweaks.service
<zyga> mvo: I hope this makes sense
<mvo> zyga: indeed, nice catch
<mvo> zyga: thanks, I overlooked it had a second +1 already, silly me
<mup> PR snapd#7962 closed: tests: cherry-pick fixes for  snap-set-core-config/ubuntu-core-config-defaults-once <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7962>
<mborzecki> interesting but unrelated to 7953 https://paste.ubuntu.com/p/XG8tpZcG3s/
<zyga> mborzecki: I saw that a number of times
<zyga> at random
<zyga> feels like something is racy
<zyga> break
<mup> PR core20#19 opened: static: add /etc/environment to writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/19>
<mborzecki> cmatsuoka: hi, there were some conflicts in https://github.com/snapcore/snapd/pull/7958 i've merged master and pushed, can you double check it looks ok?
<mup> PR #7958: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
<cmatsuoka> mborzecki: thanks, checking...
<mvo> ijohnson: hey, you asked about docker-smoke failing on uc20 the other day - here is the full log https://paste.ubuntu.com/p/Z2JStRP6sw/
 * zyga takes the dog out 
<zyga> ttyl
<cmatsuoka> mborzecki: it's good, thanks for resolving the conflict
<mborzecki> cmatsuoka: cool, hope the travis job will be green :)
<mup> PR snapd#7953 closed: tests: use new snapd.spread-tests-run-mode-tweaks.service unit <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7953>
<zyga> back
<mup> PR snapd#7966 opened: tests: first core20 test fixes <Created by mvo5> <https://github.com/snapcore/snapd/pull/7966>
<cachio> Saviq, hey
<cachio> I am trying to create some snaps with base: core20
<cachio> and I am getting this error related to multipass
<cachio> launch failed: Unable to find an image matching "core20"
<Saviq> cachio: there wasn't a build environment for them last year ;)
<cachio> any idea about when that image will be published or if is there any workaround for that?
<cachio> ll
<cachio> Saviq, any idea when it should be ready?
<Saviq> sergiusens: got any pointers for cachio ^? Is there an image yet that we could hook up to core20 builds?
<Saviq> cachio: you could try launching daily:20.04 named snapcraft-<yourproject>, but there's some setup you might need
<Saviq> That, or upgrade the one snapcraft launches for you
<cachio> Saviq, ok, I'll try that, thanks!!
<mborzecki> cachio: hi, do we have regular updates of centos spread images?
<cachio> mborzecki, yes
<cachio> weekly
<cachio> mborzecki, this is the last one 2 days ago
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/633276566
<mborzecki> cachio: thanks, i was hoping some updates for systemd landed, but apaprently not
<cachio> mborzecki, long time waiting for that landing :(
<sergiusens> cachio: Saviq build-base is what you could use
<Saviq> sergiusens: but that would only accept "core18" and "core16", right?
<Saviq> I'm thinking we could have a Multipass branch that does have "snapcraft:core20"
<sergiusens> Saviq: yes, but even if you provide a core20 base quickly for multipass our plugins would need to gain support for core20
<sergiusens> Saviq: which is a task I am going to start next Monday
<Saviq> sergiusens: ack, let me know if we can help
<Saviq> I'll bake a Multipass that has a core20 pointing somewhere sane-ish
<sergiusens> Saviq: if you add it to "mainline" multipass no harm should be done since snaps built with it will be marked grade devel
<Saviq> sergiusens: yeah but it would suggest it's something real, which it's not atm :)
<pedronis> mvo: when #7939 is green it can be landed, reminder about #7947 needing a pass from you
<mup> PR #7939: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7939>
<mup> PR #7947: boot/many: support new UC20 style kernel extraction <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
<sdhd-sascha> somewhere, i had a patch for meson and core20. Don't know why i have closed the PR 2797
<mup> PR #2797: tests: stop tying setting up staging store access to the setup of the state tarball <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2797>
<sdhd-sascha> i will recreate that PR. It was easy for meson to enable the plugin on core20
 * zyga fires spread, hoping to see some progress
<sdhd-sascha> i found my private changes - but i there is sure some refactor needed https://github.com/snapcore/snapcraft/pull/2854/commits
<mup> PR snapcraft#2854: Core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2854>
<mup> PR snapcraft#2854 opened: Core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2854>
<mup> PR snapd#7958 closed: snap-bootstrap: refactor partition creation <UC20> <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7958>
<sdhd-sascha> zyga: "fires spread" - i didn't understand the context
<zyga> niemeyer: hey, I'm sorry I haven't pinged you yet - still working on uid/gid bug
<zyga> niemeyer: not sure how your day looks like with regards to meetings, I'll have the standup in half an hour
<zyga> niemeyer: after that I'm free, we can quickly chat about snap run --explain either now or after if you have the time for that today
<zyga> sdhd-sascha: as in run spread tests
<zyga> sdhd-sascha: I'm chasing an annoying fix that takes some time to code right
<sdhd-sascha> zyga: yeah - there i have to check if my local spread is working. Without time, i like to use my github repo and my patches for that ;-)
<zyga> sdhd-sascha: I develop locally for most of the time but I run a specific set of tests to see if my understanding of the code matches reality
<sdhd-sascha> zyga: yeah, i want to test locally too. But currently dive into so many git-repo's to understand Xwayland, ubuntu-image, ... And my wife... So i have still a todo on setting up the spread locally. (I know it's started last year, but it was so slow, so that i abort it before all tests was run...)
<zyga> sdhd-sascha: my recommendation would be to start with small test that you can run via spread
<zyga> sdhd-sascha: even if that test needs to pull snaps from the store or from other places
<zyga> sdhd-sascha: this allows you to have some kind of reproducibility
<zyga> sdhd-sascha: so you can be more sure about changes than "it worked on my $complex_local_setup yesterday"
<sdhd-sascha> yes
<zyga> brb, so cold, need to get something warm
<zyga> see you at the standup
<ijohnson> morning folks
<zyga> hey Ian, how are you doing!
<zyga> I miss snow, did you get any this winter?
<niemeyer> zyga: I should be free around 4 UTC
<mup> PR snapd#7967 opened: overlord/snapstate: improve snapd snap backend link unit tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7967>
<mborzecki> cachio: do you have a debug shell to a node with arch image by any chance?
<abeato> sergiusens, hi! I was wondering, is there a way to stage packages for a snap without the dependencies? (that is, to strictly stage only what is specified in stage-packages)
<mup> PR snapcraft#2855 opened: project: remove unused errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2855>
<sdhd-sascha> Hey, if someone is interested. I found why "ubuntu-image" always create a too small rootfs-partition on my system. https://github.com/CanonicalLtd/ubuntu-image/pull/182
<mup> PR CanonicalLtd/ubuntu-image#182: rootfs: sync before measure size <Created by sd-hd> <https://github.com/CanonicalLtd/ubuntu-image/pull/182>
<cachio> mborzecki, no
<cachio> mborzecki, this is the erro https://travis-ci.org/snapcore/spread-cron/builds/633276548#L1446
<mup> PR snapcraft#2855 closed: project: remove unused errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2855>
<mborzecki> cachio: heh, so there's some changes in keys apparently, and it looks like the prompt doesn't work too well when input is not a tty
<zyga> cachio: please ping me later about that machine state checker from before the break
<Chipaca> mvo, degville: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970
<zyga> I completely forgot about it but I did work on it a bit more to get to the point where it can ship a standalone version
<cachio> zyga, sure
<mborzecki> cachio: hm weird, i have pacman -Syu in spread prepare section for arch, and got a shell just fine, so an update must have been applied without problems
<mup> PR snapcraft#2852 closed: wstool: don't rely on host git <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2852>
<pedronis> Chipaca: mvo: also it seemed you didn't want to ship snap known --remote using snapd but not download, but that's the state in 2.43 I think, no?
<cachio> mborzecki, this is the file which we use to update arch https://github.com/snapcore/spread-images/blob/master/tasks/google/update-arch-linux/task.yaml
<cachio> mborzecki, could be caused by pacman-key --populate ??
<mup> PR snapcraft#2842 closed: rust: add support for workspaces <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2842>
<mup> PR snapcraft#2845 closed: remote-build: configurable timeout/deadline for starting and monitoring build <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2845>
<mup> PR snapcraft#2767 closed: rust plugin: add rustup profile <Created by dalance> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2767>
<mborzecki> cachio: hm i've never used it
<mborzecki> cachio: what's the starting image that you use?
<cachio> mborzecki, an old one
<cachio> mborzecki, it is called arch-linux-64-base
<cachio> mborzecki, I update it every 6 months aprox
<mborzecki> cachio: ok, so the keys that are there may have expired
<cachio> mborzecki, ok, I'll update the base image and try again
<mborzecki> cachio: reading the manpage, --populate reloads the keys from keyring, but if those are expired, you still end up with outdated keys?
<mvo> pedronis: uh, indeed
<cachio> mborzecki, ah
<mborzecki> cachio: could use just use the current image as base and update that to become the next snapshot?
<cachio> mborzecki, well, I try to dont do it  because our current image has a lot a packages installed
<cachio> I think best solution is to update weekly the base image
<cachio> does it make sense?
<cachio> currently we are updating the images using the bases
<cachio> so, perhaps we should update the base image and then the test image
<cachio> using the already updated image
<cachio> the scripts that update the base images just make update/upgrade and reboot
<cachio> the scripts that update hte test images so the same + creation Â¿/deletion of users, management of service, etc
<cachio> and install packages for snapd testing as well
<cachio> mborzecki, the errror happens when we do this pacman -Suq --needed --noconfirm git jq python2 unzip wget
<mborzecki> cachio: yeah, we should probably the base image and then the spread one using the new base
<cachio> those are dependencies that we have for spread image project to run the scripts
<cachio> mborzecki, I'll skipped those to see if it works
<cachio> mborzecki, I am going to pick my daugther, I'll be back in 20 mins
 * cachio afk
<Chipaca> mvo: should we revert the 'known' change, then?
<Chipaca> mvo: for .43 i mean
<mborzecki> cachio: got it to work
<mvo> Chipaca: yeah, I think that is sensible
<mborzecki> cachio:  https://github.com/snapcore/spread-images/pull/24
<mup> PR spread-images#24: tasks/google/update-arch-linux: update archlinux-keyring before other packages <Created by bboozzoo> <https://github.com/snapcore/spread-images/pull/24>
<pedronis> Chipaca: given how far 2.44 is atm, this feels a bit premature to me: https://forum.snapcraft.io/t/behaviour-change-sticky-and-default-tracks/14970 , not sure if it was discussed at standup
<Chipaca> pedronis: it does say TBC fwiw
<pedronis> Chipaca: I got a bit worried about you liking sparkiegeek answer about how to set it now, which is kind of too early I feel
<Chipaca> pedronis: ah
<Chipaca> pedronis: it's useful if somebody wants to play with it
<pedronis> Chipaca: anyway I clarified what will happen atm if they do that
<Chipaca> you really didn't :) but now that you gave me extra context i understand what you meant
<pedronis> Chipaca: feel free to incorporate my comment expanded at the top or something then
<pedronis> Chipaca: it should probably say that snap where this is not set will still use latest, and snapd <2.44 will still ask for latest anyway
<pedronis> zyga: mvo: I got weird failures here: https://api.travis-ci.org/v3/job/634225161/log.txt
<zyga> looking
<zyga> aha, I saw this like around 5 times maybe in total
<zyga> I was never able to reproduce this with a shell
<zyga> it seems that some of the setup, perhaps of just the test, is racy and the container runs before it can really execute
<zyga> maybe just after we install snapd the profiles are not really ready yet
<zyga> but the service is up
<zyga> as in systemd thinks we are good
<zyga> so we install a snap and that explodes
<zyga> would be good to check if the first-setup we is done before or after systemd considers us to be up
<ijohnson> pedronis: off-topic but I've seen that snapd-failover task fail before as well, I added an additional debug section to one of my PR'
<ijohnson> s to see what the issue was with that
<zyga> because if it is after then this is clearly racy in that regard
<zyga> to be precise: the setup of the snap-confine profile happens as a side effect of getting core/snapd snaps
<zyga> and snap-confine actively checks if it has a profile, this is the failure that was printed here:
<zyga> + lxd.lxc exec my-ubuntu -- su -c '/snap/bin/test-snapd-sh.sh -c '\''echo from-the-inside'\''' ubuntu
<zyga> snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks
<pedronis> zyga: we are up for systemd before we do various things
<zyga> I see
<zyga> hmm, that's not great
<zyga> but it seems that there's a 2nd depth to explore here
<zyga> because why would snap-confine from core execute
<zyga> when snap-confine is not set up yet?
<zyga> perhaps we do the switch over incorrectly
<mvo> pedronis: hm, that log does not even download for me :/
<zyga> mvo: I still have it in my browser
<zyga> I can probably copy paste it
<mvo> zyga: would be nice if you could paste relevant bits, it loads only until something like 2020-01-08 16:11:20 Executing google:ubuntu-16.04-32:tests/main/snap-run-hook:reexec1 (810/3347)... for me
<zyga> sure
<zyga> the lxd failure is
<zyga> https://pastebin.ubuntu.com/p/C5Vp8N6zMR/
<zyga> then the failover test
<zyga> https://pastebin.ubuntu.com/p/bR5pfQDxgK/
<zyga> there's one more failure but it looks like regular journal error
<zyga> I need to take a break now
<zyga> see you around chaps
<niemeyer> zyga: How're things going there?
<mup> PR snapd#7957 closed: snap-bootstrap: mount the correct snapd snap to /run/mnt/snapd <UC20> <Created by mvo5> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7957>
<mup> PR core20#19 closed: static: add /etc/environment to writable-paths <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/19>
<mup> PR snapd#7939 closed: boot,o/devicestate: refactor MarkBootSuccessful over bootState <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7939>
<zyga> niemeyer: Hey, I can have a quick call, just making coffee
<niemeyer> zyga: https://meet.google.com/nej-iory-rpy
<pedronis> ijohnson: mvo: #7940 is ready for review
<mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
<ijohnson> pedronis: ack
<mvo> pedronis: thanks, in a meetng right now, I will try to look at it
<pedronis> mvo: please if you have time do first Ian's one
 * mvo nods
<pstolowski> pedronis: hey, i've made 2nd pass over #7934, would love to land it, a few small remarks
<mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<pedronis> pstolowski: thx, I will look in my morning
<pedronis> it might be time to start a new standup document, it's using 0.5G here
<pstolowski> heh, +1
<ijohnson> mvo: pedronis: having just finished a review of #7940, I think I'm ready to start working on uc20 implementation of all that, matching what's been done for uc16, is that okay?
<mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
<ijohnson> on that topic, it feels like in bootStateFor we may need to know the model to tell if it's a grade unset model in order to figure out we should use the (as of yet non-existent) bootState20, is that logical ?
<mvo> ijohnson: sounds good to me
<zyga> niemeyer: summarized as https://github.com/snapcore/snapd/pull/7728#issuecomment-572169180
<mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
<zyga> niemeyer: thank you again :)
<mvo> cachio: I uploaded a new systemd to focal and fixed the /etc/environment not writable, so hopefully a bunch of less failures with tomorrows uc20 core edge update
<pedronis> ijohnson: yes, that's what my proposal mentions as adding a HasModeenv to boot.Device
<ijohnson> pedronis: ah okay sorry I had forgotten about that proposal
<ijohnson> sounds good!
<pedronis> ijohnson: to be clear that can be implemented in terms of checking the model
<ijohnson> right
<pedronis> zyga: the plan to have a structured output api sounds good
<zyga> I agree
<pedronis> ijohnson: that will be implemented in devicestate/devicectx.go in the end
<pedronis> plus a few test places
<ijohnson> pedronis: yep that makes a lot of sense
<ijohnson> will work on that after I finish up the tests for my kernel extraction PR
<pedronis> ijohnson: great
<pedronis> ijohnson: I answered mvo wonderined in your kernel PR, which relates to this work as well
<pedronis> *wondering
<ijohnson> pedronis: ah right I hadn't seen that mvo had reviewed the PR yet (thanks mvo!)
<ijohnson> also I am going to merge in master to this PR since the uc20 spread tests are in master now so we have those tests too
<cachio> mvo, nice, just saw the message
<pedronis> ijohnson: yes, good idea. I added another comment there about the work
<ijohnson> yes that's a good point, thanks
<pedronis> ijohnson|lunch: we might not need though, because try-kernel is really relevant if try status is set
<pedronis> we might just force disable things in some cases to cleanup
<pedronis> but not sure
<ijohnson|lunch> pedronis: I'll find out soon enough I think
<pedronis> ijohnson|lunch: yes :)
 * zyga made more progress and EODs
<mup> PR snapcraft#2840 closed: plugs: plugs can have no element <Created by sd-hd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2840>
<mup> PR snapcraft#2853 closed: meta: do not set snapcraft-runner when adapter is "none" <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2853>
<sdhd-sascha> sergiusens: hey, i come back later, and fix the comments about "core20"
<pedronis> ijohnson: thinking a bit about the discussion in your kernel branch about the symlinks, it might be better if setNext in my PR taks a snap.PlaceInfo
<mup> PR snapcraft#2856 opened: meta: convert Application's `adapter` from string to enum <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2856>
<ijohnson> pedronis: hmm
<pedronis> ijohnson: because that's what we use in the bootloader interfaces to refer to snaps
<ijohnson> yes that makes sense now that I think about it
<ijohnson> cause right now it's just a string
<ijohnson> but it would be more meaningful as a snap.PlaceInfo
<pedronis> ijohnson: yes, it can be parsed, but it's awkward
<pedronis> and it's easy to get back that string
<ijohnson> right
<pedronis> if it's what is needed
<pedronis> to be clear we didn't so far but if added some method to get the revision from PlaceInfo
<pedronis> we could stop needing boot.NameAndRevision
<pedronis> I'm tempted to finally do that, but that's not really an immediate concern
<pedronis> but it's related
<pedronis> ijohnson: I'm going to push the setNext change to my PR together with the comment fixes
<ijohnson> pedronis: ok
<pedronis> in a little bit
<ijohnson> yeah I think it would be nice if we could use PlaceInfo instead of NameAndRevision, but looking at that interface it's a bit heavy for what we need in boot I think
<ijohnson> maybe that's ok
<pedronis> ijohnson: boot is taking it as input anyway
<pedronis> and it's easy to make instances
<ijohnson> right I was just thinking about places where we would need to construct a PlaceInfo in boot
<ijohnson> perhaps it's not a big deal
<ijohnson> ah well if it's easy enough to create a PlaceInfo instance then nvm
 * ijohnson doesn't remember that code
<pedronis> ijohnson: there's snap.MinimalPlaceInfo
<pedronis> not any harder to make than NameAndRevision
<pedronis> same input
<ijohnson> ahhh perfect
<pedronis> import wise nothing changes
<ijohnson> if I had scrolled down from the file I literally had open I would have saw that :-)
<pedronis> np, it's not used a lot to be fair
<pedronis> ijohnson: the original purpose of PlaceInfo is mostly for remove-like operation in which we wanted to make sure we didn't assume we could get a lot of info on the snap
<pedronis> because it might be broken to start with
<ijohnson> I see
<pedronis> ijohnson: if you are interested, that's why some methods in snapstate managerBackend interface take PlaceInfo vs Info
<ijohnson> ijohnson: that makes sense
<ijohnson> err
<ijohnson> pedronis: that makes sense
<pedronis> ijohnson: anyway a bit of context is probably useful now that you will work with this
<ijohnson> yes, very much so thanks for sharing
<mup> PR snapcraft#2857 opened: meta: enable Snap to be fully initialized with __init__ parameters <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2857>
<mup> PR snapcraft#2821 closed: meta: remove __dict__ usage in Snap  <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2821>
<mup> PR snapcraft#2838 closed: add support for system-usernames <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2838>
<mup> PR snapcraft#2858 opened: schema: add support for system-usernames <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2858>
<pedronis> ijohnson: pushed
<ijohnson> pedronis: k, I'll take a look in a bit, in the middle of something right now
<pedronis> ijohnson: np
<cachio> cmatsuoka, hey
<cmatsuoka> cachio: hello
<cachio> cmatsuoka, do you know if the file /boot/efi/foo.cfg should exist on core20?
<cachio> I have a test failing because of it is trying to read it
<cmatsuoka> cachio: like grub.cfg? I think it should be in /EFI/ubuntu, let me check here...
<cmatsuoka> ah, you mean literally foo.cfg?
<cmatsuoka> maybe some test is creating it?
<cachio> cmatsuoka, yes, the test is
<cachio> gadget-update-pc
<cachio> and it should leave that file
<cachio> but is not doing that
<cmatsuoka> hmm, let me check here...
<cmatsuoka> cmatsuoka: I think we can leave this disabled until we check with mborzecki tomorrow
<cmatsuoka> cachio: I think we can leave this disabled until we check with mborzecki tomorrow
<cachio> ok
<cachio> np
<cachio> cmatsuoka, any idea why the file /var/lib/snapd/seed/seed.yaml does not exist on core20?
<cachio> it is braking another test
<cmatsuoka> there are things that are different there, I don't remember if this specific file should be there or not
 * cmatsuoka checks the docs
<cachio> ijohnson, hey
<cachio> the netplan test is failing on core20
<cachio> https://paste.ubuntu.com/p/fTcVRFPqdT/
<cachio> the test is ubuntu-core-netplan
<cachio> I have a debug session open if you want to take a look
<cmatsuoka> cachio: yep, the structure is different
<cachio> cmatsuoka, right
<cmatsuoka> cachio: maybe you can check for something in /var/lib/snapd/seed/systems?
<cachio> snap repair is failing because of this
<cmatsuoka> cachio: hm, I think we can check this with mvo tomorrow
<ijohnson> cachio: hey
<cachio> cmatsuoka, yes
<ijohnson> sorry I missed your ping
<ijohnson> let me look
<cachio> I'll leave a note in the doc with the details
<cachio> ijohnson, do you want the credentials?
<ijohnson> cachio: I'm kinda in the middle of working on other uc20 stuff, so I don't have the time to look into this, but I will look into it tomorrow
<ijohnson> cachio: but out of curiosity are other dbus tests passing on uc20?
<cachio> ijohnson, yes
<cachio> many of tehm
<cachio> them
<ijohnson> cachio: that error message is from dbus and not specific to netplan (though the netplan test might have broken somehow)
<ijohnson> cachio: okay that's what I would have thought from this error message
<ijohnson> cachio: please just leave a note in the SU and I will look tomorrow if nobody else beats me in their AM
<ijohnson> thanks
<cachio> ijohnson, sure, thanks!!!
<ijohnson> cachio: thanks
<mup> PR snapcraft#2859 opened: meson plugin: add support for core20 <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2859>
#snappy 2020-01-09
<sdhd-sascha> Is there some documentation about the future snapd & snapcraft ? Would like to help, if i can, but need more information before i change something.
<ijohnson> sdhd-sascha: for snapd at least, there's various things on the forum with the backlog tag, but you might be best served by talking with mvo in EU morning, as mvo would know best on what would be something for you to work on, as we have a good number of features in flight all being worked on by somebody and mvo would know best what would be open
<mborzecki> morning
<mborzecki> zyga: hey, are you around? got a mystery for you https://github.com/wekan/wekan-snap/issues/103#issuecomment-572211692
<mborzecki> mvo: hey
<mvo> hey mborzecki ! good morning
<zyga> good morning
<zyga> mborzecki: looking
<mvo> hey zyga
<mborzecki> zyga: can't find any other explanation other than /tmp not existing yet, but that doesn't make much sense
<zyga> mborzecki: not having read all of the thread yet, do you know what is /tmp on the host?
<zyga> is it a special filesystem?
<mborzecki> zyga: not in my centos7 install
<zyga> mborzecki: small note, private tmp is at /tmp/snap.$name/tmp
<zyga> mborzecki: I wonder what changed that caused it to break
<zyga> mborzecki: did we roll out snapd updates there?
<mborzecki> zyga: as i understand it, the first report was that it broke after the refresh
<zyga> of what?
<zyga> of the snap or snapd?
<mborzecki> zyga: i understood the snap was refreshed, but i can double check
<zyga> ok
<zyga> hmmm
<zyga> immediately I cannot think of a reason
<zyga> unless I remember my unix wrong
<zyga> you socket() to make a socket
<zyga> and you bind() it to create a file in the FS for AF_UNIX sockets that are not abstract
<zyga> I cannot even imagine how that can cause ENOENT to be returned
<mborzecki> zyga: afaik bind(/foo/bar/baz) can get you ENOENT if /foo/bar does not exist
<zyga> sure but for /tmp?
<zyga> that's super weird
<zyga>        ENOENT A component in the directory prefix of the socket pathname
<zyga>               does not exist.
<zyga> I would do this:
<zyga> create a small python snap
<zyga> that just tries the same
<zyga> ask the reporter to snap pack
<zyga> and snap install it
<zyga> and see what we get
<zyga> I would also collect 1) kernel version 2) any virtualization/container system in use
<sdhd-sascha> good morning
<zyga> hey sdhd-sascha
<sdhd-sascha> :-)
<sdhd-sascha> zyga: how do you guys handle different timezones in messages ?
<zyga> sdhd-sascha: in which messages?
<sdhd-sascha> don't want make people to wake up
<zyga> you mean on IRC?
<zyga> I think everyone just handles that differently
<sdhd-sascha> yes
<zyga> it's not like it's an IRC-alarm-clock next to bed :)
<sdhd-sascha> in my last position, i had my phone every second week loud.  Because i could get emergence calls
<sdhd-sascha> zyga: yeah :-)
<sdhd-sascha> so, the phone is silent for most people?
<sdhd-sascha> emergency calls
<zyga> sdhd-sascha: I don't get IRC notifications on my phone
<zyga> cannot speak how others handle that
<sdhd-sascha> zyga: i have silent info on phone. But didn't have to time to watch.
<zyga> afk
<sdhd-sascha> zyga: my last company was a medical laboratory. which works 24 / 7
<sdhd-sascha> ijohnson: thank you :-)
<pstolowski> morning
<zyga> hey pawel
<mup> PR snapd#7966 closed: tests: first core20 test fixes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7966>
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<mborzecki> zyga: heh, got a snap with app like this https://paste.ubuntu.com/p/xWjB2wc4m5/ declared as a service, can't reproduce across 50+ installs
<kristian_> Hello we are having problems accessing api.snapcraft.io, so we can't update or install any packages the way we are used to. forum.snapcraft.io works sometimes and sometimes not. pinging snapcraft.io doesn't work either for us.
<kristian_> We have this problem on all our ubuntu machines, any help on how to debug this? Could we have been blacklisted?
<mborzecki> mvo: can you take a look at https://github.com/snapcore/snapd/pull/7967 ? it's a simple PR with some additional tests for snapstate backend and snapd snap scenario
<mup> PR #7967: overlord/snapstate: improve snapd snap backend link unit tests <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7967>
<zyga> re
<mborzecki> mvo: opened a separate review so that the snapd on core will be smaller
<sdhd-sascha> mvo: if you have time, it would be nice to talk.
<mvo> kristian_: hm, when did this start? maybe bloodearnest knows about connectivity issues with the store, I'm not aware of anything right now.
<mvo> mborzecki: oh, nice. I have a look now
<mup> PR snapd#7772 closed: wrappers: write and undo snapd services on core <Remodel ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7772>
<mvo> mborzecki: you said you opened a separate review - what number is that?
<mvo> sdhd-sascha: hey, I think that can be arranged
<mborzecki> mvo: i meant 7967 as separate review
<mborzecki> mvo: the last bit is snapstate changes, will open that once 7967 lands (and 7772 just landed)
<sdhd-sascha> mvo: yeah :-) but it is in no hurry since I still have a few things to do
<mvo> sdhd-sascha: ok - see /msg
<mvo> mborzecki: nice
<pedronis> mvo: hi, thanks for reviewing Ian's PR, of course we need some parts of the early boot stuff after that change...  we should discuss after the standup, I just fear we need to think through the complexities of the kernel info we put in the modeenv
<pedronis> #7940 needs a 2nd review
<mup> PR #7940: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7940>
<mup> PR snapd#7968 opened: tests: enable regression suite on core20 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7968>
<mvo> pedronis: thanks, let's discuss after the standup then
<bloodearnest> kristian_: mvo: hi, no known issues with store connectivity right now.
<bloodearnest> kristian_: can you run mtr api.snapcraft.io?
<bloodearnest> from your affected machines
<mup> PR snapd#7969 opened: snap: default to "--direct" in `snap known` for 2.43 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7969>
<mvo> pedronis: the above pr is for the bit of snap known we talked about yesterday, should be the last missing bit before I can release 2.43 :)
<pedronis> ok
<mup> PR snapd#7940 closed: boot: implement SetNextBoot in terms of bootState.setNext <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7940>
<mvo> pedronis: probably best if Chipaca has a look at 7969 first, maybe my approach is too big of a hammer
 * Chipaca likes big hammers and cannot lie
<kristian_> bloodearnest, yes I can
<kristian_> mose of them are loss 0%, some hosts are ???
<kristian_> one is constantly at a loss around 99%
<Chipaca> mvo: glad it's in the 2.43 branch :)
<pedronis> mvo: btw, now that BootParticipant has exactly one method we could probably just have boot.SetNextBoot but not urgent
<mup> PR snapd#7967 closed: overlord/snapstate: improve snapd snap backend link unit tests <Remodel ð> <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7967>
<bloodearnest> kristian_: right, so you have a bad link in your path to our datacenter I'm afraid :(
<kristian_> bloodearnest, hmm which one? how can we fix that? is that something that our ISP has to do?
<bloodearnest> kristian_: your ISP, or one that they use or peer with - it's likely there's nothing you can do directly. Can you post the mtr output?
<bloodearnest> kristian_: is there a VPN involved at all in the path?
<kristian_> https://dpaste.org/BDvg
<kristian_> sorry it removes the tabs somehow
<pedronis> mborzecki: the distros using snap-mgmt don't have the issue in #7922, right ?
<mup> PR #7922: packaging, tests: stop services in prerm <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>
<kristian_> bloodearnest, ^
<mborzecki> pedronis: yes, because snap-mgmt is part of snapd package and must be run before the package is fully removed (basically in prerm)
<zyga> afk for 15 minutes
<zyga> I should eat something
<sdhd-sascha> mvo: thank you for the talk :-)
<mup> PR snapcraft#2856 closed: meta: convert Application's `adapter` from string to enum <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2856>
<mvo> sdhd-sascha: my pleasure!
<mup> PR snapcraft#2857 closed: meta: enable Snap to be fully initialized with __init__ parameters <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2857>
<zyga> Back now
<mvo> thanks Chipaca for the review
 * Chipaca goes for coffee
<bloodearnest> kristian_: looks like there may be an issue with london backbone, I'm seeing ~40% loss on one link
<bloodearnest> nothing we can do about it but wait for it to be fixed
<bloodearnest> (our DC is in London, hence the affect)
<bloodearnest> kristian_: your report has short hostames (-w for long), but it looks like Level3 are having some issues, as my problem link is with them also
<sdhd-sascha> mvo: in 7624 the merge conflict is really wired - i will look for it
<mvo> sdhd-sascha: aha, I can fix that for you
 * Chipaca really goes for coffee
<mvo> sdhd-sascha: I was also wondering if for 7624 we start with making "--direct" the default and then do a followup with the fix for the resume in indirect mode (does that make sense?)
<sdhd-sascha> mvo: well, it's okay. For me i need to understand the changes first ;-)
<mvo> sdhd-sascha: ok, just let me know if I can help you with that one
<sdhd-sascha> mvo: i'm sure i will figure it out. But not soo fast, like you would do
<sdhd-sascha> mvo: i just started to merge, without understanding the changes ;-) like: `meld <(git show master:cmd/snap/cmd_download.go) <(git show cmd/snap/cmd_download.go)` ... and so on
<mvo> sdhd-sascha: ok, good luck and let me know if you have questions!
<mvo> sdhd-sascha: any help on this PR is welcome!
<sdhd-sascha> mvo: thank you - i love to help
<mvo> a second review for 7969 would be great
<zyga> mborzecki: hey
<zyga> got a selinux denial
<zyga> type=AVC msg=audit(01/09/20 11:09:57.766:971) : avc:  denied  { setgid } for  pid=5731 comm=snap-discard-ns capability=setgid  scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:system_r:snappy_mount_t:s0 tclass=capability permissive=1
<zyga> capability setgid
<mborzecki> zyga: discard does setgid now?
<zyga> could this be related to the fact that snap-confine is not setgid root now
<zyga> and snap-confine calls snap-discard-ns sometimes
<zyga> perhaps ahead of calling it it should setegid(0)
<zyga> like it does for snap-update-ns
<mborzecki> yeah
<zyga> mborzecki: my question to you is what does this say
<zyga> that setgid was attempted but denied?
<zyga> or something else
<mborzecki> zyga: exactly that, setgid was attempted by snappy_mount_t context, which isn't whitelisted, the command was snap-discard-ns
<zyga> cool, thanks
<mborzecki> zyga: s-c called s-d-n right?
<zyga> yes
<kristian_> bloodearnest, so nothing we can do nor our ISP it's something an snappy's side?
<kristian_> the weird thing is that this is only a problem with our network, if we use a mobile network it works fine
 * sdhd-sascha lunch
<zyga> fixed and respawned selinux test
<zyga> now let's commit this
<mup> PR snapd#7970 opened: snap-repair: use dirs.SnapSeedDir instead of seed.yaml <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7970>
<sdhd-sascha> hey, does anybody use a git diff filter, so that git understand the language better ? since years, i want to test something like that.
<thresh> are there any issues with snap store infra atm?  keep getting "error: cannot refresh "firefox": unexpectedly empty response from the server (try again later)" from snap refresh firefox
<pedronis> mvo: #7970 is not enough, we'll fail later in initDeviceInfo
<mup> PR #7970: snap-repair: use dirs.SnapSeedDir instead of seed.yaml <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7970>
<pedronis> (as I commented in the standup doc)
<zyga> afk for 15-20 minutes
<mvo> pedronis: yeah, I can close again, was a low-hanging fruit but maybe too low-hanging
<mvo> seconds reviews for 7968, 7969 would be great, hopefully pretty easy both of them
<mup> PR snapd#7968 closed: tests: enable regression suite on core20 <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7968>
<cachio> mvo, hey
<mvo> cachio: hey
<mborzecki> cachio: hey, do the updates of arch images work ok now?
<mvo> cachio: I made some progress on the tests, hopefully I have something to merge for you soon
<cachio> mvo, I have this already open https://paste.ubuntu.com/p/gN6NW7Kng5/
<mvo> cachio: thanks for the merge
<mvo> cachio: yeah, I talked to foundatins, it's a known bug, we can ignore it for now
<cachio> mborzecki, I needed to use "pacman-key --refresh-keys" to fix the problem
<cachio> the same I was using but now while preparing the image
<cachio> mborzecki, your change also failed
<cachio> mborzecki, now the image is being created well again
<mvo> cachio: 7971 could be an interessting in-between step, we need your PR too, it enables a bunch more but with 7971 we can hopefully enable ~80% of the main tests
<mup> PR snapd#7971 opened: tests: enable a lot of the tests of main on uc20 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7971>
<cachio> mvo, taking a look to 7971, thanks for the PR
<mup> PR snapd#7970 closed: snap-repair: use dirs.SnapSeedDir instead of seed.yaml <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7970>
<mvo> cachio: thank you!
<mvo> cachio: I cherry picked some your work too, thanks for this! it will unfortunately create conflicts but I can help resolving those
<cachio> mvo, no problem
<mvo> we are approving 50 open prs again, yay, 2 pages are within reach :)
<mborzecki> cachio: hah, glad that it's working now
<sdhd-sascha> zyga: you mention, that you run single spread test locally ? what cmdline do you type?
<zyga> sdhd-sascha: typically something akin to
<zyga> SPREAD_DEBUG_EACH=0 spread -debug -v google:ubuntu-16.04-64:tests/main/snap-run
<zyga> for example
<zyga> I pick the OS and the test to match the change I'm doing
<zyga> you won't be able to use google backend yourself as that requires a key to spawn machines in gcloud
<zyga> you can replace that with qemu:
<zyga> and fetch or make a compatible image
<zyga> local testing benefits tremendously from caching, otherwise it's almost entirely network bound
<zyga> IO and CPU are not a significant factor in my experience
<zyga> you also need about 20-40GB of free space
<zyga> for qemu -snapshot
<sdhd-sascha> zyga: thank you - i understand :-)
<zyga> sdhd-sascha: local testing also benefits from -reuse and -resend
<zyga> as that saves some cost per run
<zyga> sdhd-sascha: -reuse keeps the vm for another pass
<zyga> sdhd-sascha: -resend sends updated tree
<bloodearnest> kristian_: the problem is neither your side or snappy side - it's in the middle I'm afraid.  Mobile network likely uses a completely different path, and thus is unaffected. As are most folks, or else we'd be seeing alerts and more issues
<sdhd-sascha> zyga: updated tree ? did you mean the git tree ?
<zyga> sdhd-sascha: updated tree, even without git commits
<zyga> as you edit and change stuff
<zyga> unless you use -resend you will not get any changes
<sdhd-sascha> ah, ok :-)
<zyga> assuming you use -reuse :)
<sdhd-sascha> mvo: i didn't see anything about "--indirect". Just took the PR and merged the conflicted files. The rest was automerged by git. The tests are currently running locally. Manually black box test works with and without "--direct" option.
<sdhd-sascha> The merged source is here: https://github.com/sd-hd/snapd/tree/snap-donwload-via-snapd-2
<sdhd-sascha> Don't know how to get the source into the PR (i think i didn't had the permissions)
<sdhd-sascha> What is about this test "TestDownloadViaSnapd" ??? Looks for me like a integration test. Should the Test-Server not be `mocked` or something ? I don't know how to mock in golang, yet.
<mup> PR snapd#7922 closed: packaging, tests: stop services in prerm <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7922>
<pedronis> sdhd-sascha: we generally prefer using httptest.NewServer liberally vs trying to mock http stuff
<sdhd-sascha> pedronis: thank you :-)
<sdhd-sascha> how can i launch them, locally?
<pedronis> sdhd-sascha: launch what?
<sdhd-sascha> wait, .. i read about "httptest.NewServer"
<sdhd-sascha> I ask about launch, because i got a real http-query on snapd if i run the test, which contains this call `RedirectClientToTestServer`
<pedronis> ah, something is wrong then
<pedronis> that's the purpose of s.RedirectClientToTestServer
<pedronis> not to use a real snapd
<sdhd-sascha> thank you.
<pedronis> you can look how it is implemented in main_test.go
<pedronis> it is using httptest.NewServer, but that's probably not the issue
<pedronis> more the config bit, if redirecting is not working
<mup> PR snapd#7972 opened: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<pedronis> pstolowski: answered and/or addressed your comments in #7934
<mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<ijohnson> I tried a new alarm clock this morning which slowly got brighter like a sunrise which was great til the light turned off... That's not how the sun works
<pstolowski> pedronis: ty, looking
<sdhd-sascha> ijohnson: :-D
<mup> PR snapcraft#2848 closed: common: generate run scripts which can execute independently <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2848>
<zyga> hmmmm
<mborzecki> pedronis: thanks for the comment under 7972, i was kind of expecting this, the other version added new method to the snapstate backend iface but it was equally non transparent
<pedronis> mborzecki: as long as it was magical it was ok, but now if we have to ship state 3 level down the appeal starts to diminish
<mborzecki> pedronis: maybe we can quickly chat about that before/after the standup?
<pedronis> mborzecki: maybe before, we have something UC20 to discuss after already
<pedronis> (afaik)
<mborzecki> pedronis: ok, let me grab some coffe and i'll join the standup HO
<zyga> lunch
<zyga> and debugging
<zyga> I broke up my patches
<zyga> and now something fails :) oh well
<mvo> sdhd-sascha: cool, thank you, I have a meeting now, then I have a look
<sdhd-sascha> mvo: just this second i force pushed the test
<sdhd-sascha> mvo: but didn't look if all cases are handled ...
<mvo> sdhd-sascha: quite possible, I remember that test was very tricky
<mvo> sdhd-sascha: what I meant with "--indirect" was that in this PR maybe we should make "--direct" the default (that's what we have today) and instead of --indirect as an option to go via snapd. then we can fix all the missing bits in --indirect (resume of download is missing today) and once that is finished flip the default again.
<sdhd-sascha> ah, understood
<mvo> sdhd-sascha: great, thank you!
<ackk> mvo, hi about https://bugs.launchpad.net/snapd/+bug/1817276, did you see my last comment?
<mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
<sdhd-sascha> mvo: i can switch direct and indirect. if it should ?
<ackk> mvo, I happen to have a running maas here on my laptop which was idle (I was doing other things) and suddenly squashfuse is using 100%cpu
<mvo> ackk: I haven't, let me see (in a meeting right now, so will probably be a bit slow)
<ackk> it's still going, laptop fan is going crazy
<mvo> sdhd-sascha: yeah, that would be great
<zyga> and i found the part that made it fail, yay!
<mvo> ackk: can you see where snapfuse that is running and eating so much cpu comes from? i.e. which snapfuse binary path is used?
<ackk> mvo, sigh, it's dead now
<mvo> ackk: it's strange, we definitely need to debug this some more (our side)
<mvo> ackk: oh no :/
<mvo> ackk: sorry for the trouble there :(
<ackk> mvo, no probl
<ackk> I can try again the scenario from my comment (this one was a different case)
<ackk> mvo, I *think* the reason it went creazy is that maas went crazy respawing processes because it seems at times when I refresh the snap services from the old version don't get killed, so the new ones fail to start
<ackk> mvo, (which might be a separate issue)
<ackk> mvo, I had the snap installed with "try" from an unpacked snap, then I switched with refresh --amend to get the one from the store
<zyga> ijohnson: reviewed
<ijohnson> zyga: thanks will look after SU
<sdhd-sascha> mvo: just pushed into my repo, the default direct case .
<sdhd-sascha> mvo: the integration test needs fixes next
<ackk> mvo, fwiw I couldn't reproduce the issue from my last comment now...
<sdhd-sascha> zyga: thank you. -resend and -reuse works great :-)
<zyga> sdhd-sascha: some extra hints to look at: look at spread.yaml look for proxy settings, setting up a proxy for the classic packaging system (e.g. apt-cacher-ng) saves tons of tons of bandwidth and time
<zyga> sdhd-sascha: you can go further and optimize time for big snaps like core and core18 by applying some tricks as well
<sdhd-sascha> zyga: did you have custom backend_* list for apt-cacher ?
<zyga> backend?
<zyga> no, I  think not
<zyga> just a stock value
<zyga> it works good for rpm packages as well
<sdhd-sascha> ok, thank you
 * zyga sees slow traffic to the store
<kristian_> bloodearnest, sorry I just don't understand - should I contact my ISP regarding this issue? Or is there absolutely nothing we can do?
<zyga> installing core --edge takes forever now
<zyga> is store in trouble?
<ogra> status page looks fine
<zyga> type=AVC msg=audit(01/09/20 14:58:04.383:746) : avc:  denied  { setgid } for  pid=27854 comm=snap-discard-ns capability=setgid  scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:system_r:snappy_mount_t:s0 tclass=capability permissive=1
<zyga> this won't go away :/
<zyga> hmm
<zyga> need to think about why
<zyga> I bet it's the lcok
<zyga> *lock
<mvo> ackk: thanks for the updates! still in meetings .(
<sdhd-sascha> mvo: all existing tests are now green and direct is default. I commented in the PR
<mvo> sdhd-sascha: nice, that sounds great! I'm still in meetings :/ but I will look as soon as I can. feel free to open a new PR based on the existing one with your updates though, that will means people like Chipaca  can review while I sit here in meetings
<Chipaca> green tests? eww
<sdhd-sascha> mvo: wait - ... i took your repo which was listed in the PR .
<sdhd-sascha> Chipaca: has passed - locally
 * zyga tries and idea, runs spread and goes for a tea break
<Chipaca> :)
 * sdhd-sascha goes to work on own ubuntu-core and figuring out, how to split sway into reusable parts (maybe some more snapcraft-extensions)
 * ijohnson takes quick break
<mvo> 7969 needs a second review (pretty please :)
<pedronis> #7934 is also ready for a 2nd review, is not simple though
<mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<mup> PR snapd#7969 closed: snap: default to "--direct" in `snap known` for 2.43 <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7969>
<ijohnson> zyga: so the issue is that black is complaining about the unused variable in that python PR I have
<ijohnson> zyga: is there a "pythonic" way to just have a variable exist without being used?
<ijohnson> maybe `if var: pass` or something ?
<ijohnson> cachio: hey did you or anybody else look at the dbus failures on uc20 (i.e. netplan) ?
<cachio> ijohnson, sure, on master?
<mvo> sdhd-sascha: hey, just had a quick look at your sd-hd/snapd:snap-download-via-snapd-2 changes, looks very reasonable, it seems like it has a base branch that is based on something other than snapcore/snapd which seems to confuse github but the commit looks fine, I can cherry pick them into the open PR 7624
<mvo> sdhd-sascha: thanks for working on this!
<mup> PR #7624: snap: make `snap download` download via snapd if available <Created by mvo5> <https://github.com/snapcore/snapd/pull/7624>
<ijohnson> cachio: no I think on your (or maybe mvo) PR to enable the full test suite on uc20
<ijohnson> cachio: so not on master
<ijohnson> (yet)
<cachio> ijohnson, in the mvo's branch, the netplan test is disabled
<ijohnson> cachio: ok cool
<cachio> on mine is not, but it is not gonna be merged
<sdhd-sascha> mvo: i can rebase it for you ;-)
<ijohnson> cachio: so I take it no-one else has looked into it yet?
<cachio> I'll take alook again today to that test
<cachio> ijohnson, yes please
<ijohnson> cachio: ok I will look today in the PM
<cachio> I am still trying to fix tumbleweed
<cachio> ijohnson, thanks!!!
<sdhd-sascha> mvo: wait - i took it from your repo and merged it with snapd:master ?.
 * sdhd-sascha my wife is home - afk
<cjwatson> ijohnson: is it really black that's complaining, rather than something like flake8?
<ijohnson> cjwatson: hmm actually I'm not sure what is complaining let me look
<ijohnson> I thought I had configured black but maybe it's something else
<cjwatson> ijohnson: if it's flake8 then see http://flake8.pycqa.org/en/latest/user/violations.html#in-line-ignoring-errors perhaps
<ijohnson> I guess it is flake8 that is complaining about the variables
<mvo> ijohnson: 7971 should be ready, it's general flakiness that holds it back
<mvo> ijohnson: but the netplan failure is strange, I just had no time yet to debug
<ijohnson> mvo: I looked at the netplan error I think it's something more structurally wrong with dbus activated services on uc20
<ijohnson> could be something needs to be added to writable or some permissions are set wrong
<ijohnson> not sure yet
<mvo> ijohnson: aha, that makes sense. we can ask foundations for help here I guess
<ijohnson> mvo: I will look at it a bit later today, but in the meantime could I get a quick review on https://github.com/snapcore/snapd/pull/7973 pretty please :-) ?
<mup> PR snapd#7973 opened: boot.go: split makebootable family into its own file <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7973>
<mup> PR #7973: boot.go: split makebootable family into its own file <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7973>
<pedronis> mvo: can somebody else look into this, I thought ijohnson has already a lot of UC20 things on his plate
<mvo> pedronis: yeah, totally, he should not look into this, sorry if I gave this impression
<mvo> (cc ijohnson -^)
<ijohnson> ok, I will keep on uc20
<Chipaca> popey: you're better at figuring out this stuff than I am: last two comments on https://forum.snapcraft.io/t/6093 seem to be sensible answers but don't have much to do with the problem being discussed. Suspect future spammers. WDYT?
<pedronis> ijohnson: reviewed, thanks, couple of nitpicks
<ijohnson> ack, working on it now
<popey> Chipaca: i do wish i was an admin and not just a mod on that forum. I dont have access to the same admin tools that help me spot these things as I do on the ubuntu discourse
<Chipaca> popey: I'd give you admin if I could :)
 * Chipaca is also just a moderator
<popey> in fact...
<mup> PR snapcraft#2860 opened: backport fixes for 3.9 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2860>
 * Chipaca goes for a walk
<mup> PR snapd#7960 closed: tests: use unbuffered python output for daemons, misc formatting <Simple ð> <Test Robustness> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7960>
<pedronis> ijohnson: btw, given there is already a baseBootSuite, it's probably not too hard to have a separate test fill too
<pedronis> *test file
<ijohnson> pedronis: do you want to try and split that out now before making further changes?
<pedronis> ijohnson: as you prefer really, it's not crucial atm
<pedronis> just noticed
<mup> PR snapd#7974 opened: many: run black formatter on all python files <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7974>
<ijohnson> zyga: ok this is the last I'm going to do with the python stuff for a while, but that PR is just the formatter changes, no substantial code changes
 * ijohnson switches back to uc20
<mup> PR snapd#7975 opened: release: 2.43 <Created by mvo5> <https://github.com/snapcore/snapd/pull/7975>
<ijohnson> pedronis: I agree I think it's a good idea to split the makebootable tests off too, I just created a PR stacked on top of the other one
<ijohnson> opened as 7976
<mup> PR snapd#7976 opened: boot: split makebootable tests into their own file <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7976>
 * zyga is doing homework with the kids and will return to resume work in about an hour
<zyga> 2020-01-09 16:36:08 Successful tasks: 5582
<zyga> 2020-01-09 16:36:08 Aborted tasks: 0
<zyga> 2020-01-09 16:36:08 Failed tasks: 2
<zyga>     - google:fedora-30-64:tests/main/selinux-clean
<zyga>     - google:fedora-31-64:tests/main/selinux-clean
<mup> PR snapd#7977 opened: snap: add (hidden) `snap download --indirect` option to download via snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/7977>
<mvo> sdhd-sascha: just fyi, I cherry-picked your --indirect things and pushed as 7977, thanks again for your help here
 * mvo wonders how much Chipaca will hate the idea of snap download --indirect :)
<Chipaca> mvo: i don't hate it
<mborzecki> zyga: got logs?
<mvo> Chipaca: excellent :)
<mup> PR snapd#7978 opened: data/selinux, test/main/selinux-clean: update the test to cover more scenarios <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7978>
<sdhd-sascha> mvo: nice :-)
<sdhd-sascha> mvo: you work on the snap maas ?
<sdhd-sascha> MAAS
<mvo> sdhd-sascha: i don't work on that ackk does
<mvo> sdhd-sascha: and yeah, nice indeed, hopefully that can land soon
<sdhd-sascha> ok. I only want to know, if it's possible to mix a `apt install` with a `snap'ed maas`
<sdhd-sascha> if so - then i would add a `snap maas region` here
<sdhd-sascha> i mean `maas-rack`
<mup> PR snapd#7971 closed: tests: enable a lot of the tests of main on uc20 <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7971>
<mup> PR snapd#7979 opened: boot: drop NameAndRevision, use snap.PlaceInfo instead <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7979>
<mup> PR snapcraft#2861 opened: meta: remove Application's `prepend_command_chain` <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2861>
 * zyga returns to work on selinux policy bit
<mup> PR snapd#7625 closed: cmd/snap-confine: stop being setgid root <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7625>
<mup> PR snapd#7980 opened: packaging,snap-confine: stop being segid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<mup> Bug #1859084 opened: network-control interface seems to be broken on the Raspberry Pi 3 running Ubuntu Core 18 <Snappy:New> <https://launchpad.net/bugs/1859084>
<mup> PR snapcraft#2862 opened: python plugin: remove bzr workaround <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2862>
<mup> PR snapcraft#2863 opened: spread tests: use source-depth: 1 for plainbox tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2863>
<mup> PR snapd#7981 opened: snap-bootstrap: create encrypted partition <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7981>
<mup> PR snapd#7723 closed: snap-bootstrap: create encrypted partition <UC20> <â Blocked> <Created by cmatsuoka> <Closed by cmatsuoka> <https://github.com/snapcore/snapd/pull/7723>
#snappy 2020-01-10
<mborzecki> morning
<mup> PR snapcraft#2862 closed: python plugin: remove bzr workaround <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2862>
<zyga> good morning!
<zyga> mborzecki: I'll switch gears for a few hours to reset my focus away from setgid
<zyga> mborzecki: I pushed the branch that has the selinux denial, I have one more idea to explore but if all else fails I'll ask you for a moment to come up with more ideas
<zyga> quick morning coffee and I'll be around shortly
<mborzecki> zyga: hey
<zyga> I slept terribly last night
<mborzecki> btw. core20 spread tests seem to be failing
<zyga> mborzecki: there's a thread about core20 being in the stable channel being wrong, perhaps that changed just now and it is affecting tests?
 * zyga checks
<mborzecki> zyga: btw. after going through tickets in RHBZ yday evening pushed this: https://github.com/snapcore/snapd/pull/7978
<mup> PR #7978: data/selinux, test/main/selinux-clean: update the test to cover more scenarios <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7978>
<zyga> oh interesting
<zyga> I wonder if your improvement to selinux-clean test shows some more stuff in my PR
<mborzecki> zyga: we're clearly not covering some usage patterns, got some fixes for this already, but need to read on some things a bit more
<zyga> mborzecki: I think the better approach would be to do it in each test
<zyga> like we do with apparmor denials
<zyga> mborzecki: it will never be complete on its own, as a standalone test
<zyga> mborzecki: we can keep it as a quick selinux smoke test
<zyga> mborzecki: not sure if we are ready for such a switch though
<mborzecki> zyga: yeah, that'd be nice, but last time i tried it it was a bumpy ride in spread tests
<zyga> yeah, I think we are in agreement, it's a long term plan
<zyga> good to see more tests
<zyga> good morning Chipaca, mvo :)
<mvo> hey zyga and pstolowski ! good morning
<zyga> hey pawel!
<pstolowski> morning!
<mborzecki> mvo: pstolowski: Chipaca: morning guys
<mvo> hey mborzecki
<mvo> and hey Chipaca
 * Chipaca waves
<Chipaca> today's going to be weird: somebody in the forum just admitted to being wrong
<Chipaca> i should get breakfast before it escalates
<mvo> hrm, hrm, looks like uc20 breaks all the tests, I wonder what happend
<mvo> xnox: https://paste.ubuntu.com/p/Mtzr52HJp2/ - if only I can upload to the core20 ppa :(
<mvo> xnox: also, should I backport https://github.com/systemd/systemd/pull/14409/files to 244 in focal ? so that going forward we don't need to have our own version of systemd in the ppa?
<mup> PR systemd/systemd#14409: some smaller modernizations to the shutdown loop <good-to-merge/waiting-for-ci ð> <shutdown> <Created by poettering> <Merged by keszybz> <https://github.com/systemd/systemd/pull/14409>
<mvo> juliank: hey, do you think you could upload https://paste.ubuntu.com/p/Mtzr52HJp2/ to ppa:canonical-foundations/ubuntu-image ? xnox seems to be not around yet and this is currently breaking our CI - I don't have the required permissions :/
<juliank> ack
<mvo> juliank: \o/ you rock!
<juliank> mvo: uploaded
<mvo> juliank: thank you!
<mvo> xnox: juliank was kind enough to upload the fix to the ppa:caonical-foundations/ubuntu-image ppa, I prepare a proper upload with the pr14409
<zyga> pstolowski: are you getting any issues with mail today?
<mvo> zyga: my issue with mail is that I get too much (SCNR)
<zyga> mvo: I got logged out today
<zyga> mvo: and cannot log back in, google redirects me to sso, I log in and then google gives a 400 something page
<zyga> mvo: so no email today
<mvo> zyga: uh, fun. so it's google with the 400 or our sso?
<mvo> zyga: fwiw, my mail seems to be ok
<zyga> google
<pstolowski> zyga: yep (if you mean mac os mail & auth prompts)
<zyga> pstolowski: yeah, that
<zyga> pstolowski: I tried logging in again but I get 400 from google
<pstolowski> zyga: yeah something broke, i though it was fine after 3 attempts some time ago (it stopped prompting me), but i cannot send email
<zyga> pstolowski: yeah, I'll wait till EOD and report it
<zyga> pstolowski: I heard there are some issues in the DC
<Chipaca> sliced chillies omelette + itchy eyes == half hour of pain :-(
<zyga> uh?
<zyga> "just add nails" they said
<Chipaca> zyga: to the DC?
<zyga> Chipaca: to the omelette ;)
<Chipaca> zyga: https://www.youtube.com/watch?v=z-KzGKoLHXk but more boring
<mvo> fwiw, the uc20 tests should be good again, the updated core20 hit edge
<pstolowski> zyga: nb, (unsurprisingly) same problem on IOS
<mup> PR snapcraft#2860 closed: backport fixes for 3.9 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2860>
<sdhd-sascha> hi, in which branch is `snapctl` with option `user-open` ?
<pedronis> mborzecki: mvo: Ian's PRs need 2nd reviews, they are also red, is that the uc20 issue that now is fixed? do they need a master merge?
<mvo> pedronis: the uc20 issue is fixed, a new core20 hit the store ~30min ago
<mvo> pedronis: so a retry should be enough
<sdhd-sascha> i get `error: error running snapctl: Unknown command `user-open'`
<sdhd-sascha> i found it ;-)
<mup> PR snapd#7975 closed: release: 2.43 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7975>
 * zyga -> afk
<mup> PR snapd#7973 closed: boot: split MakeBootable implementations into their own file <Simple ð> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7973>
<zyga> re
<mborzecki> pstolowski: can you take a look at the lastest batch of selinux updates https://github.com/snapcore/snapd/pull/7978 ?
<mup> PR #7978: data/selinux, test/main/selinux-clean: update the test to cover more scenarios <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7978>
<pstolowski> mborzecki: sure
<mborzecki> hope i got it right
<mborzecki> it'd be great to have some useful documentation on selinux :/
<mup> PR snapd#7865 closed: travis-ci: add go import path <Created by sd-hd> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7865>
<mborzecki> ijohnson: pushed a little fix to #7976
<mup> PR #7976: boot: split MakeBootable tests into their own file <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7976>
<mborzecki> mvo: can you take another look ^^
<mvo> mborzecki: sure thing
<sdhd-sascha> can someone stop travis for 7845 ? i don't think that other builds has to wait for this change ?
<sdhd-sascha> it's need to be fixed in upstream systemd pkgconf first ...
<zyga> sdhd-sascha: sure
<zyga> done
<sdhd-sascha> zyga: maybe set "blocked" label or something. So nobody look for it, and waste time ?
<sdhd-sascha> thank you :-)
<pedronis> mborzecki: I made a comment about your changes in 7976
<mborzecki> pedronis: heh, good idea, i'll update it
<mborzecki> pedronis: thanks!
<pedronis> mborzecki: also maybe we don't need all the AddCleanup Force(nil) in the force* methods, not sure
<pedronis> because we have one in the base suite
<mup> PR snapd#7982 opened: o/snapstate, wrappers: enable services on start <Complex> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7982>
<cachio> mborzecki, hey
<cachio> I am reviewing this issue that you reported
<cachio> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1857022
<mup> Bug #1857022: gtk3-nocsd preloads a setuid library <gtk3-nocsd (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1857022>
<cachio> which is the importance of this on in your opinion?
<mborzecki> cachio: i think you can flip it to triaged:undecided, we have try to do something smart about those preloads, but not necessarily
<cachio> mborzecki, ok, thanks
<ijohnson> Thanks mborzecki
<mborzecki> ijohnson: np, hope i didn't make it worse
<ijohnson> I dunno I have really looked I just saw your ping that you fixed it :-P
<ijohnson> *haven't
<pedronis> mborzecki: the changes look good to me, let's see if it gets green as well
 * ijohnson is always happy to have mborzecki fix my things
<pstolowski> zyga: the email works for me now, had to re-authenticate and reconfirm permissions
<zyga> pstolowski: cool, I'll do that
<mup> PR snapcraft#2864 opened: meta: assume command-chain fix for prepending snapcraft-runner <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2864>
<mup> PR snapd#7976 closed: boot: split MakeBootable tests into their own file <Simple ð> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7976>
<sdhd-sascha> hmm, i just forget that /usr/ is mounted from `core` ... snapd really needs overlayfs interface.
<sdhd-sascha> would make things so much easier.
<sdhd-sascha> Is it possible to limit a snap to a kernel version on the host ?
<ijohnson> sdhd-sascha: there is no limiting of a snap to a kernel version, but you can specify features with `assumes: [snapd2.43]` etc.
<ijohnson> I don't remember the full list of features you can specify, but at least you can do snapd versions
<sdhd-sascha> ijohnson: thank you.  :-)
<sdhd-sascha> My final goal would be a complete desktop in snaps, without any gui-libraries on the host-system. I mean, no fonts, no libgl*, no libxkb and so on ...
<ijohnson> good luck :-)
<sdhd-sascha> ijohnson: it's diffcult for me alone ;-) i just test the current limits.
<sdhd-sascha> Currently i can build a monolithic "sway desktop snap", which has a terminal inside and use the gnome-extension. But to split these into composable parts, ... hmm
<mup> PR snapd#7983 opened: tests: Adding more tests to core20 test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7983>
<mup> PR snapcraft#2865 opened: cli: do not report KeyboardInterrupt errors <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2865>
 * cachio lunch
 * Chipaca does a git reset --hard, and does a grump
 * Chipaca afk
 * zyga back from lunch
<mup> PR snapcraft#2863 closed: spread tests: use source-depth: 1 for plainbox tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2863>
 * zyga EODs
<zyga> ttyl
<jdstrand> ogra_: oh, I meant to tell you, the writable label on the external drive trick worked great. thanks!
<jdstrand> (again)
<zyga> hey there jdstrand
<zyga> I'm EOD and doing some experiments before heading upstairs away from the office
<zyga> I wanted to tell you I started reviving branches from last year to address your feedback
<zyga> and that I should have some useful stuff for your eyes next week
<jdstrand> zyga: I saw thanks. I'm off next week but back the next
<jdstrand> zyga: have a nice weekend :)
<zyga> ah, good to know
<zyga> thank you, enjoy :)
<Chipaca> jdstrand: 'back next' â the week the CT sprint is on?
<jdstrand> Chipaca: I'm not in CT this time. I will be working that week though
<mup> PR snapcraft#2866 opened: spread tests: limit adapter test to amd64 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2866>
<ogra> jdstrand, awesome !
<makayabou> Hello, I want to install snaps during Debian installation but it's done in a chroot inside /target, so systemd can not be used.. I tried to create a seed.yaml in /var/lib/snapd/seed but it does not work. I put name and channel only is it enough?
<mup> PR snapcraft#2771 closed: python plugin: first try processing setup.py without PyPI <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2771>
<mup> PR snapcraft#2229 closed: elf: extract build ID and presence of debug info <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2229>
<mup> PR snapcraft#2865 closed: cli: do not report KeyboardInterrupt errors <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2865>
<mup> PR snapcraft#2867 opened: elf: remove return parameters for ElfFile's _extract() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2867>
#snappy 2020-01-11
<mup> PR snapd#7984 opened: store, overlord/snapstate, etc: SnapAction now returns a â¦Result <Created by chipaca> <https://github.com/snapcore/snapd/pull/7984>
<mup> PR snapcraft#2864 closed: meta: assume command-chain fix for prepending snapcraft-runner <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2864>
#snappy 2020-01-12
<medard> Hello. Is ubuntu snappy viable alternative to redhat coreos?
<medard> how do I install it? I could only find some .img files that I can't mount
<ogra> medard, https://ubuntu.com/download/iot
<medard> ogra, this is ubuntu server. Is it the same thing as snappy core?
<ogra> (scroll to "Ubuntu Core" at the bottom)
<ogra> snappy core never actually existed ... that was an interim name for Ubuntu Core
<medard> ogra, do I need that ubuntu SSO?
<ogra> if you want to log in :)
<ogra> (it uses the ssh key stored for the SSO account to set up key based login for the admin account)
<medard> ogra, im unable to import ssh key...
<medard> pretty sure it's openssh v2
<medard> i used  ssh-keygen -t rsa -b 4096
<sdhd-sascha> hey, medard, it's many years ago, i tested coreos. At this time it was independent from redhat. What are you looking for? What should an OS-image do for your needs ?
<medard> sdhd-sascha, im tinkering a little with container OSes. My goal is to run home server not on hypervisor but on something like coreos
<sdhd-sascha> me, too :-) I wonder, if gentoo the best - or why `rpm-packages`... And so on...
<sdhd-sascha> For me is `apparmor` security a little bit more readable. And all debian-based distro are more and more customable. For my opinion if i install CentOs, then everthing comes with them.
<sdhd-sascha> I mean, i can't stop centos to install packages. with deb i can.
<sdhd-sascha> medard: what do you want to examine or learn? The OS or some software?
<medard> sdhd-sascha, the OS
<sdhd-sascha> medard: in the past, i'm looking for something to create a cloud at home. So i'm looking around, to find something which is lightweight enough for my budget? Is this the same searching ? Or did you have another picture in your mind ?
<medard> Well, at work I work with coreos and I started thinking that maybe containers are better way to manage my applications at home, than separate virtual machines
<sdhd-sascha> Oh, it still depends. High security system - or e.g. database and software
<sdhd-sascha> Normal software you can always run in containers ;-)
<medard> sdhd-sascha, I know. I'm just looking for a proper (most minimal) underlying operating system
<sdhd-sascha> Again, it depends. But if you say the people what you need. I have learned, they listen ;-)
<sdhd-sascha> I'm here, because i'm a ubuntu fan. And i know, they listen
<sdhd-sascha> medard: did you use kubernetes ?
<medard> sdhd-sascha, yes, i did
<sdhd-sascha> :-)
<sdhd-sascha> I love the idea of k8s more then VMs
<sdhd-sascha> I started some years ago to learn it, but didn't have the support to be good ...
<sdhd-sascha> medard: Did you ever seen juju ui ? It's like apache nifi - but for cloud machine relations : https://jaas.ai/
<medard> thanks mate
<sdhd-sascha> gladly
<sdhd-sascha> hey, chipaca - what language did you use for graph alagorithm ? i love ocaml/fsharp ? but didn't have time... what should i learn ? did you know that f# has units, if you want ? e.g. pound or kilo ... and can convert it, if you like ?
