#snappy 2015-04-20
<mvo> pitti: hi, if you have a moment, I would greatly appreciate you help with udev :) I work on a end-to-end test of the new hardware assign feature, I created a snap with an assign rule for ttyS0 and on install it generates the following rule: http://paste.ubuntu.com/10854819/ but the subsequent udevadm info seems to not show the snappy-assign tag, is there anything that I'm missing here?
<mvo> pitti: hm, to be exact I have the tag after a reboot, so I guess I need to trigger a re-read of the udev rules(?)
<dholbach> good morning
<pitti> Good morning
<pitti> mvo: o/ Gruesse aus London (Bluefin)
<mvo> pitti: hey, good morning!
<pitti> mvo: wrt. the branch, I think there might still be something wrong
<mvo> pitti: how is the jetlag :) ?
<pitti> mvo: I didn't get any /dev/null failures while the ACL setting was still broken, so I wonder if the "deny all" rule was actually applied
<mvo> pitti: aha, ok
<pitti> mvo: well, getting slightly better; the strong English breakfast tea helps :)
<pitti> mvo: how is your's?
<mvo> pitti: I did a end-to-end this morning and ttyS0 got assigned, but of course that is just the allow
<mvo> pitti: I'm pretty tired :) but indeed, tea helps
<pitti> mvo: yes, if you just install the rule, you need udevadm control --reload
<pitti> mvo: ^ well, maybe; actually you might not need it for new .rules files
<pitti> mvo: but for sure a new udev rule doesn't apply to already existing machines, you need to udevadm trigger those
<mvo> pitti: aha, so udevadm trigger after the rules get installed? I will add that
<pitti> mvo: udevadm trigger --verbose --name-match=ttyS0
<mvo> pitti: nice, thanks
<pitti> mvo: the --verbose shows the triggered devices (you can leave this out on the final commit, of course)
<pitti> mvo: that will re-apply the rules on an existing device, i. e. synthesize a "change" event
<mvo> pitti: thanks, I will add that to my code
<mvo> pitti: I guess I need to write code that maps all the matches in the yaml to the udevadm trigger ? or can I do a global trigger?
<pitti> mvo: you can trigger everything too, yes
<mvo> how horrible is that?
<pitti> mvo: on a desktop this might lead to some undesired effects, like keyboard layouts getting reconfigured etc.
<pitti> mvo: but for the most part it sohuld be okay
<mvo> ok, thanks! so just udevadm trigger?
<pitti> mvo: actually, it's much easier:
<pitti> mvo: you can use the same udevadm trigger command as in my shell PoC
<pitti> mvo: just without the --dry-run
<pitti> mvo: that will trigger exactly those devices which got assigned to that app
<mvo> pitti: sweet, thanks!
<mvo> so just "udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=$APPNAME" :) ?
<mvo> well, without the --dry-run
<pitti> udevadm trigger --verbose --tag-match=snappy-assign --property-match=SNAPPY_APP=foo
<pitti> mvo: right
<mvo> pitti: \o/
<mvo> pitti: about the deny-all, will you look into this or should I do that once I finished the change above?
<pitti> mvo: I'm looking into it
<pitti> mvo: did you get the other fixes?
<mvo> thanks!
<mvo> pitti: some changes, nothing major, r32 is my latest version
<mvo> pitti: I was working on a example snap, the go code and a end-to-end test
<pitti> mvo: ah, I see you merged my stuff, good
<mvo> pitti: yes, thank you very much for this!
<pitti> $ echo > /dev/null
<pitti> bash: /dev/null: Operation not permitted
<pitti> mvo: ^ I took /dev/null out of the static list, and now get that
<pitti> mvo: IOW, it's all good
<pitti> mvo: just wanted to double-check
<mvo> pitti: \\\o///
<mvo> (spide hug ;)
<mvo> spider even
<pitti> mvo: you have *that* many arms? you scare me!
 * mvo hates jetlag
<mvo> and not even enough arms for a spider - oh well!
 * mvo drops into koma
<asac> spider hug is nice ;)
 * asac wonder if i heard that expression before
<mvo> probably not, its my jetlag speaking ;)
<JamesTait> Good morning all; happy Monday, and happy Chinese Language Day! :-D
<mvo> asac, Chipaca, sergiusens: so the hardware yaml looks like this right now: http://bazaar.launchpad.net/~mvo/snappy/snappy-hardware-yml-to-udev/view/head:/snappy/snapp_test.go#L1127 - my question is if we should include the namespace in the app-id, i.e. should it be exclusive to the app.namespace or is app ok (frameworks can not be forked so for most of the use-cases this is probably ok). but I want to double check
<Chipaca> mvo: hardware is another kind of snap?
<mvo> fwiw, thats the only open question otherwise I think all the bits for hardware assign from a oem snap are ready
<pitti> mvo: ah, I didn't check -- did you happen to have the time to upload those fixes for the failed two units?
<pitti> mvo: if not, where could I commit these changes?
<Chipaca> mvo: or is it part of the oem kind?
<mvo> pitti: I did, but it seems like its still broken because our pathes are writable only later
<mvo> pitti: i.e. the seed path is RO when systemd needs it and only made writable later
<pitti> mvo: ah, ok; that should be in devel-proposed?
<Chipaca> mvo: if part of the oem, i think sergio was going to make them namespaceless
<pitti> mvo: the tmpfiles.d thing ought to work now?
<mvo> pitti: yes the path is writable but I think its too late
<mvo> pitti: I think so, the only missing one was the random seed
<pitti> mvo: ok, so that sounds like another one which we move to the initramfs, or we just mask the service entirely
<mvo> Chipaca: the app-id can be any app, the idea is that e.g. robot-maker has a robot-oem and a robot-framework and assign the /dev/robot-brain in the oem to the robot-framework app
<mvo> asac: -^ thats right, right?
<asac> right
<mvo> pitti: yeah, there was a simiilar issue before iirc, but I don't remember the details right now without looking in the bzr log
<asac> mvo: its not app id
<asac> its part id
<asac> can be any part ;)
<asac> framework, app
<asac> ubuntu-core maybe even
<asac> (though the latter for sure not right now)
<mvo> asac: ups, I can rename that, no problem
<pitti> mvo: hm, that fix isn't in devel-proposed yet apparently (just flashed a fresh image)
<mvo> pitti: let me check
<mvo> pitti: hm, I see it at the end of /etc/system-image/writable-paths, /var/lib/systemd/random-seed but the dir is missing, thats probably the problem
 * mvo tests
<pitti> mvo: I mean /var/lib/machines/ is missing as well, tmpfiles is failing
<mvo> asac: so should I add the namespace there when I create the launcher? i.e. if I install hello-world from canonical should the part-id be hello-world.canonical? or should it be namespaceless? if you say any partid it seems we want the namespace. which makes sideloading a bit ugly and also that the oem snap needs to know the namespace of the final store package but that is probably ok
<Chipaca> lool: you around?
<mvo> pitti: I have that dir in r404
<mvo> pitti: what is your image id?
<pitti> mvo: *brown paperbag*
<pitti> mvo: no, I never forget to actually give a --channel option!
<asac> mvo: hmm
<pitti> mvo: image 404, nice! and it found it :)
<mvo> pitti: :) no worries
<asac> mvo: i think built-in field in oem snap allows both?
<mvo> pitti: hahahahaha
<asac> mvo: i think semantic should be like the install ... if no namespace is given it resolves to what really got installed and usese that
<asac> if namespace is given, it obviously uses that
<asac> if oem gives access to a part not even installed then thats a fail
<pitti> mvo: ah, /var/lib/systemd/random-seed doesn't exist at all, I figure that might be a problem as well
<asac> e.g. dont allow assigning hardware tos tauff that isnt getting installed in oemn
 * asac also feels the jet
<pitti> mvo: merely touching the file is enough
<pitti> mvo: then it actually gets mounted (that fails for nonexisting files), and now systemctl --failed is empty \o/
<mvo> pitti: nice
<mvo> asac: hm, so not allowing parts that are not installed is tricky as the oem part is installed first right now and then the others, at this point I really would like to keep it simple. I think I go with the namespace as this should not cause any problems and we can expand later(?)
<asac> mvo: ack .... lets just document it cleany
<mvo> asac: cool, I will do that
<Chipaca> mvo: about 'go remove pkg' only removing the active one, should purge do the same?
<Chipaca> mvo: there is common code there i could factor out in a branch and make it behave like that, if so :)
<mvo> Chipaca: I think purge and remove should behave the same, yeah, asac is of course the ultimate authority here but unless he says otherwise I think thats sensible
<Chipaca> i might put one of my cards back from 'in progress' to 'must do' and pick up that one, if asac can confirm
<mvo> Chipaca: ok
<asac> Chipaca: whats the question?
<mvo> asac: Chipaca> mvo: about 'go remove pkg' only removing the active one, should purge do the same?
<Chipaca> asac: should purge and remove behave in the same way wrt how its argument is interpreted? ie whether 'remove foo' should remove all forks or just the active one, etc
<mvo> heh .)
<asac> same behaviour
<asac> whether its correct as is i dont know :)
<asac> but lets stick to what we have (sound reasonable without thinking too hard)
<Chipaca> asac: there's a card to change what we have slightly
<Chipaca> asac: and what we have right now is slightly different behaviour for remove and purge
<Chipaca> asac: so we should at least make them the same :)
<Chipaca> asac: and while i'm at it, we can choose what 'the same' means :D
<asac> Chipaca: what options do we have?
<Chipaca> asac: if you have foo.canonical and foo.asac installed, should 'remove foo' remove both of them, or only the active one?
<asac> Chipaca: hmm. might be difficult, but one half of me thinks that we shoujld remove whatever the foo alias points to currently in store
<asac> but might be wrong
<asac> Chipaca: how does the world in snappy list look like?
<asac> and snappy search
<asac> i think those might give some guidance
<asac> if you could paste those for both scenarios
<Chipaca> asac: "snappy list" always shows the namespace
<Chipaca> snappy search does not, if it's got an alias
<Chipaca> snappy search seems to be missing the option to show all forks -- i thought we'd done that?
 * Chipaca is confused
<mvo> Chipaca: I have that on image r404 amd64
<mvo> Chipaca: http://paste.ubuntu.com/10855388/
<Chipaca> asac: current output of search vs list: http://pastebin.ubuntu.com/10855402/
<Chipaca> mvo: yes, not sure why my snappy was an old one -- i'd probably been testing things for an old branch on there
<mvo> no worries
<mvo> good to raise it in case there are lurking issues :)
<asac> any idwea what this 8nzc1x4iim2xj1g2ul64 43      Returns for store credit only.  is ?
<asac> Chipaca: ?
<Chipaca> asac: a package
<Chipaca> asac: it's called âReturns for store credit only.â
<Chipaca> asac: the package name is 8nzc1x4iim2xj1g2ul64
<asac> why do we see that when searching for hello-world?
<Chipaca> asac: i don't know. possibly because the icon is called 'hello.svg'? but i'm not certain
<Chipaca> asac: elastic search question
<asac> beuno: ^ is that a good package?
<beuno> asac, Chipaca uploaded it!  :)
<Chipaca> that i did! :)
<Chipaca> and it's very good. washes my dishes and everything.
<asac> Chipaca: ok, as long as that is not a bug :)
<Chipaca> indexing the icon filename might be a bug, but i'm not sure we can control that :)
<Chipaca> beuno: ?
<beuno> let me see why it matches
<asac> Chipaca: what does that package do?
<Chipaca> asac: uh... i think it's just 'hello world', renamed to something unique for testing purposes
<asac> ic
<Chipaca> asac: i wanted something i could be more or less sure nobody would find by accident
<beuno> (this is why Chipaca should never be allowed to name things)
<Chipaca> of course it turning up when looking for hello world defeats that :)
<Chipaca> beuno: hey, only *one* of my kids has a completely unpronounceable name!
<Chipaca> (for the brits, at least)
<beuno> Chipaca, the package description is "This is a simple hello world example."
<Chipaca> beuno: oops :)
<Chipaca> i guess i'll have to upload a new version that fixes that
<beuno> so ES is expecting an apologyu
<asac> Chipaca: i could imagine remove|purge --active|--inactive ... and otherwise remove all that are there
<Chipaca> beuno: good thing software is patient
<asac> Chipaca: i think having a name that is more descriptive would look nicer ... or have at least a better description stating "package with random name for testing purpose"
<mvo> pitti: hm, there seems to be still something missing in the udev foo, in the following pastebin I run udevadm trigger -v and still do not see ttyS0 even though the rule is availalbe and I called udevadm control --reload :/ details in  http://paste.ubuntu.com/10855524/ - do you have any idea(s)?
<Chipaca> mvo: ^^ asac on remove removing everything by default
<asac> note that i dont have super strong feelings, just that if i look at list it feels to me that if i type remove hello-world i would expedcrt both to disappear
<mvo> pitti: so I had to do "udevadm control --reload-rules" and "udevadm trigger" to make it appear, is that correct? it seems the trigger is a bit broad but using the specific trigger appears to not cut it
 * mvo gets lunch
<pitti> mvo: oh!
<pitti> mvo: of course, that can't work
<pitti> mvo: if the devices *had* a tag already, we wouldn't need the trigger; the new rule is the thing that adds the tag in the first place
<pitti> mvo: which is why your trigger didn't list any devices
<pitti> mvo: so yeah, do a full trigger for now
<ogra_> and a "udevadm settle" to make sure you dont add races ;)
<pitti> no, not necessary
<pitti> well, maye for apps which need to access the hardware right away, so it's indeed better, yes
<ogra_> well, i always find that safer ...
<mvo> pitti: thanks, will do
<pitti> ogra_: right
<ogra_> (if you have some late processed rule that mangles the device again or some such ...)
<asac> Chipaca: http://paste.ubuntu.com/10855615/
<asac> that one is a bit unhappy on snappy list
<Chipaca> asac: ?
<asac> Chipaca: see the paste
<asac> snappy list isnt doing anything
<Chipaca> asac: did you install anything?
<asac> all other commands are also unhappy
<asac> Chipaca: nope
<asac> Chipaca: see the ls /apps/
<asac> fresh install of the image as in paste
<asac> version version: 234
<asac> using beagleblack.canonical fwiw
<Chipaca> asac: ok, i'll look into it in a bit
<asac> Chipaca: sudo ubuntu-device-flash core --oem beagleblack.canonical --channel edge --output  mysnappy-arm.img
<asac> thats how i produdced it
<Chipaca> thanks
 * Chipaca gets some coffee
<asac> Chipaca: reproducible on amd64 kvm with sudo ubuntu-device-flash core --oem amd64.canonical --channel edge --output  my-snappy.img
<asac> guess that is quuicker to debug :)
<asac> guess its the oem snap that makes snappy unhappy
 * Chipaca builds
<mvo> pitti: thanks again, the snappy hwassign stuff works now end to end, I just tested it with https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-oem-hardware-snap/+merge/256800, ubuntu-core-launcher from the PPA and the snappy from my branch and I got access to /dev/ttyS0
<mvo> asac: -^ first successful end-to-end :-D
<asac> \o/
<asac> very good
<asac> i guess with that ogra can write his heating appliance finally :)
<asac> and start selling it :)
<ogra_> lol
<ogra_> i still have the prob that snappy cant properly handle the config in case of that app
<lool> Chipaca: i'm around, what's up?
<asac> ogra_: not sure what you mean
<asac> what config?
<Chipaca> lool: hello! have you any suggestions around how long we should wait between TERMing and KILLing a process that's been asked to stop and hasn't?
<asac> Chipaca: i think there was a field that folks could configure, but we wanted to set a maximum time theyh are allowed to request
<lool> Chipaca: less than 5 seconds
<asac> which should be pretty snappy :)
<asac> not suure if 5 seconds
<lool> Chipaca: is 5 seconds too long for your use case?
<asac> but not too far longer\
<lool> if it needs more than 5 seconds, then we shoudl have an API for it
<Chipaca> lool: there was a stop-timeout, capped at 90 seconds*, but this is not that
<lool> but the default should be less than 5 seconds
<Chipaca> um, asac^
<mvo> heh :) I suggested 15s, Chipaca went with 2s
<lool> 2s is a bit aggressive for a busy system shutting everything down
<Chipaca> lool: I had it at 2 seconds, but mvo points out that a python process on bbb takes that long to start :)
<ogra_> asac, fhem has all its config files inside the webroot and offers the user a web way to edit them ... i cant leave the files in the snappy package location (because they wouldnt be editable) and snappy wouldnt merge a new upstrema config with sme altered bits on upgrades ...
<mvo> yeah, I don't really mind, afterall there was a stop command before that already hit a timeout
<ogra_> we dont have any way to handle that scenario
<ogra_> apart from me writing higly complicated merge tools
<lool> so basically we should leave processes enough time that they can save simple state, but not unload megabytes of data
<Chipaca> mvo: note my ping to lool precedes my commit (and your review) :)
<lool> if they need to finish a long running job, or request more time, they need an API to express that
<lool> since we dont have that API for now, I'd rather we be conservative and leave it a bit longer for now
<Chipaca> 5 seconds is fine, i think
<lool> typically on the desktop you could do things like prompt the user, or show that some processes are still saving
<lool> Chipaca: yup
<lool> I believe it's also the shutdown timeout that sysv used years back  :-)
<Chipaca> this reminds me. pitti: https://twitter.com/SwiftOnSecurity/status/589981229895659520
<plorenz> hi - i wrote a simple shell script and built a snap file from it. after installing, i always get an error from app armor telling me "aa-exec: ERROR: profile 'testprojekt_mway_hello_1.0.0' does not exist". i wrote an app armor file choosing the default template and it is also installed, so what am i doing wrong?
<mvo> yeah, 5s works for me, thanks!
<Chipaca> plorenz: you wrote an apparmor file?
<Chipaca> plorenz: initially? or was that because of the aa-exec error?
<plorenz> Chipaca: i didn't initially - i just tried to solve that error ;)
<Chipaca> ah :)
<Chipaca> plorenz: that error looks a lot like an error we got while we were breaking things
<Chipaca> plorenz: maybe you're running a broken image?
<plorenz> Chipaca: could be, i'm running the raspberry pi image by lool from 15th april
<Chipaca> mmmhmm
<Chipaca> yah, that's probably got a broken snappy
<lool> hmm really
<plorenz> oh :/ is there a way to patch it?
<Chipaca> plorenz: want to update the system? then you get new, more exciting broken bits :-p
<lool> that's odd, we tested high level things liek docker on it
<Chipaca> lool: oh? interesting
<Chipaca> maybe i'm jumping to conclusions
<lool> I need to finish a couple of things then I'll try a simple snap on rpi
<Chipaca> plorenz: what are you doing when you get that error?
<plorenz> lool: thank you :) docker runs fine, also webdm
<lool> plorenz: perhaps tried an unmodified hello world; there might be a trivial typo that is causing a confusing error message
<lool> right, so other snaps get a profile
<plorenz> Chipaca: well, i have a script mway_hello and declared it as binary. i then run "testprojekt.mway_hello" and the error appears
<lool> plorenz: it sounds like there's a typo (like a name mismatch between this and that) but that we dont catch it for you
<lool> plorenz: I wonder if it's the underscore
<lool> plorenz: try with -
<lool> (that would be a bug we should catch, but wouldn't surprize me)
<plorenz> let me try that
<Chipaca> hmm, is _ valid in a binary?
<Chipaca> nope
<Chipaca> needs to match [a-zA-Z0-9+.-]
<mvo> its not right now, we might relax the rules, they are rather strict right now
<plorenz> oh okay - "snappy build" doesn't give me an error
<Chipaca> mvo: apparmor uses _ as a separator, afaik
<Chipaca> so we might need to pay more attention to some of the name mangling if we want it to be valid
<Chipaca> asac: for i in /oem/*; do mv $i $i.canonical; done will fix your image
<Chipaca> asac: it is indeed a problem with oem not having a namespace
<Chipaca> sergiusens: ^
<plorenz> aah now it's running :) thanks a bunch!
<Chipaca> plorenz: you probably don't have the review tools installed, which are the ones that would have told you about that normally
<plorenz> Chipaca: how can i install them?
<Chipaca> plorenz: (they lag a little behind, so sometimes will tell you things are wrong when they aren't, or viceversa, but are in general useful)
<Chipaca> plorenz: click-reviewers-tool
<Chipaca> plorenz: click-reviewers-tools, actually
<plorenz> Chipaca: nice, it works :) thanks, and you're all doing a great job by the way!
<Chipaca> plorenz: \o/
<asac> Chipaca: ok... thast odd, because i used beagleblack.canonical
<asac> so lets wait for serge
<Chipaca> asac: but if you look in /oem/ you'll see beagleblack, i expect
<Chipaca> asac: sergio knew this was going to be an issue. Because of your error I finally understood something he said on Friday :D
<Chipaca> I must say, sleeping 12 hours does wonders for one's comprehension of stuff
<mvo> Chipaca: could you give me a short summary of the problem or is it under control :) ?
<Chipaca> mvo: snappy quits if it finds a namespaceless snap where it expects a namespaceful one
<Chipaca> mvo: currently it expects oem snaps to be namespaceful
<Chipaca> mvo: snappy quits
<Chipaca> mvo: </summary>
<mvo> thanks, makes sense
<Chipaca> mvo: we need to either make oem snaps install themselves with a namespace, or make snappy treat them as frameworks wrt namespaces
<Chipaca> mvo: or something in between :) but right now they're broken
<Chipaca> are forks of oem snaps expected?
<mvo> Chipaca: yeah, I am slightly leaning towards option (2) but lets wait for sergiusens and his input
<Chipaca> i think sergio was too
<mvo> asac: -^-^
<mvo> I have some stuff for review in he meantime ;)
<Chipaca> maybe :-p
<mvo> (and gave feedback)
 * Chipaca looks
<asac> i dont know
<asac> i would have thought that in /apps/ frameworks also have namespaces
<Chipaca> mvo: i looked at your udev branch, and left it for somebody who actually knows udev
<asac> just that the binaries dont
<mvo> Chipaca: hahaha, so pitti needs to review it? thats fine :P
<asac> i feel we should avoid special casing namespace behaviour for new things
<Chipaca> mvo: the go code is good :)
<asac> but leave it to you guys
<Chipaca> asac: having namespaces in the files and directories impacts apparmor and such
<Chipaca> asac: hence why it's out
<pitti> mvo, Chipaca: please request a review from me, so that I'll get a mail
<mvo> Chipaca: would you prefer both branches reviewed by a udev guy? or only the one that writes the rules?
<Chipaca> asac: we had frameworks with namespaces but apparmor was all sad and aa-exec complained
<Chipaca> mvo: i'm only just looking at the other one :)
<mvo> ok, shout if I should ask for a additional reviewer for that :)
<mvo> and thanks!
<mvo> pitti: done, mail is out
<Chipaca> mvo: do you need to cd to .Path as well as give u-c-l .Path as its first arg?
<asac> Chipaca: ok. guess too late, but thought jdstrand said he could fix those namespace probs for frames
<Chipaca> asac: the other option we had was to create symlinks
<Chipaca> asac: which would've been worse, i think
<mvo> Chipaca: probably not, I think we should kill the CD and the path too, I can simplify stuff
<Chipaca> mvo: otoh it's closer to what will be done for them for services, with WorkingDirectory
<asac> Chipaca: sure. if jdstrand couldnt do it cleanly then go for that thing for release
<mvo> Chipaca: hm, good point, so I just kill it from the launcher for now
<Chipaca> mvo: some things inline
<mvo> Chipaca: I pushed the simplification now, thanks again (just omiting the baseDir in the launcher as first argument)
<mvo> Chipaca: thanks, I check that out now
<Chipaca> mvo: i see you missed the same thing i missed, wrt purge (and datadirs)
<Chipaca> mvo: package.yaml is not in the data dirs ;)
<Chipaca> mvo: and if you want to purge things that have been removed, looking for the package.yaml is not going to help
<dholbach> asac, kirkland, lool, slangasek: I sent you a mail about UOS planning - it'd be good if you could respond soon
<Chipaca> i guess i should put a comment there
<mvo> Chipaca: yeah, please do , maybe my poor jetlag brain will see it then :)
<mvo> kickinz1: btw, is the latest image good for you or do you still run into issue of stuff that does not work? I think we fixed the issues we know so it would be great if you could tell us if you need more or if its looking good
<kickinz1> testing right now the last image.
<jdstrand> fyi, we could fix the framework namespaces and make it work with apparmor
<jdstrand> he decided not to because it would make it so that namespaces had to be exposed to the apps that depended on them-- in two ways:
<Chipaca> mvo: good idea wrt making the thing inactive while purging
<jdstrand> 1. if a namespace was in the framework name and the framework policy allowed access to a file in the dir (eg, /apps/fwk.jdstrand/foo), then the framework policy would have something like '/apps/fwk.jdstrand/foo r,' in policy, then *apps* would have to use things like open('/apps/fwk.jdstrand')
<pitti> mvo: reviewed
<jdstrand> 2. since apps would have to know the framework to open(), they would then need to have in their yaml 'frameworks:\n  - fwk.jdstrand'
<mvo> jdstrand: hey, I can work on your seccomp branch and fix/update the tests if you want, my hwassign stuff is done (except for reviewer feedback and final testing)
<jdstrand> this breaks several qualities of namespaces-- they can't be forked, they must be toplevel and apps shouldn't have to know the namespace
<jdstrand> asac, Chipaca: ^ (re fwk stuff)
<mvo> pitti: thanks a lot! a detailed code reivew from you is not needed, the improtant part is that the udev rules look valid in code and tests and nothing  is obviously stupid
<Chipaca> jdstrand: yep, you were quite clear on that; i skipped over that part when telling asac about it all
<jdstrand> mvo: let me do the code cleanup first, then I can hand it to you
<Chipaca> jdstrand: sorry :)
<mvo> jdstrand: ok, either way is fine with me, I don't mind doing a cleanup along the way
<jdstrand> s/he decided/we decided/
<mvo> jdstrand: looks good fwiw from a quick look over it
<jdstrand> mvo: I'm not happy with a few of the interfaces. I'm happy to handoff, there is just some 'this works now but is ugly' bits in there. let me take out the ugly. it won't take long then I'll handoff
<mvo> jdstrand: ok, no problem. don't get me wrong, I don't want to steal it from you or anything. I just figured with the questions about the click-reviewers-tools floating around this morning that this is also somehting that you probably want to work on and need time for :) (not sure if you have seen the backlog)
<jdstrand> (2. since apps would have to know the framework *namespace* to open(), they would have need...)
<asac> jdstrand: thats not clear to me... i thought that frameworks would export the parts that apps would refer to in PATH or LD_LIBRARY_PATH etc.
<jdstrand> mvo: I haven't and I want you to take it-- it wasn't ready to be reviewed just yet
<asac> jdstrand: why does app need to know where framework is on disk?
<jdstrand> asac: it depends on how the framwork is written. I said *if* a framework exposes a file
<jdstrand> and people will do it cause that is easy enough to do
<jdstrand> I literally just came online now-- why are we having this discussion now?
<Chipaca> jdstrand: probably because we broke snappy on the image if it has an oem installed
<jdstrand> let's fix that rather than reworking namespaces :)
<jdstrand> look, if people want to have .namespace in the fwk, we can fix apparmor (requires some patches). however, if we do we are redefining some qualities of frameworks
<jdstrand> and we are making it more difficult for consumers of the frameworks
<jdstrand> (yes, we could have an alias for a fwk, but are apps supposed to depend on an aliased name for a framework? I think not-- if the alias changed all those apps could break)
<jdstrand> I'm of the opinion that the dev experience is paramount and maintain my opinion that frameworks should not be namespaced
<jdstrand> if we are adding namespace back to the name, I need to know soon so I can update click-apparmor
<asac> mvo: Chipaca: i assume you guys have fixing regexps etc. for failures of self test in backlog?
<asac> https://jenkins.qa.ubuntu.com/job/vivid-core_devel_proposed-genericamd64-smoke-selftest/45/artifact/results/core-ubuntu-core_devel-proposed-generic_amd64-404-results/log/*view*/
<asac> Can not find '^No package 'fizzler' for ubuntu-core/devel.*' in 'Installing fizzler
<jdstrand> tyhicks: hey, we need someone to review mvo's launcher branch with highest priority. it includes seccomp, cgroups and I think namespace (for /dev/pts). can you work with mvo and get soemone on that? (sorry for the short notice)
<mvo> jdstrand: no namespaces yet, sorry, if its important I can look into that next though
<jdstrand> that's ok for now. we should add a trello card/file bug though for post 15.04
<tyhicks> jdstrand: sure
<tyhicks> mvo: can I get a link to the branch?
<mvo> tyhicks: its here https://code.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk
<sergiusens> mvo: Chipaca I am finally here! Landed, drove home, slept (not even unpacked); what the executive summary?
<tyhicks> mvo: thanks!
<mvo> sergiusens: no catastrophes so far :)
<mvo> jdstrand: I wonder if http://paste.ubuntu.com/10856229/ would make sense? or is snappy build setting the wrong defaults here?
<sergiusens> mvo: Chipaca oh, oem; it's weird since I've been working with them with my branches (which I couldn't push yesterday as I had no ssh at the airport and no proxy I could use to get over that)
<jdstrand> mvo: yes-- likely. let me check
<jdstrand> we have to rework all this with the new world
 * sergiusens puts on some wake up *faster* music
<jdstrand> mvo: is the Architecture field from DEBIAN/manifest used by snappy in any way?
<mvo> jdstrand: no, 99% sure it does not
<jdstrand> beuno: can you sync the store with r442?
<beuno> jdstrand, sure
<jdstrand> beuno, mvo, jodh (and asac): that ^ should fix the review tools for all warnings/errors for *default* snappy builds, except for hashes.yaml
<jdstrand> security yaml/other checks are not in there (will pick those and hashes up later this week)
<jdstrand> this is for 'type: app'. other types will have other issues (but again, will pick up this work later this week)
<mvo> jdstrand: nice, thanks a bunch
<jdstrand> dholbach: hey, are you up for uploading click-reviewers-tools based on the r442 branch?
<dholbach> jdstrand, sure
<jdstrand> dholbach: thanks! that doesn't have the big changes, but it has important small changes (see backscroll)
<dholbach> cool - great work everyone
<mvo> jdstrand: if you could ping me once the cleanup for the seccomp branch is done, that would be great
<jdstrand> mvo: yes-- it is close. I have one last thing after the meeting)
<mvo> jdstrand: no rush, I will get dinner and see what I can do after that
<dholbach> jdstrand, uploaded and accepted :)
<jdstrand> dholbach: thanks!
<dholbach> anytime
<sergiusens> asac: so amd64.canonical -> amd64 is fine?
<sergiusens> forgot to get the explicit ack
<asac> sergiusens: amd64-generic.canonical maybe? not sure
<sergiusens> asac: okie dokie, will re upload then as that
<asac> we dont use -generic for beagleblacks either
<asac> PC-amd64.canonical :)
<asac> :)
<sergiusens> asac: ok, keep in mind it will be all lower case
<asac> hmm
<asac> just more ideas
<asac> efi-amd64
<sergiusens> pc-amd64 or x86-amd64
<jdstrand> mvo: have we defined/implemented specifying no caps yet?
<sergiusens> asac: oh, efi and legacy bios boot options would be implicit according to my discussions last week with slangasek
<slangasek> they should absolutely not be separate channels/images
<mvo> jdstrand: that should work if you put "caps: []" there
<asac> slangasek: what you think about us naming oem snap that defines our amd64 generic base image pc-amd64 ?
<mvo> jdstrand: I think there is even a test for it, I can search for the branch that implements it, one sec
<asac> currently its named amd64.canonical :)
<mvo> jdstrand: I nocited you pushed a new seccomp branch, does that mean I can hack away now ;) ?
<slangasek> asac: why "pc"?
<asac> not sure... beuno didnt like it
<asac> to be just amd64
<asac> and the snap name feels weird to me too
<slangasek> if this is just about the oem snap name and doesn't require me to change anything on the channels, I'm fine with it ;)
<jdstrand> mvo: yes, though I will have another change or two for the override bits
<slangasek> but why not 'generic-amd64'?
<mvo> jdstrand: cool, want to merge my branch that makes the tests pass again?
<slangasek> generic is nice and generic
<asac> slangasek: thats cool
<asac> thanks
<jdstrand> mvo: yes please
<jdstrand> mvo: where is that?
<jdstrand> mvo: this is click_test.go?
<asac> sergiusens: slangasek is the man from now on to pick those names :)
<asac> generic-amd64 it is
<slangasek> heh
<asac> thing is that there wont be a generic-armhf
<mvo> jdstrand: lp:~mvo/snappy/snappy.seccomp and there ./run-checks should hopefully work
<asac> just beagleblack :_)
<mvo> jdstrand: if not, shout at me :)
<asac> but tahts fine
<asac> slangasek: i thought maybe its ibmcompatible :)
<slangasek> hah
<asac> but guess thats not the term these days for all those amd64 machines, or is it?
<mvo> jdstrand: still lacks tests for the new stuff, you can also do "cd snappy && go test" to just run the snappy speciific ones
<mvo> jdstrand: I also ran your branch on my snappy test system and it worked nicely
<slangasek> indeed, lots of these things are not very "personal computer" :)
<mvo> jdstrand: anyway, I get some dinner now and will read scrollback, let me know if there is anything else that I can do, I will try hard to get the branch ready for review this evening so that we are really feature complete and that it all can land
<plars> sergiusens: can an image be successfully built for BBB now, and if so, what are all the pieces we need? I know you said on friday that the beaglebone.sergiusens one is no longer the one to use?
<sergiusens> plars: I need to release the udf I worked on during the weekend
<slangasek> sergiusens: to properly support BIOS+EFI, ./diskimage/core_grub.go needs some concept of the target architecture.  How should the interface to this look?
<sergiusens> slangasek: architecture as in amd64 and armhf or a different layer of the arch concept?
<sergiusens> slangasek: I can get that going quickly if not needed by today (as in, do it tomorrow)
<slangasek> sergiusens: should only be amd64 vs. i386 vs. armhf, as far as I know
<slangasek> I'm assuming the only ARM grub target we're supporting is efi
<slangasek> oh, and arm64
<slangasek> which is definitely efi
<beuno> jdstrand, review scripts are updated
<sergiusens> slangasek: k; I can work on this tomorrow; mind creating a card with all the requirements under a checklist so I don't miss anything?
<slangasek> sergiusens: hey, I wanted to hack on this, you're depriving me of the opportunity ;)
<slangasek> I was just looking for guidance on where you wanted the architecture exposed in the interface
<sergiusens> slangasek: ha, this needs some sort of refactor; but if you want to; feel free, just don't lose any hair :-)
<sergiusens> slangasek: architecture is exposed in the oem structure as oem.Architecture()
<slangasek> ok
<sergiusens> but you might get lost with all the backwards compatibility code paths
<slangasek> :-)
<jdstrand> beuno: thanks!
<sergiusens> asac: so I am going with x86-amd64 then for the oem package
<jdstrand> mvo: ok, branch updated. going to do some more blackbox testing
<mvo> jdstrand: cool, feel free to prpose for merging if you feel its ready, I will do a followup branch on that with added tests later tonight
<mvo> jdstrand: this way maybe Chipaca or sergiusens can do a review and we can hopefully build a test image with the feature tonight and I can make the launcher "strict" again (i.e. fail if seccomp policy file can not be found)
<slangasek> sergiusens: "x86-amd64"?  do you mean "x86-64"?
<slangasek> x86-amd64 is awfully confusing
<sergiusens> slangasek: ok then
<jdstrand> mvo: the launcher on the image applies seccomp policies?
<sergiusens> slangasek: I really don't care; IOW, I just want to make the managers happy :-)
<mvo> jdstrand: it does, if it finds them
<slangasek> sergiusens: I thought the managers were already happy with generic-amd64 ;)
<jdstrand> ah good, that will help me in testing our seccomp policy with existing snaps
<jdstrand> (which is next on my list)
<sergiusens> slangasek: heh, asac wasn't as it was inconsistent with beagleblack (no generic word in there)
<mvo> jdstrand: cool!
<slangasek> sergiusens: "<asac> but tahts fine" ;)
<slangasek> sergiusens: anyway, I'm fine with either
<sergiusens> slangasek: oh, I missed that; so choose which one; last change before I upload ;-)
<slangasek> sergiusens: whichever one is quicker to implement!
<slangasek> ;P
<sergiusens> slangasek: lol, it's just a string
<mvo> jdstrand: keep me updated, I will be a bit on-and-off in irc in the next ~1h or so
<mvo> but will read scrollback
<jdstrand> mvo: ok, I proposed a merge
<mvo> ta
<jdstrand> mvo: thanks for your help on this :)
<sergiusens> mvo: btw, I fixed the error message for installing inexistent packages and removed the channel part as it was conceptually wrong (the channel is per package, not the system one)
<jdstrand> oh shoot a conflict
 * jdstrand fixes
<sergiusens> jdstrand: yay, nice to see one less warning :-) https://myapps.developer.ubuntu.com/dev/click-apps/2407/automated-review/
<sergiusens> jdstrand: mind to review btw :-D
<jdstrand> done
<jdstrand> mvo: ok, merge with trunk and conflicts resolved. there is one new test failure in purge_test.go that I left
<jdstrand> merged*
<sergiusens> beuno: alias for generic-amd64(.canonical) please?
<jdstrand> mvo: I'm moving on to policy testing now (unless I get feedback from others on the branch)
<mvo> jdstrand: ok, I take care of that, we can't (tarmac prevents that) merge with test failures, but no worries
<beuno> sergiusens, can you ask nessita instead, otp for a while
<sergiusens> beuno: sure, not sure who is able to do this still :-P
<beuno> sergiusens, it's a state secret
<sergiusens> lol
<tyhicks> jdstrand, mvo: the snappy launcher review is just a general security team review or is it for a MIR?
<jdstrand> tyhicks: both really
<mvo> tyhicks: I'm not sure what the difference is, but the seeds will probably pull it into main. how is it looking so far?
<tyhicks> mvo: sorry, just getting to it now
<mvo> tyhicks: no problem, I'm just curious :)
<jdstrand> tyhicks: this is sensitive code, so the MIR would need a security team review. we want to give it extra special review. whoever does the MIR can say that the security team already reviewed it and signed off
<tyhicks> jdstrand: ack
<nessita> hello all
<jdstrand> tyhicks: the MIR review is 'can we maintain it?'. this is more than that
<tyhicks> right
<asac> sergiusens: slangasek: i guess we will get feedback on the naming decision one way another later
<asac> e.g. loets go with what steve said
<beuno> asac, already being done
<tyhicks> mvo: should your launcher build tests pass during a build in an amd64 schroot?
<tyhicks> mvo: the test_restrictions test fails for me: http://paste.ubuntu.com/10857373/
<mvo> tyhicks: let me try that in a schroot
<tyhicks> (vivid-amd64 host and vivid-amd64 schroot)
<mvo> tyhicks: do you see anything special in dmesg?
<mvo> tyhicks: just tested on a trusty-schroot and it works here, but I had to install the build-depends, let me create a vivid-schroot
<tyhicks> mvo: I don't see anything special in dmesg
<mvo> tyhicks: what personality did you use for the schroot?
<tyhicks> mvo: it is a slightly one-off schroot profile that the security team uses
<tyhicks> mvo: if it builds for you in your vivid-schroot, I'll chase down my local issues
<mvo> tyhicks: ok, I will try with one of the default ones, maybe you guys block something seccomp releated? the test just creates a empty profile, loads the seccomp filter and runs /bin/true and checks that it got killed
<tyhicks> yeah - I was surprised that it didn't work
<mvo> tyhicks: it works here with the desktop profile, I can try harder later once I finished my other work with a different profile
<tyhicks> mvo: no worries - I'll sort it out on my end
<tyhicks> mvo: sorry for the distraction
<mvo> no worries, I am super thankful for this review
<jdstrand> mvo: r404 on amd64 doesn't seem to have the launcher-- or if it does, I may be doing something wrong
<jdstrand> mvo: /apps/bin/... still has aa-exec. I don't see an ubuntu-core-launcher package on the image
<plars> ogra_: around? I'm still having weird issues with booting the beaglebone and wondering if you can help
<mvo> jdstrand: yeah, sorry that has not landed, you can sudo /usr/bin/apt-get install ubuntu-core-launcher to get it and copy a new snappy manually or wait ~1-2h and I will try to get a new image out with seccomp
<ogra_> plars, i havent touched my bone in months ...
<ogra_> plars, bu i can try indeed :)
<jdstrand> mvo: ack, thanks. I think there may be a bug in framework policy install that I'll try to track down for the moment
<plars> ogra_: I'm just trying to sort out how to make it boot to the emmc when I have a snappy sd in the sd card slot
<plars> ogra_: my understanding was that it *should* do that by default when you don't press the boot select button, but it appears to scan the sd card and boot to the sd by default
<plars> ogra_: I've at least sorted out how to force it to boot to the SD when I hold the boot select button (as it should), but I need it to be selected based on that button ideally - so that we can keep a stable image on emmc and use it to flash a new snappy image on the sd, then force it to boot into sd
<ogra_> plars, you can forceit to SD by zeroing the first few bytes of the MMC
<plars> ogra_: so is that where it's finding uboot? on those inaccessible partitions of the emmc?
<plars> ogra_: I can force it to the sd just fine now, my problem is the opposite - I would like it to boot to the emmc by default unless I'm holding the s2 button
<plars> so... ignore the sd card in the slot unless I press the button
<plars> I think I could do it if I could modify the uboot environment, but there is no saveenv when I boot from the emmc. And any changes I make when booting the sd card and run saveenv, don't show up when I boot from emmc
<ogra_> plars, i have never done much with the bone ... only up to XM ... i got my first BBB when i strted doing stuff on snappy
<ogra_> plars, i suspect #beagle would be a better source of info, i dont knowmuch about the HW specifics
<plars> ogra_: ack, thanks
<ogra_> (i.e. the zeroing of the MMC is the actual only BBB specific thing i know :) )
<mvo> jdstrand: fwiw, I removed all caps from hello-world, so no networkig there anymore and thats also a good example how to do it
<jdstrand> mvo: cool, I tried [] here too and it worked fine
<mvo> Chipaca: please let me know if there is anything else that the seccomp branch needs
<Chipaca> mvo: i've not been able to look at it yet; got a long phonecall
<Chipaca> am off of it now though :)
<mcaley> mcaley here from GE Firstbuildâ¦ Iâve been working with kirkland and a few others to get snappy running to control a GE fridge from a pi. ive got the snap all working fine, now ready to put pi in the actual fridge. that means replacing hardwire connection with wifi. is there a correct way of doing rootfs stuff? I have seen several posts about remounting system_a r/w and loading the deb packages, but then Iâll have
<mcaley> redo if it do a system update. i am running ubuntu-core 4.
<AppleCIDR> Is Node.js available for Snappy Core? I can't find much information on it
<ogra_> AppleCIDR, https://ograblog.wordpress.com/2015/02/21/meet-node-snapper-a-helper-to-easily-create-snap-packages-of-your-node-js-projects/
<AppleCIDR> Fantastic!
<mcaley> to get going really quick i just pulled my node and tarball as ogra has in his blog from a raspian build
<ogra_> yeah, that would surely work too
<mcaley> ogra_ a couple of us at firstbuild want to build a qemu service for doing snappy builds that is hostedâ¦ any plans for somethign like that?
<ogra_> unless you need npm ...
<mcaley> right
<ogra_> i dont have any such plans, no :)
<ogra_> if you add 24 more hours to the day i might find the time :)
<mcaley> ok, we may take a stabâ¦.
<mcaley> :)
<kirkland> mcaley: howdy!  thanks for joining us here!
<sergiusens> jdstrand: kickinz1 asac: plars http://blog.sergiusens.org/posts/Updates%20in%20snappy%20and%20ubunu-device-flash/
<kirkland> asac: lool: hiya!  mcaley is looking for some help correctly configuring wifi in a snappy image -- can you point us to any documentation?
<tyhicks> mvo: can src/overlay.[ch] go away? (the functions defined in that file are not used anywhere)
<mvo> tyhicks: yes, that can be killed, its cruft right now (we probably will add somehting like this later but not now)
<tyhicks> mvo: ack - I'll ignore that code
<asac> mcaley: hey
<mcaley> ho
<asac> mcaley: so far we dont have built in wifi config feature; however we have wpasupplicant;
<asac> mcaley: so if you do a framework you would use that one directly
<mcaley> ok, np.. just wanted confirmation before i hacked it up
<asac> right
<mcaley> thx
<asac> mcaley: so make your own config mechanism in your app and use ifconfdig up + wpasupplicant + dhclient :)
<mvo> tyhicks: gone in r28
<asac> sergiusens: am i on wrong channel now that i have image 6?
<asac> or is that rolling/edge rename now 6?
<asac> on armhf
<jdstrand> sergiusens: re blog> is 14.10 up to date?
<asac> sergiusens: so i think with beagleblack oem snap
<asac> the hostname doesnt work
<asac> it still tells me @localhost on prompt
<asac> but i saw in config its beagleboneblack as hostname
<mvo> asac: hm, jodh worked on this a while ago, does /etc/hostname look correct?
<asac> no
<asac> but it looked ok on the previous image i had with beagleboneblack.sergiusens
<asac> i think it broke in recent oem snap reconfigure
<mvo> ok, then its something else
<asac> maybe because of namespace rename
<asac> (BeagleBoneBlack)ubuntu@localhost:~$ cat /etc/hostname
<asac> localhost.localdomain
<asac> hmm
<asac> nevermind
<asac> there is no hostname
<asac> in http://paste.ubuntu.com/10858216/
<asac> yay
<asac> i used ubuntu-core config to change hostname :)(
<mvo> :)
<asac> wonder if that persists across reboot
<asac> http://paste.ubuntu.com/10858231/
<asac> sergiusens: how do i use udf to create an image without ubuntu user? guuess thats not supported yet?
<mvo> it should, there was a bugfix for tihs
<mvo> the reboot-hostname-persistance
<mvo> no idea about the other
<sergiusens> asac: if you do it through snappy config it would persist
<asac> yeah
<asac> let me reboot until we have auto reboot
<asac> ok good hostnames persist across reboot
<asac> now when there is new iamge i can try with upgrade even
 * asac goes all-in and installs docker on his beagle
 * asac thinks SD cards are not made for big things
<asac> good docker seems to be running
<asac> now i need instructions how to easily try it on arm
<asac> kickinz1: do you have those ?
<kickinz1> asac, sorry, wasn't there.
<kickinz1> asac: what do you need? instructions to test docker on arm?
<asac> kickinz1: how to install and use docker iamge for armhf
<asac> woudl be nice
<kickinz1> You have a bbb with snappy?
<asac> yep
<asac> its running
<asac> i have docker running too
<asac> docker images
<asac> REPOSITORY          TAG                 IMAGE ID            CREATED             VIRTUAL SIZE
<kickinz1> So for some smole tests, you can install docker on snappy then issue 'docker run -it armbuild/ubuntu'
<kickinz1> s/smole/smoke/
 * asac runs that command
<asac> ok itws pulling stuff
<asac> kickinz1: so hgow do i use that imnage now?
 * asac is docker illeterate
<asac> oh i think i am in it :)
<asac> root@ed4e2b9bf2ea:/#
<asac> hehe
<kickinz1> asac, if all the download was fine, yes you are in it.
 * asac runs apt-get update
<asac> kickinz1: how can i reuse that container tomorrow?
<asac> or lets say i log out
<asac> can i relog-in?
<kickinz1> asac: yes, just issue a docker ps -a, you will see the conatiner with a random name and a unique id.
<asac> kickinz1: is that running after boot?
<asac> i see it now
<asac> http://paste.ubuntu.com/10858375/
<asac> kickinz1: thats pretty cool
<asac> however its suspicious
<asac> hmm
<asac> not sure why
<asac> kickinz1: how can i log into that again?
<mvo> asac: I triggered a new image build, it should contain all the new stuff, hardware assign support, purge support and seccomp launcher support. build for amd64 (r405) should be available in ~20min or so. I need some sleep but testing welcome, I also queued a full build in 30+min or so
<kickinz1> asac: yes, random names.
<mvo> Chipaca: thanks again for your reviews, I get some rest now
<Chipaca> mvo: rest is good
<mvo> sergiusens: plesae mail me if you need reviews in my morning (in +7h)
 * mvo waves
<asac> yay
<asac> i started the container
<kickinz1> asac: docker start suspicious_sinoussi
<asac> and attached
<asac> success
<kickinz1> asac: ok
<asac> kickinz1: does it always stop when i exit the shell?
<kickinz1> asac, yes in interactive mode.
<asac> kickinz1: nowe that i started it
<kickinz1> asac, else you have to make it run a doeamon or a process.
<asac> and attached will it be stopping again?
<asac> ok
<asac> dont woorry
<asac> as long as i can get into that thing i am happy enough
 * asac installs git-core in docker
<asac> heh
<kickinz1> asac: I have also a docker_template snap if you want to try docker containre as a service for snappy that will start at boot time.
<kickinz1> asac: http://bazaar.launchpad.net/~kick-d/+junk/docker_template/
<sergiusens> Chipaca: https://code.launchpad.net/~sergiusens/snappy/lockDownRemove/+merge/256849
 * Chipaca pulls out his big angry button of (-1) disapproval
<sergiusens> Chipaca: oops
<asac> hmm so i am doing a wildcard search
<asac> and it returns zero hits
<Chipaca> sergiusens: hmmmm
<sergiusens> Chipaca: want me to move mvo's changes back to snap.go?
<Chipaca> wat?
<sergiusens> Chipaca: then what is the hmm about?
<asac> http://paste.ubuntu.com/10858447/
<asac> is that a problem?
<asac> Chipaca: sergiusens ?
<sergiusens> asac: are you on rolling or 15.04 is hello on rolling or 15.04?
<asac> sergiusens: well i installed docker
<asac> but search *
<asac> returns zero
<asac> too
<Chipaca> sergiusens: i understand the objective of your branch is to not allow uninstalling preinstalled software
<Chipaca> asac: pastebin that please
<asac> sergiusens: http://paste.ubuntu.com/10858450/
<asac> Chipaca: http://paste.ubuntu.com/10858450/
<Chipaca> ta
<sergiusens> Chipaca: want me to split it?
<Chipaca> sergiusens: is that ^ the objective of the branch?
<sergiusens> Chipaca: in file movement and new feature?
<asac> how odften do we produce images?
<sergiusens> Chipaca: yes it is
<asac> can we increase that to every 1h ?
<asac> for now?
<asac> slangasek: ^
<Chipaca> sergiusens: what should the behaviour of that be?
<asac> slangasek: i think for testing would be nice that we get new ones all the time :P
<sergiusens> Chipaca: if the to be removed file is in built-in it can't be removed
<Chipaca> sergiusens: that is: your branch lets you remove the software that was preinstalled, as long as you've installed a newer version
<Chipaca> sergiusens: is that the right behaviour?
<sergiusens> Chipaca: yeah, similar to the oem package; if you factory reset in the future, the original preinstall will always be there
<Chipaca> sergiusens: ok
<Chipaca> asac: you need to tell us how you created the image you're running, and when, and the output of system-image-cli -i would be nice as well
<sergiusens> asac: I get all this http://paste.ubuntu.com/10858465/
<Chipaca> asac: because it's not the first time _today_ you've tinkered with an old/weird image :)
<slangasek> asac: I'll do that for now; I don't know if that will cause a load problem across the buildds, we'll have to test and find out
<sergiusens> asac: I did a 15.04 flash fwiw
<sergiusens> Chipaca: if we need to request the output of s-i-cli we did something wrong with snappy [info|list] ;-)
<sergiusens> both of those should be enough
<Chipaca> sergiusens: both of those, or either of those?
<asac> odd
<Chipaca> sergiusens: (yes, you have a point, my bad, etc)
<asac> Chipaca: sergiusens: sudo ubuntu-device-flash core rolling --oem beagleblack --channel edge --output  my-snappy.img
<sergiusens> asac: search only stopped working after installing docker?
<slangasek> sergiusens: I really have no idea what's going on here, it looks like mastering the image is unreliable.  I'm now sure that I've gotten a proper boot partition at least once using revision 160... but most of the time it fails
<sergiusens> slangasek: show me your fixes; use 162 btw with what I have in the blog post
<slangasek> sergiusens: this is with *no* changes from me; and I'm using 160 instead of 162 because I wasn't getting it to work with 162; and what blog post?
<sergiusens> slangasek: or sudo ubuntu-device-flash core rolling --channel edge --output test.img
<sergiusens> or s/rolling/15.04/
<sergiusens> slangasek: http://blog.sergiusens.org/posts/Updates%20in%20snappy%20and%20ubunu-device-flash/
<asac> sergiusens: didnt test before
<asac> sergiusens: i have image 6 accordintg to channel.ini
<sergiusens> asac: yeah, snappy list and snappy info give you that info
<asac> channel: ubuntu-core/rolling/edge
<asac> sergiusens: you say i should try flashing new?
<asac> to check if its docker?
<sergiusens> asac: to check if installing a framework breaks the world, yes
<Chipaca> i have docker installed
<Chipaca> on amd63
<Chipaca> or 64
<Chipaca> and it works
<sergiusens> I'm installing docker now
<sergiusens> on armhf
<slangasek> sergiusens: I used this commandline; still the same problem: ubuntu-device-flash --verbose core 15.04 --channel edge -o system-image-test-proposed.img.raw --device generic_amd64 --developer-mode
<sergiusens> slangasek: so no boot when doing that? Are you bzr bd'ing by any chance?
<slangasek> sergiusens: yes, it's bzr bd
<slangasek> sergiusens: and yes, no boot
<sergiusens> slangasek: not sure if all the dependencies with the versions required are on vivid, can you make sure they match the ones on ppa:snappy-dev/images?
<sergiusens> slangasek: or maybe try the u-d-f from ppa:snappy-dev/tools and tell me if you see the same
<slangasek> ok, looking
<asac> sergiusens: ok let me first try uninstall that
<sergiusens> Chipaca: asac: installing docker indeed limits the results
<Chipaca> hoo!
<sergiusens> http://paste.ubuntu.com/10858541/
<sergiusens> Chipaca: I think I know why; if we pass the framework in the store, it might be filtering
<sergiusens> to the store
<tyhicks> jdstrand: a regular user will be able to run ubuntu-core-launcher, right?
<jdstrand> tyhicks: yes
<slangasek> sergiusens: golang-ar-dev, golang-yaml.v2 are at the same versions in ppa:snappy-dev/image as in vivid.  golang-snappy-dev has a newer version in the ppa.  So I'll take a look
<tyhicks> jdstrand: thanks - I'm trying to decide the best way to sanitize the input arguments and wanted to confirm that before I spent too much time on it
<asac> sergiusens: seems framework break search
<asac> yes
<sergiusens> asac: I guess we need to talk to the store guys; not sure if Chipaca is already playing with random queries to verify
<asac> sergiusens: :)
<sergiusens> I need to brb
<asac> sergiusens: http://paste.ubuntu.com/10858559/
<asac> on beagle :)
<asac> ghuess we should really refuse to install a new oem
<jdstrand> tyhicks: np-- and thanks for looking at that
<sergiusens> asac: that was working until all the switch work happened ;-)
<sergiusens> asac: I guess we need to hardden our tests
<asac> jojo
<asac> want me to file something?
<asac> or rather remember :P
<sergiusens> tbh, I wasn't aware that today was last call and that we had until thursday for polish
<jdstrand> Chipaca: ok, I figured out my issue. if I have a framework snap that has a binary that references a cap that is shipped by the framework policy of the same snap, then it fails to install
<asac> sergiusens: :)
<Chipaca> jdstrand: should that work?
<asac> its important to last call early!! :P
<sergiusens> asac: a task will do
<asac> but not too early
<sergiusens> asac: not really, then we do things in a hurry and miss stuff ;-)
<asac> sergiusens: at least we have two days to fix those now
<asac> better than zero
<Chipaca> sergiusens: so this is a bug because frameworks should add to the list of results, not substract from it, correct?
<jdstrand> Chipaca: it wasn't every really discussed, but I noticed with both docker and my test dbus framework that it is very handy
<slangasek> sergiusens: upgraded golang-snappy-dev; same outcome
<Chipaca> jdstrand: darn :)
<jdstrand> Chipaca: let me see if it is just a simple ordering thing. if we unpack the framework policy first we should be ok
<sergiusens> Chipaca: correct
<sergiusens> brb
 * Chipaca ponders dinner
<jdstrand> Chipaca: I'm right in this area of the code, so enjoy dinner. if needed, I'll file a bug
<Chipaca> jdstrand: let me know, if it's just ordering i might sneak it in
<jdstrand> yep
<Chipaca> dinner will be quick either way :)
<jdstrand> heh
<asac> sergiusens: https://trello.com/c/8E2zsHNV/322-snappy-install-oem-must-fail-cleanly-if-run-on-running-snappy-system
<asac> added
<slangasek> sergiusens: so you're saying this command definitely works for you on amd64 with rev 162, and gives you a correct boot partition? 'ubuntu-device-flash --verbose core 15.04 --channel edge -o output.img'
 * asac tries steves command
<asac> sergiusens: that command produces something for me that boots in kvm
<asac> and is version 8
<asac> not 162
<asac> slangasek: http://paste.ubuntu.com/10858591/
<asac> sergiusens: sorryt .... wanted to highlight steve
<asac> slangasek: ^
<slangasek> asac: rev 162 of ubuntu-device-flash
<asac> kk using the package ... think udf could really benefit from udf version command :)
<slangasek> and installing the package from the tools repo, I get this error - what's the fix?: 2015-04-20 22:18:27 ERROR snappy logger.go:199 generic-amd64 failed to install: unpack helper not found, do you have snappy installed in your PATH or GOPATH?
<asac> 0.20snappy5-0ubuntu1
<asac> slangasek: so above i had troublbes because of missing depends of udf on the right snappy thing
<asac> slangasek: sudo apt-get install ubuntu-snappy-cli
<slangasek> asac: thanks
<slangasek> btw, looks like we've inflicted a namespace collision on the archive now; command-not-found wants me to install the 'snappy' package for the snappy command, which is clearly wrong
<Chipaca>  snappy is a media player that gathers the power and flexibility of
<Chipaca>  GStreamer inside the ease of a minimalistic Clutter interface.
<slangasek> ok, the version from the tools ppa works; and building rev 164 for myself works (at least once, so far)
<slangasek> make that twice
<slangasek> and now when I apply my diff, udf works as expected
<lool> kirkland: wifi will be cmdline only wpasupplicant and such; I didn't set it up myself, but we made sure the low level tools are in the image
 * Chipaca back
<jdstrand> Chipaca: arg, false alarm. I had a bug in my apparmor policy but all I got from snappy was 'exit status 1' so it took me far too long to figure out the issue
<Chipaca> jdstrand: :(
<jdstrand> tyhicks: hmm, I just ran ubuntu-core-launcher and it doesn't seem to be doing an aa_change_profile() correctly
<jdstrand> tyhicks: I'm using what is in the ppa (https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages). let me pull that down and see if it is missing any changes
<tyhicks> jdstrand: I have only invoked it in order to abuse it and haven't actually tested it in its intended mode
<tyhicks> jdstrand: it just calls aa_change_onexec(argv[2])
<tyhicks> jdstrand: that shouldn't fail if 1) the profile is loaded and 2) argv[2] contains the correct profile name
<jdstrand> tyhicks: we need to fail if the profile isn't loaded
<tyhicks> jdstrand: agreed - is that not happening?
<jdstrand> well, right now things are unconfined
<jdstrand> but my vm seems weird. let me retry in a new vm
<tyhicks> jdstrand: oh, I see the problem
<tyhicks>     if (getenv("SNAPPY_LAUNCHER_SKIP_APPARMOR") != NULL) {
<tyhicks>        // set apparmor rules
<tyhicks>        rc = aa_change_onexec(aa_profile);
<tyhicks> jdstrand: that getenv() conditional is backwards
<tyhicks> jdstrand: there are some other issues - I'll add that to my list and send out what I have so far before I go eod
<jdstrand> sudo snappy install hello-world.jdstrand
<jdstrand> hello-world.evil  ; ls -1 /tmp/myevil.txt
<jdstrand> Hello Evil World!
<jdstrand> /tmp/myevil.txt
<jdstrand> tyhicks: that sounds great. mvo went offline, so if you can send an email, that would be perfect
<tyhicks> jdstrand: ack - that was my plan
<tyhicks> jdstrand: so, a workaround for now is to set the SNAPPY_LAUNCHER_SKIP_APPARMOR env variable :)
<sergiusens> slangasek: oh, sorry, forgot to mention the asac incidence
<asac> guess it helped ;)
<jdstrand> tyhicks: yep, thanks. I added a trello card for the apparmor issue but said to look at feedback from you
<sergiusens> asac: yes, I did create a branch to dep on ubunut-snappy-cli now
<tyhicks> jdstrand: is it ok to set NO_NEW_PRIVS? (it is currently being set but it'll prevent any AA profile transitions)
<jdstrand> tyhicks: hmm, I had it setting NO_NEW_PRIVS cause I thought it would prevent some attacks. however, if we aren't allowing the seccomp or ptrace syscalls, we likely don't need it
<tyhicks> jdstrand: I think it is a good thing until we want to start doing profile transitions
<jdstrand> tyhicks: well, docker does them already
<tyhicks> jdstrand: hrm... I bet docker won't work with this launcher
<jdstrand> that is an interesting point. can you add it to your feedback?
<tyhicks> yes
<jdstrand> I figured we would use @unrestricted to the seccomp bits, but I'm guessing the cgroup parts will also be a problem
<jdstrand> s/to the/for the/
<jdstrand> ok, I gotta run
<tyhicks> jdstrand: NO_NEW_PRIVS is only a seccomp thing so it shouldn't affect the cgroup part
<tyhicks> jdstrand: also, NO_NEW_PRIVS is set after the cgroup setup
<tyhicks> jdstrand: bye!
<sergiusens> asac: oh, fwiw, the 162 is the trunk revno :-)
<asac> sergiusens: yeah ... thinking udf version could have nice info :)
<Chipaca> raise your hand if you think âMake installing a framework restarting dependent apps services failing revert the installation, restarting dependent apps servicesâ is only marginally less hard to follow than the quagmire of deferred failure handling it engenders
 * sergiusens raises the hand just from failing to understand the sentence
#snappy 2015-04-21
<asac> Chipaca: whats that?
<asac> :)
<asac> from the docs?
<sergiusens> just a commit message
<Chipaca> asac: a card, a description of a task, a branch, and a commit message
<Chipaca> asac: i was in a maze of so many deferreds for a moment i thought i was programming twisted again
<asac> oha
<asac> Chipaca: was that your card :)?
<asac> hehe
<asac> you could have reworded it
<asac> guess its hard to convey what that should do :)
<Chipaca> asac: maybe :)
<Chipaca> asac: maybe it was fun, also
<kirkland> lool: okay, wpasupplicant has always been primitive and tricky, in my experience
<dholbach> good morning
<mhall119> mvo: does the PPA listed on https://developer.ubuntu.com/en/snappy/start/ need to be changed?
<mhall119> didrocks tells me the beta PPA actually has an old version of snappy
<mvo> mhall119: indeed, utopic and trusty are outdated, I updated them now, so that shold be fine. we may still want to use a different one when snappy gets released (i.e. the beta name sounds wrong then). asac has the final say here
<dpm> dholbach, ^
<dholbach> asac, lool, slangasek: ^
<dholbach> I asked at least 5-10 times which PPA to use :)
<dholbach> which are we going to use? :)
<dholbach> I'm obviously happy to change it, but I'm a bit confused
<dholbach> mvo, ^ were there any discussions about changing the ppa setup and nomenclature?
<asac> good question
<asac> i think we will be using a new ppa :)
<asac> lol
<mvo> dholbach: only asac knows that :) I think it should be staging -> beta -> tools and we use tools for the final and stable PPA, but iirc asac wnated a different ordering. I personally don't mind either way is fine as long as its documented
<mvo> but if I would decide, that how I would do it
<dholbach> we should just use the archive if you ask me personally :-P
<mvo> good point, we could use the backports archive
<JamesTait> Good morning all; happy Kindergarten Day! :-D
<mvo> kickinz1: whats a good way to test docker? your tdocker snap?
<kickinz1> mvo: For now I would say either direct command line or tdocker, yes. I need to finish owncloud snap package.
<mvo> kickinz1: where is the docker snap? I think I need to add some caps for the seccomp stuff or make it unrestricted there (thats probably the best option for now until jdstrand is around)
<kickinz1> mvo: launchpad.net/~snappy-dev/snappy-hub/docker/
<mvo> ta
<mvo> kickinz1, jdstrand: please pardon if this diff is stupid, it seems with seccomp enable I need to do at least http://paste.ubuntu.com/10860613/ in the docker-client or it won't even talk to docker (i.e. the docker command will just hang)
<kickinz1> mvo: is it with new seccomp code in the image? (it was working yesterday)
<mvo> kickinz1: it landed during the night
<kickinz1> mvo: ok, I'm downloading it right now.
<mvo> kickinz1: you will need to apply the pasted patch  to make it work at all, dmesg will indicate if something goes wrong, the kernel message starts with "audit:"
<kickinz1> mvo thanks
<mvo> Chipaca: hm, hm, this should not be possible, right? http://paste.ubuntu.com/10860659/ - note the two pastebinit packages I managed to install first I installed it via the store and then sideloaded it and that worked :/
<Chipaca> mvo: sideload always works
<Chipaca> oh
<Chipaca> oooh
<Chipaca> ouch
<Chipaca> mvo: i thought it was going to be about versions, not about namespaces
<Chipaca> ouch
<Chipaca> mvo: i'll look into it as soon as i get this branch up
<mvo> Chipaca: thanks ,you rock!
<mvo> much much appreciated
 * mvo dives back into seccomp land
<Chipaca> mvo: before you're in too deep
<Chipaca> mvo: sideload install of an already installed package is ok, yes?
<Chipaca> that is, we don't want to force devs to bump revno or uninstall to test their packages
<Chipaca> ?
<beuno> FWIW, I sort of think that what distinguishes sideloading from not is whether it's signed by the store
<mvo> Chipaca: oh, sideload again a already sideloaded one? yeah, I guess, but we will probably run into the textfile-busy problem we had earlier when we allowed reinstall. its a problem worth fixing and maybe its ok for sideload
<Chipaca> mvo: textfile busy should be sorted now that we stop things properly, mehtinks
<mvo> yay
<mvo> then go for it
<mvo> excellent news
<mhall119> dholbach: so are we waiting to hear from asac about which PPA to use in our docs?
<asac> mhall119: we are talking :)
<asac> about that
<asac> mhall119: if you want to participate join the call on my calendar right now
<mhall119> ok, cool, I'll leave that in your hands then
<mhall119> asac: as long as I can tell didrocks it's being done, I'm happy :)
<asac> mhall119: why is didrocks so worried?
<asac> is he depending on us?
<mhall119> asac: because he saw that it was wrong and he's sitting across the table from me
<mhall119> asac: he's working on a prototype with it this week I think
<mhall119> I don't think he's blocked, just noticed an error in our docs
<asac> mhall119: is he willing to join this channel :)?
<didrocks> hey
<robert_ancell> asac, oh, the PPA was via me. I was reading the docs and assumed it was wrong. You guys were all asleep when I was asking from .nz :)
<didrocks> asac: so not blocked on that, but we just posted an email to snappy-devel ML with a simple example (even if we have way more questions/wonderings), so as soon as you get some time to look at itâ¦ that would be appreciated!
<asac> hey didrocks :)
<asac> welcome to the snappy world
 * beuno hands didrocks the standard-issue goggles
<didrocks> :)
<Chipaca> mvo: fix for sideload & namespaces messing things up: https://code.launchpad.net/~chipaca/snappy/check-namespaces-on-sideload/+merge/256904
<asac> jodh: how is self test going?
<jodh> asac: we're now blocked on a store issue.
<asac> beuno: ^
<asac> jodh: whats the issue in one line?
<jodh> asac: installing a framework breaks 'snappy search'
<asac> thats a store problem>
<asac> hmm
<asac> nessita: ^^
<asac> JamesTait: ^
<jodh> asac: Chipaca has raised a MP which is now approved, but needs to be merged + included in an image.
<beuno> asac, mvo and Chipaca know about it, not a store issue, really
<asac> jodh: an MP against the store?
<beuno> :)
<asac> jodh: ok, please be more precise :)
<asac> so its a snappy bug
<asac> Chipaca: mvo: i guess you are on it?
<jodh> asac: it's a store issue or a snappy issue :)
<Chipaca> it's a bug in the system, which includes the client and the store. We've decided to fix it on the client.
<Chipaca> it keeps the parts consistent
<asac> ok
<Chipaca> that is: the store is self-consistent on this matter, the client is not
<Chipaca> so it made sense to fix it in the client
<asac> yeah
<Chipaca> even if we could have also fixed it from the store
 * JamesTait grabs popcorn
<asac> makes sense
<asac> thanks
<Chipaca> JamesTait: sorry to disappoint :)
 * ogra_ steals JamesTait's popcorn bucket
<JamesTait> Not at all, Chipaca, happy to help if it's needed, happy to stand aside otherwise.
<Chipaca> JamesTait: i meant wrt popcorn :)
 * JamesTait throws unpopped kernels at ogra_ and Chipaca.
 * JamesTait whistles innocently, points at beuno.
 * Chipaca feels he's already thrown enough mock abuse at beuno for a few more minutes still
<davmor2> Chipaca: you mean there is a limit to the mock abuse you can throw at beuno, why am I the last to learn of this?
<Chipaca> davmor2: that depends on the acerbity of your abuse
<Chipaca> davmor2: with me having slept so little, i don't trust myself
<davmor2> Chipaca: hahahaha
<Chipaca> davmor2: also, beuno is within range for a lot more weapons than normally
<Chipaca> I don't think he's within the record sniper 'confirmed kill' range, but it's close
<robert_ancell> Trying to build a lightdm snap here. First blocker - LightDM needs PAM configuration to work. This requires installing files into /etc/pam.d. How do we do this? Does ubuntu-core need some sort of hook to pull PAM configuration from frameworks that require it?
<asac> didrocks: you have to subscribe using your @canonical.com
<asac> the other will be unsubscribed
<ogra_> carzy annoyances :P
<dholbach> davidcalle, dpm: I'll look into amending the snappy internal docs for use as guides next
<dholbach> davidcalle, dpm: feel free to take any of the other work items
<davidcalle> dholbach, dpm, I'm on the architecure page + diagram
<dholbach> davidcalle, excellent - are you going to import any content for that?
<didrocks> asac: hum, ok :)
<davidcalle> dholbach, from the slides?
<dholbach> ok cool
<dholbach> thanks a lot
<didrocks> asac: done
<ogra_> didrocks, i was pondering to set up a petition to get the (10 years well working) old scheme back for MLs :)
 * ogra_ is seriously annoyed by getting half his mails back because he forgets to swithc to the other account
<asac> mterry: will you be in standup today?
<dpm> davidcalle, I was going to pick the WI of modifying the diagram to add the enablement bit. Are you planning on taking that one too? If so, I'll leave it up to you :)
<davidcalle> dpm, I've just finished :)
<dpm> \o/
 * dholbach relocates to the office, brb
<davidcalle> dpm, what do you think? (to me, it works well) https://developer.ubuntu.com/en/snappy/guides/architecture/
<dpm> davidcalle, good work. Seems like the "How does it work" row is both on the landing page and the architecture one. Would it not make sense to have it only in one place?
<davidcalle> dpm, right, removing it from architecture
<sergiusens> dpm: davidcalle you can have an app directly on top of ubuntu core too
<dpm> davidcalle, I think after release it might be work redrawing the  "Stack examples" diagrams so that they are more inline with the rest of the site, and have a <h2> section for each one of them
<dpm> sergiusens, davidcalle, then perhaps we can say "an optional layer of frameworks" in the text?
<dholbach> davidcalle, dpm, I'll drop the snappy internals for now
<dholbach> asac said it'd be good to look at the image channels and stuff first
<dpm> dholbach, ok
<dholbach> and the ./start page
<dholbach> I'll look into writing the content for the channels page
<dholbach> and then we can take it from there
<dpm> dholbach, what's there to do in the start page?
<dholbach> ?
<dholbach> ah ok
<dholbach> well, the start page contains all the links to all kinds of images
<dholbach> there will have to be links or at least mentions of other releases/channels
<asac> slangasek: would be great if we could get the first prebuilt images done early today so davidcalle and dholbach can put together our nice page to find the right bits and pieces
<dpm> dholbach, ah, got it now, I wasn't thinking to it in relationship with the image channel links
<dpm> dholbach, if you need the diagram, here's where I created it back in the day for the devices page: https://docs.google.com/drawings/d/1CxoxNsWGA3r5IS9ZavfSR_QbhlAKE2D9KaCtvL-zM88/edit
<dholbach> thanks - that's greta
<dholbach> great
<mterry> asac, I can make sure to be, yeah
<asac> mterry: great. woudl be nice to get an update and coordinate what and how to bring stuff togethher for release
<asac> thanks
<jdstrand> mvo: re docker-- yeah, that's fine, though I'm starting to feel like network-service isn't a useful group-- docker client is not a server yet it needs bind
<asac> jdstrand: mvo: apps can depend on multiple frameworks right now, correct?
<jdstrand> they should be allowed to, yes
<mvo> yes
<dholbach> davidcalle, do you know why there are no margins on https://developer.ubuntu.com/en/snappy/guides/channels/?
 * dholbach surely broke something :-P
<dholbach> do we have something like -proposed in terms of image creation?
<dholbach> or is that just 'edge'?
<dholbach> slangasek, ^
<slangasek> dholbach: edge, was previously called -proposed
<dholbach> thanks
<sergiusens> slangasek: can you look at my man generation mp?
<slangasek> sergiusens: otp, will be able to later
<sergiusens> stgraber: btw, if I'm on trusty, is there a ppa for lxc where the download template would have vivid images?
<sergiusens> ty steve
<asac> sergiusens: what still needs landing before we can featuure freeze?
<asac> mvo: ?
<sergiusens> asac: I need some u-d-f stuff; just finished the oem bug work and now moving to autopilot autoreboot
<sergiusens> asac: the security stuff is still in the works
<stgraber> sergiusens: ppa:ubuntu-lxc/stable should get you a recent enough lxc for that
<sergiusens> asac: blocking sideloaded updates
<sergiusens> stgraber: thanks!
<sergiusens> asac: and some fixes from Chipaca
<asac> sergiusens: ok you think we can get those in before EOD and still have a good image to start freeze?
<sergiusens> asac: well, the security stuff doesn't depend on the team
<asac> dholbach: so i assume those stack pics will not stay on the channels guides?
<asac> i think i can use them in the appliance guide ... and maybe we can improve the thing on the architecture inspired by these
<mvo> asac: we are mostly good, two unapproved branches left, not critical IMO, the launcher needs some further work and discussion with the security team, some real concerns here. worst case is that we need to disable the hardware: assign: feature if there is no solution found
<dholbach> asac, sure... it's not done yet
<dholbach> asac, once it is, I'll let you know :)
<mvo> asac: we also don't hvae a image with the latest ubuntu-snappy, I don't know why, there should be at least one since 418, I wonder if its because of arm64 :/
<asac> slangasek: ^^
<dholbach> dpm, davidcalle, can you help me with the styling of https://developer.ubuntu.com/en/snappy/guides/channels/?
<asac> mvo: 418? i dont have that high numbers
<asac> i am on 18 or something witjh the new channel names
<asac> mvo: maybe you are leeching on the old channels?
<dpm> dholbach, on it
 * dholbach hugs dpm
<asac> jdstrand: can you please think hard how we can make it so that we dont need to disable the hwassign feature?
<mvo> asac: this is the amd64 image number
<jdstrand> I'll invite tyhicks to the standup, he did the review
<asac> i really would prefer a solution than a discussion though.
<mvo> jdstrand: I'm happy to fix it, I just need some input what the best aproach is, maybe we need to brainstorm it from what we need instead of what we have right now
<dholbach> dpm, nice work - how did you do it?
<dholbach> dpm, davidcalle: does the text generally make sense to you? :)
<dpm> dholbach, for Raw HTML, you need to enclose the whole page in <div class="row"></div>
<dholbach> ohoh ok!
<dpm> dholbach, and then within that row, you can choose how many columns with <div class="eight-col"></div>
<dholbach> gotcha
<tyhicks> I'll attend the standup
<tyhicks> unfortunately, I don't have a solution atm
<jdstrand> mvo: are you planning another ubuntu-snappy upload? I'd like to drop the reference to apparmor-easyprof-ubuntu-snappy in debian/control. that is gone. easiest is to replace it with ubuntu-core-security-apparmor
<jdstrand> (note, nothing is broken because ubuntu-core-security-apparmor Provides apparmor-easyprof-ubuntu-snappy)
<mvo> jdstrand: I think I did that already, let me check
<mvo> jdstrand: yep, trunk has no easyprof string anymore AFAICS
<jdstrand> ok, thanks
<dholbach> mvo, asac: is http://paste.ubuntu.com/10861645/ what we want documented for the ppa?
<dholbach> just to be sure :)
<asac> dholbach: so all tools will be available for trusty,vivid
<asac> 15.04/stable = {trusty,utopic,vivid}/tools
<asac> as an example
<dholbach> asac, ok - what is "tools" in this nomenclature - what kind of stability can be expected there - how often is it updated?
<dholbach> asac, is the note on the right hand side of the webdm page (https://developer.ubuntu.com/en/snappy/guides/webdm/) what you were looking for?
<dholbach> dpm, davidcalle: do you think we should try to separate the links on https://developer.ubuntu.com/en/snappy/participate/? ie, "articles for hardware enablement", "articles on snappyfication" or "articles about snappy in general"
<slangasek> mvo: which channel are you looking for the import to happen on?
<mvo> slangasek: devel-proposed, is that the wrong one?
<slangasek> I don't know
<slangasek> I'm asking so I can check :)
<slangasek> mvo: ubuntu-core/15.04/edge/, last import was Apr 21 9:41 - same as devel-proposed.  So it's not that
<sergiusens> mvo: I updated the auto reboot branch
<dholbach> thanks sergiusens!
<jdstrand> tyhicks: fyi, r35 for ubuntu-core-security
<jdstrand> tyhicks: (makes the network-* changes we discussed)
<tyhicks> jdstrand: sorry for the delay - I'm just thinking through that change a little more
<tyhicks> jdstrand: I thought that you weren't going to add all the permissions to network-client until the socket params were filtered
<tyhicks> mvo: fyi - I verified that not doing setgroups() is fine in this case
<jdstrand> tyhicks: heh, obviously I thought they'd be the same except for socketpair
<jdstrand> tyhicks: that said, if you think there are things that should be in one and not the other, that's fine with me. my understanding coming out of there was that only socketpair is actually server related
<jdstrand> err
<jdstrand> server only
<tyhicks> jdstrand: what I was trying to say was that an app doing AF_UNIX communication may need many of the things that are in network-service
<jdstrand> right, which is why I added them to client
<tyhicks> ok
<tyhicks> I thought that was going to happen after the arg filtering
<jdstrand> because this separation is meant for inet/inet6
<tyhicks> I don't think it makes a big difference though since we plan to do the arg filtering
<tyhicks> right
<tyhicks> really, there is AF_UNIX and AF_INET/AF_INET6
<tyhicks> it is tough to split on client and server since those terms mean different things between those 3 domains
<jdstrand> tyhicks: the are essentially the same now because I don't want people to ask for network-service now when they don't need it. that way people can add in network-service once we support arg filtering
<tyhicks> ok
<jdstrand> re tough split> exactly
<tyhicks> wfm
<jdstrand> I realize there is no practical difference now
<tyhicks> I'm reviewing the seccomp filter now
<jdstrand> this is for establishing the groups for the future
 * tyhicks nods
<jdstrand> tyhicks: re review, thanks
<mvo> thanks tyhicks
<mvo> pitti: is there a API to figure from a libudev device to get if its a block or char device? I'm overlooking something silly probably
<pitti> mvo: no, this is curiously hard to determine
<pitti> mvo: that's why in the PoC I was checking for "/block/" in the device path, otherwise it's a char
<mvo> pitti: ok, thats all I need to know, thanks
<pitti> mvo: that should be pretty safe
<jdstrand> tyhicks, mvo: fyi, http://paste.ubuntu.com/10862547/
<jdstrand> updating the packaging now and will request an MP
<jdstrand> I think I am going to be more lenient on the uevent rule
<jdstrand> /sys/devices/**/uevent r,
<jdstrand> we can finetune that later if needed
<tyhicks> jdstrand: wow - nice profile
<tyhicks> (minus having to include cap_sys_admin)
<jdstrand> yeah
<jdstrand> it is what it is
<tyhicks> jdstrand: oh, were you going to deny transitioning to unconfined?
<jdstrand> Chipaca: that comment was for you ^
<jdstrand> tyhicks: oh yes, thanks for reminding me
<Chipaca> jdstrand: which comment?
<jdstrand> Chipaca: 'it is what it is'
<jdstrand> Chipaca: I know how much you like that phrase ;)
<jdstrand> </lame joke>
<Chipaca> in my defence it was a long week and i was somewhat sleep deprived
<jdstrand> I liked what you had to say about it
<jdstrand> :)
 * Chipaca hopes the memories will come back someday
 * Chipaca also hopes he wasn't rude
<mvo> stgraber, tyhicks: hrm, hrm, so after some refactoring it seems like devices.allow is too clever and just having the FD is not good enough, it will deny access, from looking at the source it appears its checking if the task has CAP__SYS_ADIM so the open fd and then do the rest with thta seems to not work (which is really disappointing)
<jdstrand> Chipaca: it was something along the lines of, "Have you ever noticed that when someone says 'it is what it is' it usually means it is sh!+"
<jdstrand> hehe
<jdstrand> awesome
<stgraber> mvo: gah, I hate it when checks are done on write rather than open...
<jdstrand> jjohansen: heh, can you look at this: http://paste.ubuntu.com/10862602/
<Chipaca> jdstrand: well, i wasn't wrong :)
<jdstrand> jjohansen: s/heh/hey/
<jdstrand> Chipaca: you weren't! :)
<jjohansen> jdstrand: sure
<jdstrand> jjohansen: clearly, that says that I don't want to allow transitioning to unconfined
<jdstrand> jjohansen: I was thinking I wanted to say "not to unconfined and not to a profile that starts with '/'"
<jdstrand> jjohansen: but I wasn't sure how to express the alternation
<jjohansen> jdstrand: yeah that should do it, by why that instead of using a deny?
<jdstrand> jjohansen: oh heh, yes, that would be considerably cleaner, haha
<jdstrand> jjohansen: thanks!
 * jdstrand grabs brown bag
<jjohansen> deny change_profile -> {unconfined,/**},
<jjohansen> change_profile -> **,
<jjohansen> jdstrand: so this is one area of the language that could really use some improvements
<jdstrand> yeah
<jjohansen> there are just some things that are really hard to express
<jdstrand> in this case, the deny rules do a great job
<jdstrand> jjohansen: change_profile -> **, why the '**'?
<jjohansen> yeah but if you start doing stuff like that in the deny rule ...
<jjohansen> * will stop at /  just as with file paths
<mvo> stgraber: yeah, unless there are more smart ideas I think I can not make the critical section smaller
<jjohansen> you may not care as they shouldn't be in the names you are allowing
<jdstrand> jjohansen: so, 'foo' ok, but 'foo/bar', no
<jjohansen> right
<jdstrand> that makes sense
<jdstrand> ok, thanks again
<jdstrand> tyhicks: did you see mvo's last comment? ^
<tyhicks> oh, no
<jdstrand> what if we dropped all caps except sys_admin until after the cgroups?
<mvo> jdstrand: let me try that
<mvo> well, its terrible but better than full root
<mvo> (well, maybe not, I need to check what is allowed with that)
<tyhicks> dropping all except sys_admin doesn't gain us much
<tyhicks> let me look back at the launcher code to see if I have any other ideas
<jdstrand> jjohansen: hrm, seems we have a parser bug
<jjohansen> jdstrand: ?
<jdstrand> jjohansen: all of these give a parser error:
<jdstrand> #    deny change_profile -> {unconfined,/**},
<jdstrand> #    deny change_profile -> unconfined,
<jdstrand> #    deny change_profile -> /**,
<jdstrand> AppArmor parser error for /home/ubuntu/usr.bin.ubuntu-core-launcher in /home/ubuntu/usr.bin.ubuntu-core-launcher at line 32: syntax error, unexpected TOK_CHANGE_PROFILE, expecting TOK_ID or TOK_MODE or TOK_SET_VAR
<jjohansen> jdstrand: indeed, and ouch
<jdstrand> jjohansen: my previous paste works
<jjohansen> I'll get right on it
<jdstrand> jjohansen: so, I guess I am back to my previous question on the alternation
<jjohansen> right, its complaining about deny with change_profile
 * jdstrand nods
<jdstrand> jjohansen: I don't think it is worth an emergency upload. we can SRU the fix
<jdstrand> jjohansen: I'll file a bug and reference it in the profile
<jjohansen> sure not worth an emergency upload but something to get done
<jdstrand> I imagine it is a pretty easy fix
<jjohansen> jdstrand: give me a sec, to paste you it
<tyhicks> mvo: bummer... I don't see another obvious idea
<jjohansen> jdstrand: http://paste.ubuntu.com/10862679/
<tyhicks> mvo: we could temporarily drop, do the udev stuff, regain, write the devices lists, then permanently drop
<tyhicks> mvo: but I don't know that it gains us much
<tyhicks> mvo: I'll look at the udev code to see if it is a concern
<jdstrand> jjohansen: ok, that was what I was thinking. thanks
<jdstrand> jjohansen: fyi, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1446794
<jjohansen> thanks
<mvo> tyhicks: well, drop and regain is not that helpful (from my limited understanding about the security I have). I am playing with libcap right now, but again limited success, I will get the kernel source next to see what its actually checking
<mvo> "it" being the devices.allow write of course
<tyhicks> mvo: ah, I'll do that "it"
<mterry> If I want to upload a package to the Snappy store, but like on behalf of a team (for example, ~mir-team), how do I do that?  I'm not sure how to not upload just as me
<tyhicks> mvo: ah, just noticed one more thing - the fclose() ret val needs to be checked in write_string_to_file() since there's not an explicit fflush()
<tyhicks> mvo: when writing to the device cgroup files, devcgroup_update_access() does the real work and it immediately returns an error if 'current' does not have CAP_SYS_ADMIN: http://lxr.free-electrons.com/source/security/device_cgroup.c#L603
<tyhicks> mvo: there's no way around it :/
<mvo> tyhicks: yeah, I found that too, thanks! I have http://bazaar.launchpad.net/~mvo/ubuntu-core-launcher/drop-root-early-use-caps/revision/45 that drops root earlier, the code is not clean (enough) yet but my brain is a bit fried right now not sure if this is worth it or not
<tyhicks> looking now
<jdstrand> mvo: fyi, I'm just about to do a MP for the apparmor profile for ucl
<jdstrand> (ubuntu-core-launcher)
<mvo> jdstrand: nice, does it work with exotic apps like docker?
<mvo> (I assume it does :) still curious)
<jdstrand> I am trying docker right now
<jdstrand> I missed one rule
 * jdstrand is testing now
<jdstrand> docker itself has an issue:
<jdstrand> Apr 21 19:10:35 localhost kernel: [22039.617003] audit: type=1400 audit(1429643435.305:104): apparmor="DENIED" operation="file_mprotect" profile="docker_docker-daemon_1.6.0.001" name="/bin/bash" pid=1886 comm="docker.start" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<tyhicks> mvo: I think that patch does help
 * jdstrand fixes docker
<tyhicks> mvo: I haven't went through all of the cap_*() calls closely but I understand what you're doing
<mvo> tyhicks: ok, I will take a break and either do the cleanup now or tomorrow morning, plus new tests, the old approach is no longer working but I have a plan for new tests
<mvo> tyhicks: and THANKS for your help with this!
<mvo> much appreciate the feedback I got
<tyhicks> mvo: thanks for the quick turnaround on everything! :)
<jdstrand> mvo: https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/ubuntu-core-launcher.aa-profile/+merge/256992
<jdstrand> mvo: if you are using libcap, the profile will need to be updated
<tyhicks> mvo: I'll go back through the list and verify that everything has been done and, if necessary, propose some changes for you
<tyhicks> s/everything/everything important/
<jdstrand> mvo: (it should be easy to see what needs to be done, but I/tyhicks can also help)
<jdstrand> ah meh, conflict
 * jdstrand resolves
<jdstrand> these branches are moving to fast :)
<jdstrand> (it's just the changelog)
<jdstrand> tyhicks: here is the final profile: https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/ubuntu-core-launcher.aa-profile/+merge/256992
<jdstrand> mvo: ok, that ^ is ready to pull in (obviously update as necessary for your changes)
<tyhicks> jdstrand: looks good
 * jdstrand uploads docker with the small profile change
<jdstrand> kickinz1: fyi ^
<jdstrand> kickinz1: committed to the branch
<jdstrand> kickinz1: can you delete ./package-dir/meta/docker-daemon.*priv now that they are no longer needed?
<mvo> jdstrand: thanks, uploaded! hints what the libcap branch needs for apparmor would be great (ideally by mail). I will check in my morning (in +8h) and continue on the capability branch
<kickinz1> jdstrand: I'll do
<asac> lool: still around?
<asac> lool: do you have the code for the demo that displays stuff on the mini LED screen still?
<jdstrand> kickinz1: thanks!
<jdstrand> tyhicks: fyi, r37 of ubuntu-core-security
<jdstrand> (added capget)
<kickinz1> jdstrand: done, but I will try uploading when owncloud package is somehow working, caus I think it will need some apparmor adjustment (bind mounts).
<tyhicks> jdstrand: ack - are you ok with me explicitly denying umount and umount2?
<jdstrand> tyhicks: yes
<tyhicks> pushed
<jdstrand> tyhicks: are you ok with my doing the same in apparmor? :)
<tyhicks> jdstrand: yes :)
<tyhicks> jdstrand: don't forget about remount in apparmor (it is a separate rule)
<jdstrand> right, done
<jdstrand> and pushed
<jdstrand> ubuntu-core-security 15.04.6 pushed to the image ppa
<jdstrand> kickinz1: you are going to need that ^ for docker to work correctly
<kickinz1> jdstrand: ok, thanks.
<asac> jdstrand: you know what is left still?
<asac> for mvo :
<jdstrand> asac: a few finish touches on the launcher
<jdstrand> finishing*
<asac> hmm
<asac> what needs doing?
<jdstrand> the last bits from the security review
<jdstrand> aiui
<jdstrand> there was a snag with passing fds (it didn't work), so an alternate implementation that wasn't as comprehensive is being done
<jdstrand> the apparmor profile bits are in the image ppa
<asac> ok, what hints is he waiting for>
<asac> ?
<jdstrand> (ie, ubuntu-core-launcher runs under the profile)
<jdstrand> none
<asac> 21:50 < mvo> jdstrand: thanks, uploaded! hints what the libcap branch needs for apparmor would be great (ideally by mail). I will check in my morning (in +8h) and continue on the capability branch
<jdstrand> oh, that
<jdstrand> I sent that to him already
<asac> k
<jdstrand> it is just how to update the aforementioned profile for if he uses libcap
<asac> sergiusens: so on my image sshd is not started by default
<asac> sergiusens: ignore... let me recreate
<asac> not 100% sure i --enable-ssh
<kickinz1> jdstrand: so I need a new image? Which revision ?
<sergiusens> asac: if you wait for the publisher to finish maybe try the latest u-d-f? But it does need a new image build as snappy list is broken
<jdstrand> kickinz1: it isn't on the image yet. you can grab a new image, then do: sudo mount -o remount,rw / ; sudo dpkg -i /tmp/*.deb ; sudo mount -o remount,ro /
<jdstrand> kickinz1: pull the 3 ubuntu-core-security packages from https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages
<jdstrand> kickinz1: note, I am getting non-apparmor/seccomp error when doing 'docker pull ubuntu:trusty'
<jdstrand> kickinz1: I was going to follow what is in framework-policy/apparmor/policygroups/client, but the docker repo seems broken
<jdstrand> sudo docker pull ubuntu:trusty
<jdstrand> ...
<asac> sergiusens: from trusty
<jdstrand> Error pulling image (trusty) from ubuntu, Untar exit status 1 operation not permitted Untar exit status 1 operation not permitted
<jdstrand> maybe it isn't their repo
<asac> sergiusens: ppa?
<jdstrand> but no denials of any kind
<jdstrand> kickinz1: anyway, I have to step away for a little while. I'll be back later
<asac> sergiusens: getting 0.20snappy7-0ubuntu1 and will redo the flash
<kickinz1> jdstrand, trying locally (out of snappy) to check (pull ubuntu:trusty)
<asac> sergiusens: which channel?
<asac> sergiusens: 15.04 edge?
 * asac thinks we still work on rolling/edge until we cut it
<asac> sergiusens: this is what i am now dd'ing https://pastebin.canonical.com/130045/
<asac> or open paste: http://paste.ubuntu.com/10863294/
<kickinz1> jdstrand: ubuntu-core-{launcher,meta,security}?
<kickinz1> jdstrand: ok, sorry
<asac> sergiusens: still have invalid package on system :/
<asac> sergiusens: system-image-cli -i
<asac> current build number: 18
<asac> device name: generic_armhf
<asac> channel: ubuntu-core/rolling/edge
<asac> last update: 2015-04-21 18:27:44
<asac> version version: 18
<asac> version ubuntu: 20150421.A
<asac> version raw-device: 20150421.A
<asac> sergiusens: this doesnt help me much
<asac> sergiusens: yuou say w eneed a new image build>?
<asac> do we have the fix landed?
<asac> slangasek: https://launchpad.net/~snappy-dev/+archive/ubuntu/image this ppa is in theory in image?
<slangasek> in practice, not just in theory
<slangasek> the next scheduled image livecd-rootfs build is in 56 minutes; after which we need to again mangle for importing
<asac> ok copied the snappy binary :)
<asac> it works
<asac> i love go :P
<asac> ok the launcher seems to be old style
<asac> jdstrand: hello-world.env
<asac> Bad system call
<asac> thats the problem?
 * asac reboots
<sergiusens> asac: yes; you need snappy trunk
<sergiusens> asac: and your u-d-f command was good
<sergiusens> slangasek: asac  can we trigger a build sooner?
<asac> i would love to see whats in
<asac> right now i feel its broken
<asac> but maybe my copying didnt do the good thing
<asac> slangasek: sergiusens: ok if we kick an image?
<asac> given that we have to mangle once anyway :)
<asac> it would help us getting answers sooner
<slangasek> yes
<slangasek> triggered
<asac> gratias
<asac> hmm. guess i need the new -security package
<asac> to get the syscall problem above eliminated
<asac> ok, i am sure all is fine its relly just installing that swecuerity stuff
<kickinz1> jdstrand: on r404, installed debs + install docker, seems to work. r419: no way, same error as you.
<kickinz1> jdstrand: put docker in debug mode, not much more info...
<kickinz1> jdstrand: seems related to auplink. Does auplink need some seccomp profile?
<asac> kickinz1: whats the error you see?
<kickinz1> asac; same as jdstrand: FATA[0016] Error pulling image (latest) from cirros, Untar exit status 1 operation not permitted
<kickinz1> asac: I put docker on debug mode, same message, I'm trying to strace, no better info...
<kickinz1> asac: last traces from strace:
<kickinz1> asac: http://paste.ubuntu.com/10863526/
<kickinz1> asac: on, r404, all clear...
<asac> kickinz1: i am on r22 :/
<asac> kickinz1: how do you produce the image?
<kickinz1> I made a little script.
<kickinz1> asac; r22 on amd64?
<kickinz1> asac: r22 -> bbb?
<asac> no on amd64
<asac> kickinz1: how do you produce the image?
<asac> or is it an upgraded one?
<kickinz1> asac: generated one: http://paste.ubuntu.com/10863556/
<sergiusens> kickinz1: heh, keyboard layout is killed on the latest images
<sergiusens> kickinz1: are you using ppa:snappy-dev/tools?
<kickinz1> sergiusens, for building?
<sergiusens> kickinz1: yeah
<asac> slangasek: ready for a manual mangling?
<kickinz1> sergiusens, no I'm using snappy bin from images (I may not use the r419 though)
 * asac hopes new image is ready now
<sergiusens> kickinz1: sorry, I meant u-d-f
<slangasek> asac: yes, doing
<asac> kickinz1: this is revision for snappy tool?
 * asac confused... i cannot install anything with that high numbers after our channel redo
<asac> great
<sergiusens> asac: they are using --channel ubuntu-core/devel-proposed
<kickinz1> asac: I take snappy from images for building, I think the last one I took was from r404.
<asac> sergiusens: that doesnt even work for me
<asac> sergiusens: guess only in beta ppa that works?
<sergiusens> asac: they are using an old u-d-f
<sergiusens> asac: yeah or no apt update
<asac> well, lets wait for next image
<asac> hope thats useful
<asac> guess we can only hope that things really came together
 * asac reboots
<kickinz1> sergiusens, I use dnappy-dev/beta yes
<kickinz1> sergiusens, ok, I update...
<sergiusens> slangasek: I think this is what we need https://code.launchpad.net/~sergiusens/snappy/conflictsPackaging/+merge/257008
<kickinz1> so if updated, I can build without getting snappy from images?
<kickinz1> sergiusens, ^
<kickinz1> sergiusens, I have updated I still get r419... What am I doing wrong?
<sergiusens> kickinz1: add-apt-repository ppa:snappy-dev/tools ?
<kickinz1> sergiusens, sorry...
<jdstrand> kickinz1: you should see seccomp denials if that was it. besides, you are using @unrestricted in the docker-daemon seccomp filter so no seccomp filters (ie, it shouldn't be seccomp)
<asac> ok getting 23 it seems
<asac> lets see
<jdstrand> kickinz1: thinking about it, I bet it is the cgroups
<jdstrand> a) docker hasn't been assigned any hardware and b) I doubt it would work with our cgroups implementation
<jdstrand> because docker already does stuff with cgroups
<jdstrand> (docker really is not a great first framework-- literally everything is an exception)
<asac> kickinz1: ok i think 23 might be better... :) lets see
<asac> at least i can install docker
<kickinz1> the pb is to docker run -it ubuntu.
<jdstrand> kickinz1: my feeling is we either need a way to flag the launcher that it shouldn't do anything but aa_change_onexec (ie, aa-exec) or special case docker in bin-path so it uses the old aa-exec
 * jdstrand tests by modifying the systemd unit
<jdstrand> it's the launcher
<jdstrand> I'm going to send mvo an email and CC you guys
<kickinz1> jdstrand: thanks
<asac> jdstrand: still get bad system call
<asac> on 23
<asac> latest image
<jdstrand> asac: is that capget?
<jdstrand> you need ubuntu-core-security-seccomp 15.04.6
<asac> jdstrand: ok good news is that the apps seems to work now
<asac> at least the hello-world.echo
<asac> docker images fails with bad system call though
<jdstrand> right
<jdstrand> yes, that is fixed
<asac> jdstrand: docker?
<jdstrand> what kickinz1 and I are talking about is something different
<asac> line 11: 1218 Bad system call ...
<asac> select_bin ddocker
<jdstrand> yes, 15.04.6 fixes the syscall
<asac> etc.
<asac> jdstrand: thats fixed?
<asac> hmm
<asac> so we need yet another image?
<jdstrand> select_bin?
<asac> jdstrand: which package?
<jdstrand> what arch is that?
<asac> amd64
<asac> jdstrand: we spun an image after the most reent ppa upload
<jdstrand> can I see the syslog entry?
<asac> ok
<asac> hmm
<asac> have to forward port
<asac> jdstrand: Apr 21 22:36:43 localhost kernel: [   66.568721] audit_printk_skb: 12 callbacks suppressed
<asac> Apr 21 22:36:43 localhost kernel: [   66.568724] audit: type=1326 audit(1429655803.718:15): auid=1000 uid=1000 gid=1000 ses=1 pid=905 comm="docker.x86_64" exe="/apps/docker/1.6.0.002/bin/docker.x86_64" sig=31 arch=c000003e syscall=228 compat=0 ip=0x7ffc8e52cb4d code=0x0
<asac> thats the thing i get when i run docker iamges
<asac> 228
<asac> probably select_bin
<asac> hehe
<jdstrand> syscall=228(clock_gettime)
<jdstrand> I can adjust that
<jdstrand> fyi, sudo sc-logresolve /var/log/syslog
<jdstrand> email on docker sent
<asac> jdstrand: ?
<jdstrand> I will fix that ^ seccomp denial a bit later
<jdstrand> asac: I sent it to you too
<jdstrand> I have to step away again for a few minutes
<asac> kickinz1: what /dev nodes does docker access?
<asac> kickinz1: can you strace the command on a normal ubuntu system?
<asac> vivid?
<asac> to see?
<kickinz1> asac: ok
<kickinz1> asac:
<kickinz1> asac, http://paste.ubuntu.com/10863741/
<asac> jdstrand: its not clear to me why you have no problems
 * kickinz1 going to bed...
<asac> kickinz1: i mean i have the latest image i think
<kickinz1> asac: ok, do you want me to test?
<asac> orr
<asac> err
<asac> sorry
<asac> kickinz1: no
<asac> i meant jdstrand
<asac> sleep well
<asac> and see you tomnorrow
<asac> slangasek: do you know if ubuntu-core-security15.04.6 is on latest image?
<kickinz1> asac: ok, will be around for a few minutes still but not too long (pb with uploading owncloud image armhf to docker registry)
<asac> jdstrand: i clearly have 15.04.6
<kickinz1> asac: for now I've created a docker image for ubuntu:trusty for armhf (I'll change to vivid as soon as everything else works)
<asac> guess you say its working on bbb?
<slangasek> asac: yes, ubuntu-core-security 15.04.6 is in the latest images on edge (except arm64)
<asac> ok i did my first seccomp hackery
<asac> enabled clocktime
<asac> and now i can runn docker iamges
<asac> and i am docker pulling
<asac> kickinz1: any idea what it untars at the end?
<asac> FATA[0032] Error pulling image (trusty) from ubuntu, Untar exit status 1 operation not permitted
<jdstrand> asac: that's fine. it is interesting that you are seeing that seccomp denial in the client where I didn't, but I didn't have a chance to test a lot of it due to the daemon not working well with the launcher
<kickinz1> asac: it downloads layers of the image, and then it untar it. It is pulling fgood from registry, and tars are in /var/lib/apps/docker/.tmp/..../xxx/xxx.tar, then it decompresses it, and it must populate /var/lib/apps/docker/aufs with them
<jdstrand> I will prepare 15.04.7
<kickinz1> ls
<jdstrand> we need to not try to fix the launcher for docker at this time and just special case it
<jdstrand> if someone wrote a framework for snappy that needed the kinds of perms and did the kinds of things that docker is doing we would almost certainly say 'no'. this is a special case. let's special case it in the easiest way possible now and then see how to deal with this sort of thing going forward
<asac> yeah maybe
<asac> kickinz1: how can i get logs for docker?
<kickinz1> asac, just systemctl stop docker_.... then sudo vi /apps/docker/current/bin/docker.start and uncomment the DEBUG="-D" line
<kickinz1> asac, then restart daemon, it will logs to journalctl
<kickinz1> asac: really going
<asac> bye
<asac> jdstrand: what does docker appamrmor get access to in /dev ?
<jdstrand> asac: in 'unprivileged' mode: http://paste.ubuntu.com/10863849/
<jdstrand> asac: note, most of those are directories, it is just the first 6 lines and the last that are actual files
<jdstrand> asac: however, in 'privileged' mode, it has all of /dev
<jdstrand> it defaults to unprivileged. there is a command to toggle privileged
<jdstrand> docker has the ability to assign hardware to app containers
<jdstrand> (which in our snap is reserved for privileged mode)
<asac> jdstrand: right. so still dont get whats going on here... do we know that the devnodes that you pasted are really avail there?
<jdstrand> asac: what we know is that docker fails to run without them
<jdstrand> docker was not designed for snappy and we are shoehorning it into a framework
<asac> jdstrand: hmm
<asac> jdstrand: so with new launcher those defaults are not getting mapped in?
<jdstrand> don't get me wrong, it is useful for people, but its design is not in line with snappy
<jdstrand> asac: I don't know why the launcher is breaking docker
<jdstrand> asac: I imagine that it is going to be whack-a-mole
<asac> jdstrand: right, but do the devnodes get mapped into the launcher cgroup?
<jdstrand> ie, we give the devices then it breaks cause of how it uses cgroups
<jdstrand> asac: nothing is doing that mapping atm because there is no oem snap that sets those up. even if it did, the udev rule for docker privileged mode would be 'tag everything for docker'
<asac> jdstrand: right i get that
<asac> jdstrand: can i use hwassign to try doing those dev nodes?
<asac> http://paste.ubuntu.com/10863849/
<asac> those
<asac> i guess i would have to do a find on all those directories :)
<jdstrand> as it turns out, no. the command line hw-assign works only with templated policy atm, not hand-crafted policy like docker-daemon has
<jdstrand> this is in my personal backlog (there is no trello card)
<jdstrand> if that is deemed important, it can be SRUd
 * jdstrand adds a trello card
<jdstrand> asac: but, cli hw-assign doesn't do the udev stuff. it only adds rules to apparmor policy. as such, with the cgroups implementation, it is currently broken
 * jdstrand just realizes that and adds a trello card
#snappy 2015-04-22
<jdstrand> we should probably just document how to use the oem config bits and remove hw-assign
<asac> jdstrand: so for me hw-assign is about drafting rules for development
<asac> you do hw-assign app /dev/null
<asac> this creates a rule with path=/dev/null :)
<jdstrand> that was how I saw it too
<jdstrand> yes, that used to work
<jdstrand> now with the cgroups and launcher, it doesn't
<asac> you could also do hw-assign --kernel=ttyS* --with-tag=...
<asac> this will just create the same rules we havae
<asac> just "runtime rules
<asac> :"
<asac> once you are happy you can dumb them and copy them into your oem config :)
<jdstrand> right, we'd need to define the cli experience for that
<asac> jdstrand: sure i am saying this would be mapped into that
<asac> udev engine
 * jdstrand nods
<jdstrand> right, if we didn't remove hw-assign, we would have to integrate it
<jdstrand> the trello card currently says update it for cgroups
<asac> ack
<asac> think that can be SRU'd the advanced CLI is then future
<jdstrand> yeah, that sounds fine
<asac> fine
<jdstrand> heh
<asac> jdstrand: so you say that apps have now zero device nodes?
<jdstrand> no, they have a few
<asac> wasnt there a default set of nodes that we wanted to assign
<asac> where can i find that?
<jdstrand> /dev/null, /dev/full, /dev/zero, etc
<asac> that list :)
<jdstrand> it is hardcoded in the launcher
<jdstrand> let me get the link
<jdstrand> asac: http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/main.c#L57
<asac> jdstrand: ok, did you upload new -security?
<jdstrand> I am about to
<jdstrand> it will be a few minutes
<asac> hmm
<asac> so the go webserver does not start anymore
<jdstrand> asac: sudo grep DEN /var/log/syslog ; sudo sc-logresolve /var/log/syslog
<jdstrand> I can try here
<asac> Apr 22 00:24:44 localhost kernel: [ 6546.952744] audit: type=1326 audit(1429662284.103:45): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=2682 comm="sed" exe="/bin/sed" sig=31 arch=c000003e syscall=137(statfs) compat=0 ip=0x7f9a1d0a4017 code=0x0
<asac> jdstrand: statfs
<jdstrand> ah we added statvfs earlier
<jdstrand> I'll fix and see if there are any other stat* that we missed
<asac> jdstrand: so python xckd server also has no port open
<asac> root      1244     1  0 00:29 ?        00:00:00 /usr/bin/python3 /apps/xkcd-webserver.canonical/0.4/bin/xkcd-webserver
<asac> it is running though
<asac> or wait
<jdstrand> what does logresolve say about that?
<jdstrand> fyi, the final syscall list hasn't been uploaded yet. tyhicks and I have been reviewing it today
<asac> its fine
<asac> python works
<asac> just didnt have right port forward
<asac> and was to stupid for lsof
<jdstrand> which is what I am preparing now. it changes some things around wrt to the networking bits that could have blocked it, but the new upload won't block it
<jdstrand> ok, good
<asac> its odd
<asac> lsof doesnt have a hit on 80\
<asac> e.g. no hit on liten
<asac> LISTEN
<asac> oha
<asac> i dont see the LISTEN ports as normal user
<asac> guess thats a feature?
<asac> as root i see it
<jdstrand> that is normal
<asac> http://paste.ubuntu.com/10864024/
<jdstrand> yeah
<jdstrand> I don't know why otoh, but that is consistent with my experience
<asac> jdstrand: its not on my normal desktop :)
<asac> maybe admin group
<asac> good
<asac> jdstrand: added statfs and fstatfs to seccomp
<asac> and now go is running
<jdstrand> cool
<asac> slangasek: is there a new image supposed to happen now?
<asac> iirc it should be about time :)
<asac> jdstrand: not sure if fstatfs is needed, but saw fstatvfs so thought it makes sense
<slangasek> asac: next one fires off in 16 minutes
<asac> jk
<asac> k
<jdstrand> asac: it does, there are also statfs64 and fstatfs64 that I am adding
<asac> right
<jdstrand> I'm also downloading the latest linux-libc-dev to see if we are missing anything else
<jdstrand> interesting, a new syscall 'switch_endian'
<asac> heh
<asac> guess docker might want to use that later
<jdstrand> it is something for powerpc
<asac> sure
<asac> jdstrand: so i am lost currently how our mir etc. framework can easily be tested without hw-assign
<jdstrand> asac: it is probably also broken under the launcher
<asac> jdstrand: you mean if you assign the right devnodes it still doesnt work?
<jdstrand> because aiui, it uses a hadn-crafted policy
<asac> jdstrand: well, there are two things... a) policy and b) access to dri devnodes
<asac> do you know what the policy hacks look like?
<jdstrand> hw-assign does nothing with udev atm (hence the trello card). the launcher looks at udev to add devices to the cgroups
<asac> right
<jdstrand> it may not. I have not seen the branch
<asac> but we need some cli so folks can test mir
<asac> without having to put togehter a full appliance
<asac> jdstrand: where do we put the udev rules?
<asac> /lib/udev/rules.d/80-snappy-assign.rules
<jdstrand> but if they use hw-assign, it is broken cause hw-assign and udev don't do anything. if it uses hand-crafted policy, it is broken because nothing tells the launcher to add the devices to the cgroups
<asac> sure i get that
<asac> saying that hw-assign should just add new udev rules :)
<asac> lol
<jdstrand> yes, it should :)
<jdstrand> hence the aforementioned trello card :)
<jdstrand> hehe
<asac> so
<jdstrand> anyway, yeah
<asac> what does a udev rule look like?
<asac> that just matches the path?
<jdstrand> so, that is going to be in snappy somewhere
<jdstrand> I see that http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/src/snappy-app-dev is a script to add files to the cgroups
<asac> https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-oem-hardware-snap
<jdstrand> hw-access could call out to that
<jdstrand> but, I think that is being removed (no matter, the same functionality could be added to hw-assign
<asac> well hwassign should add the proper rules imo
<jdstrand> if hw-assign is going to be persitent, use, it should add the udev rules
<jdstrand> s/use/yes/
<jdstrand> it is probably pretty easy to add come to think of it-- all of it is already in snappy
<asac> hmm
<asac> so an oem snap can ship binaries?
<asac> wow
<jdstrand> I was not aware of that either
 * jdstrand jots that down to ask about later
<asac> sergiusens: where are our oem snap sources
<asac> i dont see them in ~snappy-dev
<asac> jdstrand: ok somethign worrying: http://paste.ubuntu.com/10864146/
<asac> hello-world.jdstrand failed to install: exec: "sc-filtergen": executable file not found in $PATH
<jdstrand> indeed
<jdstrand> that looks similar to the fs issues I keep talking about
<asac> ?
<jdstrand> what does dmesg say?
<asac> jdstrand: thats when running udf
<jdstrand> udf
<asac> dmesg doesnt say much
<asac> [10770.939947] systemd-udevd[10485]: failed to execute '/tmp/test.sh' '/tmp/test.sh': No such file or directory
<asac> :)
<asac> not sure what that is
<jdstrand> I guess you need to have ubuntu-core-security-utils on your host
<jdstrand> I'm not sure where you are seeing that
<jdstrand> on the host or in the guest?
<asac> hmm. thats not in the ppa it seems
<asac> jdstrand: on the host
<asac> when running udf
<jdstrand> ubuntu-core-security-utils is a part of ubuntu-core-security
<asac> to produce an image with stuff preinstalled
<jdstrand> I see
<jdstrand> so, you should be able to install ubuntu-core-security-utils from vivid
<asac> i am on trusty though
<asac> so this has to go into tools ppa's
<asac> for all supported things
<asac> and dependency need adding
<jdstrand> sergiusens: ^
<asac> do we need to run this stuff?
<jdstrand> I've been a little surprised how much need to be on the host for udf
<asac> i mean those sc-... commands?
<jdstrand> I don't know
<asac> jdstrand: i think udf just runs snappy tool
<jdstrand> I guess it is preinstalling the snap via the host tools
<asac> right
<asac> but the apparmor stuff is done on first boot
<asac> this one should be done similar i gues
<jdstrand> it seems it would be much safer to use the tools in the image
<asac> s??
<asac> no?
<asac> well
<jdstrand> I agree
<asac> i think its wrong
<jdstrand> but, we don't have the systemd unit file to do that yet
<asac> to do what?
<jdstrand> which was one of the things I mentioned earlier
<asac> i think appamor is run on first boot, no?
<jdstrand> apparmor is run on every boot
<jdstrand> on first boot it will notice that there isn't policy for the snaps
<asac> hmm. i mean the stuff that you run when package gets installled
<asac> okk
<jdstrand> and it will call aa-clickhook and everything is fine. niext time, the policy won't have to be regenerated
<asac> shouldnt sc do all the same?
<asac> i thought we would have same semantics
<jdstrand> seccomp doesn't have that
<jdstrand> click had that nice quality
<jdstrand> so we have to reimplement it for seccomp and then again for apparmor when it moves away from click
<jdstrand> this morning I was talking about updating policy via a unit if the seccomp policy changed
<jdstrand> that unit would solve this problem too
<jdstrand> asac: sc and aa should have the same semantics. aa is still implemented as a hook tool. sc is not. aa will be made to not once we clean it up in 15.10
<asac> yes, but what i thought you said was that we would follow same approach for sc
<asac> anyway
<asac> so now we have to add unit?
<asac> and figure how to get rid of sc invocation in snappy install?
<jdstrand> what I said was that we would implement the new approach so we only have one thing to migrate when we drop the click methodology
<jdstrand> sc is new approach
<jdstrand> aa is old
<jdstrand> you still need sc invocation on snappy install so that the policy is in place when a service or binary is started prior to reboot
<asac> so now we have two approaches... in future never do two approaches
<asac> always one and then move both over
<asac> so we need unit
<asac> and special case in snappy to not run anything if its on host tool
<asac> not sure how to do that
<asac> sergiusens: any idea?
<jdstrand> asac: well, you say the two approaches thing. the reality is that it would have taken as much time to do the old approach for sc as the new, and it seemed silly to do the old only two weeks later to undo it
<asac> i know, but the new approach makes things more complex
<asac> so we should have done that
<jdstrand> not really
<jdstrand> there is a unit for apparmor
<jdstrand> it is just a different unit
<asac> hmm
<asac> anyway, what needs doing now?
<asac> we need to fix this for sure somehow
<jdstrand> I don't think this two approaches thing is something to worry about
<jdstrand> I will implement the unit as I said I would this morning
<asac> ok
<asac> and how to fix snappy tool?
<jdstrand> I helped with the launcher all day today
<asac> right
<jdstrand> that we need serguisens on
<asac> sergiusens: see above, we need the snappy install not call sc- stuff if run through udf
<asac> e.g. on host
<asac> and defer that to the first boot/unit
<jdstrand> maybe it is as simple as unpacking and not running the tools if doing a preinstall
<jdstrand> right
<asac> i dont think they will like just unpacking
<asac> they were super happy that snappy install was finally able to run on host tool
<asac> cross
<jdstrand> that's fine-- just saying, whatever doesn't need the tools
<asac> i think it does logic
<asac> the sc tools yes
<jdstrand> that didn't come out right
<asac> so we dont want to run the sc- tools if on host
<asac> if cross
<asac> not sure how we do the decision on appamor
<jdstrand> yes, do everything except run these bits. that said, these bits could run on the host-- they are not complicated tools
<asac> but we run them on first boot anyway
<asac> i dont want to add more stuff to tools ppa really
<asac> think that starts to become nasty
<asac> need to be tested and done for trusty etc.
<jdstrand> I was more talking about unblocking you now
<asac> i am not blocked. but tomorrow we have to get things together
<asac> so we should do it right right away
<jdstrand> ok, 15.04.7 uploaded to image ppa and archive
<asac> yep saw that
<jdstrand> go-example-webserver wrks
<asac> thx
<asac> great
<asac> check 1 :)
<jdstrand> I'll work on the unit tomorrow. that will give me insight as to what needs to happen with apparmor when we switch it to the new
<asac> jdstrand: generateSeccompPolicy
<asac> is that the whole function to kill?
<asac> on cross?
<jdstrand> let me check
<asac> is the unit difficult?
<jdstrand> addOneSecurityPolicy() can exit early if run under udf
<jdstrand> it shouldn't be
<asac> addOne
<asac> isnt matching
<jdstrand> that is in snappy/click.go
<jdstrand> in trunk
<asac> ah
<jdstrand> hmm
<jdstrand> no, it's ok
<jdstrand> I thought namespaces might trip me up, but it won't
<asac> jdstrand: is there a script you can give us to run after boot so we can test this in the morning?
<jdstrand> that is what I need to write
<asac> jdstrand: you say we can run those tools on host?
<asac> to shortcut?
<jdstrand> I don't see why not
<jdstrand> I installed several images today with udf
<jdstrand> I have ubuntu-core-security-utils installed
<asac> jdstrand: did you try snaps with built-in?
<asac> normal images work
<jdstrand> I did not
<asac> it just busts if we have built-in stuff
<jdstrand> I don't know how to do that
<asac> jdstrand: run udf with --oem ./...
<asac> and use http://people.canonical.com/~asac/tmp/generic-amd64_1.1_all.snap
<asac> locally
<asac> udf ... --developer-mode ... --oem ./generic-amd64_1.1_all.snap
<asac> that one tries to install hello-world.jdstrand
<asac> sudo ubuntu-device-flash core rolling --developer-mode --channel edge --oem ./oem-hardware-assign_1.0_all.snap --enable-ssh -o outputamd64.img
<asac> jdstrand: that command
<asac> give it a spin
<jdstrand> just grab fyi, I just installed ubuntu-core-security-utils and ubuntu-core-security-seccomp from the image ppa and python3-yaml from the archive in a trusty vm fine
 * jdstrand adjusts the deps for ubuntu-core-security-utils
<jdstrand> curious why ${python3:Depends} didn't do it for me
<jdstrand> ./oem-hardware-assign_1.0_all.snap failed to install: snappy package not found
<jdstrand> I don't know where that is
<asac> jdstrand: sorry wrong name
<asac> uuse the one
<asac> you downloaded
<asac> ./generic-amd64_1.1_all.snap
<asac> not ./oem-hardware-assign_1.0_all.snap
<asac> sudo ubuntu-device-flash core rolling --developer-mode --channel edge --oem ./generic-amd64_1.1_all.snap --enable-ssh -o outputamd64.img
<jdstrand> oh right, duh
<asac> heh
<jdstrand> asac: it failed in some other manner, but it seems like it probably got past sc-filtergen
<jdstrand> http://paste.ubuntu.com/10864267/
<asac> jdstrand: thats probasbly becauuse your system is busted
<asac> reboot
<asac> jdstrand: wait
<asac> jdstrand: so remember that udf does not use a chroot anymore afaik
<asac> its just run on host with path etc.
<asac> not sure what your tools are doing
<asac> if you are sure your system is still alive
<asac> then reboot :)
<jdstrand> I was running sbuild at the time. it had a problem related to unmounting
<asac> good
<jdstrand> it might've been the systemd shared mount space stuff
<asac> ok how does it look now?
 * jdstrand is trying again
<jdstrand> it reported breaking differently, but still a umount issue
<asac> i would suggest to reboot
<jdstrand> I can reboot, but it will be a minute
<asac> sure, better than giving up :)
 * jdstrand has a lot of context atm
<jdstrand> you could also try installing the tools I mentioned on trusty
<asac> this will mess my system a lot
<asac> but ok
<asac> utils?
<jdstrand> ubuntu-core-security-utils ubuntu-core-security-seccomp from the ppa
<jdstrand> you will also need python3-yaml
<jdstrand> and seccomp
<jdstrand> that should be it
<asac> yay
 * jdstrand uploads 15.04.8 to add Depends on python3-yaml 
<asac> it worked :)
<jdstrand> good!
<asac> too bad
<asac> hw assign is broken anyway
<asac> jdstrand: sent mail
<asac> i drop off
<jdstrand> ok, good night
<jdstrand> jeex it must be late there
<jdstrand> jeez*
<asac> i think autopilot jsut udpated :)
<asac> yay
<asac> it atuomatically rebooted
<asac> nice
<asac> good to end day like that :)
<asac> lol
<asac> cu in a bit
<jdstrand> hehe
<jdstrand> nice :)
<kickinz1> o/
<dholbach> good morning
<dholbach> dpm, davidcalle will work on refinements for the raspi bits, the channels and the start page - those are going to be most important pieces, later on we might look into importing stuff like you did
<dholbach> dpm, great work
<davidcalle> dholbach, +1
<dholbach> davidcalle, sorry
<dholbach> I meant to say...
<dholbach> "davidcalle and I"
 * dholbach needs another coffee :)
<plorenz> hi, i'm running snappy ubuntu on my raspberry pi 2 (by lool) and for some reason, the system only shows 116 MB of RAM available although it should be 1 GB of RAM. i guess it's a problem with GPU memory split, but i can't find a setting. can anybody help me please?
<davidcalle> dholbach ;)
<JamesTait> Good morning all; happy Earth Day! :-D
<dpm> dholbach, ack, thanks!
<dholbach> davidcalle, I updated https://developer.ubuntu.com/en/snappy/guides/channels/ - do you feel it's clearer in the regard we discussed earlier?
<dholbach> davidcalle, also... I'm considering extending the image at the bottom to explain the transition from alpha to beta, etc - wdyt?
<davidcalle> dholbach, not sure if the image needs to be extended. The table on top looks good, I still think you should add a wget and a udf examples under it, to make it clear what to do with this channel/release combination.
<davidcalle> dholbach, the page works well for me, especially with the table called a cheatsheet
<dholbach> davidcalle, ah yes, that's right - I'll add an example, but I'm not sure about wget/udf instructions - wouldn't we have to update the instructions as well whenever thing change again or images get updated?
<davidcalle> dholbach, that's true, I forgot udf was a moving target. But for wget, it would be mostly to show off how the path is composed (http://cdimage.ubuntu.com/ubuntu-core/15.04/edge/ubuntu-15.04-snappy-armhf-bbb.img.xz), to show people they can compose the img path based on what they need.
<dholbach> that makes sense
<dholbach> unfortunately we don't have http://cdimage.ubuntu.com/ubuntu-core/rolling/ yet
<davidcalle> dholbach, implementation detail :p
<dholbach> all right, I'll figure it out, thanks for the feedback
<sergiusens> dholbach: davidcalle we have finalized u-d-f, it won't be moving again except for bug fixes
<davidcalle> dholbach, I'd like to say something like "if it's documented, it needs to exist ASAP" ;-)
<davidcalle> sergiusens, oh cool :)
<dholbach> davidcalle, ok, updated - thanks again
<dholbach> davidcalle, are you working on the start page now?
<dholbach> davidcalle, I added channel info for the kvm case - does it look all right to you? do you think it helps like that?
<davidcalle> dholbach, I'm starting now. It looks right to me, so these are the final paths? edge at cdimages.ubuntu.com/ubuntu-snappy and stable, beta, rc at releases.ubuntu.com?
<davidcalle> dholbach, also, we talked about this earlier, but I'm not sure we had a definitive answer : are cloud images going to follow the naming scheme for release? (or should we just use the stable image names they provide tomorrow?)
<davidcalle> dholbach, don't mind the lat question, I've found what I'm looking for.
<davidcalle> last*
<yngves> Wondering if something is broken in the new Docker 1.6 package? I keep getting "aa-exec: ERROR: profile 'docker_docker_1.6.0.002' does not exist" when invoking Docker.
<dholbach> davidcalle, I'll ping the cloud guys and point them to the page - AFAIK those are the final paths, yes
<davidcalle> dholbach, thanks
<dholbach> a review with Steve and Alex later on should let us know if we're on the right track or not :)
 * davidcalle starts getting confused about the naming scheme again.
<asac> ppisati: hey, how is the cape going?
<dholbach> davidcalle, in the case of OVA, do you think we should explain the URL scheme - or just add the box with the links?
<davidcalle> dholbach, I've done both
<dholbach> ok... I personally would've thought that the box would be enough, but maybe just leave it in there and we talk about it later on together :)
<davidcalle> dholbach, the scheme of cloud-images is a bit different
<dholbach> oh! did you find out how it works there?
<ppisati> asac: i've got the original image to work, but once i compile the TI kernel, it doesn't boot on my board
<ppisati> yesterday i spent the entire day doing test for the release
<asac> ppisati: why do we need TI kernel?
<asac> if we have it working with our generic one?
<asac> ok have to go for lunch
<asac> bbiab
<ppisati> asac: because first you get a piece of hw working with the code that supports it
<ppisati> asac: then you derive a delta from it etc
<davidcalle> dholbach, I think so
<dholbach> davidcalle, I added a box like this to the bbb docs too
<dholbach> davidcalle, it gets placed in the wrong area though
<dholbach> davidcalle, do you have an idea how to fix it?
<davidcalle> dholbach, I'm fixing
<dholbach> davidcalle, if we ever do a sprint together, you should do a workshop on how to fix stuff like that :-)
<dholbach> I'd make sure to get a seat in the first row!
<davidcalle> dholbach, why not :) Fixed. I'm confused by the fact that if you download both images (15.04/stable and 15.04/edge), you have no way to differentiate the files by their names.
<dholbach> davidcalle, we should note this down
<davidcalle> dholbach, I've also left a comment on the card regarding the other tasks.
<dholbach> thanks
<dholbach> davidcalle, do you feel we're done with the page now, barring any changes we might need to do after a meeting with Alex and Steve and potentially the cloud guys?
<davidcalle> dholbach, yep
<dholbach> cool
 * dholbach hugs davidcalle
<dholbach> good work
<davidcalle> dholbach, same :)
<dholbach> asac, slangasek: whenever you have time, davidcalle and I would review https://developer.ubuntu.com/snappy/start/ and https://developer.ubuntu.com/snappy/guides/channels with you
<dholbach> asac, mvo, sergiusens: I'm still not quite sure which ppa to recommend? right now there's 'beta', 'tools', 'tools-proposed' (and probably unrelated: 'image')
<dholbach> asac, mvo, sergiusens: what kind of changes do you anticipate to land in which of the PPAs
<dholbach> I'm still not sure how to explain the four PPAs to users
<sergiusens> dholbach: tools has latest and greatest and always breaks, beta is for users; but I want to get rid of that as it's too confusing
<dholbach> sergiusens, ok... so I just recommends 'beta' for nowÃ?
<plorenz> sergiusens: do you know how i can increase my available ram with snappy on the raspberry pi 2?
<sergiusens> dholbach: yes
<sergiusens> plorenz: no
<dholbach> thanks sergiusens!
<dholbach> can somebody review and land https://code.launchpad.net/~dholbach/snappy/markdown-doc-fixes/+merge/257080?
<sergiusens> dholbach: done
<asac> pitti: is there an easy way on the cli to query for devices that got assigned to the app?
<asac> pitti: from the app point of view?
<asac> udev query
<sergiusens> dholbach: would be nice to use the ```[code] annotation eventually :-)
<dholbach> sergiusens, did you see r416 on the MP as well? I pushed another commit
<dholbach> sergiusens, I've never seen any ```[code] notation
<dholbach> thanks Chipaca
<sergiusens> dholbach: github markdown being the engine I refer to
<dholbach> ah ok
<sergiusens> dholbach: https://help.github.com/articles/github-flavored-markdown/#syntax-highlighting
<dholbach> cool
<dholbach> I hope one day a bunch of people get together and figure out one markdown standard to rule them all
<sergiusens> dholbach: that's easy; github :-P
<dholbach> right
<sergiusens> standards are hard in an ever moving fast paced world
<pitti> asac: yes, cat /sys/fs/cgroup/snappy.appname*/devices.list
<pitti> asac: this gives you the real actual ACL
<pitti> asac: you can also get a list of devices tagged for the app with udevadm
<pitti> asac: udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=$APPNAME
<asac> pitti: so jdstrand is a bit unhappy to allow apps to ask for what they can talk to this way
<asac> i think its super useful for some app to say "give me all the devs that are of type X and that i am allowed to use"
<asac> pitti: so trigger is doing the query?
<pitti> asac: well, so far that's coming from OEM.yaml, so not from the app?
<asac> pitti: but an app needs too know what it can talk to
<asac> at best using the closest to current practices
<pitti> asac: why shouldn't we allow the apps to query for what they can access? either by devices.list or udev?
<pitti> they can just try and open everything in /dev/ after all
<asac> pitti: jdstrand doesnt like that this leaks info about what is installed
<asac> i think its a bug that we can address later :)
<asac> but we should allow apps to query udev
<pitti> asac: oh, you mean the udevadm?
<asac> pitti: not sure
<dholbach> https://code.launchpad.net/~dholbach/snappy/more-markdown-fixes/+merge/257094
<pitti> asac: oh, we need to
<jdstrand> pitti: I'm fine with apps trying to open things in /dev
<pitti> asac: but right now the apps aren't confied at all
<asac> pitti: only thing i know is that i want to tell a story on how an app that we assigned access to
<asac> can find the usb devices that it can now poke
<jdstrand> pitti: I'm less fine about an app querying udev and being able to see all the tags, and therefore, enumerate installed apps on the system
<pitti> asac: that udevadm on the shell or libudev in C should be fairly adequate for that query
<asac> right
<asac> pitti: but jdstrand wants to take powers away from us to not allow to use libudev :P
<asac> which i think is not good for real life :P
<pitti> well, not querying sysfs at all is a no-go IMHO
<asac> right :)
<asac> i agree!!
<asac> so i think for me this is a must
<pitti> so you could at most restrict the access there
<asac> and we need to figure later how to make things even better
<asac> right
<asac> we can try to make udev smarter later
<jdstrand> well hold on
<asac> to hide stuff :)
<pitti> but quite frankly, this is by faaaaaar not the most problem we are having :)
<pitti> 'impotant'
<jdstrand> sysfs is another conversation
 * ogra_ thought you were planning something like the trust-store we have on the phone 
<asac> its the same kinda
<asac> ogra_: thats a higher level
<ogra_> why
<pitti> well, libudev just queries /sys and /run/udev/
<asac> no time to argue
<ogra_> jus integrate something like that with udev
 * jdstrand notes that I am not taking powers away from using libudev. apps don't currently have it. I am trying to understand what the access gives
<asac> jdstrand: apps on normal ubuntu have it
<jdstrand> asac: apps on touch do not
<pitti> libudev itself is just conveience; you can't do anything with it that you can't already do with /sys and /run/udev/
<asac> right, but they dont want to poke devices :)
<pitti> so we need to restrict /run/udev/ if we want to restrict app access
<jdstrand> if we allow this and don't fix udev to restrict the access, then on touch we regress
<asac> we should restrict it
<asac> later
<asac> smart
<pitti> that might break some apps, but might be appropriate
<asac> not sure how
<asac> is there a way we can restrict it?
<ogra_> polkit ?
<ogra_> via udev-acl
<asac> e.g. is /run/udev/ content compatible with apparmor?
<jdstrand> pitti: is it fair to say that if I use udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=hellow-world.sideload under confinement I can see what read only access is required?
<asac> jdstrand:  you need read access to /sys and to /run/udev i think
<jdstrand> pitti: is there a udev daemon?
<asac> yeah
<asac> i think there is and that could later mediate
<jdstrand> pitti: as in, udevadm talks to a daemon?
<asac> not sure if libudev is going through that, but could be!
<pitti> jdstrand: there is udevd, but udevadm query and libudev don't talk to it
<pitti> as I said, it's just reading /sys and /run/udev (for the properties and tags)
<asac> ah bummer :)
<asac> jdstrand: yeah so short term we woudl have to open access for those friends
<asac> to those directories
<asac> and then later see how to make libudev go through mediation or make /run/udev so that the app info can be confined
<pitti> we also don't yet start apps under its own pid namespace, so presumably apps can already see what other apps are running?
<jdstrand> well, in the future to resrict this, we would want to have a tool that talks to an out of process helper, perhaps udevd, then udevd asks libapparmor for the label of the client, then filters the query results to be only those for the app
<ogra_> and "those friends" would be aware that their apps break at some point ?
<jdstrand> then we remove access to /run/udev, etc
<pitti> again, there is *no* point in restricting libudev as such
<dholbach> Chipaca, sergiusens: any idea why https://code.launchpad.net/~dholbach/snappy/more-markdown-fixes/+merge/257094 might be unhappy?
<asac> jdstrand: can you do a find on /run/udev after tagging something?
<asac> jdstrand: i think its a simple pattern match to hide that
<asac> i think the app name is really in the tagname on disk
<jdstrand> pitti: we have restricted access in /proc, but there are some leaks there that we plan to address. I'm concerned about adding more and more stuff that leaks info about the system. if we understand what needs to be done, that is fine
<asac> right
<asac> but we have to take a holistic look at that later :P
<pitti> "private process namespace" :)
<ogra_> i dont really get that ... there is such a mechanism via polkit and udev--acl already, why dont we use it ?
<pitti> now that we have a launcher, we can easily add that, and private /tmp and such
<asac> thats too high level. we work on primitives to hard wire access here
<jdstrand> we can't use polkit because no one can do the authorization
<pitti> ogra_: that doesn't restrict visibility
<asac> polkit or such can be built on top
<ogra_> pitti, thats indeed true, but access ...
<pitti> also, it's logind plus ACLs
<ogra_> ah, right, i'm a bit behind :)
<pitti> ogra_: access restriction is already in the lanucher nw
<pitti> now
<sergiusens> dholbach: hmm, outage or godeps changed
<pitti> that's what mvo and I worked on last week
<ogra_> ok
<ogra_> the launcher = ubuntu-app-launch ?
<pitti> yes
<ogra_> ro did you re-implement that
<ogra_> awesome :)
<jdstrand> ogra_: the snappy launcher is ubuntu-core-launcher. how this will work on touch is less clear, but either ubuntu-core-launcher is updated to do UAL-y things, or the other way around
<ogra_> ah, so it is a separate thing ... k
<jdstrand> for now
<jdstrand> pitti, asac: ftr, right this second, we don't leak anything in /proc on snappy (we do on touch, but there is a bug on that). udevadm will change that, but it sounds like that is what is required, so I'll document all this
<asac> jdstrand: given that we have to revisit all this holistically anyway for next releases i really think its fine to have leak about apps that have hw assigned for the time being.
<asac> jdstrand: we could in future use a crypto token for assign that is only known to the core system itself and the app?
<asac> so instead of SNAPPY_APP:=....
<jdstrand> fyi, udevadm doesn't work under the launcher
<jdstrand> I'd prefer to wait on designing how to fix it for when we are interested in fixing it. way to much to do today
<jdstrand> pitti: do you know why udevadm would fail under our cgroups implementation?
<pitti> jdstrand: no, it shouldn't have anythign to do with the devices cgroup; when I tried mvo's MP even sudo worked there
<pitti> jdstrand: how does it fail?
<jdstrand> I get apparmor denials under aa-exec but nothing under the launcher other than the app saying: udevadm: Operation not permitted
<pitti> apparmor? syscalls failing? (strace)
<pitti> sorry, deeply in release prep/testing mode right now
<jdstrand> no, none of that. I'll keep poking
<davidcalle> dholbach, back o/
<pitti> jdstrand: ok, so stracing it might be insightful?
<asac> pitti: just last thing: to query on cli i would use trigger?
<asac> or adm?
<asac> err ignore
<pitti> asac: trigger --dry-run is nice for getting a list of devices that have certain names/attributes/properties/tags
<dholbach> davidcalle, I looked into importing the snappy internal docs and fixed a few bits in the markup to make it easier for us to import it "as is"
<pitti> query is good for getting info about a particular dev
<pitti> asac: ^
<asac> nice
<asac> thanks
<davidcalle> dholbach, yes, seen it, I'm starting on the meta one
<dholbach> davidcalle, looking at 'oem' now
<dholbach> davidcalle, one problem we're going to have is linking from files to each other
<dholbach> davidcalle, we could wrap dpm's instructions into a small python script
<davidcalle> dholbach, there are a lot of links?
<asac> jdstrand: https://pastebin.canonical.com/130117/
<asac> those i am getting
<dholbach> ... which could replace a mention of "security.md" with a proper link to its location on the website
<dholbach> davidcalle, not too many
<asac> jdstrand: udevadm trigger --verbose --dry-run --tag-match=snappy-assign
<dpm> dholbach, yes, and feel free to improve it, I just wrote a few one-liners to make it simpler, but could be more elegant
<asac> jdstrand: maybe its working if you have the /dev as r ?
<davidcalle> dholbach, let's assume their path is guides/<name>
<davidcalle> dholbach, a script is fine too :)
<asac> jdstrand: yeah so /dev/**
<dholbach> davidcalle, to keep stuff in sync I just thought that it'd be nice if we had a self-contained script that won't grow into a chaotic monster (~50 lines) which would take an .md file from the branch and turn it into exactly what we need to paste into the text box of django cms
<asac> not just /dev/*
<dholbach> dpm, that was no criticism - thanks a lot for figuring stuff out so far already! :)
<davidcalle> dholbach, oh right, keeping stuff in sync after that.
<dholbach> yep
<davidcalle> dholbach, then absolutely :)
<dpm> dholbach, I didn't interpret it as criticism, just saying I'm not particularly proud of the one-liners :)
<dpm> but I did it between other things this morning, and I thought I'd put something together real quick
<dholbach> davidcalle, dpm: I'll put the oem article online, and could then look into writing such a script
<dpm> cool
<davidcalle> Ok
<dpm> dholbach, I noticed a few typos and markdown syntax errors on the config.md script that I fixed on the final HTML. I think the original docs might need some fixes.
<dholbach> asac, slangasek: davidcalle and I still around for a review of /snappy/start and /snappy/guides/channels - we have a meeting coming up in 45m though
<dholbach> dpm, https://bazaar.launchpad.net/~snappy-dev/snappy/snappy/changes :)
<dholbach> dpm, there might be more though
<dpm> dholbach, nice, good work :)
<jdstrand> pitti: it was an apparmor issue but there was no denial. kernel rate limiting may have been in effect
<davidcalle> dpm, dholbach, moving on to frameworks
<dholbach> https://code.launchpad.net/~dholbach/snappy/even-more-markdown-fixes/+merge/257112
<sergiusens> mvo: want to remerge trunk on your branch?
<sergiusens> mvo: it conflicts with the packageYaml removal from the signature in oemHwUDRules you did in another branch
<dholbach> dpm, davidcalle: I'll mail the snappy lists to help out with a docs review for the release tomorrow and tell them to either respond on list or ping davidcalle and me on IRC - does that sound all right to you?
<dholbach> ... or file bugs on developer-ubuntu-com
<dholbach> maybe that's the best option
 * dholbach reviews  bug list
<mvo> sergiusens: I updated the branch, thanks again and also removed println()
<sergiusens> jdstrand: can you ack https://code.launchpad.net/~mvo/snappy/snappy-add-apparmor-override/+merge/257076 ?
<sergiusens> you have needs info there
<jdstrand> I thought I did
<sergiusens> given we are so close to release I don't want to override
<jdstrand> ah, I was trying to test it. that is what I was working on when the meeting came
<dholbach> https://code.launchpad.net/~dholbach/snappy/even-more-markdown-fixes/+merge/257112
<dholbach> oops
<Chipaca> dholbach: âARM or X86 devices such as the Beaglebone Blackâ is probably unfortunate word order
<Chipaca> dholbach: or unfortunate lack of oxford comma,
<Chipaca> or something :)
 * genii armors his X86
<dholbach> Chipaca, good find - fixed, thanks!
<dholbach> we inherited quite a few docs, trying to get on top of things everywhere :)
<Chipaca> man, i had to use wdiff to see machanisms -> mechanisms in that diff
<dholbach> Chipaca, yeah, sorry - I always use    bzr diff --using=wdiff     for commits like that :)
<Chipaca> heh :)
<Chipaca> dholbach: updates on in `oem` package
<sergiusens> Chipaca: oh, I just commented the same
<dholbach> sergiusens, pushed a change to fix your comment
<Chipaca> dholbach: hmm
 * Chipaca tries something
<Chipaca> dholbach: so, in pandoc, instead of ```yaml, you'd do ~~~ {.yaml}
<Chipaca> dholbach: you then need css to do the highlighting, but it's something
<Chipaca> dholbach: you can also use -B for the content before the body, and -A for after
<dholbach> oh nice
<dholbach> I'll take a look
<sergiusens> dholbach: Chipaca does pandoc have some form of syntax checker we can enable in ./run-checks?
<dholbach> Chipaca, do I need to close the ~~~ {.yaml} tag somehow?
<Chipaca> dholbach: yes, ~~~ on its own line
<dholbach> right
<Chipaca> dholbach: http://pandoc.org/README.html#extension-fenced_code_blocks
<Chipaca> it's actually 3 or more ~s
<Chipaca> sergiusens: i didn't think markdown had the idea of 'bad syntax'
<sergiusens> Chipaca: markdown itself, no; maybe pandoc does
<Chipaca> also, you can tell pandoc to use markdown_github
<Chipaca> which would probably make sergiusens wet himself
<sergiusens> oh neat
<Chipaca> so don't tell him that
<sergiusens> we should do that
<sergiusens> lol
<dholbach> haha
<sergiusens> it is the markdown style everyone uses
<dholbach> I'll leave this open for discussion for the team
<dholbach> I don't care too much
<dholbach> as long as we have something which spits out raw html I can paste into developer.u.c's djangocms, I'm happy
<sergiusens> dholbach: is it fully automated now?
<sergiusens> dholbach: or html that you copy paste?
<dholbach> the latter
<dholbach> automating this fully will be too much work right now
<sergiusens> dholbach: maybe adding a form to upload a raw html file will allow full automation
<sergiusens> oh
<sergiusens> I thought it wouldn't be too hard
<dholbach> the content right now lives in a database
<sergiusens> just a uri you can post to or put to change the resources
<sergiusens> and django would save it to the db
<dholbach> if you want access, then yes, you have a page where you can copy/paste
<dholbach> sergiusens, Chipaca: can somebody make a decision on if we want to use github markdown or something else?
<dholbach> I don't care too much
<dholbach> but it'd be good to decide this
<dholbach> maybe it'd also allow us to change the .rst doc to an .md doc
<Chipaca> whatever's the path of least work
<dholbach> AFAIR it was just tables which stopped it from using regular markdown
<dholbach> maybe tables work in github markdown?
<Chipaca> pandoc's take on github markdown might not be github markdown
<Chipaca> just to keep things clear
<dholbach> ok
<Chipaca> dholbach: i don't think we need to change anything more than the minimum to get things to look right on our website, now
<Chipaca> dholbach: next week we can talk grand designs
<dholbach> +1
 * dholbach moves on
<dholbach> :)
<dholbach> I'll file a bug on snappy
<sergiusens> dholbach: easy
<sergiusens> Chipaca: mvo jodh http://www.poll-maker.com/poll299911x1d4b4d87-11
<Chipaca> hahahah
<Chipaca> sergiusens: that's sweet
<Chipaca> sergiusens: markdown_phpextra (PHP Markdown Extra)
<Chipaca> footnotes, pipe_tables, raw_html, markdown_attribute, fenced_code_blocks, definition_lists, intraword_underscores, header_attributes, abbreviations.
<Chipaca> markdown_github (Github-flavored Markdown)
<Chipaca> pipe_tables, raw_html, tex_math_single_backslash, fenced_code_blocks, auto_identifiers, ascii_identifiers, backtick_code_blocks, autolink_bare_uris, intraword_underscores, strikeout, hard_line_breaks
<Chipaca> markdown_mmd (MultiMarkdown)
<Chipaca> pipe_tables raw_html, markdown_attribute, link_attributes, raw_tex, tex_math_double_backslash, intraword_underscores, mmd_title_block, footnotes, definition_lists, all_symbols_escapable, implicit_header_references, auto_identifiers, mmd_header_identifiers
<Chipaca> markdown_strict (Mar
<Chipaca> ...
<Chipaca> :)
<sergiusens> Chipaca: mark down strict is nice
<sergiusens> I like strict
<Chipaca> no you don't
<Chipaca> :D
<mvo> sergiusens: haha
 * Chipaca stops having fun with sergiusens 
<mvo> I guess the fact that we talk markdown now means we can release, right?
<mvo> :P
<Chipaca> mvo: +1
 * mvo hugs dholbach, Chipaca, sergiusens
<sergiusens> Chipaca: it's bad tat we are having some fu and mvo is still crunching at it
 * sergiusens hugs back
 * Chipaca joins the hug party
<dholbach> hugs! :)
 * dholbach hugs you all
 * sergiusens wonders if it's beer'o clock already
<Chipaca> sergiusens: it is in germany!
<dholbach> asac, slangasek: are you going to have time to review the start and channels pages any time soon?
<mvo> Chipaca: hahaha, beerclock=[0-24] in germany
<Chipaca> mvo: that also :) but i meant it was after 5pm
<jdstrand> asac, pitti: fyi, I profiled 'udevadm trigger --verbose --dry-run --tag-match=snappy-assign --property-match=SNAPPY_APP=<appname>'. it requires this rule: '/run/udev/data/* r,'. This actually gives away far more info than what apps are installed
<jdstrand> asac, pitti: eg "The files in this directory reveal all kinds of information about the hardware, UUIDs of partitions, the MAC address of ethernet interfaces and more. This is enough information for a malicious snap to conduct data mining and identify individual systems and breaks our privacy model."
<jdstrand> this is bug #1447237
<asac> dholbach: the image links would be nice to have them right on top
<asac> of the section
<asac> like in getting started on baeglebone black
<davidcalle> dholbach, hangout dropped for me
<asac> sergiusens: i assume avahi wont work unless you have webdm or did we move that to core system?
<jdstrand> asac: so, we've worked extremely hard on touch to not reveal things such as the mac address
<sergiusens> asac: no, it's not in core on request from high above
<asac> jdstrand: could we argue that only apps that get hw assign can read this?
<jdstrand> asac: so we have a couple of choices. accept the information disclosure, but have someone get on the restriction soon or don't allow reading /run/udev/data/*. Interestingly, if you call udevadm without -property-match=SNAPPY_APP=<appname>, you don't need /run/udev/data/*
<asac> jdstrand: in the end this would put the decision into the yard of the guy that makes the system
<asac> and touch could for instance just allow only their framework to access that
<asac> and they can still realize their model
<jdstrand> asac: yes, we can adjust mvo's branch to do that
<asac> jdstrand: would this make you feel more comfortable?
<jdstrand> it would
<jdstrand> I would downgrade the priority significantly
<asac> lets do that i guess... later we have to look how to make udev better
<asac> i think udev coul dhave different data directories
<asac> one with /snappy/ and one with /crazy/data/
<asac> or wait
<asac> i think we could even restrict acces to the devices in there that the snapp has assigned?
<jdstrand> most hardware assigned things are frameworks and trusted. if a system builder preinstalls, that is also a form of trust (though different). a user that opts in is saying opting into this
<asac> jdstrand: right
<jdstrand> asac: I put ideas in the bug
<asac> yep
<asac> cool
<asac> lets do that
<asac> jdstrand: will the hw-assign cli work same way? i think its fine and maybe we even disable that in non-developer mode eventually
<jdstrand> asac: it will
<jdstrand> ok, I'll update the policy for the safe access and then talk to mvo about this one extra access
<jdstrand> that will be a very small addition
<fionnan> anyone getting this `profile 'docker_docker_1.6.0.0.002' error does not exist` on a fresh snappy install? https://bpaste.net/show/5fb0130cf91c
<yngves> fionnan: Yes, I do.
<yngves> fionnan: There definitely is no AppArmor policy of that name in the package. I hacked my way around it by changing the last line of /apps/bin/docker to read: aa-exec -p docker-default -- /apps/docker/1.6.0.002/bin/docker "$@"
<yngves> fionnan: A very ugly hack. Hope it gets fixed.
<fionnan> yngves: cheers!
#snappy 2015-04-23
<asac> fionnan: i think stuff is coming along... most recent image should work fine with docker
<davidcalle> asac, hey, still around?
<dholbach> good morning
<dholbach> salut davidcalle, mon ami - Ã§a va?
<davidcalle> dholbach, hey Daniel, I'm great, and you?
<dholbach> doing well as well - thanks :)
<dholbach> asac, HAPPY BIRTHDAY! :)
<dholbach> davidcalle, I think I'll go through the BBB docs again
<davidcalle> Dammit, we actually need to make him happy. I was planning on slacking most of the day.
<davidcalle> Happy birthday asac :)
<dholbach> damn, you're right :)
<davidcalle> dholbach, I've started on updating the porting guide, then I'll do the appliance builder one.
<dholbach> ok cool
<dholbach> did you fix the ova instructions?
<davidcalle> dholbach, nope, I'm still a bit confused about what/how to fix.
<dholbach> ok... I'll take a look at that too
<dholbach> mvo, shall I try with a different channel then edge?
<mvo> dholbach: its not working for you?
<mvo> dholbach: do you have a serial cable to test?
<dholbach> no, I'm afraid I don't have a serial cable
<dholbach> although somebody might in the office
<dholbach> does http://cdimage.ubuntu.com/ubuntu-snappy/15.04/edge/ubuntu-15.04-snappy-armhf-bbb.img.xz work?
<dholbach> utlemming, rcj: can you give us a few more instructions on how to factor http://blog.utlemming.org/2015/01/snappy-images-for-vagrant.html into developer.ubuntu.com/snappy/start?
<dholbach> I'm not sure we have all the information here
<dholbach> or http://blog.utlemming.org/2015/04/using-snappy-ova-images-when-you-dont.html
<dholbach> asac, davidcalle and I are around when you are
<dholbach> davidcalle, man, I'm so glad I'm working together with you on this :)
<davidcalle> dholbach, same!
<dholbach> and with the other hippies in here :)
<dholbach> mvo, so I'm trying this image now, but dd'ing it (and syncing) just takes some millisecond
<dholbach> I feel like something doesn't quite work right
<dholbach> nevermind, now that I'm doing it right, it's working now - still doesn't boot
<mvo> dholbach: yeah, dosn't boot for me either
<mvo> sergiusens: did anything change in u-d-f that might cause issues with beaglebone boots? I can't boot it with a freshly written image currently and I wonder what is going on. I get  http://paste.ubuntu.com/10870157/
<dholbach> trying http://cdimage.ubuntu.com/ubuntu-snappy/15.04/20150422/ubuntu-15.04-snappy-armhf-bbb.img.xz
<dholbach> mvo, ^ works
<dholbach> I just had to try to ssh into all machines on the network
<dholbach> that took a while :)
<dholbach> I'll run snappy update now to see what's new and if that works
<dholbach> davidcalle, ^ getting there
<davidcalle> dholbach, \o/
<dholbach> davidcalle, snappy tour updated *\o/*
<dholbach> mvo, 15.04/20150422 works
<dholbach> I updated it to the latest and updated the snappy tour docs, so that's all fine
<dholbach> davidcalle, I'll comment out the webdm stuff on the /start page
<davidcalle> dholbach, ok. I'm not linking it from the Guides page, but still leaving it in the top list of subpages. I think that's an okay middle-ground.
<davidcalle> (it = the whole webdm page)
<dholbach> +1
<davidcalle> dholbach, what do you think of https://developer.ubuntu.com/en/snappy/guides/?
<dholbach> <3 <3 <3
<dholbach> beautiful work
<davidcalle> dholbach, cool :)
<dholbach> davidcalle, I'm running linkchecker over the namespace
<davidcalle> dholbach, uh oh :)
<dholbach> not too bad - just one link broken :)
<mvo> dholbach: still fails for me, I think my bbb is broken
<dholbach> fixing
<dholbach> mvo, with the 22 image it worked, but it took a while to boot... and as I said: I needed to loop over all IPs in the subnet to ssh into it (but that might be a office network specific thing that I couldn't find "webdm")
<mvo> asac: feedback for https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-oem-hardware-snap/+merge/256800 would be great and for https://code.launchpad.net/~mvo/snappy-hub/snappy-examples-hwassign/+merge/257231
<mvo> asac: we may want those example in unless they are superseeded by your applicance guide work of course
<davidcalle> dholbach, have you started on https://trello.com/c/L6sBYZqC/44-start-beagleboard-kvm-instructions-better-download-experience ? If not, I am
<dholbach> davidcalle, can do
<pitti> mvo: guten Morgen!
 * pitti puts up his "do source new review on release day for beer" cardboard sign
<mvo> hey pitti
<dholbach> mvo, pitti's cheap
<pitti> I didn't say how much :0
<mvo> pitti: ahah, I will wait for steve then ;)
<dpm> dholbach, davidcalle, looking at the start page, good work with the download boxes for the images. Do you mind if I change the top text to e.g. "Download KVM images" instead of "Image links" to make it more clear?
<mvo> pitti: sorry, I know its terrible
<dholbach> dpm, sure
<dpm> ok
<davidcalle> dpm, +1
<dpm> ok, on it, then
<dholbach> :)
<davidcalle> dpm, since you are touching it, do you mind moving them to the top right of their sections?
<dpm> davidcalle, sure
<davidcalle> dpm, thanks!
<pitti> mvo: can you please fix the "Vcs:" tag in bzr? It's spelled Vcs-Bzr:
<mvo> pitti: silly me, sure
<pitti> mvo: (no need to reupload, just for next time)
<pitti> mvo: also, would you mind adding a standard copyright/license headers to the .c files? there's no COPYING, the only license/copyright ATM is in debian/
<pitti> which is fine for a native Debian package, but it's not "upstreamable" or distriubtable as a tarball that way
<mvo> yeah, indeed, I fix that now too, thanks pitti
<pitti> mvo: why do we need debian/dirs, OOI?
<mvo> pitti: I think I actually don't need them anymore, iirc the makefile was not that smart initially but thats fixed
<pitti> dh_install and dh_apparmor etc. sohuld also create missing dirs
<pitti> mvo: ok, accepted; I'll do the binNEW in a bit when it's built
<mvo> pitti: \o/
<mvo> pitti: and I fix the issues
<pitti> mvo: cheers
<dpm> dholbach, davidcalle, done
<dpm> ah, wait, the bbb box is still missing
<dpm> on it
<pitti> mvo: FTR, it's depwait on arm64/ppc64el because of missing seccomp
<pitti> mvo: IIRC arm64 is a snappy target, so we have to sort that out in wanking
<pitti> or wobbly, or whizzy, or whatever 15.10 will be :)
<asac> mvo: yes those examples are good; i am not sure though if we want to tell the world to use the oem.snap to ship executables too
<asac> mvo: so hw-assign for sure
<asac> the other ... maybe superseeded or make a smaller pair than the demo
<asac> davidcalle: dholbach: o/
 * dholbach hugs asac
<asac> davidcalle: dholbach: seems the list in docs TODO is significantly shorter now!
<asac> davidcalle: dholbach: anything to crunch througjh/review first thing now?
<pitti> mvo: binNEWed, and infinity unblocked it, so it should hit vivid in a few
<davidcalle> asac, yeah, we deleted a lot of cruft ;-)
<mvo> pitti: \o/
<dholbach> asac, still a bit unsure on what to land wrt OVA
<davidcalle> asac, and Vagrant
<davidcalle> asac, I've also added a comment for you on https://trello.com/c/L6sBYZqC/44-start-beagleboard-kvm-instructions-better-download-experience , that's pretty much it, afaik
<asac> davidcalle: yeah, so i think having two commands might be confusing... but we should explain that this command is getting XXX and that other options are avail on the right
<davidcalle> asac, ok, I think that's a good middle-ground
<dholbach> +1
<asac> davidcalle: on the beaglebone start i think this paragraph has to go now that webdm isnt highlighted there anymore: Try exploring the store and install one of the available snapps. If you have your own snapp you would like to publish, simply upload through the Ubuntu Software Store. Alternatively, as a developer you can also sideload snapps manually.
<asac> then it reads nice
<asac> davidcalle: so after the 1-2 minutes wait you can access it with ssh and start with the walkthrough
<dholbach> asac, but snaps are still "in the store"
<dholbach> "snappy search" will search the store, no?
<asac> dholbach: sure you could rephrase it ... but i would put the ssh into it first
<asac> because you cannot explore store unless you have anything :)
<dholbach> right
<asac> so 1. wait 1-2 munutes; 2. ssh into it; 3. if you want explore the store with snappy search or go for the tour
<asac> :)
<dholbach> davidcalle, do you want me to try to rephrase it?
<davidcalle> dholbach, sure :)
<dholbach> ok
<davidcalle> dpm, thanks for the boxes!
<dholbach> ok, done
<davidcalle> dholbach, lgtm
<dholbach> done - ship it!
<dpm> davidcalle, finished, added a Raspi 2 box too
<davidcalle> dpm, looking good, thanks
<asac> davidcalle: dholbach: how do you want to coordinate final updartes? trello cards or pings here?
<asac> its just a tweak here and there like making a link etc.
<mvo> can someone give me a hint how to generate a raspi2 snappy image? I guess I need the oem part of lool?
<beuno> mvo, that part should be in the store, FWIW
<dholbach> asac, as you like it
<asac> davidcalle: dholbach: so on the appluiance guiide we should urlify this paragraph a bit:
<asac> "As this guide makes intentional use of a very broad set of primitives provided by snappy Ubuntu Core 15.04, we recommend you make yourself familiar with how to setup a beaglebone as well as our various other guides and docs about the internals of a snappy system."
<asac>  "how to setup a beaglebone" -> link to /start#beagle...
<asac>  "various other guides" -> link to the guides landing page
<davidcalle> asac, right
<beuno> mvo, pi2.lool
<asac> davidcalle: think a link to the tutorials landing page too somewhere... mayber for that rephrase the sentence so it make sense and point them to all major entry points
<mvo> beuno: thanks, building now
<dholbach> dpm, ^ maybe we could make the nav bar more obvious in general?
<asac> davidcalle: next "assignment basically works in two steps:" ... there are bullets under that
<asac> that looks a bit messy ... also on appliance guide
<asac> guess you will see and know how to make better when olooking
<asac> dholbach: yeah the navbar is pretty good though, but i think having that stuff embedded in that paragraph is also good
<asac> it was made for that reason :)
<asac> we could also explain to look to the top of the page to find the nice navbar if that helps :P
<dpm> dholbach, which nav bar?
<dholbach> dpm, the one on developer.u.c
<dpm> you mean the TOC thing we put in the start page?
<dholbach> dpm, the one which shows "Guides Tutorials etc."
<utlemming> dholbach: just got up
<dholbach> dpm, when I showed the bar to people at the sprint who hadn't used dev.u.c before some said they had never noticed the navbar
<sergiusens> mvo: only thing that happened was a rebuild
<utlemming> dholbach: I'm a bit unclear what you need for integration.
<dholbach> I just thought asac's comment was similar in that regard
<dholbach> utlemming, me too :)
<dpm> dholbach, you mean the breadcrumbs?
<sergiusens> mvo: well and a change from default channel from edge t stable
<mvo> sergiusens: I think its my hardware
<dholbach> dpm, yes
<sergiusens> mvo: are you the only one?
<dpm> dholbach, that'd be a question for the web team, we're using their navigation patterns
<dholbach> ok, nvm then
<mvo> beuno: hm, I get a error that pi2.lool can not be found in the store is it available for rolling?
<asac> dholbach: utlemming: will you guys talk to sort out OVA and vagrant sections?
<asac> mvo: lool has it in a people dir too i think
<dholbach> utlemming, I'm not quite sure which of your blog posts to take and which bits to integrate to explain it well to users
<dholbach> asac, we are talking about it now
<asac> mvo: and its linked from the Pi2 instructions directly too
<asac> dholbach: good
<asac> :)
<beuno> mvo, it isn't, not even for 15.04  :)   https://myapps.developer.ubuntu.com/dev/click-apps/2332/
<beuno> but you can download it from there, if you just want the .snap
<asac> mvo: https://code.launchpad.net/%7Elool/+junk/pi2.lool/
<asac> mvo: http://people.canonical.com/~lool/pi2-device-and-oem/
<mvo> lool: could you set https://myapps.developer.ubuntu.com/dev/click-apps/2332/releases/ please?
<asac> mvo: he is off
<mvo> asac: thanks!
<asac> beuno: ^^
<davidcalle> asac, appliance guide fixed, thanks :)
<beuno> asac, mvo, I can fiddle with it in the admin, but maybe its better to re-upload under the shared account, instead of lool's personal one?
<asac> davidcalle: so the appliance guide also has bunch of things taht could be nice inline <code> formatted
<asac> davidcalle: like where we refer to "video0" or "/dev/..." or "some command" inline
<asac> not sure if you want to eyeball over it and do what you can spot ... maybe there is more important stuff to do
<asac> surely cosmetic
<dholbach> utlemming, if people expect to run ubuntu core in a vm locally (and not kvm), what should we recommend to them?
<davidcalle> asac, since it has long paragraphs, that's important to make these stand out, I'll take care of it.
 * davidcalle is afk for a moment
<dholbach> utlemming, I can see your vagrant instructions - shall I update the vagrant bits with http://blog.utlemming.org/2015/01/snappy-images-for-vagrant.html?
<dholbach> utlemming, and for ova (many will probably expect to download the images and just doubleclick them to get them working with virtualbox), shall I integrate everything from http://blog.utlemming.org/2015/04/using-snappy-ova-images-when-you-dont.html?
<dholbach> (or rather the first part of the latteR)
<utlemming> dholbach: yeah, update the vagrant bits with the instructions
<dholbach> asac, ^ do you have an opinion too?
<dholbach> utlemming, ok, looking into it
<asac> dholbach: if utlemming has an opinion i am agreeing with him :)
<asac> if not i always have an opinion on everuything as you know :P
<asac> to fill the opinion gaps of the world :P
<asac> davidcalle: so https://developer.ubuntu.com/en/snappy/guides/architecture/ i think we could have links below the nice graphics that link to intersting pages for the individual elements
<asac> davidcalle: like links about apps, about frameworks, about oem snap, about enablement (guess porting for now until we have omething better), and to the appliance guide
<asac> for the overall system
<asac> (just as an idea so the reader finds more info where he wants to deep dive
<utlemming> dholbach: I just realized that the links in my blog were bad on the bottom for the Vagrant instructions. I've updated them.
<dholbach> utlemming, are we going to add stable as well?
<utlemming> dholbach: yes, stable is building now
<dholbach> yeehaw!
<dholbach> thanks a lot utlemming!
<asac> davidcalle: so on our guides landing page (which looks pretty awesome tbh with good content) https://developer.ubuntu.com/en/snappy/guides/
<asac> davidcalle: can we make the lower list have the same nice graphics fopr the bullets as the upper one?
<dholbach> asac, I'll take care of it - davidcalle is gone for a bit (probaby looking after his sick kid)
<asac> oha
<asac> thanks
<dholbach> utlemming, check the vagrant section again and let me know if it's better
<dholbach> asac, looking after the guides page now
<asac> dholbach: also those nice boxes referring to our big guides could look even nicer if we would put a nice "education" icon from the official ubuntu icon set there (dont know if hwe have that, but i am sure we must have something for tutorials)
<asac> those boxes at the bottom
<dholbach> asac, bullet points fixed
<utlemming> dholbach: looks better, thanks
<dholbach> utlemming, rock and roll
<asac> dholbach: so i wonder ... maybe the tutorials should also become guides and go into simillara boxes at the end of tghe guides page?
<asac> dholbach: https://developer.ubuntu.com/en/snappy/guides/
<dholbach> utlemming, should I provide the information about the cloud config bits?
<asac> dholbach: https://developer.ubuntu.com/en/snappy/tutorials/
<asac> err
<asac> they look pretty sparse and its not clear to me what they are difference
<asac> dholbach: so we have just overivew, get started, guides, participate on top level hierachy
<dholbach> asac, guides are supposed to be explanatory, taking you by the hand and explaining the world from snappy's eyes - tutorials are step by step instructions to get something done
<dholbach> asac, https://design.ubuntu.com/wp-content/uploads/pictogram-help-orange-hex.svg
<dholbach> asac, https://design.ubuntu.com/wp-content/uploads/pictogram-education-orange-hex.svg
<dholbach> were you looking for any of these? ^ and where would you put them?
<dholbach> which boxes were you referring to? the image/channel link boxes?
<asac> mvo: i can make a port forward for you to look at my appliance
<asac> that is in the broken state
<mvo> beuno, asac: I uploaded pi2 as https://myapps.developer.ubuntu.com/dev/click-apps/2436/
<beuno> mvo, ask for a manual review
<dholbach> utlemming, vagrant instructions confirmed to be working - thanks
<asac> mvo: i have no permissions, but that is fine i hope
<beuno> mvo, ready to publish
<mvo> asac: what exactly should I do? fix it? what application is that? can I install it locally somehow? (I try to make my pi2 work right now9
<mvo> )
<asac> mvo: there are a few things i wnated to show you
<asac> a) right now the appliance was put together and the seccomp parts for arm were not picked up
<asac> if i install the app again with the board running it will work
<asac> b) howver it will not work with the current udev rule ... which is kinda the same as the one generated with hw-assign
<asac> which would then work again
<mvo> asac: yeah, that might be the need for a updated ubuntu-core-snappy-seccomp in the ppa/system?
<asac> mvo: so i guess i can give you a login and you could observe those things
<mvo> asac: yes, I am happy to do that
<mvo> asac: (b) is strange
<asac> mvo: could be, but i think it might be tricky... i have the feeling it has to do with the fact that thos are ARM specific syscalls
<asac> and our seccomp compiler is not good at crossing
<asac> tyhicks: jdstrand: ^ would have to check that i am sure
<asac> mvo: ok gimme a sec i will give you details and we can talk in /msg :)
<mvo> asac: ohhh, if its checking hte architecture its running on, that will not work. it need to generate all syscalls everytime :/
<asac> mvo: right, it might even be built time though if its not a text file
<mvo> indeed
<asac> e.g. it could be its in an #ifdef __arm__ in the libsecomp binary
<mvo> yeah, that would explain the brakage
<mvo> but I don't know the code, I guess its best to wait for jamie
<rcj> dholbach, the azure instructions will change a bit with naming changes made to incorporate the 'channel' name
<dholbach> rcj, if you can provide any pointers or explanation that'd be much appreciated
<rcj> dholbach, I emailed you the changes.  Bit too complex for irc.
<dholbach> utlemming, http://cloud-images.ubuntu.com/snappy/15.04/core/ has stable now
<dholbach> utlemming, shall I test it with vagrant and add it to the instructions
<dholbach> rcj, thanks, looking
<utlemming> dholbach: give me a minute first
<dholbach> utlemming, no worries
<dholbach> rcj, are there going to be stable images too?
<rcj> dholbach, hopefully.  The python2 / Azure agent issue is being worked to give us working images.
<rcj> dholbach, I'll ping you with that name for the examples when it exists.  But for now the 1504 edge is the image for the docs
<dholbach> rcj, updated - can you reload and confirm that that's what you expected?
<asac> sergiusens: so interesting is that i fell into the trap believeing the the seccomp was still the problem
<utlemming> dholbach: the Vagrant Cloud instructions should be "vagrant init ubuntu/ubuntu-15.04-snappy-core-stable"
<asac> sergiusens: but turns out that we dont generate the APP_DATA_PAH with udf for built-in stuff properly
<asac> is now my prob
<asac> sergiusens: mvo said something with writable path overload etc.
<asac> sergiusens: you want to log into my bbb and look at the situation?
<rcj> dholbach, not seeing updates on my end
<dholbach> rcj, ctrl-shift-r (might be the cache)?
<dholbach> utlemming, ok cool
<rcj> dholbach, I really don't see an update to Azure on http://www.ubuntu.com/cloud/tools/snappy Even loading it on a clean browser w/o cache
<dholbach> rcj, sorry
<dholbach> rcj, we moved everything over to http://developer.ubuntu.com/snappy/start
<dholbach> ... and we'll drop all technical stuff fomr ubuntu.com/cloud/tools/snappy
<dholbach> ... and ubuntu.com/things
<rcj> dholbach, those look good
<dholbach> rcj, <3
<dholbach> rcj, are you going to let me (and/or davidcalle) know later on if we will have stable images as well
<dholbach> ?
<dholbach> utlemming, I updated the vagrant docs again - they now point to stable by default and I added instructions for how to move to 'edge'
<dholbach> with that I'd think we'd be done for vagrant
<rcj> dholbach, utlemming or I will update you on release day names for cloud images
<sergiusens> asac: I think I know what tis is about
<sergiusens> asac: on second boot it should be there, if it is, then I know what it is about and I thought it was fixed
<dholbach> rcj, today is release day
<dholbach> so later on, I guess - can you please ping davidcalle and me - just to be sure one of us can get to it
<asac> oh
<asac> sergiusens: so i got autopilot reboot ... maybe its now working?
<rcj> dholbach, yeah, but they're not released yet (nor do they exist yet) ;)
<asac> sergiusens: no it didnt help
<sergiusens> asac: if it's there, there's a race of service start and dir creation
<asac> sergiusens: let me give you details
<rcj> dholbach, we'll keep you updated
<sergiusens> oh, it's something else then
<dholbach> rcj, thanks muchly
<sergiusens> asac: Apr 23 11:14:59 localhost systemd[1]: var-lib-apps.mount: Directory /var/lib/app
<sergiusens> s to mount over is not empty, mounting anyway.
<sergiusens> asac: that might explain
<sergiusens> asac: yeah, that's it
<sergiusens> asac: writable-paths might need a fix
<asac> sergiusens: is that a udf update?
 * asac thinks so
<asac> i am sure if i remove/install it will work
<asac> sergiusens: you need to look more?
<asac> or can i try that?
<sergiusens> asac: so, a new image is required
<sergiusens> asac: I change writable paths myself and rebooted your device
<asac> sergiusens: so you umounted, copied what was there and mounted and copied back?
<asac> sergiusens: current image still does right thing for parts installed after boot right?
<asac> just not preinstall?
<sergiusens> asac: so, I mounted read/write, modified /etc/system-image/writable-paths, rm -rf /writable/system-data/var/lib/apps and rebooted
<sergiusens> asac: yes
<asac> sergiusens: it is running :)
<asac> sergiusens: want to see if pluggin in video now just picks it up
<mvo> sergiusens: aha, writable-path wrong? that makes sense
<mvo> asac: if its up and running I would love to inspect the udev rules
<asac> mvo: yes log in again
<asac> i will wait with plug in
<asac> the udev rule looks good
<asac> and i am sure it will match with trigger
<asac> but yesterday it wasnt picked up ... e.g. access still denied
<asac> and hw-assign worked though
<asac> tell me when you are in :)
<mvo> sergiusens: I upload a new ubuntu-core-config with writable path fix unless you are already on it?
<mvo> asac: I'm in and what I see on the filesystem looks good, could you plug in the webcam?
<dholbach> utlemming, I integrated your http://blog.utlemming.org/2015/04/using-snappy-ova-images-when-you-dont.html blog post - if we get bugs about it, we'll fix them
<utlemming> dholbach: ack, link to the final product?
<asac> mvo: ok lets plug :)
<asac> mvo: its plugged
<asac> mvo: udevadm trigger --verbose --dry-run -
<asac> /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb1/1-1/1-1:1.0/video4linux/video0
<asac> err
<dholbach> utlemming, https://developer.ubuntu.com/en/snappy/start/
<sergiusens> mvo: please do, I broke something
<asac> mvo: $ udevadm trigger --verbose --dry-run --tag-match=snappy-assign
<asac> /sys/devices/platform/ocp/47400000.usb/47401c00.usb/musb-hdrc.1.auto/usb1/1-1/1-1:1.0/video4linux/video0
<sergiusens> mvo: so I changed none to transition for /var/lib/apps
<sergiusens> mvo: maybe we should change all of these paths to transition
<asac> mvo: but look at sudo systemctl status -l webcam-demo_webcam-demo_1.0.1.service
<asac> mvo: operatoin not permitted
<asac> mvo: so it is not perfect
<asac> even if you remove the ATTRS part of the rule it will not work
<dholbach> davidcalle, looking into 1447422
<asac> buyyt if you now run hw-assign it wuill start working again
<asac> mvo: any clue?
<asac> mvo: maybe we need to do a udevadm trigger settle etc. still?
<asac> mvo: very ood
<mvo> asac: I think I found the bug :( a typo in the apparmor rules, let me fix
<asac> i think it shot ONE picture
<asac> Apr 23 11:41:12 localhost.localdomain ubuntu-core-launcher[678]: Disabling the the banner.
<asac> Apr 23 11:41:12 localhost.localdomain ubuntu-core-launcher[678]: Writing JPEG image to 'shot.jpeg'
<asac> but then stopped doing it
<asac> very odd
<asac> very odd
<asac> not sure how to get complete log
<asac> maybe it worked but then something disabled it after a bit
<asac> mvo: its great that you found the bug!!!
<asac> not :(
<mvo> asac: look at it, it works now
<mvo> asac: well, you need to be video group or root but
<asac> mvo: well look at the service log
<asac> it still doesnt work
<asac> mvo: do i need to restart that
<mvo> asac: where is the service log?
<mvo> asac: oh, nevermind
<asac> sudo systemctl status -l webcam-demo_webcam-demo_1.0.1.service
<asac> i wanted this to start working :)
<asac> but if you hacked apparmor maybe we need to restart it
<asac> mvo: buut if you started from command line, first stop
<mvo> $ sudo systemctl restart webcam-demo_webcam-demo_1.0.1.service
<asac> then kill all stuff still running from your cli
<asac> and then start
<asac> the cli thing leaves stuff behind
<asac> if you ctrl-c it ... its a dirty script :)
<asac> mvo: right so there is a problem the jkpeg is black
<mvo> asac: so is it working now? the systemctl seems to be happy?
<mvo> asac: oh
<asac> but i am sure its because you left stuff over
<asac> mvo: you see the JPEG error?
<asac> thats a prob
<asac> let me stop
<asac> and kill all and start
<mvo> Apr 23 11:47:21 localhost.localdomain ubuntu-core-launcher[2879]: VIDIOC_DQBUF: No such device
<asac> right
<asac> its racy
<asac> because your CLI left stuff over
<asac> the CLI is only for debvugging
<asac> i shall remove it asap
<davidcalle> dholbach, ok, doing fixes on the appliance guide (fyi, I'm going to keep being on and off for ~1h)
<asac> mvo: weird
<asac> Apr 23 11:49:15 localhost.localdomain ubuntu-core-launcher[3231]: GD Error: gd-jpeg: JPEG library reports unrecoverable error: Not a JPEG file: starts with 0xea 0x2cCaptured frame in 0.00 seconds.
<asac> i still get that
<asac> maybe reboot
<asac> or replug
<asac> let me replug first :)
<mvo> ok
<asac> ok unplugged
<asac> log is as expected
<asac> nope
<asac> ok let me reboot
<asac> and laeve it plugged :)
<asac> if all is good it should just start working
 * asac decides its good to also power the board properly
<dholbach> davidcalle, I might run out for lunch in a bit - dpm, mhall119: will you be around if there are last minute docs changes for the snappy pages?
<asac> mvo: it works :)
<mvo> asac: yay!
<dpm> dholbach, I will be. Anything in particular we should watch for?
<asac> mvo: look at the shoot.jpeg in a few secs
<mhall119> dholbach: I won't be, about to get lunch myself and then leaving for Bluefin
<mvo> asac: ok, so we need one ubuntu-core-config fix and one snappy fix, both are already done so we just need to get a new image and a new u-d-f
<dholbach> asac, rcj, utlemming, mvo, slangasek: please ping davidcalle and dpm and me if you have changes which should go to developer.ubuntu.com/snappy/*
<dholbach> mhall119, gotcha
<dholbach> dpm, pings :)
<kickinz1> asac: owncloud ko on new bbb r33 image...
<dpm> ok :)
<asac> kickinz1: yes because of bad path
<asac> writable
<kickinz1> asac: ok reading scrollback
<asac> sergiusens: does the writable path work
<asac> if you reboot
<asac> and install?
 * asac wonders when this regressed
<asac> kickinz1: so maybe uninstall, reboot, install fixes it
<asac> kickinz1: for all software
<asac> dont install on first boot
<asac> weird
<asac> though
<sergiusens> asac: it might of regressed when we removed click as the hooks tok care of these things iirc
<asac> Chipaca: around?
<Chipaca> asac: yarp
<asac> i have finished the guide... could yuo maybe do a quick read and do sggestions again?
<asac> Chipaca: page 17 onwards is new
<asac> the rest is unchanged
<asac> davidcalle: dholbach: so the guide got finished... Chipaca is doing some first round of wordsmithing and then i will hand it over for integration. new is from page 17
<asac> davidcalle: i made a final section "Question" where we should put our standard boilerplate on how to get in ocontact like on the porting guide
<Chipaca> asac: you know what would be cool? being able to express in hardware.yaml "when this device gets plugged in, start that service"
<davidcalle> asac, which guide is it?
<davidcalle> Chipaca, ^
<Chipaca> asac: first pass complete. Any resemblance to real persons, living or dead is purely coincidental.  Void where prohibited.  Some assembly may be required.  Batteries not included.  Contents may settle during shipment.  Use only as directed.  May be too intense for some viewers.
<Chipaca> davidcalle: it's not my link to hand out :-/
<davidcalle> Chipaca, well, is it the appliance webcam guide or something else?
<asac> Chipaca: lol
<Chipaca> davidcalle: yes, it's the webcam thing
<davidcalle> Chipaca, thanks :)
<davidcalle> asac, please don't validate chipaca changes on the doc, I need them for my fixes :)
<davidcalle> Well validate/accept suggestions
<davidcalle> Hmm, actually you can if you want, since this is all new text (/me grabs more coffee)
<Chipaca> davidcalle: the first paragraph i think was there last night
<Chipaca> but i spotted things in it that were wrong so :)
<utlemming> dholbach: AMI ID's for AWS: http://paste.ubuntu.com/10871048/
<asac> davidcalle: oh
<asac> davidcalle: i thought it was all new
<asac> davidcalle: i added a marker of all new stuff
<asac> you can just replace that
<asac> or append
<asac> at most there is one paragraph that was already there
<asac> with changes
<asac> davidcalle: all changes got accepted
<asac> ready to go!!
<asac> further changes i will not apply without telling you
<davidcalle> asac :)
<utlemming> dpm, davidcalle: can you update the AMI ID's with http://paste.ubuntu.com/10871048/
 * dpm looks
<davidcalle> dpm, I can do that after the guide if you want
<dpm> davidcalle, sounds good. Can I leave it in your hands, then?
<davidcalle> dpm, yeah
<dpm> thanks
<asac> davidcalle: dholbach: are you guys done with everything?
<asac> davidcalle: dholbach: if so the snappy tour could get some further attention
<asac> it is a bit unclean right now as is
<asac> but dont want to detour other stuff we already discussed
<davidcalle> asac, dholbach has already made a pass on it this morning, could you outline specific points you want changed?
<davidcalle> asac, in the meantime, I still have a couple things to finish
<asac> ok let me look at latest tour
<asac> davidcalle: dholbach: who is coordinating with peter the updaste of website?
<davidcalle> asac, dholbach maybe, not sure
<shadeslayer> oh halo
<shadeslayer> could someone expand on what's going on with the desktop stuff + snappy ?
<asac> hi shadeslayer
 * shadeslayer is quite interested
<asac> willcooke: ^^
<shadeslayer> I read https://plus.google.com/u/2/+WillCooke/posts/AxfoU3N1Ezo , but it doesn't really touch on nitty gritty details :P
<dholbach> asac, I talked to Peter - he said everything should be fine for release
<dholbach> utlemming, taking a look in a bit
<asac> dholbach: but who is coordinating when to roll out the changes?
<asac> are you telling him later"?
<asac> dholbach: asking him in -internal now
<asac> :)
<dholbach> asac, it'll be part of the whole website release
<asac> shadeslayer: so all this is pretty new and fresh
<asac> so there might not be very detailed gritty details :)
<shadeslayer> ah :)
<asac> shadeslayer: but willcooke is here and give you more up to date story
<shadeslayer> understandable, I'm just curious as to what's moving to snappy and what isn't
<dholbach> mvo, did you end the call? :-P
<shadeslayer> and if flavors ( or well, Kubuntu ) can leverage this as well
<dholbach> davidcalle, I'll update the AMIs
<davidcalle> dholbach, I'm doing it right now :
<davidcalle> :)*
<dholbach> ooooook :)
<dholbach> <3
<ogra_> shadeslayer, everything will mmove to snappy in tehh long term ... but as i said in the other channel, the existing stuff wont go away ... if you want to move to snappy as well yu will just haveto use or provide the right framework packages i guess
<shadeslayer> mhm
<shadeslayer> ogra_: so ... you won't share any packaging with debian in the long term?
<shadeslayer> or do you plan to push snappy to debian?
<ogra_> ther is no deb support in snappy currently
<ogra_> its all snaps ... and snaps are more like tasks than like single binary packages
<davidcalle> dholbach, I've done the change, but I don't mind a second pair of eyes on it.
<dholbach> davidcalle, let me take a look
<ogra_> i.e. in my vision of the future desktop there are framework snaps for Mir, Wayland or plain Xorg ... then framework snaps for the different desktop flavours ... and on top your snaps of desktop apps
<ogra_> and on the low level some shared functionallity framework snaps (printing, avahi etc) that all on top can consume
<willcooke> shadeslayer, asac, sorry, was in a meeting...
<ogra_> but thats only my personal vision ... there has nothing official been defined yet
<willcooke> shadeslayer, best thing is to listen in on the UOS sessions
<willcooke> shadeslayer, but in a nut shell...
<dholbach> davidcalle, looks good!
<willcooke> shadeslayer, we're creating a Snappy Personal Image (similar to an ISO) which will use Snappy packages instead of debs for the installation of software.
<willcooke> to start with we are going to be pre-installing a lot of software while we get to grips with Snappy packaging
<ogra_> ubuntu-desktop framework snap :)
<willcooke> but over the course of the next 6 months more and more things will become snaps, and fewer and fewer things will be in the image
<davidcalle> dholbach, thanks :)
<willcooke> e.g.  Today, LibreOffice might be in the image, in a few months there will be a LibreOffice Snap which you can install
<willcooke> and, like the .deb version, the desktop package will pull in a lot of apps by default, like LO
<willcooke> plus it'll be Unity 8 & Mir of course
<dholbach> davidcalle, are we done now? :)
<dholbach> I think we are... minus bug reports and some 'edge' images which still have to pop up, right?
<shadeslayer> willcooke: I see, thanks for providing some insight :)
<willcooke> shadeslayer, no worries, feel free to drop in to #ubuntu-desktop and chat with us some more, plus UOS sessions of course
<shadeslayer> ofcourse :)
<davidcalle> dholbach, I think so! Which bug reports?
<dholbach> davidcalle, those that come in later on :)
<dholbach> I fixed one by steve earlier
<davidcalle> dholbach, oh right :) eg. https://bugs.launchpad.net/developer-ubuntu-com/+bug/1447626
<davidcalle> asac, what can we say for this report? ^ Is there a command issue or the user has the wrong PPA on vivid?
<asac> davidcalle: i think its outdated udf
<asac> sergiusens: https://bugs.launchpad.net/developer-ubuntu-com/+bug/1447626
<asac> can you confirm?
<sergiusens> yes
<sergiusens> davidcalle: you need the ppa even on vivid... I did have a small discussion with dholbach about this
<sergiusens> davidcalle: but if we default to everyone needing the ppa no matter what distro series you are on, support is so much simpler
<davidcalle> sergiusens, of course, what I'm wondering is: for this command to work, which PPA on vivid? The one called "beta" right?
<sergiusens> davidcalle: beta is what we promote, correct
<davidcalle> sergiusens, thanks, I'll mention it on the guide to clarify things.
<dholbach> sergiusens, mvo, asac: I have a problem - I just produced an updated image with udf (r35), but when I dd (incl. sync run) it onto my micro-sd it takes around 2-3 seconds only
<dholbach> I don't know what's going wrong
<asac> dholbach: its not right
<asac> dholbach: what /dev/node are you using?
<dholbach> any pointers on how I could debug it?
<dholbach> of=/dev/mmcblk0
<asac> dholbach: is that a built in thing?
<dholbach> yes
<dholbach> in a lenovo x220
<asac> dholbach: ls -la /dev/mmcblk*
<sergiusens> asac: that's fine, it's my def target as well
<sergiusens> oh, dd is broken
<sergiusens> hmm
<sergiusens> I mean, dd'ing
<dholbach> asac, http://paste.ubuntu.com/10871641/
<dholbach> what?!
<dholbach> how is dd broken?
<asac> dholbach: so it seems you dded to the bigh debice
<asac> when the device was down
<asac> dholbach: i would suggest to rm that file
<asac> and maybe it comes back automatically
<asac> dholbach: try to rm it
<asac> rm -f /dev/mmcblk0
<asac> if that doesnt work yhou need to reboot
<asac> or reload your eemc driver
<asac> i removed that file and replugged to get it back when i had that
<asac> the 3.9G file is hiding your devnode
<asac> afaict
<asac> most lkely its a mknod 179,0 /dev/mmcblk0
<asac> in case it doesnt reappear
<asac> but i would rather reboot than risk doing something naasty
<dholbach> 3900000000 Bytes (3,9 GB) kopiert, 6,75914 s, 577 MB/s
<dholbach> 6,7s
<dholbach> I don't think that's possible
<dholbach> but yeah, I'll reboot
<dholbach> brb
<dholbach> now it's complaining that  Â»/dev/mmcblk0â  is readonly
<dholbach> ok, now it's starting to copy - let's see if I can boot it later on
<dholbach> :)
<sergiusens> dholbach: mmcblk0 readonly might be becase the sdcard has a lock switch toggled
<dholbach> sergiusens, yes, that was the case this time - but what's bizarre: this morning I could toggle the switch whichever way I wanted, it was always readonly
<dholbach> anyway, now it seems to be happy
<dholbach> davidcalle, ah.... ok - now I got it - Tim was all about the porting guide
<dholbach> thanks
<dholbach> mvo, sergiusens, did you ever see something like http://paste.ubuntu.com/10871824/?
<sergiusens> dholbach: yes, a package with no namespace that isn't supposed to have one does
<sergiusens> dholbach: output of ls /apps /oem please
<dholbach> sergiusens, http://paste.ubuntu.com/10871833/
<sergiusens> dholbach: snappy list still works?
<dholbach> sergiusens, yes - http://paste.ubuntu.com/10871837/
<mvo> dholbach: I just got that
<mvo> sergiusens: I got that too, it is type framework, this is confusing
<sergiusens> mvo: so we are probably printing the wrong error
<sergiusens> dholbach: I need to fix the empty message on error
<davidcalle> dpm, dholbach, asac, what about hiding the Tutorials page for now? It brings nothing to the table.
<dholbach> davidcalle, the tour?
<sergiusens> mvo: oh, Chipaca has an mp
<sergiusens> ...
<davidcalle> Oh right, the tour is a subpage of it. Nevermind then :)
<asac> davidcalle: it has two tutorials linked, no?
<dholbach> yes, let's just leave it there for now
<dholbach> let's do more IA changes after the release
<dholbach> or... the other way around: let's try to avoid doing IA changes today :)
<mvo> sergiusens: thats for later, we need one fix from him, but no more non-critical bugs, I guess we need to fork trunk to 15.04 too at some point
<sergiusens> mvo: yeah, make last call and I'll create the series
<sergiusens> and trunk can move on
<davidcalle> dholbach, asac, yes yes, I've been focusing on the Guides page and forgot these 2 were under tutorials.
<lool> mvo: pi2.lool should be in the store since lsat thursday or so
<lool> I used it successfully from the store
<lool> but then I think we landed some store changes with namespaces, not sure if that changes anything
<lool> mvo: published rpi2.lool for 15.04 and rolling
<mvo> lool: I uplaoded pi2.canonical
<lool> mvo: oh great; so should I kill mine?
<mvo> lool: with a higher version number but otherwise identical
<lool> mvo: so we're officially supporting it?
<dholbach> lool, mvo: does that mean we need to update the docs? (https://developer.ubuntu.com/en/snappy/start/#snappy-raspi2)
<lool> I wasn't sure about that
<mvo> lool: probably, see other channel - uh, I don't know, thats a question for asac I guess
<lool> mvo: first, I thought we'd want rpi upstream to maintain, then I thought PES would maintain
<mvo> lool: someone (need to check backlog) suggested to use the canonical namespace for it
<lool> asac: ^
<mvo> lool: but I can unpublish if that is not actually what we want
<lool> mvo: you're right, we need asac on this Q
<asac> we dont want it to be .canonical for now
<asac> its fine to be .lool
<asac> we can discussin malta
<lool> mvo: ^
 * ogra_ notes down "want to be .lool"
<lool> ogra_: I'll upload an ogra.lool
<ogra_> lol
 * lool hug
 * ogra_ hugs lool 
<lool> my mailbox has blown completely out of proportions in the last 24 hours
<mvo> lool, asac: unpublished pi2.canonical
<mterry> How do I update a devel snappy install to devel-proposed?  I tried using system-image-cli but that doesn't seem to take effect
<mterry> (using --switch)
<dpm> mterry, I was just going to ask the same question :)
<mterry> :)
<mterry> jdstrand, did that framework-dependency issue every get resolved?
<jdstrand> mterry: oh yes, I never did ping you
<jdstrand> mterry: it's all good
<mterry> jdstrand, awesome
<jdstrand> mterry: that was fixed *ages* ago. like, Monday even
<mterry> :)
<jdstrand> :)
<jdstrand> mterry: happy release day btw :)
<mterry> w000
<rcj> mhall119, Updates for snappy start docs for cloud images.
<rcj> mhall119, change the gce example image name from "ubuntu-core-devel-v20141215" to "ubuntu-snappy-core-1504-stable-2-v20150423"
<rcj> mhall119, remove the table of AWS EC2 AMI ids of images.  There is a command to list them that will return the correct AMIs for a point in time; that cmd is already in the doc.
<rcj> mhall119, change the Azure example image name from "b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-15.04-Snappy-core-amd64-edge-20150423-36-en-us-30GB" to "b39f27a8b8c64d52b05eac6a62ebad85__Ubuntu-15.04-Snappy-core-amd64-edge-20150423.1-40-en-us-30GB" in all occurrences as this is the release image.
<rcj> dpm, dholback ^
#snappy 2015-04-24
<ash_charles> hello---I'm new to snappy and just learning my way around.
<ash_charles> I see an error "beagleboneblack_1.0_all.snap failed to install: Signature verification failed with exit status 10" when playing with the beaglebone example oem package
<ash_charles> any hints?
<ash_charles> Ah---the magic seems to be adding the '--developer-mode' argument for locally built packages
<D_Cent> hi, i installed java on my snappy ubuntu and now wrote a bash script which starts a java application which should be running as a service. the problem is that apparmor won't let me execute java, it says "Operation not permitted". can i allow java to be called somehow?
<D_Cent> (the service was installed as a snap)
<Chipaca> D_Cent: what exactly is getting blocked?
<D_Cent> Chipaca: the java call itself
<Chipaca> D_Cent: dmesg | grep DENY
<D_Cent> Chipaca: hm... that doesn't give me anything
<Chipaca> D_Cent: then it isn't apparmor
<D_Cent> Chipaca: systemctl status says: Apr 24 07:01:04 localhost.localdomain ubuntu-core-launcher[1318]: /apps/rda-watchdog.sideload/0.1/bin/rda-watchdog: line 4: /usr/bin/java: Operation not permitted
<Chipaca> D_Cent: wait, you installed java to /usr/bin/?
<D_Cent> Chipaca: well, I basically just installed the raspbian debian package - I didn't find a snap or anything for snappy
<Chipaca> haha
<Chipaca> D_Cent: how did you install a package from a different architecture? isn't raspbian armel?
<D_Cent> Chipaca: i've got "oracle-java8-jdk_8_armhf.deb", so i guess not ;)
<Chipaca> D_Cent: looks like there is an armhf raspbian. fair enough.
<D_Cent> Chipaca: so why is the call getting blocked? is there another way to get java working?
<Chipaca> D_Cent: it's not getting blocked; it's probably entirely broken
<Chipaca> D_Cent: can you run java from the terminal?
<D_Cent> Chipaca: but i can execute the script when not using systemd
<D_Cent> Chipaca: exactly
<Chipaca> D_Cent: once you've installed a debian package onto a snappy system it is not a snappy system any more, you're pretty much on your own there. have you looked into whether seccomp is blocking it somehow?
<Chipaca> i've got to go, but can probably help you a bit further when i return in an hour and half or so
<D_Cent> Chipaca: okay, thank you!
<Chipaca> D_Cent: meanwhile, look into seccomp
<D_Cent> I'll do
<ogra_> D_Cent,  you either need to put the java install inside your snap or you need to create a framework package if you actually need to consume java from multiple snaps ... installing a deb will be reverted completely on updates
<dholbach> good morning
<ogra_> Chipaca, raspbian is armhf but ARMv6 ...
<D_Cent> ogra_: okay, so this will be a problem for me then... for example, i need wi-fi (wpa_supplicant) and that doesn't come with ubuntu core, so i installed that with dpkg, too
<davidcalle> dpm, when trying the appliance guide last night, have you been hitted by this (second part of the bug) ? https://bugs.launchpad.net/snappy-ubuntu/+bug/1447724
<dpm> davidcalle, that's the bug that I fixed
<davidcalle> dpm, oh! Cool :)
<dpm> davidcalle, the .sideload references are now .canonical
<davidcalle> dpm, ok, makes sense
<dpm> davidcalle, I think it's because the original version of the guide was written with a locally-installed snapp, whereas a store snapp was made available afterwards. At least that's what I think
<dpm> after changing the instructions to .canonical, the guide worked for me
 * davidcalle should get a bbb
<mhall119> davidcalle: dholbach: did rcj's changes to the snappy docs get made yesterday?
<davidcalle> mhall119, yep
<dholbach> mhall119, davidcalle responded at 23:54 CET
<JamesTait> Good morning all; happy Friday and happy Teach Your Children to Save Day! :-D
<Chipaca> D_Cent: so if you need to use something like wap_supplicant, i think you need to create a framework package with that, and then make your package depend on the framework
<Chipaca> D_Cent: however, i do believe the intention is for core to have some kind of wifi story soon :)
<Chipaca> it might just mean that we're going to create that framework package ourselves
<D_Cent> Chipaca: that would be great :)
<Chipaca> D_Cent: meanwhile you might need to muddle through it on your own though :)
<Chipaca> it's not even on the trello yet
<Chipaca> afaik :)
<D_Cent> Chipaca: so now i'm trying to put java directly into the snap and it *seems* to work. Now I have to deal with other issues that the usb4java library has ;) (temporary directory creation)
<Chipaca> D_Cent: temp dir should be set up properly though
<D_Cent> Chipaca: i guess it tries to create that directory right where you call the java command from, but i guess i can fix that :) i just hope that i won't run into problems when accessing usb devices
<Chipaca> D_Cent: what directory is it trying to create?
<Chipaca> D_Cent: wrt usb devices, that's what âsnappy hw-assignâ is for
<D_Cent> Chipaca: it should be /apps/rda-watchdog/watchdog/usb4java
<Chipaca> D_Cent: your thing is a framework?
<D_Cent> Chipaca: right now it's just an app
<Chipaca> D_Cent: that's not the path of an app though
<D_Cent> Chipaca: ah wait...
<D_Cent> Chipaca: /apps/rda-watchdog.sideload/current/watchdog/usb4java is the correct path
<Chipaca> better :)
<D_Cent> :)
 * Chipaca hadn't even notice the missing version in the first one
<Chipaca> D_Cent: your app is trying to write there?
<D_Cent> Chipaca: the usb4java framework wants to extract a jar file temporarily to get access to a native library which it then wants to load
<ogra_> so you need to ship that library inside
<Chipaca> ogra_: java doesn't give you too much control over that, does it?
 * Chipaca doesn't know
<D_Cent> i'll try that :)
<ogra_> Chipaca, i think java uses enmv vars you can shufflke around
<Chipaca> D_Cent: if your java thing expects PWD to be writeable, better cd to $SNAP_APP_DATA_PATH (or $SNAP_APP_TMPDIR ?) before starting it
<Chipaca> ogra_: or -Xeogijuoifvhiofiodsfqrigikvnueoicodifighiu43
<Chipaca> or maybe it was 44, and 43 was "go buy beer"
<Chipaca> hard to know
<D_Cent> Chipaca: aah thanks, that's a better idea
<Chipaca> D_Cent: if you're running on an arm board, and you know that extracion is happening every time your app starts, and you can instead ship things unextracted, go with that
<Chipaca> D_Cent: save yourself some time
<Chipaca> s/arm/low power/
<Chipaca> probably same applies for the intel thingamajig
<D_Cent> Chipaca: hmmm 2cd: /tmp/snaps/rda-watchdog.sideload/0.1/tmp: No such file or directory"
<D_Cent> Chipaca: that happens when trying "cd $SNAP_APP_TMPDIR"
<Chipaca> D_Cent: hm. maybe you need to mkdir -p it first?
<Chipaca> if that doesn't work, double-hm :)
<D_Cent> okay, double hmm ;) "mkdir: cannot create directory â/tmp/snapsâ: Permission denied"
<Chipaca> tee, hee. ok. that's a Bug
<Chipaca> D_Cent: hm. the code to make it is there.
<Chipaca> D_Cent: maybe you're running something old/ancient?
<Chipaca> D_Cent: there's a mkdir in the wrapper in /apps/bin/<your app>
<D_Cent> Chipaca: i just build my image yesterday with ubuntu-device-flash
<D_Cent> *built
<Chipaca> D_Cent: could you pastebin the wrapper?
<D_Cent> Chipaca: you mean my script which starts the java process?
<Chipaca> D_Cent: no, i mean the wrapper that's created for the binaries declared in your package.yaml and placed in /apps/bin/
<Chipaca> D_Cent: which is what sets up the environ for your app before calling it with ubuntu-core-launcher
<D_Cent> Chipaca: aah sure, just a sec
<D_Cent> Chipaca: http://pastebin.com/sszsfZGt
<Chipaca> D_Cent: so, that fine; that creates the directory
<D_Cent> Chipaca: okay, but i start that as a service
<Chipaca> D_Cent: you .. what?
<D_Cent> Chipaca: it is supposed to be started by systemd
<Chipaca> D_Cent: but then it's not a binary, it's not in /apps/bin/
<Chipaca> i'm making you look in the wrong place :)
<D_Cent> Chipaca: hehe so basically, i just run "sudo systemctl start rda-watchdog_rda-watchdog_0.1" and that runs the systemd script in /etc/systemd/system - seems like that doesn
<D_Cent> * doesn't use /apps/bin
<Chipaca> D_Cent: so, could you pastebin the service file from /etc/systemd/system/ ?
<Chipaca> D_Cent: should be something like rda-watchdog_yourservice_yourversion.service
<D_Cent> Chipaca: sure :) http://pastebin.com/jN2Gq3SK
<Chipaca> hmmmm :)
<Chipaca> dunno why i asked you to do that. no surprises there.
 * Chipaca digs into it
<D_Cent> hehe thanks :)
<Chipaca> pitti: i've got a systemd question for you when you're around
<D_Cent> Chipaca: now i see what it is trying to do - app armor reports: "audit: type=1400 audit(1429867806.982:39): apparmor="DENIED" operation="mknod" profile="rda-watchdog.sideload_rda-watchdog_0.1" name="/tmp/usb4java2636409983806462228.tmp" pid=2021 comm="java" requested_mask="c" denied_mask="c" fsuid=0 ouid=0"
<Chipaca> D_Cent: good. now you need to find out what env var is needed so that it uses the "right" tmpdir
<Chipaca> D_Cent: while i sort out that right tmpdir getting created, you should be able to create it yourself from outside
<D_Cent> Chipaca: for the moment, i just use $SNAP_APP_DATA_PATH which exists and is writable
<Chipaca> D_Cent: ok :)
<Chipaca> mvo: sergiusens: I *think* we need to put something in tempfiles.d so the services get their tmpdir. Waiting for confirmation from pitty wrt that.
<pitti> Chipaca: just shoot
<Chipaca> pitti: we're telling services they should use a given TMPDIR
<Chipaca> pitti: that TMPDIR does not exist
<Chipaca> pitti: poking around a little it seems we need to drop a file in one of the tempfiles.d
<Chipaca> pitti: is that the right way?
<Chipaca> pitti: so a file named like the package, with one line of the form âd $TMPDIR 1777 ubuntu ubuntuâ per service
<pitti> Chipaca: that works, but TBH I'd rather set this up in ubuntu-app-launcher
<pitti> Chipaca: i. e. just mount  a private /tmp/ into the app's namespace, so that you don't need a $TMPDIR at all
<Chipaca> pitti: that sounds a lot better; a lot of code doesn't check TMPDIR anyway.
<pitti> Chipaca: yeah, that was my concern
<pitti> Chipaca: I noticed that with the ROS snap, I had to sed its code to make it respect TMPDIR
<ogra_> can you actually call mount from a snap ?
<Chipaca> ogra_: not on my watch :)
<pitti> ogra_: no, you don't need to, just the launcher
 * Chipaca doesn't actually have a watch
<ogra_> ah, so systemd then
<pitti> ?
<Chipaca> ogra_: no, ubuntu-core-launcher
<pitti> (not related to that)
<ogra_> oh, thats a new thing ...
<Chipaca> ogra_: maybe. it's also setuid.
 * ogra_ only has dones service snaps yet
<pitti> at least in my PoC I already create a new namespace for mounting a private /dev/pts/
<pitti> it's trivial to add a tmpfs /tmp/ there
<pitti> I think that might not yet be in mvo's C implementation in vivid, but at some point we want to add it
<Chipaca> pitti: is that PoC on the launcher, or is it something else?
<Chipaca> ah
<Chipaca> ok :)
<pitti> Chipaca: on ubuntu-core-launcher, yes
<Chipaca> so, we probably want to do that soon
<Chipaca> because services have no tmpdir right now
<pitti> yeah, agreed
<pitti> and also the /dev/pts/ so that apps can't spy on each other's terminals (well, apparmor would/should prevent that too, but it's still cleaner)
<Chipaca> pitti: sgtm. asac also wanted private /dev/, but that's hairier
<Chipaca> anyway, sounds like we have a plan for this, and either you or mvo are on it already. I'll go back to worrying about obscure error cases.
<Chipaca> D_Cent: meanwhile, you'll have to create the directory by hand every time (or create a file in /etc/tmpfiles.d; man tmpfiles.d)
<pitti> Chipaca: we have restricted device access already
<pitti> Chipaca: private /dev/ was teh original plan and PoC, but we have something better now (using the devices cgroup)
<D_Cent> Chipaca: alright, thank you!
<Chipaca> pitti: ok :) i thought we'd had to go back on that for now, but glad to be wrong
<Chipaca> pitti: added a comment on the /dev/pts card so we don't forget
<mvo> yeah, private /tmp and /dev/pts is planed just not done yet and will be added soon(ish)
<D_Cent> hm... got another problem now. i put java into an own framework package and it works completely. now i have an app, set java as a framework for the app and tried calling "java". without mentioning the path "/apps/bin/java" it doesn't find the executable. if i use that path directly, i get an "operation not permitted" error
<sergiusens> fwiw, and executable shouldn't be a framework
<sergiusens> a framework should be something that mediates resources
<D_Cent> hm.. okay, the documentation mentions i could put binaries and services into frameworks
<ogra_> sergiusens, an interpreter isnt a resource ?
<sergiusens> ogra_: i felt that was coming
<ogra_> lol
<sergiusens> it will be very hard to claim the 'java' namespace in any case
<D_Cent> can somebody explain what exactly java tries doing here so it gets killed? "[24632.544408] audit: type=1326 audit(1429880585.774:262): auid=1000 uid=0 gid=0 ses=25 pid=4173 comm="java" exe="/apps/rda-watchdog.sideload/0.1/java/bin/java" sig=31 arch=40000028 syscall=370 compat=0 ip=0x76ede622 code=0x0"
<jdstrand> pitti: fyi, the private /dev conversation was because cgroups don't block what the app sees, only what the app accesses. so, ls /dev shows everything even if the app can only access /dev/foo. personally, I think that is fine. we aren't trying to reimplement container solutions-- if people want containers, they can use them
<mvo> D_Cent: try scmp_sys_resolver 370
<mvo> D_Cent: this looks like there is a missing syscall in our seccomp whitelist
<ogra_> well, he is using an ARMv6 binary ...
<ogra_> could be related
<mvo> yeah, we had issue with the arm private syscalls before
<mvo> libseccomp did not implement them all, jdstrand send a patch upstream, maybe there are more private arm syscalls (but really I'm no expert for this)
<jdstrand> I haven't sent one yet
<jdstrand> err
<jdstrand> haven't sent it upstream yet
<jdstrand> there were 5 listed in the kernel sources and confirmed in other seccomp implementations (firefoxos, minijail)
<jdstrand> we shouldn't have any more missing syscalls. our template might be missing one
<jdstrand> the private syscalls have a much higher number. 370 is in the normal range and not a private arm syscall
<mvo> ahah, ok
<mvo> sorry
<jdstrand> on bbb:
<jdstrand> $ scmp_sys_resolver 370
<jdstrand> name_to_handle_at
<jdstrand> name_to_handle_at is explicitly denied due to "a history of vulnerabilities and are not widely used"
<jdstrand> tyhicks: can you look at backscroll for 1 hour and advise?
<jdstrand> tyhicks: it appears java is trying to use name_to_handle_at
<D_Cent> mvo: thanks a bunch! can you also tell me how to enable the syscall by default?
<jdstrand> D_Cent: please read my comments
<jdstrand> this is a problematic syscall and we've disabled it
<D_Cent> jdstrand: ah okay, i'm sorry
<jdstrand> you now, you can add it manually to /var/lib/snappy/seccomp/profiles/<yourapp>
<jdstrand> but it will be lost on upgrade
<D_Cent> jdstrand: that's what i did for now :/
<jdstrand> you might be able to avoid it in your java code
<D_Cent> jdstrand: it's actually not my code - it happens in the usb4java library (which basically is based on a C library)
<jdstrand> this gives some information on the call: http://manpages.ubuntu.com/manpages/utopic/man2/open_by_handle_at.2.html
<jdstrand> D_Cent: perhaps there is a way to disable it at compilation. It was introduced in 2.6.39 kernel (~4 years ago). if this library is meant to be used on older kernels...
<tyhicks> I'm looking at how/why usb4java is using that syscall
<D_Cent> jdstrand: i didn't compile it myself yet, so i guess i should do that now. the library i use now was built on GCC: (Debian 4.6.3-14+rpi1) 4.6.3
<jdstrand> tyhicks: hi! (and thanks)
<tyhicks> jdstrand: hey :)
<jdstrand> D_Cent: you might wait for tyhicks' response
<tyhicks> D_Cent: hi - I've cloned the libusb4java and usb4java git trees and I'm not finding where that syscall is being made in either of them
<tyhicks> D_Cent: can you give me some more info? (is it a specific version of libusb4java?)
<ogra_> tyhicks, he is grabbing the binaries from raspbian ...
<ogra_> which is a hacked up armhf, forced to ARMv6 instead of v7 ...
<D_Cent> tyhicks: i can't find it either by just grepping, so it must be an indirect call i think
<ogra_> (so they rebuild the debian archive with different compile options)
<tyhicks> hrm
<D_Cent> tyhicks: the function is called once i call "UsbHostManager.getUsbServices()"
<tyhicks> this is really odd
<tyhicks> I've never heard of anything needing that syscall other than an nfs server that was implemented in userspace
<D_Cent> tyhicks: i'm also very confused. everything else in my java code is working, just not that usb library call
<jdstrand> tyhicks: fyi, https://codesearch.debian.net/results/name_to_handle_at/
<tyhicks> jdstrand: I'm on page 8 :)
<tyhicks> btw, "UsbHostManager.getUsbServices()" is from javax-usb and I pulled down their git tree and don't see it being called in there
<jdstrand> oh, interesting
<tyhicks> jdstrand: I didn't see any packages actually using name_to_handle_at... only things that need to enumerate the syscall table
<jdstrand> http://sources.debian.net/src/docker.io/1.3.3~dfsg1-2/contrib/mkseccomp.sample/?hl=393#L393
<D_Cent> i wish i could track that system call down a bit more, like with a call stack or something
<jdstrand> docker blocks it by default. of course, they have a way to add it
 * jdstrand notes we have a way to add blocked syscalls to via the "security-override" mechanism, however, this particular one is explicitly denied
<jdstrand> too*
<D_Cent> :(
<tyhicks> I'm wondering if the "hacked up armhf, forced to ARMv6 instead of v7" part is the problem
<tyhicks> maybe the syscall number is different somehow??
<ogra_> that was what i thought ...
<D_Cent> tyhicks: the oracle JVM runs fine on raspbian on the same machine (raspberry pi 2)
<tyhicks> D_Cent: what is the oracle JVM version?
<D_Cent> tyhicks: they only put the major version (8) into the package name
<tyhicks> ok
<tyhicks> D_Cent: I pulled down the tip of the jdk8u tree (http://hg.openjdk.java.net/jdk8u/jdk8u/) and I'm still not seeing open_by_handle_at() being used
<tyhicks> D_Cent: I'm pretty convinced that nothing is using that syscall and there are other low level issues at play around syscall numbering
<D_Cent> tyhicks: is there a way to make sure?
<tyhicks> D_Cent: I can try to find the source of the kernel that you're running
<D_Cent> tyhicks: or i'll try the openjdk package from here: https://launchpad.net/ubuntu/+source/openjdk-8
<tyhicks> D_Cent: you can try that but don't spend too much time on it
<blackout24> Hello, I'm trying to get a better understanding of Ubuntu Snappy. I'd like to know how the system image is put together (I guess this is made from debs) and how the "ubuntu-core" package that list listed by "snappy list" is created. I looked around on launchpad, but I'm a bit lost.
<tyhicks> D_Cent: I don't think it'll help since I think the problem is lower in the stack than openjdk
<jdstrand> tyhicks: fyi, http://paste.ubuntu.com/10879065/
<jdstrand> tyhicks: do you have a moment to go through that with me?
<nessita> mvo, hey, you around?
<jdstrand> tyhicks: well, a few moments
<tyhicks> jdstrand: yeah, we should talk through that diff soon
<tyhicks> D_Cent: what kernel version? `uname -r`
<nessita> jdstrand, o/ do you know, by any chance, if the snaps define "hooks" in their manifest, or the "hooks" is just a click thing?
<ogra_> tyhicks, he is not using openjdk but oracles java for RPi ... ;)
<jdstrand> nessita: hooks are click only
<nessita> jdstrand, great, thanks
<jdstrand> (white lie-- click-apparmor is still a hook, but that will be removed in coming weeks
<jdstrand> )
<tyhicks> ogra_: uhh... happen to have a link to that source?
<D_Cent> thecomedian: 3.19.1-4-generic-bcm2709
<D_Cent> woops
<ogra_> tyhicks, no, i just followed the conversation before you joined ... i guess D_Cent has one though
<D_Cent> thecomedian: 3.19.1-4-generic-bcm2709
<D_Cent> tyhicks: 3.19.1-4-generic-bcm2709 - now i got that right
<ogra_> (and i doubt there is source .... being oracle )
<thecomedian> lol
<D_Cent> thecomedian: sorry, auto completion by irssi ;)
<thecomedian> np :)
<ogra_> tyhicks, next time you need to know D_Cent's kernel version, ask thecomedian ... he has it spare ... twice :)
<tyhicks> :)
<thecomedian> :-P
<D_Cent> hehe
<D_Cent> tyhicks: okay, the openjdk doesn't make it better
<D_Cent> bbl
<vmayoral|pc> greetings
<vmayoral|pc> asac: We keep finding the issues with the boot partition getting corrupted in Snappy. Has someone addressed this in newer versions of snappy for the BBB?
<jodh> davidcalle: hi - I've just noticed that https://developer.ubuntu.com/en/snappy/guides/filesystem-layout/ is outdated. The latest details are in http://bazaar.launchpad.net/~snappy-dev/snappy/snappy/view/head:/docs/system-updates.rst
<jodh> davidcalle: do we plan to put that doc up as a separate one at some point?
<jodh> davidcalle: bug raised - https://bugs.launchpad.net/snappy-ubuntu/+bug/1448203
<jdstrand> sergiusens: hey, can you add this to your webdm profile: '@{PROC}/sys/net/core/somaxconn r,'
<jdstrand> sergiusens: see snappy-dev@
<jdstrand> sergiusens: there is another denial that we should address as well
<jdstrand> slangasek: fyi:
<jdstrand> $ sudo snappy update
<jdstrand> Installing ubuntu-core (36)
<jdstrand> Starting download of ubuntu-core
<jdstrand> 136.29 KB / 136.29 KB [=================================================================================] 100.00 % 3.35 KB/s
<jdstrand> Done
<jdstrand> Failed to run command '/bin/mount -obind /boot/uboot /writable/cache/system/boot/uboot': mount: mount point /writable/cache/system/boot/uboot does not exist
<jdstrand>  (exit status 32)
<jdstrand> I think that might be what is reported in the bug on upgrade problems
<jdstrand> (that is a bbb)
<slangasek> jdstrand: yes, it's certainly the same bug.  what was your upgrade path on this system?
<slangasek> after one update on the stable channel, I've got /boot/efi and /writable/cache/system/boot/efi which I don't think were there before.  I also have /boot/uboot still correctly in place
<jdstrand> slangasek: r33 trying to go to r36
<slangasek> jdstrand: and r33 was the initially installed version?
<jdstrand> slangasek: note, I've tried several times to upgrade
<slangasek> ok
<jdstrand> slangasek: actually, I think I started on r30, got to r33, then tried r36
<jdstrand> slangasek: not sure if you say my other comments in that bug-- previous attempts had umount errors and autopilot errors in syslog
<jdstrand> s/say/saw/
<slangasek> ok
<yngves> What is the intended behaviour if an app specifies a framework that is not installed? Resolve the dependency by installing the missing framework? Fail, and inform the user what is missing?
<tyhicks> D_Cent: Hi - I got pulled into something else for a while but I just got a chance to look at the kernel sources that you're running
<tyhicks> D_Cent: it looks like name_to_handle_at is syscall 370 there, too
<tyhicks> D_Cent: however, I still think something odd is going on and don't feel comfortable white listing that syscall until we see the same behavior on one of the officially supported platforms
<tyhicks> D_Cent: could you please file a bug against ubuntu-core-security so that we can track the issue?
<HoloIRCUser2> Hi, can anyone hell me? I tried snappy 15.04 stable and edge (in kvm). And i want to try the webdm, but there is no service which listen in a TCP port except ssh.
<asac> vmayoral|pc: not sure which version you are using
<asac> vmayoral|pc: but we surely invested into making this pretty reliable
<asac> HoloIRCUser2: we are working on making webdm work on 15.04 right now... in a couple days an update will be in sotre that will bring the webserver back
<HoloIRCUser2> Help not hell ^^
<asac> HoloIRCUser2: its fine... i didnt even read "hell" until you mentioned it
<asac> HoloIRCUser2: https://developer.ubuntu.com/en/snappy/guides/webdm/ read the box on the right
<asac> :)
<HoloIRCUser2> ADAC: thank you very mich!
<davmor2> HoloIRCUser2: in kvm you need to set the port,  you'll see other examples of it.
<asac> welcome!
<HoloIRCUser2> Lool, German Android keyboard
<asac> davmor2: that too, but webdm we preinstall doesnt start the server because its not compatible with latest snappy tooling yet... had to make that decision to get base system rock solid for release
<asac> buut couple days it will all look great and even better than before
<davmor2> asac: yeah I got hit installing it and couldn't figure out why I couldn't access it
<asac> HoloIRCUser2: android keyboard? wow... guess you try snappy on your laptop right now? :)
 * asac uses his laptop for ubuntu core amd64 now
<asac> davmor2: i am sure sergio is hacking on the plane right now to get us stuff back
<asac> :)
<asac> vmayoral|pc: would you mind trying with the released image?
<asac> or rather 15.04/edge
<asac> if you want bleeding edge from stable
<asac> vmayoral|pc: so many things did land in last couple weeks that you surely want to update
<HoloIRCUser2> davmor2: i connected to the console and searched with netstat for listening ports. I know what you mean. I am using bridge and not a internal network for the guests
<asac> jdstrand: what was your upgrade series to get into that state?
<asac> slangasek: you think you can try the upgrade path 30 -> 33 -> 36? i think its about the same kickinz1 had
<asac> jodh: can you provide an update to just filesystem doc? and at best integrate that as a separet md
<asac> we want one that is just about that
<asac> the system upgrade is good, but should refer to the spec that is just about that at best
<asac> thx
<asac> btw, interesting discussion going on here: http://www.phoronix.com/forums/showthread.php?117235-Ubuntu-s-Desktop-Next-Switching-From-DEBs-To-Snappy
<jdstrand> asac: sorry was in a meeting
<asac> some folks seems to get it
<asac> jdstrand: i just asked 2 minutes ago :)
<jdstrand> asac: flash r30, upgrading to r33, tried to get to r36
<jdstrand> I noticed autopilot errors after r33
<jdstrand> r30 to r33 was ok
<jdstrand> if there were errors, I didn't see them
<jdstrand> (there weren't on the console for sure)
<asac> right we must not send an update to the stable channel until we have figured
<asac> slangasek: did you pull 3?
<asac> just triple checking :)
<jdstrand> I would agree with that
<jdstrand> (being cautious)
<HoloIRCUser2> asac: which box do you mean, I can't find such box ^^
<D_Cent> tyhicks: hey, thank you very much for your help! of course, i'll do that as soon as possible!
<tyhicks> D_Cent: thanks!
<blackout24> Hi, is there any place where I can learn how the ubuntu-core system image is put togehter? I have been looking for a launchpad repo that has all the tools that are used, but could not find anything.
<asac> blackout24: so we use our official infra to do that which is not very nicely documented
<asac> nor available
<asac> blackout24: we use livecd-rootfs
<asac> afaik
<asac> sorry, didnt see any pings if there were any :)
<asac> slangasek: so i am in a armhf click chroot ... and i have libssl-dev:armhf installed and i have an autoconf/make project that doesnt find it without me giving very strong hints...
<asac> slangasek: isnt there some magic supposed to be that does all that for me? like setting CONFIG_SITE=/etc.. ?
<asac> this doesnt do anything for me ;/
<asac> i even ran autoreconf to ensure i ahve all the latest stuff
<asac> but nothing
<asac> ok guess i really have to set libdir manually
<asac> slangasek: figured it. ignore
#snappy 2015-04-25
<pitti> jdstrand: yes, I agree; /dev isn't a secret anyway, you can get that information from /sys too
<pitti> or listening to uevents (through the kernel)
#snappy 2015-04-26
<slangasek> asac: pull 3> I did back out image #3 from the 15.04/stable channel for armhf, yes
<slangasek> asac: asac as for the upgrade path, I'll certainly check this out asap
#snappy 2016-04-25
<edsiper> is Ubuntu core already released for the Dragonboard _
<edsiper> ?
<zyga> good morning
<shuduo> good morning.
<shuduo> is there any plan to have classic dimension back? ;)
<shuduo> should I expect snapcraft working in a chroot environment?
<zyga> shuduo: I'm sure classic will work though I'm not quite sure when
<zyga> shuduo: snapcraft and chroot, hmm, I heard that people had issues with kpartx
<zyga> shuduo: you might be able to snapcraft in a chroot but only construct the squashfs manually or on the outside
<shuduo> zyga: since no classic environment to build snap app for armhf target, i'm trying to run snapcraft in an armhf chroot. but got msg "Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path
<shuduo> " when i build examples
<zyga> shuduo: maybe try snapcraft from source, I don't know
<shuduo> zyga: yes, i just pulled it from github and build/install it in chroot.
<zyga> shuduo: you can also use launchpad to build snaps AFAIR but I haven't used this much
<shuduo> zyga: sorry never heard of that. how?
<zyga> I don't really know but from what I remember it's like a PPA
<zyga> just builds snaps
<shuduo> zyga: i looked at lp. seems only target amd64 and i386.
<zyga> ah, too bad
<dragly> Hi. I'm trying to package an app that is built using one of the newest versions of Qt (5.6 or 5.7). Because these are installed manually, I have written a plugin that copies all *.so libs and QML modules to the install folder. I was getting close to making this work when I encountered an annoying bug. After building and installing the snap 2-3 times, I
<dragly> always get the following error when running the app:
<dragly>  /bin/sh: 0: Can't open /snap/neuronify/100006/command-neuronify.wrapper
<dragly> It goes away if I rename the snap and build/install again. Have anyone here seen this before?
<zyga> dragly: yes, this is already (almost) fixed
<zyga> dragly: though I don't know if my fix will land or if it will need larger changes
<zyga> dragly: as a workaround, uninstall and install your snap each time
<dragly> Oh, okay. I can live with that workaround while developing. Thanks!
<dragly> That works. Now I just need to figure out how to get access to xkb working.
<dragly> Do you know if I might be missing some "plugs" when I get this error?
<dragly> xkbcommon: ERROR: failed to add default include path /usr/share/X11/xkb
<dragly> I already have "plugs: [unity7,opengl,x11,system-observe]"
<zyga> dragly: you can consult generated apparmor profile but I suspect that nothing grants x11/xkb access
<zyga> dragly: please open a bug with the details of your snap, I will be working on interfaces a lot this week,
<dragly> zyga: ok, du you prefer bugs on launchpad or github?
<zyga> dragly: I think we want launchpad
<qengho> What's wrong with this?
<qengho> echo -e 'name: xeyes\nversion: 1\ndescription: eyes\nsummary: toy\napps:\n snapxeyes:\n  command: usr/bin/xeyes\n  plugs: [ x11 ]\nparts:\n pkg:\n  plugin: nil\n  stage-packages: [ x11-apps ]' |tee snapcraft.yaml |cat -n
<qengho> Okay, ignoring a wrapper problem.
<qengho> $ /snap/bin/xeyes
<qengho> Bad system call
<zyga> qengho: try with --devmode
<zyga> qengho: (remove the snap and install it with --devmode)
<zyga> qengho: then observe syslog
<zyga> qengho: also check if the x11 plug is connected
<zyga> qengho: I had a few people report intersting bugs lately
<qengho> zyga: https://pastebin.canonical.com/155116/
<zyga> qengho: interesting, so you use encrypted home
<zyga> qengho: you have to add the home plug and connect this
<zyga> qengho: I'm not sure that it will suffice though
<zyga> qengho: but please report a bug that snappy won't work at all with encrypted home directory
<qengho> zyga: https://bugs.launchpad.net/snappy/+bug/1574526
<ubottu> Launchpad bug 1574526 in Snappy "snappy doesn't work with encrypted home directory" [Undecided,New]
<zyga> qengho: thank you
<zyga> qengho: can you snap install links
<zyga> qengho: and run links successfully?
<ara> qengho, I get the same dmesg, but the snap works fine
<ara> qengho, I got the bad system call the first time (interfaces were disconnected), but uninstalling the snap and installing it agian, solved the issue
<qengho> zyga: "links" snap works.
<zyga>  qengho, thanks
<zyga> so it's not encrypted home per se
<zyga> qengho: is your snap trying to access regular home directory?
<ara> qengho, if you try uninstalling the snap and reinstalling it, do you get the bad system call again?
 * zyga wonders if the encrypted-home option is available in the installer anywhere
<ara> zyga, you mean ubiquity?
<ara> zyga, it is
<zyga> ara: yes, I'm looking but all i see is encrypted /
<ara> zyga, wait until it asks for your username
<zyga> ara: ah, thanks
<ara> zyga, it will have a radio button to encrypt your home
<ara> qengho, was xeyes the first snap that you installed on your system?
<qengho> ara: not the first.
<qengho> $ sudo snap install ./xeyes_1_amd64.snap
<qengho> [-] Make snap "xeyes" available to the system
<qengho> $ /snap/bin/xeyes
<qengho> Bad system call
<qengho> cmiller@vetinari:/tmp$ sudo snap connect xeyes:x11 ubuntu-core:x11
<qengho> [|] Connect xeyes:x11 to ubuntu-core:x11
<qengho> cmiller@vetinari:/tmp$ /snap/bin/xeyes
<qengho> Bad system call
<zyga> qengho: and with devmode you get those messages about ~/.Private?
<zyga> qengho: currently we don't get notices about seccomp denials in --devmode
<ara> zyga, the .ecryptfs messages are always shown
<ara> zyga, even without --devmode
<ara> zyga, and even if the app works fine (like links)
<ara> zyga, for me, if I launch links successfully, I still get those messages
<zyga> odd
<zyga> thanks!
<qengho> Yes, "links" also causes four ecryptfs DENIED rw
<qengho> But no crash
<zyga> qengho: apparmor gives EPERM but seccomp gives you sigkill
<ara> zyga, I thought that was going to change
<zyga> ara: I don't think it did yet
<qengho> Okay, so it's not dependent on ecryptfs.
<zyga> ara: because seccomp needs kernel work
<qengho> Is it?
<qengho> Okay, so this bug is not dependent on ecryptfs?
<zyga> qengho: it seems it's not
<qengho> zyga: Your xeyes runs, then?
<zyga> qengho: I'm still setting up an env
<zyga> qengho: I'll try on my host
<zyga> qengho: xeyes doesn't run
<zyga> kwi 25 11:44:15 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1461577455.555:55): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=16555 comm="xeyes" exe="/snap/xeyes/100001/usr/bin/xeyes" sig=31 arch=c000003e syscall=51 compat=0 ip=0x7f3da9445df7 code=0x0
<zyga> that is getsockname
 * zyga looks at snappy source
<zyga> qengho: it doesn't work because x11 doesn't include that profile
<zyga> qengho: unity7 will work
<zyga> qengho: I just confirmed that it works with unity7 plug
<zyga> qengho: I've updated the bug
<zyga> with everything is a file/everything is over a socket, I find snappy interfaces related to networking rather limited
<qengho> zyga: With devmode, it runs with no crash. Same dmesg output.
<zyga> apparmor will need more work
<zyga> qengho: change to "plugs: [unity7]"
<zyga> qengho: then it works for me
 * qengho boggles.
<zyga> qengho: I've updated the bug
<qengho> *Should* it have unity7 as plug?
<zyga> qengho: no
<zyga> qengho: it's just a bug
<qengho> Okay, so I'm trying to figure out how to report it. "snappy's x11 plug doesn't work for 'getsockname' syscall"?
<zyga> qengho: I renamed the existing bug
<zyga> qengho: have a look
<qengho> zyga: ah, perfect. Thank you.
<qengho> zyga: I don't get that syscall=51 log message. Am I running stale software, or a different bug causes it to be missing?
<zyga> qengho: it's a bug
<zyga> qengho: that message says "getsockname is denied"
<zyga> qengho: it's a bug in snappy
<zyga> qengho: the message is obviously cryptic :/
<qengho> I was just worried about *silence*.
<qengho> Cryptic is fine. I've used linux since 1995. Cryptic, I got.
<zyga> I reported https://bugs.launchpad.net/snappy/+bug/1574556
<ubottu> Launchpad bug 1574556 in Snappy "apparmor denials reported for encryped HOME" [Undecided,New]
<zyga> qengho: FYI: https://github.com/ubuntu-core/snappy/pull/1069
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/1069
<dpm> hey all could someone ask this user on Ask Ubuntu? It seems their snappy system is locked due to errors (see the pastebin in the last comment) http://askubuntu.com/a/760782/9781
<dpm> sorry, not *ask, I meant help
<dpm> I'm just wondering what the way is to recover from those errors they see on the output of `snap changes`
<zyga> dpm: snap changes errors are harmless
<zyga> dpm: they are just a trace that something went wrong
<zyga> dpm: it seems that people still install using "$snap.$origin" (instead of just $snap)
<zyga> dpm: the error with revision 2 there seems interesting though
<dpm> zyga, thanks. Not sure, in that case, they're saying the install command was `sudo snap install ubuntu-clock-app`
<zyga> dpm: yes, that was the command that was tried next
<dpm> ah, I see what you mean now
<dpm> zyga, any ideas on what to recommend?
<zyga> dpm: I'm responding on askubuntu now
<dpm> awesome, thanks!
<qengho> zyga: what's the answer? How does he recover? I tried 'strace'ing once to find out.
<qengho> I think the strace didn't pass through launcher. I think.
<zyga> qengho: I don't know what his problem is yet
<zyga> qengho: I asked for additional information: http://askubuntu.com/a/762340/532607
<zyga> qengho: at the end of the day it should be possible to wipe snappy state entirely
<plars> zyga: not sure what josepht and popey were seeing, but even with your devtools script, I get a kernel oops on mount with xenial on my laptop, and on a trusty system I get this: failed to install "canonical-pc" from "edge": canonical-pc failed to install: [--root /tmp/diskimage700808732/system enable snap-canonical\x2dpc-5.mount] failed with exit status 0:
<zyga> plars: odd, I just tested this (including booting) on 0a58844b8b48b2c5d08154b44edd182287e6c589
<zyga> plars: seems like a bug in udf
<plars> zyga: is that the sha1 of your udf? That's not what I have
<popey> fails here too
 * popey replied with pastebin to the list
<plars> popey: do you get the oops also?
<popey> yes
<popey> http://paste.ubuntu.com/16046785/ is my dmesg
<popey> gah, that mount process is unkillable
<ogra_> sounds more like a kpartx bug
<zyga> plars: no, that's the head of devtools I'm on
<zyga> ouch [  588.493709] BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
<zyga> kernel bugz
<cjwatson> shuduo: LP, amd64/i386> No, that's not true.  amd64 and i386 are the default architectures, but you can use "Change details" on the snap to enable any architecture for which we have good virtualised sandboxing, so any of armhf/arm64/ppc64el.
 * ogra_ notes we have working yakkety image builds
<zyga> ogra_: snappy images? :)
<ogra_> zyga, sure
<zyga> ogra_: where are those published?
<ogra_> nowhere atm ... you'd have to grab the snaps yourself
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> (and i'm nt sure what we should do with these snaps ... we dont have a 16.10 channel in the store)
<ara> zyga, autopilot.service execs "/usr/bin/snap refresh", but that command expects a snap name (or fails if it doesn't have it)
<ara> zyga, known bug? or something missing?
<zyga> ara: known bug
<zyga> ara: (we knew about this before releae)
<ara> zyga, but something that it is going to be addressed at some point? shall I file a bug as reminder?
<zyga> ara: yes, certainly, we have a card for this, there's a bug as well somewhere AFAIR
<ara> zyga, can you point me to the card, please?
<zyga> ara: https://trello.com/c/l1EpwBoT/98-re-enable-auto-refreshing-autopilot
<zyga> ara: here you go :)
<ara> zyga, fantastic, thanks
 * zyga refreshed the fix for bug https://github.com/ubuntu-core/snappy/pull/1049
<kyrofa> Good morning
<kyrofa> mcphail, not sure if you got your question answered, but the ownCloud snap isn't compatible with the desktop just yet
<kyrofa> I hasn't been released for Snappy 16-- it's still using rolling
<ssweeny> niemeyer, zyga, so what are next steps for https://github.com/ubuntu-core/snappy/pull/1037 ?
<sergiusens> morning
<dpm> JamesTait, beuno, in the store, what's the difference between 'Make private' and 'Unpublish' for a snap?
<sergiusens> dragly in case our question hasn't been answered `export QT_XKB_CONFIG_ROOT=` to some path in your snap and maybe also stage-package xkb-data
<sergiusens> zyga ^
<JamesTait> dpm, "Make private" puts the package behind an ACL, whereas "Unpublish" removes it from the store.
<JamesTait> I suspect your next question might be "How do I set up an ACL?" and I think the answer is that you have to share the package, but it's a part of the UI I'm not familiar with.
<zyga> ssweeny: AFK, I'll reply in ~1 hour
<ssweeny> zyga, ack
<dpm> JamesTait, thanks. Actually, my next question was going to be... what's an ACL? :)
<JamesTait> dpm, Access Control List. ð
<dpm> oh, ok
<dpm> thanks
<JamesTait> dpm, so you might use it, for example, to allow members of your QA team to download a binary from the edge channel to test it before promoting it to stable.
<dpm> JamesTait, ok
<mcphail> kyrofa: thanks!
<dpm> nice one, thanks for the askubuntu answer on snap refresh ara!
<beuno> dpm, private snaps are only available to ~canonical, I think
<beuno> (atm)
<dragly> sergiusens: Thanks! I'll try that out.
<dholbach> sergiusens, kyrofa: when do we want to do the clinic?
<kyrofa> dholbach, I thought it was tomorrow?
<dholbach> did we say tomorrw at 15 UTC (the community Q&A slot)?
<dholbach> just wanted to double-check, so I can announce it now :)
<Unser> Hello, were do I get the builds for raspberry pi 3?
<kyrofa> dholbach, yeah we didn't set a time, but I think 15 UTC works fine
<dholbach> kyrofa, perfect
<dholbach> sergiusens, ^ does that work for you too?
<sergiusens> dholbach I guess; with our current state though I wish we could push it another week, not sure what kyrofa thinks about that :-P
<sergiusens> anytime is good tomorrow fwiw
<kyrofa> I don't mind pushing
<kyrofa> That's a good point actually
<dholbach> the week after is UOS
<dholbach> that's a good time for demos and stuff anyway
<kyrofa> dholbach, snappy 16 is not on ubuntu core yet-- weird situation
<dholbach> kyrofa, I'm not sure I understand
<zyga> ssweeny: I'll catch up with the conversation on that pull request now
<kyrofa> dholbach, unless things have changed since I used edge, snappy on the desktop and snappy on ubuntu core are different
<ssweeny> zyga, great, much appreciated :)
<dholbach> sergiusens, ^ what do you think?
<dholbach> do you think the week after things should be better?
<sergiusens> kyrofa we only care about snaps on the desktop/server though (for now)
<kyrofa> sergiusens, ah, okay good to know
<sergiusens> dholbach I am +1, let's see what olli| thinks
<kyrofa> sergiusens, what "state" were you referring to, then, regarding pushing?
 * olli| scrolls
<sergiusens> kyrofa producing a full fledged desktop snap
<sergiusens> not enough interfaces ready yet
<sergiusens> or known issues made known :-)
<kyrofa> sergiusens, ah, true. None of your attempts worked out either, huh?
<sergiusens> kyrofa not really; I will know more this after the group meeting
<ogra_> well, it could be a developer desktop ;) installed with --devmode
<kyrofa> ogra_, hahaha
<sergiusens> kyrofa but the fact that most apps use network manager to get info about connectivity status brings down a lot of options
<sergiusens> ogra_ hah
<zyga> ssweeny: so looking at this I think we want to implement the per-connection thing better, I'll fork this and give you a patch
<ssweeny> zyga, ok fair enough
<zyga> ssweeny: quick question, how do you test this?
<ssweeny> zyga, I do a smoke test in a vm with your devtools scripts then have someone with a snappy system w/ bluetooth hardware exercise it
<ssweeny> zyga, I use this snap btw https://code.launchpad.net/~ssweeny/+snap/bluez
<zyga> ssweeny: and the VM, I assume it doesn't have bluetooth, or does it?
<ssweeny> zyga, it doesn't, so I only test that bluetoothctl can connect to the daemon
<zyga> ok
<zyga> ah, right
<zyga> that's all I need, thanks!
<ssweeny> yw
<seb128> dpm, hey, is the store supposed to list things calculator? is it amd64 only or supposed to work on i386 as well?
<seb128> is there a snap status command or equivalent?
<popey> seb128: its an amd64 only build I believe
<seb128> k, that explains -:/
<seb128> :-/
<seb128> popey, thanks
<popey> despite it being qml only, it's got lots of binaries lobbed in to make it work
<dpm> seb128, the x86 build does not work for some reason
<seb128> I see you guys look down on us i386 users :p
<dpm> seb128, you mean *user? :P
<seb128> :-)
<dpm> :)
<seb128> k, next question
<seb128> $ sudo snap install hello-world
<seb128> error: can't install "hello-world": snap "ubuntu-core" has changes in progress
<seb128> how do I figure out what's going on?
<dpm> seb128, I actually did an x86 build, but gets a "Bad system call" message when executed on an x86 machine
<seb128> there is no status command?
<dpm> seb128, `snap changes` perhaps
<dpm> and then `snap changes $CHANGEID` to zoom in
<seb128> thanks
<josepht> I'm having checksum mismatches when I build a snap on my rpi2 and try to upload it to the store.  I'm building in a chroot on the device itself.
<popey> seb128: when I had the "changes in progress" issue, the only resolution I had was to nuke my snappy config (and apps) from orbit :(
<seb128> popey, where do those live?
<popey> so i had to stop the snapd service, umount /snap/*/* and rm all of /var/lib/snapd/* iirc
<popey> then reinstall snapd and snap install ubuntu-core
<josepht> seb128: reset-state from here should do it.  https://github.com/zyga/devtools
<popey> it "fixed" it for me
<popey> ooh, we even scripted it!
<seb128> josepht, popey, thanks
<josepht> seb128: my pleasure
<olli|> sergiusens, let's chat in the team mtg
<zyga> ssweeny: hey, this is a totally crude attempt at this
<zyga> ssweeny: I'll build the snap next but I wanted to show you https://github.com/zyga/snappy/commits/bluez-fix-rules
<zyga> ssweeny: one thing I could do is to look at all the apps in the slot
<zyga> ssweeny: and let the sender (with the plug) talk to each of those apps specifically
<zyga> ssweeny: I'm not sure we want that though
<zyga> jdstrand: hey, are you around?
<dragly> Is there a way to set LD_LIBRARY_PATH, or do I need to run a script that does this before executing a C++ executable?
<zyga> dragly: AFAIR we set something, let me check
<ogra_> the launcher does that automatically for a bunch of dirs ...
<zyga> dragly: what do you need specifically?
<ogra_> (just make sure your libs are in the right location inside the snap)
<dragly> I'm trying to set the QT_XKB_CONFIG_ROOT you mentioned, which made me set up a script that does this first
<dragly> this however, required me to set LD_LIBRARY_PATH, and now I get "Could not initialize GLX", which lead me to believe that I might have set something the wrong way that shadows the OpenGL libs.
<zyga> dragly: opengl stuff is handled separately
<zyga> one sec
<ogra_> well, just make sure to always keep the existing LD_LIBRABRY_PATH if you actually append anything to it
<zyga> dragly: we set SNAP_LIBRARY_PATH
<zyga> to /var/lib/snapd/lib/gl:
<zyga> looking what picks that up
<zyga> the launcher is not
<zyga> I guess you want your wrapper
<dragly> I just need to set the QT_XKB_CONFIG env variable, so any way that enables me to do that without breaking OpenGL is what I need
<dragly> seems like setting LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP_LIBRARY_PATH didn't help
<dragly> I must have messed up something else
<dragly> is there a way to set env variables in the yaml?
<zyga> nope
<dragly> is launching the app like this in my wrapper the right way to do it?
<dragly> $SNAP/bin/neuronify
<zyga> yep
<zyga> that will work
 * zyga finished meeting and returns to bluez interface and snap
<josepht> sergiusens: are you able to build snaps with snapcraft on rpi2 and successfully upload to the store?
<shuduo> cjwatson: let me try. thanks!
<sergiusens> josepht what are you seeing? my rpi2 has been in the closet for a while; kyrofa has been playing with one though
<sergiusens> josepht just in case you are missig the snap registration added last week (you need to go to the store and register the name yourself)
<josepht> sergiusens: the snap fails to upload due to a checksum mismatch.  I have registered the name.
<sergiusens> dragly $SNAP/bin is in PATH so just `command: neuronify` should be enough
<sergiusens> josepht oh; don't know about that; the store guys wrote the upload code for us; so not deeply familiar with it; I'll check or maybe be lazy and ask vila
<dragly> sergiusens: Thanks. Still getting the same error about it being unable to initialize GLX. I think it comes from Qt, but I don't know what its missing.
<dragly> sergiusens: Adding the QT_XKB_CONFIG_ROOT helped me get a step further, though.
<josepht> sergiusens: I don't think it's related to the store though.  I checked the last time I uploaded an rpi2 snap and I get a different checksum if I unsquashfs and resquashfs the snap using the commands from the snapcraft source (at the time)
<dragly> Are there any OpenGL packages I should consider adding to stage-packages?
<zyga> dragly: I don't think you should
<sergiusens> dragly that I don't know, not a GUI person myself; I will fwd you to kgunn for the GLX question
<kyrofa> josepht, sergiusens sorry guys, my rpi2 snap takes an entire day to build on the rpi so I started using the LP builders and uploading directly to myapps
<sergiusens> kyrofa smart ;-)
<vila> josepht: the upload doesn't (and won't) upload the checksum but I think the store checksums the /file/, not its content, but rebuilding the squashfs may change the resulting file
<kyrofa> josepht, fails to upload, or fails review?
<josepht> kyrofa: fails review
<kgunn> dragly: sorry, can you briefly explain what you're up to? i presume building a qml app snap to  run on 16.04 desktop?
<dragly> kgunn: I suppose I'm pushing the limits here. I'm building an app with Qt5.7 (we need QtCharts) and trying to pack it with snapcraft.
<dragly> I have made a custom plugin that copies all QML modules and Qt libs to the install folder.
<kgunn> dragly: hmm...are you digging into our example here as a guide/for instance?
<kgunn> http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/ubuntu-clock-app/
<dragly> So far so good, I've gotten all errors about missing platforms, QML modules and libraries to go away, but now I'm stuck with the error "Could not initialize GLX".
<kgunn> you can see the clock.wrapper has all the env set
<kgunn> dragly: so, accessing gl drivers provided by the host system in ubuntu-core is a very new feature...
<dragly> nice, I'll have a look at it and see if I can add anything I'm missing. Thanks!
<kgunn> so if you'd be willing to share all your work, it's possible you're just hitting a bug or unforeseen iss
<kgunn> dragly: yep, try to look at the example first...
<kgunn> if you think you've got it...and still hitting it, then file a bug on ubuntu-core with your work
<kgunn> thanks for being an early adopter
<zyga> tyhicks: hey, have you seen jamie today?
<kyrofa> zyga, I believe he's out today
<zyga> ah
<zyga> thanks
<tyhicks> zyga: hey - he'll be back tomorrow
<zyga> tyhicks: do you have time for a quick apparmor question?
<tyhicks> zyga: sure
<zyga> tyhicks: is it safe/okay to use #include statements inside a particular profile?
<zyga> tyhicks: normally we include bits earlier
<zyga> tyhicks: but one interface we're working on now does that per plug connection
<tyhicks> zyga: are you asking if the #include has to happen at the top of the profile?
<zyga> yep
<tyhicks> zyga: #include's can go anywhere
<zyga> ah, thanks!
<tyhicks> no problem
<tyhicks> zyga: the parser simply inserts the contents of the #included file right where the #include is found so you'll be fine as long as the inserted contents do not cause a compiler error
<josepht> kyrofa: how do I use the LP builders to build my snap?
<kyrofa> josepht, it's actually pretty easy. First of all, you need to have an LP project, and push your code there
<kyrofa> josepht, are you hosting your code there already, or elsewhere?
<josepht> kyrofa: nowhere yet :)
<kyrofa> josepht, ah!
<josepht> kyrofa: I'll setup a project and push my code there
<kyrofa> josepht, yeah, create an LP project and either use bzr or git to get your code up there. Once you have that, come back and I'll continue walking you through :)
<sergiusens> kyrofa josepht should even work from +junk
<josepht> sergiusens, kyrofa: the builder uses 'architectures' from snapcraft.yaml?
<cjwatson> josepht: not yet
<josepht> okay
<josepht> kyrofa: I've got my project pushed
<cjwatson> josepht: https://bugs.launchpad.net/snapcraft/+bug/1533713
<ubottu> Launchpad bug 1533713 in Snapcraft "Add metadata describing the architectures that a snap can be built for" [Wishlist,Triaged]
<kyrofa> josepht, click on the branch you pushed
<cjwatson> josepht: (i.e. currently that field does not appear to have the semantics we need)
<kyrofa> josepht, and one of the options should be to "Creat a snap package"
<kyrofa> with an e in there somewhere
<josepht> kyrofa: check
<cjwatson> kyrofa: as sergiusens says, you really don't need a full project, and a full project is likely inappropriate in most cases
<kyrofa> cjwatson, sergiusens alright thanks :)
<sergiusens> cjwatson https://lists.ubuntu.com/archives/snappy-app-devel/2016-April/000654.html in case you have an opinion; sorry I forgot to link that to the bug
<cjwatson> I mean, not a project just for the snap stuff.  If there's an existing upstream project for the thing you're packaging then it would normally make sense to put the branch in there
<kyrofa> josepht, so you have a snap, but I believe by default it'll only build for x86 and amd64
<kyrofa> josepht, so select the snap package, and go to "Edit snap package"
<kyrofa> josepht, select the archs you want
<cjwatson> sergiusens: can't say I really care about the exact name :)
<sergiusens> cjwatson ok; I was planning on fixing it last week but chasing  the snapd story consumed most of our time
<kyrofa> josepht, then you should be able to hit "Request builds" on the snap package
<cjwatson> sergiusens: sure; likewise probably won't get round to the LP side of it for a little bit, need to focus on the auto-upload-to-store story
<cjwatson> sergiusens: but it would at least make it possible :)
<kyrofa> cjwatson, what are the limitations on the snap name? Do they need to be unique? Unique to the project? Unique to the user?
<josepht> kyrofa: ack.  My branch will need to have the source in it as well.  i.e. it can't pull from github.com?
<oparoz> What's the easiest way to add a path to the Snap's LD_LIBRARY_PATH from Snapcraft?
<kyrofa> josepht, ah, indeed. I host on github as well, but push to LP for building. Anything beyond that (auto-sync or whatever) is a question for cjwatson probably
<kyrofa> oparoz, write a wrapper
<josepht> pwd
<josepht> :)
<cjwatson> kyrofa: unique to the user
<oparoz> kyrofa, It's already in a wrapper since it's in an init script, but I don't want to have to deal with the various paths used by various architectures
<oparoz> kyrofa, so wondering if that path could be "built" while creating the snap
<cjwatson> kyrofa: usual naming constraints for names of things on LP, basically alphanumeric plus [+.-], with the first character alphanumeric only
<cjwatson> josepht: git-to-git imports are on the near-term plan; in the meantime, just mirror stuff to LP manually
<kyrofa> cjwatson, can multiple branches be associated with the same snap?
<josepht> cjwatson: ack, thanks
<cjwatson> josepht: but I think both kyrofa and I misunderstood your question slightly
<cjwatson> josepht: only the snapcraft.yaml needs to be in a branch hosted on LP; the rest can be pulled from github or wherever
<josepht> cjwatson: oh! hrm, my amd64 build failed to clone the nmap repo from github
<kyrofa> cjwatson, ah, good catch. josepht I assumed the repo you were referring to WAS the snapcraft.yaml
<cjwatson> kyrofa: snapcraft.yaml can reference whatever it likes.  the only thing LP knows about directly is the branch that contains snapcraft.yaml, and it only makes sense for there to be one of those
<cjwatson> josepht: URL?
<josepht> cjwatson: https://launchpadlibrarian.net/256016424/buildlog_snap_ubuntu_xenial_amd64_nmap_BUILDING.txt.gz
<kyrofa> cjwatson, I was more thinking for a little CI infrastructure around a snap being creating by multiple devs collaborating. I actually have PRs and stuff coming in for the owncloud snap, and I'd like to get snaps automatically building. Those are multiple branches
<kyrofa> oparoz, you could make use of the SNAP_ARCH variable, or you could add it to a local plugin (or just a part with a Makefile) to generate it at build time
<cjwatson> josepht: could you give me the URL that contains /+build/ instead?
<kyrofa> The part with a Makefile would probably be easier
<cjwatson> kyrofa: no, that doesn't exist.  you could fairly easily just create the necessary snap objects on the fly though.
<kyrofa> cjwatson, just name then randomly, essentially?
<kyrofa> cjwatson, or delete when done?
<cjwatson> kyrofa: either
<kyrofa> cjwatson, sounds good
<oparoz> Thanks kyrofa. I'll give it a try. I'm currently using a nil plugin since it's just adding a deb
<kyrofa> cjwatson, and I just noticed the web hooks there as well
<josepht> cjwatson: https://code.launchpad.net/~joetalbott/+snap/nmap/+build/777
<kyrofa> cjwatson, how long to the built snaps live before they're removed?
<cjwatson> josepht: only http/https is proxied; you need to use https:// rather than git://
<josepht> cjwatson: ah, thanks
<cjwatson> kyrofa: there's actually no pruning right now, but there should be; expect no more than a couple of days
<kyrofa> cjwatson, yeah that seems reasonable
<sborovkov> Hi. I see this variable - "SNAP_USER_DATA=/root/snap/screenly-client/100001" -> Is this basically home directory for the snap?
<kyrofa> sborovkov, a similar question was recently asked here: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
<josepht> kyrofa: thanks a bunch for helping me
<josepht> cjwatson: thank you for helping as well
<cjwatson> np
<kyrofa> josepht, hey any time. Thanks to cjwatson for putting it all in place!
<sborovkov> kyrofa: cool, that's what I was interested in, thanks
<cjwatson> kyrofa: (but we'll probably try to get auto-upload to the store working before we start pruning; there aren't so many snaps at the moment so we should be able to get away with that)
<kyrofa> cjwatson, good to know, but I'll make sure I don't rely on it :)
<kyrofa> Hey ogra_ I'm curious what magic you go through to create OS snaps. I don't suppose that's documented anywhere?
<ogra_> kyrofa, livecd-rootfs/live-build builds a normal rootfs like you'd do for any other image ... at the point where that gets usually tarred up we intercept and create a snap meta dir and call snapcraft snap
<dpm> wow, really nice answer kyrofa, thanks! -> http://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
<kyrofa> ogra_, oh that's pretty easy, okay
<kyrofa> dpm any time!
<ogra_> kyrofa, line 322-346 http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build#L322 is the code we actually use to snap it up
<kyrofa> ogra_, excellent, thank you!
<ogra_> if you want to set up your own build env, perhaps take a look at project-rootstock-ng (rather outdated, but the principle didnt change)
<dpm> JamesTait, beuno, what exactly can I use the share link in a snap for? Which kind of access does it grant in the store to the people I send it to?
<kyrofa> ogra_, isn't rootstock deprecated though? (https://wiki.ubuntu.com/ARM/RootStock) why use that instead of live-build?
<ogra_> kyrofa, -ng ... it is deprecated, but -ng is a wrapper around live-build
<kyrofa> ogra_, ahh
<ogra_> just so you get an impression how your build chroot should be set up
<ogra_> (and the env around it)
<kyrofa> ogra_, gotcha, exactly what I was looking for, thank you :)
<JamesTait> dpm, I'm not actually completely sure.  IIRC, it gives you permission to download the package from a device, so in that respect it's similar to having store reviewer permissions. I think it also gives you permission to manage the package through the web UI, as if it were your own.
<dpm> JamesTait, ah, the latter is the bit I'm interested in, so I guess it's a way to have a team manage package uploads and editing metadata, right?
<JamesTait> e.g. I have a snap package that someone shared with me, and I can upload a new revision, unpublish, make it private, and edit at least some of the metadata.
<JamesTait> Exactly. âº
<dpm> ah, great, exactly what I was looking for :)
<oparoz> Is it Snapcraft or the store which signs snaps?
<kyrofa> oparoz, the store
<oparoz> Thanks kyrofa
<wililupy> Do any of you know of a way to actually see the package contents of a .snap?
<oparoz> unsquashfs
<wililupy> I didn't think of that. I'm trying to see why my kernel.snap says there is no kernel and yet is 74MB.
<ogra_> All modules ? ;)
<sergiusens> oparoz you will eventually be able to sign snaps as well
<oparoz> Is there a helper in snappy which writes users to extrausers or do we need to echo users to those files?
<oparoz> Thanks sergiusens
<sergiusens> oparoz iirc adduser worked
<sergiusens> ogra_ didn't I add a flag to write to extrausers, or maybe you did?
<oparoz> sergiusens, it might be because I'm using an older version of core, but it fails
<oparoz> groupadd: cannot lock /etc/group; try again later.
<sergiusens> kyrofa one step further with electron; although nodejs is hurting my brain!
<kyrofa> sergiusens, haha, I believe it!
<ogra_> oparoz, yu need the --extrausers arg for adduser
<ogra_> oparoz, though why would you even add users there at all ? your snap should surely not use the system password db
<oparoz> ogra_, without adding any other flags, it still fails with: /usr/bin/chfn: unrecognized option '--extrausers'
<oparoz> ogra_, but you're right, I may not need extra users. I'm testing things. It's for a Samba server
<ogra_> you can ignore that bit (there is a bug open for it i need to SRU)
<ogra_> (the chfn)
<oparoz> ogra_, thanks for the heads up about the bug
<kyrofa> sergiusens, elopio I totally lost track of time
<sergiusens> kyrofa oh, me too, no worries; let's skip and keep on rolling desktop snaps
<kyrofa> sergiusens, whew, okay sounds good
<sergiusens> kyrofa any luck on your side?
<edsiper> is Ubuntu core already released for the Dragonboard _
<edsiper> ?
<kyrofa> sergiusens, no. I finished fleshing out the indicators/notifications bug, now I'm hunting for another qt example to snap
<kyrofa> sergiusens, I'm gonna go with the simple text editor. That shouldn't require any special interfaces
<kyrofa> sergiusens, have you messed with .desktop files yet?
<wililupy> I'm trying to clean-cache with the latest u-d-f and it keeps keeps saying unknown command. How do I clear the cache to get the latest builds?
<ogra_> look under ~/.cache
<wililupy> orgra_ any specific directory? There are 2 .fr-* directories with data.tar.xz, is that it?
<kyrofa> zyga, is there any documentation about using .desktop files in meta/gui ?
<zyga> kyrofa: not that I know of
<zyga> kyrofa: I can tell you how it works
<zyga> kyrofa: and how to use it
<kyrofa> zyga, please do :)
<zyga> kyrofa: but I don't think it's written down anywhere
<zyga> kyrofa: desktop files from meta/gui are parsed, sanitized and placed in /var/lib/snapd/desktop
<zyga> kyrofa: ${SNAP} is expanded (exactly ${SNAP}, nothing else) to point to the snap install/mound directory
<zyga> kyrofa: the icon needs to refer to ${SNAP}/something (e.g. ${SNAP}/meta/gui/icon.png) to work
<zyga> kyrofa: that's all I remember
<kyrofa> zyga, when you say "sanitized" I assume that means there are limitations to what I can put in there?
<zyga> you can put anything, we just filter out some things
<zyga> and "allow" only certain things that are safe
<zyga> e.g. no TryExec
<zyga> it's pretty crude but the idea is that untrusted .destkop files are okay
<kyrofa> Alright, thanks :)
<sergiusens> kyrofa desktop files, just drop them in `setup/gui/<app>.desktop`
<kyrofa> sergiusens, yeah, I was just curious about the parsing/sanitization
<kyrofa> zyga, does the home interface not automatically connect?
<ogra_> no
<kyrofa> ogra_, is that a bug or is there a reason for that?
<sergiusens> kyrofa on purpose
<ogra_> security ;)
<kyrofa> Huh. I wish `snap install` would have told me :P
<ogra_> we can key-log all your Xorg keystrokes, but cant store them in your home dir ;)
<zyga> kyrofa: no, it's super dangerous as you can steal almost all user data
<kyrofa> zyga, and X isn't?
<zyga> kyrofa: that's on a TODO list, we just basically had no way to do it lately
<kyrofa> ogra_, yeah exactly, haha
<ogra_> shhh
<zyga> kyrofa: X is bad but then most apps don't work without X
<zyga> kyrofa: but most apps *can* work without your real HOME
<kyrofa> zyga, nah, I understand. Just caught me by surprise
<kyrofa> sergiusens, alright, first (relative) success: https://github.com/kyrofa/qt-example-snaps/tree/master/application
<kyrofa> zyga, is there a way to access the webcam via interfaces?
<zyga> kyrofa: no, not today
<zyga> kyrofa: we need hooks to make that sane
<kyrofa> zyga, alright
<zyga> kyrofa: as those are typically dynamic objects
<kyrofa> zyga, right yeah, all that hw-assign stuff is
<zyga> kyrofa: having said that, I was working on the pi2 camera iface a while ago
<zyga> kyrofa: the interface itself wasn't hart, what was the problem at the time was lack of proper firmware and shared libs in the base image
<zyga> kyrofa: I'm sure the next few weeks will see a rapid evolution of interfaces
<kyrofa> zyga, rapid evolution + SRU = ? :P
<sergiusens> kyrofa does it look good? is it in the store already? :-)
<kyrofa> sergiusens, no, should I put it in the store? And yeah, it's not bad
<sergiusens> kyrofa is it all your code or some upstream project?
<kyrofa> sergiusens, upstream
<kyrofa> sergiusens, they're qt examples
<sergiusens> ah
<sergiusens> kyrofa maybe get a gtk example in next ;-)
<kyrofa> sergiusens, alright I've got one more qt one, then gtk
<sergiusens> kyrofa heh, will and seb might take on gtk
<Domi> Hello, where do I get the images for raspberry pi 3?
<kallisti5> ...  is not of type 'object'
<kallisti5> I don't get it.. I pretty much get that from snapcraft for everything
<kyrofa> kallisti5, sounds like your YAML isn't right
<kyrofa> kallisti5, want to put it in http://pastebin.ubuntu.com/ ?
<kallisti5> http://pastebin.ubuntu.com/16055433/
<kallisti5> err.. ignore r1scsi there... that should read "thing"
<josepht> kallisti5: it looks like you're missing 'command:" in your app
<kallisti5> heyyy
<kallisti5> that did it
<kyrofa> kallisti5, yeah that was just invalid YAML
<dragly> when running "snapcraft", is it possible to specify that a part with "plugin: copy" should rerun (i.e. clean and then copy the files again)
<dragly> cloning and building the rest of the project takes some time
<kyrofa> dragly, yes, you can give snapcraft specific parts
<kyrofa> dragly, e.g. snapcraft stage part1
<kyrofa> dragly, you also don't need to clean completely
<kyrofa> dragly, try cleaning only back to the build step: snapcraft clean -s build
<kyrofa> dragly, or cleaning only part1 back to the build step: snapcraft clean part1 -s build
<dragly> thanks!
<dragly> is it possible to "chroot" into the snap to inspect the environment somehow?
<dragly> kgunn: Thanks for showing me the example. I got a bit further now, but both with the example and my own package I get the following error:
<dragly> libGL error: No matching fbConfigs or visuals found
<kgunn> dragly: interesting, so if you build and sideload the example snap that occurs?
<dragly> sorry, I don't know what sideload means
<kgunn> dragly: sideload==you build it locally and did sudo snap install mylocallybuild.snap
<kgunn> vs download/install from the snap store
<dragly> yes
<kgunn> oh ok, this is weird then
<dragly> sudo snap install ubuntu-clock-app_3.6+snap2_amd64.snap; ubuntu-clock-app.clock
<kgunn> i wouldn't have expected that
<dragly> I have Nvidia drivers on my host system, if that matters
<kgunn> dragly: it shouldn't...but possibly
<kgunn> dragly: do you have a hybrid gpu system?
<dragly> not on this machine, no
<kgunn> like 2 gpus and drivers available at the same time ?
 * kgunn thinks for a moment
<kgunn> dragly: on your machine do you have something like /usr/lib/nvidia-<xxx>
<kgunn> containing the nvidia drivers?
<dragly> here are some findings, if they help:  /var/lib/snapd/lib/gl/ is empty on the host, /usr/lib/nvidia-361 exists on the host and has a libGL.so, but in the snap I only find libGL.so in ./usr/lib/x86.../mesa
<dragly> looking at the older snaps I had for my own project, I see they copied nvidia-361 to ./usr/lib
<kgunn> dragly: right, the idea implemeted was to permit the snap to leverage the libgl from the host system, rather than copy in...
<dragly> this however stopped at some point (I realize now I should have used version control while working on this too)
<kgunn> b/c otherwise you're stuck to that gpu/impl
<dragly> that makes sense
<kgunn> dragly: but like i say that was a very recent addition
<kgunn> of a feature to ubuntu-core/snapd etc
<dragly> I'm using snapcraft as installed with "sudo apt install" by the way
<dragly> version 2.8.4
<kgunn> dragly: i think that's fine...
<kgunn> dragly: this is more about not being able to find the drivers at run
<kgunn> dragly: interesting...someone else seemed to have a very similar prob last week
<kgunn> http://askubuntu.com/questions/759647/opengl-error-in-snaps-ubuntu-16-04/760096#760096
<kgunn> so i'm wondering if there's just a niggly nvidia symbolic link issue going on
<kgunn> what else is /usr/lib/nvidia-361 have inside?
<dragly> seems reasonable, considering other's findings like here: https://askubuntu.com/questions/541343/problems-with-libgl-fbconfigs-swrast-through-each-update
<kgunn> dragly: :-/ bummer...but wonder if some sort of reinstall of those drivers might help?
<kgunn> i don't have nvidia myself...i've asked someone in another channel, just to give it a go
<dragly> http://pastebin.com/ABU2THVw
<kgunn> i do know one of the snappy team guys tried the feature out building on intel/run on nvidia then vice/versa...and the feature worked...
<dragly> I'll try reinstalling and doing a quick reboot
<dragly> I can also try it on a machine with intel, just give me a couple of minutes
<kgunn> dragly: hey, when did you start trying snapcraft and ubuntu-core on desktop?
<kgunn> reason i ask, is at one point i ran into problems with an update...
<kgunn> and  i did have to reinstall...but if you've only started in the last week or so...may be a red herring
<kgunn> but at one point i had to run a script like this
<kgunn> https://pastebin.canonical.com/155170/
<kgunn> and then reinstall ubuntu-snappy-cli and ubuntu -core etc
<kgunn> fwiw
<dragly> I started yesterday
<dragly> cannot access the pastebin
<dragly> but I can try reinstalling those
<dragly> moving the clock .snap to a laptop with intel produces the following error:
<kgunn> dragly: sorry bout that
<kgunn> http://pastebin.com/68FTk1gv
<dragly> QXcbConnection: Could not connect to display :0
<dragly> building and running on Intel laptop works
<dragly> That is, it has Nvidia Prime, but I've disabled Nvidia and running only on Intel now.
<dragly> I'll try moving it to the other machine.
<dragly> same error, I'll try the script you sent now
<kgunn> dragly: sorry, confused...so you did have success running on intel?
<dragly> yes, building and running the clock example on intel works
<dragly> building on intel, running on nvidia doesn't work
<dragly> building on nvidia, running on either doesn't work
<wililupy> I have a custom kernel snap and I build my image using u-d-f, and when I install it to my device and try to boot up, I get the following error: http://pastebin.ubuntu.com/16056244/ and it goes back to the grub menu.
<wililupy> system will boot when using the stock snappy image, but I need custom modules so I build my kernel snap and it builds successfully, everything looks good in the .snap file, but I can't boot the device. Any pointers?
<dragly> kgunn: After running the script and reinstalling snapd and snapcraft (should I have reinstalled others?), installing the package built on intel and running it on nvidia gives the QXcbConnection error (not seen on that machine before)
<dragly> and, the same happens if I run the script once again and build the whole example from scratch. So still having some issues, but the error message changed.
<pedronis> dragly: does the snap asks for unity7 and x11 plugs?
<kgunn> pedronis: he's using the clock example i think
<dragly> yes, it's the clock example. "plugs: [unity7,opengl]"
<dragly> really strange, reinstalling the snap on the nvidia system (no rebuild) gives the previous "libGL error: No matching fbConfigs or visuals found"
<dragly> I don't see how the reinstall changes anything
<pedronis> mmh, this sounds more like the issue of security not being regenerated on updates
<dragly> I'll diff the folders...
<pedronis> (we are working on it)
<kgunn> dragly: confirmed with another guy who has nvidia...he's seeing your libgl err
<dragly> kgunn: ok, thanks
<kgunn> so i think this might be a bug, we'll need to work with mvo on it tomorrow
<pedronis> yes, that one seems a genuine different problem
<pedronis> (the cannot access display more the security not setup on update one instead)
<dragly> kgunn: Great. Let me know if I can help. I really like this project and would love to see it succeed.
<sergiusens> kyrofa elopio telegram seems busted here, I get notifications but can't see messages
<dragly> pedronis: Ok, thanks for letting me know. I'll keep that in mind when I see the error next time.
<dragly> Is there a way to specify where snapcraft outputs the folders like "parts", "stage" and so on?
<wililupy> I feel like I'm missing a module from my kernel config for loop in my snapcraft.yaml for the kernel_initrd_modules...
<ogra_> wililupy, heh, no, that wouldnt help you with grub :)
<ogra_> wililupy, you want loop support builtin
<ogra_> if grub fails with a "cant find loop" error you are far before the initrd in your boot process
<wililupy> ogra_ the funny thing is that I created an image using u-d-f with all the defaults, and it works, but when I change the --kernel=my-kernel.snap, it doesn't boot up.
<ogra_> did you use snapcraft to create the kernel snap ??
<wililupy> ogra_ yes.
<ogra_> well, then the snap structure should be ok i guess
<wililupy> ogra_ I verified it by unsquashfs and everything looks good.
<zerwas> On Ubuntu 16.04 Desktop (upgraded from 15.10), the snap command does not work for me. It immediately exits with: "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps?q=test&sources=store: dial unix /run/snapd.socket: connect: no such file or directory". What might cause this?
<zerwas> I just realized it might have to do with me still using upstart instead of systemd.
<ogra_> uuuh
<Domi> Hello, i get the error "Unable to locate package snappy-tools" what is wrong?
<zerwas> Domi: Do you need a package called snappy-tools?
<Domi> yes I want to create a .snap with snapcraft
<Domi> In the documentaion is written that I just have to "sudo apt install snappy-tools"
<Domi> https://developer.ubuntu.com/en/snappy/build-apps/get-started/
<oparoz> Domi, what happens if you jhust try to apt install snapcraft?
<Domi> i think i need the other tools too. Do you use Snappy ?
<oparoz> Domi, yes, I use Snapcraft
<Domi> how did you install it?
<oparoz> The link you gave me has either just been updated or is telling me to install snapcraft
<oparoz> The old documentation required snappy-tools
<oparoz> Domi: I followed this guide: https://github.com/owncloud/ubuntu-snap/wiki/Building-your-first-snap
<oparoz> But that's to build snaps from within Snappy
<Domi> did you install snapcraft on ubuntu core or on a deskop version of ubuntu?
<oparoz> Domi on core
<Domi> oh ok. I thought it would be possible to pack the snap on my normal deskop machine and then upload it to core
<Domi> because it says "Once your Ubuntu host system is up and running, you can then install the snappy-tools package, which will in turn install the optimal selection of Snappy development software to your system."
<oparoz> Domi, yes, it should be possible, but I haven't tried yet and if I'm not mistaken, core is a bit behind and unstable, so you may run into some surprises
<Domi> ok I just want so python core running and use the GPIOs of the raspberry pi.
<oparoz> whereas if you develop in a VM using core, you should be able to test things right away
<oparoz> I use an amd64 vm for bigger stuff and develop straight on the Pi for lighter stuff
<oparoz> It works pretty well, thanks to the launchpad builders
<Domi> launchpad builders?
<oparoz> If you push your git code to launchpad, you can ask LP to build snaps for various architectures
<Domi> ok, but it is not possible to use any IDE on core or?
<oparoz> What I do is push files from my workstation to the core VM, so I can use any desktop IDE I want
<oparoz> It's probably possible to launch an IDE from core, if you can find one
<Domi> so you write your code on the workstation and than move it to core. On core you make a .snap and than you install the .snap
<oparoz> That reminds me that I'm able to use snapcraft on core because I still have classic mode, but that's been removed...
<oparoz> There is one piece of the puzzle I'm missing. If I wanted to build from the desktop, how do I make sure I target core and not the desktop...
<oparoz> Because if the latest images of snappy don't have classic mode, I don't know how you're going to build a snap
<Domi> ok without classic mode there is no way to build the snap on core. Should I ask tomorrow someone on how to install snapcraft on desktop?
<oparoz> Installing Snapcraft is not the problem
<oparoz> just apt install
<oparoz> but the documentation goes from install snapcraft to "your first snap"
<Domi> no the documentation says install snappy-tools which is not available in apt
<oparoz> No, that's the old documentation
<oparoz> https://developer.ubuntu.com/en/snappy/build-apps/get-started/
<oparoz> $ sudo apt install snapcraft
<oparoz> That's the doc for 16.04
<Domi> ok thank you, i read https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md which is for 16.04 too. very  confusing
<Domi> I will follow this guide tomorrow. Thank you for your greate help
<oparoz> You're welcome
#snappy 2016-04-26
<oparoz> I have a question regarding: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<oparoz> It says that the snap will only work on Core, so how do we pick a target since snaps can also be created for the desktop?
<davidcalle> oparoz: actually, the snappy is running on core on the desktop, so yes, it should work as long as the snap targets the right arch
<davidcalle> s/the snappy/the snap :)
<oparoz> Thanks davidcalle, so it's just a problem with the doc then. I can install snapcraft on a desktop, create a multi-arch snap and deploy on desktop,server and core without any issue as long as they all use the same Snappy engine (16.04)
<zyga_> good morning
<oparoz> Do we report doc problems on LP, in the Snapcraft project?
<davidcalle> oparoz: yes, snapcraft doc is being updated to match the latest state of things. Examples in here (https://developer.ubuntu.com/en/desktop/) are the most recent (less detailled, though).
<davidcalle> oparoz: snapcraft project, yes. https://bugs.launchpad.net/snapcraft
<oparoz> Thank you davidcalle
<davidcalle> yw
<slvn> hello ... a few questions : 1) I have a few .click (arm, native binary) package for ubuntu phones, does it make sense to upgrade to snappy package ?
<zyga> slvn: what kind of app is that?
<zyga> slvn: I guess right now the answer is "if that snap would run on desktops"
<slvn> zyga, games based on libSDL2
<zyga> slvn: sure, you can target the desktop with your snap
<slvn> the games could also run on desktop, provided I compiled them for desktop
<zyga> slvn: and inevitably the phone will adopt snaps at some point so you will already know how things work there
<slvn> also I tried to install my .click package on my destkop and it refused to be installed (cannot be install on X ...)
<slvn> so I should look how to provide a snap package that contains both arm and x86 libs for arm and desktop
<slvn> Will snapy packages run *confined* like .click on phones ?
<davidcalle> slvn: to some extent, yes. Eg. snaps on the desktop can be granted access to $HOME
<davidcalle> slvn: note that the phone switch to snap will take time.
<slvn> davidcalle, zyga, thanks for the answers, I will have a look on snapy !
<seb128> is there an "apt-cache show" equivalent in the snap world?
<seb128> snap list lists names, but that's not very useful to figure out what the snaps are exactly
<zyga> seb128: I don't think there is one
<seb128> :-/
<zyga> seb128: as a hack, you can look at /snap/$name/current/meta/snap.yaml
<zyga> seb128: but that's just a portion of the information we have about each snap (2nd part comes from the store)
<seb128> zyga, I'm not hacking
<seb128> just trying to use it as an user
<zyga> seb128: I know that Chipaca is working on a richer REST API
<seb128> k, I'm also trying if we have those info available so we integrate them with the desktop frontend
<zyga> seb128: you mean in gnome-software?
<seb128> yes
<zyga> seb128: AFAIR gnome software should use the rest api
<zyga> seb128: there we can expose many details easily
<seb128> right
<seb128> I was just trying to see what is currently exposed
<seb128> and I though I would start as an user with using the command line to see what is displayed there
<seb128> but I hit that wall ;-)
<zyga> yep, I understand
<zyga> seb128: perhaps this can be of some use: https://github.com/ubuntu-core/snappy/blob/master/client/packages.go
<zyga> this is the client side rest API
<plars> popey: you still have these problems like we discussed yesterday with building images with udf, right? fgimenez just sent me a rebuilt binary, but it didn't seem to help, and then I found myself wondering if there was some known-fix that I just didn't hear about yet
<zyga> it's in go but you can make the query in any language
<seb128> right
<popey> plars: i haven't tested since it made my laptop unusable
<seb128> zyga, is there an easy way to see what is currently available? I'm looking after the license info
<zyga> seb128: available as in "can install"?
<plars> popey: ack, thanks
<popey> happy to test to confirm any thing you might need plars
<seb128> zyga, no, I was wonder if there is a way to query the license from a snap through the rest api atm
<zyga> ah
 * zyga looks
<plars> popey: I just wonder how it works for others
<popey> plars: i expect people don't run that commanbd
<zyga> seb128: no, I don't think so, AFAIR some license code was removed before 16.04 as it wasn't ready
<seb128> attente, ^
<zyga> seb128, Chipaca: will know more for sure
<seb128> zyga, thanks
<Chipaca> no i won't
 * Chipaca reads
<seb128> willcooke, do we maintain a list of things we would need? until ^ is resolved g-s is going to show snaps with a "that software is non free" banner
<seb128> Chipaca, can we query the license of a snap through the rest api?
<Chipaca> seb128: nope
<Chipaca> not sure why not though
<Chipaca> gimme a sec
<Chipaca> seb128: so, no. But it could be added easily.
<seb128> Chipaca, we have https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1555567 could you comment/triage the snappy/store side?
<ubottu> Launchpad bug 1555567 in gnome-software (Ubuntu) "License information from the store not being used" [Medium,Triaged]
<willcooke> seb128, we need to get it on to the backlog, so we attend the stakeholders meeting and request it.  (wow! such manager speak)
<seb128> willcooke, :-)
<seb128> willcooke, ^ bug reference there
<willcooke> seb128, so I think we should log bugs and tag them
<willcooke> ah nice
<willcooke> I'll think up a suitable tag name
<Chipaca> seb128: done
<seb128> Chipaca, willcooke, thanks
<Chipaca> willcooke: our bad, wrt licensing
<Chipaca> as long as we're not talking of *accepting a license prompt*, shipping the info should be doable rsn
<Chipaca> if it's urgent i mean :-D
<Chipaca> the interactive license thing is for in about a month? wild-arsed guess
<seb128> yeah, no need of interaction
<willcooke> just spoke to seb128 about this - this issue is that there is a fairly large and unsightly banner in g-s which nags "Freedom hater"
<willcooke> so it would be /nice/ to have that fixed
<willcooke> for the first release of the snappy enabled g-s
<stevebiscuit> https://code.launchpad.net/~stevenwilkin/webdm/snappy-2-0/+merge/292902 # gets WebDM building against recent Snappy
<slvn> got some error when doing "snappy -v" : "snappy version 0.3.7" .... "(snappy:16290): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed.No media set. '
<slvn> http://paste.ubuntu.com/16061735/
<slvn> sorry stupid question, don't know which tutorial makes me install that :)
<Chipaca> slvn: that's probably not this snappy
<Chipaca> :-)
<flexiondotorg> If I create a snap that uses a reserved interface in a snap, such as unity7, is it subject to manual review when submitted to the stire.
<flexiondotorg> *store
<slvn> Chipaca, yes, I figured out :) (though this "snappy" fails anyway).  Just build the hello-world opencv snap :)
<slvn> In addition to "snappy", the package "snap" is also confusing .. one should install "snapd"
<jamiebennett> flexiondotorg, thats the idea, yes
<kyrofa> Good morning
<dpm> hm... it seems somehow 'ubuntu-core' got uninstalled from my system?
<dpm> Is this a known issue, shall I just manually reinstall?
<dpm> on a 16.04 desktop, that is
<dpm> flexiondotorg, although I believe right now only 'home' triggers manual review in the store. 'opengl' will trigger manual review too until the store starts recognizing it
<dpm> so somehow 'snap list' does not list 'ubuntu-core' for me, yet if I try to install it, snap install tells me it's already installed
<dpm> and 'snap interfaces' does not list any slots available
<dpm> ubuntu-core cannot be removed, either
<flexiondotorg> dpm, jamiebennett Is there a 'mir' interface as an alternative to x11 and unity?
<flexiondotorg> If so, is it confined?
<dpm> flexiondotorg, these are the interfaces currently available: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md, but there is ongoing discussion about interfaces in general
<flexiondotorg> dpm, Thanks. Understood. I thought I'd seen mention of a 'mir' interface, but I must have been mistaken.
<dpm> flexiondotorg, perhaps you've seen it in a discussion here on the mailing list, but I don't think it's available
<flexiondotorg> Maybe, I thought I'd seen something.
<oparoz> flexiondotorg, it will probably be available once snaps replace clicks
<josepht> 'snap refresh <snap>' gives me a wrapper error.  I have to 'snap remove <snap>' twice to remove both revisions and then 'snap install <snap>' to get it working again.
<kyrofa> josepht, any chance you had an app running when you tried to remove?
<josepht> kyrofa: no
<sergiusens> josepht kyrofa this happens when sideloading, I hope the fix lands soon
<sergiusens> kyrofa I have gulp working btw! EOD I might get vscode working; then I'll try atom but we need to support grunt
<josepht> sergiusens: ah, thanks.
<kyrofa> sergiusens, yeah make sure you create bugs so we don't forget to upstream what we're working on!
<sergiusens> stevebiscuit as a user, would you prefer using a nodejs snapcraft plugin with a possibility to select npm, gulp or grunt as a build driver or individual plugins for each? So we'd have a nodejs plugin (which already exists), then a gulp  plugin and a grunt one?
<sergiusens> kyrofa upstream? as in snapcraft?
<sergiusens> kyrofa the bug report depends on stevebiscuit's output ;-)
<kyrofa> sergiusens, haha, yeah
 * sergiusens puts some weight on someone else
<kyrofa> sergiusens, same question to you regarding qmake for qt4 versus 5
<sergiusens> kyrofa qmake afaik is tied to Qt versions, is it not?
<kyrofa> sergiusens, sort of. There are different qmake packages for each version, but the qt5 one can call the qt4 one
<kyrofa> sergiusens, but maybe it would be more clear to keep them separate
<sergiusens> kyrofa yeah, I'd hop on to #ubuntu-touch and ask those guys ;-)
<kyrofa> sergiusens, alright
<stevebiscuit> jdstrand: http://pastebin.ubuntu.com/16062943/ # AppArmor is giving a denial when starting WebDM, I think similar has already been reported?
<stevebiscuit> sergiusens: I'd be tempted to see which toolchain the JS community is favouring, build a solution based on that and wait to see if there's demand for the other options
<bloodearnest> jdstrand, hi there! beuno sent me your way regards finding out more about a) cgroups/namespace used to confine snaps, and b) the kernel boot/rollback process, if you've any pointer to docs?
<ogra_> i think jdstrand is out this week
<stevebiscuit> ogra_: cheers for the headsup
<ogra_> stevebiscuit: try tyhicks
<stevebiscuit> tyhicks: http://pastebin.ubuntu.com/16062943/ # AppArmor is giving a denial when starting WebDM, I think similar has already been reported?
<stevebiscuit> ogra_: ta
<sergiusens> stevebiscuit from what I am seeing, gulp and grunt are a waste of time
<sergiusens> stevebiscuit used when the project target's windows as people think npm scripts need to be shell scripts
<jdstrand> stevebiscuit: what version of webdm are you using?
<jdstrand> ogra_: I was only out yesterday
<sergiusens> stevebiscuit http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/
<stevebiscuit> jdstrand: building from https://code.launchpad.net/webdm
<sergiusens> stevebiscuit ok, I think I'm sold on separate plugins that inherit from the nodejs plugin
<sergiusens> so I can deprecate the other ones in an easier fashion
<ogra_> jdstrand: oops :)
<zyga> jdstrand: hey, how are you
<jdstrand> bloodearnest: the documentation is all in flux. I believe that the community team (dpm) is handling updating that
<jdstrand> zyga: hi, good. you?
<jdstrand> bloodearnest: if you had specific questions, I might be able to help with some
<zyga> jdstrand: good :-)
<bloodearnest> jdstrand, ah, ok
<jdstrand> stevebiscuit: I don't see snap.yaml or snapcraft.yaml in that tree. what are you using for that?
<beuno> jdstrand, wasn't there a whitepaper something or another?
<jdstrand> beuno: there is a whitepaper for 15.04, yes, but it wasn't ever published (I asked to have it done but don't think that ever happened)
<jdstrand> beuno: the whitepaper for 16 is done except it'll need updates for GA
<beuno> ah
<bloodearnest> jdstrand, ok, so I've seen various mentions of cgroups and namespace usage for snaps, would like to know what cgroups/namespaces are used, and how they interact with plugs/slots
<zyga> jdstrand: I read that on developer.u.c somewhere (the whitepaper)
<beuno> bloodearnest, there's also apparmor
<stevebiscuit> jdstrand: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/snap.yaml
<beuno> to complete a buzzwork bingo
<bloodearnest> beuno, right, that part I understand
<zyga> beuno, bloodearnest: and dbus and seccomp and udev tagging
<bloodearnest> or at least, understand enough of
<roadmr> at least there's no synergy!
<stevebiscuit> jdstrand: it needs updating to use snapcraft and currenly has it's own build.sh
<jdstrand> stevebiscuit: ah, I missed that. what are the perms of /snap/webdm/100001/snappyd?
<stevebiscuit> sergiusens: so you're going to have something that can be installed via npm initially? the JS community seems intent or re-inventing *everything* in JS heh
<sergiusens> stevebiscuit I am chatting from a snap that uses the nodejs plugin already ;-)
<sergiusens> nodejs/npm
<sergiusens> but I ignored gulp and grunt; but turns out vscode uses gulp and atom uses grunt
<stevebiscuit> jdstrand: 0755. It can be run fine standalone oddly
<jdstrand> stevebiscuit: sorry, what is the ownership
<stevebiscuit> jdstrand: it's owned by ubuntu:ubuntu
<jdstrand> stevebiscuit: ok, that is your problem. how are you building your snap?
<jdstrand> dholbach: note, https://developer.ubuntu.com/en/snappy/guides/security/ is terribly out of date
<jdstrand> dpm: ^
<dholbach> jdstrand, yes, we're on it
<dholbach> AFAICT it's not more than 2 weeks out of date
<stevebiscuit> jdstrand: it's still being built with sergiusens origional build.sh, I've not yet looked into what it needs to be moved to using snapcraft
<jdstrand> dholbach: zyga mentioned the 15.04 security whitepaper was on developer.u.c. I can't seem to find it. do you know where it is?
<dholbach> jdstrand, no, I don't think it ever was on there
<jdstrand> stevebiscuit: ok, let me look at that real quick
<ogra_> you need to at least use snapcraft snap instead of snappy build
<zyga> that was a while ago
<jdstrand> stevebiscuit: right, build.sh is using 'snappy build $builddir'
<jdstrand> stevebiscuit: I think if you change that to 'snapcraft snap $builddir' it should work
<stevebiscuit> jdstrand: cool, I've give that a whirl
<thomas25> Hi
<jdstrand> bloodearnest: I shared the link with you
<jdstrand> bloodearnest: for 16
<jdstrand> bloodearnest: note in general most things should be all settled, but there might be a few things that will change (nothing architecturally)
<jdstrand> bloodearnest: but for the benefit of people in this channel, Ubuntu Core uses a combination of technologies to implement the sandbox. the heart is apparmor, but we also use seccomp, device cgroups, private /tmp and devpts newinstance
<bloodearnest> jdstrand, great, thanks!
<thomas25> Hi
<jdstrand> bloodearnest: the only namespace is the mount namespace for /tmp. we chose to implement the snadbox in this manner because it allows snaps to integrate more fully with the system and to better interact with each other. for people wanting full containers, people can use lxd or docker (though atm neither is available on 16, but will be before GA)
<thomas25> I have a question about the configuration file
<thomas25> How are they handle since the snaps are read only
<jdstrand> tyhicks: fyi, in case you didn't notice, I answered stevebiscuit
<thomas25> I tried the mosquitto snap but I can't edit the mosquitto.conf file.
<bloodearnest> jdstrand, right, I assumed a fairly limited namespace usage, was just looking for details
<jdstrand> thomas25: I'll answer since I happened to have seen the question. In general, the snap would be set up to copy the configuration file from $SNAP to $SNAP_DATA and have the daemon use the file in $SNAP_DATA so that the file is then readable. I don't know how mosquitto is packaged though
<ogra_> thomas25: there used to be a "snap config" command that would use the conf as input and put it into the writable space ... that is temporarily gone and being re-worked
<thomas25> ok thanks
<sergiusens> thomas25 mosquitto from snapcraft sources?
<thomas25> yes
<sergiusens> that is just an example, not meant to be configurable afaik
<jdstrand> bloodearnest: if you want the implementation details of what we do with the devices cgroup, see http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/README
<ogra_> boo
<sergiusens> you can add the smarts for it thought (like have it read from SNAP_DATA or SNAP_USER_DATA)
<sergiusens> ogra_ the examples are also a stress tester for snapcraft itself; not for snaps
<sergiusens> ogra_ I wish the core guys wrote more snaps as that would really make sure the system is good
<jdstrand> I should have said "is then *writable*"
<ogra_> they will come over time :)
<thomas25> SNAP_DATA nad SNAP_USER_DATA are used to override the path of configuration file in snaps ?
<bloodearnest> jdstrand, thanks! already skimming the whitepaper has answers most of my questions! :D
<jdstrand> cool
<kyrofa> thomas25, this question might help: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data
<thomas25> Or the snap just copy the configuration file in SNAP_DATA path ?
<ogra_> thats up to you :)
<ogra_> the snap only provides the path ... weather you copy it and make your service use it is up to you
<ogra_> (you could ship an immutable config just in the readonly dir and not allow the user to alter it at all)
<thomas25> In the snapcraft.yaml how to you say that this goes to SNAP_DATA and that in SNAP_USER_DATA ?
<thomas25> Just using "copy" plugin ?
<ogra_> no, you would write a wrapper that does the copying for you on service startup
<sergiusens> kyrofa with great pleasure I deliver this bug to you https://bugs.launchpad.net/bugs/1575188 ;-)
<ubottu> Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,New]
<kyrofa> sergiusens, yes I just saw that come in
<kyrofa> sergiusens, thanks :P
<thomas25> ogra_: Thanks
<sergiusens> kyrofa while the snapping might work, not sure it would ever be accepted by the store with so many dead symlinks
<kyrofa> sergiusens, yeah might be a question for beuno
<sergiusens> jdstrand rather
<sergiusens> I'm sure it won't
<kyrofa> sergiusens, so is this a wontfix, or should the review tools change?
<sergiusens> kyrofa I'd ask him if the review tools passed without warnings in his previous working snaps
<kyrofa> sergiusens, alright :)
<asac> the pi2 really has no reset button right? (or do i need glasses?)
<zyga> asac: it has no buttons at all AFAIK
<zyga> looking at mine now
<asac> good :)
<ogra_> you can use a strobe light to reset it though
<josepht> lol
<zyga> heheh
<zyga> we need strobe interface
<asac> hehe
<asac> maybe i should use my ttl power and then i can use some tricks with /dev/ttyUSB to repower?
<zyga> asac: whad are you trying to do?
<asac> just rebooting
<asac> without having to fiddle myself through 5 layers of cables :)
<asac> hoping to not unplug some other board or ttl
<asac> ok installing hello-0world to look at hello-world.sh
<asac> to see what is going on
<asac> nice
<asac> doesnt work :)
<asac> bah the pi2 kernel really always get a reset by peer
<asac> so i cannot even try the latest
<asac> error: cannot perform the following tasks:
<asac> - Download snap "canonical-pi2-linux" from channel "stable" (read tcp 10.42.0.95:56112->69.88.149.140:443: read: connection reset by peer)
<ogra_> you really dont make friends with that nordic guy today eh ?
<asac> hehe
<asac> he seems to not like the pi2
<ogra_> i just built aa set of images here
<asac> db worked fine
<ogra_> no issues
<asac> to update
<asac> hmmmmmmm
<asac> think its only when you use it from the device
<asac> not during udf
<zyga> yep, same here
<ogra_> hmm
<zyga> asac: are you on 3g?
<ogra_> lol
<asac> no stble landline
<asac> super stable
<zyga> 4g :-) ?
<asac> 5L
<asac> :
<asac> :P
<ogra_> who would do a kernel update of his pi2 over 3G ?
<zyga> super proxy in betweeen to  read your mail?
<asac> not that i know
<zyga> hmm
<asac> i am direct
 * zyga looks from device
<asac> its really something else
<asac> but the device goes through my desktop
<asac> e.g. connection share
<asac> so could be due to that
<zyga> hmm, all up-todate
<zyga> ahh
<asac> let me think
<zyga> maybe, try direct
<asac> have no lan
<asac> but i never had problems
<zyga> until today ;) AFAIR n-m doesn't use a proxy but I might be wrong
<asac> no it doesnt
<asac> its pure routing
<asac> too bad nothing works on image so i cannot download a big iso to see
<asac> i am sure that would work :)
<asac> well  not so
<asac> let me get a wget
<asac> oh i have chroots
<asac> let me try there
<ogra_> snap install doesnt work either ?
<asac> for instance i had zero issues setting up those chroots
<zyga> works for me
<zyga> just tried on pi2
<zyga> image built yesterday
<asac> ok wget http://cdimage.ubuntu.com/ubuntu-core/releases/xenial/release/ubuntu-core-16.04-core-amd64.tar.gz is running
<asac> wget finished
 * zyga goes to pick up kids from school
<asac> no issues
<asac> ogra_: tells me its already installed
<ogra_> asac, i mean a random snap
 * asac tries
<asac> yeah nmap gives me same error
<asac> xkcd-webserver works
<asac> install mvos image, try refresh
<asac> not working
<ogra_> weird
<oparoz> Is it asking for trouble if bundling python 2.7 in a snap?
<ogra_> just use snapcrafts python plugin
<oparoz> ogra_, I don't need to build anything in python, it's just that dtrx needs python 2.7
<oparoz> ogra_, So I'm just wondering what should be done for such scripts
<ogra_> using the python plugin ;)
<ogra_> it makes sure the right bits get bundled
<ogra_> there was some trick to only get the interpreter ...
<ogra_> source: .
<ogra_> or some such
<oparoz> ogra_, So you mean, not use the deb, but the source archive?
<ogra_> no, define a snapcraft part that uses the python plugin
<ogra_> in your snapcraft.yaml
<oparoz> and use the deb as a staging deb
<ogra_> which deb ?
<oparoz> dtrx
<ogra_> oh
<ogra_> yeah, with teh copy plugin or so
<oparoz> The problem is how to run it on the other side
<oparoz> But I'm guessing Snapcraft will include python2.7
<oparoz> Thus my question whether it's a good idea since python 3 is already present
<oparoz> Because the script calls /usr/bin/python
<ogra_> well, what does the deb depend on ?
<oparoz> Depends: python (>= 2.7), python (<< 2.8), bzip2, unzip, cpio, rpm, binutils, p7zip-full, cabextract, unshield, lzma, xz-utils
<ogra_> smaller than 2.8 ...
<ogra_> there you got your answer :)
<oparoz> OK, so Snapcraft will ship Python2.7 and create a wrapper which points /usr/bin/python to /usr/bin/python2.7 ?
<ogra_> i dont know, thats a sergiusens or kyrofa question :)
<kyrofa> ogra_, oparoz if python is pulled in via stage-packages snapcraft won't do anything special
<ogra_> but i think it replaces the shebang line in all py scripts it finds
<ogra_> kyrofa: no, via the python plugin
<oparoz> kyrofa, Ah, then the script will fail in the snap
<kyrofa> Ah, but ogra_ is right-- the shebangs should be fixed via the stage-packages
<oparoz> Ah, no, the default in core is 2.7, so I'm guessing v3 scripts in debs use /python3
<oparoz> kyrofa, Ah, that's good if snapcraft fixes shebangs
<kyrofa> oparoz, should be replaced with "#!/usr/bin/env python"
<oparoz> kyrofa, OK and the wrapper will provide the correct env
<ogra_> yeah
<kyrofa> oparoz, assuming you're using the python plugin, yeah
<oparoz> OK, I'm going to try that and see if it works, thanks
<sergiusens> python is very unflexible about installation paths which is sad for such a flexible language in itself
<ogra_> wobbly-python :)
<oparoz> :D
<_morphis> zyga: whats with the changes you did for the bluez itnerface? did jdstrand review them?
<jdstrand> I wanted to sync on that today. I'm not sure what is expected at this point
<ogra_> will be interesting to see what happens if you install it on a desktop :)
<jdstrand> that's another converstation that needs to be had. sdoc interfaces vs core interfaces
<seb128> jdstrand, hey, I think you had a go at making at snap from gnome-calculator, is your work available somewhere? we are at a sprint and would like to have a look to start tomorrow, would be nice to restart from scratch if you resolved some of the issues already though
<jdstrand> seb128: I tried, it failed. I talked to dsert and he gave some tips but I was unable to continue. someone I think last week was trying something similar and so I gave my notes. let me find that
<seb128> jdstrand, thanks
<jdstrand> seb128: this is the branch (note, it is horrible) -- lp:~jdstrand/+junk/gnome-calculator . Still digging up notes
<seb128> jdstrand, thanks
<jdstrand> right, it was sergiusens I talked to about it
<jdstrand> seb128: http://paste.ubuntu.com/15923754/
<seb128> sergiusens, ^ did you look more into that one (before we dup work)?
<jdstrand> seb128: sergiusens was looking at snapping firefox (which is gtk) and I gave him those notes. not sure how much farther he got if at all
<seb128> jdstrand, thanks, hopefully we can move things forward at the sprint this week
<jdstrand> cool
<sergiusens> seb128 no I haven't
<jdstrand> though I imagine you're going to need some interfaces work. I was trying to get it to a point where I could look at that, but couldn't at first and then was busy helping with interfaces/etc for release
<seb128> sergiusens, no worry
<jdstrand> so a working snap in --devmode would be great
<seb128> right
<_morphis> jdstrand: not sure, zyga just said he wanted your eyes on what we he implemented
<jdstrand> I thought I did that...
<_morphis> jdstrand: https://github.com/ubuntu-core/snappy/pull/1037#issuecomment-214386816
 * jdstrand looks at the PR again
<_morphis> jdstrand: hah, sounds like we're deadlocking :-)
<jdstrand> _morphis: I need zyga to comment. I gave zyga a patch for him to build off of. I haven't seen anything else
<_morphis> jdstrand: he implemented https://github.com/zyga/snappy/commit/16228ad739da17d0ff975a1d781db4a53dfdbc79
<jdstrand> _morphis: ok, commented in both
<_morphis> jdstrand: thanks
<_morphis> jdstrand: didn't looked through the snappy code yet for this, but isn't there an easy way to figure the plug name?
<jdstrand> _morphis: not at that point in the code
<_morphis> jdstrand: ok
<_morphis> ssweeny: can you pull those changes in from zyga?
<_morphis> jdstrand: will implement the same for networkmanager tomorrow
<jdstrand> _morphis: that is the bit that zyga needed to look at (I gave him a similar patch as the commit which he was going to work off of to get the app name, which isn't available in any of the structures in that function atm)
<ssweeny> _morphis, already pulled them locally and tested them
<ssweeny> _morphis, pushing now
<_morphis> ssweeny: awesome!
<jdstrand> please add a FIXME comment though
<_morphis> jdstrand: could you have a look on the minimize dbus policy at https://github.com/ubuntu-core/snappy/pull/1036 too?
<_morphis> jdstrand: will add the same changes we're doing for security label tomorrow
<ssweeny> jdstrand, it should end up as "snap.bluez." ?
<ssweeny> trying to parse the punctuation in your comment
<jdstrand> ssweeny: what 'it' are you referring to?
<jdstrand> the future fix or the current implementation?
<jdstrand> current proposed* implementation
<jdstrand> _morphis: commented
<_morphis> jdstrand: thanks
<ssweeny> jdstrand, I mean, should the comment be "FIXME: this glob turns into snap.bluez.* where it *SHOULD* be snap.bluez."
<jdstrand> ssweeny: 'where it *SHOULD* be snap.bluez.<app>'
<ssweeny> jdstrand, ok that's what I wanted to understand
<jdstrand> ssweeny: also, really, it should say 'where it *SHOULD* be snap.<name>.<app>'
<ssweeny> jdstrand, I think your <app> got lost in the comment
<jdstrand> ah
 * jdstrand shakes fist at github
<ogra_> what do you expect from a site that requires flash to provide you tarballs of the trees :P
<jdstrand> ssweeny: fixed github comment
<mvo> jdstrand: snappy-debug is your baby, right? would be nice to have an update for 16 - looks like it is using old-security, anything we can do in the short term with it? do we have an interface that works ?
<jdstrand> mvo: it is completed broken
<mvo> jdstrand: and we can not bring it back because it has to be unconfined?
<jdstrand> mvo: it has to be rewritten. best to remove it at the moment
<jdstrand> the tool itself is broken
<jdstrand> interfaces moved all policy into go and so there is nothing to grep
<mvo> jdstrand: oh, I see
<mvo> jdstrand: ok, I updated the bug about it (doing triage now and stumbled over this one)
<jdstrand> is it in 16?
<jdstrand> I didn't ask for it to be there
<jdstrand> once it is rewritten it should work with log-observe
<jdstrand> but that isn't autoconnected
<jdstrand> mvo: ^
<mvo> jdstrand: its not in 16
<jdstrand> ok
<mvo> jdstrand: there is a bug that its broken in rolling and I was checking the state
<jdstrand> are you taking my irc comments and putting them in the bug?
<jdstrand> or shall I? I can, but what is the bug number?
<mvo> jdstrand: I will add them
<slvn> hello. I'm trying to build/install my first snap package. I use SDL2 which needs to access "libmirclient". After building, "libmirclient" is not in my "/snap/mytest/current/..." whereas libSDL2 is. I think I should set a magic line in cmake to install it ? any idea ?
<mvo> jdstrand: https://bugs.launchpad.net/snappy/+bug/1543118
<ubottu> Launchpad bug 1543118 in Snappy "Snappy-debug installation on 16" [Wishlist,Triaged]
<jdstrand> mvo: thanks! fwiw, this is the next thing I will move to after various interfaces work
<mvo> jdstrand: ta
<sergiusens> jdstrand can I invoke your wisdom http://pastebin.ubuntu.com/16065450/ ?
<sborovkov> ogra_: Hello, are there still 2 gadget snaps for rpi?
<sergiusens> jdstrand oh, seems to not be related to security; crashes with --devmode too
<sergiusens> I guess I need to do some sort of gtk dance
<ogra_> sborovkov: yes, canonical-pi2 and canonical-pi3
<ogra_> they share the canonical-pi2-linux kernel package
<jdstrand> I'll still add those denials as something to consider
 * jdstrand is gathering a list
<ogra_> sergiusens: videos though, or it didnt happen
<ogra_> i guess seb128 knows the exact steps for all gkt dances
<ogra_> *gtk
<sergiusens> yeah, it might not be gtk
<sergiusens> ogra_ jdstrand I'm running into this code path https://chromium.googlesource.com/chromium/src/+/lkgr/crypto/nss_util.cc#206
<ogra_> uh, nss
<jdstrand> sergiusens: you might ask ChrisCoulson if he knows anything about that chunk of code. I have a feeling he had to work with that before with webapp-container
<jdstrand> (as webapp-container relates to oxide)
<sergiusens> jdstrand yeah, it will be a hard fix as this is electron
<sergiusens> necessary though as all apps are written with this now :-)
<ogra_> "all apps"
<sborovkov> ogra_: so for RPI2 and RPI3 different images will need to be built always?
<ogra_> sborovkov: unless ppisati made the uboot binary work on both, yes ... the pi3 uboot breaks the pi2 serial
<ogra_> i'll look into an arm64 build too in the near future
<ogra_> so there might even be a third gadget
<sborovkov> Is it possible to mount directory with binaries instead of squashfs temporarily? So that I have write access but still run inside of the snap
 * ogra_ doesnt understand that question
<ogra_> you can only deliver snaps as squashfs ... so there is no way to make the snap itself writable
<ogra_> you can mount overlays on top of files manually i guess ... for temporary changes and tests
<sborovkov> ogra_: yeah, I don't want to deliver, just to be able to make quick changes locally
<zyga> _morphis: not that I know of yet, could you push them to the branch so that they appear in the pull request?
<zyga> test
 * zyga wonders if this works
<zyga> jdstrand: hey, around?
<jdstrand> zyga: yes, hi
<zyga> jdstrand: hey
<zyga> jdstrand: I sent a pull request the other day, that changed the x11 interface
<sborovkov> zyga: Hello, do you have any time estimations when RPI interfaces going to be in? If not - is that a difficult change to do to allow access to /dev/vchiq and may be I could it myself then?
<zyga> jdstrand: I also made a change to bluez but I'm not sure if you've seen that
<zyga> sborovkov: hey, no estimate yet, our focus is on devices but I'm sure I'll be split between desktop and iot world for now
<zyga> sborovkov: I can guide you with interface work, I will gladly review and merge new interfaces
<zyga> jdstrand: https://github.com/zyga/snappy/commits/bluez-fix-rules
<sborovkov> zyga: ah, alright cool, could you point me to the source code of some similar interface may be?
<zyga> jdstrand: https://github.com/zyga/snappy/commit/e0f7f3bec17b0f33f3aaf4fa0c0f4273c98a788a
<zyga> sborovkov: there aren't any yet, please familarize yourself with the two articles I've published on interfaces already, I have the third one half-written (specifically about how interfaces work internally), reading interfaces/core.go would be useful
<sborovkov> zyga: Ok
<jdstrand> zyga: I commented on https://github.com/zyga/snappy/commit/16228ad739da17d0ff975a1d781db4a53dfdbc79 a few minutes ago
 * zyga looks
<jdstrand> (https://github.com/zyga/snappy/commits/bluez-fix-rules)
<zyga> jdstrand: replied
<jdstrand> zyga: I didn't see the x11 PR. where is it? (I didn't see the bluez one either until _morphis pointed it out to me)
<zyga> jdstrand: trying to find the pull request
<zyga> https://github.com/ubuntu-core/snappy/pull/1069
<zyga> jdstrand: mvo merged it
<jdstrand> zyga: replied to your question
<jdstrand> zyga: getsockname is fine
<zyga> jdstrand: I think we need a protocol to ensure that in the future all such requests are acked by you before they land
<jdstrand> I agree. we said before that any changes to policy should go through the security team
<jdstrand> its fine if that is me for now, but it could be anyone on the team once things settle a bit
<jdstrand> it's
<zyga> jdstrand: thanks for clarifying the bluez patch, I will fix it shortly!
<jdstrand> np, thank you! :)
<zyga> jdstrand: offtopic, can we do a pulseaudo interface so that games can have sound :)
<jdstrand> well, that is a very interesting conversation
<jdstrand> cause it brings out a problem we have
<zyga> (perhaps just for playback as 1st attempt)
<zyga> auto-connect?
<jdstrand> Ubuntu Core systems vs sdoc
<zyga> sdoc?
<jdstrand> which we are seeing already
<jdstrand> snappy dimension on classic
<zyga> ah
<jdstrand> snappy on desktop
<zyga> yes, I see
<zyga> same with network-manager and pulseaudio really
<zyga> and bluez
<jdstrand> for example, we have a bluez interface, about to have nm and pulseaudio
<jdstrand> yeah
<jdstrand> you see what I'm getting out
<zyga> I was thinking that we should auto-create the slots on desktop systems and not create them on IOT systems
<jdstrand> the interfaces are with slots/plugs snaps in mind
<jdstrand> but classic has these as debs
<ogra_> and if my IOT wants to use sound notifications ?
<jdstrand> ogra_: then you install the pulseaudio snap
<zyga> I think the value should be that the interface is the same (if you have pulse snap)
<ogra_> jdstrand: and that provides the same interface ?
<jdstrand> zyga: I'm not so sure
<zyga> and the same client snap would work on desktop (with deb based pulseaudio) and on iot with a pulse snap
<jdstrand> ogra_: that is the question
<zyga> no?
<ogra_> heh
<zyga> eeek, no power
<zyga> brb
<ogra_> get an M10 !
<jdstrand> traditional desktop apps might use things in pulseaudio that we wouldn't want to allow to apps
<jdstrand> for example
<jdstrand> pulseaudio has a socket interface and a dbus interface
<jdstrand> on touch, we only allow access to one because the other is dangerous
<ogra_> yeah
<jdstrand> so, core systems might want a different policy than classic systems
<zyga> ogra_: I'm not sure it could replace my activities today, I'm tempted to see how it plays out at the upcoming sprint
<zyga> jdstrand: ok, simplifying this for now, I'd like a sound interface that works for 80% of the desktop games out there
<ogra_> zyga: well, it is good if you do a lot on remote machines ... i doubt i'd want to use it for loacl image builds or so :)
<zyga> jdstrand: because that's a vaiable target for snappy today and because it's a good thing to have :)
<jdstrand> zyga: obviously I'm not saying no to accessing pulseaudio. I'm just saying all this brings up questions
<zyga> ogra_: I hack on snappy
<ogra_> mail, irc, browsing and terminals definitely work fine ... and it lasts a good 16-18h
<zyga> jdstrand: yes, but I think we have to be pragmatic, we should populate 16.04 with useful desktop interfaces rapidly
<ogra_> zyga: and ?
<zyga> ogra_: and nothing else, I use udf to build snap images
<zyga> ogra_: not heavyweight
<ogra_> zyga: i hack on all sorts of stuff ... rarely on teh machine i'm typing on :)
<jdstrand> zyga: no one is arguing that. I think a conversation with niemeyer would be worthwhile though :)
<zyga> ogra_: I don't want two machines, tried that, went back to one
<zyga> jdstrand: no disagreements there :)
<jdstrand> my inclination is actually maybe put these in unity7, or maybe unity7-audio
<jdstrand> and leave pulseaudio interface as a proper interface for a pulseaudio snap
<zyga> ogra_: I'd be sold iff I could get usable editor (vim) with my settings and ability to run it without squinting my eyes in the terminal
<zyga> ogra_: assuming I can do a xenial chroot
<ogra_> yeah
<zyga> jdstrand: hmm, interesting
<ogra_> and even natively ...
<zyga> jdstrand: I'm sure we'll bring this up at the sprint
<jdstrand> zyga: because these are all of the 'classic desktop' persuasion and shoehorning stuff that wasn't designed for snappy
<zyga> asac: offtopic, I just built the bbb image
<jdstrand> zyga: on an image that isn't ubuntu core plus a bunch of magical dbus things that appear to be from no where (from the app's perspective)
<jdstrand> anyway, niemeyer said he is back tomorrow I think. we can pick it up then
<zyga> yep
<sergiusens> jdstrand ok, so my vscode snap turns out to fail even when running locally but preferring the libraries from the snap; coincidentally most of them are glib/gtk ones ;-)
<jdstrand> interesting
<zyga> sergiusens: once we make it work, do we sent that to microsoft to release?
<sergiusens> zyga yeah, I already learned gulp and created a `snap` target and have snapcraft.yaml fully building
<sergiusens> it just doesn't work ;-)
<zyga> sergiusens: does a pre-made binary work?
<sergiusens> zyga I don't think so; the electron binary is prebuilt (fetched from the build system)
<sergiusens> zyga and the `snap` works as long as ld_library_path (toup())  is not set to point to the snap
<zyga> sergiusens: any idea what the problem is/
<zyga> hmm
<zyga> rpath?
<sergiusens> zyga I suspect it is gtk initialization
<zyga> sergiusens: did you try to snap the gtk demo app with all the widgets?
<sergiusens> zyga no; gtk is black magic to me
<sergiusens> zyga you try ;-)
<zyga> sergiusens: why? :)
<zyga> sergiusens: I can try on Friday
<sergiusens> zyga ask jdstrand :-)
<zyga> jdstrand: ^^ :-)
<jdstrand> ask me?
<zyga> (I want to know what I'm getting into)
<jdstrand> I'm no gtk guru
<jdstrand> seb128 is sprinting this week and are going to look at this stuff
<sergiusens> jdstrand I didn't tell him to ask you to do it, but rather how your endeavour came through ;-)
<jdstrand> I suggest talking to him
<jdstrand> oh
<jdstrand> my endeavor failed
<zyga> hehe
<zyga> in what way?
<sergiusens> from the looks of it; there are more vars than for Qt and there are dependencies on fixed paths
<jdstrand> I was able to start the calc without crashing, but menus, themes, gsettings, etc all failed
<zyga> gtk loves to have various processes
<zyga> I wonder what the approach should be
<zyga> isolate each snap
<zyga> or have them see a part of gtk (daemons)
<zyga> from the system
<zyga> e.g. themes will be a problem otherwise, I don't know what qt does here
<zyga> (apart from fully-skinned apps)
<jdstrand> zyga: note, I talked to dsert about this a bit a while ago, but couldn't go farther due to other snappy work. I forwarded that conversation to seb128: http://paste.ubuntu.com/15923754/
<zyga> I suspect gtk will need a few patches to love $SNAP first
<jdstrand> that would not surprise me
 * ogra_ whispers "static builds"
<sergiusens> reason I love go ogra_
<sergiusens> just drag and drop!
<ogra_> so just do it in go-gtk :)
<ogra_> trivial ... just port the app :P
<sergiusens> ogra_ go-gtk dyn links against gtk
<ogra_> lol
<sergiusens> it would have to be an api compatible rerwite using Qt underneath ;-)
<zyga> ogra_: what's the battery life like on m10?
<ogra_> zyga: i'm at 60% after doing 6h of constant work on it
<zyga> ogra_: wow, what perhiperhials are you using?
<zyga> ogra_: do you have a screen attached?
<ogra_> and i have a bunch of apps excluded from lifecycle mgmt ... meaning it actually consumes more than a default system
<ogra_> only a k480 Bt keyboard
<zyga> ogra_: no mouse?
<zyga> ogra_: do you work with the only screen being the 10" tablet?
<ogra_> nah
<ogra_> yep
<zyga> ogra_: man, you must have good eyes
<zyga> ogra_: how do you physically keep it in place on your desk? any stands/arms holding it?
<zyga> ogra_: I was wondering if I'd switch to that device entirely or just use it in addition to my laptop
<sergiusens> zyga jdstrand GI is s glib/gtk thing, right? http://pastebin.ubuntu.com/16069260/
<ogra_> zyga: http://i.imgur.com/apYL565.png
<zyga> looks like gobject introspection
<zyga> ogra_: it looks big on my 15" screen ;)
<zyga> hmm
<ogra_> heh
<jdstrand> glib, yes
<zyga> I wonder if someone could come up with hdmi-over-ethernet snap for x86 boxes
<zyga> pick old laptop
<zyga> install that snap
<zyga> and use it as a networked monitor
<zyga> use modern hw with all the spare "monitors" :)
<sergiusens> ogra_ what chat app is that
<ogra_> kiwi
<ogra_> excluded from lifecycle
<ogra_> the app from the store
<zyga> how do you do that?
<zyga> I was actually thinking that lifecycle elision would be a nice interface
<zyga> I'm sure we'll have to solve a lot of very interesting cases before phone and snappy merge
<ogra_> its a gsettings key that takes a list of app ids
<zyga> ah
<ogra_> i got dekko, kiwi and the terminal added there
<sergiusens> ogra_ why dekko?
<sergiusens> I use dekko all the time, never had the need to exclude it from lc
<ogra_> because my mailserver is a single core machine running off a 4200rpm disk
<zyga> ogra_: do you have a chroot or did you made / writable?
<ogra_> takes a century to deliver a mail ... so i want dekko to sync in bg
<zyga> ogra_: (as in, will you get OTAs?)
<ogra_> nothing writable, no
<ogra_> i have a local libvertine container for X apps
<ogra_> *libertine
<ogra_> the device is proper on teh stable channel, system partition untouched
<zyga> ogra_: you should blog about how you set that up
<zyga> ogra_: I'm not sure I even heard about libertine :)
<ogra_> i was planning to do that on teh weekend ;)
<ogra_> it gives you containers hooked into xmir
<ogra_> so you can run firefox and stuff
<zyga> ogra_: is firefox readable on the fhd screen?
<ogra_> well, it doesnt use the proper DPI settings yet ...
<ogra_> it is very small ... but you noticed already that i have good eyes ;)
<ogra_> but i obnly used it twice for a few mins ... the ubuntu browser is really superior to it imho
<sergiusens> I am using the ubuntu browser on desktop as well fwiw ;-)
<sergiusens> so light weight!
<ogra_> yeah
<sborovkov> Is /writable still the place to write a lot of stuff? I don't want to write to SNAP_USER_DATA because it would be replicated (from what I understood) and since I am on RPI and there is a lot of stuff I need to store that would be pretty bad for SD card
<ogra_> your snap cant see /writable ...
<ogra_> but yes, it is still the writable area (as the name kind of implies ;) )
<ogra_> and actually our only system partition nowadays
<sborovkov> Wait, so what do I do if it can't see it
<ogra_> you write to SNAP_DATA
<ogra_> afaik there was work going on to allow your snap to override the duplication/copying on upgrade ... not sure where that stands though
<sborovkov> ogra_: SNAP_DATA won't be replicated and will be persistent, right?
<ogra_> it will be replicated by default, but yes, it is persistent
<sborovkov> ogra_: Ok. May be it would be better to use HOME interface? it allows access to /home/ubuntu as far as I understand. We keep playlist which can be pretty large
<sborovkov> any additional replications won't be good for SD card
<ogra_> not sure if teh home interface actually works on IOT ... thats a desktop thing
<ogra_> also note that you can not attch to the home interface automatically
<ogra_> requires user interaction
<ogra_> as i said, there was work to allow you to prevent the duplication ... but i dont know where that stands
<oparoz> ogra_, regarding "your snap cant see /writable" is this a new thing which is going to stay that way?
<sborovkov> ogra_: Yeah, I understand, but while it's not in I'd prefer to use something else without replication. We implemented slot in gadget snap (which we use custom version of) before to allow access to /dev/vchiq. Is it possible to do the same with new security to grant access to /writable or /home/ubuntu or any other directory?
<ogra_> oparoz: nope, has always been that way
<sergiusens> elopio kyrofa standup today?
<kyrofa> sergiusens, ah yeah on my way
<ogra_> oparoz: a snap can only see its own subdirs
<oparoz> ogra_, I'm able to access data from another snap by using a /writable path
<ogra_> (one of them is a writable one)
<sergiusens> kyrofa let me get some coffee first
<ogra_> oparoz: that would be a bug if yuor snap is actually confined
<kyrofa> sergiusens, ugh, you remind me I need to roast some
<oparoz> I'm on the older mvo image though...
<oparoz> Ah, good point, ogra... I was testing with unconfined
<ogra_> ah
<ogra_> yeah, then you have access everywhere :)
<ogra_> sborovkov: install the hello-world snap ... then use hello-world.sh .... that gives you a shell inside a confined snap env
<ogra_> so you can inspect what you can access and what you cant
<oparoz> ogra_, so the way forward is to wait for you guys to implement an interface giving writable storage access to other snaps
<oparoz> that would help make snaps more atomic
<ogra_> well, not sure that is planned at all ... you can have a "library" snap that all your other snaps can access ... i guess that way you could have a shared dir
<ogra_> but i think these library snaps are also still a bit away
<oparoz> ah, that famous library snap :)
<ogra_> zyga could probably tell you more ... i'm mainly guessing here from what i pick up in drive-by conversations
<jdstrand> tyhicks: can you advise how I should fix https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1574556 ? it seems like I should add to ubuntu-core-launcher's policy the ecryptfs workaround rules from the base abstraction
<ubottu> Launchpad bug 1574556 in ubuntu-core-launcher (Ubuntu) "apparmor denials reported for encryped HOME" [Undecided,New]
<tyhicks> jdstrand: that's the best option for now - there'll soon be a kernel fix upstream for this and then we can SRU that and drop the workaround rules
<jdstrand> that would be fantastic! :)
 * jdstrand hugs tyhicks :)
<tyhicks> jdstrand: actually, it was a contribution from chromeos (I still need to review and test v2 of their patch)
<wililupy> Ok, let me ask if this makes sense for adding kernel modules to my kernel snap...
<wililupy> I get my source (apt-get source linux-image-`uname -r`
<jdstrand> I don't know how to hug chromeos, so I'll leave that with you
<wililupy> I build it with snapcraft (snapcraft build)
<tyhicks> jdstrand: :)
<wililupy> I then build my kernel modules against the build (make all KSRC=/tmp/ksnap/parts/kernel/build)
<wililupy> I then stage (snapcraft stage)
<wililupy> I copy the modules into ./stage/lib/modules/`uname -r`/extra/*.ko)
<wililupy> depmop them (depmod -b ./stage/kernel `uname -r`)
<wililupy> then build the snap (snapcraft snap)
<wililupy> Does that make sense? I want to script this for the customer and want to know if this is a good solution.
 * zyga looks at backlog for that one bit 
<kgunn> so, if i'm adding an interface...and i go to install my built snap for the very first time...bout how long should the  'Setup snap "mir-server" security profiles' take?
<kgunn> seems to be spining quite some time...
<kgunn> any hints what i might have done wrong
<zyga> jdstrand: around
<zyga> kgunn: can you share your branch please
<kgunn> will do
<jdstrand> kgunn: it would be nearly instant. no more than a second or two
<jdstrand> zyga: yes
<jdstrand> s/would/should/
<sergiusens> jdstrand kyrofa zyga nailed the vscode problem down to libnss3 being included in the snap
<zyga> jdstrand: I want to show you the bluez code with 2nd fix, let me quickly share it
<zyga> sergiusens: \o/
<jdstrand> sergiusens: nice! :)
<sergiusens> I don't know how to solve it yet though :-P
<zyga> sergiusens: solve it?
<sergiusens> zyga I know what causes the SIGABRT
<sergiusens> but not why
<zyga> ahh
<sergiusens> zyga - Remove snap "vscode" from the system (remove /snap/vscode/100001/CHANGELOG.md: read-only file system)
<sergiusens> what is going on?
<zyga> sergiusens: oh, nice bug
<zyga> sergiusens: please report this, note that it wants to remove the *changelog*
<zyga> sergiusens: I saw it before but I wasn't sure how to reproduce it
<zyga> jdstrand: https://github.com/zyga/snappy/commit/e9b2da3d1459d1f0dfa92036f0de477757024a4b
<zyga> (no more globs :-)
<sergiusens> zyga I've just installed and removed repeatedly
<zyga> sergiusens: please report it with snap changes and syslog parts (journalctl -u snapd)
<zyga> sergiusens: keep your state around if you can, I'm sure pedronis will want to see it
<zyga> sergiusens: (or attach it to the bug as well please)
<sergiusens> zyga seems to be a systemd mount issue
<sergiusens> zyga https://bugs.launchpad.net/snappy/+bug/1575385
<ubottu> Launchpad bug 1575385 in Snappy "After installing and removing for a while I can't remove anymore" [Undecided,New]
<zyga> Apr 26 18:34:53 lindon /usr/lib/snapd/snapd[16408]: overlord.go:142: Failed to stop "/etc/systemd/system/snap-vscode-100001.mount": [stop snap-vscode-100001.mount] failed with exit status 1: Job for snap-vscode-100001.mount failed. See "systemctl status snap-vscode-100001.mount" and "journalctl -xe" for details.
<zyga>                                                     , but continuing anyway.
<zyga> Apr 26 18:34:53 lindon snapd[16408]: 2016/04/26 18:34:53.066860 overlord.go:142: Failed to stop "/etc/systemd/system/snap-vscode-100001.mount": [stop snap-vscode-100001.mount] failed with exit status 1: Job for snap-vscode-100001.mount failed. See "systemctl status snap-vscode-100001.mount" and "journalctl -xe" for details.
<zyga> Apr 26 18:34:53 lindon snapd[16408]: , but continuing anyway.
<zyga> I suspect this is key
<zyga> thanks sergiusens!
<sergiusens> zyga np
<zyga> jdstrand: is the patch sensible?
<zyga> jdstrand: if so I can propose it and we can close the earlier branch
 * jdstrand looks
<zyga> jdstrand: as a full pull request: https://github.com/ubuntu-core/snappy/pull/1078/files
<zyga> I also closed the earlier one
<jdstrand> zyga: so, I think this looks generally fine. I've been working under the assumption that you can do a connection between snaps, between apps or between apps and snaps. if this is the case, will slot.Apps() contain all the apps if connection to a snap?
<zyga> slot.Apps is the map of all apps bound to that slot
<zyga> it's not about connections
<jdstrand> zyga: ie, what this does is get rid of the glob entirely, but the glob is useful for connecting to a snap
<zyga> connections are handled by calling the interface many times
<zyga> so if both, say, bluetoothctl from the same snap is connected
<zyga> and a 3rd party snap with some apps are connected
<zyga> those will get separate snippets
<jdstrand> sure
<zyga> that both specify the peer label precisely
<sergiusens> zyga ok, another weirdness; now on every `snap install` I get this old snap installed that can't be removed
<zyga> not sure if that answers your question
<sergiusens> zyga already ran your cleanup script twice!
<zyga> sergiusens: oh?
<zyga> sergiusens: did you restart snapd too?
<zyga> sergiusens: I think the script stops it
<sergiusens> zyga your script does that, does it not?
<zyga> yep
<zyga> hmm
<zyga> so run the script, don't start snapd
<zyga> see if anything else remains, systemd mount units maybe?
<zyga> but actually
<zyga> snapd restarts changes + tasks
<zyga> hmm
 * zyga has no idea
<sergiusens> zyga not unmounting now
<jdstrand> zyga: I understood that. what I'm saying is this: snap connect foo.bar:bluez bluez5:bluez vs snap connect foo.bar bluez5.bluezd:bluez
<jdstrand> where foo has:
<jdstrand> name: foo
<sergiusens> zyga /var/lib/snapd/snaps/vscode_100001.snap (deleted) on /snap/vscode/100001 type squashfs (ro,relatime)
<jdstrand> apps:
<jdstrand>   bar: ...
<jdstrand> and bluez5 has:
<jdstrand> name: bluez5
<jdstrand> apps:
<jdstrand>   bluezd: ...
<jdstrand>   bluetoothctl: ...
<zyga> jdstrand: note that you cannot connect an application, if you connect foo's plug, you connect the bar app from foo snap (reading rest)
<zyga> jdstrand: I'm not sure if I understand what you are saying, in your example you would do the following connect:
<jdstrand> zyga: ok, fine, so snappy does magic
<zyga> jdstrand: snap connect foo:something bluez5:bluez5
<jdstrand> let me come up with a paste
<zyga> or s/bluez5:bluez5/bluez5:bluez/
<zyga> sergiusens: we merged better remove today
<zyga> sergiusens: remove removes all revisions now
<zyga> sergiusens: maybe it hit the ppa by now
<zyga> (though I don't know if you want to follow the ppa)
<wililupy> crap. Ok. So I built my kernel snap using snapcraft, I add it as the --kernel= with u-d-f but when I try to boot up, I get the following error: http://pastebin.ubuntu.com/16071576/ and then I go back to GRUB menu...
<wililupy> Any ideas?
<zyga> wililupy: nope, sorry
<wililupy> Everything looks good, just no ideas. At first I thought maybe it was becuase I wasn't root when building the kernel snap, but even that doesn't work...
<zyga> I don't think you should ever be root with snapcraft
<zyga> ogra_: any idea if I can try convergence/firefox on nexus 7?
<wililupy> zyga it builds fine with my normal user account as well, everything builds fine, I just haven't been able to build a working kernel snap since 2.5...
<zyga> ogra_: I have a channel (pd-proposed or something) that has the firefox icon but it does nothing
<zyga> wililupy: I think you want to talk to sergiusens
<sergiusens> no, I'm not a kernel person
<zyga> he is just teasing ;)
<sergiusens> jdstrand zyga ok, apparently I can't "relocate" nss, but it is not in ubuntu-core
<zyga> sergiusens: isn't nss using lots of plugins and a socket to talk to various parts and a daemon
<zyga> sergiusens: doesn't sound like something we should put into snaps
<zyga> sergiusens: it does name resolution among other things IIRC
<sergiusens> zyga right, but if core doesn't provide it, what to do?
<zyga> sergiusens: provide it in core
<sergiusens> zyga do it then ;-)
<sergiusens> ogra_ ^
<sergiusens> :-)
<zyga> ogra_: correct me if I'm wrong but it feels like a core item
<zyga> btw are you sure it's not in core?
<zyga> extra users AFAIR use nss
<zyga> (some fancy plugin to look at places other than /etc/passwd)
<jdstrand> zyga: http://paste.ubuntu.com/16071638/
<sergiusens> zyga if I don't add it $ vscode /snap/vscode/100001/code-oss: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory
 * zyga focuses on the pastebin
<kgunn> zyga: will send you a mail with info later...got to attend to a house calamity atm :)
<zyga> kgunn: sure
<jdstrand> sergiusens, zyga: not libnss3 is Network Security Services, an encryption library from the mozilla project and not 'Name Service Switch' from glibc name resolution
<jdstrand> s/not/note/
<jdstrand> ie, there is no daemon, etc, etc with libnss3
<zyga> jdstrand: I see
<zyga> jdstrand: /o\
<zyga> jdstrand: as for the pastebin, I think we can special case 2. to just use the app name, for 1 I'd keep it as-is, it's precise and does the same thing
<jdstrand> sergiusens: I wonder if you need libnspr4
 * zyga will name all his new libraries libnss
<zyga> libnewstuffsomething
<zyga> with a random number
<sergiusens> jdstrand it is in there
<sergiusens> jdstrand I am manually adding the plugins now to see if that is it
<sergiusens> adding libnss as a stage-package
<jdstrand> zyga: so I'm inclined to agree, but note that complex alternations ({1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,...}) can be a bit unwieldy when a glob would be better
<zyga> jdstrand: hmmm, so the glob might make sense if slot.Apps != slot.Snap.Apps
<zyga> jdstrand: we can special case both cases so that we get a glob or no globs or alternation
<zyga> jdstrand: if you think it's worth doing
<zyga> s/!=/==/
<jdstrand> zyga: it is most correct and since we are thinking about it, it would be better to do it now. otherwise I would suggest you add a comment saying that snaps with a lot of apps in them could be better written with a glob rule
<zyga> jdstrand: you mean special case both of those?
<zyga> jdstrand: I can do it quickly
<jdstrand> zyga: yes please
<sergiusens> jdstrand zyga ok I stage-package'd libss3 and am further ahead, happy to see apparmor denials :-) http://paste.ubuntu.com/16071766/
<jdstrand> zyga: which means we need a test for case 1 and case 2 in addition to your existing test (of course)
<jdstrand> sergiusens: ok, two of those are the same as you gave earlier and I'll do a PR to add them (the /proc denials). the /etc/profile.d you need to invoke bash differently (ie with a bashrc) so it doesn't look there and /var/tmp is probably a noisy denial
<jdstrand> sergiusens: it is probably trying /var/tmp then going to /tmp
<sergiusens> jdstrand maybe, yeah, the first ones were there already, just put it to be thorough
<sergiusens> jdstrand wrt bash, I not invoking it directly so no idea
<sergiusens> will need to debug some more
<sergiusens> jdstrand the vscode electron process is running, but I don't see anything on screen; so that's my next issue
<jdstrand> sergiusens: I mean, we could allow /etc/profile.d, but that would just open up whatever is in in there and cause trouble (eg, it adds apps-bin-path.sh which updates PATH which is not what we want)
<jdstrand> sergiusens: I suspect that read on /etc/profile.d is not causing any issues and just noice (but I don't know that)
<jdstrand> noise
<sergiusens> jdstrand --norc is the default if called as /bin/sh so I'll need to dive into the vscode code
<sergiusens> thanks
<zyga> ok, done, pushing
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/1078/commits/c1c084f186a6e747db2d03109206d387760b73a4
<croepha> what do you all use for a text editor on snappy? the best I can come up with is to run nano inside of docker with a mounted volume out to the host
<zyga> croepha: I use vim on my host
<zyga> croepha: I don't hack on snappy itself, I did when we had classic (we're getting classic back soon)
<zyga> croepha: when I had classic I also used vim
<zyga> croepha: don't settle for less :)
<croepha> what is classic?
<zyga> croepha: on snappy you could say "snappy enable-classic" and you got a regular classic, deb-based ubuntu
<zyga> croepha: we removed it before the 16.04 release to polish it before it is brought back
<croepha> ahh ok
<zyga> croepha: it essentially lets you apt-get install anything you need inside snappy in a lxc container that is integrated with the host in a special way (more than a regular lxc ubuntu container would)
<zyga> e.g. apt-get install minicom and use the serial port directly
<croepha> zyga, ahh thats clever, kinda similar to what I was doing with docker
<wililupy> Ok, I installed the .snap on a current system, and when I look at /writables/snap/im-kernel, it has the symbolic links still set to the system I build the snap on... Is that normal?
<sergiusens> zyga another one for you https://bugs.launchpad.net/snappy/+bug/1575399
<ubottu> Launchpad bug 1575399 in Snappy "Half installation for a snap" [Undecided,New]
<zyga> jdstrand: I'm EODing, it was great to work on this but I'm falling asleep now
<wililupy> I rebooted the system, but it didn't boot my new kernel snap...
<zyga> sergiusens: thanks!
<zyga> sergiusens: we're sure we have bugs in install/remove code
<zyga> sergiusens: and in undo code for those bits
<zyga> sergiusens: more testing == faster bug fixing :)
<croepha> Im really new to snappy, just picked it up today, is one of the goals to basically make system upgrades bullet proof? like no issues where you did a dist-upgrade and now you have to get into recovery mode... stuff like that?
<zyga> croepha: among other goals
 * zyga EODs for real, ttyl
<wililupy> later zyga!
<croepha> bye
<wililupy> It's almost like snappy is seeing my kernel snap as a gadget...
<wililupy> It didn't ask to reboot after installing it to make it active...
<jdstrand> zyga: thanks for the PR, I made a nitpick comment but feel free to ignore. thanks and good evening! :)
<sergiusens> jdstrand last one http://paste.ubuntu.com/16072031/ (I hope)
<jdstrand> sergiusens: seems you need 'plugs: [network]' but possibly 'network-bind' for 'shutdown' (assuming this is amd64)
<jdstrand> sergiusens: do you know why it is using the shutdown syscall?
<jdstrand> actually, strike that
<jdstrand> shutdown is in 'network'
<jdstrand> just plugs network
<wililupy> Has anyone successfuly built a kernel snap with snapcraft 2.8.4?
<sergiusens> jdstrand oh, they weren't auto assigned
<sergiusens> jdstrand this is totally weird http://paste.ubuntu.com/16072127/
<sergiusens> ok, back to the known issues
<jdstrand> sergiusens: huh. sounds like a bug. I know I've seen times when they didn't get autoassigned...
<sergiusens> jdstrand I've logged my fair share of bugs today!
<jdstrand> heh
#snappy 2016-04-27
<Domi> Hello, is it possible to use a package form pip in a snap?
<ogra_> sergiusens: nobody reads my mails :(
<ogra_> sergiusens: we are past release, we cant change seeds (unless we apply gross hacks)
 * ogra_ wrote a long mail about that topic, but nobody reacted
<ogra_> i'm not sure how we should add something like nss beyond making up an artificial dep in one of the packages
<sergiusens> ogra_ false warning, not needed
<ogra_> ok
<sergiusens> And not my idea
<ogra_> sergiusens: doesnt fix the base problem though ...
<ogra_> i'm sure the next nss is around the corner :)
<sergiusens> But I did read your email. I wanted you to tell zyga what you just told me ð
<sergiusens> desktop support landed too close to release
<ogra_> i suspect we could make ubuntu-core-config kind of a meta package ... to get such deps in
<ogra_> yeah, it did ...
<sergiusens> And this is what we get
<ogra_> and really broke to much of the IoT side
<sergiusens> You don't say
<ogra_> heh
<ogra_> well, we'll dig our butts out of this ... as we always do :)
 * sergiusens needs a telgram sticker now
<ogra_> hah
<slvn> Hello, I am trying to create my first snap but have some issue. (I already read some doc, and tried the opencv example).
<slvn> I build SDL2 example, with cmake. But it fails to execute as a snap
<slvn> because some shared libs are missing. SDL2 tries to dlopen some libs, like mirclient.so, and probably some other ..
<slvn> should I put all those shared libs into the snap package ?
<slvn> (I think CMake is putting the libSDL2 into the snap package, but not libmirclient.so for instance)
<dholbach> good morning
<dholbach> mvo, wow, you're improving your bug karma :)
<zyga> good morning
<stevebiscuit> https://code.launchpad.net/~stevenwilkin/webdm/use-snapcraft-to-snap/+merge/293053 # should get WebDM in shape to be put back on the store
<mvo> dholbach: hey, good morning. indeed, bug triage ftw!
<zyga> https://github.com/ubuntu-core/snappy/pull/1080
<dpm> hi all - does anyone know if there is a workaround for this error, other than wiping out the whole snap installation again? http://pastebin.ubuntu.com/16075906
<pedronis> dpm: mvo is looking into those kind of issues, how theory is that Notes was running?  that issue is local to the snap so in principle it doesn't need wiping out everything
<pedronis> s/how/our/
<dpm> pedronis, yes, I think it was running at the time of install, but it was on a different workspace and I hadn't noticed it. However, even after closing it the uninstall error remains. If the issue is local to the snap, is there a way to fix it, though?
<slvn> Hello ! My snap package needs to access to X11. but it fails because of apparmor (?). (syslog: apparmor="DENIED" ... operation="connect" ... requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0" peer="unconfined"  )
<zyga> slvn: hey, is the x11 interface connected? can you pastebin your snapcraft.yaml please
<slvn> zyga, probably not since this is my first snap ... http://paste.ubuntu.com/16076031/
<zyga> slvn: no worries, please add this uner "command:", "plugs: [unity7]"
<zyga> slvn: and perhaps add opengl there (after unity7) if that doesn't work still
<zyga> slvn: http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html
<slvn> zyga, seems to work better ! (though I have another error now)
<zyga> slvn: cool, what's the next error?
<slvn> zyga, my first snap tries to use SDL2. but SDL2 can require libmirclient.so or libX11.so. or now libGL.so ... should I all add them to the snap, with cmake. or should I let the snap access the system lib ?
<zyga> slvn: I think you should bundle them but I'm not 100% sure
<zyga> slvn: there are some special provisions for opengl apps
<zyga> slvn: what error do you see now?
<zyga> dholbach: ^^ do you know if those libs should be bundled?
<slvn> zyga, SDL2, has started to communicate with x11. (through libX11.so), now it requires to load libGL.so.
<slvn> it fails because it cannot dlopen libGL.so
<slvn> (btw, cmake doesn't include by itself libX11.so, so I need to make a *fake* call to a x11 lib, so that the libGL.so is include in snap/ ) (maybe there is a correct command to tell cmake to include it ...)
<zyga> slvn: try adding the package that has libgl.so to stage-packages
<dholbach> zyga, I have no idea - dpm: ^ what's your experience?
<zyga> do we have any opengl apps?
<dpm> zyga, dholbach, ubuntu-clock-app, ubuntu-calculator-app and notes all use the opengl interface
<dpm> IIRC they install the required libraries via dependencies in stage-packages
<zyga> https://github.com/ubuntu-core/snappy/pull/1081
<slvn> zyga, now it looks for another lib :/  "libGL error: unable to load driver: swrast_dri.so", "libGL error: failed to load driver: swrast", "DEBUG: Could not create GL context: BadValue"
<zyga> slvn: that tells you it cannot load software rendering for opengl, I think there's some magic you have to do to make it use system-wide opengl libraries (that snappy provides)
<zyga> slvn: but I don't know how this works, sorry, I cannot help you
<slvn> zyga, thanks anyway :) because you fixed me, in 5 min, a few issues I spent 2 hours yesterday
<zyga> slvn: I'll look at SDL/opengl apps more closely soon (~ days)
<zyga> slvn: I'll be blogging about how to snap them correctly
<slvn> zyga, I'll send you my snap package if I can make it work correctly
<zyga> slvn: sure
<wesleymason> Question: is it possible to define post-install hooks in a snap? My problem: pkg_resources in python are incredibly dumb, and usually get generated with full paths in them..which means they end up with the "install" part path on my filesystem embedded at the point snapcraft runs, and completely fails when invoked in the installed snap
<pedronis> wesleymason: no, it's something that snapcraft needs to learn/deal with, maybe a snapscraft bug report could help there
<wesleymason> pedronis: *nod*..might not be entirely possible for snapcraft to fix itself, as some of the pkg_resources import hooks rely on non-rel paths (it's why the --relative option to virtualenv is deprecated and used to break a lot)..and obviously you can't rely on knowing the path a snap will be installed at I don't think
<wesleymason> will fil the bug
<popey> dpm: did you get an answer to your problem of not being able to uninstall a snap if there was a process running, and leaving you in an inconsistent state?
<dpm> popey, I didn't, so I ran the "wipe out the world" script and filed bug 1575550 :)
<ubottu> bug 1575550 in Snappy "Snap removal while snap is running prevents subsequent removal or installation" [Undecided,New] https://launchpad.net/bugs/1575550
<popey> dpm: which wipe the world script did you use? I have seen a few
<dpm> the one you pasted a while ago
<dpm> let me re-paste
 * popey confirms the bug
<popey> it's worse if your app launches a binary which isn't even graphical
<popey> you have no idea it's running without hunting it down with lsof and friends
<dpm> oh, I see, so you don't notice easily if it's running or not
<popey> yeah
<dpm> http://pastebin.ubuntu.com/16076306/ <- that wfm
<popey> i had a random binary called "--debug" running :)
<popey> ta
 * popey saves as nuke_snap_from_orbit.sh
<zyga> dpm, popey: please don't use that
<zyga> use this instead: https://github.com/zyga/devtools/blob/master/reset-state
<zyga> run this script as the pastebin above is incomplete and leaves some stuff behind
<zyga> feel free to spread the link, I maintaing that script to work as snappy evolves
<dpm> thanks zyga - does the system need to be rebooted after runing the script? E.g. for mounts and such
<zyga> dpm: I don't believe so
<zyga> dpm: though if you find a corner case do let me know
<zyga> dpm: and I will gladly take pull requests
<zyga> dpm: to improve on the wording, behavior, etc
<dpm> thanks zyga
<pedronis> zyga: though the goal is not to need the script :)
<zyga> pedronis: hehe :) I wonder if dpkg had a 'wipe.pl' script in the early days ;)
<zyga> pedronis: I fully agree though :)
<zyga> after the first sru the number of breaking bugs will certainly be much lower
<dragly> zyga: You mentioned blogging about it when OpenGL apps are working properly. Where's your blog? I'd like to follow the progress on this :)
<zyga> dragly: zygoon.pl, also on planet.ubunt.com
<slvn> zyga, just to let you know. snap package works when the SDL2 renderer is set as software (no GL libs). Using opengl renderer, libGL.so can't load libswards_dri.so. Verbose log http://paste.ubuntu.com/16076481/
<dragly> thanks
<zyga> slvn: does it work when you install the snap with --devmode (remove it first please)
<zyga> slvn: please report a bug on snappy with the log you see above and with syslog output (journalctl -n 1000,)
<zyga> slvn: we won't "fix" it immediately but it will help us to track it
<zyga> slvn: please include your snapcraft file / sources as well (as links or attachments)
<slvn> Adding --devmode won't help
<slvn> also, I have the swarst_dri in the ./snap/  see : http://paste.ubuntu.com/16076518/
<slvn> I'll report the issue ...
<zyga> slvn: if --devmode doesn't help then you need to tweak your snap to have the right settings to intialize GL (I cannot help there unfortunately)
<zyga> slvn: including, perhaps, more libraries
<seb128> dholbach, is https://github.com/ubuntu-core/snapcraft/blob/master/docs/your-first-snap.md uptodate?
<slvn> zyga, I continue investigating before reporting (or not) the issue. it seem dri/swrast.so is there, but libGL.so is not finding it :/
<slvn> zyga, what does devmode does ?
<zyga> slvn: http://www.zygoon.pl/2016/04/snap-install-devmode.html
<slvn> zyga, ok! strange because with "--devmode" but no plug x11/opengl and no stage package libgl1-mesa-glx, it still cannot find libGL.so.
<pedronis> that's what subset of libs we mount, not a security one
<pedronis> I suspect
<slvn> zyga, still want me to enter a bug report ? (https://launchpad.net/snapcraft ?)
<zyga> slvn: yes please
<dholbach> seb128, it should be - if it's not, that's a bug
<seb128> dholbach, ok, good, just checking before starting reading it ;-)
<seb128> dholbach, thanks
<dholbach> seb128, https://github.com/ubuntu-core/snapcraft/pull/454 is a pending change I know of
<seb128> dholbach, danke
<dholbach> kyrofa, ^ can we land this one soon?
<seb128> dholbach, I started by reading https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md
<seb128> which states
<seb128> "This is the most important selection of tools you will get after installation:
<seb128> snappy try          - try snaps from a .snap, the [stage] or [snap] dir"
<seb128> but "snappy" is command-not-found
<seb128> so I was wondering if the rest was updated
<seb128> going to read more and see if I find issues
<seb128> dholbach, k, that pending change address that one
<slvn> zyga, there https://bugs.launchpad.net/snapcraft/+bug/1575582
<ubottu> Launchpad bug 1575582 in Snapcraft "Snap package, using SDL2, needs access to libGL.so and DRI dependencies" [Undecided,New]
<zyga> slvn: thanks, checking
<slvn> zyga, the attachment is the SDL2 helloworld ..
<zyga> slvn: the attachment looks good, thanks for reporting this
<slvn> zyga, my opinion is that GL libs should not be provided in the snap package. But the SDL2 should require an access to a subset of system libs.
<slvn> when I add the "plug"  unity7, I can get access to mirclient I guess?
<slvn> but when I add the plug "opengl" I dont get access to libGL !
<ogra_> that would be unity8 :)
<ogra_> (there is no expectation for mir on unity7 i thinnk)
<slvn> to get access to libGL, I need to add the stage-package libgl1-mesa
<zyga> slvn: that much is true but which *actual* libraries are provided by the snap and which are provided by the os is tricky
<zyga> slvn: from a particular GL call in your code to, say, nvidia userspace blob doing something is a long path
<zyga> slvn: a similar thing happens with openCL but there it, at least, was designed correctly up front
<slvn> ogra_, yep unity8 :) but that's probably a typo ..  btw, if I put unity8, I get an error at runtime "Bad system call".
<zyga> slvn: so you can query available drivers and pick the right one
<zyga> slvn: there is no unity8 interface yet
<Domi> Hello, how do I pack packages form pip in my snap?
<zyga> Domi: hey, look at snapcraft examples, there are some pip-based python demos there
<slvn> zyga, yep tricky choice of lib to include or not ... Best case: the snap contains only the Application. Worse case: it contains the whole distribution ...
<slvn> how can I know that the "plug" "opengl" do ?
<Domi> zyga: I just see the python example with spongeshaker and github
<Domi> https://github.com/ubuntu-core/snapcraft/blob/master/examples/py3-project/snapcraft.yaml
<zyga> slvn: look at snappy source code, today there's little docs on interfaces
<zyga> slvn: I'm writing some but they are not ready yet
<slvn> zyga, np, I will have a look :)
<Domi> snapcraft snap fails because the python installation. Her is the output http://pastebin.com/GmZB6v4D can anyone help me?
<seb128> can snapcraft.yaml use a dynamic version?
<seb128> like version: "version: `bzr revno`"
<zyga> seb128: nope
<zyga> seb128: not that I know of at least
<seb128> :-(
<_morphis> zyga: you saw my comment about moving the security label building code somewhere else where every interface implementation can consume it?
<zyga> _morphis: no, not yet
<zyga> _morphis: though I think it makes a lot of sense :)
<_morphis> ok
<_morphis> :-)
<zyga> _morphis: I was thinking if n-m would use it
<kyrofa> Good morning
<_morphis> zyga: for sure
<kyrofa> dholbach, I was hoping to wait until snappy was in sync across the desktop and ubuntu core, but perhaps that's not necessary
<loic_m> hi there
<loic_m> I work on a project where I'll have raspberryPis running various applications (deal with a central API, and run a chrome-browser in kiosk mode to display an html app displayed on a screen plugged-in by hdmi)
<loic_m> I'm discovering Snappy and I wonder if it could be a great tool to manage my applications and their deployment accros all the devices
<loic_m> can I have "private" snaps on the store?
<zyga> loic_m: I'm sure you can :-)
<zyga> _morphis: I'm looking at one more thing and then I'll switch focus to n-m
<_morphis> zyga: ok, just moving those bits into a specific function is enough for me, I can adjust the n-m interface implementation then
<sergiusens> kyrofa I have another morning gift for you https://bugs.launchpad.net/bugs/1575628
<ubottu> Launchpad bug 1575628 in Snapcraft ""copy" plugin symlinks whole snap folder when no source is given" [Undecided,New]
<kyrofa> sergiusens, yeah I'm discussing it now in another channel
<seb128> did anyone looked at making snaps load locale .mo translations?
<seb128> dpm, ^ do you know?
<kyrofa> sergiusens, the problem is that built snaps are copied if the source is '.'. Which is a problem with all plugins that accept the source keyword
<seb128> also to get locales generated in the snap
<dpm> seb128, tl;dr, I did, it didn't work
<seb128> did you file a bug about it?
<dpm> seb128, the clock app is an example:
<dpm> it builds and ships the .mo files
<dpm> but the UI toolkit does not find them
<seb128> well, non english locales are not even available right?
<seb128> we would need to generate locales on the core image
<sergiusens> kyrofa yeah, I am not a fan of source: '.'; we could be smarter about this and do a `bzr export`, `git whatever` and then default to a plain copy (depending on the plugin of course)
<seb128> or to include locales in the snap
<seb128> and generate those in some way
<dpm> seb128, for the toolkit, apparently setting https://github.com/sergiusens/qt5conf/blob/master/qt5-launch#L55 should take care of it, but it didn't work. And yeah, good point, if they're not generated, they won't be recognized
<vila> sergiusens: yeah, coverage is not such a big deal for me... as long as you don't block on that ;-) The integration tests cover the parts that the unit test don't
<vila> sergiusens: this is ready to review though
<kyrofa> sergiusens, what does bzr export (or similar) get us?
<sergiusens> vila well we do block on low unit test coverage ;-)
<sergiusens> kyrofa exporting the pure sources without generated artifacts
<kyrofa> sergiusens, assuming the snap is in version control?
<kyrofa> sergiusens, what if we disallowed specifying '.' as the source? We could get rid of the build step's filtering that way
<vila> sergiusens: well, you want me to require a dev setup including sso, sca, cpi and updown servers ? ;-)
<sergiusens> kyrofa yeah, that's why I said, if nothing is possible, default to plain copy (depending on the plugin)
<kyrofa> Ah
<sergiusens> vila I say talk to elopio; he's the master of test; but we mock server requests/responses for these cases in general
<kyrofa> sergiusens, that also means we can't run if one hasn't committed to git (or bzr, whatever)...
<vila> sergiusens: the coverage decreased is caused by the implementation change and by replacing mocked tests by tests against real code
<vila> mocked requests/response bitrot faster than the server evolves, especially here for macaroons
<zyga> http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html
<ogra_> heh, zyga playing doctor :)
<zyga> :-)
<sergiusens> vila so this is not specced? Chipaca are you testing the macaroons implementation with unit tests in snapd?
<sergiusens> vila this is also why we need both in any case, integration tests and unit
<vila> sergiusens: what do you mean by speceed ?
<sergiusens> vila client/server interaction
<dholbach> kyrofa, probably not
<kyrofa> dholbach, alright, I'll write it for the desktop, since that'll be valid soon for ubuntu core
<zyga> dholbach: note, I won't be able to attend the snappy community sync
<kyrofa> sergiusens, alright with you if we get https://github.com/ubuntu-core/snapcraft/pull/454 into the SRU as well?
<vila> sergiusens: it is, that didn't mean there is no bugs (we've fixed several along the way)
<zyga> dholbach: unless you want me to dial-in from a classic mobile
<dholbach> zyga, no worries
<dholbach> dpm, ^ looks like zyga and niemeyer can't make it for the sync
<dholbach> maybe we should set up a separate meeting to discuss interfaces/playpen?
<zyga> I could have otherwise just not today (I learned a moment ago)
<dpm> niemeyer, zyga, would another day this week work better for you?
<zyga> dpm: any, sorry, I'm usually free at this time
<niemeyer_> dpm: Not at this time
<niemeyer_> dpm: I mean, not if the slot is at the same time of the day
<dpm> dholbach, niemeyer, zyga, would tomorrow, 30 mins later than the original time work?
<dpm> I'm looking at the calendars and I don't see any conflicting calls
<zyga> earlier would work, I'm free at all times except for the stand-up call we have right now
<dpm> 1h earlier, then?
<sergiusens> kyrofa yeah, it is fine
<seb128> is plugs security enoug to let a snap access to the network?
<zyga> yes
<zyga> 'network' plug gives you client access
<dpm> zyga, niemeyer, so would tomorrow, 13:30 UTC work for you, right after your standup?
<dpm> dholbach, I'm otp atm, if that works for everyone, would you mind moving the meeting? ^
<niemeyer_> dpm: Yeah, that works
<dpm> excellent
<dholbach> dpm, hohum... that won't work for me
<dholbach> I have an appointment from which I have to get back home
<dholbach> I'd be late quite a bit
<dholbach> maybe I should make that clearer in my calendar
<niemeyer_> dholbach, dpm: Done, thanks!
<dholbach> or hang on
<dholbach> UTC
<dholbach> nevermind
<dholbach> ignore me
<dpm> dholbach, ok, cool :)
<dholbach> sorry, I didn't want to complicate things additionally :-)
<dpm> all good now :)
<zyga> jdstrand: about x11, can we do anything about that untrusted client thing that mjg59 mentioned?
<sergiusens> ogra_ dholbach how would we SRU snapcraft when needed? We have some bug fixes around for a 2.8.5; and later on I'd like to get 2.9 with support for gulp to be able to build some node/electron apps
<ogra_> sergiusens, well, through the normal SRU process
<ogra_> have bugs ... subbscribe the SRU team ... upload to -proposed with the bugs mentioned in the changelog ...
<jdstrand> zyga: its being discussed in another thread. there are options. untrusted isn't likely one of them since it doesn't actually block key sniffing (it only blocks one way to sniff)
<jdstrand> zyga: all options require engineering effort
<jdstrand> zyga: but the main thing is that this is a strategic decision and a transition, and messaging should reflect that
<jdstrand> zyga: and messaging beyond what has been messaged is being discussed with olli, jamiebennett, etc
<dholbach> sergiusens, get all fixes into yakkety first
<dholbach> sergiusens, then file a bug report listing with the stuff that's fixed in the SRU, and add the https://wiki.ubuntu.com/StableReleaseUpdates description to the bug
<dholbach> sergiusens, let me know if you need any help with that
<seb128> jdstrand, hey, can you tell us how snap is blocking syscalls? seems to block "socketcall" on my i386 install for some reason
<ogra_> seb128, via seccomp
<seb128> ogra_, any idea about it blocking "socketcall" on i386?
<ogra_> (there used to be ways to exclude syscalls from it ... not sure that still exists with the switch to interfaces though)
<ogra_> well, it will most likely block creation of system sockets outside of the confined snap area
<ogra_> (you should be able to create session related sockets in your rw space though)
<jdstrand> seb128: via seccomp. the launcher sets up a list of allowed syscalls. you can use 'scmp_sys_resolver ##' on the target system to see what the syscall is
<jdstrand> seb128: you can manually add them to the seccomp filter in /var/lib/snapd/seccomp/profiles/... to temporarily unblock yourself
<ogra_> jdstrand, is there still a way via snap.yaml ?
<desrt> jdstrand: the problem is that the syscalls for individual socket APIs are very new on i386
<desrt> and glibc still doesn't implement them via the new calls
<desrt> so on i386 we need to allow socketcall() for any network access
<desrt> but unfortunately that will also open up bind() listen() etc
<desrt> this is more or less why they introduced the new calls....
<jdstrand> seb128: socketcall is included in the 'network' plug. add 'plugs: [ network ]' to your yaml
<desrt> (for the sake of seccomp)
<desrt> jdstrand: we already have that :/
<jdstrand> seb128: it's possible you have that and it isn't autoconnecting. sergiusens saw that yesterday
<jdstrand> desrt: ^
<jdstrand> I think zyga is aware of the issue
<desrt> really, we need a new glibc...
<ogra_> desrt, just ship it in your snap ;)
<jdstrand> oh, no I lied
<jdstrand> socketcall is commented out
<jdstrand> it is intentionally blocked
<desrt> could we at least get it with network-bind?
<jdstrand> probably
<desrt> if we have network-bind then clearly the whole range of socket calls is OK...
<jdstrand> let me look into it
<desrt> thx!
<jdstrand> for now, to unblock yourselves while I look at that, add it to /var/lib/snapd/seccomp/profiles/...
<desrt> thanks for the help :)
<seb128> jdstrand, thanks
<desrt> you might want to let socketcall() happen for 'network' if we're on x86....
<desrt> on account of the fact that that's probably more reasonable than listing network-bind in every app that uses the network and doesn't want to be aborted on 32bit
<desrt> strictly, it's a leak of additional privilege... but considering the alternative (ie: all apps effectively have to list network-bind everywhere) it seems fairly reasonable
<slvn> quick question, my snap application needs images. I copy them directly in the "./snap" folder and open them with the path "$env(SNAP)/foo.png". Is there a better way to do that ?
<seb128> jdstrand, is there a way to allow dbus communication between unity and confined softwares?
<sergiusens> jdstrand desrt yes, after multiple install/uninstalls will eventually casuse this
<desrt> specifically, unity needs to make a method call, the app needs to reply, and then the app needs to be able to broadcast signals that unity can see
<ogra_> slvn, sounds like an okayish way to me
<desrt> apps also need to be able to own a specific bus name
<slvn> ogra_, ok :)
<slvn> ogra_, maybe a magic CMake instruction, to automate the copy of images to ./snap :/ ?
 * ogra_ would just use the copy plugin to copy the dir 
<slvn> ok!
<kyrofa> slvn, indeed, that's what the copy plugin is for
<sergiusens> dpm can I have comment permissions to your "Snap this!" doc?
<sergiusens> dpm thanks!
<dpm> sergiusens, done
<sergiusens> dpm yeah, I said thanks when I saw I had access :-)
<sergiusens> dpm fully commented, every bullet ;-)
<slvn> ogra_, kyrofa, in fact, I use "install(FILES ${IMAGES} DESTINATION .)"   because COPY copy in build/...
<Trevinho> sergiusens: hey, how can I get snapcraft to be more verbose (or a plugin to be)?
<kyrofa> slvn, ah, we meant the copy plugin in snapcraft
<kyrofa> slvn, but doing it in cmake works as well :)
<sergiusens> Trevinho --debug
<ogra_> yeah, indeed
<slvn> kyrofa, :) well .. since it's now written in the cmakefile .. I'll keep it there..
<sergiusens> Trevinho we still have an action to add --verbose which would enable verbose builds for everything that supports it
<sergiusens> slvn long term, doing it in the build system is the better option
<Trevinho> sergiusens: ok, thanks
<Trevinho> sergiusens: it would be cool
<jdstrand> seb128: sorry, was in several meetings
<Trevinho> sergiusens: also, what if a nodejs package needs to do npm i multiple dirs (like parent and child folder)? adding two parts does work?
<jdstrand> seb128: so, what I told willcooke was that if you give me the snap, I can work through the policy issues and update the unity7 interface security policy
<sergiusens> Trevinho two parts should work
<kyrofa> slvn, great!
<sergiusens> Trevinho what are you doing out of curiosity?
<Trevinho> sergiusens: mh well... it almost does... but then I've an error in looking for files
<jdstrand> seb128: in the meantime, you can temporarily adjust things in /var/lib/snapd/apparmor/profiles/... then add this rule in between the curly brackets:
<jdstrand>   dbus,
<sergiusens> Trevinho I have multiple additions for the nodejs plugin (among those, being able to use gulp as the driver)
<jdstrand> sergiusens: then do: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/...
<jdstrand> err
<jdstrand> seb128: ^
<sergiusens> err
<sergiusens> :-)
<Trevinho> sergiusens: as experiment https://github.com/Aluxian/Whatsie
<jdstrand> seb128: that will allow all dbus calls until you reboot
<Trevinho> jdstrand: the changes are http://paste.ubuntu.com/16081259/
<seb128> jdstrand, thanks
<Trevinho> jdstrand: very hacky though
<jdstrand> seb128: actually, until snapd updates the file, which I think is on reboot but might happen every 12 hours
<Trevinho> there are hardcoded archs... or
<Trevinho> cahce files with are not generated
<Trevinho> cache*
<jdstrand> oh, you are doing this on i386 and not amd64?
<seb128> jdstrand, the pastebin from trevinho are our hacks from the day
<seb128> I am
<seb128> my laptop is 6 years old never reinstalled
<jdstrand> I see
<jdstrand> I could easily adjust locally
<sergiusens> Trevinho you might want to wait for my gulp branch
<seb128> but we have people who tried on amd64
<Trevinho> well, yeah... but also in a brandnew VM things do the same
<seb128> right
<jdstrand> Trevinho: that is a diff to my junk branch?
<seb128> sergiusens, gulp?
<Trevinho> sergiusens: ah, ok...
<Trevinho> jdstrand: yes
<seb128> jdstrand, yes
<jdstrand> ok, I have another meeting in a few minutes but will start playing with this after
<seb128> sergiusens, are you telling us we shouldn't have started working on a gnome example because we dup work with you?
<sergiusens> seb128 no, I am talking to Trevinho ;-)
<seb128> jdstrand, k, we are mostly done for today here
<Trevinho> jdstrand: this is for x86-64 http://paste.ubuntu.com/16082479/
<Trevinho> jdstrand: and... you need to copy there /usr/share/mime/mime.cache
<sergiusens> seb128 carry on with gtk :-)
<seb128> sergiusens, well, Trevinho is with us at a team sprint where we collectively work together
<sergiusens> seb128 oh, well he is looking at a nodejs project
<seb128> ah ok
 * Trevinho too
<seb128> so other thing :-)
<ogra_> jdstrand, you should just declare it "notabug" and blame seb128 for skipping laptop refreshes twice already :P
<jdstrand> ah yes the loaders cache. I would've forgotten about that
 * Trevinho multi-tasking
<jdstrand> Trevinho: thanks!
<jdstrand> ogra_: hehe
<sergiusens> seb128 and I've just added gulp support (a nodejs build driver) to the nodejs plugin
<sergiusens> still missing grunt
<seb128> jdstrand, we got gnome-calcultor to work including icons and exported menus and theme (unrestricted), in restricted menus are missing
<jdstrand> seb128: willcooke said something about you guys pushing a branch somewhere at some point. can you ping me whenever that happens?
<sergiusens> and the G is not related to glib, gtk or gnome :-)
<jdstrand> sergiusens: that is great! I have some policy for menus but lacked an app to verify it
<seb128> jdstrand, sure, I need to clean up the diff in the pastebin and replace the arch encoded bits
<jdstrand> darn it
<jdstrand> seb128: ^
<seb128> k
<seb128> great :-)
<seb128> jdstrand, we hope that the "have to ship precompiled cache, pixbuf loaders, etc" is going to get replaced by proper solutions over time though
<ogra_> be introducing postinst in snaps ?
<seb128> that wouldn't help
<Trevinho> sergiusens: however, in these cases, I should do a custom plugin or is there another way to run gulp? Actually it seems to build the src though
<seb128> you don't want each app to ship the glib locales and have to do e.g locale-gen
<Trevinho> sergiusens: the only thing I did was a simple http://pastebin.ubuntu.com/16082644/
<jdstrand> seb128: oh for sure. that is rather icky. but one step at a time :)
<jdstrand> seb128: curious if you think that means changes to gtk to support snaps (whether that is a plugin or something else)
<seb128> jdstrand, are we going to recommend upstream to copy our hacks to include gio, etc caches?
<jdstrand> seb128: no, I mean design a solution that can work with it
<jdstrand> basically, I'm curious if you have ideas on what the proper solution will be
<seb128> well it's a design choice
<Trevinho> sergiusens: but then I get something like
<Trevinho> https://www.irccloud.com/pastebin/1tASMLIM/
<seb128> I think e.g image loaders should be part of the core
<seb128> not something appdevs are interested to have a custom copy of
<jdstrand> seb128: I would tend to agree. ie, ubuntu personal has all these kinds of things, like how touch does
<seb128> right
<seb128> then things like schemas, etc we need to resolve
<ogra_> seb128, i really dont want image loaders in my IoT device :P
<seb128> that's why you would install core and not personal
<ogra_> (unless its some camera IoT think perhaps)
<jdstrand> seb128: now whether that is a separate os snap or a special snap that works with the os snap, idk. that is for the architects to decide
<seb128> right
<jdstrand> ok
<ogra_> i guess we need some low level library snap from canonical that provides the bits and pieces
<Trevinho> and... with other files... Here's the deubg output
 * ogra_ would have it called a framework snap :P
<Trevinho> https://www.irccloud.com/pastebin/1dNpAbUr/
<Trevinho> ogra_: yeah, a framework for gtk/gnome is really needed...
<ogra_> except that we killed frameworks with snappy 2.0
<ogra_> (thus the :P above )
<Trevinho> yeah, that's what I was worried about....
<Trevinho> so, we're going to ship a 66Mb snap for the calculator, and other hundreads of apps?
<Trevinho> ogra_: ^
<ogra_> and buy stocks of some SSD manufacturer, yeah
<Trevinho> al least if deduplication was still something we cared about...
<ogra_> (i know the prob is known ... but the former solutions were abandoned .... not sure whats in the pipe for that in the future )
<oparoz> library snap?
<ogra_> that only helps within one namespace
<ogra_> per definition
<oparoz> I thought the goal of the library snap was to offer common tools and space?
<slvn>  Got an apparmor issue "shm_open() failed" when initializing audio. Syslog: apparmor="DENIED" operation="open" name="/dev/shm/pulse-shm-4267673202
<seb128> jdstrand, sergiusens, ogra_, do we have a plug for sound?
<ogra_> oparoz, withing your namespace, yes
<ogra_> seb128, not yet ...
<oparoz> ogra_, what do you call the namespace? dev ID?
<slvn> :(
<ogra_> oparoz, yes
<oparoz> ogra_, makes sense
<kyrofa> slvn, I don't think we have any audio interfaces yet. I think zyga is working on it
<slvn> kyrofa, ok np, I will just skip the audio initialization for the moment ..
<jdstrand> seb128: not yet. zyga and I discussed it a bit yesterday but need niemeyer_'s input
<ogra_> just deliver some sheet music alongside your app ...
<seb128> k
<jdstrand> this is again, due to not having a working snap
<seb128> well no need of that for calculator
<seb128> I've just been playing a bit more, including pulseaudio in a snap and trying paplay
<jdstrand> seb128: is there an app that is using it?
<jdstrand> I see
<jdstrand> seb128: so there are two things at play here (fyi niemeyer_): 1) a pulseaudio snap that works on core proper and 2) pulseaudio access for snaps on classic
<jdstrand> I foresee the policies to actually be different
<_morphis> jdstrand, awe_: updated https://github.com/ubuntu-core/snappy/pull/1036 today, would be great if you guys can have another look
<jdstrand> so we need to work out if for the transition perid of snaps on classic if pulseaudio should just be included in unity7 or maybe a new unity7-audio, and then have the pulseaudio interface for a pulseaudio snap
<jdstrand> seb128, niemeyer_: ^
<seb128> jdstrand, right
<jdstrand> niemeyer_: perhaps you have other opinions. personally, I'm leaning towards unity/unity7-audio
<jdstrand> niemeyer_: but I'm totally open to other options
<jdstrand> s#unity/unity7-audio#unity7/unity7-audio#
<seb128> do we have an human-description of the current plugs?
<_morphis> jdstrand: sounds good to me as we will use an actual "pulseaudio" interface for the real pulseaudio snap we're doing for core
<jdstrand> seb128: in docs/interfaces.md. that will be updated on the website in the coming days
<seb128> _morphis, how is that going to work? does it mean an app that needs audio is going to be able to depends on the pulseaudio one?
 * ogra_ wonders if such a setup can even work when pulse runs as a session thing (vs a system daemon)
<slvn> also .. SDL_Init(SDL_INIT_JOYSTICK) will say "Can't init SDL JOYSITCK:  Could not initialize UDEV:
<_morphis> seb128: for ubuntu-core not desktop we're going to make an pulseaudio snap
<ogra_> i assume the pulse snap will spawn a system process ...
<ogra_> (have to)
<seb128> _morphis, but can snaps have depends on other snaps/share resources?
<jdstrand> _morphis: yes. are you guys planning on picking up diwic's work? /me notes that the pulseaudio discussion applies equally to network-manager and bluez
<_morphis> which will use a "pulseaudio" itnerface to provide slots for other snaps to connect to
<seb128> we start having frameworks then?
<jdstrand> seb128: no, frameworks are dead
<_morphis> jdstrand: we do but its the last item in the list
<ogra_> we just abandoned them :)
<_morphis> seb128: the only thing you need in your app is a plug using the "pulseaudio" interface
<seb128> _morphis, then installation your application would install the other snap?
<_morphis> and for sure a client lib inside your snap to connect to pulse
<seb128> e.g sort of depends?
<ogra_> no
<ogra_> no depends
<ogra_> the interface would simply not be there and you wouldnt get sound
<seb128> so your users might get sound working or not
<ogra_> yeah
<_morphis> yes
<seb128> "great"
<seb128> :-)
<jdstrand> seb128: instead there are interfaces. a pulseaudio interface can be used on the slot side (server) or the plugs side (client). a pulseaudio snap would declare it provides the pulseaudio slot for apps to connect to. clients declare to use the pulseaudio slot. then UX defines how to surface snaps that plug pulseaudio if you have the pulseaudio snap installed or not (ie, the slot is available for use)
<jdstrand> s/clients  declare to use the pulseaudio slot/clients declare to use the pulseaudio slot via 'plugs'/
<_morphis> seb128: could be that we do different pulseaudio itnerface for different use cases if we have to limit certain aspects for security reasons or so
<seb128> jdstrand, any dev/snap is going to be able to provide slot side?
<jdstrand> seb128: that is a pure ubuntu core system. not sdoc
<ogra_> _morphis, well, i'm still curious about system daemon vs session daemon ...
<_morphis> ogra_: I suspect we will only have a system instance on core
<ogra_> today every user has his own pulse daemon on a per session base
<jdstrand> seb128: yes, but if you are declare a slot and the slot is deemed dangerous, then the snap will be flagged for manual review (eventually handled via assertions)
<jdstrand> seb128: today, all snaps that declare slots are flagged. that will evolve
<awe_> ogra_, sure and every user has it's own obexd
<jdstrand> seb128 (and niemeyer_): as for pulseaudio on sdoc, you can see that there is an interplay there that we need to consider. the ubuntu-core os snap doesn't provide pulseaudio, but it is magically provided by how snappy on classic is implemented. and the pulseaudio on classic is different (and would certainly conflict with) a pulseaudio snap
<awe_> ogra_, for snappy, this was changed to work on the system bus
<jdstrand> so there are questions to be solved
<awe_> ogra_, not saying it won't take work...
<jdstrand> answered*
<ogra_> awe_, well, if i look at NM i have a proper split ... might make sense to have that everywhere
<awe_> not sure what you mean?
<awe_> by NM split?
<seb128> jdstrand, thanks, direction looks good :-) it just feels weird that a dev can't declare that his app requires e.g an audio slot
<ogra_> NM has a system process and a session process ...
<ogra_> pulse currently doesnt allow that
<seb128> jdstrand, it means device users might be able to install video player and not be able to get sound which makes the app looks buggy
<jdstrand> slvn: as for joysticks-- that is going to need an interface. once you figure out what it is that need and perhaps how to get there, please file a bug against snappy and add the snapd-interface tag
<awe_> ogra_, there's only one NM
<awe_> and it's system
<jdstrand> seb128: apps do declare it. eg, a game might 'plugs [ network, unity7, pulseaudio ]'
<ogra_> awe_, but there is a system wide daemon and there are user-session clients using it
<awe_> sure, and on snappy.. there'll be a system-wide daemon, and one or more snaps using it via interfaces
<jdstrand> seb128 (and niemeyer_): in the pure ubuntu-core system. in the sdoc system, maybe that is 'plugs: [ network, unity7 ]', maybe 'plugs: [network, unity7, unity7-audio ]', maybe something else (that is the discussion
<ogra_> awe_, right, but thats not how pulse works atm
<ogra_> it hogs the device from userspace via a session daemon
<jdstrand> niemeyer_: note, I'm effectively CCing you on the conversation but not because we need to have it this second, just so that you have context in the future conversation
<awe_> jdstrand, can snaps be restricted from running on a sdoc system?
<seb128> jdstrand, thanks
<awe_> I don't see any possible use case for a NM snap to be installed there
<jdstrand> awe_ (and niemeyer_): there is no mechanism for that atm afaik. I guess you are thinking about blocking network-manager from an sdoc system. that is something else to consider for sure (and I think niemeyer_ may be thinking about that already)
<jdstrand> awe_ (and niemeyer_): it sorta feels like ubuntu-core os snap should only expose certain interfaces on sdoc (eg, unity7, x11) and filter other (network-manager, bluez, pulseaudio, etc). that needs to be worked through
<awe_> yea, I've seen enough odd requests to make NM co-exist with other pseudo 'network-managers', but two NMs on the same device seems a super bad idea
<awe_> jdstrand, +1
<jdstrand> indeed :)
<ogra_> awe_, if you hide it and someone is insane enough to upload a wicd snap to the store you get into the same trouble though (and you might not have any control over the person providing the wicd one to sdoc)
<ogra_> sounds like a very tricky problem
<jdstrand> I think snappy could handle that
<jdstrand> ie, wicd would need an interface too
<jdstrand> so if network-manager was installed, wicd would not be available
<ogra_> well, some standard network-device-access thing
<jdstrand> and vice versa
<jdstrand> if neither were installed, both would
<ogra_> jdstrand, i'm talking about hiding NM on sdoc
<awe_> well... out interface is *very* specific to NM
<ogra_> you wont block people from pushing other stuff that breaks this
<awe_> I suppose a wicd snap might be able to use it
<awe_> however if wicd provided a DBus API it wouldn't work
<awe_> but in the end
<ogra_> (and you wouldnt block me from providing a naetwork-manager.ogra either)
<slvn> jdstrand, I'll debug the joystick (and fill a bug report if needed) another day  :)
<awe_> if they do all the work to create a wicd iface
<awe_> then they can upload right?
<awe_> and we have the same conflict problem on an sdoc system
<ogra_> thats my point :)
<awe_> I think if any package is valid example
<awe_> it's be commman
<awe_> s/it's/it'd/
<jdstrand> the idea with interfaces is that they are a sort of contract
<awe_> unfortunately bound a little too tight IMHOP
<jdstrand> if something declares it provides the slor for network-manager, it is network-manager to any clients that connect to it
<jdstrand> so if wicd can't do that, it needs its own interface
<awe_> right, definitely not usable to any other package
<awe_> ...but to ogra's point
<awe_> there's no reason why we wouldn't upload a connman snap at some point
<awe_> and it would have the same issues on an sdoc system
<jdstrand> yes
<ogra_> right ... so how would you filter all of these snaps ... you cant just only forbid n-m on sdoc
<jdstrand> that will need to be discussed
<awe_> the question is where's the line... do we assume people won't do such dumb things, or do we need to add a mechanism to prevent?
<jdstrand> but connman would have its own interface, so it could be added to the filter
<jdstrand> (on an sdoc system)
<awe_> right
<jdstrand> (if that is how it is implemented)
<awe_> I mean we are reviewing
<ogra_> someone would have to maintain all these filter rules then
<ogra_> that might become a huge thing
<jdstrand> maybe
<ogra_> given that anyone can invent interfaces
<jdstrand> no
<jdstrand> all interfaces go through ubuntu core
<ogra_> for the client side ?
<jdstrand> a snap can't ship an interface
<ogra_> ah, i thought i can offer a foobar interface to others when i package foobar
<jdstrand> it can only implement it (it slots) or consume it (it plugs)
<awe_> but it's all in the one interface added to core
<jdstrand> Ubuntu Core controls the types
<ogra_> ok
<jdstrand> the types are bluez, network-manager, wicd, connman, pulseaudio, etc
<awe_> wicd??? really?
<jdstrand> you can p[rovide an implementation (slots) that uses that type
<jdstrand> awe_: wicd isn't there now. I was just creating a list based on this conversation
<jdstrand> ok, I have a meeting
<awe_> are we going to provide oss too?
<awe_> thanks jdstrand
<awe_> ttyl
<_morphis> ogra_, awe_: we can run pulseaudio easily as system daemon
<_morphis> pulseaudio --system is all you need
<ogra_> _morphis, i thought there were mutil-user reasons to do it the way we do it today
<_morphis> ogra_: sure
<ogra_> like ... not freeing up the interface when you switch users etc
<_morphis> ogra_: on a multi user system you really don't want --system
<ogra_> right
<_morphis> but on a ubuntu-core system you do
<_morphis> as we don't have multiple users there anyway
<awe_> _morphis, that's what I said earlier
<awe_> just like we do with obexd
<_morphis> yeah
<_morphis> we will do this with all daemons we're putting on ubuntu-core
<_morphis> no session bus
<awe_> again, we may need to run things differently on core
<awe_> this is all new ground
<jdstrand> _morphis: you mentioned pulse as last on the list. what is the list? I know bluez nm and pulse
<_morphis> jdstrand: nm, bluez, ofono, modemmanager, pulseaudio
<jdstrand> cool
<jdstrand> thanks!
<_morphis> jdstrand: which includes interconnections between them
<awe_> and possibley "rild"
<_morphis> like we need the nm snap to work with both ofono and modemmanager
<awe_> but we may just bundle as part of ofono
<_morphis> jdstrand: ah not to forget location-service
<awe_> still tbd
<seb128> calling it a day here
<seb128> good evening everyone
<seb128> jdstrand, I'm going to clean up things and push tomorrow morning
<jdstrand> seb128: thanks! hopefully once I'm done with my meetings today I can play with the paste
<jdstrand> seb128: have a nice evening :)
<seb128> cool, let me know tomorrow or it goes (or feel free to drop an email
<seb128> thanks
<seb128> see you tomorrow!
<ogra_> _morphis, user management is on the TODO for core ... so i wouldnt count on single-user-forever
<awe_> for s16?
<awe_> that's all we care about atm
<awe_> can't worry about future problems yet
<awe_> ;)-
<ogra_> i know mark is pushy to get rid of the ubuntu user
<ogra_> but i dont know if for 16
<qengho> Er, should sound work from within a snap? Should one use pulseaudio client libraries?
<ogra_> LOL !!!!
<ogra_> looks like someone missed all the fun of the last 2h backlog in this channel :)
<ogra_> qengho, no audio yet
<qengho> Oh. I did. I saw "kodi" had new release, thought I'd try something ambitious.
<geneios> Hi guys, I have a question about the python2 plugin. Is there a way to tell the setup.py to include a path? i.e I have a package that depends on a certain numpy version, which requires python-dev, but the path Python.h from python-dev isn't getting included.
<ogra_> qengho, if you are really ambitious, try it with Mir as standalone snap ;)
<niemeyer_> jdstrand: Sorry for not paying too much attention to the conversations this morning
<niemeyer_> jdstrand: Have been in calls for the last several hours
<niemeyer_> jdstrand: I think we want network-manager to be a slot offered by ubuntu-core itself in sdoc
 * niemeyer_ => late lunch
<slvn> Install a snap package once, it works fine. But twice (event with version increment), it says : /bin/sh: 0: Can't open /snap/myapp/100002/command-example.wrapper
<jdstrand> niemeyer_: no worries at all, I was in calls all morning before that, so, I can relate. mostly I wanted you to be aware of the conversations
<jdstrand> niemeyer_: I can say that if network-manager is a slot in sdoc, then we are going to want to consider different slot and plug policy depending on if running on sdoc or not
<jdstrand> niemeyer_: in fact, we'll have to cause the security label for network-manager will be 'unconfined' on an sdoc system whereas on a pure core system it will be 'snap.network-manager...'. I know there will be different policy for pulseaudio too
<jdstrand> niemeyer_: anyway, we can discuss at a more convenient time
<zyga> jdstrand: I wasn't aware of issues specific to i386, is there a bug open on this?
<wililupy> So who is a good Snappy Kernel expert?
<niemeyer_> wililupy: It's generally easier to shoot question and see who picks it than to fish for self-appointed experts :)
<wililupy> That's true. niemeyer_
<ogra_> wililupy, ricmm or asac perhaps (asac wrote the basic plugin, and i know ricmm used it quite a lot in the past)
<wililupy> I'm hitting a brick wall when my kernel snap. I can get it to build, but when I try to boot it fails.
<ogra_> how does the boot fail
<wililupy> I've made it work in the past, but since 2.5 I haven't been able to get one to boot.
<ogra_> what are the symptoms then
<wililupy> When I use it as the kernel in u-d-f it won't boot. It starts grub, I see writable, it tries to boot and I get error: not a regular file
<wililupy> error: disk 'loop' not found
<ogra_> ohm that grub thing
<wililupy> error: you need to load the kernel first and then back to the grub menu
<ogra_> i remember ... but have not much more help to offer ... apart from ... make sure your kernel has all bits builtin the ubuntu kernel also uses
<ogra_> the ubuntu kernel has loop device support built in
<wililupy> If I install the .snap in a working instance, it installs, but never boots to that.
<wililupy> I verified that, it is a module.
<wililupy> I'm basically using the 4.4.0-21-generic config
<ogra_> ogra@styx:~$ grep DEV_LOOP /boot/config-4.4.0-21-generic
<ogra_> CONFIG_BLK_DEV_LOOP=y
<ogra_> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
<ogra_> CONFIG_AUFS_BDEV_LOOP=y
<ogra_> not a module here
<ogra_> so i'd start there :)
<wililupy> This is what I have.
<wililupy> CONFIG_BLK_DEV_LOOP=y
<wililupy> CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
<wililupy> CONFIG_BLK_DEV_CRYPTOLOOP=m
<ogra_> ok
<wililupy> CONFIG_AUFS_BDEV_LOOP=y
<ogra_> and you have the squashfs module in your initrd modules ?
<wililupy> in my snapcraft.yaml yes.
<wililupy> I tried adding loopback, but snapcraft failed to build with that option so I removed it.
<ogra_> (and you also build it i assume )
<wililupy> Yep. Snapcraft builds successfully.
<wililupy> I also have this in my config file for squashfs:
<wililupy> CONFIG_SQUASHFS=m
<ogra_> right, else snapcraft would fail
<wililupy> CONFIG_SQUASHFS_FILE_DIRECT=y
<ogra_> (trying to add a nonexisting module to the initrd)
<wililupy> CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y
<wililupy> CONFIG_SQUASHFS_XATTR=y
<wililupy> CONFIG_SQUASHFS_ZLIB=y
<wililupy> CONFIG_SQUASHFS_LZ4=y
<wililupy> CONFIG_SQUASHFS_LZO=y
<wililupy> CONFIG_SQUASHFS_XZ=y
<jdstrand> zyga: wrt i386> I didn't mean to refer to that. I meant the fact that autoconnect doesn't seem to always work. I noticed it, sergiusens did, seb128 did, kgunn may have, etc. I don't have a reproducer. sergiusens thought it might have to do with uninstalling/installing the same version over and over again
<zyga> hmmmmm
<zyga> interesting
<zyga> there is a mechanism that blacklists auto-connection
<zyga> I'll add logging there so that at least we can know it is responsible
<jdstrand> zyga: for example, I've had 3 different pings on things in the network policy that people were hitting, but they plugged network
<wililupy> I've used this config in the past with this same kernel and it worked.
<zyga> jdstrand: there's a bug (now fixed) in 2.0.2 that makes upgrades 100% broken
<zyga> jdstrand: until we SRU we'll see plenty of intertwined bugs
<jdstrand> perhaps its that
<ogra_> wililupy, and you use the very latest u-d-f ?
<jdstrand> zyga: though I think kgunn needs some help which looked like a locking issue. he sent an email last night
<zyga> jdstrand: oh? I need to check
<jdstrand> zyga: note, I answered kgunn's final slots question in a hangout today
<wililupy> ogra_ yes.
<zyga> ok
<zyga> was the hangout recorded?
<ogra_> and also the canonical-pc gadget from the "16" series in the store ?
<wililupy> I updated it yesterday just to be sure.
<wililupy> yes, my u-d-f is sudo ./ubuntu-device-flash core 16 --channel=edge --kernel=my-kernal.snap --gadget=canonical-pc --os=ubuntu-core -o my-snappy.img
<ogra_> yeah, that should be all fine
<zyga> jdstrand: I see his email now, I'll work on that next
<wililupy> However, if I install the snap in the base snappy instance, it installs, I can go to /writable/snaps/my-kernel/ and everything is there, but the system never boots to it, it still says 4.4.0-18-generic instead of 4.4.6 when I do uname -r
<jdstrand> zyga: cool. fyi, I think I finally have some time to do some policy updates. I have around 10. it would be easiest for my to group at least some of them in the same PR, but is there a commit policy where I need them all separate?
<zyga> jdstrand: that's up to you, a branch with 10 commits with descriptions is perfect for mew
<zyga> me*
<jdstrand> that'll work
<jdstrand> thanks!
<zyga> jdstrand: but if you think it would be easier to review separate branches I'm fine with that as well
<wililupy> And i do that with just scping the .snap to the system, and running sudo snap install my-kernel.snap and it shows up with snap list
<ogra_> wililupy, well, you should see why it doesnt boot on the console ... does it actually attempt to boot and just fall back to the other kernel ... does it not attempt the new one at all etc
<wililupy> It doesn't even attempt the new one.
<wililupy> No rollback error or anything.
<ogra_> right, not sure sideloading lkernel snaps still works with 2.x
<ogra_> but it should definitely work with u-d-f
<ogra_> i fear you need mvo ... i'm not really good with the grub mishmash we have on the images (it is quite a mess)
<wililupy> Thats fine ogra_, when does mvo come on?
<ogra_> i think he ended his day (i'm not on the internal channel atm, see if you find him there perhaps)
<wililupy> He's not on the internal channel atm.
<ogra_> yeah, thought so
<wililupy> I'll send him a quick email and see if he has any pointers. I'm getting close to my deadline with this device and I want to be able to give them something besides a procedure that doesn't work.
<ogra_> i think wed. is his hockey day
<zyga> kgunn: hey
<zyga> kgunn: I'm looking at your branch
<almejo_> Hi.. someone has time for a question about packaging a snap app?
<MichaelTunnell> almejo_: wont know until you ask your question?
 * zyga was about to reply with the don't ask if you can ask, just ask
<MichaelTunnell> :)
<zyga> kgunn: just FYI, you probably saw this already but just in case: http://www.zygoon.pl/2016/04/anatomy-of-snappy-interface.html
<kgunn> zyga: nope, so i'll read that in a moment
<zyga> nothing revolutionary there :)
<ChrisTownsend> Hi!  I guess I need to get the security team's input on https://bugs.launchpad.net/snapcraft/+bug/1575188 ?
<ubottu> Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,Incomplete]
<almejo_>  haha.. thanks. I am trying to package a qml app. It is written in python for the phone. I am traying to figure out the dependencies and I can not find an example of how to do it.. i found something about a qml plugin but it is not listed in snapcraft list-plugins
<ChrisTownsend> Comment #5 hopefully explains my use case.
<almejo_> My last output from starting my app is "qmlscene: could not find a Qt installation of ''"
<almejo_> in stage-packages i have: qmlscene, libxcb1, libqtcore5a, libqtgui5, libqtgui5-gles, libpulse0
<jdstrand> beuno: hey, can you have someone pull r638 of the review tools for opengl bug #1572140
<ubottu> bug 1572140 in Canonical Click Reviewers tools "click-reviewers-tools don't know opengl interface" [Medium,Fix committed] https://launchpad.net/bugs/1572140
<sergiusens> jdstrand this is for you https://bugs.launchpad.net/snapcraft/+bug/1575188
<ubottu> Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,Incomplete]
<sergiusens> jdstrand even thought it will eventually build, not sure it would be a good idea as the next step would be to block it
<sergiusens> jdstrand as in for you, waiting for your input
<sergiusens> almejo_ look at dpm's clock app work
<beuno> jdstrand, sure. cc/ roadmr ^
<jdstrand> sergiusens: yes, I added it to my list of things to look at this week
<roadmr> beuno, jdstrand : no problem, I'm on it
<jdstrand> roadmr: thanks!
<jdstrand> roadmr: fyi, that has no code changes, just a change to a data file for the store to consume (not sure how far back the store is at this point, so maybe it is a super fast pull-- up to you)
<almejo_> sergiusens Â¿dpm clock? the one in snap find? The phone clock?
<roadmr> jdstrand: we're at 636, have been since Monday
<jdstrand> oh yes
<almejo_> I would love to see the snapcraft.yaml of the app
<jdstrand> then this is fast
<roadmr> jdstrand: yes :) it's just a matter of negotiating the test -> land -> CI -> staging -> production pipeline
<jdstrand> roadmr: not sure what your processes are, but extremely low risk
<jdstrand> ack
<jdstrand> I'll leave it in your capable hands :)
<roadmr> jdstrand: so I point a config file to the desired revno, commit, wait ~40 minutes for it to be on staging, test manually, if all is OK request a prod deployment
<jdstrand> nice
<roadmr> jdstrand: (btw, my manual test is just uploading a package and checking the c-r-t version reported is the expected one. If ever you want more detailed testing, let me know, I can check for more specifics if needed)
<jdstrand> roadmr: ack, good to know
<sergiusens> almejo_ yeah, clock or calculator, I forget
<almejo_> I know the apps and I can browse de app.. but I can not find the snapcraft.yaml. It seems that it is not part of the project...
<ogra_> http://bazaar.launchpad.net/~snappers/snappy-desktop-examples/trunk/files/head:/ubuntu-clock-app/
<sergiusens> almejo_ this might be an abandoned branch, but here you go bzr+ssh://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/
<almejo_> thanks!!! exactly what i was looking for!
<almejo_> thanks for your time :D
<sergiusens> almejo_ the `environment` part can probably replaced by an `after` like in https://github.com/dplanella/snappy-playpen/blob/master/notes/snapcraft.yaml
<almejo_> thanks again
<sergiusens> np
<zyga> roadmr: hey
<zyga> roadmr: I'll be in canada next week
<roadmr> hello zyga !
<zyga> next +1
<roadmr> zyga: awesome! it's across the country from me
<zyga> roadmr: yeah, I tried to have a 24 layover in montreal but no luck
<roadmr> zyga: :( well bummer, but I've heard good things about where you're going :)
<roadmr> zyga: (I've never been there - maybe some day)
<roadmr> zyga just vanished haha
 * zyga always suspends with some darn shortcut when switching keyboards 
<zyga> roadmr: are you sprinting anytime soon? I heard that some people from your team are going too
<roadmr> zyga: yes! not me though, sorry :( recently-arrived baby means I have to stay here and help
<zyga> ah, the fantastic and terrible things that await you :)
<zyga> I'm trying to convince my son to finish his english homework :-/
<roadmr> zyga: yes, he's 3 months old and it's felt like 5 minutes... (underwater haha)
<zyga> he loves spanish, doesn't digest english
<zyga> it gets easier after three years
<roadmr> zyga: YEARS!?! NOOOO /o\
<zyga> ...after they move out ;-)
<zyga> oops, weren't supposed to tell you so quickly ;)
<roadmr> zyga: http://theoatmeal.com/pl/minor_differences4/kids
<zyga> ohhh yes
<zyga> I know that by the URL :D
<roadmr> :)
<zyga> reality is much worse
<zyga> much more subtle :)
<roadmr> yeah heh
<roadmr> zyga: I didn't tell you - *I* was doing it wrong, that's why I couldn't build the image, remember I had that weird "0 partitions found" error?
<zyga> roadmr: yeah, what was the problem?
<roadmr> zyga: it's because I was trying it inside an lxc. Once I did it natively, it worked.
<zyga> ah, yes, I head that people bumped into this before
<zyga> layers of layers of software
<roadmr> zyga: I've also been unable to snap install inside an lxc, even with a privileged, nesting container. I wonder if we'll ever want snap to work inside containers, I imagine so :)
<zyga> I wonder if it is because of older kernel or because of something that lxc does itself
<roadmr> zyga: it's a xenial system so I don't think it's an old kernel :D
<zyga> roadmr: I know this too, this will need lots of work on the kernel and snappy side first
<zyga> roadmr: apparmor namespaces are required first (those are under way as the security savvy people tell me)
<roadmr> yay :)
<zyga> roadmr: right now kvm works very well but lxc won't for 16.04
<roadmr> zyga: yes, I'm running stuff under virtualbox and/or kvm for snap work
<zyga> roadmr: running natively on xenial is also an option, it's usually not a disastrer if it breaks
<roadmr> usually? /o\ haha :)
<zyga> no bank account interface yet ;)
<roadmr> 'show-me-the-money' as a plug?
<zyga> no, that's flashlight app 2.0
<zyga> "flashlight needs access to your bank account, allow or deny?"
<roadmr> haha :)
<zyga> next to the "deny" button there is a nice animated icon saying "don't miss out on mr flashy"
<zyga> nah, that was android
<zyga> we're better :)
<sergiusens> zyga roadmr lxc and u-d-f might just probably fail due to kpartx and needing access to kernely things to map that
<jdstrand> zyga and roadmr: fyi, a lot of work happened with what is called apparmor stacking to support just that. it didn't all land by 16.04 release, but we hope to have enough of it completed by 16.04.1 so that you can run one level deep. Ie, running a full system (ie Ubuntu Core) in lxd so you can install snaps. however, running lxd inside of lxd or snappy in lxd on ubuntu core will not be supported since those required 2 levels deep
<jdstrand> tyhicks: please correct me ^
<roadmr> jdstrand: cool!!
<jdstrand> zyga and roadmr: when implemented nesting > 1 may be possible to backport to 16.04, at least with a backport kernel
<roadmr> jdstrand: yes, I imagine if we're to push snaps as a format going forward, it makes sense to ensure they work inside lxd, which we're also pushing :)
<jdstrand> yes
<roadmr> jdstrand: not sure "all the way down" will be so useful, but at least one level deep should be
<jdstrand> people will then want to run snappy in lxd on snappy, but that is a bit farther out. it requires upstream kernel changes and a few other things
<roadmr> jdstrand: thanks for the info! at least I know this is known and I'm not crazy :)
<jdstrand> it is very much known and you are not crazy
<jdstrand> at least not because of this ;)
<tyhicks> jdstrand: I think "snappy in lxd on ubuntu core" should only require 1 level deep container
<jdstrand> tyhicks: well... remember, lxd will be running under a label that is not unconfined
<jdstrand> tyhicks: I'm not sure how that plays into it, but snappy in lxd on snappy would certainly be nice to have in 16.04
<jdstrand> tyhicks: I guess it would be one level though cause lxd is still in the global namespace
<tyhicks> right
<jdstrand> ok, even better :)
<tyhicks> only one thing is stacking and that's lxd
<jdstrand> roadmr: ^
<jdstrand> tyhicks: thanks :)
<wililupy> ogra_ This is interresting, looking at my grubenv on sda2, I don't have a reference to snappy_kernel. I have one for snappy_os.
<tyhicks> jdstrand: np - it is very confusing to think of the profile transitions and stacks involved there..
<ogra_> wililupy, looks like u-d-f doesnt pick up your kernel snap properly then :/
<ogra_> it should put that variable in place at image creation time
<wililupy> ogra_ I'm going to manually add it and see what that does...
<ogra_> (probably u-d-f has an issue with your version string ? ... )
<jdstrand> tyhicks: indeed. I need to focus on the policy namespaces involved and then I should be able to remember
<ogra_> (wild guessing here)
<wililupy> or possiably the name?
<ogra_> did you use any unusual chards in the name ?
<ogra_> **chars
<ogra_> (writing it in arabic or chinese ? )
<ogra_> :P
<wililupy> no
<ogra_> yeah, i thought so
<wililupy> well, it finds my kernel and tries to boot now, but it hangs after running /scripts/local-premount ... grep: /proc/device-tree/model: no such file or direcotry
<pedronis> ogra_: u-d-f doesn't care much about the names,  it cares very much about being able to open the snaps and the type in them
<wililupy> findfs: unabled to resolve 'LABEL=writable'
<ogra_> pedronis, well, it calls snap install ... and that has issues with certain version strings ... (like ... yu cant use colons for example)
<pedronis> ogra_: is this 15.04?
<ogra_> wililupy, ignore the device-tree thing ...
<ogra_> pedronis, nope
<pedronis> we don't care about versions anymore much in 2.0
<ogra_> wililupy, ext4 compiled in ?
<wililupy> Yeah, it just looked like it hung, it just popped up the latest error for findfs
<ogra_> pedronis, ah, cool
<pedronis> because the logic is about revisions now
<pedronis> and from sideloaded stuff in u-d-f you just get revision==
<pedronis> 0
<ogra_> yeag
<wililupy> ogra_ yes
<pedronis> (bit of a corner case that will be different with ubuntu-image)
<ogra_> wililupy, you should have an initrd shell now
<wililupy> CONFIG_EXT4_FS=y
<wililupy> CONFIG_EXT4_USE_FOR_EXT2=y
<wililupy> CONFIG_EXT4_FS_POSIX_ACL=y
<wililupy> CONFIG_EXT4_FS_SECURITY=y
<wililupy> CONFIG_EXT4_ENCRYPTION=m
<wililupy> CONFIG_EXT4_FS_ENCRYPTION=y
<ogra_> so you can inspect further
<wililupy> now I'm bumped to busybox...
<ogra_> yeah
<ogra_> check /proc/modules and see if squashfs is loaded
<pedronis> ogra_: anyway getting one boot var set and not the other afaict is a bit of a corner case, staring at code you will need something like the kernel not having the right type set in snap.yaml
<pedronis> or something like that
<pedronis> looking it doesn't like u-d-f checks that the things have passed have the right types
<pedronis> it will just skip setting the boot var though
<pedronis> for maximum confusion
<wililupy> cat /proc/modules:
<ogra_> pedronis, well, wililupy uses snapcraft to roll the kernel snap ... i'D expect the snap.yaml to be fine
<wililupy> squashfs 49152 0 - Live 0xffffffffc0000000
<ogra_> looks good
<pedronis> the other chance is that u-d-f does the right thing but firstboot unsets it
<ogra_> nah
<ogra_> the issue shows on freshly built imgs as i understand it
<pedronis> it has logic to swap things around for crash fallbacks
<wililupy> pedronis, that is interresting, becuase after first boot, I get my error message, then it says that it is going to trial reboot and then it gives me the same error message.
<ogra_> before firstboot ran
<pedronis> ah
<ogra_> wililupy, huh ?
<pedronis> but IÂ don't know what it does if there's no fallback
<ogra_> wililupy, are we talking about the same thing then ?
<ogra_> wililupy, i thought you use your kernel snap with u-d-f
<wililupy> ogra_ yes. After first boot after building with u-d-f I get my three error: messages, it then says it is going to trial reboot, and i get the three error: messages and then it takes me to the grub menu. After that, I just get the same three error messages, and that only happens after I do a fresh image using u-d-f
<ogra_> (dont tinker with instaled systems and trying to sideload your kernel ... that might hit other issues which we wont really resolve)
<wililupy> ogra_ np. I'm just working with my u-d-f image now.
<kgunn> zyga: hey, so i get the point of having plugs and slots in the same interface for a server/client...but just for development, i can just populate the slot side to get the server going right? (and just leave the plug stuff empty for the moment)
<pedronis> that's actually boot-ok to be precise, anyway this may be the bootloader part of that logic
<pedronis> which I don't know about
<ogra_> that part is pretty trivial actually
<ogra_> (lives in https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems in the grub.cfg or uboot.env.in files)
<wililupy> I added snappy_kernel=im-kernel_0.snap in the (hd,1)/EFI/grub/grubenv
<wililupy> which now I get my kernel to load up, but now I get initramfs errors and dumped into busybox.
<wililupy> I got this problem before due to now having squashfs in my initrd module in my snapcraft.yaml, but that is fixed now.
<ogra_> yeah, but it obviously cant find the label for the writable partition
<ogra_> which is a bit strange
<wililupy> The last error I got before this was findfs: unabled to resolve 'LABEL=writable'
<pedronis> ogra_: anyway IÂ checked nothing except install (which would be u--d-f) sets those vars in snappy itself
<ChrisTownsend> I have the home interface included in the plugs in my yaml and once I have the connection made.  However, the binary wrapper script that is used has $HOME re-exported to a different location.  How am I supposed to access things in ~/ ?
<ogra_> wililupy, right ...
<ogra_> it is like the label is missing or some such
<ogra_> (which i dont belive)
<pedronis> ChrisTownsend: there's been a bit of discussion around that, atm home means that if you get a path to something there you can access it, doesn't quite mean you get a handle to it, unless you go from user id to its value
<ogra_> wait-for-root "LABEL=$label" "${ROOTDELAY:-180}"
<ogra_> thats the code we call ...
<ChrisTownsend> pedronis: Ah, ok, well, I guess there is no way to map in the common XDG directories to the app in the snap.
<pedronis> ChrisTownsend: maybe there's already a bug that zyga knows about, otherwise we probably need one, there's  a bunch of requirements a bit colliding with each other at moment in that area
<ChrisTownsend> pedronis: As the thing I'm working on would like to use ~/Documents, ~/Music, etc.
<ChrisTownsend> pedronis: Ok, thanks.
<ogra_> hmm
<zyga> kgunn: yes, just have the other unused methods return nil, nil
<kgunn> cool
<kgunn> swamped today with manager stuff...but will get on this more tomorrow
<wililupy> Is there a reason system-boot is fat32? Is it due to it being the EFI partition?
<ogra_> yes
<ogra_> it also guarantees to work with all bootloaders across the board
<wililupy> ogra_ gotcha. I'm looking at the partition layout right now. I have three partitions on /dev/sda sda1 is labeled grub unknown fs
<wililupy> sda1 is labeled system-boot fat32
<ogra_> and writable
<ogra_> thats about right
<wililupy> and sda3 is writable
<wililupy> ext4
<ogra_> right
<wililupy> labels are right
<ogra_> well, but findfs doesnt find it
<wililupy> Thats funny, from my ubuntu rescue session on my device, findfs LABEL=writable, it finds /dev/sda3
<almejo_> Guys... another question if someone can help me. I need to run 'pip3 install hangups' in my snap. Is it possible in snapcraft right now?
<ogra_> wililupy, tyr the same in the initrd shell on teh image ... perhaps yu get more interesting errors
<wililupy> ogra_ I'm booting it up right now, waiting for it to timeout...
<ogra_> the fun thing is ...
<ogra_> in the code we first call
<ogra_> wait-for-root "LABEL=$label" "${ROOTDELAY:-180}"
<ogra_> and then
<ogra_> findfs LABEL=$label
<ogra_> the first one doesnt seem to fail
<ogra_> (since that would spit out a different error)
<sergiusens> elopio for some reason I cannot see http://162.213.35.179:8080/job/github-snapcraft-autopkgtest-cloud/600/
<sergiusens> mind giving me some crumbs to look at?
<geneios> alemjo, I think you can use the "python-packages:" keyword with "hangups" as the value
<almejo_> thanks!!! :D
<geneios> I was able to use it to pip install some dependencies in my snap, but I am still struggling if python-dev is required
<almejo_> and last question about the life cicle of snaps. If i build a snap, and then I add a new dependency, the only way to build the package again is to do a snap clean?
<almejo_> I am a little tired of cleaning every time and wait for all the packages to download
<LinuxGuy2020> Hello I was trying to follow the snapcraft tutorial online and got the snap to build but I'm wondering how to skip the publication step and just install it for personal use only or just to test it out before publishing. Is there a way?
<almejo_> LinuxGuy2020, snap install app.snap
<niemeyer_> jdstrand: About the networkmanager interface, where do we stand?
<niemeyer_> jdstrand: I was a bit surprised by the comment that this should be black listed on 16.04.. why isn't it a slot on the os snap?
<ogra_> niemeyer_, what do you do if someone installs the NM snap on a desktop ?
<jdstrand> niemeyer_: the actual mp I think is blocked on you deciding the name and zyga refactoring the bluez code for the slot side dbus apparmor label. I do plan to also look at the latest comments regarding bus policy
<ogra_> (where you already have NM running)
<wililupy> same error, unable to resolve 'LABEL=writable'
<niemeyer_> ogra_: See above.. the point isn't to install the snap on the desktop, but to make the interface available in the os snap
<jdstrand> niemeyer_: then there is that question-- how to handle nm on classic vs nm on core+snap
<ogra_> niemeyer_, ah, sorry, i thought it was the same "blacklisting" we talked about above
<ogra_> now jamie brought it into the discussion :)
 * jamiebennett hides
<jamiebennett> What did I do?
<jdstrand> jamiebennett: me :)
<ogra_> jamiebennett, the other one ;)
 * jamiebennett dodges another
<jdstrand> niemeyer_: so, if we do as you suggest, then snapd needs to be adjusted to create different snippets if it is running on classic vs pure core
<LinuxGuy2020> almejo_: Thats what I tried the other day but it attempted to download something first and failed.Maybe I didnt build the snap correctly or something. I'm just trying to make snaps for packages that are already available as debs. That way I can use store them on local drives more easily than a boat load of debs. Is there a better tutorial explaining just converting pre-existing debs to snaps?
<wililupy> Here's a new error:
<niemeyer_> jdstrand: Yeah, that seems appropriate
<jdstrand> niemeyer_: cause at a minimum the labels will be wrong
<LinuxGuy2020> Or should I just keep trying the way I was before.
<niemeyer_> jdstrand: Well
<LinuxGuy2020> I was following this https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/
<niemeyer_> jdstrand: This is the same story we discussed for the bluez snap
<wililupy> findfs [   383.689847] random: nonblocking pool is initialized
<jdstrand> niemeyer_: but I know for a fact we will have different actual policy for pulseaudio on classic vs core
<niemeyer_> jdstrand: It's bogus to cook a snippet hardcoding the name of the snap
<LinuxGuy2020> It seems very vague though.
<jdstrand> niemeyer_: no, you misunderstand
<niemeyer_> jdstrand: Ah..?
<ogra_> wililupy, thats just mess-up of the console messages ...
<jdstrand> niemeyer_: I'm assuming that patch will be committed
<ogra_> wililupy, not an error
<wililupy> ogra_ ack
<niemeyer_> jdstrand: Sorry, I don't understand the idea about the labels being wrong then?
<jdstrand> niemeyer_: what I'm saying is that the label of the slot side on sdoc would be 'unconfined' but on pure core it will be the slot side snap (ie, snap.nm...)
<jdstrand> niemeyer_: but beyond that, we will likely want different rulesets on sdoc vs pure core
<almejo_> LinuxGuy2020: That tutorial is about dowloading a .deb form the archives and packaging it with other tools. is that what you want? I know other tutorial in www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<jdstrand> niemeyer_: for example, on core, there is no policykit, on sdoc there is. this affects the policy. there will be cases where the rules aren't strictly additive so we need to consider that when deciding on this
<niemeyer_> jdstrand: Well, I think on sdoc we don't even need a snippet at all, do we?
<niemeyer_> jdstrand: On the slot side, that is
<jdstrand> niemeyer_: if there is no snippet there is no access
<jdstrand> there is a slot side and a plug side
<niemeyer_> jdstrand: nm is running already, unconfined
<wililupy> ogra_ I'm not seeing any sd* in /dev...
<LinuxGuy2020> almejo_: I just need a tutorial to make a snap out of lets say the ardour3.deb thats in the repos already. But of course the snap would have all the dependencies included. Thats all Im looking for.
<jdstrand> the plug side needs the label of the slot side
<ogra_> wililupy, aha
<ogra_> wililupy, so still some kernnel config bit missing i guess
<niemeyer_> jdstrand: So how would that work?
<niemeyer_> jdstrand: nm is already running..
<ogra_> wililupy, do you have devtmpfs enabled ?
<jdstrand> niemeyer_: I'm not talking about nm being confined. I'm talking about the plug side snippet a) needed label=unconfined on sdoc vs label=snap.whatever on pure core and b) different apparmor rules on sdoc vs on pure core
<LinuxGuy2020> almejo_: What would be the best tutorial for me to follow for that?
<wililupy> CONFIG_DEVTMPFS=y
<wililupy> CONFIG_DEVTMPFS_MOUNT=y
<ogra_> wililupy, oooooh ! i know what it is !!!!
<jdstrand> niemeyer_: sdoc and ubuntu core are radically different and the security policy is going to have to deal with that sort of thing
<wililupy> ogra_ please tell please tell please tell.....
<almejo_> LinuxGuy2020 I followed the second one and it builds ok. Also, that one teaches you about plugs and slots, something absolutly necesary
<niemeyer_> jdstrand: Yeah, absolutely
<ogra_> wililupy, add ahci to your initrd modules (or compile it in)
<jdstrand> on sdoc nm is unconfined and has one label, on pure core it is confined and has snap...., on sdoc it is compiled with polkit, on pure core not, etc, etc
<almejo_> LinuxGuy2020, the firstone is also good. Read both :D
<niemeyer_> jdstrand: So is "unconfined" a magic label to tell the process has no labels?
<ogra_> wililupy, and perhaps also libahci
<wililupy> ogra_ I have this in my config:
<wililupy> CONFIG_SATA_AHCI=m
<wililupy> CONFIG_SATA_AHCI_PLATFORM=m
<wililupy> CONFIG_SATA_INIC162X=m
<wililupy> CONFIG_SATA_ACARD_AHCI=m
<wililupy> CONFIG_SATA_SIL24=m
<jdstrand> niemeyer_: if a process is launched without using aa_change_profile/aa_change_on_exec and there is no binary attach policy for it in /etc/apparmor.d, then it automatically defaults to have the unconfined label (and policy)
<wililupy> CONFIG_ATA_SFF=y
<ogra_> wililupy, right, it is a module ... and you need it in the initrd
<LinuxGuy2020> almejo_: ok thanks. Should the system need to download any files before it actually installs the snap? Cause the ones I built were trying to download something like 64.64MB or something like that. No idea what it was.
<niemeyer_> jdstrand: Gotcha
<ogra_> wililupy, or compile it in
<jdstrand> eg, most process on desktop are 'unconfined' (see ps auxZ)
<jdstrand> most on snappy are confined (well, depending how many snaps you have installed :)
<almejo_> LinuxGuy2020, When you build a snap, it downloads all the dependecies specified in snapcraft.yaml. Then it build the snap using ALL the dependencies creating a really big .snap file
<wililupy> I gotcha I see,so add ahci to the kernel_initrd_modules in snapcraft.yaml?
<niemeyer_> Nice
<almejo_> LinuxGuy2020, then, you have to install that snap. It will not dowload other files
<ogra_> wililupy, right ...
<niemeyer_> THe output, not the fact they're unconfined :)
<jdstrand> niemeyer_: so, we can do it your way, but if we do, then snapd needs to make decisions about the system at runtime. in some ways that is nice, but in others it is pretty magical and adding complexity
<LinuxGuy2020> almejo_: Right. Then I got the *.snap file and tried the sudo snap install *.snap whatever the name was. Ill just try again and see exactly what happens at that point.
<niemeyer_> jdstrand: Well, I don't see it as magical, or even as adding relevant complexity
<almejo_> LinuxGuy2020, yes. The snap will be installed in /snap/
<niemeyer_> jdstrand: The whole point of the interface system is to enable snaps to interoperate in the different enviornments
<pedronis> niemeyer_: it seems we need some internal blessed way to know if we are on sdoc vs other scenarios (we need to cleanup firstboot and friends also)
<almejo_> LinuxGuy2020, you can go to /snap/bin and see the executable files
<jdstrand> niemeyer_: an alternate approach would be what I was saying before-- implement nm, bluez, et al as pure core interfaces, then filter them out on sdoc systems. then adjust unity7(*) accordingly for common policy (since it is transition policy)
<niemeyer_> jdstrand: having a network-manager interface that works only on devices would be super awkward
<jdstrand> niemeyer_: I didn't think interfaces really solved anything with pure core vs sdoc. I thought it solved snaps slotting interfaces and connecting in arbitrary ways
<pedronis> niemeyer_: we need *it* to cleanup firstboot
<wililupy> ogra_ I'll give it a shot and see what happens.
<niemeyer_> pedronis: Hmm.. tell me more?
<niemeyer_> jdstrand: Isn't that what we're talking about?
<pedronis> niemeyer_:  we need to know to skip firstboot code etc when setting up from empty state
<jdstrand> niemeyer_: I think it is a bit awkward that nm is considered part of the os snap on sdoc but it needs a snap on pure core
<niemeyer_> jdstrand: We have a network manager process in the system, and a network-manager interface.. why would it work on one device and not the other
<niemeyer_> ?
<pedronis> seems we need it now also to drive interface behavior
<jdstrand> niemeyer_: sorta, but an area we never really explored
<niemeyer_> jdstrand: That sounds like a misunderstanding about interfaces
<LinuxGuy2020> almejo_: Ok im starting with a clean install on my laptop instead of using the live environment. Ill try again and come back if I have issues. Thanks.
<pedronis> the all point is that you don't need to know what providing the slot
<jdstrand> niemeyer_: there is also the issue of not wanting to install the nm snap on an sdoc system. that is perhaps solved if snapd blocks installing multiple snaps that slot the network-manager type, and ths os snap is shown to slot that on sdoc
<almejo_> LinuxGuy2020, great!!! But I am going home now.. I hope someone else can help you... or maybe tomorrow
<LinuxGuy2020> almejo_: thats cool
<niemeyer_> pedronis: Right, exactly
<niemeyer_> jdstrand: That's a good idea
<jdstrand> niemeyer_: I see where you are coming from, but the network-manager interface on sdoc will be different because it is on sdoc (ie, the security policy will be different). I thought that the interface provides a contract between the client and the slot
<niemeyer_> jdstrand: The security policy is the implementation
<jdstrand> niemeyer_: therefore a snap plugging nm may work on core but not on sdoc, or vice versa, because it is a different contract
<niemeyer_> jdstrand: It's a bit like saying the bits on amd64 need to be different than on arm to provide the same CLI experience
<jdstrand> I don't think that is an apt analogy
<niemeyer_> jdstrand: Surely they must be different.. what we're trying to preserve is the paltform behaivor, not how it is implemented
<pedronis> jdstrand: sounds more like it shouldn't be one interface then but needs more granularity, no?
<pedronis> if it's really diverging that much
<jdstrand> pedronis: that is another option, arguably also awkward
<jdstrand> really, all of the options have warts
<jdstrand> cause we are shoehorning classic into the new world
<jdstrand> or the new world onto classic
<niemeyer_> What's the wart?  I couldn't see it yet
<niemeyer_> Having different security policy to implement the same behavior is expected and not actually a wart
<jdstrand> if we have one interface, but different policy on sdoc vs pure core, and a plugging app works on one and not the other because of the policy
<pedronis> niemeyer_: I think jdstrand is saying that behavior will be different
<pedronis> so my remark about granularity
<niemeyer_> jdstrand: Why would a plugging app work differently?
<jdstrand> one could argue that the policy should encompass everything, but that may not be appropriate-- it might be too wide on pure core since things in classic aren't designed for snappy
<jdstrand> niemeyer_: the plugging app would try to work the same, but perhaps break in one
<niemeyer_> pedronis: Yeah, I just didn't see the actual relevant difference as far as the snap perception is concerned
<jdstrand> I have a feeling in the nm case in particular, we could probably make it work. nm is always going to be reserved since it offers a lot of privilege
<jdstrand> but, for pulseaudio we will have the same issue
<jdstrand> and that one I know we want different policy
<jdstrand> because desktop pulseaudio access is different than say Touch access
<niemeyer_> jdstrand: How is it different?
<jdstrand> Touch is much more limited (it uses the safe apis and apps may only use those), whereas on desktop apps, they will not
<jdstrand> because desktop apps weren't designed for that-- they expect to be able to use everything
<jdstrand> but Touch apps are designed for that
<jdstrand> so to be clear
<jdstrand> we *can* do this if we allow for different policies if snapd detects what can of system it is running on
<jdstrand> the question is then if we should or not
<niemeyer_> jdstrand: That sounds like two different interfaces then
<jdstrand> and I'm not convinced it is a good idea
<wililupy> ogra_ It's interresting, in the grubenv file, there is no value for snappy_kernel
<jdstrand> niemeyer_: indeed. with pulseaudio in particular I was considering siply adding it to unity7. we could alternatively create unity7-audio (or similar)
<ogra_> wililupy, right, that was the initial prob ... but it should now boot if you add the var
<niemeyer_> jdstrand: We need to look into this in more detail, but if the protocol the applications use to communicate is actually different, then they're of course incompatible, which implies two interfaces rather than one
<ogra_> i.e. the initrd bug should be gone
<niemeyer_> jdstrand: We shoulld call it out for what it is
<jdstrand> niemeyer_: right. so with nm, one is a subset of the other. the desktop nm is a superset of the pure core nm
<niemeyer_> jdstrand:  If it is pulseaudio-simplified or similar, than that's what it is
<jdstrand> niemeyer_: I think bluez is also going to fall into that category. what gets interesting again is Personal may have a different subset
<niemeyer_> jdstrand: We can also start exploring interface attributes
<jdstrand> niemeyer_: I don't disagree, but then that has warts too cause we have a bunch of different interfaces that people may not know what to use
<niemeyer_> jdstrand: But I really need to understand more details before being able to recommend something sensible
<niemeyer_> jdstrand: Well, we *will* have a bunch of different interfaces :)
<niemeyer_> jdstrand: In fact, we do already
<niemeyer_> jdstrand: Conveying what those are and when to use them is an important issue to address properly
<jdstrand> niemeyer_: really it boils down to the characteristics of the device. sdoc has one set of characterists, pure core another and personal possibly another. depending on the device, the policy may or may not be different
<niemeyer_> jdstrand: Yeah, and that's all okay
<niemeyer_> jdstrand: Different policy just means a different implementation to the same result
<niemeyer_> jdstrand: Different protocol means something else
<jdstrand> niemeyer_: I think we should be striving for just enough interfaces and no more. we've seen other platforms make this mistake and developer's getting confused and asking for too much, etc. with user's connecting it then gets confusing, etc
<jdstrand> I should rephrase
<jdstrand> we haven't made a mistake
<niemeyer_> jdstrand: Just enough interfaces to do what..
<niemeyer_> jdstrand: Of course we shouldn't be producing interfaces just because it's fun to do so :)
<jdstrand> we've seen other platforms offer too many similar choices...
<jdstrand> niemeyer_: hehe
<jdstrand> no
<jdstrand> but if we are in pulseaudio-simplified vs pulseaudio-complex, it makes me wonder
<jdstrand> because complex would (possibly) always work so no one would choose pulseaudio-simplified, but pulseaudio-simplified is actually 'the good one'
<jdstrand> it is an interesting problem
<wililupy> ogra_ I think I'm going to have to rebuild my whole snap. I tried just adding ahci to my snapcraft yaml, but cat /proc/modules doesn't show it.
<jdstrand> I may be coming around to your thinking (I was never really opposed to it), but perhaps there is something with attributes there that I haven't considered that would make it really good
<wililupy> I'll give it a run since it takes about 2 hours to complete and I'll update you tomorrow.
<wililupy> thanks for all your help ogra_
<niemeyer_> Yeah, let's understand better how pulseaudio is organized so we can have a more informed position
<ogra_> wililupy, you will need to run whatever step megres the modules into the initrd
<niemeyer_> jdstrand: Need to step out now, but let's follow on later/tomorrow
<ogra_> wililupy, good luck then, i'm sure the initrd side is fixed
<jdstrand> niemeyer_: sure, np. I can fill you in on the pusleaudio differences tomorrow
<niemeyer_> jdstrand: Thanks, and thanks for the chat
<jdstrand> niemeyer_: my pleasure :)
<jdstrand> niemeyer_: have a good evening :)
<elopio> sergiusens: I can see it. Failed to clone the git repo.
<elopio> I'd say retest.
<sergiusens> elopio thanks
 * sergiusens is so tired of resetting snapd
<Laxman> where to find sources for raspberry pi 2 ubuntu snappy
<geneios> Where should snapcraft issues be filed? At https://launchpad.net/snapcraft? I didn't see an issues section on the github repo.
<Domi> Hello snapcraft snap fails because the python installation. Her is the output http://pastebin.com/GmZB6v4D can anyone help me?
#snappy 2016-04-28
<svij> is there no "snap update" command, or will it update automagically?
<zyga> svij: it's snap refresh
<svij> ah I see, is there no command to update all snaps, rather than one single with refresh? (I don't need it right now, just curious)
<zyga> svij: it will be refresh, just not implemented yet
<svij> zyga: ah okay
<svij> thx
<dholbach> kyrofa, sergiusens: once you're both up, can we chat about the snapcraft sessions at UOS and get them scheduled?
<slvn> jdstrand, zyga, about SDL2 failling with UDEV for Initialization of INIT_Joystick. That happens when calling "udev_monitor_new_from_netlink", and apparmor says :  audit: type=1400 audit(1461830101.683:1127): apparmor="DENIED" operation="create" profile="snap.MyApp.app" pid=11228 comm="MyApp" family="netlink" sock_type="raw" protocol=15 requested_mask="create" denied_mask="create"
<slvn> (maybe I need to use the plug network ?)
<zyga> slvn: I suspect that will stay denied for a while unless netlink support in apparmor is improved, for now I'd compile joystick support out
<slvn> zyga, it's not blocking anyway.. joystick is just not initialized.. just report the issue
<zyga> ah, ok
<slvn> zyga, also audio was failing, but it's not *killing* the apps, it just stays not initialized.
<slvn> zyga, just correcting myself, in fact, audio pulse if really failling (.shm_open() failed: Permission denied). So I need to desactivate it.
<zyga> slvn: we know about audio, we'll get something supported, if you check the backlog we discussed this issue last night
<zyga> slvn: there are still a few things to decide before that can happen but we do know about it
<slvn> zyga, ok
<ysionneau> about Mark shuttleworth's email : what's "GA" ?
<zyga> ysionneau: general release?
<ysionneau> A for Release ? :o
<zyga> availability? :)
<zyga> globally awesome release :)
<Gunther_> hehe we also discussed the meaning of "GA" here :)
<ysionneau> :)
<vijaikumar> General Availability
<ysionneau> thanks
<Gunther_> latest allsnaps: sudo snap remove trionet error: can't remove "trionet": cannot find mounted snap "trionet" at revision 100001
<Gunther_> :(
<Gunther_> did work before, but at one time complained about: sudo snap remove trionet [-] Remove snap "trionet" from the system error: cannot perform the following tasks: - Remove snap "trio
<Gunther_> and after reboot I am stuck
<zyga> Gunther_: it's known broken for now
<zyga> Gunther_: will be fixed with the next SRU
<zyga> Gunther_: you can use my script to reset snap state: github.com/zyga/devtools
<zyga> Gunther_: look at reset-state
<Gunther_> ok thanks
<zyga> Sorry for the bad experience
<Gunther_> no problem, I am developer myself
<Gunther_> zyga: worked great ;-) all snaps removed including the kernel (ooops)
<zyga> Gunther_: ooops
<zyga> Gunther_: this was tested on the desktop
<zyga> Gunther_: it would need some love on devices
<zyga> Gunther_: can you look at what would be needed to make it work there and fix it please
<Gunther_> zyga: I ll try
<dpm> oh, I just discovered a nice snap trick: https://bugs.launchpad.net/snappy/+bug/1574829/comments/1
<ubottu> Launchpad bug 1574829 in Snappy "snappy install requires root or login, but doesn't tell you so" [Wishlist,Triaged]
<dpm> snap without sudo
<asac> pitti: where is the rename of wlan0 to wlxXXXXXX done? I couldnt find the matching rule in udev
<pitti> asac: in xenial release it is still /lib/systemd/network/90-mac-for-usb.link
<asac> ahh... /me was already thinking maybe its in systemd
<pitti> asac: however, that will change soon (also in xenial) to /lib/udev/rules.d/73-special-net-names.rules due to bug 1574483
<ubottu> bug 1574483 in systemd (Ubuntu Xenial) "assigns MAC-based names for devices with locally administered MAC address" [High,In progress] https://launchpad.net/bugs/1574483
<asac> ok gotcha... let me study the .link file a bit though so i know how that works
<pitti> asac: see /usr/share/doc/udev/README.Debian.gz
<pitti> that still refers to a wrong name (01- instead of 90-)
<qengho> My gnome-disks UI looks pretty hilarious after using snappy for a while.
<zyga> _morphis: hey, you should be able to rebase n-m interface on top of https://github.com/ubuntu-core/snappy/pull/1078 now
<_morphis> zyga: awesome!
<_morphis> will do, thanks a lot for that!
<zyga> _morphis: https://github.com/ubuntu-core/snappy/pull/1078/files#diff-939866a2238749d2c6989a8a757f430f
<keestu> Hi, I use ubuntu since last 5 years. I came across  about the snappy. I have dev embedded board, and i have a question now.  Is it possible to get ubuntu core into the this embedded device ?
<zyga> keestu: yes, you need a kernel that works there and a supported bootloader
<zyga> keestu: though right now devices (boards) are in rapid development after 16.04 release so expect a lot of changes in the next few weeks
<keestu> zyga,  thanks, my knowledge is petty limited to this. I have a board, where we port android, linux with qt, how snappy is going to be different ?
<zyga> keestu: if you have a working kernel, it should be not much different
<zyga> keestu: the only requirement is a supported arch, what SoC
<zyga> keestu: (you don't build snappy entirely from source,)
<zyga> keestu: you just buld the kernel and gadget snaps, the rest is stock and shared by all devices
<keestu> so, snappy is a way to get the customized desktop feel in embedded device ?
<zyga> keestu: snappy has no desktop feel
<zyga> keestu: anyway, please familiarize yourself with the documentation on snappy that's available on ubuntu.com now
<keestu> zyga,  i am looking at the business perspective.  We see the customers demanding porting android to our embedded device.
<keestu> zyga, sure.
 * zyga -> lunch
<keestu> :)
<keestu> bon appetit
<slvn> zyga, another issue snap+SDL2+x11. At first install (after reset-state), it doesn't connect to x11. I need to remove the snap, then reinstall it. then it can connect to x11. The syslog error was "apparmor="DENIED" operation="connect" profile="snap.MyApp.app" pid=22559 comm="MyApp" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/tmp/.X11-unix/X0"
<slvn> peer="unconfined"
<ogra_> ppisati, have you seen bug 1574103 ?
<ubottu> bug 1574103 in Snappy "Raspberry Pi 2 image LEDs are swapped." [Medium,New] https://launchpad.net/bugs/1574103
<ogra_> and bug 1574075 might also be interesting
<ubottu> bug 1574075 in Snappy "Snappy does not detect Sagem wifi dongle" [Medium,New] https://launchpad.net/bugs/1574075
<sergiusens> dholbach I will have to rain check on that and ask for it to be in a couple of hours; both kyrofa and myself are unavailable right now
<seb128> sergiusens, can parts/files have dynamic values?
<seb128> like "somelib: /usr/lib/$(ARCH)/somelib"?
<seb128> sergiusens, hey btw :-)
<jdstrand> slvn: fyi, you need to plugs either unity7 or x11. did it not autoconnect?
<slvn> jdstrand, both are in the plugs list (and also opengl) of the snapcraf.yaml file
<slvn> maybe the reset-state script is incomplete ?
<jdstrand> slvn: would you mind filing a bug for that? show your snapcraft.yaml, how you installed, the denial and the policy in /var/lib/snapd/apparmor/profiles/snap.MyApp.app
<slvn> first install -> x11 doesn't work. then remove, and install again. it works
<jdstrand> slvn: and please add that detail :)
<slvn> jdstrand, yep. I go away now, but I will re-try that later and fill a report.
<jdstrand> slvn: thanks. others have seen this but I don't think there is a bug
<slvn> jdstrand, if first install always fail to launch, it's kind of problematic for me :)
<jdstrand> slvn: very much indeed :)
<bencc> can I package an erlang app with snappy and do hot code upgrade?
<slvn> jdstrand, but i'll double check later and let you know! ++
<bencc> upgrade the code while the app is till running?
<dholbach> sergiusens, I'll have to leave at 16:00 or 16:15 UTC today - it'd be good if we could talk about it before
<zyga> slvn: you can always connect manually but I'm wondering why auto-connect did not work
<zyga> slvn: thanks, I'll investigate this
<wesleymason> Snapcraft Q: is there a variable representing the install stage path that I can, for example, pass to a makefile to tell the target where to install into
<wesleymason> ?
<kgunn> zyga: just confirm, if i change something in snap, go build it and snapd, copy over and fire up snapd...i should see the change i made in snap?
 * kgunn swears he saw this before, hopes he's not going crazy
<zyga> kgunn: in a meeting, you need to copy snapd (and restart it, devtools helps)
<zyga> kgunn: for security changes disconnect and reconnect
<kgunn> zyga: was doing pkill -9 snapd, then starting
<oparoz> wesleymason, $SNAPCRAFT_STAGE
<zyga> not really
<zyga> kgunn: try github.com/zyga/devtools
<zyga> there are more bits and magic there
<zyga> and it's all made for this use case
<wesleymason> oparoz: great, cheers
<kgunn> zyga: ok
<kgunn> so i can't just go build snap/snapd, copy over?
<zyga> you can but you need more, devtools does all that
<zyga> and more :-)
<zyga> try it
<kgunn> ok, i may need help, cause my vm i use for mir isn't the standard one
<zyga> syure
<zyga> sure*
<kgunn> mainly ssh  config i suppose
<oparoz> Is there a recommended way to use start-stop-daemon in init scripts? Default policy doesn't allow scripts to call it
<ogra_> first of all you would have to ship it in your snap :)
<ogra_> (and then i dont think it would be accepted or used at all in the end ... given we use systemd in snappy )
<oparoz> ogra_, I get "access denied", so it must be there, just not allowed. The way I understand it is that systemd calls whatever start script is given to it, so it shouldn't be an issue to call this command, no?
<kgunn> zyga: actually...i got it....devtools talking to my vm, i see devtools.snap in there :)
<kgunn> relying on magic now
<ogra_> oparoz, it is a tool from sysvinit scripts ... it should really not be used at all in systemd envs
<ssweeny> jdstrand, zyga, is there a recommended way to do service logging in snappy? My location-service snap is trying to create /var/log/location-service which obviously isn't going to work
<zyga> kgunn: cool, just use refresh-bits (it has --help and is trivial to read)
<zyga> ssweeny: I don't think there is one, maybe just let systemd manage logging
<zyga> ssweeny: but I don't really know
<ssweeny> zyga, ok, thanks
<ogra_> ssweeny, "snappy service logs" used to do that ...
<zyga> kgunn: I will gladly take patches for new features
<kgunn> zyga: hmmm, with latest tools...do i have to sudo snap for such things as "snap list" ?
<ogra_> i would expect that to be back once the snap service command comes back
<zyga> kgunn: yes, because the socket is root-owned
<zyga> kgunn: or chmod 666 /path/to/socket (/var/snapd.socket AFAIR)
<zyga> kgunn: it's not handled by devtools because I was always lazy and using sudo
<kgunn> that's right...i see a note
<kgunn> ok, fully relying on devtools...and i still don't see my mod
<zyga> kgunn: if you get it supported, just send me a patch please, I was annoyed by this once and there was one bug hidden by this already
<zyga> kgunn: what's the mod about? policy change?
<zyga> kgunn: you should connect/disconnect or remove/install the snap because there is no logic that detects interface implementation changes yet
<zyga> kgunn: you should also check generated profiles (/var/lib/snapd/{apparmor,seccomp}/profiles
<jdstrand> ssweeny: if you want your own log, you need to change the path to somewhere in SNAP_DATA
<ssweeny> jdstrand, yeah that was my other thought
<zyga> jdstrand: hey, gustavo recommended that we work on making n-m interface supported on the desktop; it would also unblock a bunch of prospective snaps; can you tell me if the current policy there is safe for desktop use?
<jdstrand> ssweeny: (if you don't want systemd to handle it-- with systemd it will capture stdout and stderr and you can use journalctl to see the output from your service)
<kgunn> jdstrand: isn't there a command line to list interfaces?
<zyga> jdstrand: (just comment on the pull request anytime you have a moment to look at it)
<kgunn> i thot i recalled that...couldn't find the email
<zyga> kgunn: snap interfaces
<kgunn> dang it...soo simple
<kgunn> shoulda guessed
<zyga> :-)
<seb128> does anyone know if parts/files have dynamic values?
<seb128>  like "somelib: /usr/lib/$(ARCH)/somelib"?
<ssweeny> jdstrand, ah so I can just change logging to stdout and stderr and systmd will take care of it for me? cool
<zyga> seb128: I don't think they do
<seb128> :-(
<zyga> seb128, kyrofa: or sergiusens would know
<zyga> seb128: what are you trying to build?
<seb128> they are not around though
<seb128> a GTK app
<zyga> seb128: you can use $SNAP_ARCH
<zyga> seb128: it's an env variable we set
<seb128> to install thing?
<jdstrand> ssweeny: note, it will also show up in syslog, but yes
<zyga> seb128: you'd have to do a wrapper for it though
<zyga> (or patch gtk)
<seb128> at build time?
<zyga> seb128: no, at runtime
<seb128> that doesn't interet me
<zyga> seb128: for build-time i don't know
<zyga> (I'm hacking on the other side)
<zyga> seb128: I'd recommend starting with amd64, then working with snapcraft hackers to generalize
<jdstrand> zyga: re nm-- we had a rather lengthy discussion on that at the eod yesterday but I didn't think we came to a conclusion. but to specifically answer your queston, no, the nm policy is not safe for confined apps-- it grants too much privilege
<zyga> seb128: for the runtime part I think we should perhaps explore patching some bits to understand snap runtime layout
<zyga> jdstrand: ok, could we do a simple version for now that still works on the desktop and land that, iterating on a broader one using some other ways (attributes, more ifaces)
<seb128> zyga, I'm on i386 so starting with amd64 is not going to work for me :p
<zyga> jdstrand: I think the key is to ensure that we don't leave the desktop as we progress
<zyga> seb128: oh, sorry
<zyga> seb128: i386 is fine though, it's just a suggestion to try to solve the simpler problem first
<seb128> right
<seb128> well I've the arch coded
<seb128> but I wanted to push that so jdstrand and others can play with it
<jdstrand> zyga: I feel like I am missing context. we left it yesterday that we need more discussion for the desktop case
<seb128> but it sucks if everyone needs to sed the arch before building
<zyga> jdstrand: I just talked about this in the standup, gustavo recommended that we ensure it works on the desktop before it lands
<jdstrand> well, then I need to understand the direction
<jdstrand> zyga: did niemeyer_ comment in the pr?
<zyga> jdstrand: checking
<zyga> jdstrand: nope
<zyga> there's the community sync in 3 minutes
<zyga> let's continue that after if you have time, otherwise let's do it by email
<jdstrand> zyga: email is probably best so everyone has context
<seb128> did anyone look at snap and translations?
<seb128> what would be the right place to discuss the topic/put notes?
<seb128> list? launchpad pad? spec?
<ogra_> seb128, UOS ? :)
<ppisati> ogra_: ack
<seb128> ogra_, right, because that's going to be useful if nobody of the snappy team is interested and joining
<seb128> is there any plan to mount some part of the snaps to normal system locations?
<seb128> rather than trying to make everything reallocatable?
<seb128> mvo, hey, do you know if it somebody discussed making locales part of the core image before?
<ogra_> i think that was discussed and deemed to be to space hungry
<ogra_> (given it was designed for embedded without actual users)
<zyga> seb128: I doub't that
<zyga> (not relocatable)
<seb128> zyga, :-(
<ogra_> seb128, i suspect we're moving into -pd territory ...
<seb128> ogra_, are such gaps documented somewhere? launchpad bugs?
<ogra_> not that i know of ...
<zyga> seb128: I think that would be against the idea of snappy
<ogra_> but i personally wouldnt see locales as something to have in core ...
<seb128> ogra_, you would see each application needing to ship the libc locale definition?
<seb128> + to patch glib to allow relocating those
<caio1982> hi there, i am snapping a system monitor tool and i wonder what plugs would be necessary to access /proc/vmstat and a given /etc file like /etc/mtab... is there one?
<ogra_> seb128, well, a snap *has to be* completely inependend from the core system,. they always need to be separately upgradeable ...
<ogra_> thats one of the base definitions of snappy
<seb128> ogra_, with, snaps don't have to ship their own libc, do they?
<ogra_> they can
<seb128> but don"t have to?
<ogra_> thats the one thing they could use ... but nothing stops you to ship your own
<seb128> well, shipping your translations, fine
<seb128> having to ship the glibc locale definitions
<seb128> I doubt it's something any appdev is going to want
<seb128> also glibc doesn't support relocating those
<ogra_> well, but shipping them in core means you add a dependency
<seb128> depends to what?
<seb128> snaps depends on the core anywhy
<seb128> anyway
<ogra_> between the system and the snap
<ogra_> i.e. what if glibc locale handling code changes in incompatible ways in the system snap
<ogra_> you would need something liek a versioned dependency
<seb128> ogra_, you are saying "what if glibc changed in an incompatible way", but that's already an issue since you don't force snaps to ship a copy of glibc
<ogra_> sure
<seb128> if you have this stance it's fine, but then be consistent and force snaps to include a libc copy
<dholbach> niemeyer, which time between 14 and 20 UTC would work for you for an interface session next week (3-5 May)?
<dholbach> zyga, ^ too
<seb128> if you allow them to rely on the core one there is no point to say that can only be for some parts of libc
<zyga> dholbach: any except standups but I'm flexible
<ogra_> seb128, right, the "it is useless on headless IoT systems without users" thing is still valid though ...
<ogra_> we'd need two core setups
<seb128> unsure
<seb128> you might want your ls, etc to be in german
<ogra_> which ls ?
<seb128> your commands on the core
<ogra_> on my router i only have that web UI :P
<seb128> well, you might want that webui in german
<ogra_> on my drone i even only have that mobnile app that talks to it
 * zyga checks backlog
<ogra_> sure, but for that i dont need glibc locales necessarily
<seb128> right
<seb128> we need frameworks :p
<ogra_> good idea !
<zyga> seb128: though ogra was spot on on pocket-desktop area, I think on personal the core snap could provide you with a gtk runtime interface
<ogra_> uh
<zyga> seb128: so if you want that runtime to be something you depend on, great, but I don't know if that's exactly what we want to do with gkt
<ogra_> a whiole runtime is to much imho
<zyga> seb128: perhaps for SDK runtime first
<zyga> seb128: we don't need frameworks, we need interfaces
<zyga> seb128: anything that a framework could do is doable with a new interface
<seb128> can an interface snap add files to /var and /lib in your snap mount?
<zyga> seb128: an interface can let a snap do this
<zyga> seb128: we still don't have hooks, when we get them from new state engine we'll be able to react to all actions (connect, etc)
<zyga> seb128: if you tell me more about the problem perhaps I could suggest a solution
<seb128> zyga, trying to get translations working in my snap
<seb128> which requires to have locales generated in /usr/lib/locale/locale-archive
<seb128> that can be relocated
<seb128> by then gettext tries to read from /usr/share/locale:/usr/share/langpack-locale
<seb128> which can't be relocated
<seb128> but as an appdev I don't want to have to learn how to generate libc locales
<zyga> seb128: the appdev part should be solved with snapcraft support
<seb128> I guess we could teach snapcraft to generate those though
<seb128> that still doesn't solve the fact that glibc doesn't let you relocate/specify another dir to load the .mo
<seb128> out of patching glibc's code and rebuilding glibc as part of your snap
<zyga> seb128: doesn't textdomaindir do that?
<seb128> no
<seb128> it works only for the gettext command line
<zyga> I mean
<seb128> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=114461
<ubottu> Debian bug 114461 in gettext "gettext: there is no way to control where message catalogs are found at run time" [Normal,Open]
<zyga> bindtextdomain
<seb128> zyga, no
<zyga> why not? it seems to do just that?
<zyga> (assuming you build an app from source)
<seb128> well
<seb128> right, I'm repackaging a deb
<zyga> ah, right
<seb128> but then if you do that
<zyga> for deb-repacking I agree
<seb128> what if need also strings from libc
<seb128> +you
<zyga> what is the domain used by libc?
<zyga> this feels like a SDK runtime problem
<zyga> locale generation is perhaps more subtle
<seb128> libc.mo
<seb128> SDK sort of
<zyga> but I think a snap developer should just end up with a bunch of .mo files
<zyga> that they can even filter out if they want
<seb128> gettext() is not specific to a SDK
<zyga> yes, but SDK should just solve it for people
<zyga> for just fishing parts of binary debs, it feels tricky
<seb128> it could
<zyga> so back to interfaces
<zyga> we could design an interface that lets you do bind mounts and other magic
<zyga> I just wonder if that's a solution (it doesn't feel like one)
<seb128> yeah, maybe not
<seb128> maybe we just make those part of pd
<seb128> and declare that core users can't have translations
<zyga> basic locales? I would say yes
<zyga> core users will probably use webapps
<zyga> and if not, they can bundle the world if they want a custom kiosk localized GUI
<seb128> well, I guess as long as we provide easy tools to help them to bundle the world...
<seb128> it still feels to me that locales are a base feature of the OS and shouldn't have to be bundle
<zyga> I think we should explore both sides, patching sources to understand snap runtime layout and environment variables and reach for low-hanging fruit
<seb128> but it's a good point that they take space and are not needed on a core
<zyga> eventually I would hope that all important upstream projects have a getenv("SNAP") somewhere
<seb128> is having the deb repackaging case working a goal
<zyga> and that they just work
<seb128> or just something hacking we play with?
<zyga> that depends on if the upstreams support snap internally :)
<seb128> yeah, I don't agree with that
<zyga> I think our patches to n-m weren't merged
<seb128> projects shouldn't have to getenv for platform specifc hacks
<zyga> but if they were ,you could repackage nm (or be closer to) instead of having to build it
<zyga> seb128: I somewhat disagree, this is a big shift
<zyga> seb128: relocatability
<zyga> seb128: nothing really supports that out of the box yet
<zyga> perhaps it is not SNAP, perhaps SNAP Is in some common platform glue
<morphis> sergiusens: ping
<zyga> but patching upstreams for native relocatability would be worth-while IMHO
<qengho> Spin up a new autopkgtest machine that uses "dpkg --instdir=/relocated/" to install.
<popey> jdstrand: I have an app doing "Bad system call" inside a snap, in dmesg I see an apparmor failure with sig=31 arch=40000003 syscall=45 compat=1 ip=0xf77e3547 code=0x0 - is this something I can work around, a bug, or something else?
 * zyga looks
<qengho> Oh, popey. So innocent.
<popey> wat wat wat
<zyga> that's shmctl
<ogra_> scmp_sys_resolver 45
<ogra_> run that
<jdstrand> popey: on the device do 'scmp_sys_resolver 45'
<kyrofa> Hey seb128 dholbach I'm around now
<ogra_> zyga, how do you know ? it varies between arches ;)
<jdstrand> popey: it must be on the device/vm
<zyga> ogra_: yes, true, I checked for amd64
<popey> jdstrand: inside the snap?
<zyga> brb
<ogra_> :)
<popey>  this is on my laptop
<ogra_> zyga, it is brk on armhf
<jdstrand> zyga, ogra_: note the syscall numbers are different depending on the arch
<popey> (amd64)
<jdstrand> popey: ok, on amd64 that should be recvfrom
<popey> yes
<jdstrand> popey: you need to plug one of network, x11 or unity7
<jdstrand> popey: if you are, autoconnecting isn't working for you
<popey> I have all 3
<popey>     plugs: [x11, network, network-bind, unity7, opengl]
<jdstrand> popey: right, my understanding is that removing and installing again will get it to connect
<jdstrand> popey: otherwise you can manually connect
<jdstrand> zyga: I asked slvn to file a bug for that, but I think he had to step away. do you have a bug for this? ^ is it known to you?
<popey> jdstrand: removing "it" as in, the snap?
<jdstrand> popey: yes
<seb128> jdstrand, that's 32 bits code on amd64, unsure if that makes a difference?
<jdstrand> zyga: in other news, I figured out why the unintended bluez change ended up in my branch and have adjusted my processes
<seb128> if I understood popey correctly
<jdstrand> seb128: I think you just confused me :)
<jdstrand> he had a seccomp denial
<seb128> right, I'm just saying that he's multiarching
<jdstrand> so I just asked that he run scmp_sys_resolver on whatever architecture logged the denial
<seb128> k
<jdstrand> multiarch doesn't matter
<seb128> I was mentioning in case
<jdstrand> thanks
<seb128> np
<popey> bah! got into the state where I have to nuke and pave again :(
<seb128> :-(
<seb128> hey kyrofa
<seb128> is there a way to tell snapcraft to rebuild without wipping out the deb cache?
<popey> seb128: I ended up installing apt-cacher-ng on my laptop
<seb128> popey, :-(
<popey> seb128: feel free to point your apt at my laptop as a proxy ã
<seb128> but thanks for the tip
<kyrofa> seb128, you can clean individual steps of the lifecycle-- would that help?
<popey> (I appreciate you may not want to)
<kyrofa> seb128, instead of cleaning the pull, just clean back to build
<seb128> kyrofa, I ended up reworking my yaml but that feels like a workaround
<seb128> kyrofa, oh ok
<kyrofa> seb128, essentially instead of cleaning everything, you say "don't wipe out the pulled stuff."
<seb128> I ended up having 2 parts
<seb128> and cleaning only one
<seb128> I didn't know that my issue was due to "cleaning the pull"
<seb128> or that was a thing
<seb128> thanks
<kyrofa> seb128, no problem! Yeah try `snapcraft clean -s build` (by default it cleans everything, including the pull step)
<seb128> that sounds like a poor default :p
<seb128> kyrofa, thanks!
<dholbach> kyrofa, thanks... I was wondering if sergiusens, you and I could pick dates/times for the snapcraft UOS sessions
<dholbach> we're still very much free to pick times between 14 and 20 UTC on 3-5 May
<kyrofa> dholbach, yeah sounds good. sergiusens is running a few errands right now and I have a meeting in a few minutes, but after that I'm free all day
<popey> Argh, "sudo snap install mylocalfoo.snap" on a clean box will download ubuntu core, fail to install it, fail to download my local snap from the store, but install my local one anyway, without ubuntu-core. So next time I try something it tries to download ubuntu-core again!
<ogra_> uh
<ogra_> popey, so your snap is i386 ?
<ogra_> i wonder if it tries to download the matching core
<popey> nope
<ogra_> hmm, k
<ogra_> i wonder why it fails then
<popey> also, you have to remove snaps before installing them again, or you get a broken snap installed.
<popey> repeatedly installing the same snap over and over leads to a non-functioning snap
<jdstrand> popey: between those two and not autoconnecting, it sounds like you are hitting 3 bugs :\
<popey> \o/
<jdstrand> popey: 4 now :\
<roadmr> a bug trifecta
<jdstrand> popey: would you mind filing them?
<popey> sure thing
<jdstrand> I don't think any are filed
<jdstrand> thanks!
 * zyga confused signal number with syscall number
<ogra_> mvo, ricmm, http://paste.ubuntu.com/16095818/ should we start with that ?
<slvn> jdstrand, zyga : I have just retried this "auto-connect" issue with new package name, and it worked. then I did a "reset-state". the first new install was longer (installation of 64 MB ? whereas the snap is 2 Mo ...). and x11 didn't connect. re-install, it worked. To me, the issue seems something missing in the script "reset-state". Since this is non-official, should I make be a bug report ?
<zyga> slvn: interesting
<zyga> slvn: no, I'll experiment, thanks
<zyga> slvn: the first time when you installed the snap it bundled ubuntu-core with it
<zyga> slvn: when you installed the snap, was that side-loaded (locally on your FS) or from the store?
<zyga> slvn: snap install ./foo.snap or snap install foo
<zyga> ogra_, jdstrand: How do  you lookup syscalls?
<ogra_> scmp_sys_resolver
<jdstrand> zyga: signal vs syscall> easy to do
<zyga> jdstrand: I know how to lookup signal numbers
 * jdstrand wants to get to fixing snappy-debug to help people in this regard but has a few more things to tend to first
<zyga> jdstrand: but not syscall numbers
<jdstrand> scmp_sys_resolver ...
<zyga> ahhh
<jdstrand> (on the device)
<jdstrand> always on the device :)
<zyga> thanks!
<jdstrand> (unless you know your archs are the same of course)
<zyga> yeah, I had an index somewhere but I lost it now
<jdstrand> seb128: hey, I saw you mention something about trying to get the tree together for me and others to test-- what is the status (just wondering if I should move to the next thing on my list and circle back or not-- no big rush)
<seb128> jdstrand, I'm about to push
<slvn> zyga, I have always installed the snap from my FS. I haven't played with the store yet.
<dholbach> kyrofa, ok
<jdstrand> seb128: thanks
<seb128> jdstrand, ok, lp:~ubuntu-desktop/+junk/gnome-calculator-snap updated
<jdstrand> seb128: thanks!
<seb128> jdstrand, yw!
<seb128> jdstrand, I'm going to file some bugs now about the issues we had/have and the workaround we did
<seb128> jdstrand, btw got https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1576066 filed about the 32bits issue
<ubottu> Launchpad bug 1576066 in glibc (Ubuntu) "32bit glibc calls old socketcall() syscall, causing seccomp problems" [High,New]
<zyga> jdstrand: just curious, what's the outlook on non-enforcing seccomp landing in the kernel?
<seb128> jdstrand, "justincornack" says that updating libseccomp to 2.3.0 should fix it
<jdstrand> zyga: I need to work with them on it. we have a good relationship with them, it is just devmode is a couple places down the list atm
<zyga> jdstrand: sure understood
<zyga> jdstrand: is there a place where I can look at the list?
<jdstrand> zyga: at my list?
<jdstrand> the security team trello board
<zyga> jdstrand: do you have a link handy by any chance?
<jdstrand> seb128: oh interesting
<jdstrand> seb128: thanks!
<seb128> jdstrand, yw!
<seb128> jdstrand, I guess we should SRU https://github.com/seccomp/libseccomp/commit/73d83e45efbe8c31067c97155162f17ca51b7435
<seb128> desrt, ^
<desrt> this won't help
<seb128> oh :-(
<desrt> this only helps if the C library is indeed calling those new functions
<slvn> zyga, not sure you got the message : I have always installed the snap from my FS. I haven't played with the store yet.
<zyga> slvn: ah, thanks
<zyga> slvn: perhaps there's some interesting bug in that case, I'll give it a try
<desrt> actually, i may take that back.  i have no idea what this does =)
<desrt> and maybe it does contain/improve demuxing for that call, indeed
<zyga> slvn: I know for a fact that there are plenty of related bugs fixed in master (to be released very soon)
<zyga> slvn: perhaps tomorrow it will be in the archive
<seb128> jdstrand, desrt, there are also other commits in trunk that might help in fact, our version is old
<slvn> zyga, I used the same SDL2/snap of the other bug to test it.
<ogra_> you have high hopes about our SRU process it seems :)
<seb128> e.g https://github.com/seccomp/libseccomp/commit/d32c3bfa4b07add90dcd04292eb4ba278dd103ba
<zyga> slvn: right, we had a bug that didn't auto-connect in some cases, I suspect it is that, I'll check again when I have power
<seb128> though pitti backported some of those changes already it seems
<zyga> slvn: I'll ping you tomorrow, after the release is out
<slvn> zyga, I'll also tomorrow if there is some update:
<desrt> https://github.com/seccomp/libseccomp/commit/983835f3e0fd000a42c8beaea9d7fbe726ffff65
<desrt> this is the one that will really help
<desrt> " + * Convert a multiplexed pseudo socket syscall into a direct syscall "
<zyga> jdstrand: there's a micro task for home to auto-connect
<zyga> jdstrand: do you think we should set it to auto-connect and let the store flag that for review?
 * ogra_ wonders if we should prehaps grow the reviwers team 
<zyga> gahh, sorry, battery dies
 * zyga orders a new battery, power cuts are annoying
<zyga> ttyl
<jdstrand> zyga: I think autoconnecting is fine-- the store currently flags for manual review. But the topic overall has an unclear path. sabdfl said to do one thing with x11/unity7 and niemeyer another. home to me is the same sort of thing.
<mvo> ogra_: I like that, lets do it
<ogra_> mvo, ok, will upload then
<seb128> jdstrand, what's the right component to file the bug about "unity7 plug profile needs updating for menus"
<jdstrand> seb128: snapd. add the snapd-interface tag
<seb128> jdstrand, thanks
<mvo> ogra_: nice, let us try to test today/tomorrow and see how it goes
<ogra_> yeah
<ogra_> well, we need someone who has a uboot gadget snap for i386
<ogra_> i was hoping ricmm has something like that handy
<seb128> jdstrand, bug #1576287
<ubottu> bug 1576287 in snapcraft (Ubuntu) "unity7 plug needs to be updated to allow menus export" [Undecided,New] https://launchpad.net/bugs/1576287
<jdstrand> seb128: thanks
<sborovkov> Hello, how do I enable classic shell now? snap enable-classic does not work
<jdstrand> mvo: hey, does being a member of ubuntu-core on github give me commit access?
<mvo> jdstrand: hm, I actually don't know, commit access to snappy on github? just create your branch and send a pull-request
<jdstrand> mvo: I did that, but I also got an invite not long ago nad just accepted. my branch is tagged Reviewed. I wasn't sure if I should wait or commit and wanted to ask what the commit policy was
<mvo> jdstrand: oh, ok. I think I saw that there was one outstanding question on the branch. or did that get resolved? if resolved one of us will merge it
<jdstrand> mvo: I resolved it and made two reverts based on mailing list and bug feedback
<mvo> jdstrand: nice, let me have a look then, I can merge it
<mvo> jdstrand: usually (but not always) its branch-owner != person-who-merges
<jdstrand> I see
<mvo> jdstrand: we also have no separate branch for xenial and yakkety (love the name)
<mvo> (yet)
<jdstrand> ok
<seb128> jdstrand, mvo, just for the record that's some bug reports about the issues we hit when playing with gnome-calculator https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue
<jdstrand> nice
<seb128> jdstrand, I guess there is already one for the gsettings proxy work?
<seb128> or is it only in specs like https://wiki.ubuntu.com/SecurityTeam/Specifications/ApplicationConfinement?
<seb128> opened one, we can close it if needed
<jdstrand> seb128: the proper confinement for gsettings is a separate thing. snaps on classic could utilize that, but we'll likely simply need to add it and say it is a limitation of the mediation (much like X is)
<jdstrand> s/need to add it/need to add the rules for the global gsettings/
<seb128> jdstrand, right, good, thank we can use bug #1576308
<ubottu> bug 1576308 in snapd (Ubuntu) "gsettings doesn't work with snap confinement" [Undecided,New] https://launchpad.net/bugs/1576308
<wililupy> Good morning ogra_, mvo.
<ogra_> wililupy, good evening :)
<seb128> jdstrand, the libseccomp issue, gnome-calculator on i386 hits the bug (it needs to download currency info from internet), I can test patchs if you want, just ping me with commits or debs
<wililupy> I got the system to boot today after adding ahci to the initrd modules in snapcraft, but I still had to edit the grubenv file on /dev/sda2 to point to my kernel snap to boot up properly.
<jdstrand> seb128: thanks
<ogra_> wililupy, right, and that bit is out of my territory of knowledge ... mvo might be a better counterpart here
<wililupy> ogra_ Thank you so much for your assistance on this. I now have a working Kernel snap with the modules in it, so now all I have to do is snap up the application and test it and I could be back on schedule. I still need to work on the grubenv so that install is easy and doesn't require user intervention.
<mvo> wililupy: hm, is your kernel called vmlinuz and the initird.img ? the code currently assumes that
<wililupy> mvo, do you know why the grubenv doesn't update with the snappy_kernel= variable?
<mvo> wililupy: a symlink is probably fine
<wililupy> let me check mvo.
<mvo> wililupy: it should if the kernel snap is of type: kernel, could you paste your meta/snap.yaml please? I need to look what is going on
<wililupy> definitely mvo.
<mvo> wililupy: and please pastebin the output of grub-editenv right after you installed your kernel
<wililupy> sure.
<mvo> (but before you manually adjusted something)
<mvo> cool, thank you!
<wililupy> mvo: meta/snap.yaml: https://pastebin.canonical.com/155478/
<ogra_> oha
<wililupy> mvo: (hd,2)/EFI/ubuntu/grub.d/grubenv: https://pastebin.canonical.com/155479/
<ogra_> why doesnt snapcraft set "type: kernel" ?
<mvo> wililupy: could you please add "type: kernel" and see if that helps?
 * ogra_ guesses there is your issue
<mvo> aha ogra_ was faster :)
 * mvo hugs ogra_
<ogra_> heh
 * ogra_ hugs mvo 
<wililupy> I can post my snapcraft.yaml
<mvo> just add this one line first, that sounds very likely to be the culprit
<ogra_> but it is weird, given the snapcraft kernel plugin was used
<ogra_> i woudl actually expect that it sets that
<wililupy> https://pastebin.canonical.com/155480/
<wililupy> type: kernel before the parts: section?
<ogra_> in meta/snap.yaml
<wililupy> gotcha ogra_
<ogra_> and then just "snapcraft snap" the dir
<kyrofa> It seems /snap/bin is not in the PATH if I try to run with sudo. This worked in rolling-- is it a bug, or is it supposed to work this way?
<sergiusens> popey I logged bugs about install/remove/install/remove/.../.../install
<wililupy> snapcrafting now.
<sergiusens> seb128 log a bug about the ARCH thing, we can support it easily
<seb128> sergiusens, https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576232
<ubottu> Launchpad bug 1576232 in snapcraft (Ubuntu) "Doesn't allow dynamic file install targets ('usr/lib/$arch')" [Undecided,New]
<jdstrand> mvo: thanks for the merge. I'm not sure who is doing release notes, but one of those commits fixes bug #1575914
<ubottu> bug 1575914 in Snappy "snaps using home interface have full access to SNAP_USER_DATA of other snaps" [High,In progress] https://launchpad.net/bugs/1575914
<mvo> jdstrand: uh, thanks. a "Closes: LP#1575914" in the commit picks it up automatically
<sergiusens> seb128 thanks, I love bugs! :-)
<seb128> yw!
<jdstrand> mvo: oh, whoops
<jdstrand> mvo: I'll know for next time
<wililupy> mvo, ogra_ same error, I have to modify the grubenv to boot up properly.
 * jdstrand updates his notes for autoclosing snappy bugs
<mvo> jdstrand: no worries, I will add it later manually
<wililupy> weird, it didn't update the snap.yaml...
<wililupy> I updated it in the snap directory and then re-ran snapcraft snap.... hmmmm
<ogra_> E: config/hooks/15-remove-grub-common.chroot failed (exit non-zero). You should check for errors.
<ogra_> P: Begin unmounting filesystems...
<ogra_> P: Saving caches...
<ogra_> GRRR !
<wililupy> looks like snapcraft snap overwrote my meta/snap.yaml with the one without type:kernel.
<ogra_> hmm, it shouldnt do that
<kyrofa> wililupy, the snap folder it _output_, not input
<kyrofa> is*
<wililupy> kyroga, the snap directory, correct?
<wililupy> kyrofa ^
<kyrofa> wililupy, right
<ogra_> kyrofa, we only wannt to check a one line change in snap.yaml .. and not re-build anything but the snap
<om26er> stgraber, Hi! ChrisTownsendwas helping me debug an lxc container not starting, he suggested me to show the logs to you. Can you please take a look at these logs ? http://paste.ubuntu.com/16102061/
<wililupy> I modified the snap/meta/snap.yaml there, then went back to my source directory and ran snapcraft snap.
<kyrofa> ogra_, try `snapcraft snap snap` then?
<kyrofa> ogra_, tell snapcraft to use the snap directory to create the snap rather than going through its lifecycle to do so
<wililupy> I'll t ry that, can't hurt
<ogra_> kyrofa, yeah, thats what i mean abover with <ogra_> and then just "snapcraft snap" the dir
<ogra_> :)
<ogra_> i should have written "snapcraft snap snap" :)
<kyrofa> wililupy, ogra_ it's also worth noting that snapcraft will re-generate the meta/ directory each time, even if the rest of the lifecycle has already run
<ogra_> oh
<kyrofa> wililupy, ogra_ i.e. you don't need to rebuild the project just to change the meta/ dir
<ogra_> well, he could just move the snapcraft.yaml away :)
<ogra_> then it will just roll the dir into a snap
<ogra_> without regenerating anything
<wililupy> meta/snap/snap.yaml still has my changes after running snapcraft snap snap
<wililupy> Another u-d-f and a burn in on the device...
<ogra_> mvo, hmm, not sure why but seems my changes to live-build/ubuntu-core/hooks/15-remove-grub-common.chroot make the world explode (on all arches)
 * ogra_ doesnt understand why ... very weird 
<ogra_> http://paste.ubuntu.com/16103786/
 * ogra_ scratches head
<wililupy> ogra_, mvo, kyrofa: That did it!!
<ogra_> wililupy, well, we still dont know why snapcraft.yaml doesnt add the type field
<ogra_> it should do that by default with the kernel plugin
<wililupy> yeah, should I put in a bug?
<ogra_> sergiusens, ^^^ is that a bug ? (kernel plugin not setting type: kernel in snap.yaml)
<sergiusens> ogra_ you have to do that in your snapcraft.yaml
<ogra_> sergiusens, https://pastebin.canonical.com/155480/
<ogra_> does it need extra mentioning of type: kernel ?
<sergiusens> ogra_ yes
<ogra_> ah !
 * ogra_ didnt know :)
<sergiusens> ogra_ we have no contract for plugins changing top level things
<ogra_> pfft :P
<sergiusens> ogra_ it is a constant discussion we have internally as it would be ideal to also create apps and commands
<ogra_> yeah
<sergiusens> ogra_ but then what happens when the use wants to do something special :-)
<ogra_> well, if it is set at the top level you dont touch it ... if nothing is set at the toplevel the plugin takes over
<sergiusens> ogra_ what if you want to payload a kernel in a normal snap app?
<sergiusens> for some weird reason
<ogra_> notmal snaps dont have a type ?
<ogra_> *normal
<sergiusens> ogra_ implicit type 'app'
<wililupy> sergiusens, so where in my snapcraft.yaml to I tell it that it is a type: kernel snap?
<sergiusens> wililupy same level as name, summary, ...
<wililupy> sergiusens: so after description: add type: kernel before parts:
<sergiusens> wililupy order doesn't matter in yaml, just make it at the same level
<wililupy> sergiusens: ack. Going to try it now.
<sergiusens> ubottu hey
<sergiusens> kyrofa hey, can you reach nodejs.org?
<kyrofa> sergiusens, yessir
<sergiusens> darn, what happened to my DNS?
 * sergiusens reboots router
<sergiusens> kyrofa here you go https://github.com/ubuntu-core/snapcraft/pull/490
<sergiusens> kyrofa that is the one you thought of when you thought you thought incorrectly
<sergiusens> elopio do you know the status of https://github.com/ubuntu-core/snapcraft/pull/480 ?
<sergiusens> ogra_ so I push this (https://launchpad.net/snapcraft/+milestone/2.8.5) to yakety; wait for it to go in smoothly and then tag every bug in there to hint the SRU and then dput to xenial and wait?
<sergiusens> is that it in a nutshell?
<kyrofa> sergiusens, ah, you're right :P
<ogra_> sergiusens, yeah
<ogra_> there is a wikipage too for it
<sergiusens> ogra_ I read the wiki page, twice; it assumes I know a bunch of things already :-)
<sergiusens> ogra_ thanks
<ogra_> heh
<ogra_> bah ...
<ogra_> so i cant remove /boot/grub on the os snap because there is a file in it !
<ogra_> silly stuff ...
<ogra_> unicode.pf2
 * ogra_ removes it anyway
<oparoz> Is there a particular reason the command wrapper changes the working dir to SNAP_DATA?
<ogra_> it is the writable dir the snap provides ....
<ogra_> (the default writable dir)
<sergiusens> oparoz afaik it doesn't unless you tell it to
<oparoz> Sure, but isn't it the user's responsibility to call commands from SNAP_DATA?
<oparoz> sergiusens, maybe it's because I'm still on an older rolling Snappy then
<ogra_> the user would call from SNAP_USER_DATA ;)
<sergiusens> oparoz yeah, not seeing it http://paste.ubuntu.com/16118454/
<ogra_> SNAP_DATA is somewhere in /var/lib ... it is the writable bit your snap knows about and if executed without any cotext that is the place where binaries can write
<kyrofa> sergiusens, the wrapper cds into it
<sergiusens> kyrofa not from what I am seeing here though
<sergiusens> look at my pastebin
<ogra_> if you execute a snap app in context of a user, then SNAP_USER_DATA is your place
<sergiusens> unless you are talking about a daemon
<oparoz> ogra_, let's say the user wants to wget something from a folder in SNAP_DATA, the files end up in the root of SNAP_DATA instead of the folder
<sergiusens> kyrofa the qtlaunch script does iirc
<sergiusens> but it is meant for UI apps, launched from a desktop file, so it should not really matter
<kyrofa> sergiusens, oh, it was services with a workingdir I think
<ogra_> oparoz, that shouldnt happen, the stuff should end up in SNAP_USER_DATA in such a scenario ...
<ogra_> (i know it did in the past by default when i used my unconfined wget)
<oparoz> ogra_, sergiusens that's the wrapper that gets created https://paste.ubuntu.com/16118505/
<oparoz> Just before ubuntu-core-launcher, there is a cd $SNAP_DATA
<oparoz> sergiusens, ogra_ could it be because of the security policy?
<kyrofa> oparoz, probably an old version, I don't see it in the current: https://github.com/ubuntu-core/snappy/blob/master/snappy/binaries.go#L62
<oparoz> I mean does it have an influence on the wrappers?
<ogra_> it could well be that i'm not up to date ...
 * zyga smells 15.04 snappy
<ogra_> regarding my knowledge
<zyga> oparoz: that's 15.04 right?
<kyrofa> zyga, nah, not 15.04
<oparoz> Thanks kyrofa
<oparoz> zyga, thats the mvo image from february
<zyga> ah
<zyga> ancient stuff then
<kyrofa> zyga, so rolling stable
<oparoz> Indeed
<zyga> SNAP_APP_doesn't exist anymore
<ogra_> february  ?
<ogra_> you should really update
<kyrofa> ogra_, to what? A 16 image? :P
<ogra_> yeah ...
<oparoz> :)
<ogra_> feb is definitely before 2.0
<kyrofa> Indeed
<zyga> oparoz: you can use my script to build a new image using mvo's udf
<zyga> oparoz: github.com/zyga/devtools
<ogra_> for 16.04 only the images from the last two weeks are actually ok
<zyga> oparoz: though images are not fully supported now, you may have to re-flash periodically as we stabliize
<zyga> ogra_: full of bugs, the next set will be okay (with next version of snapd)
<oparoz> Thanks zyga, the problem is that all users of the ownCloud snap are still on that image, so I can't update yet
<ogra_> sure, full of bugs, but up to date with the right concepts at least
<ogra_> while all older images are simply broken
<zyga> oparoz: I see
<oparoz> But thanks for confirming that the change of dir doesn't happen any more
<zyga> ogra_: I agree
<zyga> there were more changes in the last month than in the year before
<oparoz> ogra_, we have enough trouble getting people to test the image. If they need to re-flash every week, we're going to lose all of them
<ogra_> yeah, understood
<zyga> oparoz: it would be nice to at least switch to 2.0 snappy because that old image feels like tech debt personified, it's going to bite you more the longer you wait
<oparoz> But yeah, it's problemtic because some problems don't apply any more
<ogra_> it is just that any development you do on them is moot ... since the design of snappy changed a lot
<zyga> you probably require an interface, you won't find that on that old image
<kyrofa> zyga, still using old-security there. Fortunately the interfaces required are simple (network and network-bind)
<zyga> I think you have a tough choice ahead
<zyga> kyrofa: cool, nothing fancy to access hdds?
<kyrofa> zyga, we're splitting partitions
<zyga> kyrofa: ah, interesting
<oparoz> We're going to have to switch in the next 2 weeks anyway
<kyrofa> So the upgrade path is actually pretty easy. It's just that 16 a) isn't stable and b) doesn't seem to support preinstalling snaps so we can't generate a factory image
<kyrofa> Unless mvo's new u-d-f fixed the --install and it works on 16
<zyga> we're working on making udf saner again but it's still a roadmap
<ogra_> i thought that was fixed a while ago
<zyga> I mean a permanent fix
<zyga> not another layer of duct tape
 * ogra_ doesnt know what everyone has against duct tape ... 
 * oparoz agrees :D
<oparoz> except when it comes to software development ;)
<zyga> I'd hear what you say if I dind't have duct tape over my ears ;)
<ogra_> well, at least you'll get rid of these hairs in your ears then :P
<kyrofa> zyga, anyway, we'd love to jump to 16. But we need those things
<kyrofa> So rolling stable is at least giving people something to test
<zyga> kyrofa: those things?
<kyrofa> stability and preinstalled snaps
<zyga> kyrofa: I'm not sure I know what you refert to now
<zyga> ah
<zyga> stability as in debian stable, that I understand
<zyga> preinstalled snaps, soon :)
<zyga> ish
 * zyga loves 'ish'
 * ogra_ used to work for "ish" 
<oparoz> zyga, weeks?
<zyga> oparoz: ask me after the next sprint
<oparoz> zyga, OK
<zyga> oparoz: now I can reliably predict by looking at coffee leftovers or other wizardy
<kyrofa> oparoz, which is in 10 days
<zyga> ish
<zyga> yep
<ogra_> https://de.wikipedia.org/wiki/Ish_%28Unternehmen%29
<ogra_> (not even available in english )
<kyrofa> ogra_, wait.. you were serious? :P
<zyga> LOL
<ogra_> yeah :)
<zyga> that explains a lot ;)
<zyga> hehe
<zyga> lovely company name
<ogra_> that was my last job before canonical ...  leading a tech team of 15 ppl
 * zyga recalls the company that makes light bulbs "osram", which is very popular in poland despite the name
<ogra_> cable internet was the new thing in germany back then
<kyrofa> I can hear the promo now: "Stable... fast.. _ish_"
<oparoz> (kyrofa, 10 days is good, we can make a decision then)
<kyrofa> Hey sergiusens I figured out what was wrong with the ROS example
<kyrofa> sergiusens, it's a locale issue-- setting LC_ALL=C fixes it
<kyrofa> sergiusens, I guess something changed on xenial?
<ogra_> should be C.UTF-8 nowadays
<ogra_> (and iirc thats the default fallback in xenial)
<kyrofa> ogra_, setting that works too, but without it it barfs
<kyrofa> ogra_, but my ignorant american self doesn't know very much about locales :(
<ogra_> yeah, you're i ascii-land
<ogra_> wow, snapcraft grew some solid dependencies ...
 * ogra_ notes while reading image build logs that it pulls in 30 packages and eats 10MB nowadays
<ogra_> (50MB installed)
<oparoz> IF I want to add "reload to a daemon, I simply add reload-command to the "app" in the yaml?
<zyga> oparoz: not sure
<zyga> gimme a sec
<oparoz> https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
<oparoz> No mention or reload, so I gues not...
<zyga> one sec :)
<zyga> checking now
<oparoz> Thanks zyga :)
<zyga> oparoz: so there's restart condition
<zyga> but there is no restart command
<zyga> wait
<zyga> checking services
<oparoz> zyga, I've noticed that restart works out of the box, but reload doesn't, so I thought I needed to add something to the yaml
 * ogra_ sighs ... livecd-rootfs doesnt like me today
<zyga> there are ExecStop
<zyga> ExecStopPost
<zyga> ExecStart
<zyga> and that's it
<oparoz> :(
<zyga> there's also Restart
<zyga> what are you looking for exactly?
<ogra_> cant you send a HUP to the process if it is in the same snap ?
<oparoz> zyga, in quite a few situations, you just want to reload a config without having to bring everything down and up again
<zyga> oparoz: do what ogra_ said
<oparoz> OK, I will give it a go
<oparoz> pkill didn't work, but kill did, thanks ogra_
<ogra_> good
<wililupy> ogra_ adding the type: kernel to the snapcraft.yaml makes it work as designed!
<ogra_> yay
<wililupy> No need to change anything manually.
<ogra_> good you finally got everything working :)
<wililupy> Yes!
<wililupy> Now on to building the app snap. This should be a little more straight forward.
<zyga> oparoz: pkill would need /proc access
<wililupy> Thank you so much ogra_, mvo, sergiusens, kyrofa!
<zyga> morphis: any updates on https://github.com/ubuntu-core/snappy/pull/1036
<ogra_> np
<oparoz> Ah, thanks zyga. That was a question I had. Any daemon requesting access to /proc is hutdown, correct?
<zyga> oparoz: not really, just denied access to pkill wound't be able to find all the details probably
<zyga> oparoz: (depending on how pkill is written)
 * zyga should finish the current post on snappy security
<oparoz> zyga, OK, so denied access which some "app" may not be too happy about
<ogra_> yay, finally ...
 * ogra_ has the images building again 
<zyga> ogra_: cool :-)
<ogra_> silly stuff ...
<ogra_> something like:
<ogra_> [ -d /boot/grub ] && rm -f /boot/grub
<ogra_> makes everything explode ...
<ogra_> because on all arches where that dir doesnt exist the test exits non-zero and tears down live-build
 * ogra_ hates that common sense doesnt apply in some cases ...
<zyga> ogra_: like almost always?
<ogra_> heh
<zyga> ogra_: note that common sense is just that, common, it's not really always sensible :)
<kgunn> zyga: i was just wondering, when hacking on snap/snapd and using your tools...i was just doing refresh-bits snap/snapd/run-snapd...but should i be doing 'refresh-bits setup' first ?
<ogra_> so true
<kgunn> i'm still not seeing any of my changes applied when i run the tools
<kgunn> fwiw, i did try doing refresh-bits setup...but didn't make a diff
<zyga> kgunn: setup is needed once per vm boot
<zyga> kgunn: it ensures that regular snapd doesn't start by accident
<zyga> kgunn: I run setup snapd run-snapd; then only snapd run-snapd
<zyga> kgunn: what were you hoping to happen?
<zyga> kgunn: what changes?
<zyga> kgunn: after you push the new snapd to your VM you should uninstall/reinstall your mir snap
<zyga> kgunn: and observe interfaces reported by snap interfaces
<zyga> kgunn: and observe generated apparmor/seccomp profiles
<kgunn> zyga: so question...if i don't install mir snap at all, and only run the mod'd snapd...and i type snap interfaces...i should see the mod correct?
<zyga> what mod?
<kgunn> zyga: mod== addition of an interface called mir
<zyga> what were you expecting to see exactly, from what I remember from your branch you woundn't see anything new
<zyga> there is no way to see the list if interfaces
<zyga> just the list of plugs and slots
<zyga> those come from snaps
<zyga> note that the OS snap would *not* offer the mir slot
<zyga> it would be offered by mir itself
<zyga> so you'd have to install new snapd, install mir (snap) and see what the rsult is
<kgunn> ok
<zyga> does that make sense?
<zyga> snapd would contain the implementation of mir interface
<zyga> but that would only show up when you install the mir snap
<zyga> normally snappy logs and ignores unknown interfaces on snaps
<zyga> but with your patches, mir snap would really gain the mir slot
<zyga> and would really gain the permanent permissions resulting from that slot
<zyga> right?
<kgunn> zyga: ok, maybe i've been trying to see something that simply won't happen
<kgunn> i'll fiddle a bit more later with this...good to know on the setup run first time on vm tho
<sergiusens> kyrofa sadly saying please is mandatory
<ogra_> you could also friendly say please though
<ogra_> :P
<sergiusens> ogra_ not to a build system that decides to fail :-P
<sergiusens> ogra_ imagine saying please to livecd rootfs ;-)
<ogra_> i did, it helped !
<thekeymaker> if you are building snaps using snapcraft on ubuntu 16.04, is there a easy way to try(run) them instead of installing them with the command snap install ./my-snap?
<zyga> thekeymaker: not yet
<zyga> thekeymaker: though installing them is very lightweight
<zyga> thekeymaker: we just copy and mount them
<zyga> there are plans to add a new command that will be even better but that's not finalized
<zyga> thekeymaker: and also note that unless you run master you should remove the snap first, this will avoid hitting a number of known, fixed but (not released) bugs
<oparoz> zyga are symlinked followed when a snap is removed or purged?
<oparoz> *symlinks
<zyga> I'm not sure, probably
<zyga> but I don't really know and it's rather too late for me to check now
<zyga> (and give you an accurate answer)
<oparoz> yeah, no worries, was surprised to still see you here ;)
 * zyga is writing a very long article 
<oparoz> Ah :)
<Domi> Hello, does anyone use Python in a snap?
#snappy 2016-04-29
<genios> Domi, I am *trying* to
<sergiusens> What is your problem when using python?
<morphis> zyga: later today
<morphis> need to finish a bunch of non-snappy stuff first
<zyga> sure, thanks
<pippo> hello
<zyga> hey
<pippo> I'm wworking with what is called snappy for IOT and I've been having problems with 15.04 and 16.04. I need webdm, Webdm for 15.04 does not exist in the market. Hoping that webdm is present in the 16.04 market i tried to use it but this version of ubuntu-core is not present in the default ubuntu-device-flash server. Can someone help me?
<pippo> Besides, the snappy-tools package is not present in the 16.04 desktop. but this is another problem.
<pippo> s/16.04 desktop/16.04 snappy-tools repo/
<qengho> 15.04?
<qengho> You lost me right there.
<pippo> you don't read? it could be my client
<pippo> hi
<pippo> someone knows if webdm is going to be reintroduced in 15.04? (i tried to use 16.04 but it is not available) (i'm talking about snappy for "iot" armh)
<pippo> ok I see that webdm was reintroduced in the 15.04 market.
<qengho> pippo: Where do you see that?
<zyga> pippo: 16 is not released yet
<zyga> pippo: webdm should be available in the store soon but is still under development
<zyga> pippo: 15.04 is almost guaranteed not to be supported anymore AFAIK
<zyga> pippo: (webdm soon == for 16)
<pippo> what is not available ? webdm for 16.04 or 16.04 core? ubuntu-core 16.04 is not present in the default ubuntu-flaash-device server.
<zyga> nothing yet
<zyga> all that is available is the source under development
<mvo> ogra_: I think we need an initramfs update for uboot on x86, I will work on this in a bit, it seems like it is acting really silly
<ogra_> mvo, oh ?
<ogra_> given that only grub bits were dropped from the image that is weird
<ogra_> it shouldnt behave any different from uboot on armhf
<ogra_> (i havent seen any arch specific code )
<mvo> ogra_: the initramfs code is just plain silly, I upload in a bit once you see the diff it should be obvious
<ogra_> there is a lot silly stuff in the old initrd code :)
<mvo> ogra_: yes :)
<mvo> ogra_: I'm just double checking a few things before the upload to not make things worse
<ogra_> mvo, btw, should we perhaps rename /etc/system-image before final ?
<ogra_> i know thats just cosmetic ... :)
<mvo> ogra_: yeah, good idea
<ogra_> but the german in me screams seeing it all the time there :)
<mvo> ogra_: what german in you?!?
<ogra_> lol
<pippo> ogra: i'd like to generate snappy-tools (for 16.04 desktop) and ubuntu-core 16.04 (for arm) from sources, is there some doc? (for the second one I suppose this is the place: https://github.com/ubuntu-core/snappy)
<ogra_> pippo, the latter one happens in your image build infrastructure ... thats rather complex
<ogra_> we use live-build to create the rootfs snaps with the configuration from the livecd-rootfs package in the archive
<pippo> well, I have to migrate from 15.04 to 16.04. If the packages are not available from ubuntu-device-flash to download I have to generate it somehow.
<pippo> "complexity" is not a problem ;)
<ogra_> what do you mean by " If the packages are not available "
<ogra_> mvo, so amd64 building fails ...
<ogra_> boot/ubuntu bind mount failed with: exit status 32 mount: mount point /tmp/diskimage835456834/system/boot/grub does not exist
<zyga> pippo: core snap is available but the kernel and gadget snaps are being redesigned
<ogra_> seems we need a mkdir in u-d-f
<pippo> i mean that 16.04 is not here: https://system-image.ubuntu.com/ubuntu-core/
<zyga> pippo: so no matter if you can build stuff from source, you will also chase a moving target
<ogra_> zyga, well, all sbnaps are "available" currently
<ogra_> both, in the store and on cdimage.ubuntu.com
<zyga> ogra_: "yes"
<zyga> ogra_: "available" but not released
<ogra_> and they usually produce bootable images
<zyga> usually :)
 * zyga loves our optimism
<ogra_> well, the ones in the store "always" :)
<zyga> "this bridge is not finished but we let people use it every day, trucks too"
<zyga> "it ususally doens't fall apart"
<zyga> "we rebuild it every night too"
<zyga> "last night it was blue"
<ogra_> cdimage is currently broken due to the "uboot on i386" crazyness :)
<ogra_> but the store is a manual thing ... i personally dont uzpload anything that i didnt smoketest
<zyga> in the end we'll build a tunnel
<ogra_> you might need to re-flash them if format changes, but you shoudl always be able to use the userspace for testing development stuff
<qengho> At Release Day, disk image uploads quiet down, right?
<ogra_> we're rolling :)
<qengho> So, we have to fix that.
<ogra_> release day only marks when we start with that officially ;)
<qengho> Software is hard. :(
<zyga> usually hardware is hard
<zyga> software just ships broken
<zyga> but has a splash screen so it's all good
<ogra_> the really good SW has a splash *and* a progressbar
<zyga> while being on fire ;)
<ogra_> mvo, woah ... so your image build failed ... in chpasswd for the ubuntu user ?!?
 * ogra_ doesnt get why that would fail all of a sudden
<mvo> ogra_: eh, that is very surprising
<kyrofa> Good morning
<ogra_> mvo, yeah, totally not logical ... nothing changed
<zyga> ogra_: friday failure syndrome
<ogra_> zyga, well, there is no reason at all why it could fail ... no code changes, no changes in the archive that could even remotely touch chpasswd behaviour
<zyga> ogra_: we saw totally weird autopkgtests errors this morinng
<ogra_> but it now fails reproducable
<zyga> ogra_: no idea what the cause ise
<zyga> is*
 * ogra_ starts a yakkety build ... to check if that fails too 
<ogra_> mvo, yakkety builds :/
<mvo> ogra_: all broken?
<ogra_> xenial, yes
<ogra_> yakkety not ...
<ogra_> the only thing that changed in the archive since the last working xenial build was bind9
<ogra_> but i see no reason why that should make chpasswd fail
<ogra_> Get:52 http://ftpmaster.internal/ubuntu xenial-updates/main arm64 libisc-export160 arm64 1:9.10.3.dfsg.P4-8ubuntu1 [124 kB]
<ogra_> Get:53 http://ftpmaster.internal/ubuntu xenial-updates/main arm64 libdns-export162 arm64 1:9.10.3.dfsg.P4-8ubuntu1 [534 kB]
<ogra_> Get:31 http://ftpmaster.internal/ubuntu xenial-updates/main arm64 debootstrap all 1.0.78+nmu1ubuntu1.1 [35.7 kB
<ogra_> the only three packages we get from xenial-updates
<ogra_> and debootstrap only adds a yakkerty link ... must be one of the two other libs
<ogra_> (which obviously come from bind9)
 * ogra_ ponders to push a rool-back package to the PPA 
<ogra_> *roll
<zyga> jdstrand: hey
<zyga> jdstrand: I found something curious/buggy yesterday
<zyga> jdstrand: I wanted to ask you before proposing a fix
<zyga> jdstrand: also seems like might be a CVE if you look at it the right way
<ogra_> mvo, oh, lovely ... bug 1576378 touches our bootloader work too ...
<ubottu> bug 1576378 in snapd (Ubuntu) "Snap installing doesn't work in live session" [Undecided,Confirmed] https://launchpad.net/bugs/1576378
<ogra_> "can not set next boot: cannot determine bootloader"
<mvo> ogra_: oh, right
<mvo> hmm
<ogra_> i guess firstboot will also barf with the /boot/grub dir returned in the rootfs
<ogra_> do we have any i386 uboot gadget yet that we could test with ?
<ogra_> ricmm, ^^^^ ?
<ricmm> not from me, we need AceLan for that and Taipei is asleep
<ogra_> hmm, k
<ricmm> send him an email
<ogra_> i will, once i got the images back to building
 * ogra_ hopes the bind9 rollback will fix us
<ricmm> sounds terrible
<ogra_> it is
<ogra_> and it ate my day so far :)
<ricmm> ogra_: could be worse :)
<ogra_> yeah,. it could rain or some such ...
 * ogra_ taps foot waiting for the arm PPA builders
<sergiusens> kyrofa care to take a glance at https://github.com/ubuntu-core/snapcraft/pull/480/files ?
<kyrofa> sergiusens, sure, I'll trade you for my quickly bloating https://github.com/ubuntu-core/snapcraft/pull/454
<kyrofa> sergiusens, I'm starting to not like maintaining snappy docs in snapcraft. Things change without our knowing
<zyga> kyrofa: interfaces?
<kyrofa> zyga, like the removal of services, or --allow-unauthenticated
<zyga> ah, yeah
<kyrofa> Err, removal of snappy service
<zyga> well, bumpy ride
<kyrofa> zyga, perfectly natural, just makes for sloppy docs
<kyrofa> zyga, since we don't realize we're out of date until we actually hit something
<kyrofa> zyga, or someone complains :P
<zyga> yeah, I completely understand and agree
<ogra_> finally, bind9 built ...
 * ogra_ kicks an amd64 image with the rolled back version ... lets see
<vila> kyrofa, sergiusens: speaking of being out of date, the macaroon MP aims at reducing the gap between the store and snapcraft regarding '16', there are more work to be done still, but the switch from OAuth to macaroons should happen sooner rather than later to get feedback from users
<beuno> sergiusens, kyrofa, FYI, we're dropping oauth support very soon
<beuno> so without vila's branch, snapcraft will break soon  :)
<ogra_> mvo, definitely not the bind9 upload ... still fails
 * ogra_ rips livecd-rootfs from the PPA 
<ogra_> next build running ...
<slvn> hey! just wondering about icons on snap. not sure that putting a file "./setup/gui/icon.png" is working .. is there a GUI to see my installed snap and there icons ?
<zyga> svij: nope, not yet
<zyga> slvn: ^^
<zyga> sorry, svij:
<slvn> zyga, ok np !
<ogra_> mvo, so even removing all packages from the PPA (except your initrd change) make chpasswd fail
<ogra_> oh, crap
<ogra_> LP lied ... the livecd-rootfs package still comes from the PPA despite having been deleted
<slvn> zyga, another remark: it seems to me libpng12.so is accessible (because I don't provide it in my snap). but libjpeg is not, so that I need to provide it in the snap to get jpeg image loaded through SDL2_image!
<ogra_> *sigh*
<zyga> slvn: you need both, you cannot access libpng12.so from the OS
<slvn> zyga, well it seems this is possible :/ all my png images gets loaded correctly !  (and when I do "ldd on my snap binary, it requires : libpng12.so.0 => /lib/x86_64-linux-gnu/libpng12.so.0 (0x00007f8eb9799000))
<zyga> slvn: indeed
 * zyga wonders why we need libpng in the OS snap
<zyga> slvn: it's safer to include your own copy
<zyga> slvn: though I cannot say as to when we will remove libpng from the os snap or if we ever will
<slvn> zyga, ok .. then I'll include it
<zyga> ogra_: is there a nice tool / website that shows the seed for ubuntu-core and how it results in the effective set of packages included?
<ogra_> zyga, there might be some germinate wikipage, not sure
<quagland> hi, does anybody know of an easy way to disable apparmor for created snaps for testing purposes?
<jdstrand> quagland: install the snap with --devmode
<zyga> quagland: yes, http://www.zygoon.pl/2016/04/snap-install-devmode.html
 * jdstrand let's zyga handle it from here
<zyga> :D
<zyga> I just use my crude language skills to describe what I work with :)
<sergiusens> beuno that branch was missing something rather important, unit tests; while that is being worked on I don't want to switch to it.
<vila> sergiusens: I thought that was settled with elopio, faked tests can be good while you can't test the real code, but this branch already test the real code so fakes are not needed and will only create paperwork
<quagland> thanks for the --devmode argument, looks like still got some investigating to do - trying to get a java snap (with bundled jvm) working to no avail
<vila> sergiusens: with unit tests using fakes for Oauth, snapcraft will happily keep passing tests even when it stop working
<kyrofa> vila, that's not an argument for having integration tests instead of units-- it's an argument for having both
<vila> sergiusens: with tests using real code both snapcraft and the server team have the opportunity to learn earlier that something broke
<vila> kyrofa: if the client and the server were in the same project they would be unit tests, just like a snappy command calls its internals
<vila> kyrofa: we don't have that, we have a staging server, that's better than fakes
<kyrofa> vila, having tests that make sure we stay in sync with the real server is great. But we also need tests making sure our code works the way we think it does. Just because the server could change isn't a reason not to cover the code in unit tests
<vila> sergiusens, kyrofa: can we relax the definition of unit vs integration tests ? I don't think it helps getting progress. I'm focused on reducing the feedback loop between snapcraft and the store
<vila> kyrofa: and I don't think it helps anybody to know that the code does what he thinks it does if it does the wrong thing
<vila> kyrofa: don't get me wrong,
<josepht> I've discovered some squashfs inconsistencies on pi2.  http://paste.ubuntu.com/16127818/
<vila> I /do/value layered and focused tests
<vila> kyrofa: and I like my test to allow reproducing and fixing bugs, fakes don't help with that and as far as the snapcraft part dealing with the server, fakes won't help either. I did ran into that when I started working on that branch
<josepht> jdstrand: ^ this is related to why my nmap snap built on pi2 fails click-reviewers-tools
<kyrofa> vila, the code doing the wrong thing as defined by what? By a service external to snapcraft. The snapcraft code would still be doing what it was designed to do, and passing its unit tests as a result. If that becomes the wrong thing with regards to the external service, that's exactly what an integration test is made to catch
<kyrofa> You see how there are different layers here?
<jdstrand> josepht: oh that will be helpful. I had this in a trello card but just filed bug #1576763
<ubottu> bug 1576763 in click-reviewers-tools (Ubuntu) "pi2 images generate different checksums on repeated runs" [Undecided,New] https://launchpad.net/bugs/1576763
<jdstrand> josepht: can you check the version of squashfs-tools that the pi2 system is using?
<jdstrand> josepht: also, attaching the offending snap would be great
<josepht> jdstrand: I added both to the bug.  Thank you
<jdstrand> josepht: thank you! :)
<josepht> jdstrand: my pleasure
<ogra_> mvo, mystery solved ... task header missing in initramfs-tools-ubuntu-core and ubuntu-core-config ... the latter ships the extrausers pam config ... that is why chpasswd failed
<slvn> zyga, another thing I noticed : I don't know what is value of the current directory when running a snap. So I had to do a "chdir($env(SNAP))" to get file loaded correctly.
<sergiusens> mvo still around, need to ask you SRU strategy questions and how you will deal with it
<zyga> slvn: I don't think the directory is modified, I might be wrong
<slvn> zyga, currently it is the real cwd (same as the shell). but the snap is confined .. so (for me) it's better to have it set to $env(SNAP). not sure what should be done
<zyga> slvn: I think that's the desired behavior
<slvn> ok
<slvn> np
<zyga> slvn: e.g. when the snap is using the home interface
<vila> kyrofa, sergiusens: sorry for the interruption, desktop crashed hard
<slvn> (need to go away)
<slvn> zyga, I don't use the "plug home"
<vila> I didn't get anything after:
<vila> <vila> kyrofa: and I like my test to allow reproducing and fixing bugs, fakes don't help with that and as far as the snapcraft part dealing with the server, fakes won't help either. I did ran into that when I started working on that branch
<zyga> slvn: yes but if you did, would you expect snappy to behave differently for such a basic operation/
<vila> ... and that wasn't a crash test ;)
<kyrofa> vila, I didn't notice for a bit too long :P
<kyrofa> <kyrofa> vila, the code doing the wrong thing as defined by what? By a service external to snapcraft. The snapcraft code would still be doing what it was designed to do, and passing its unit tests as a result. If that becomes the wrong thing with regards to the external service, that's exactly what an integration test is made to catch
<kyrofa> <kyrofa> You see how there are different layers here?
<vila> kyrofa: then you're talking about the tests around _store.py which defines the internal API between snapcraft and the next layer which is storeapi, I can agree with that. But storeapi deals with the store
<vila> kyrofa: it cannot be tested without the store
<vila> kyrofa: the analogy would be for snapcraft to test without involving mksquashfs but fake it in memory
<vila> kyrofa: or testing the clean command without building a snapcraft.yaml
<kyrofa> vila, how do you test error handling if you only talk to the real store?
<sergiusens> vila to be clear you are saying that doing something like this https://github.com/ubuntu-core/snappy/blob/master/store/store_test.go#L179 is impossible?
<vila> kyrofa: for the edge cases where it's less effort to fake the errors, that's indeed what I did
<vila> sergiusens: not impossible, but less valuable as fakes bitrot
<sergiusens> vila in the case of mksquashfs, we trust that the interface for that won't change (how it is called and what it will generate), but we make sure in a unit test we called it the right way
<vila> sergiusens: certainly fakes are better than not testing, but testing against the real thing is better than testing with fakes and when the real thing is available, why use fakes ?
<sergiusens> vila fakes should not bit rot; you will not be around forever to keep this working, we need ensurance that when we change something it won't break badly
<sergiusens> vila you don't understand, we need both
<sergiusens> I am really really sad you don't see that
<kyrofa> vila, we're not saying that we don't want to use the real store. Those tests are very valuable
<vila> sergiusens: I'm really sad that you don't see that using fakes means you will have to wait for your users reporting bugs rather than having the tests fail as soon as one side makes a wrong change
<kyrofa> vila, in that case the integration tests fail
<vila> sergiusens: and if I won't be around, the test will
<sergiusens> vila and if the store is down during maintenance? and if I want to develop while on an airplane?
<vila> kyrofa: you're back with the dichotomy between unit and integration, it's a continuum
<kyrofa> vila, okay-- "in that case the tests with talk to the staging server fail"
<kyrofa> s/with/which/
<vila> fail if the server is down, skip if you're on the airplane
<kyrofa> vila, how is that different than what you've currently done?
<vila> but if you're changing code dealing with the server on an airplane you can't test them either
<kyrofa> vila, exactly. Not to mention such things are run in CI
<kyrofa> vila, it won't merge if it's broken
<sergiusens> vila bottom line, if the branch is not green, it is not landing; that means you cannot drop code coverage
<sergiusens> vila if you don't want to do it, don't.
<sergiusens> we will, but until then it does not land
<vila> ...
<vila> Snapcraft has the ability to upload snaps for publication in the Snappy Store.
<vila> If you're working on a feature that requires you to interact with the store, you
<vila> might want to use the staging server instead of the production store.
<vila> Your call, it's your project, I'm trying to help
<beuno> vila, yeah, I think at this point, lets just roll with it
<sergiusens> beuno vila so where is this part of the store documented for us to start working on it?
<ysionneau> hi, I get this when running ubuntu-image to create a devel pi2 image : http://pastebin.ubuntu.com/16129071/
<ysionneau> any idea zyga ?
<zyga> ysionneau: !
<zyga> ogra_: ^^
<zyga> is that the same thing?
<zyga> ysionneau: I have no idea except that it seems to be everywhere now
<zyga> ysionneau: are you on xenial or something else?
<kgunn> i've got a situation where my snap won't install due to a previous install attempt where it got stuck...so it now says "error: cannot install snap file: snap "mir-server" has changes in progress"
<kgunn> i have already rebooted
<ogra_> ysionneau, you didnt download the u-d-f from mvo today, did you ?
<kgunn> i looked at using snap abort
<kgunn> but how to find the change-id ?
<zyga> kgunn: reboot wont help since snappy tracks changes in a persistent way
<zyga> kgunn: snap changes
<ogra_> (that is in active development atm, might be broken)
<zyga> kgunn: if all else fails rebuild the VM, I recommend using -snapshot for kvm boxes
<zyga> kgunn: but I know you have special requirements
<ysionneau> zyga: I'm on ubuntu mate 16.04
<kgunn> hmmm seemed to work...returned id 1
<kgunn> bugger...abort didn;t complain, but install still does...
<kgunn> ok, rebuilding image
<ysionneau> ogra_: it's a brand new udf from mvo, yes
<zyga> mvo: do you know anything about the squashfs magic number issue we saw in autopkgtests today?
<ysionneau> I modified the sha512sum from ubuntu-image to make the script accept it
<ogra_> ysionneau, well, better roll back then
<ysionneau> ah, and I guess I cannot download the old one can I? ;)
<ogra_> it is actively being changed atm
<ogra_> hmm, probably not
<zyga> ysionneau: ubuntu-image keeps old versions
<zyga> ysionneau: revert to earlier hash
<zyga> ysionneau: if you ran that hash at least once it will work
<zyga> (as in, it will run that udf)
<ogra_> ah, cool
<zyga> ubuntu-image is transactional ;-)
<ysionneau> wouldn't it be interesting to do versionning of those?
<ogra_> heh
<ysionneau> like opening a git repository with udf binaries?
<zyga> ysionneau: it would be much more interesting to not have to od htat
<ogra_> it would be interestiong to have a working version in the archive :)
<zyga> and I think that's what we are trying to get :)
<ysionneau> zyga: yes, I agree, but since it's been monthsthat we use this script and this binary
<ysionneau> with this method of distribution (wget)
<ogra_> well, atm we're trying to get uboot into i386 :P
<zyga> ysionneau: because we were focused on 16.04
<ysionneau> maybe we should at least do it right (with proper versioning)
<zyga> ysionneau: it will be stabilized quickly now
<ogra_> high hopes :P
<zyga> ogra_: what times we live in
<zyga> uboot i386
<zyga> _i386_
<ogra_> insanity
<zyga> not even amd64
<ogra_> next they will come and ask for grub on arm !!!
 * ogra_ shakes head
<zyga> heheh
<ysionneau> zyga: none ofthe cached versions I have work :/
<ysionneau> does someone here have a working udf binary?
<zyga> ysionneau: it's Friday
 * zyga checks
<mvo> zyga: the squashfs test is fixed, please merge master
<zyga> mvo: \o/ thanks!
<zyga> ysionneau: the copy I have doesn't work now
<mvo> zyga: yw! Chipaca is the hero who did it
<ogra_> ysionneau, http://people.canonical.com/~ogra/snappy/all-snaps/ubuntu-device-flash that is the last one
<ogra_> mvo, YAY ! so after wasting my day on this we now have images building again ...
<ogra_> just finished :)
<ogra_> what a silly issue
<zyga> so what was the true root cause?
<ogra_> zyga, missing XB-Task headers in PPA packages
<zyga> what even is that?
<ogra_> if you dont use a metapackage for your seed, the packages get only a task header added ... that works fine in the archive
<mvo> ogra_: meh, again
<ogra_> as soon as you upload to the PPA that header goes missing
<mvo> ogra_: the headers are terrible
<ogra_> yes
<mvo> ogra_: glad its fixed now
<ogra_> "fixed"
<ogra_> i hacked them in :P
<ysionneau> ogra_: this one works, thanks!
 * ogra_ triggers a full image set ... just to be sure
<ogra_> what a waste ... :(
<dz0ny_> Broken link https://developer.ubuntu.com/en/snappy/porting/
<zyga> mhall119: ^^
<dz0ny_> From bottom of https://developer.ubuntu.com/en/snappy/start/
<jdstrand> zyga: you're famous: http://www.ubuntu.com/usn/usn-2956-1/
<zyga> my dream has come true :)
<jdstrand> :)
<zyga> given that I hack on interfaces all day, I wonder if I'll be on the less honorable end of the CVE (or rather, when :/)
<jdstrand> heh
<beuno> zyga, just wait until there's a big security flaw named after you
<zyga> beuno: I sense it will be named after "Polon"
<mhall119> zyga: thanks, fixed it
<zyga> mhall119: thank you :)
<sergiusens> ogra_ ok, SRU followup questions :-)
<sergiusens> ogra_ if I push this to yakety https://github.com/ubuntu-core/snapcraft/pull/491 (changing the series), can I push the same thing to xenial? or should the series there be xenial-updates?
<sergiusens> ogra_ if it is just xenial, it will be auto forwarded to xenial-proposed, right?
<kyrofa> Hey jdstrand, tyhicks: as of https://github.com/ubuntu-core/snappy/pull/1095 Snappy supports unversioned data. Okay with you if I add the creation of the one in $HOME/snap to ubuntu-core-launcher?
<geneios> Is there anyway to change the gcc  compiler version used when trying to install packages from pip inside of a python2 snap?
<geneios> It seems I can't compile the version of numpy I need with gcc 6, from some testing it looks like gcc 4.7 is working
<jdstrand> kyrofa: that seems reasonable
<kyrofa> jdstrand, alright thanks :)
<sergiusens> jdstrand ah, maybe I can ask you SRUing questions :-) can I?
<jdstrand> I'm not on the ubuntu-sru team, but you can ask :)
<sergiusens> jdstrand so I want to get this out https://github.com/ubuntu-core/snapcraft/pull/491 do I just dput that to yakety, wait for it to get in and the dput to straight out xenial (it should get forwarded to xenial-proposed iirc)
<sergiusens> and then tag all those bugs as per the SRU doc (and probably update the description to cover how it is safe and all that)
<josepht> geneios: I'd assume you could add gcc-6 or whatever to build-packages.  I don't know if the python2 plugin supports the options to indicate a different compiler, but I'll bet you could write a custom plugin to do it fairly easily.
<jdstrand> sergiusens: dput to yakkety, yes. you will want to use a diferent version for xenial following: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Update_the_packaging
<jdstrand> sergiusens: I believe you will need to use xenial-proposed (that will definitely do the right thing), but I'm not 100% if it is required. otherwise, follow https://wiki.ubuntu.com/StableReleaseUpdates#Procedure
<geneios> josepht: Thanks! I have started digging around in the python2 plugin. I had to make some changes already because it was having issues finding the python-dev headers too.
<sergiusens> jdstrand so when uploading to xenial I can change the version to 2.8.5ubuntu16.04 ?
<jdstrand> sergiusens: yes
<jdstrand> sergiusens: you might even consider 2.8.5ubuntu16.04.1
<zyga> jdstrand: can I have a moment of your time?
<sergiusens> jdstrand ok, the next release in Y will be 2.9 and we will ty and get that SRUed as well (as we will have to basically SRU everything we do anyways).
<zyga> https://github.com/ubuntu-core/snappy/pull/1095/files#diff-a34e166c5b3016c122430c5884f41e9b
<zyga> jdstrand: can you please look at apparmor changes there?
<zyga> seems harmless I just want to ensure you see it
<jdstrand> zyga: I did already. they look fine. I'll comment
<jdstrand> zyga: thanks! :)
<zyga> thanks!
<sergiusens> jdstrand hmm, looking at how the desktop team did gnome software really confuses me https://launchpad.net/ubuntu/+source/gnome-software
<sergiusens> slangasek can I bug you about SRUing?
 * sergiusens is pinging everybody
<slangasek> sergiusens: hi
<jdstrand> sergiusens: indeed, that is non-standard to say the least :)
<jdstrand> they should've used 3.20.1+git20160426.1.a976144-0ubuntu0.16.04.1 for xenial and 3.20.1+git20160426.1.a976144-1 for yakkety
<sergiusens> jdstrand series also says 'xenial' in the yakety changelog
<sergiusens> jdstrand to be fair, it is sort of what I want to do; but I get it if it is not valid :-)
 * sergiusens likes clear versions
<jdstrand> sergiusens: they probably did a pocket forward copy
<jdstrand> which people sometimes do at the beginning of the release. but people should do separate uploads due to our shiny gcc
<sergiusens> jdstrand yeah, but this is python, so if there is a new python that breaks the old one, there goes my ideal one code base to rule them all
<jdstrand> sergiusens: what I described is the normal procedure. for a short period of time at the beginning of the release you can get away with the shortcut. but you can't go wrong if you follow the route I mentioned
<sergiusens> jdstrand yeah; I follow :-) I just want my development focus to be xenial (as it really is) and just upload to yakety because the norm says so ;-)
<jdstrand> sergiusens: it's simply a changelog difference and a dput
<sergiusens> jdstrand snapd will see it much worse as they will have to deal with go 1.7
<jdstrand> I did literally the same thing for ubuntu-core-launcher today
<sergiusens> jdstrand ack then :-)
<sergiusens> slangasek so the only question for you about SRUing is, do I put `xenial` in debian/changelog and expect to be automatically forwarded to -proposed?
<slangasek> sergiusens: yes
<sergiusens> slangasek ty!
<sergiusens> jdstrand and ty!
<oparoz_> how do you restart the network in snappy or use ifconfig?
<oparoz_> Ah.. you use sudo ifconfig :facepalm:
<kgunn> jdstrand: so i'm really close...but just need to confirm one thing
<kgunn> in my mir.go file, when adding apparmor/seccomp for the mir-server (not the client) i was add those for permanentslot right?
<kgunn> (not plug)
<jdstrand> yes
<kgunn> dang...i was hoping that was wrong jdstrand
<kgunn> jdstrand: cause now i get the endless hang on install
<kgunn> debug from snapd
<kgunn> https://pastebin.canonical.com/155582/
<jdstrand> we need zyga
<kgunn> :-/
<jdstrand> actually
<jdstrand> ERROR cannot setup dbus for snap "mir-server": cannot obtain DBus security snippets for snap "mir-server": unknown security system
<jdstrand> you need to I think give something empty
 * kgunn raise one eyebrow
<jdstrand> kgunn: there are 4 secure subsystems-- apparmor, seccomp, dbus and udev
<kgunn> jdstrand: ok, i wondered about that
<jdstrand> you are only need two
<jdstrand> so you have to do something with the other two it seems
<kgunn> i notice bluze and netrwork had those
<jdstrand> but they have an empty udev
<kgunn> jdstrand: i suppose i can just return nil, nil right?
<kgunn> on each
<jdstrand> I'm not sure. what did you do for udev?
<kgunn> jdstrand: nothing actually
<kgunn> jdstrand: i only have aa & seccomp for slot
<jdstrand> let me look at what they did for udev
<jdstrand> yes
<jdstrand> il, nil
<jdstrand> nil, nil
<jdstrand> kgunn: look at ConnectedPlugSnippet in bluez.go
<jdstrand> notice:
<kgunn> jdstrand: thanks , will do...
<jdstrand> case interfaces.SecurityUDev, interfaces.SecurityDBus:
<jdstrand>    return nil, nil
<kgunn> jdstrand: so zyga's blogs mention nothing of udev and dbus
<kgunn> :)
<jdstrand> so in each of all of those different places where you can return snippets, return nil, nil for the ones you aren't using
<jdstrand> nothing is using udev yet
<kgunn> seems strange to me to have a template requiring those when most folk might not need
<jdstrand> that will come with actual hardware assignment, which is probably slated for the gadget snap
<kgunn> yep
<jdstrand> kgunn: you might make that comment to him regarding the template
 * kgunn remembers jamie always says hw assignment when they speak, but always says "next time..."
<kgunn> jdstrand: will do and thanks for the pointers
<jdstrand> np
<kgunn> finally starting to form in my mind waht's happening
<sergiusens> kyrofa elopio the beast is alive!
<sergiusens> missing fonts === SIGABRT ;-)
<kgunn> jdstrand: hmmm, still giving me the same error.... and i've double checked, i'm pretty sure i've got it correct on which interfaces get returned and tested etc
<jdstrand> kgunn: unfortunately that would really need zyga then
<kgunn> yep, thanks tho
<kgunn> jdstrand: i wonder if i'm the first interface addition not using dbus...maybe there's a baked in assumption somewheres
<jdstrand> kgunn: most of the builtins don't use dbus
<kgunn> hmm
<jdstrand> kgunn: that said, most of the builtins don't have a slot side
<kgunn> just bad luck for me i suppose
 * jdstrand nods
<kgunn> jdstrand: and it is permanent slot right?
<kgunn> just double checking
<jdstrand> yes. mir server needs certain policy to run at all regardless of connection. that is what permanent is supposed to be for
<jdstrand> the connected stuff is when a slot and plug are connected
<kgunn> right...which make sense
<kgunn> bummed i didn't make better/more progress this wekk
<jdstrand> but if you install your server snap it would fail to start until you connected it to a client. that is weird which is why the permanent stuff is there
<kgunn> at least i learned some stuff
<jdstrand> if you really think it is a blug in the slot side permanent stuff, you could but it in slot side connected
<jdstrand> and then connect and see if it runs
<jdstrand> s/blug/bug/
<jdstrand> s/but it/put it/
<kgunn> interesting idea
<jdstrand> clearly, it is getting to the point where I should stop :)
<kgunn> i may tinker with that
<jdstrand> (too many typos)
<kgunn> :)
<sergiusens> jdstrand is there a way to do `setpriority`?
<jdstrand> sergiusens: once this lands, yes: https://code.launchpad.net/~jdstrand/ubuntu-core-launcher/seccom-arg-filtering/+merge/291069
<jdstrand> tyhicks: btw, don't wait on me for that ^ wrt socketcall(). I'm going to see if I can fix it properly. If not, I'll do a separate MP
<sergiusens> jdstrand what is the quick hack for it? I don't know where all the new paths are
<jdstrand> sergiusens: /var/lib/snapd/seccomp/profiles
<sergiusens> jdstrand can i just add setpriority to /var/lib/snapd/seccomp/profiles/snap.vscode.vscode ?
<jdstrand> sergiusens: just add it to the end
<sergiusens> and launch again?
<jdstrand> yes
 * sergiusens tries
<jdstrand> note, snapd may regenerate that
<jdstrand> but it is fine for testing
<jdstrand> sergiusens: also note, the seccomp arg filtering branch is for GA
<sergiusens> jdstrand great; I am so close; I have vscode working with --devmode now, but not with "normal" mode; aside from setpriority I have http://paste.ubuntu.com/16136197/
<sergiusens> jdstrand sounds good (wrt seccomp)
<sergiusens> I guess that /dev/shm/.org.chromium.Chromium.49BqTu would be a problem
<kgunn> jdstrand: hey one quick thing, and i swear it's last ques for the day...just confirming something zyga said
<kgunn> if i add the permanent slot to snappy, then run snapd....and i run snap interfaces
<kgunn>  i would or would not see mir(interface) listed under slots?
<jdstrand> kgunn: the design aiui is that you would see it
<jdstrand> sergiusens: erf it has chromium too? what isn't in that thing
<jdstrand> sergiusens: those will be tricky
<jdstrand> cause /dev/shm/.org.chromium.Chromium.49BqTu is not app-specific
<kgunn> jdstrand: ok, zyga said i would not, until i loaded my mir.snap (which didn't make sense to me)
<kgunn> and fwiw, i do not see it
<jdstrand> sergiusens: you get /{dev,run}/shm/snap/@{SNAP_NAME}/@{SNAP_REVISION}/**
<jdstrand> kgunn: oh I meant after the loading
<kgunn> ...and i can't get past the loading
<jdstrand> for before, I'm not sure
<jdstrand> this is all pretty new stuff here. it landed a week ago I think :)
<jdstrand> fyi, I clocked out a few minutes ago
<jdstrand> I'll read backscroll
<kgunn> lol
<kgunn> sorry
<jdstrand> have a nice weekend :)
<kgunn> you too
<sergiusens> jdstrand yeah, electron IS chromium ;-)
#snappy 2016-04-30
<Kamilion> trying to get the webcam-webui example to work, had to apt install snapd, but I get an error when trying to snap install webcam-webui_1_amd64.snap: - Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)
<caraka> While doing the 'build your first snap' tutorial, the 'snapcraft stage' command never sees/installs the stage-packages: -fswebcam portion of the yaml. Any ideas what I could be missing?
<daker> ogra_: ping
<daker> hi i am trying to install a snap using
<daker> sudo snap install raspi2modulessyncup_4.4.0_armhf.snap
<daker> a local snap, but snap is trying to download it from the store
<daker> https://paste.ubuntu.com/16143215/
<caraka> dacker: I have no business offering advice here, but have you tried specifying the complete path the .snap file?
<oparoz_> Does snappy care about what's in the snap's /etc/init.d folder?
<sergiusens> Kamilion did you install only snapd and not by any chance any deb you were not supposed to? Like ubuntu-snappy?
<sergiusens> Kamilion log a bug just in case
<oparoz> Is there an easy way to clean up all the garbage left over by snaps in /etc/systemd ?
<slvn> oparoz, maybe the scripts from zyga, e.g. https://github.com/zyga/devtools/blob/master/reset-state
<oparoz> Thanks slvn. I think that script goes too far as my system probably wouldn't boot any more :)
<oparoz> But it could be altered
<slvn> oparoz, I tried it to remove/clean-up all snaps installed on my system ...
<oparoz> slvn, your system is probably desktop?
<slvn> yes
<oparoz> The problem with core is that some of these snaps are required to boot
<oparoz> But that script still helps as it gives the location of files
<slvn> oparoz, ok, then maybe don't use this script :)
<slvn> btw, may I ask you what kind of platform do you use for this ?
<oparoz> What do you mean by platform?
<slvn> hardware ? I mean this is not a desktop ?
<oparoz> I use a VM for amd64 stuff, otherwise it's a Pi2
<slvn> ok, I'm just curious
<oparoz> Once Snappy core is GA, I'll probably use the desktop version
<oparoz> Right now I just need something which matches the target
<slvn> oparoz, but snappy is currently working on desktop, isn'it ? I mean, I just build and tested my first snap packages last week. Is this different for rpi2 ?
<oparoz> Yes, it's different because the Pi2 uses Core which isn't ready yet
<oparoz> Should take another month or 2
<slvn> ok
<bumblehead> Hi I'm trying to run the webchat snap example. I was able to create the webchat snap package. I was able to install it. I'm not able to run it.
<bumblehead> http://askubuntu.com/questions/765571/how-do-i-run-the-snapcraft-webchat-example
<bumblehead> would someone tell me what I'm doing wrong?
<bumblehead> should snappy still be considered to be in the "baking" stage?
<Kamilion> bumblehead: sorry, just woke up a little while ago -- I had questions like yours too
<bumblehead> Kamillion: were you able to find answers or help for the questions you had?
<Kamilion> from what I understand, snappy moved beyond the initial baking stage with 16.04's release, supposed to include snapd/ubuntu-core-launcher on the install media of all of the different spins
<Kamilion> unfortunately, lubuntu doesn't ship with snapd/ubuntu-core-launcher
<bumblehead> Kamilion: do I need to install snapd/ubuntu-core-launcher?
<Kamilion> <sergiusens> Kamilion did you install only snapd and not by any chance any deb you were not supposed to? Like ubuntu-snappy?    <---- no, fresh lubuntu 16.04 64bit ISO, apt install snapd, snap install webcam-webui_1_amd64.snap
<Kamilion> bumblehead: I don't know
<Kamilion> are you using lubuntu?
<Kamilion> do you have the 'snap' command available?
<bumblehead> no regular ubuntu
<bumblehead> I do have the snap command
<Kamilion> when i tried to use the snap command I got this error
<Kamilion> - Make snap "ubuntu-core" available to the system (can not set next boot: cannot determine bootloader)
<Kamilion> in response to 'snap install webcam-webui_1_amd64.snap'
<Kamilion> bumblehead: as far as I know, all of the other isos have snapd (and ubuntu-core-launcher is one of it's dependants)
<Kamilion> once I actually installed the OS to a disk, I got past the strange bootloader error
<bumblehead> i don't think this looks good when the examples don't run
<Kamilion> but now I have the same problem as you
<Kamilion> I built the webcam snap, and installed it, and have no idea how to launch it
<bumblehead> it looks like a lot of the information out there is spread out and incomplete
<bumblehead> despite the marketing around snap, official support snap may be shallow
<Kamilion> correct, IMHO canonical has followed this plan before with a lot of their 'not-invented-here' alternatives to standard linux, such as the unity desktop, mir, 'click' packages, and a couple others I could name but decline to at this point
<bumblehead> maybe they'll have some of the issues worked out in the next release
<Kamilion> there's lots of news postings
<Kamilion> and very little wiki/documentation
<bumblehead> yeah some of the documentation just looks like it was created as a formality
<Kamilion> and what documentation there is, seems targeted at either developers only, or "users, no developers, no admins"
<bumblehead> what good is a howto document that doesn't show me how to run or test the app?
<Kamilion> I'm very used to tools where the documentation is "read the comments in the source code", so i'm not TOO bothered
<bumblehead> I'm using ubuntu touch --same situation there
<bumblehead> stuff just languishing in a broken state for years
<Kamilion> but this isn't a bashing session, just pointing out
 * Kamilion laughs
<Kamilion> yeah, Upstart.
<bumblehead> the ubuntu touch store also
<Kamilion> The stories I could tell you about my adventures with upstart. *facepalm*
<Kamilion> what about Ubuntu-One? Poof, gone, all my dotfiles and homedir neccessities...
<Kamilion> I love that they try new things
<Kamilion> but it's a double edged sword.
<Kamilion> so I hope nobody mistakes this as "I hate canonical!" because that's just totally untrue. I have much <3 for them, I just don't agree with them all the time, that's all :D
<bumblehead> its fair to observe flaws
<Kamilion> anyway, snappy seems half-baked at the moment
<bumblehead> there's always this persective 'its open source so you aren't in a position to complain and we're all busy and can't fix our broken stuff so live with it'
<Kamilion> the idea is well thought out, but the implimentation is... uh... What's a word for 'disorganized and strewn about" ?
<bumblehead> implementation is incomplete
<bumblehead> and the pattern appears to be that once something gets released
<Kamilion> eh, the ecosystem is incomplete; the core tool works at the moment
<bumblehead> they stop improving it
<Kamilion> *cough* ptrace in upstart...
<Kamilion> yeah.
<Kamilion> The one thing I wanted to do was launch the webserver... Oh, sorry, can't launch apache with upstart because upstart uses ptrace somewhere and apache really doesn't like that.
<Kamilion> longstanding bugs, plans formed, and in the end? systemd swoops in and the whole problem evaporates.
<Kamilion> I'm kind of afraid that's what's going to happen to Mir/Unity as well...
<bumblehead> sounds like they need to figure out a way to do that with unity and ubuntu touch and snappy and the application store and the core ubuntu apps...
<Kamilion> wayland will suddenly get a whole bunch of industry support (like the recent announcements that the new GL/Vulkan stuff was already wayland compatible) and then people will be left holding the ball trying to support what amounts to be a personal project
<Kamilion> well, it seems to me that's exactly what snappy is
<bumblehead> its too bad...
<bumblehead> in theory the idea is really attractive
<Kamilion> a way to ship a whole application bundle with it's libs and everything, as one package.
<Kamilion> It will be GREAT for games.
<bumblehead> is there an alternative to snappy that's supported by a responsible vendor?
<Kamilion> no longer does it matter that this game needs qt4-something and I only have qt5-something
<Kamilion> uhhh, honestly? Not that I know of.
<Kamilion> I'm familiar with most of the distros and the package managers that run them
<Kamilion> the only thing that I can think of that's similar is gentoo's overlay system for portage
<Kamilion> Or, well, ubuntu's own PPA system if there's a metapackage in the PPA that 'grabs everything'
<Kamilion> and that's one of the reasons why I'm still here
<Kamilion> Canonical may be quirky and slow to support things.. but they *ARE* innovating greatly
<sergiusens> bumblehead the snapcraft examples are meant to be examples; and fwiw, it is run on every commit of snapcraft it self
<Kamilion> like the lxqt PPAs (there's an lxqt-metapackage in the PPA that will get the right bits from universe and from the ppa)
<sergiusens> it is not a command line tool (the way the example is crafted at least).
<sergiusens> and you have an answer http://askubuntu.com/questions/765571/how-do-i-run-the-snapcraft-webchat-example
<Kamilion> http://puu.sh/oBzoy/7622f10efb.png   <--- so it should be running on :3000 now?
<Kamilion> *checks*
<bumblehead> sergiusens: thank you that looks like the information I needed
<sergiusens> Kamilion it should
<sergiusens> I can't try right now; I'm on 3g
<sergiusens> if you want a better node app; try shout. I am using it to write into right now
<sergiusens> I'm really close to an electron app working as well
<sergiusens> but it is the weekend after all
<sergiusens> and not much free time to get to these things
<bumblehead> seriusens: I want to package something with nw.js --if you finish packaging the electron app will you share the result somewhere?
<bumblehead> sergiusens: I will try the shout example
<Kamilion> sergiusens: are you one of the primary developers?
<Kamilion> (it is not running on :3000 for me)
<bumblehead> https://github.com/ubuntu-core/snapcraft/blob/6685d6359887fbb7b1c35f3dce30bb70e7b06e8a/examples/shout/snapcraft.yaml
<Kamilion> oh
<Kamilion> I should point out -- you probably want The Lounge, not shout
<Kamilion> https://github.com/thelounge/lounge
<Kamilion> #thelounge here on freenode. It's a community fork of Shout, because the developer said that Shout is a personal project and he apparently wants to keep it that way
<bumblehead> the should example does not build either
<bumblehead> Issues while validating snapcraft.yaml: Additional properties are not allowed ('uses' was unexpected)
<sergiusens> Kamilion it was already pointed out to me
<sergiusens> bumblehead are you using master?
<bumblehead> ah no
<bumblehead> I will try the master example
<sergiusens> bumblehead what are you using?
<bumblehead> there is a 1.* branch that's what I was referencing
<sergiusens> Kamilion https://github.com/sergiusens/shout/commit/899e61fa28fe6cb98a434123584a621c1d11ceb3#commitcomment-17313321
<sergiusens> even though shout is not really abandonded though
<bumblehead> snap is building the shout package
<Kamilion> Shout isn't *abandoned*
<Kamilion> "We felt that the original Shout project "stagnated" a little because its original author wanted it to remain his pet project (which is a perfectly fine thing!).
<Kamilion> A bunch of people, excited about doing things a bit differently than the upstream project forked it under a new name: âThe Loungeâ."
<Kamilion> I've been hanging around the IRC channel for the past ~3-4 weeks, and development is extremely active right now
<sergiusens> Kamilion yeah, "active" and wanting to use it for real makes me think I want the dust to settle a bit; but I haven't checked out yet to be certain of my initial thoughts
<Kamilion> but that's also a good thing that Shout isn't hugely active, the snaps made from it probably won't be version-obsolete for a while. :)
<Kamilion> sergiusens: I should mention -- right now Shout cannot handle getting disconnected, and has no idea when 'the server has gone away'.
<bumblehead> i wish one of the examples was a nw.js/electron hello world app that runs from a shell or icon click
<sergiusens> Kamilion I fully know about that :-)
<sergiusens> Kamilion you may see me pinging ubottu to know if my connection is alive :-)
 * Kamilion chuckles
<Kamilion> yeah, I do that to my supybot as well
<Kamilion> although ours is the buddy/guy/friend/pal sequence from south park
<Kamilion> trying to craft a snap from my old disker-gui package: https://github.com/kamilion/disker-gui
<Kamilion> or at least, that is the plan.
<Kamilion> sergiusens: do you know if snapd works on any of the other live ISOs, or if it's required to be an on-disk install with a 'normal' root filesystem?
<Kamilion> I just can't seem to get snaps working on my most recent xenial spin, https://github.com/kamilion/kamikazi-core/releases/tag/0.9.0-rc1
<bumblehead> sergiusens: do you recommend electron over nw.js?
<Kamilion> I don't think it's enthused that my root filesystem is a squashfs.
<sergiusens> Kamilion I don't know about installation requirements or not, sorry
<sergiusens> bumblehead I'm not a nodejs person; but everything interesting is using electron
<sergiusens> Kamilion a bug report against snapd might be handy
<Kamilion> sergiusens: once I can figure out what needs to go in it, repros and data.
<Kamilion> where should bug go? to the github issues, or launchpad on snapd?
<Kamilion> ah, nevermind, answer's obvious if I look at the github -- no issue tracker.
<Kamilion> just pull requests.
<bumblehead> what does the yaml file look like for a tradional desktop style application which does not run as a service daemon?
<caraka> noob question: While doing the 'build your first snap' tutorial, the 'snapcraft stage' command never sees/installs the stage-packages: -fswebcam portion of the yaml. Any ideas what I could be missing?
<Kamilion> bumblehead: I'm looking through the examples tree, and I'm not seeing any desktop applications, but I would figure it would expose a .desktop file in /usr/share/applications or somewhere else that a desktop environment looks for .desktop files.
<Kamilion> caraka: I had some trouble going thru the steps myself; but grabbing the final from the git repo and snapcraft snap worked.
<Kamilion> https://github.com/ubuntu-core/snapcraft/tree/master/examples
<Kamilion> caraka: This is pretty much what I saw: http://puu.sh/oBzoy/7622f10efb.png
<caraka> Thanks Kamilion. I haven't got  that far because fswebcam isn't getting staged. I'll try cutting and pasting the complete example yaml again, but I'm not sure it's going to help.  :P
<Kamilion> I had some problems when it went to go update repos, I had keybase's deb repo enabled and it was very unhappy there was no Release file for xenial
<Kamilion> caraka: there's a snapcraft-examples package you can install from apt
<Kamilion> what I did was cp -R /usr/share/doc/snapcraft-examples/examples/webcam-webui ~/snapcrafty/webcam-webui
<caraka> I shall try that, thanks. Would prefer to roll my own in order to learn the thng tho...
<Kamilion> understood
<caraka> all part of the learning curve.
<Kamilion> I myself was just making sure everything was operating as intended before moving on to trying my own
<Kamilion> yeah, I just started reading the docs myself yesterday
<caraka> And of course I'll be having a go at a full desktop app before I'm ready.  :P
<Kamilion> someone linked them to me after I complained about the release notes pointing to a Marketing press release page that wasn't very helpful
<Kamilion> then found out lubuntu somehow missed snapd in their 16.04 release
<Kamilion> I was told it's supposed to be part of the platform seed, which all of the different spins inherit from
<Kamilion> so in theory snapd should have been included with all of the 16.04 release ISOs.
<caraka> I think it may have all hit the betas at a very late stage
<Kamilion> but nobody tested before shipping, and #ubuntu-release was a madhouse during release week, so it doesn't suprise me it was overlooked or put off till 16.04.01's june point release
<caraka> I thought I heard it skidding into the blocks on April 20th...
<Kamilion> hahaha no wonder
<Kamilion> meanwhile, I've been running xenial since november
<Kamilion> got so many little papercut annoyances fixed between 15.04 and 16.04
<caraka> I waited. and mucked around with systemd and thoroughly barfed on my wily, so that I could erase it last week and start again
<Kamilion> openvswitch is just so much happier now
<Kamilion> xen and openvswitch play together nicely now too
<Kamilion> and they barely caught the cusp of the ceph LTS release
<Kamilion> I think they put one of the release candidates in the repo just before release and there's a SRU promised when the final lands. <3
<Kamilion> I really love that they loosened the SRU restrictions this LTS
<Kamilion> because of it now we get nginx 1.10
<Kamilion> (that was a VERY pleasant suprise)
<Kamilion> none of these ship on canonical ISOs, so they can all get updated in the archive without worry.
<caraka> I never play with any of the infrastructure toys
<Kamilion> all in all, 16.04 is gonna be a really solid platform that'll be well cared for till 2020ish for the server packages, and like 2018 for the desktop packages.
<Kamilion> well, uh
<Kamilion> till about 14.10 they were kinda sorta broken when just pulled in bare from the archives <.<
<caraka> I hope so. canonical is mature enough to have made enough people grumpy. (and enough happy)
<Kamilion> in 15.04 I complained enough so the defaults were sane but kind of poopy performance
<Kamilion> in 15.10 I got the performance problems resolved with a lot of the defaults
<caraka> and now you have an LTS you are happy with
<Kamilion> and the openstack team has been doing GREAT work on papercut bugs too
<Kamilion> well, now we have an LTS where everything works out of the box, at least.
<caraka> ^^
<Kamilion> 14.04's point releases really helped too
<Kamilion> and if you wanna play around with the fancy VM stuff
<caraka> Well, we're onto our 6th LTS or so, so the pattern is set
<Kamilion> https://github.com/kamilion/kamikazi-core/releases/tag/0.9.0-rc1  <--- my appliance image USB stick is powered by ISOs and casper
<Kamilion> TORAM=Yes is my bestest friend.
<Kamilion> I steal a gigabyte of ram for a full desktop on top of xen/kvm, openvswitch, ceph, and python3
<Kamilion> "Don't mix your OS with your data" is a good way of describing it... Stick it on a slow USB stick, boot it into ram, unmount the slow usb stick, mount the user disks.
<Kamilion> ubuntu-core's a different way of doing the same thing
<caraka> thats some serious effort!
<Kamilion> as an appliance, I expect to throw away 99.9% of runtime data when the machine shuts down. Anything the user cared about, they saved. (EG, logs and databases and such)
<Kamilion> I stood on the shoulders of some pretty tall giants. :3
<caraka> Despite it being Sunday morning, I must go to work. Keep up the good work!
<Kamilion> but yeah -- after three years, my goals and canonicals have somewhat aligned
<Kamilion> thanks to openstack getting popular.
<Kamilion> o/
<Kamilion> good luck with snapcraft!
<caraka> o/ thanks, I'll need it!
<bumblehead> howI installed the ubuntu-calculator-app with snap http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snapcraft.yaml
<bumblehead> how do I run the calculator from a shell?
<bumblehead> ubuntu-caculator-app.start
<bumblehead> command not found
<sergiusens> bumblehead use autocomplete or ls /snaps/bin
<sergiusens> err /snap/bin
<bumblehead> sergiusens: thanks I'm able to run the calculator app
<bumblehead> now I'm trying to run my nw.js application with snap but I think the npm command fails because it is not executed from the same location as the package.json
<bumblehead> I'm using this command
<bumblehead> `command: bin/npm run nw`
<bumblehead> `nw` is defined in the script space of the package.json
<bumblehead> relative to the snap root directory it is found in lib/node_modules/flashcards/package.json
<bumblehead> I tried changing command to `cd lib/node_modules/flashcards/ && ../../../bin/npm run nw
<bumblehead> but snapcraft says the cd command is not found
<sergiusens> bumblehead you build using parts; `command` should hold the final application
<sergiusens> so `apps` defines how the application is exposed within the snap to the outer world
<sergiusens> and parts define how to build and/or lay it out in the snap
<oparoz> Is it possible redirect calls going outside of a snap to an internal folder? Like when a binary only wants to create folders in /var/run
<oparoz> Because even when compiled from source, we can't tell the binaries where the writable partition is
<bumblehead> sergiusens: can you tell me how I would describe a build step in the parts section? for example running browserify?
<bumblehead> it looks like I would need to write a plugin using python that would drive the node behaviour I need
<bumblehead> I don't know where the best place would be to make possible suggestions
<bumblehead> but I would suggest that the snappy plugin should use a special npm run command
<bumblehead> that way people using node/npm would have an easy way to hook up functionality they need for setting up snap packages
#snappy 2016-05-01
<bumblehead> I've been trying to build a node-webkit snap package and am wondering what the best strategy is...
<bumblehead> should I build the node-webkit binary and in the yaml file put "command: bin/node path/to/nwbin"?
<bumblehead> i would normally call "nw" from within the root directory of the package and there's a manifest file there which node webkit uses for its initialization
<bumblehead> but doing the same with snappy is not simple. snappy does not let me 'cd' into the directory using something like this "command: cd && node nw"
<bumblehead> so maybe a bash script that uses cd would be necessary? or maybe that's a bad way of doing it...
<bumblehead> has anyone here done this?
<bumblehead> and the node webkit produced binary is somewhat large --70mb
<bumblehead> but my application is a small flashcard application
<bumblehead> the source files are probably about ~30kb
<bumblehead> maybe this "fine" I don't know
<wililupy> Anyone else getting this error using ubuntu-device-flash building a core snappy image?
<wililupy> http://pastebin.ubuntu.com/16163489/
<wililupy> This is the command I am using:
<wililupy> sudo ./ubuntu-device-flash core 16 --channel=edge --kernel=canonical-pc-linux --gadget=canonical-pc --os=ubuntu-core -o snappy_amd64.img
<bumblehead> it seems there's some permissions issue running the node webkit binary...
<bumblehead> it would be terrific if a hello-world/todo-list example using nw.js or electron would be published
<bumblehead> I'll need to give up on this task this I wasn't able to complete it today :(
<slvn> Hello, my snap package is been reject because of "checksums do not match. Please ensure the snap is created with either 'snapcraft snap <DIR>' or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs' security-snap-v2_squashfs_repack_checksum"
<slvn> but doing "snapcraft snap my_app" says "[Errno 2] No such file or directory: my_app/meta/snapcraft.yaml"
<slvn> whereas doing "cd my_app; snapcraft snap" correctly make the snap package, which is working
<slvn> any idea ?
<pedronis> wililupy: how was that u-d-f built? where i comes from? it looks like a bug that was briefly on ubuntu-core/snappy master but now is fixed
<pmp> In what way does the recent announcement of Marc's (et al) has influenced the status of a RPI2 snappy-image generation?
<pmp> I'm asking this as currently I'm not able to build an image (since 3 weeks actually) with u-d-f for rpi (from ~mvo)
<pmp> "failed to install "canonical-pi2" from "edge": cannot open snap: unknown header: "hsqs \x00 ..."
<qengho_> slvn: Are you building with snapcraft on 16.04? What does "snapcraft -v" say?
<slvn> qengho_,  yes this is snapcraft on 16.04, snapcraft -v says "2.8.4"
<qengho_> slvn: Huh. How about "file *.snap", where you have a snap in curdir.
<slvn> qengho_, it says "Squashfs filesystem, little endian, version 4.0, 8468182 bytes, 72 inodes, blocksize: 131072 bytes, created: Sun May  1 15:44:04 2016"
<slvn> (I have just re-created it)
<slvn> snap-review will fail with the message : "security-snap-v2:squashfs_repack_checksum"
<slvn> "checksums do not match. Please ensure the snap is created with either 'snapcraft snap <DIR>' or 'mksquashfs <dir> <snap> -noappend -comp xz -all-root -no-xattrs'"
<qengho_> slvn: I don't know. Could be a dozen things. There's a link at the bottom of the page. Report it as a bug. Someone will work it out, probably starting tomorrow.
<slvn> qengho, np, I'll ask the question again tomorrow
<qengho> Okay, but IRC is not a bug tracker.
#snappy 2017-04-24
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<Son_Goku> morphis_: night/morning
<morphis_> Son_Goku: morning!
<Son_Goku> I'm amazed I'm still up
<morphis_> :-)
<Son_Goku> morphis_: https://bugs.launchpad.net/snapd/+bug/1685626
<mup> Bug #1685626: Add command for completely removing snappy artifacts on complete uninstall <cross-distro> <snapd:New> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1685626>
<Son_Goku> also, can you talk to someone on the LP team to reactivate rhbz integration?
<Son_Goku> I filed a bug about this against LP itself some time ago, but nothing happened... https://bugs.launchpad.net/launchpad/+bug/1678486
<mup> Bug #1678486: Enable watching Red Hat Bugzilla bugs <Launchpad itself:New> <https://launchpad.net/bugs/1678486>
<morphis_> Son_Goku: I can see what I can do
<morphis_> Son_Goku: to workaround #1685626 we can craft a simple shell script which does that job
<mup> Bug #1685626: Add command for completely removing snappy artifacts on complete uninstall <cross-distro> <snapd:New> <snapd (Fedora):Unknown> <https://launchpad.net/bugs/1685626>
<morphis_> Son_Goku: something like what zyga devtools are doing
<Son_Goku> ?
<morphis_> https://github.com/zyga/devtools/blob/master/reset-state#L44
<Son_Goku> ah. I see
<morphis_> Son_Goku: https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/snapd.postrm
<Son_Goku> ...
<Son_Goku> that is a horrifying postrm
<Son_Goku> also, shouldn't this be prerm?
<Son_Goku> otherwise, terrifying things could happen...
<morphis_> why should it be prerm?
<Son_Goku> I mean, I guess if /snap isn't a registered directory to dpkg, it wouldn't matter either way
<Son_Goku> but making things disappear on the package manager sounds like a horrible idea
<Son_Goku> or the opposite case, preventing the package manager from cleaning up
<Son_Goku> that said, given that this is implemented in shellscript in two different places, it sounds like it really should be a command built into snapd
<morphis_> how would that be different other than that the postrm script would call `snap reset`
<Son_Goku> morphis_: consistently implemented?
<Son_Goku> though it wouldn't be possible for it to be postrm at that point
<morphis_> that is the only point, yes
<Son_Goku> since /usr/bin/snap would be gone by postrm time
<morphis_> and that is what make things tricky
<Son_Goku> well, that's what prerm is for
<Son_Goku> afaik, purge is propagated to prerm
<morphis_> sure but that might have consequences on the running system etc., however lets not discuss that here right now
<Son_Goku> anyway
<morphis_> I think for fedora we can go with a simple script for now
<Son_Goku> yeah
<morphis_> in the long run we can rework that and make it the same across all distros
<Son_Goku> when I'm not completely dead, I'll whip something up for snapd-2.24
<Son_Goku> err
<Son_Goku> 2.25
<Son_Goku> assuming it's going to be tagged this week or something
<morphis_> ok
<morphis_> Son_Goku: I am currently fixing all the failing unit tests on Fedora
<Son_Goku> if not, I'll put it together for snapd-2.24
<Son_Goku> morphis_: okay :D
<morphis_> so patch for that is coming
<Son_Goku> excellent
<morphis_> sadly too late for 2.25
<Son_Goku> as long as it gets merged into master, I don't mind carrying it for a release or two
<Son_Goku> morphis_, it might be able to land for 2.25
<Son_Goku> the milestone isn't even halfway done
<morphis_> Son_Goku: the milestone is always in flux :-)
<Son_Goku> anyway, snapd 2.24 has propagated out to all Fedora releases
<Son_Goku> so when JamieBennett is preparing the announcement, he can announce both Fedora and Ubuntu at once
<morphis_> Son_Goku: nice!
<Son_Goku> whether he does... I dunno
<morphis_> Son_Goku: he will for sure :-)
<Son_Goku> morphis_, so I finally blew my top: https://forum.snapcraft.io/t/integrate-snapd-xdg-open-into-snapd-repository/100/75?u=conan_kudo
<zyga> good morning
<Son_Goku> gurgle
<zyga> Son_Goku: hey
<zyga> Son_Goku: FWIW I agree on xdg-open
<zyga> Son_Goku: not on the repo, one repo is convenient, but on the approach used
<Son_Goku> I am not looking forward to the day when the security team or the core dev team stops being able to understand where one ends and the other begins
<pstolowski> morning
<zyga> hmm, we seem to have a lot of DNS issues in linode
<zyga> dial tcp: lookup search.apps.ubuntu.com on [::1]:53: read udp [::1]:34462->[::1]:53: read: connection refused
<zyga> fgimenez: I saw you commented about this on the forum, do you have any idea what he cause may be?
<fgimenez> zyga: nope, it started happening last week
<zyga> fgimenez: maybe it is related to the rollout of the new store?
<Son_Goku> zyga, morphis_, I'm going to sleep now. I've been up for almost a whole day...
<Son_Goku> JamieBennett, snapd-2.24 is available in all released Fedora versions
<JamieBennett> Son_Goku: Awesome!
<Son_Goku> I would appreciate it if the formal snapd 2.24 announcement also included a blurb about Fedora alongside the typical Ubuntu stuff
<fgimenez> zyga: maybe, i think that the first errors of this kind appeared last friday at ~ 5:00 utc, that's after the rollout right?
<JamieBennett> Son_Goku: Will do, thanks
<zyga> Son_Goku: take care! thank you for everything!
<Son_Goku> JamieBennett, it was supposed to sync out Friday, but the Red Hat datacenter had a massive network outage
<zyga> Son_Goku: I'll make sure it does :)
<Son_Goku> infra came back online Saturday, and everything sync'd out Sunday :)
<Son_Goku> anyway, must sleep, I have work in 6 hours!
<sborovkov> Good whatever time of day it is for you guys. When I use shutdown interface - should I also use dbus plug to allow my snap to interact with systemd's dbus API or is interface enough by itself?
<JamieBennett> thanks Son_Goku
<Son_Goku> JamieBennett: you're welcome
<zyga> sborovkov: checking
<zyga> sborovkov: shutdown is enough, it lets you talk to systemd /logind
<sborovkov> thanks
<zyga> mvo: hey, about the repair assertion, can you tell me what you think about the idea to have wildcard support in the model field?
<mvo> zyga: fixing the dns issue
<mvo> zyga: that is leftover from trying to get a handle on the systemd bug we talked about friday
<zyga> mvo: thanks! so it is a bug on our end!
<zyga> mvo: ah, right
<zyga> mvo: I recall you synced the real package
<mvo> JamieBennett: do you want me to update https://forum.snapcraft.io/t/draft-snapd-2-24-available/245 with some lines about fedora or will you use a different draft for the announcement?
<mvo> zyga: yeah, I reuploaded a "fixed" package that removes the offending patch
<mvo> zyga: wildcard is fine
<zyga> mvo: I was thinking if the assertion system supports such constructs
<mvo> zyga: I think we shoudl do that, I will look into the repair assertion again now, add some more meat beside the assertion
<mvo> (or tofu)
<zyga> mvo: but I think that a wildcard is mandatory otherwise, I don't think it is sensible to issue lots of assertions for a common issue
<zyga> haha, I love tofu
<mvo> zyga: sure, the wildcard is nice. at the same time, there is still a lot to do, the wildcard is something I'm not super concerned about. we can always simulate that using the body script itself by doing a check via bash
<mvo> zyga: I guess I'm trying to say that I don't consider it a blocker :)
<JamieBennett> mvo: that post is what I will use for the announcement so feel free to update it
<mvo> JamieBennett: thanks, will do
<zyga> mvo: good point about that
<zyga> mvo: though shell scripting wise I think it's hard to ask snapd which model it is
<mvo> zyga: yes, this is a good point, we should make this easier
<mvo> zyga: actually snap known model should work
 * mvo checks
<zyga> mvo: yes but not unique
<zyga> mvo: you can snap ack more models
<mvo> zyga: indeed. anyway, I think we are in agreement, this will come
<Chipaca> o/
<mvo> hey Chipaca, good morning!
<zyga> Chipaca: morning, how are you feeling today?
<Chipaca> mvoâ morning! how's things?
<Chipaca> zygaâ a'ight! just a pesky cough left now \o/
<Chipaca> zygaâ how are you?
<zyga> good, returning home after school drop
<mvo> Chipaca: all going well
<zyga> Chipaca: I didn't find anything wrong in the tab-completion code, I will approve it soon
<Chipaca> woo
 * zyga walks home now, brb
<zyga_> mvo: I have some good news and some casual news, with the idea from last week I moved to the last problem in update-ns bag, that of shadowed mounts
<mvo> zyga_: nice!
<zyga_> mvo: but I also wonder if this is something that is an actual blocker, I will try to land existing branches and move on to integration in snapd (so that it runs automatically)
<zyga_> mvo: and spread testing
<zyga_> mvo: the limited use cases of content so far should not be affected by this problem
<zyga_> mvo: (though theoretically they can)
<zyga_> mvo: but I want to see how this functions in the wild before we go and solve another non-trivial problem
<pstolowski> mvo, hey! it would great to land #3197, are you still tweaking it?
<mvo> zyga_: when can this happen? only if snaps do manual (out-of-band) mounts?
<zyga_> mvo: I'd like to land https://github.com/snapcore/snapd/pull/3138
<mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<mvo> pstolowski: should be ready, looked like there is a test failure, I need to lookwhat is going on
<zyga_> mvo: and https://github.com/snapcore/snapd/pull/3216
<mup> PR snapd#3216: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3216>
<zyga_> mvo: I'll iterate to make tests green there, not sure why the first one failed (probably not related to the change)
<mvo> zyga_: I am building a new core now, once that is finished we should have working tests again (the systemd change is then removed again)
<mvo> zyga_: I have a look. I would also really like to see gustavo looking at this at some point but maybe this will happen today, he said he will want to do a review day on the 2.25 branches
<zyga_> mvo: so no luck with fixing the problem and getting pairty with xenial systemd?
<mvo> zyga: no, unfortunately not yet, there is one patch that we need to remove otherwise things fall apart on core
<mvo> zyga: it seems to be a bit of a can of worms as I am only able to reproduce on linode, not in qemu
<mvo> zyga: plus only on core and running core tests takes some extra time because of the setup it needs to do first etc. its a bit of PITA.
<zyga> mvo: did you see the question from slangasek, about cloud-init?
<mvo> zyga: I did but I did but I did not think about this yet. the ubuntu-core image disables cloud init and the errors happen inside the ubuntu-core image so I suspect cloud-init is not at play here but this is not well researched yet
<zyga> mvo: is the new core built?
<mup> PR snapd#3220 opened: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
<mvo> zyga: yes, let me check if the store has it already
<zyga> pedronis: what is "snap prefer"?
<pedronis> zyga: if there are conflicts  enable the aliases of this snap and disable the aliases of conflicting ones
<mvo> zyga: new core should be ready
<zyga> mvo: thank you
<zyga> pedronis: aha, I see
<zyga> pedronis: interesting concept, so snaps can disagree on aliases
<pedronis> not snaps
<zyga> pedronis: that's pretty cool as people will have their preferences
<pedronis> but yes in theory the store can give the same alias to more than one snap
<zyga> ah? those are user aliaes only?
<pedronis> no, auto aliases
<pedronis> IÂ mean the command will disable manual aliases, but there's no memory of manual aliases, they are either there or not
<pedronis> atm we have no such conflicts in the store fwiw
<mup> PR snapd#3216 closed: cmd/snap-update-ns: add actual implementation <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3216>
<Chipaca> morphis_â did you get to have a look at snapd#2969 as jdstrand requested way back when?
<mup> PR snapd#2969: interfaces: mediate netlink sockets via seccomp <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2969>
<sborovkov> jdstrand: Hi. Btw I am getting similar issue with dbus, I was getting when using pydbus before. When using shutdown interface I am getting "apparmor denied" because pydbus tries to do introspection :-( https://hastebin.com/inohabofad.vbs
<zyga> sborovkov: aha, interesting
<zyga> sborovkov: I think introspection should be allowed by default
<Chipaca> fgimenezâ as I count them snapd#3014 now has two +1's so it's gtg
<mup> PR snapd#3014: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
<morphis_> Chipaca: not really
<zyga> sborovkov: can you pastebin 'dmes | grep DENIED\
<sborovkov> zyga: [ 5560.678149] audit: type=1107 audit(1493024823.398:2127): pid=1037 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/org/freedesktop/login1" interface="org.freedesktop.DBus.Introspectable" member="Introspect" mask="send" name="org.freedesktop.login1" pid=29564 label="snap.screenly-client.ping" peer_pid=1032 peer_label="unconfined"
<zyga> sborovkov: thanks
<sborovkov> zyga: is dbus-send command available from inside the snap? going to just call it manually from python as a workaround for now
<zyga> sborovkov: you can add it to your snap
<morphis_> Chipaca: but added on my list for today
<sborovkov> zyga: understood.
<morphis_> sborovkov: I think dbus introspection isn't allowed by the interface yet
<Chipaca> snapd#3018 is short and sweet and needs a second review
<mup> PR snapd#3018: tests: add empty initrd failover test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3018>
<sborovkov> morphis_: yeah I noticed. I am using pydbus though. It does not work without it. Couple of weeks ago I could not even get SystemBus(). Jdstrand added rule that allows introspection on itself which fixed the issue.
<sborovkov> That seems pretty similar
<morphis_> sborovkov: was that for a different service?
<fgimenez> Chipaca: about snapd#3014 yep, assuming mvo's review is an actual +1 yes, gtg
<mup> PR snapd#3014: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
<Chipaca> fgimenezâ I read it that way
<Chipaca> zygaâ you seem to have an unaddressed comment from gustavo on snapd#3026, correct?
<mup> PR snapd#3026: cmd/snap-confine: use defensive argument parser <Created by zyga> <https://github.com/snapcore/snapd/pull/3026>
<sborovkov> morphis_: well the issue was that you could not even obtain system bus in pydbus. It was doing introspection on itself. Just simple code bus = pydbus.SystemBus()
<morphis_> sborovkov: ok, for the systemd service you should be fine doing a direct call to the relevant method without introspection
<zyga> morphis_: I think that introspection should be open by default
<morphis_> zyga: sure
<zyga> morphis_: the problem is that pydbus uses introspection to know what methods are allowed and what the types are
<morphis_> zyga: however it needs to be activated for every service individually with our current setup
<morphis_> zyga: there is no way in pydbus to do an explicit dbus method call without introspection?
<mvo> fgimenez: indeed, that was a +1
<fgimenez> mvo: great, thanks!
<mup> PR snapd#3014 closed: tests: add dbus interface spread test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3014>
<mup> PR snapd#3215 closed: tests: address review comments from #3186 <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3215>
<zyga> morphis_: everything is possible but perhaps a bit too hard
<zyga> morphis_: I worked on pydbus extensions and I think it'd be just annoying to add
<zyga> morphis_: I think we can allow introspection on all objects on all paths
<zyga> morphis_: it's the interface that's constant
<pstolowski> can somebody take a look at #3208? we need 2nd review, and it looks safe/non-controversial..
<zyga> pstolowski: thanks :)
<pstolowski> zyga, any time ;)
 * zyga has a headache today, wind kept waking me up all night
<zyga> I'm adding spread tests for update-ns
<pstolowski> speaking about spread tests... #3205 also needs 2nd review and should be safe to land
<morphis_> zyga: sure, but that would mean for 2.26 which may be too late for sborovkov
<Chipaca> morphis_â 3205 is on the first page, not there yet
<sborovkov> morphis_: I'll just use more simple lib for now :-) The one that does not require introspection
<morphis_> sborovkov: sounds good
<Chipaca> pstolowskiâ what's snapd#3119 waiting for?
<mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
<pstolowski> Chipaca, needs review from niemeyer
<Chipaca> niemeyer needs a manager to play interference on him so he can get to all these PRs :-)
<Chipaca> s/on/for/
 * Chipaca was not offering
<Chipaca> zygaâ you requested changes on snapd#3136 but have not re-reviewed
<mup> PR snapd#3136: snap-confine: add code to ensure that / or /snap is mounted "shared" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3136>
<zyga> Chipaca: I know, we're waiting for the locking branch to land
<zyga> Chipaca: so that mvo can use the new locking primitives
<zyga> Chipaca: (or I can push a small change that uses them)
<zyga> Chipaca: curiously the locking branch needs a 2nd review (mvo +1d it)
<Chipaca> curious, curious
<zyga> Chipaca: very :)
 * zyga is in a slightly better mood as headache is wearing off
<zyga> I need to fix some of the blinds to avoid wind rattling everything
<Chipaca> zygaâ next time, don't have your office inside a moored zeppelin
<pedronis> very steampunk of him
<mup> PR snapd#3221 opened: snap-repair: add `snap-repair run` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3221>
<Chipaca> zyga could totally rock the steampunk mad scientist thing
<zyga> pstolowski: question
<zyga> pstolowski: so let's say we have connect
<zyga> pstolowski: and connect hooks run
<zyga> pstolowski: when should we correct the mount namespace
<zyga> pstolowski: I'd say we should correct the mount namespace before the connect- hook runs the mount namespace must be already adjusted
<Chipaca> zygaâ snapd#3141 is green and you looked at it but didn't actually review it
<mup> PR snapd#3141: many: show available "tracks" in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3141>
<Chipaca> mupâ you should totally use colours to include status for some of these things
<mup> PR snapd#3222 opened: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis_> zyga: ^^
<Chipaca> gah, https://forum.snapcraft.io/t/cant-install-snap-app/376/2 is another one of those "nil map" panics
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/3223
<mup> PR snapd#3223: systemd: mount squashfs as read-only <Created by zyga> <https://github.com/snapcore/snapd/pull/3223>
<zyga> Chipaca: is that the fixed one?
<Chipaca> zygaâ I think it was fixed, but I don't know where -- maybe you know more
<mup> PR snapd#3223 opened: systemd: mount squashfs as read-only <Created by zyga> <https://github.com/snapcore/snapd/pull/3223>
<zyga> Chipaca: content.go one
<zyga> Chipaca: and one more reason to review and land https://github.com/snapcore/snapd/pull/3208
<mup> PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208>
 * zyga brb
<morphis> Pharaoh_Atem: https://paste.fedoraproject.org/paste/Oy3r7PpWM9E19LSsBYNYHV5M1UNdIGYhyRLivL9gydE=
<Chipaca> zygaâ where are you seeing 'rw' next to a squash mount?
<zyga> Chipaca: curious, now I don't
<Chipaca> zygaâ what about in 'snap try'?
<zyga> let me dig because I'm sure I didn't write that patch out of the blue
<zyga> Chipaca: no, I didn't try snap try
<zyga> (and that's a good point)
<zyga> ahq
<zyga> aha
<zyga> 665 658 7:7 / /snap/lonewolf/3 rw,relatime master:32 - squashfs /dev/loop7 ro
<zyga> Chipaca: look at mountinfo
<zyga> Chipaca: it is obviously confusing
<zyga> Chipaca: there are two sets of options
<zyga> Chipaca: mount options, where I do see rw, and superblock options where we see ro
<zyga> Chipaca: obviously my patch means little (except for kernel bugs, if any) because the filesystem is readonly
<zyga> Chipaca: but we were mounting a read-only filesystem without the read-only flag as you can see above
<Chipaca> yeah
<Chipaca> zygaâ mount (at least the command) seems to have special-handling of known-ro filesystems like isowhatsit
<zyga> Chipaca: are you sure? (I'm curious, I don't know)
<zyga> Chipaca: I assumed that mount just looked at /proc/mounts
<zyga> Chipaca: that shows less information
<Chipaca> zygaâ mount: /dev/loop5 is write-protected, mounting read-only
<zyga> Chipaca: aha
<zyga> Chipaca: well, I bet you could force-mount ext4 on top of the same loop device
<zyga> so perhaps mount itself does the right stuff early on when it allocates a loopback device
<Chipaca> zygaâ in any case my question about try stands
<Chipaca> ah, try doesn't have fstype=squash i guess?
<Chipaca> zygaâ but, would having ro,bind there work?
<Chipaca> 'cause that would be good i think
<zyga> Chipaca: yes, it would
<Chipaca> make try more like the real thing from the outside
<zyga> Chipaca: I didn't touch that part of the problem
<zyga> Chipaca: when you try you get writable $SNAP (which is very odd)
<abeato> mvo, hi, I hve this small fix for Core: http://people.canonical.com/~abeato/snappy/fix-wpa-conf-typo.diff
<zyga> abeato: nice catch
<zyga> abeato: can you propose that to github.com/snapcore/core
<abeato> zyga, sure, is that the official way for proposing changes to core?
<zyga> abeato: some things are still debs so changes there are made in the regular unregular way
<zyga> abeato: but anything else, yes
<abeato> zyga, got it, thanks
<Chipaca> morphisâ snapd#3156 has spread failures that i *think* are relevant to the branch itself
<mup> PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<abeato> zyga, hm, it does not look like that repo contains /lib/systemd/system/wpa_supplicant.service.d/snap.conf , maybe the debdiff is still needed for this change?
<morphis> Chipaca: I know, and they are specific to that branch
<zyga> abeato: aha, I think ogra_ is the one to know where this part goes
<morphis> zyga, abeato: it goes into the ubuntu-core-conf deb in the image ppa
<Chipaca> morphisâ yup. I think the one from tests/main/completion is caused by whatever is causing the failure of tests/main/snap-sign
<ogra_> abeato, https://github.com/snapcore/core-build/
<ogra_> morphis, ^^^
<ogra_> initrd is landing there too (once i get PR reviews)
<zyga> ogra_: thanks!
<morphis> ogra_: is that the new origin of ubuntu-core-conf?
<ogra_> morphis, right
<abeato> ogra_, ok, thanks
<morphis> ogra_: that misses things
<ogra_> morphis, and will soon also be the upstream branch for initramfs-tools-ubuntu-core
<morphis> ogra_: the .deb in the ppa has a wpa-supplicant.service.d directory in https://github.com/snapcore/core-build/tree/master/config/lib/systemd/system
<abeato> ogra_, yeah, not in that repo :) ^^
<morphis> ogra_: so looks like something is broken
<ogra_> morphis, hmm, that was reviewed against the package source before it landed (i even had to re-do the PR because mvo found issues)
<ogra_> we dropped 3 obsolete bits ... but nothing wpa related
 * ogra_ checks the PPA
<morphis> ogra_: https://launchpadlibrarian.net/310101186/ubuntu-core-config_0.6.40+ppa42_0.6.40+ppa43.diff.gz
<abeato> ogra_, /lib/systemd/system/snapd.generate-network-conf.service is missing too in the gihub repo
<ogra_> morphis, hmm, looks like mvo "just uploaded" ...
<ogra_> abeato, yeah
<morphis> ogra_: the wpa thing is there for quite a long time
<morphis> ogra_: ok, not that long but over a month: Wed, 08 Mar 2017 09:22:16 +0100
<morphis> not sure since when the git repo exists
<ogra_> morphis, march 29
<zyga> Chipaca: one more tweak https://github.com/snapcore/snapd/pull/3224
<mup> PR snapd#3224: interfaces/mount: write current fstab files with mode 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/3224>
<mup> PR snapd#3224 opened: interfaces/mount: write current fstab files with mode 0644 <Created by zyga> <https://github.com/snapcore/snapd/pull/3224>
<Chipaca> zygaâ i'll get to it in a bit
<Chipaca> i'm going to go have lunch
<Chipaca> zygaâ do reviews!
<zyga> Chipaca: I should oto
<zyga> too
<ogra_> morphis, looks like a mid-air crash ... http://paste.ubuntu.com/24447438/
<Chipaca> zygaâ yes.</serious face>
<ogra_> morphis, i'll adjust the branch
<morphis> ogra_: thanks!
<ogra_> morphis, abeato ... please use the branch in the furture (indeed) ...
<morphis> ogra_: +1
<pstolowski> zyga, yes, +1. the idea was that connect- hooks are executed after connection is set up and with correct security profiles are in place
<pstolowski> zyga, as opposed to prepare- hooks
<zyga> pstolowski: thanks for confirming that, I will make sure that this happens
<mup> PR core-build#7 opened: Sync deb <Created by ogra1> <https://github.com/snapcore/core-build/pull/7>
<ogra_> sigh ... wha does that one include all other changes ..
<ogra_> *why
 * ogra_ closes
<mup> PR core-build#7 closed: Sync deb <Created by ogra1> <Closed by ogra1> <https://github.com/snapcore/core-build/pull/7>
<ogra_> silly git :(
<zyga> ogra_: just don't push silly patches ;-)
 * zyga hugs ogra_ 
<zyga> git can be confusing
<mup> PR snapd#3225 opened: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<niemeyer> Good mornings
<zyga> niemeyer: hey
<Son_Goku> moo
<zyga> mvo: locking is now in place, we can return to /snap sharing
<mup> PR snapd#3149 closed: cmd: make locking around namespaces explicit <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3149>
<mvo> zyga: excellent, I will update my pr
<zyga> mvo: thanks!
<morphis> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1444819
<mvo> zyga: pushed, lets see if tests are still happy
<zyga> mvo: thanks!
<zyga> mvo: I'll review it shortly
<ogra_> zyga, well, if i work on a new brasnch i expect it to not commit all other existing branches ...
<abeato> ogra_, hey, have you already updated core-build? I still see the differences with the deb pkg
<ogra_> abeato, no, my git tree is messed up with other patches i need to fix that first
<ogra_> (and got dragged away into other things, it'll be fixed before EOD)
<abeato> ogra_, ack, just wondering, not that I am in a big hurry :) thanks!
<ogra_> after all it is just book-keeping, the core snap uses the deb, not the tree :)
<abeato> ogra_, does that mean I need to propose the debdiff still for the package?
<ogra_> abeato, i'll include it
<abeato> great
<Son_Goku> morphis: comments left
<morphis> Son_Goku: I thought I cleaned all of the remaining references
<Son_Goku> you've got at least an Obsoletes in there
<morphis> right
<morphis> Son_Goku: is gone now when you recheck the spec at the same location
<mup> PR snapd#3223 closed: many: mount squashfs as read-only <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3223>
<pedronis> niemeyer: standup?
<jdstrand> sborovkov: ok
<zyga> mvo: I found another bug with re-exec
<zyga> for snap-confine
<ogra_> zyga, https://forum.snapcraft.io/t/package-lists-for-distro-specific-core-base-snaps/378
<zyga> ogra_: replied
<cwayne> zyga: heya, any update on that kernel landing?
<zyga> cwayne: I didn't check yet
<zyga> cwayne: I can propose a quick branch that targets 2.25 that re-enables this
<Chipaca> jdstrandâ I just noticed I hadn't requested you as a reviewer of snapd#3150
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
 * zyga needs to eat lunch now 
<zyga> mvo: so quick fact, there's still something wrong in the code that syncs aa profile for snap-confine
<Chipaca> jdstrandâ I was just about to ask you if you'd been able to look at it before noticing :-/
<jdstrand> Chipaca: I haven't yet, but it is on my list
<zyga> mvo: I strongly believe it is just in tests but the merge of locking into master will verify that assumption
<zyga> mvo: I'll break for lunch and see if I can find this
<Chipaca> jdstrandâ ah, thank you
<mvo> zyga: do you have more info? what is wrong with the snap-confine aa profile?
<Son_Goku> ogra_: thanks for making that forum post about core snap
<Son_Goku> I'll start taking a look at adjusting my core snap builder to include the necessary things you're asking for
<morphis> Son_Goku: you have a core snap builder?
<Son_Goku> I made one last October
<Son_Goku> for RPM based distros
<morphis> nice
<Son_Goku> I can't *do* anything with it because snapd won't let me use it
<morphis> Son_Goku: that depends :-)
<Son_Goku> but at least I can make the stupid buggers
<morphis> you could try to get a core system working with it
<Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-mkrpmdistcoresnap
<Son_Goku> I made the tiniest core snaps I could because I didn't know what to put in there
<Son_Goku> now that I have some idea, I can try to make a proper one
<cwayne> zyga: thanks
<mup> PR snapcraft#1276 opened: sources: validate unknown source-type in yaml <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1276>
<mup> PR snapd#3018 closed: tests: add empty initrd failover test <Created by fgimenez> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3018>
<lutostag> curious if I can set an env variable to let snap know I am installing in a ci env, so the stats for a particular snap are not misleading
<mup> PR snapd#3226 opened:  snap-repair: add `snap-repair run` #3221  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3226>
<mup> PR snapd#3221 closed: snap-repair: add `snap-repair run` <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3221>
<morphis> niemeyer: if I create a modified debian image on Linode now can snapshot it?
<niemeyer> morphis: Heya, yep
<morphis> niemeyer: ok, let me spawn up one now
<mvo> niemeyer: hey, do you think I should write a "base snaps" proposal in the forum to make it a bit clearer what the intend of those is? seems like there is some confusion
<niemeyer> mvo: +1
<mvo> niemeyer: thanks, will do that
 * ogra_ hugs mvo 
<morphis> niemeyer: getting: 2017/04/24 16:42:32 Cannot allocate linode:debian-unstable-64: cannot create Linode disk with debian-unstable-64: you do not have enough unallocated storage to create this Disk (1200 requested, but only 0 available)
<mvo> ogra_: yw, sorry about the confusion
<morphis> niemeyer: any idea what the reason is for this?
<niemeyer> morphis: What machine is this?
<ogra_> mvo, well, this is the time where i'm sad we dont still use blueprints ... they were awful but you had a clear plan ahead of starting any work :)
<morphis> niemeyer: didn't even started one yet
<morphis> niemeyer: my .spread-reuse.yaml is empty and just running $ spread -reuse -shell linode:debian-unstable-64: within my spread-images branch
<zyga> re
<niemeyer> morphis: This is running on a machine, though.. please paste the whole log
<zyga> darn bug in modem support
<zyga> 16:41 < zyga> mvo: thanks!
<zyga> 16:41 < zyga> mvo: I'm somewhat confused myself, will we mount parts of the core snap into the base snap (snapctl)?
<zyga> 16:43 < zyga> mvo: so I ran a quick test and the profile for snap-confine was stale
<zyga> 16:43 < zyga> mvo: but perhaps that's resend/reuse in spread
<zyga> 16:43 < zyga> mvo: I'm running a clean one to se
<morphis> niemeyer: https://paste.ubuntu.com/24448247/
<niemeyer> morphis: Uh.. pretty awkward
<mvo> zyga: aha, thank you. so the profile writen on the host in /etc/apparmor.d/snaps.core.999.usr.lib.snapd.snap-confine was stale?
<morphis> niemeyer: let me retry with -vv
<zyga> mvo: yes
<zyga> mvo: but as I said, not sure if this is test preparation that's flaky in case of resend
<zyga> mvo: discarded and running now
<zyga> (not sure if will pass)
<morphis> niemeyer: there we go: 2017/04/24 16:47:05 Creating disk on linode:debian-unstable-64 (Spread-14) with debian-unstable-64...
<niemeyer> morphis: Done.. we had two machines with overallocated disks
<morphis> niemeyer: ok let me try again
<niemeyer> morphis: and we _only_ have those two machines.. everything else is busy running CI
<morphis> ok
<zyga> mvo: ok, empty test reproduced this;
<zyga> mvo: let me dig in
<zyga> mvo: but this may affect all kinds of PRs :/
<mvo> zyga: meh, sucks. keen to learn about the details, I can help with the fix
<mvo> zyga: also, good that we find it now in tests and not in the wild :)
<mvo> base snaps is described in the forum now, if it looks good I can write down an implemenation plan next
<zyga> mvo: first modification of the profile for a while
<zyga> mvo: the copied profile is definitely wrong but the other one is correct (the one in the package)
 * zyga is puzzled
<zyga> aha
 * zyga checks one more file
<zyga> mvo: so
<zyga> mvo: the file in the core snap is wrong
<zyga> mvo: we don't update that
<zyga> mvo: so the derived one is also old
<niemeyer> mvo: I've been cutting off the "RFC" sort of comment because that's somewhat implied from the forum context.. most things there are an opportunity for commenting, in a way
<mvo> niemeyer: sure, thank you
<niemeyer> mvo: No problem, just wanted to provide the rationale so it didn't feel abusive
<niemeyer> I've also been attempting to make subjects not super long and avoid uppercasing (recall "IN PROGRESS" at least once for example), to improve browsing
<ogra_> mvo, so it would function like stacked chroots ? you have the "outer chroot" that is basically our core snap running snapd and then you have an "inner chroot" that is te base snap on top serving as execution env for the respective distro focused snap ?
<pedronis> Chipaca: am I confused, or "snap info" is actively using the feature of setting channel="" ?
<Chipaca> pedronisâ you are not confused
<pedronis> so we cannot kill that feature
<pedronis> or paper it over
<Chipaca> pedronisâ it might no longer be necessary though?
<pedronis> because of the channel map?
<Chipaca> pedronisâ 'snap info foo' needs to show info about foo even if there is no foo in stable
<pedronis> yea, so we need it
<zyga> mvo: I think I know what's wrong
<zyga> mvo: testing the fix now
<pedronis> Chipaca: my plan was to default to stable at that level but seems not possible
<Chipaca> pedronisâ sounds like it to me, but maybe there's a different way i don't know
<Chipaca> yeah, for snap info we can't
<mup> PR snapcraft#1277 opened: Handle revoked-uploads case on snap-developer revokes.  <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/1277>
<zyga> mvo: yeah,
<slangasek> zyga, mvo: if you /don't/ use cloud-init to provision your user when deploying it in the cloud, how do you provision your user?
<zyga> mvo: question on the base snap, did you meant to say ubuntu-16.04 vs ubuntu-16?
<zyga> slangasek: we have code that does this from the outside in the step that prepares a spread machine
<zyga> slangasek: AFAIR
<slangasek> zyga: hmm, I don't understand how that's meant to work "from the outside", that sounds like a security hole :)
<zyga> slangasek: before it boots
<zyga> slangasek: we do magic stuff
<zyga> slangasek: (where it means I don't remember)
<slangasek> hmm, well, the instructions mvo gave me don't do any magic stuff before booting
<zyga> slangasek: what did those look like?
<slangasek> zyga: the ones in the bug comment
<zyga> slangasek: ok
<pedronis> Chipaca: would having a AnyChannel bool on SnapSpec be saner?
<morphis> niemeyer: I will try this again later today when we may be have more free instances
<niemeyer> morphis: Ack
 * niemeyer lunches
<niemeyer> Back shortly
<Chipaca> pedronisâ also note channel is explicitly set to "" if a revision is given
<pedronis> Chipaca: yes
<pedronis> that's ok
<pedronis> Chipaca: my issue is that channel="" means stable sometimes in snapd, and sometimes it means any
<pstolowski> pedronis, i've address your comments to #3171
<pedronis> Chipaca: so my idea is that AnyChannel true or Revision is set we set channel="" for the store, otherwise we take "" to mean stable
<Chipaca> hmm, i thought we set it early to 'stable' to avoid this before
<pedronis> Chipaca: we do in snapd the daemon, but not snapd all the places
<Chipaca> which is how we got here, yah
<Chipaca> pedronisâ sounds fair
<pedronis> Chipaca: I mean I can fix it higher up, IÂ just fear that somebody will hit this again
<Chipaca> pedronisâ yeap
<pedronis> ok, I'll try something along this lines and ping you for a review
<pedronis> *these
<zyga> mvo: https://github.com/snapcore/snapd/pull/3227
<mup> PR snapd#3227: tests: copy .real profile as .real <Created by zyga> <https://github.com/snapcore/snapd/pull/3227>
<mup> PR snapd#3227 opened: tests: copy .real profile as .real <Created by zyga> <https://github.com/snapcore/snapd/pull/3227>
 * zyga needs a coffee
<zyga> eat lunch, not drink coffee, go back to start and suspsned
<zyga> monopoly of life
<mvo> zyga: thank you, looking
<zyga> mvo: thanks!
<zyga> mvo: also replied to your base snap post (thank you for posting it!)
<mvo> ogra_: inner vs outer> I think we have not decided on all the details, one question for example is how Ubuntu Core will work, one way would be to have core with just snapd and ubuntu-core-16 as the base which also contian the booting bits. I will update the forum with some of the open questions
<mvo> zyga: thank you! reading now
<ogra_> mvo, yeah, i didnt really take images into account at all ... that was all more focused on execution env for snaps
<zyga> mvo: that commit message is totally meaningless, I wonder what happened when I wrote that!?!
 * zyga is fixing it
<zyga> or something happened in VI
<zyga> it's totally chopped in pieces
<zyga> corrected
 * zyga -> coffee
<Pharaoh_Atem> morphis: why are we using gnupg instead of gnupg2?
<zyga> Pharaoh_Atem: I presume because of the CLI interface they provide
<zyga> Pharaoh_Atem: gpg has terrible API story
<Pharaoh_Atem> I'm aware
<Pharaoh_Atem> gpg intentionally doesn't have an api
<Pharaoh_Atem> if you want something with a semblance of one, you should use gpgme
 * zyga never heard about gpgme
<Chipaca> does not sound like something you'd ask for on a first date
<Pharaoh_Atem> zyga: https://www.gnupg.org/software/gpgme/index.html
<Pharaoh_Atem> I'm rather surprised you didn't know about gpgme
 * zyga will call his software ${somethingelse}made-easy
<zyga> Pharaoh_Atem: I didn't touch assertion code
<cwayne> zyga: any chance that fix was in -75 kernel?
<zyga> cwayne: didn't get to the checking part yet
<zyga> cwayne: let's see
<zyga> cwayne: -75?
<zyga> cwayne: I see -49 now
 * zyga wonders why opensuse made leap 41 and 42 and now switches to ...15
<zyga> equally meaningless number
<pedronis> Pharaoh_Atem: the plan is to possibly drop gpg at some point,  it's not used at runtime, it's used at snap/device development time
<Pharaoh_Atem> pedronis: that seems like a bad idea
<Pharaoh_Atem> so it's not possible to digitally sign and verify those signatures at runtime?
<pedronis> Pharaoh_Atem: we use the go libraries for that
<Pharaoh_Atem> the horror never stops
<mup> PR snapd#3228 opened: store,daemon: make store interpret channel="" as stable in most cases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3228>
<pedronis> Chipaca: ^
<zyga> Pharaoh_Atem: I really don't understand your problem
<zyga> Pharaoh_Atem: if we used python and "import cryptography" that would do exactly this I don't think you'd complain
<zyga> Pharaoh_Atem: using libraries is a perfectly natural way of doing things
<zyga> hmm
<zyga> refresh delta from core fails now
<zyga> presumably because new core mvo built
<zyga> pedronis: the ensure TestEnsureLoopPrune test failed again
<zyga> pedronis: I wonder if this has any correlation to the core snap builds?
<Pharaoh_Atem> zyga: afaik, go libraries reimplement everything rather than using system resources
<Pharaoh_Atem> python-cryptography and similar libraries don't attempt to reimplement crypto
<Pharaoh_Atem> they just expose a nicer interface for already well-tested and well-vetted libraries
<zyga> Pharaoh_Atem: such as? crypto in C is terrible
<zyga> Pharaoh_Atem: also go didn't link to other things very well until recently
<Pharaoh_Atem> crypto in general is terrible
<Pharaoh_Atem> so it's not really worth blaming it on C or any other language
<Pharaoh_Atem> crypto is one of the hardest things to implement "correctly" in any language
<zyga> Pharaoh_Atem: yes but C has a class of issues that's impossible in go
<zyga> Pharaoh_Atem: my point is that I think having a good language tends to see reimplementation of critical infra
<Pharaoh_Atem> it's hard to beat how awful C can be :)
<zyga> Pharaoh_Atem: and go is just one example of that
<Pharaoh_Atem> when Go gives me nice shared libraries, then I'll concede
<zyga> Pharaoh_Atem: not sure how the rust community has done this but I woudn't be surprised to see it
<Pharaoh_Atem> you're right
<zyga> Pharaoh_Atem: well, does java give you those (that you can use from C)
<Pharaoh_Atem> but I don't particularly like that reusability is still awful in Rust
<zyga> Pharaoh_Atem: shared library that's cross language is hard
<zyga> Pharaoh_Atem: as languages get more stronger checks done at build and link time
<Chipaca> jdstrandâ o/
 * zyga reboots
<Chipaca> jdstrandâ answered in-pr, thought i'd catch you here but never mind
<Chipaca> wondering about %q. Probably best if i write a test to explain what i mean.
<Chipaca> >sigh<
<pedronis> zyga:Â it seems to be failing to the other side, like not that not enough time has passed, but too much
<pedronis> s/to the other/from the other/
<pedronis> zyga:Â IÂ mean chg1 was not just aborted but also removed it seems
<pedronis> need to dig a bit more
<mezzopiano> Hi everyone, a quick question -- I just installed docker via snap, and though the daemon is running and the snap-based interfaces are ok, I can't connect to it via the normal user, and root cannot stat the user's home directory. Usually I would simply add the user to the docker group so that it can interact with the daemon, but adding users to groups seems to be an as-yet unsolved problem (e.g. https://forum.snapcraft.io/t/snapp
<mezzopiano> Could you give me a hint as to how to add docker access for a regular user?
<mezzopiano> Any ideas are much appreciated. Thanks in advance!
<mezzopiano> (btw, I'm running snap 2.23.6 [16 series] on ubuntu core)
<niemeyer> There we go: https://forum.snapcraft.io/t/review-sprint-1/377
<mup> PR snapd#3227 closed: tests: copy .real profile as .real <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3227>
<niemeyer> Wrote a small tool to update the statuses, so they should be more realistic and more frequently updated
<mezzopiano> Just a subtle ping -- any hints whatsoever regarding the installation of docker within snappy core would be massively appreciated. I've now also tested the fancy new release candidate ( https://forum.snapcraft.io/t/call-for-testing-docker-snap/362 ), but to no avail. What might I be doing wrong?
<kyrofa> mezzopiano, it might be worth posting in the forum
<kyrofa> mezzopiano, you'll get more eyes
<mezzopiano> kyrofa: Thanks, I haven't given up hope yet that I am missing something super-obvious. I will go to the forum eventually, but this can't be that hard, can it?
<kyrofa> mezzopiano, it kinda depends on the snap, and I'm afraid I at least have zero familiarity with it
<mezzopiano> Ok, success -- I found the new command docker.help (ships with the latest candidate), and that outlines a proper setup. Phew!
<mezzopiano> kyrofa: Thanks for chiming in!
<kyrofa> mezzopiano, ah, excellent!
<kyrofa> mezzopiano, haha, I was no help, but you're welcome :P
<mezzopiano> kyrofa: It helps a lot of times just to have somebody respond -- thanks for your patience :-)
<kyrofa> Of course, any time
<mezzopiano> Docker is now working beautifully as ever :-) .
<kyrofa> Wonderful!
<mup> PR snapd#3117 closed: tests: parameterize gadget snap channel <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3117>
<pedronis> zyga: I'm saying tests failing like this:  ERROR run hook "configure": cannot create lock directory /run/snapd/lock: Permission denied
<zyga> pedronis: I fixed this in master earlier today
<zyga> pedronis: if you merge it should be good
<zyga> pedronis: unless you already have 12147158ce41c7c2c896c6645008476edeec4a69 and it still fails
<zyga> pedronis: then I want to know because it may be something more
<pedronis> zyga: I see, I thought at least one of my branches was really recent, but seems not, I will merged master into my branches and see how it goes
<zyga> pedronis: thanks
 * zyga fixes his spread tests to work, gee so many typos on "dry run" coding
<kyrofa> jdstrand, I've hit another issue running the nextcloud snap in lxc
<kyrofa> jdstrand, php-fpm creates a worker to service requests, and then the worker goes away once it's done servicing
<kyrofa> jdstrand, however, on lxc, this turns into a defunct process instead of actually going away
<kyrofa> jdstrand, the end result is that Nextcloud can only seem to handle one request or so before never responding again
<kyrofa> Any idea what could be causing this?
<jdstrand> kyrofa: are there any denials?
<kyrofa> None on the container itself, but there are plenty on the host
<kyrofa> Here:
<kyrofa> Ah, let me restart it again so I an get a good paste
<kyrofa> jdstrand, here: http://pastebin.ubuntu.com/24449820/
<kyrofa> I don't really know how to parse those, though
<jdstrand> kyrofa: I've not seen the peer="---" denial before. it seems like nextcloud in the container is trying to talk to itself via an anonymous socket and is getting blocked. I think we need jjohansen to look at that
 * zyga looks too
<zyga> peer="---"
 * zyga has no idea what that is
<jjohansen> kyrofa: what kernel? there was fix for this rolled out a while ago
<zyga> jjohansen: was that fixed and undone when the whole apparmor changes were reverted?
<jjohansen> zyga: the --- indicates that the peer has a label that is not visible
<kyrofa> jjohansen, 4.4.0-72
<jjohansen> zyga: I'm looking
<kyrofa> Looks like I can update to -75
<jdstrand> jjohansen: ok, not sure what you and zyga are talking about, but kyrofa and I were talking about the nextcloud snap running in lxd getting denials of this form: http://pastebin.ubuntu.com/24449820/
<jdstrand> jjohansen: see backscroll from a few minutes for context
<jjohansen> jdstrand: that is precisely what we are talking about
<jdstrand> ok. I don't know how zyga knows what kernel version kyrofa is running, but ok :)
<jdstrand> ah, nm
<jdstrand> I am doing too many things at once
<jjohansen> kyrofa, zyga: so it went into 4.4.0-73
<kyrofa> Nice, updating then!
<kyrofa> jjohansen, zyga jdstrand yep, that fixes it, no more defunct processes
<kyrofa> Thank you all!
<zyga> kyrofa: the real thanks go to jjohansen :)
<zyga> jjohansen: hey, quick question, did you manage to make that branch that tracks apparmor patches against mainline?
<jdstrand> jjohansen: nice!
<jjohansen> zyga: there is http://kernel.ubuntu.com/git/jj/linux-apparmor-backports/
<jjohansen> the v4.10-aa3.6-backport-to-vXXX branches are up to date zesty from a 5 weeks ago
<jjohansen> however I don't have an update for 4.11 yet, and
<jjohansen> v4.1, v4.0 are very much a wip, and I haven't taken it all the way back to 3.10 yet
<zyga> jjohansen: I think the mainline based branch is the most intestesting one
<jjohansen> sure, and sometime this/next week I'll add a 4.11 one
<jdstrand> jjohansen: oh, hey, I guess the bug that was fixed was bug #1660832 ?
<mup> Bug #1660832: unix domain socket cross permission check failing with nested namespaces <verification-done-xenial> <verification-done-yakkety> <apparmor (Ubuntu):Confirmed> <linux (Ubuntu):Fix Released> <apparmor (Ubuntu Xenial):Confirmed> <linux (Ubuntu Xenial):Fix Released> <apparmor (Ubuntu
<mup> Yakkety):Confirmed> <linux (Ubuntu Yakkety):Fix Released> <apparmor (Ubuntu Zesty):Confirmed> <linux (Ubuntu Zesty):Fix Released> <https://launchpad.net/bugs/1660832>
<jdstrand> it's funny because I just went back to looking at my inbox and that was the first thing there :)
<jjohansen> jdstrand: yes
<kyrofa> Haha
<pedronis> niemeyer: niemeyer: master is broken on linode:ubuntu-core-16-64:tests/main/failover:emptyinitrd (I'm seeing that one failing also on my PRs), I think it was merged recently
<pedronis> not sure if it's broken or just very flaky, or interacted with something that was merged
<niemeyer> Oh noes
<niemeyer> This test itself was just merged wasn't it?
<pedronis> niemeyer: yes, very recent
<pedronis> I think
<pedronis> niemeyer: here's a failing run: https://travis-ci.org/snapcore/snapd/builds/225329709
<pedronis> mmh, it's failing with:    ERROR cannot replace signed kernel snap with an unasserted one
<pedronis> not sure how it passed
<pedronis> initially
<pedronis> unless I'm misreading the logs
<niemeyer> pedronis: I suggest disabling the test and asking fgimenez to have a look tomorrow
<pedronis> niemeyer: ah, it might an interaction with the other change about parametrizing channels
<niemeyer> So we're not blocked on that otherwise
<niemeyer> Yeah, could be
<niemeyer> School run... back later
 * zyga EODs
<mup> PR snapd#3137 closed: overlord: switch to aliases v2 tasks for install/refresh etc ops plus transition <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3137>
<pedronis> niemeyer: merged my first PR together with disabling that test for now
<niemeyer> pedronis: Sweet, thanks!
<niemeyer> pedronis: I've included spread status on the latest review sprint board
<niemeyer> pedronis: Only when they fail, specifically, so it's more visible
#snappy 2017-04-25
<mup> PR snapcraft#1278 opened: recording: save the snapcraft.yaml in the resulting snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1278>
<zyga> good morning
<zyga> mvo: how are you doing? :-)
<mvo> hey zyga
<mvo> zyga: I'm doing very well, played hockey last night, what more to wish for?
<zyga> mvo: nice :)
<zyga> mvo: I spent some time digging through an issue and finally got to a more-less working update-ns
<zyga> hmm, tests are a bit more unreliable lately
<zyga> or maybe just more starved for resources
<mvo> zyga: yeah, tests are a bit flaky, annoying
<mvo> zyga: but I have not seen a pattern yet
<malanve> Hi there!
<malanve> Anyone online?
<zyga> hey
<zyga> indeed
<leeboby> hi
<malanve> Morning
<malanve> I have a serious stupid question
<malanve> Does snapd work for SLES (Suse Linux Enrerprise Server)
<malanve> Does snapd work for SLES (Suse Linux Enrerprise Server)?
<zyga> malanve: hey
<zyga> malanve: we have a openSUSE build and we're working on fixing some issues there still, we didn't look at SLES support yet but I'd certainly like to support it too
<zyga> malanve: you can try the system:snappy repository to see if it'd work with a simple rebuild
<morphis> malanve: there are also instructions available on https://snapcraft.io/docs/core/install-opensuse
<malanve> morphis: Not looking for Opensuse, SLES instead.
<malanve> zyga: Thanks, but I have already tried LOL
<morphis> malanve: for SLES we don't have packages atm
<morphis> but its on our list
<malanve> Thanks Guys!
<morphis> actually I didn't looked yet what is required to get the snapd.spec building for SLES
<morphis> could be that there are a few dependencies missing in SLES
<malanve> Well....
<malanve> sudo zypper install snapd Loading repository data... Reading installed packages... Resolving package dependencies...  Problem: nothing provides systemd needed by snapd-2.23.6-1.6.x86_64  Solution 1: do not install snapd-2.23.6-1.6.x86_64  Solution 2: break snapd-2.23.6-1.6.x86_64 by ignoring some of its dependencies  Choose from above solutions by number or cancel [1/2/c] (c):
<malanve> There is your first dependency
<malanve> sudo zypper install snapd Loading repository data... Reading installed packages... Resolving package dependencies...  Problem: nothing provides systemd needed by snapd-2.23.6-1.6.x86_64  Solution 1: do not install snapd-2.23.6-1.6.x86_64  Solution 2: break snapd-2.23.6-1.6.x86_64 by ignoring some of its dependencies  Choose from above solutions by number or cancel [1/2/c] (c):
<malanve> Whoops
<morphis> malanve: ah, no systemd
<morphis> that makes things a bit harder
<morphis> systemd is more or less a strict requirement for snapd
<morphis> malanve: which SLES version are you running?
<mup> PR snapd#3224 closed: interfaces/mount: write current fstab files with mode 0644 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3224>
<malanve> morphis: SUSE Linux Enterprise Server 11 SP4
<morphis> looks like 12 introduced systemd if I am not looking wrong
<zyga> malanve: I think we will only support SLES 15
<zyga> malanve: maybe 12 as well (as it matches leap 42)
<malanve> There SUSE Guys and them versioning.... LOL
<malanve> Thanks a lot for the info
<malanve> These SUSE Guys and them versioning.... LOL
 * zyga just shrugs thinking "LOL"
 * zyga has wired snap-update-ns into the rest of snapd, running tests now
<zyga> mvo: when is 2.25?
<zyga> mvo: is that now-now?
<mvo> zyga: the aliases branch need to land, right now we cannot release
<zyga> mvo: I think update-ns should be merged just after release
<mvo> zyga: so when this is ready we can do 2.25
<zyga> mvo: then have a cycle of testing
<mvo> zyga: sounds good, or we hide it behind a feature flag
<zyga> mvo: how could we do that?
<zyga> mvo: I actually do like that
<zyga> mvo: store a permanent feature flag in the snapd state?
<zyga> mvo: then have a get/set via debug API
<zyga> mvo: something like that?
<zyga> wow that all worked
 * zyga commits
<zyga> I'll run a full pass over main
<mvo> zyga: or just an environment that people need to set in /etc/systemd/systemd/snapd.conf.d or /etc/environment
<zyga> (with automatic updates to mount namespaces)
<mvo> zyga: does not have to be super fancy, but merging after 2.25 also works
<mvo> zyga: nice!
<zyga> mvo: I think it all depends on if we can merge current branches :)
<zyga> mvo: thanks for merging some of them btw :)
<zyga> I think currently the most important one is https://github.com/snapcore/snapd/pull/3225
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<zyga> mvo: I added https://github.com/snapcore/snapd/pull/3208 to 2.25 as we had a few people crash their snapd with 2.24
<mup> PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208>
<mvo> zyga: sounds good, I think we just need a review from gustavo on this one
<zyga> mvo: okay
<pstolowski> good mornings!
<zyga> pstolowski: hey
<zyga> mvo: do you remember what discards all namespaces between test invocations?
<mvo> zyga: unfortunatly not, would have to look around, probably tests/lib/restore.sh
<zyga> mvo: do we just purge the package?
<mvo> zyga: yes we do
<mvo> zyga: tests/lib/reset.sh
<zyga> mvo: aha, thanks, I think I got it now :)
<zyga> ok, so snap-update-ns works, snap-confine writes the current profile, snap-discard-ns removes the current profile, snapd runs snap-update-ns when needed
<zyga> I'll focus on testing but all the patches so far look great
<zyga> mvo: one request, would you +1 a small branch that makes snap-confine/snap-discard-ns grok the current profile for 2.25
<zyga> mvo: the changes are minimal there, I'll push a PR if you want to see
<zyga> mvo: this way the 2.26 release will already start with the currnet profile in most cases
<zyga> mvo: and thus nobody will have the more complex upgrade case
<pedronis> mvo: hi, yes, I'll be working on the feedback on aliases branches today, another one just need a small tweak and then I can land it... the unalias one needs larger changes that I will do
<pedronis> mvo: I'll have a couple more small branches as well
<mvo> pedronis: thanks for the update
<mup> PR snapd#3229 opened: overlord/snapstate: make UpdateAliases idempotent, simplify the backend interface bits for aliases not used anymore <Created by pedronis> <https://github.com/snapcore/snapd/pull/3229>
<pedronis> mvo: would appreaciate a review of snapd#3229, it's small,  it was of those related small branches
<mup> PR snapd#3229: overlord/snapstate: make UpdateAliases idempotent, simplify the backend interface bits for aliases not used anymore <Created by pedronis> <https://github.com/snapcore/snapd/pull/3229>
<pedronis> s/it was/it's one/
<morphis> mvo: having https://github.com/snapcore/snapd/pull/3177 in 2.25 would be great, its actually really close now
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<pedronis> mvo: also snapd#3328 small (not aliases but the issue I discussed at standup)
<morphis> mvo: you and jdstrand approved I am just waiting for the last tests to go green
<pedronis> morphis: it will take a while for the aliases bits in case
<morphis> pedronis: ok
<pedronis> also tests are flakey
<mvo> zyga: ups, missed the question about the profile. I think thats fine
<mvo> pedronis: checking 3229
<mvo> pedronis: yeah, was looking at 3328 earlier, there will be conflicts with the "tracks" branch, but we can sort those easily (its mostly code going away in the channels-2.0 branch)
<mvo> pedronis: have you seen a pattern in the tests? I saw only some network issues and resource issues (cannot allocate machines). have you seen more?
<pedronis> mvo: yes, what's blocking the tracks one?
<mvo> pedronis: quick question about the repair work, what primary key (instead of repair-id) would you suggest
<mvo> pedronis: I htink the tracks one is ready now, got a +1 from gustavo last night and I think I addressed his few open questions/suggestoins
<pedronis> mvo: ok, good
<pedronis> mvo: the question about the reapair-id, is mostly if we let other entities emit repair assertions how do we carve out the namespaces? or do we want to make authority-id, or have brand-id in the assertion and part of the primary key
<mvo> pedronis: aha, so primary key would be (brand-id, repair-id) ?
<pedronis> yes
<pedronis> but I think maybe we should have a short meeting with Gustavo to discuss this out
<pedronis> or discuss it in the forum
 * pedronis late breakfast while tests run
<mvo> pedronis: thank you, this makes a lot of sense in the light of the open-up-for-brands later. I will put it into the forum
<mvo> pedronis: enjoy breakfast
<morphis> mvo: https://github.com/snapcore/snapd/pull/3177 is ready now
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<mvo> morphis: excellent, I give it a final look but I am pretty sure its excellent
<morphis> mvo: :-)
<mup> PR snapd#3177 closed: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3177>
<morphis> mvo: thanks a lot!
<Chipaca> mvoâ today's the cutoff for 2.25, yes?
<mvo> Chipaca: ideally, its a bit unusual this time because we need the aliases branches in
<mvo> Chipaca: so the goal is today but it depends on reviews for those
<pedronis> Chipaca: hopefully, we need aliases in, so IÂ think either today, or middle of tomorrow
<pedronis> for some value of middle
<Chipaca> I'd _really_ like to get tab completion in as well
<mvo> Chipaca: the door is open :) there is a bunch of stuff tagged for 2.25, I would love to see refresh-schedule landing. and tracks-2.0
<Chipaca> sigh
<pedronis> mvo: should IÂ merge #3141, it's green
<mvo> Chipaca: speaking of which, are there any concerns about the (small) ui change for channels-2.0 ?
<Chipaca> mvoâ i haven't heard any
<mvo> pedronis: there is a (small) ui change, instead of "stable" it now says "latest/stable". but if everyone if ok I think we should merge it
<pedronis> ah
<Chipaca> mvoâ in fact snapd#3141 seems to have two +1's and is green
<mup> PR snapd#3141: many: show available "tracks" in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/3141>
<mvo> Chipaca: great, then lets go ahead
<Chipaca> heh, yeah
<mvo> pedronis: -^
<Chipaca> I think there is one aliases branch i haven't reviewed yet, 3220, but it's the last one in the pipe
<mup> PR snapd#3141 closed: many: show available "tracks" in `snap info` <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3141>
<pedronis> Chipaca: there's a new small one as well #3229
<pedronis> Chipaca: and there's another one that needs changes after Gustavo's feedback
<pedronis> mvo: I'm going to fix the conflicts in #3228
<pedronis> now
<pedronis> mvo: snapd#3228 can be reviewed
<mup> PR snapd#3228: store,daemon: make store interpret channel="" as stable in most cases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3228>
<morphis> mvo, zyga: a review on https://github.com/snapcore/snapd/pull/3222 would be great
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<pedronis> Chipaca: mvo: as I said reviews for #3229 appreciated (it's small)
<mvo> pedronis: just looking at it
<mvo> pedronis: looks fine, wondering if it can ever happen that UpdateAliases(add, remove) gets the same alias.Name in both add and remove, e.g. to change alias.name to a new alias.target. but I guess no?
<pedronis> mvo: it can happen but it works anyway
<mup> PR snapd#3136 closed: snap-confine: add code to ensure that / or /snap is mounted "shared" <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3136>
<mvo> pedronis: oh, you are right of course
<pedronis> mvo: removed is for that case, it's just an opt though really
<mvo> pedronis: yeah, I see that now. thank, will approve
<mup> PR snapd#3230 opened: tests: extend network-control spread test to cope with network namespaces <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3230>
<pedronis> thx
<Chipaca> morphis, mvo, are there any distros where bash-completion isn't installed in /usr/share/bash-completion?
<morphis> Chipaca: good question
<morphis> on fedora it is
<mvo> Chipaca: a really good question, no idea. it is on debian
<zyga> ooh
<zyga> 139 tests passing with update-ns :D
 * zyga starts to shoot branches
<mup> PR snapd#3191 closed: many: implement snap alias <snap.app> <alias> (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3191>
<pedronis> ok, back to bigger fish now
<mup> PR snapd#3229 closed: overlord/snapstate: make UpdateAliases idempotent, simplify the backend interface bits for aliases not used anymore (aliases v2) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3229>
<pstolowski> pedronis, hey, 3220 appears to have conflicts
<pedronis> I need to fix 3192 first anyway
<mvo> pedronis: I can look at the conflicts in 3220 if you want
<mvo> (my branch caused them afterall)
<pedronis> mvo: no, 3220 is something else
<mvo> aha, 3228 is the one I had in mind
<pedronis> and the conflicts are already in 3192
<pedronis> mvo: that one is fixed already, just needs a 2nd review
<mvo> pedronis: cool, let me do that then
<pedronis> mvo: I mean I fixed the conflicts
<morphis> zyga, mvo: https://github.com/snapcore/snapd/pull/3222 would be nice to get merged too now that all tests are passing
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> morphis: hey
<zyga> morphis: I'll have a look in a sec
<morphis> zyga: whenever you have time :-)
<zyga> morphis: just finished a call and I'm wrapping up something
<morphis> ok
 * zyga looks now
<pstolowski> zyga, commented on 3225
<zyga> thanks, checing
<zyga> checking*
<zyga> pstolowski: replied
<pstolowski> k thanks
<zyga> mvo: added one small branch to 2.25, I'll add two more (equally short)
<mup> PR snapd#3231 opened: cmd/snap-discard-ns: remove current profile when cleaning up <Created by zyga> <https://github.com/snapcore/snapd/pull/3231>
<mvo> zyga: ok
<mup> PR snapd#3232 opened: cmd/snap-confine: write current mount profile <Created by zyga> <https://github.com/snapcore/snapd/pull/3232>
<mup> PR snapd#3233 opened: packaging: remove current mount profiles when purging <Created by zyga> <https://github.com/snapcore/snapd/pull/3233>
<zyga> mvo: done
<mvo> zyga: brace yourself for a grumpy review ;) - I see a lot of C
<zyga> mvo: not lots, very little!
<zyga> mvo: :D
<mvo> zyga: yeah
<zyga> mvo: if those three PRs land 2.26 will be efortless
<zyga> for update-ns
<mup> PR snapd#3234 opened: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234>
<mup> PR snapd#3235 opened: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <https://github.com/snapcore/snapd/pull/3235>
<zyga> pstolowski: updated https://github.com/snapcore/snapd/pull/3225
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<zyga> pstolowski: looking at https://github.com/snapcore/snapd/pull/3235/files I don't understand the nesting/looping there
<mup> PR snapd#3235: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <https://github.com/snapcore/snapd/pull/3235>
<zyga> pstolowski: maybe it'd be easier if the function was reworked to do "bail out" style
<zyga> pstolowski: if !something { return false };
<zyga> pstolowski: instead if a { if { b if c { } } }
<zyga> pstolowski: the loop and second check for run-hook kind is something I don't understand though, can you help?
<morphis> Chipaca: /usr/share/bash-completion exists in suse too
<morphis> hm, Linode is really overallocated ..
<zyga> morphis: yeah
<zyga> morphis: sorry, I pushed a few branches now and spread, without queueing, is really bad
<morphis> it is
<morphis> zyga: aren't we specifying a maximum number of concurrent builds for travis?
<zyga> not sure
<morphis> https://docs.travis-ci.com/user/customizing-the-build/#Limiting-Concurrent-Builds
<pedronis> lots of test run timing out :(
<pstolowski> zyga, ok, let me rework it a little bit and you will let me know if it needs explanation
<zyga> morphis: have a look at https://github.com/snapcore/snapd/pull/3222/files
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> pstolowski: thanks
<ogra_> mvo, i think i addressed all issues in https://github.com/snapcore/core-build/pull/6 (dont want to make shellcheck a build-dep, i'll add another branch that runs it for every commit instead)
<mup> PR core-build#6: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <https://github.com/snapcore/core-build/pull/6>
<zyga> morphis: I'm reviewing the rest, I only gave one nitpick about the true/false argument
<morphis> zyga: ok, reworking that
<zyga> thank you!
<zyga> morphis: will that let you run tests on fedora already?
<zyga> morphis: or just the first step towards that
<morphis> zyga: yes that allows us running all tests with 100% pass rate but just for the vendorized build
<zyga> morphis: oh, that's nice
<morphis> zyga: for the not-vendorized build we need to update a few more packages
<morphis> zyga: and introduce one new package
<zyga> morphis: I'll look at suse reviews, I think that needs some love too
 * zyga breaks for lunch
<morphis> zyga: I am on that one right now
<zyga> I'll focus on code reviews now
<zyga> for the rest of the day
<zyga> I'll start with chipaca's, then morphis' then jdstrand's
<morphis> zyga: sounds good
<zyga> 2017-04-25 10:37:01 Cannot allocate linode:ubuntu-core-16-64: cannot create Linode disk with ubuntu-core-16-64: you do not have enough unallocated storage to create this Disk (608 requested, but only 0 available)
<zyga> pstolowski: replied on https://github.com/snapcore/snapd/pull/3225
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<pstolowski> zyga, ok, will check in a moment. I've simplified 3235 a bit, let me know if it's more clear now
<zyga> pstolowski: checking!
<zyga> pstolowski: nice!!
<morphis> zyga: updated https://build.opensuse.org/request/show/490989
<zyga> morphis: I just got a beep on my phone :)
<zyga> morphis: thanks!
<morphis> zyga: hehe
<zyga> morphis: what is the rcsnapd file?
<morphis> that is something suse wants for systemd services to have backward compatiblity with sysvinit
<morphis> rpmlint complains about this when it's not there
<morphis> zyga: https://en.opensuse.org/openSUSE:Packaging_checks#suse-missing-rclink
<zyga> morphis: approved
<morphis> zyga: thanks
<pstolowski> zyga, cool. i need to get rid of the habit of nesting if's... :/
<mup> PR snapd#3228 closed: store,daemon: make store interpret channel="" as stable in most cases <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3228>
<mvo> ogra_: thank you, I have a look
<ogra_> sigh ...runniing shellcheck on the whole tree gives some mad ooutput :/
<morphis> ogra_: snapd tree?
<ogra_> morphis, core-build tree
<morphis> ah
<mvo> ogra_: yeah, we will certainly need to exclude some tests
<ogra_> i'm working on a travis commit check ... but simply running shellcheck gets me like 100 lines about missign quotes
<mvo> ogra_: i.e. --exclude=1,2,3 etc :) anyway, maybe not worth the hassle
<ogra_> and some really pointless bits ... like
<ogra_>             for i in $(cat /proc/cmdline); do
<ogra_>                      ^-- SC2013: To read lines rather than words, pipe/redirect to a 'while read' loop.
<ogra_> (that code obviously wants to read words, not lines)
<ogra_> mvo, well, i wonder how we can exclude only single hits like the above ... SC2013 doesnt seem like a bad suggestion but i dont want to be notified for "cat /proc/cmdline"
<zyga> re
<mup> PR snapcraft#1261 closed: storeapi:  improve the error message for the case the Store answers an upload needs manual review <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1261>
<niemeyer> o/
<zyga> niemeyer: hey :)
<pstolowski> mvo, any idea why https://travis-ci.org/snapcore/snapd/builds/225133882 says "All good..", yet travis concluded a failure?
<pstolowski> hi niemeyer !
<zyga> all good, patient died
<zyga> weird :)
<zyga> pstolowski: I saw that too a few times
<pstolowski> :)
<zyga> I just re-triggered
<zyga> though I'd wait now, everything is busy
<mvo> pstolowski: usually when the static tests earlire faied
<mvo> failed
<youmin> hi everyone, I spend more than 3h to set up static IP address on Dell Edge with Core 16 without success. I tried everything... network-manager, interfaces, etc. Ideas?
<zyga> /home/travis/gopath/src/github.com/snapcore/snapd/cmd/snap/cmd_changes_test.go:133:2: ineffectual assignment to rest
<zyga> pstolowski: ^^ indeed
<zyga> the static check should have stopped the rest
<mvo> I think we should fix that in our tests, i.e. fail early
<zyga> youmin: hey
<zyga> mvo: yeah
<zyga> youmin: at what stage are you know, do you have a keyboard/monitor connected to your device?
<pstolowski> zyga, ah! thanks
<youmin> zyga: I have access through network and console
<zyga> s/know/now/
<zyga> youmin: ok, so from the console run ...
 * zyga thinks
<zyga> console-conf?
<zyga> ogra_: is that how the binary is called?
<ogra_> zyga, yep
<zyga> yeah
<ogra_> you want sudo
<zyga> fortunately the core snap is at hand to check ^_^
<zyga> youmin: run sudo console-conf
<zyga> youmin: and follow along :)
<zyga> youmin: I also recommend that you check out forum.snapcraft.io
<mvo> pstolowski, zyga: I will do a branch in a bit that makes it fail early, silly travis :)
<zyga> mvo: thank you!
<ogra_> zyga, though the dell might be special ... i.e. using some kind of assertion mgmt and NM
<zyga> ogra_: oh, I see
<ogra_> not sure ...
<zyga> youmin: if that doesn't work please open a question on the forum
<zyga> youmin: the people that know the dell gateway very well will surely answer
<ogra_> right, the CE guys shoudl know and be able to answer if it doesnt work
<youmin> zyga: thanks I'll try it, is not possible to configure that manually?
<morphis> youmin: you need to do that via nmcli, can you tell me what you tried so far?
<ogra_> sigh ... shellcheck really makes me doubbt my shell skills :P ... so many missing quotes
<youmin> morphis: I did it with nmcli and it's automatically reconfigured by the system when I reboot, I don't know how to do that properly
<morphis> youmin: can you show me what exactly you did?
<youmin> morphis: the problem is not my knowldge about nmcli because it works and when I reboot my configuration disapear
<zyga> youmin: I think this is managed through netplan
<zyga> youmin: netplan describes the configuration declaratively
<zyga> youmin: this is picked up by either systemd-networkd or nmcli
<morphis> zyga: no, no netplan
<zyga> youmin: (well, network-manager)
<zyga> morphis: oh? no?
<mup> PR snapd#3236 opened: tests: ensure travis fails early if static checks fail <Created by mvo5> <https://github.com/snapcore/snapd/pull/3236>
<zyga> morphis: can you tell me more, I thought that how it worked
<morphis> zyga: you can use netplan yes, but that is not ver well working
<morphis> like for every netplan change you have to restart NetworkManager etc.
<morphis> which will have effects on the actual network configuration ..
<zyga> mmm
<youmin> morphis: where do I can find information about how netplan works?
<morphis> youmin: don't consider netplan for this case, can you show me the exact commands you executed?
<morphis> zyga: I can explain that more in depth later
<morphis> zyga: we plan to inverse the call chain from netplan -> network-manager
<morphis> network-manager needs native read/write support for netplan instead of netplan generates network-manager configuration files
<mup> PR snapcraft#1273 closed: core: check SNAP_NAME to detect if snapcraft is a snap <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1273>
<morphis> Son_Goku: you already took a look at the postrm implementation for the snapd rpm?
<Son_Goku> yep
<Son_Goku> I've got something cooking for snapd 2.25
<morphis> Son_Goku: nice, do you mind if I reuse that for suse then?
<youmin> morphis: I use network-manager.cli con edit eth0 and then using the CLI I modify mode to manual and I set up the network parameters, then I save the config I check the configuration files and I restart network manager and it works perfectly
<morphis> youmin: but not after reboot?
<youmin> after reboot my configuration disapear
<morphis> youmin: you saw the configuration being saved into a file?
<morphis> youmin: do you mind sharing the output of journalctl --no-pager -u snap.network-manager.networkmanager with me?
<youmin> morphis: yes it is in the network-manager directories
<youmin> morphis: now I lost the log because I reconfigured it with console-conf like you told me; but I don't know where the configuration is saved now
<Son_Goku> morphis: sure, I'll let you know when it's ready
<Son_Goku> I'm still testing and tweaking
<morphis> youmin: can you check which files are in /etc/netplan
<youmin> morphis: yes, here it's. Let me go to have lunch and later I'll follow trying everything
<youmin> morphis, zyga: thanks
<morphis> youmin: can you show me the content of these files?
<youmin>  /etc/netplan$ l 00-snapd-config.yaml
<youmin> sudo cat 00-snapd-config.yaml  # This is the network config written by 'console_conf' network:   ethernets:     eth0:       addresses: [10.2.0.22/26]       gateway4: 10.2.0.1       nameservers:         addresses: [10.2.0.1]         search: []   version: 2
<youmin> now it's working thanks the console-conf configuration
<youmin> sorry I have to have lunch, I'll be here in some minutes
<morphis> youmin: ok, just ping me when you're back :-)
<niemeyer> omw!
<ogra_> morphis, if you implement snapd --user. please also make it time out (or add a --timeout= option the dbus invocation can use) so we dont end up with a constantly running daemon
<morphis> ogra_: good idea
<cwayne> morphis: ping
<morphis> cwayne: pong
<cwayne> morphis: hey after running wifi-ap.setup-wizard it tells me to systemctl restart a service that doesn't seem to exist..
<niemeyer> morphis: Some late review comments on snapd#3177
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3177>
<morphis> niemeyer: thanks! responded on the PR already
<morphis> cwayne: looks like the message is out of date, these days you don't have to restart the service anymore
<morphis> cwayne: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/wifi-ap/tree/cmd/client/cmd_wizard.go#n413
<morphis> cwayne: mind propose a MP to fix that?
<cwayne> morphis: sure
<morphis> cwayne: awesome!
<youmin> morphis: I'm here
<morphis> youmin: ok, can you paste me the content of the files in /etc/netplan?
<youmin> I did it before, but when I paste the format is lost. How do you want to receive that pastebin?
<youmin> https://pastebin.com/aR9YBSDH
<mzanetti> hey, we're trying to host our own snappy store following http://blog.dustinkirkland.com/2016/06/howto-host-your-own-snap-store.html but struggling with the assertions/signatures thing atm. Does anyone have some pointers on how that stuff works?
<morphis> mzanetti: you mean creating assertions or distributing them?
<youmin> morphis: https://pastebin.com/aR9YBSDH
<morphis> mzanetti: general documentation is available at https://docs.ubuntu.com/core/en/reference/assertions
<morphis> youmin: ok, that is one way you can do it but now you can't use nmcli on that connection anymore
<pedronis> mzanetti: there is no documented way to have a full idenpedent store atm, it's something we are thinking about
<youmin> yes, noticed it
<youmin> morphis: yes, I noticed it
<youmin> morphis: is there a way to disable netplan?
<morphis> youmin: just remove all lines from 00-snapd-config.yaml
<youmin> morphis: sorry this is not enough... as I explained some times after reboot configuration of nmcli is lost
<morphis> youmin: sure, but I want to get to find out why :-)
<morphis> youmin: so drop the configuration from 00-snapd-config.yaml, try to configure via nmcli again, reboot and give me the output of $ sudo journalctl --no-pager -u snap.network-manager.networkmanager
<youmin> morphis: me too, I assume Dell guys added anything... I'm going to do what you ask me
<morphis> youmin: trust me, you're talking with the right person to solve this problem :-)
<youmin> nice
<Chipaca> zyga, niemeyer, here do this: mkdir /tmp/foo && cd /tmp/foo && touch "foo$(tput setaf 1 1)bar.txt"
<Chipaca> zyga, niemeyer, and tell me what tab completion does when you try to use it in that directory (eg 'ls <tab>')
<niemeyer> morphis: Thanks!
<niemeyer> ls foo$'\033'\[31mbar.txt
<niemeyer> Chipaca: ^
<Chipaca> exactly
<Chipaca> it's not echoed as control characters to the terminal
<niemeyer> Chipaca: That's slightly different, right?
<Chipaca> niemeyerâ if it is, then i didn't get the point?
<niemeyer> Chipaca: I mean that one is being handled by bash internally to precisely manipulate the terminal line being edited.. the other is trying to do the right thing
<niemeyer> Chipaca: Maybe it's a non-issue, but I wouldn't be convinced just by looking at that example alone
<Chipaca> niemeyerâ that kind of thing you see is what you get when trying to complete control characters
<Chipaca> e.g. if I do, in a function, COMPREPLY=( "hello\rthere" )
<Chipaca> the completion will offer âhello^Mthere"
<mzanetti> morphis: am I reading that right that I should be able to use snap sign to sign our snap package and then somehow host that resulting assertions file on our store?
<niemeyer> Chipaca: Okay, that's great then
<morphis> mzanetti: you have the store working without an assertion?
<mzanetti> morphis: yes, we can snap find and everything, just snap install fails because of the missing assertion and snap download downloads the package and then complains about not finding an assertion
<morphis> mzanetti: easiest would be to install with --dangerous for now
<mzanetti> it says --dangerous can only be used for local files...
<ogra_> that would also prevent updates
<youmin> morphis: https://pastebin.com/hWqT5HXa
<morphis> generating your own signed assertions will be a bit more tricky as you need a trusted key in your store and snapd needs to have its public key configured
<mzanetti> and well, sure, we could, in theory call snap download and then do the --dangerous thing, but this is supposed to be a product, would like to set up things properly
<pedronis> mzanetti: the issue is how to setup the chain of trust,  at the moment snapd doesn't support parallel/multiple chain of trust
<morphis> mzanetti: https://github.com/snapcore/snapd/blob/master/asserts/sysdb/trusted.go
<morphis> mzanetti: but pedronis is the right person you want to talk to about this :-)
<mzanetti> ah ok
<morphis> mzanetti: btw. why do you want to have your own store?
<mzanetti> because canonical promised us one but isn't able to deliver in time
<mzanetti> so, that's kinda plan b already...
<pedronis> but there's no real support for that plan b atm
<pedronis> sorry IÂ don't have enough context to suggest a way forward
<pedronis> you probably need to reengage with the people that propsed plan a
<morphis> mzanetti: so you want a branded snap store, right?
<pedronis> morphis: I suppose not, those are easy to setup
<morphis> pedronis: yeah
<mzanetti> I think yes, that's what we want
<pedronis> then I'm confused, those are easy to setup
<morphis> mzanetti: who is "we"?
<mzanetti> maarten said it's not
<mzanetti> guh.io, that is
<mzanetti> we ^
<ogra_> zyga, do you feel like giving a second ack on https://github.com/snapcore/core-build/pull/6 so i can merge (and move on with the tests) ?
<mup> PR core-build#6: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <https://github.com/snapcore/core-build/pull/6>
<Chipaca> there's some detail escaping us i guess
<pedronis> mzanetti: depends what you are talking about, a branded store in our terminology is a substore in the normal store, but can be private/limited access etc
<mzanetti> yes, that's exactly what we want
<youmin> morphis: in the latest pastebin that I pasted there are the logs that you want
<morphis> youmin: thanks! I will look in a bit
<mzanetti> in order to use snapd to distribute updates to the devices we ship...
<youmin> morphis: no problem
<pedronis> mzanetti: sorry, we really lack context here, as I said we are probably missing something here, because those are relatively easy to setup
<pedronis> there may be a feature or property X  that you need and our current concept doesn't offer
<pedronis> or some other kind of miscommunication
<mzanetti> one sec, will ask t-mon to join, he has more details than I do as I am just about to join them
<ogra_> we definitely have a bunch of branded stores running in production already
<zyga> ogra_: looking
<ogra_> thx
<niemeyer> zyga: I think the Travis thing might be a momentary hiccup of travis itslef
<zyga> niemeyer: what were you seeing exactly?
<niemeyer> There was a period of a day or so where most of the issues happened
<mzanetti> ok, so, t-mon, what exactly is the issue why we can't use the branded snappy store?
<niemeyer> zyga: Spread cleans after itself today.. for us to get space allocation issues, it means several independent PRs were sequentially interrupted in the middle
<niemeyer> zyga: In other words, several independent PRs, one after another, start and are not allowed to finihs
<zyga> ok, I'll push fewer branches, if it happens for whatever reason it will be easier to scope
<niemeyer> Hmm.. one reason why this might happen is if we get our tests to consistently blow the 50 minutes limit
<niemeyer> zyga: ack
<zyga> niemeyer: ah, this is a self accelerating issue then
<niemeyer> zyga: Thanks for keeping an eye
<zyga> niemeyer: you do over 50 because whatever, those machines stay allocated
<zyga> niemeyer: another PR will hit the same issue, use more VMs
<zyga> niemeyer: until all grinds down to a hald
<zyga> halt
<niemeyer> zyga: Well, the timing each unit takes is unrelated to whether other machines are allocated or not
<niemeyer> zyga: So not self-accelerating in that sense
<zyga> niemeyer: yes but you can miss it just by trying to allocate a machine and failing
<niemeyer> zyga: Hmm.. still don't understand it..
<niemeyer> zyga: You can miss what?
<zyga> niemeyer: trying spread-A, busy, trying spread-B no space, trying spread-... then you run and you don't have enough time to finish
<zyga> niemeyer: miss the 50 minute window
<zyga> allocation takes a non-trivial amount of time
<niemeyer> zyga: Ah, yes, although it doesn't really continue forever, nor will the independent tries sum up
<zyga> niemeyer: but if those VMs don't get cleaned up they don't return to the pool instantly
<niemeyer> zyga: But yes, it will consume a slice of time to not be able to allocate
<zyga> niemeyer: so the next PR will have the same experience (unless something else finishes in time)
<niemeyer> zyga: Yes, but it's not accelerating was my point
<niemeyer> zyga: Each PR will wait for a fixed time limit until it gives up
<zyga> niemeyer: once travis kills a job how long does it take for spread to collect those machines?
<niemeyer> zyga: 2h is what we configured on spread.yaml, IIRC
<zyga> and woud that also clean up the disk space?
<jdstrand> ogra_: fyi, new kernels available for generic (bbb)
<jdstrand> ogra_: and hi!
<ogra_> jdstrand, yeah, i saw them on -changes
<ogra_> (and hi! too :) )
<t-mon> Hi! as mzanetti already meantioned, we have a branded store, but maarten told us this is for testing
<mzanetti> pedronis: morphis ^
<t-mon> an we are not able to release snaps (need manual review) which are not allowed
<t-mon> i f we go in production with a test store, and the store will be switched off (for what ever reason) we are dead :-D
<niemeyer> zyga: Spread cleans up every single disk at the end of the test
<niemeyer> zyga: Whether it allocated it for the test or not
<niemeyer> zyga: So to drive it completely out of space a sequence of several mishaps needs to take place
<pedronis> t-mon: sorry, these sounds like commercial issues of which IÂ don't understand the details, IÂ don't think I can help
<mzanetti> hmm, interesting... but from a technical point of view it should just work, no?
<ogra_> yeah ... it definitely does for others
<niemeyer> I've just put 6 more machines on the Spread cluster to help the review week
<pedronis> mzanetti: yes, usually once it's really yours you can do reviews for it etc
<jdstrand> t-mon: I might mention that if you have a branded store, you (or someone working on your behalf) should be in control of the review process to that store. this is part of the commercial pedronis mentioned
<zyga> ogra_: why do we ship dpkg on core?
<ogra_> zyga, ??
<ogra_> zyga, we explicitly remove it
<zyga> /snap/core/current/usr/bin/dpkg
<zyga> try that
<t-mon> perdonis: jdstrand: mzanetti: thanks, I'll get in contact on offical ways :)
<ogra_> (we do ship /usr/local/bin/dpkg to print a pretty error ...
<mzanetti> yeah... that makes sense... ok, we'll try to contact maarten again then... so far we were under the impression that there is something missing on the server end to be able to actually turn the production branded stores
<ogra_> )
<ogra_> zyga, definitely a bug
<zyga> do you want me to report it
<ogra_> zyga, yeah, assign me
<zyga> done
<zyga> https://bugs.launchpad.net/snapd/+bug/1686106
<mup> Bug #1686106: The core snap contains fully working dpkg <snapd:New for ogra> <https://launchpad.net/bugs/1686106>
<ogra_> zyga, thanks for catching that ... we obviously remove all dpkg-* binaries http://paste.ubuntu.com/24454366/ ... not sure why dpkg is left
<zyga> ogra_: you don't remove plain dpkg
<ogra_> https://github.com/snapcore/core/blob/master/live-build/hooks/600-no-debian.binary
<ogra_> right
<ogra_> just anything else related to it
<ogra_> silly oversight
<ogra_> i actually think there was a reason for that in 15.04 thats not relevant in 16
<ogra_> zyga, trust me !!!!
<ogra_> :)
<youmin> morphis: have you had the chance to see the pastebin?
<morphis> youmin: not yet, will do in a few min
<youmin> morphis: oK
<zyga> ogra_: merged
 * ogra_ hugs zyga 
<mup> PR core-build#6 closed: add the initramfs-tools-ubuntu-core package source <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/core-build/pull/6>
<niemeyer> morphis: Once you have a PR for those notes in the merged PR, please let me know the # and I'll include it in the review sprint board
<morphis> niemeyer: will do
<Chipaca> jdstrandâ give me a shout when you have a moment please?
<Facu> Hi all, I'm getting a test failure in snapcraft's master, snapcraft.tests.sources.test_subversion.SubversionDetailsTestCase.test_svn_details_commit, fails with testtools.matchers._impl.MismatchError: '1' != None
<Facu> does it happen to anybody else? thanks!
<morphis> youmin: you created  /etc/network/interfaces.d/eth0 ?
<youmin> no
<morphis> can you paste its content?
<morphis> youmin: also, is this a device upgrade from 15.04?
<youmin> yes, it is
<zyga> ha, curious
<zyga> how does one upgrade from 15.04?
<morphis> zyga: with a special upgrade tool we wrote
<morphis> zyga: its more or less a migration than a direct upgrade
<morphis> and needs to be run manually
<youmin> I used a pendrive that Dell gave me
<morphis> youmin: if you move the eth0 file somewhere else the problem should be solved
<youmin> just rename'
<youmin> Â¿
<youmin> ?
<morphis> youmin: you need to move it out of /etc/network/interfaces.d or remove it if you are sure you don't need it anymore
<jdstrand> Chipaca: I have an errand atm. when I get back I intend to look at your feedback from yesterday
<Chipaca> jdstrandâ ok, i'll be here
<youmin> morphis: sorry I created this file just for testing, it doesn't work. It is ignored by the system.
<youmin> morphis: let check something
<morphis> youmin: you need to remove it
<morphis> that is why your configuration isn't correctly applied
<youmin> morphis: now I've got the point, you're right this is the file that is processed just now
<morphis> youmin: what happens when you remove it?
<youmin> morphis: now networkmanager start working
<morphis> youmin: so even after a reboot you have the configuraiton now applied via nmcli?
<niemeyer> Lunch, biab
<youmin> morphis: I though network manager has been loaded but it seams is failing.... and now admin/admin is not working for login and the only IP that I have is localhost
<youmin> morphis: I'm trying to log in but there is no way
<mup> PR snapd#3237 opened: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
<pedronis> niemeyer: ^ IÂ opened this one as well about "snap aliases"
<morphis> youmin: can you give me a few more details, like which commands did you use to configure the network connection via nmcli etc.
<morphis> youmin: now that /etc/netplan and /etc/network/interfaces.d network configuration is gone you need to manually configure things via nmcli
<morphis> youmin: btw. the best to track this would be to file a bug as described in https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/report-bug
<mup> PR core-build#8 opened: add shellcheck test, fix code for shellcheck <Created by ogra1> <https://github.com/snapcore/core-build/pull/8>
<niemeyer> pedronis: Thanks, added to the board
<morphis> zyga: https://github.com/snapcore/snapd/pull/3156 .. all green, finally :-)
<mup> PR snapd#3156: many: support debian in our CI <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<zyga> morphis: wow, that's pretty neat!
<mup> PR snapd#3236 closed: tests: ensure travis fails early if static checks fail <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3236>
<zyga> morphis: does [ ] support globbin?
<zyga> morphis: you do tests like [ "$SPREAD_SYSTEM" != "debian-*" ]
<Chipaca> zygaâ no
<niemeyer> fgimenez: Can you join a call just now?
<zyga> Chipaca: right, I think you need [[ for that
<Chipaca> yep
<fgimenez> niemeyer: sure
<ogra_> or something like ... [ "$(echo "$SPREAD_SYSTEM" | grep -q debian-)" ]
<Chipaca> ogra_â or case/esac
<ogra_> which would be the fastest and cleanest
<zyga> mvo: hey, are you in a meeting now?
<mvo> zyga*: yes
<zyga> mvo: let me know if you plan to relesae 2.25 today or is that slipping to tomorrow/
<zyga> (when you can)
<mup> PR snapd#3238 opened: cmd/snap-confine: re-enable re-assciate fix for CE <Created by zyga> <https://github.com/snapcore/snapd/pull/3238>
<mvo> zyga: looks like !today at this point :/
<mup> PR snapcraft#1279 opened: misc: rename the snap dir variable to prime dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1279>
<niemeyer> Current stats on review sprint: 44 total â ( 14 waiting â 16 reviewing â 4 reviewed â 9 merged ) â 10 closed
<niemeyer> Incorporated that to the bottom of the board
<niemeyer> 34 to go...
<niemeyer> https://forum.snapcraft.io/t/review-sprint-1/377
<jdstrand> Chipaca: I'm here but haven't had a chance to really work through your comment. do you want me to do that first or discuss now?
<Chipaca> jdstrandâ whichever you'd rather. One big question I have is whether something completing '; sudo yadda' is a problem
<jdstrand> Chipaca: well, basically what I'm thinking is that I don't want bash completion to be any worse than simply running a cli command
<jdstrand> Chipaca: and I've not tried to attack bash completion in the past, so just thinking through everything
<Chipaca> mhmm
<jdstrand> Chipaca: the user's input going into snap run --complete and then running under confinement for the bash completion is no different than just running a snap command (and whatever shell tricks that might give you. ie, no worse)
<jdstrand> Chipaca: (and again, I really like you design)
<Chipaca> jdstrandâ your review made me think about what i _wasn't_ checking, and i added checks for those things
<jdstrand> Chipaca: it is the handoff from confined to unconfined that I am thinking about, and I'm not super familiar with the whole completion mechanism to know the attack surface there (yet)
<Chipaca> jdstrandâ yeap
<Chipaca> jdstrandâ is there anything i can do to help?
<jdstrand> Chipaca: I think there are two things to think about: 1) attacking completion after go from confined to unconfined but before the user does anything and 2) tricking the user
<jdstrand> if there are successful attacks against '1', we could *probably* chalk that up to vulnerabilities in bash that should be fixed. however, if there are hardening measures to put some guardrails there, that would be nice
<Chipaca> on the tricking the user front I haven't found a way to abuse, say, terminal escape chars to do evil stuff; bash escapes those before offering suggestions to the user
<Chipaca> for escaping, i think the sanitization i did last night fixes one way that might have existed of doing that (if a malicious completion script set arbitrary things that got passed to compopt)
<jdstrand> Chipaca: yeah, echo doesn't allow that by default. I'd like to play with printf a bit more
<jdstrand> cool, I haven't seen the updates for sanitization there
<Chipaca> https://github.com/snapcore/snapd/pull/3150/commits/b02ba90d15d61ad5817eda8e241975669b3fff43
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<jdstrand> Chipaca: the nice thing about printf %q is it definitely makes it shell safe. I do wonder how that might trip up things in practice. I suspect a lot of things would be ok with it, but I'm not sure about everything
<Chipaca> jdstrandâ for COMPREPLY (ie for the last print), it adds a layer of quoting
<Chipaca> that will break things; a lot of code in bash completion is about getting the right layer of quoting in place :-/
<jdstrand> ah, I like https://github.com/snapcore/snapd/pull/3150/commits/b02ba90d15d61ad5817eda8e241975669b3fff43#diff-65f7e8d7984bf6791a40090a663253abR17
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<jdstrand> Chipaca: note, you say non-alphanumeric but it is really just lowercase alpha
<Chipaca> e.g. if you have a file with a space, a line there would be foo\\ bar, so you get offered something that works when completed
<Chipaca> jdstrandâ yeah; i was about to just list all the known options even but thought it overkill
<jdstrand> Chipaca: re right layer of quoting. are you saying that bash(-completion) itself is making sure that happens?
<niemeyer> mvo: snapd#2833 reviewed and approved aside from trivials.. one more review from pedronis and it should be ready to move on
<mup> PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
<pedronis> finishing something and then IÂ will look at it
<Chipaca> jdstrandâ i'm saying if you want to offer the user "foo\\ bar" (so that if they choose that they get something with a space in it and not two somethings separated by a space), and we pass that through %q, they'll be offered foo\\\\ bar which is two somethings one of which ends in a backslash
<Chipaca> jdstrandâ that kind of problem
<jdstrand> Chipaca: (I also acknowledge the issues with escaping ' '. it's also hard getting the blacklist correct. I was thinking a whitelist of something like '^[a-zA-Z0-9\._ -]$' and escaping everything else, but again, not thought all this through)
<jdstrand> Chipaca: yep, I get that
<jdstrand> Chipaca: eg, a kinder, gentler %q
<jdstrand> Chipaca: mind you, I'm not saying to do that, I'm saying that is something I was thinking about. do you think that is feasible?
<Chipaca> jdstrandâ I'm sceptical it can be made to work in a practical way and still be useful
<Chipaca> jdstrandâ i'm still hopeful you'll find it unnecessary, but if it's got to be done Â¯\_(ã)_/Â¯
<jdstrand> Chipaca: the other thing I was thinking about is that assuming we can trust the handoff, maybe just at the end we do some escaping. again, not looked at this
<mvo> niemeyer: thanks a lot!
<Chipaca> jdstrandâ if i can help by writing tests (or trying stuff), give me a shout
<jdstrand> Chipaca: yet another thing I was thinking of is that we can, in theory, so that we support x, y, and z completions, but not a, b and c. meaning, yes, ' ' can be in there, but no, ';' cannot
<jdstrand> Chipaca: that is a variation on the kinder, gentler %q. you said you thought that would break things to the point of it not being useful. is there something you can think of otoh?
<jdstrand> s/so that/say that/
<niemeyer> mvo: np, glad to see this one getting in :)
<Chipaca> jdstrandâ if we definitely want to filter, ';' would probably do relatively little damage (i have very few files that have that in them, and don't think i've ever seen a commandline tool that takes explicit ;s outside of 'find' or programming languages)
<Chipaca> jdstrandâ i mean: passing the completion through grep and doing no completion if it matches some regexp seems like it'd do less damage than quoting
<Chipaca> alternatively filtering individual completions could be done in the same way
<jdstrand> Chipaca: yeah, I have a feeling we'd want to be pretty agressive on that. I think we are at the point where I need to study the handoff
<Chipaca> jdstrandâ ok
<morphis> zyga: fixed the PR
<zyga> morphis: thanks!
<jdstrand> Chipaca: I wonder if it would be useful to land the feature with a fairly aggressive grep. this would demonstrate the feature and we could always loosen it
<Chipaca> jdstrandâ I think it might
<Chipaca> jdstrandâ we have people waiting for the feature so if we're going to do that, i should check whatever we land is workable for them :-)
<jdstrand> heh, indeed :)
<lazyPower> Do we have a why snaps vs $alternative page somewhere?
<zyga> lazyPower: alternative?
<lazyPower> zyga: eg: flatpack
<zyga> lazyPower: ah
<zyga> lazyPower: I misread your question
<zyga> lazyPower: I don't think we do
<zyga> niemeyer: quick question, so you say it's okay to use camel case for system-level C constants like UMOUNT_NOFOLLOW?
<niemeyer> zyga: Let's be a bit more specific..
<niemeyer> zyga: I meant that
<niemeyer>   const Foo // This is FOO
<zyga> lazyPower: er
<niemeyer> method(Foo)
<zyga> er
 * zyga meant under_score
<niemeyer> Is better as const FOO; method(FOO)
<zyga> ok
<nacc> can classic snaps only be in beta and edge channels?
<zyga> nacc: they can be in stable as well but need store review
<nacc> zyga: ah ok -- do i need to request that manually? i don't see a way to do that from the web UI?
<zyga> nacc: I don't know TBH :/
<nacc> zyga: ok :)
<nacc> i can recommend --edge for now, for this snap, it's fine
<mup> PR snapd#3239 opened: many: show aliases changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
<niemeyer> nacc: I think you can just try to push it and the store should provide some feedback.. if it doesn't seem straighforward, please let us know as that's something we'd like to fix
<nacc> niemeyer: ok, it's an already published snap so i would have though there'd be a way to do it from the web interface (it let me add beta but didn't list the other channels)
<niemeyer> nacc: We've been handling store requested in the forum under the store category, but still.. this particular need is something that should be more integrated into the release workflow
<nacc> niemeyer: i'll try the push now though
<niemeyer> nacc: Right.. please try to just put it in the stable channel and let us know how it goes
<niemeyer> nacc: It should really be that obvious.. if it's not we have work to do
<nacc> heh, well i need to change my yaml grade first :)
<niemeyer> nacc: Indeed
<nacc> niemeyer: will wait for that to autobuild and try again, thanks!
<niemeyer> nacc: np, let us kno
<niemeyer> w
<niemeyer> pedronis: snapd#3192 reviewed again, and LGTM assuming you like the suggestion
<mup> PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
<niemeyer> We need a second review on this one pleeeeease ^
<pedronis> niemeyer: ah, I had that idea, if you prefer it I can go for it
<niemeyer> pedronis: +1!
<niemeyer> pedronis: A, B, A+B, sounds great
<pedronis> finishing rereviewing the refresh one and then will go back to that
<pedronis> mvo: commented on the refresh one, what I'm wondering is the Sleep left in the tests given that we don't have a timer anymore
 * Chipaca takes a break
<mup> PR snapd#3218 closed: interfaces: allow writing to /run/systemd/journal/stdout by default <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3218>
<nacc> niemeyer: confirmed, after opening the channel via `snapcraft` it did work
<nacc> niemeyer: and now the web ui shows it for the i386 build (i did it for the amd64 build)
<nacc> niemeyer: it does seem like, though, that there is no web ui way to 'open' a channel
<niemeyer> nacc: Opening a channel is just a matter of publishing a snap into it
<nacc> niemeyer: right, but the snap is already published in the web ui
<nacc> niemeyer: and there's no option to publish it to further hcannels
<nacc> but `snapcraft` can
<nacc> seems odd to an end  user, imo
<cachio> niemeyer, hey, I am trying to automate the console conf tests by using spread
<cachio> niemeyer, the tests console conf is started and is it suddenly closed if I run a expect from spread
<pedronis> niemeyer: done
<Chipaca> naccâ if you go into a revision, the "release" link lets you add it to different channels
<cachio> niemeyer, but If I run the same with -shell and invoque the expect manually with expect -f the test work
<cachio> niemeyer, If replicate the test execution from the test machine and execute the same command the spread executed it also works
<cachio> niemeyer, any idea?
<niemeyer> cachio: The allocation of the terminal is a bit different when running a shell or not.. we do have expect tests in our suite, though, so somehow it does work
<niemeyer> Let me get an example
<cachio> niemeyer, yes I saw the code
<niemeyer> cachio: https://github.com/snapcore/snapd/blob/master/tests/main/create-key/task.yaml
<niemeyer> cachio: These tests are passing all the time
<niemeyer> So it necessarily must work somehow
<cachio> niemeyer, what I see expect is not the problem, because if I run the same but form the test machine it works
<cachio> and it is using expect
<cachio> niemeyer, I think there is something aroud ssh or the terminal that could be affecting, but not sure
<niemeyer> cachio: That's why I'm pointing out that expect itself works, somehow, in that environment
<cachio> I changed spread to print the command that executed to run a test and if I run the same commadn with all the exports it works
<niemeyer> cachio: I suggest starting from the task I mentioned above, and transforming it into your task until it breaks
<niemeyer> cachio: Then you'll know what's the delta that makes it not work
<cachio> niemeyer, ok, I'll try that
<niemeyer> jdstrand: Question on snapd#3219
<mup> PR snapd#3219: interfaces/i2c: allow modifying device-specific sysfs entries <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3219>
<niemeyer> jdstrand: Sorry, nevermind.. I'm blind
<mup> PR snapd#3219 closed: interfaces/i2c: allow modifying device-specific sysfs entries <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3219>
<jdstrand> Chipaca: ok, I have data/completion/* copied over to a vm. where do those files go?
<jdstrand> Chipaca: (I of course also have the rebuilt snapd, snap, snap-exec)
<jdstrand> looks like etelpmoc.sh goes in /usr/lib/snapd...
<mup> PR snapcraft#1262 closed: replace : with _ in file names <Created by andyli> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1262>
<jdstrand> snap probably goes in /etc/bash_completion.d
<mup> PR snapcraft#1275 closed: init: add a newline at the end of the file <Created by roxyd> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1275>
<jdstrand> ah, complete.sh also lives in /usr/lib/snapd
<Chipaca> jdstrandâ yeah in /usr/lib
<Chipaca> jdstrandâ but complete.sh can be wherever
 * jdstrand puts snap in /usr/share/bash-completion/completions/
<Chipaca> jdstrandâ that's completion for the snap command, not related to this :-)
<jdstrand> ah, ok
<jdstrand> Chipaca: so, my snap would source complete.sh, so it just needs to be somewhere predictable?
 * jdstrand is trying to understand the 'can be wherever' comment
<Chipaca> jdstrandâ your snap wouldn't source complete.sh
<jdstrand> right, duh
<Chipaca> (unless you're sourcing complete.sh for reasons)
<Chipaca> complete.sh is the "outside" one
<Chipaca> ie the user would source it after sourcing bash_completion
<jdstrand> Chipaca: ok, that is was the comment is about. at the moment, that is happening and there needs to be some way for that to happen, but for me, I can source it and just have etelpmoc.sh in /usr/lib/snapd
<Chipaca> jdstrandâ your snap needs to have a completer entry in its snap.yaml
<jdstrand> err
<jdstrand> that *isn't* happening
 * jdstrand nods
<jdstrand> btw, etelpmoc.sh is incredibly hard to type :P
<Chipaca> jdstrandâ yep, and you need the new snap-exec "inside" for it all to work
<Chipaca> :-D
<Chipaca> it doesn't get easier
<jdstrand> hehe
<jdstrand> Chipaca: so, hmm, how are you putting snap-exec insode, a bind mount/overlay mount?
<Chipaca> yeah, i just copy everything into a snapd directory and bind-mount it
<jdstrand> normally I only deal with snapd and just use SNAP_REXEC=0, but this is different
<jdstrand> ok
<mup> PR snapcraft#1268 closed: Added link to forums in the Get in touch section <Created by Ads20000> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1268>
<mup> PR snapcraft#1274 closed: Simple explanation of what the test groups mean <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1274>
<zyga> jdstrand: question: I want to create an interface that provides data from snaps to unconfined world
<zyga> jdstrand: technically snapd would need to expand $SNAP to the externally visible location of the mounted snap
<jdstrand> zyga: can you be more specific. what kind of data? for what unconfined process to use?
<zyga> jdstrand: so the question is this, it kind of feels like content but it's not really, snapd would need to manage a namespace of files (say snap.$SNAP_NAME.$stuff) in a fixed directory for that interface
<zyga> jdstrand: specifically wallpapers for gnome
<zyga> jdstrand: gnome needs an XML file that describes each wallpaper
<zyga> jdstrand: I'd like to have a snap that can ship wallpapers and then get the XML file where the background selector expects it
<zyga> jdstrand: I was thinking about possible attacks but let's set that aside for a moment and just think about mechanics
<zyga> (we can say that each image is converted via a confined helper to a bmp so that it is not an attack vector)
<zyga> jdstrand: should this be a new backend
<zyga> jdstrand: that instances of that backend can manage things like this
<zyga> jdstrand: (e.g. files that are visible from classic world)
<jdstrand> fyi, it isn't thrilling to think about xml and image files coming from a snap to be fed to unconfined processes. the wallpapers code is likely not coded defensively against malicous input
<jdstrand> images you can't really get away from, but xml parsing, this could be done in other ways
<zyga> jdstrand: right, we can generate the xml in confined trusted helper, we can post-process each image as I described
<zyga> jdstrand: I want to focus on just the part where you want to let snapd manage part (likely via glob like snap.*) of the classic filesystem
<zyga> jdstrand: is that a new backend?
<zyga> jdstrand: and if so is it generic or super specific to this instance of the problem
<jdstrand> zyga: otoh I'd skip bind mounts. we have too many of them. just symlink from /usr/share/wherever/gnome/knows/about/wallpapers/snap.$SNAP_NAME.1.png to /snap/wallpapers/current/1.png
<zyga> jdstrand: we need an xml file in /usr/share/gnome-background-properties/*.xml
<zyga> jdstrand: then those files name (and describe) wallpapers
<jdstrand> that's fine too
<jdstrand> usr/share/gnome-background-properties/snap.$SNAP_NAME.1.xml or whatever
<zyga> jdstrand: there's some meta-data like what is the background color, which type of scaling to use, etc etc
<zyga> jdstrand: ok
<zyga> jdstrand: snapd can even write that file though it'd be somewhat repetetive but doable (ther'es a lot of little useless things there like i18n)
<niemeyer> pedronis: snapd#3239 reviewed too
<mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
<jdstrand> point is, use the snap.$SNAP_NAME.* mechanism and hook into existing dirs with symlinks. this should work for all kinds of things and at least parts are generalizable
<niemeyer> This also needs a second review ^^^
<zyga> jdstrand: symlinks targetting what? I think we need to get an actual file as $SNAP is not known at build time
<jdstrand> generating xml is not, but, we could generate xml into /var/lib/snapd somewhere and symlink into there (or generate in place if that makes more sense)
<zyga> jdstrand: right, that's doable
<zyga> jdstrand: so snapd would manage generated files in /var/lib/snapd and symlinks in a designated directory
<jdstrand> zyga: I was assuming that gnome just read the xml that told it where the images are. is that not correct?
<zyga> jdstrand: yes that's correct
<jdstrand> ok, yes
<jdstrand> then what you said last
<zyga> jdstrand: thanks, I may have some code for that in a few evenings :)
<zyga> jdstrand: just something I wanted to tackle personally
<zyga> jdstrand: perhaps this could be reused to allow man pages or other similar content
<jdstrand> the generalizable part is symlinking data from known dirs to places in /snap. the wallpaper-specific part is the xml
<zyga> (through again always the issue will be having software munge on untrusted data)
<jdstrand> zyga: man pages I think we could do if we ran the man page through a linter. if it passes, symlink. if not, don't
<jdstrand> that can happen at install/refresh
<zyga> jdstrand: hmm, here it'd not be a symlink to /snap/* anything; I assumed snapd would generate the xml files in /var/lib/snapd/(made up, say dataproviders)/gnome-wallpapers/snap.hello-kitty-1.xml and put a symlink to that file in /usr/share/gnome-background-properties/snap.hello-kitty.xml
<jdstrand> of course, that linter should run confined, but that isn't insurmountable
<zyga> jdstrand: yeah, I think a linter or perhaps a transformation tool could be a generic step
<jdstrand> zyga: yeah, that's fine too. I wasn't sure if gnome wanted the data in some convenient location
<zyga> jdstrand: though interesting what ships the linter, perhaps a snap that has the slot?
<zyga> jdstrand: just the xml files, the images can be anywhere
<jdstrand> zyga: perhaps /usr/share/wallpapers so other DEs could use it without xml or something
<pedronis> niemeyer: thanks
<zyga> jdstrand: perhaps, I was trying to get it to work in gnome first but yeah; depending on how the interface is coded it could be a generic wallpaper provider
<pedronis> niemeyer: "snap prefer" and "snap aliases" are the two left
<jdstrand> zyga: if we are shipping man page, core snap should arguably have the man command. it would be easy to create a profile for man to have it run checks. effectively aa-exec -p man-lint -- man /snap/foo/current/path/to/man/page
<jdstrand> are allowing shipping man pages
<zyga> jdstrand: yes, for man I agree
<jdstrand> it could be a separate snap such that if man command is present, just use it (putting the man page in the right place)
<zyga> jdstrand: ha, the "man" snap
<zyga> quite literally
<jdstrand> yeah
<zyga> it's also interesting for classic vs core
<zyga> on core the snap makes sense
<zyga> on classic the man slot would be on the core snap itself
<jdstrand> well, possibly
<jdstrand> I'd like to see the man command on there, but it isn't up to me
<zyga> jdstrand: thanks for the discussion
<jdstrand> np
<jdstrand> this may actually help the plasma guy actually. there is a discussion there where he is running arbitrary script through a dbus api in order to set the wallpaper
<zyga> jdstrand: aha, interesting, where is that discussion?
<jdstrand> I wonder if whatever plasma needs (ie, its equivalent of gnome's xml), perhaps he doesn't need to do all that
<jdstrand> snapcraft@ mailing list
<zyga> jdstrand: yes, looking at more than one consumer of wallpapers would help
<zyga> jdstrand: though this feels like wallpaper-control interface
<jdstrand> it does
<mup> PR snapcraft#1280 opened: Added support for 'branches' in Store responses (release, close, and status) <Created by facundobatista> <https://github.com/snapcore/snapcraft/pull/1280>
<jdstrand> and that's ok. perhaps it uses the ExposeData (ie symlinks) backend or maybe not (depends if the data needs to be symlinked or just the meta data files)
<facubatista> roadmr, â
<roadmr> facubatista: whee!
<facubatista> :)
<zyga> jdstrand: I see what you did there ;-)
<zyga> jdstrand: naming backends already, thanks!
<jdstrand> hehe
<zyga> jdstrand: would you put the symlink + generate data functionality into that backend?
<zyga> jdstrand: I'd actually allow the specification to carry that
<jdstrand> maybe?
<zyga> jdstrand: as after all, it's all in snapd
<zyga> jdstrand: (then two interfaces can do different stuff without being any less trusted)
<jdstrand> it seems clear that the backend would be useful for even just the xml, cause the backend could do the symlinking
<zyga> jdstrand: yes, I bet it could be pretty generic
<jdstrand> perhaps the backend has a generator api that could be xml for gnome, linter for man, nothing for /usr/share/wallpapers
<zyga> jdstrand: yes, I think the symlinking is a generic feature but where the data comes from (generator) is a function the interface can attach to the specification
<jdstrand> yeah
<zyga> jdstrand: symlink or copy or something similar, details to be defined
<jdstrand> yes
<zyga> jdstrand: I also smell...
<zyga> jdstrand: ssl :D
<zyga> jdstrand: we could ship ssl certs with a plug
<zyga> jdstrand: (and control via assertions)
<zyga> jdstrand: and update out of bound or let private entities install their own certs
<zyga> jdstrand: we may even look at desktop files a little this way (though that's a stretch)
<zyga> jdstrand: (well just as an interface, much of the strucutre would fit right in)
<zyga> jdstrand: maybe themes
 * jdstrand nods
<zyga> jdstrand: I'd love if one could ship a theme this way and have it available in classic world and in snaps the same way (.so files aside)
<zyga> anyway, I think I need to try something small firsT :)
<pedronis> Chipaca: mvo: a 2nd review of snapd#3192 would be appreciated
<mup> PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
<jdstrand> desktop is slightly messy cause they are so particular about the file name and the contents of the file, but sure
<jdstrand> and yes, would be nice for themes. .so files are a bit scary though
<niemeyer> pedronis: Just did snap prefer
<niemeyer> pedronis: Looks sane, although it's getting a bit hard to make sure I'm not skipping anything
<niemeyer> I'll take a break now
<pedronis> niemeyer: yea, they are quite big :/
<pedronis> thx
<zyga> niemeyer: enjoy! thanks for the reviews!
<jdstrand> oh huh, 'assumes'. I hadn't seen that
<mup> PR snapcraft#1281 opened: core: switch to version git <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1281>
<ryebot> is there a timeout on `snap login`, or does the login token last indefinitely?
<roadmr> ryebot: it should last unless you logout or change your password
<ryebot> roadmr: excellent, thanks :)
<roadmr> ryebot: (technically it expires periodically but snapd takes care of refreshing it for you, no need to re-enter credentials)
<ryebot> roadmr: ah, good to know, thanks :)
<niemeyer> zyga_: Thanks!
<niemeyer> jdstrand: Yeah, not very well known
<pedronis> niemeyer: IÂ tried to answer the comments on the "snap aliases" one with some further questions, I do prefer to keep Status honestly
<niemeyer> pedronis: Yo
<niemeyer> pedronis: Sorry, which Status was that?
<pedronis> niemeyer: Status in /aliases response
<niemeyer> pedronis: Ah, ack.. what's the background?
<pedronis> niemeyer: well we discussed a lot of options how to do things, having one set of aliases per snap is the simplest possible thing, not clear it will stay like that forever
<pedronis> niemeyer: having one status per aliases should keep working though, independently of the policy by which they are disabled/enabled in groups
<niemeyer> pedronis: Hmm
<niemeyer> pedronis: I think we can always bring it back if necessary, but the structure we evolved towards in the server seems to ring a nice bell
<niemeyer> pedronis: We basically have a snap, with aliases, and Auto/Manual targets
<pedronis> niemeyer: well, it means the client needs to do all the computation that aliasesv2.go does to interpret the status
<niemeyer> pedronis: Even if we introduce groups, it sounds like this would still fit
<niemeyer> pedronis: Yeah, but isn't that trivial?  I find it awkward that we're still modeling the client end after the old model when the server end seems to have improved a lot recently
<pedronis> niemeyer: sorry, personally I find it strange to have to teach the exact semantics to the client code again
<pedronis> it needs to know again that manual wins , apply a flag across aliases etc
<niemeyer> pedronis: I find the opposite end strange: we're sending data to the client as if aliases might have individual settings, when they really can't... people will end up building algorithms on it which don't really make sense if they think that's the case
<niemeyer> pedronis: If this sounds controversial, it would be fine to wait a bit I think
<pedronis> niemeyer: well we need something, atm "snap aliases is broken"
<niemeyer> Just disabling the API for the time being so we don't buy incompatibilities
<niemeyer> pedronis: Ok, let's come back into this tomorrow then.. it's a bit late here, and even later there!
<pedronis> niemeyer: I see it mostly as a display to user API atm,  if we want to send more details they would probably go in /snap no, like other bits of snapstate?
<niemeyer> pedronis: Hmm
<niemeyer> pedronis: Okay, indeed.. we can keep this API and include the additional fields in the snap when we want to.. that's the idea I had as well (to have them in the actual snap structure instead of under /aliases)
<niemeyer> pedronis: Can we replace "unaliased" by "disabled"?
<niemeyer> pedronis: In the Status
<pedronis> yes
<niemeyer> pedronis: Okay, deal
<pedronis> I think you proposed "unaliased" at some point, maybe because of snap install --unaliased ?
<niemeyer> pedronis: I do have crackful ideas sometimes..
<niemeyer> pedronis: It's a terrible term for what is simply "disabled"
<niemeyer> pedronis: and now that we have AutoAliasesDisabled, that stands out even more
<pedronis> niemeyer: do we care about being backward compatible at all?  I'm taking abotu App/app vs Command/command in the struct?
<pedronis> s/taking/thinking/
<niemeyer> pedronis: In this particular case we've opted to bite the bullet and break compatibility to have a major overhaul, and I seriously doubt there was enough time for anyone to build on this API yet, so these two things summed up make me think it's fine
<pedronis> ok
<pedronis> so I'll change the struct and not just the output
<pedronis> thanks
<pedronis> in the morning though, it's indeed late
<pedronis> niemeyer: I summarized what we discussed here in the PR
 * pedronis -> rest
<pedronis> ttfn!
<niemeyer> pedronis: Thanks a lot, and have a good night!
<azubieta> Hello, I heard that the Ubuntu store is closing, will this affect snappy technologies to ?
<kyrofa> azubieta, no no, just phones
<kyrofa> snappy/ubuntu core is still going strong
<azubieta> oh
<azubieta> good
<azubieta> :D
<azubieta> thanks!
#snappy 2017-04-26
<mup> PR snapd#3205 closed: tests: add openvswitch interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3205>
<mup> PR snapcraft#1282 opened: parts: remove the deprecated snap keyword from the internal parts representation <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1282>
<mup> PR snapd#3138 closed: interfaces/mount: add Change.Perform <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3138>
<pedronis> mvo_: morning, IÂ need 2nd reviews of snapd#3192 and snapd#3239
<mup> PR snapd#3192: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
<mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
<mvo_> pedronis: thank, I have a look
<pstolowski> morning
<zyga> good morning
<zyga> mvo_: sorry for being late, I will focus on code reviews the whole day
<mvo_> zyga: hey, good morning. and no worries
<zyga> mvo_: did you see this error? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/i386/s/snapd/20170425_122307_f3ac6@/log.gz
<zyga> + dpkg --purge --force-depends snapd
<zyga> dpkg: error processing package snapd (--purge):
<mvo_> zyga: I have not seen this error yet. pre-removal script returned 1 is really not helpful :(
<zyga> mvo_: are those logged in any dpkg specific log file?
<mvo_> zyga: unfortunately not, the best info we have is "Job for snapd.service canceled." right before that
<mup> PR snapd#3197 closed: store: retry on connection reset too <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3197>
<mup> PR snapd#3192 closed: many: implement snap unalias <alias-or-snap> (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3192>
<pedronis> mvo_: static checks are failing on the refresh scheduling branch, and thanks for bearing with me about naming stuff
<pedronis> mvo_: also thanks for the other review
<mup> PR snapd#3240 opened: snap: add `snap refresh --time` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/3240>
<mvo_> pedronis: thank, looking
<mvo_> thanks even
<ogra_> zyga, do you have access to https://travis-ci.org/profile/snapcore  i would like to get the core-build branch turned on
<ogra_> (or mvo_ ^^)
<zyga> ogra_: looking
<zyga> my github token is in poland so... fingers crossed
<zyga> I have
<zyga> ah, no
<ogra_> whee
<zyga> You require admin rights to enable these repositories
<ogra_> :(
<zyga> so that's gustavo or mvo perhaps
<mvo_> ogra_: I can not
<zyga> or JamieBennett
<zyga> it's pretty terrible that we don't even know who controls this apart from gustavo
<JamieBennett> zyga: I do not have admin rights there, I would defer to niemeyer
<ogra_> yes, spoiled by LP team management :)
<ogra_> ok, then i'll wait
<zyga> thanks for checking JamieBennett
<pedronis> Chipaca: hi, maybe you can give a 2nd review to snapd#3239 (it's smallish and has already a +1)
<mup> PR snapd#3239: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3239>
 * zyga is sorry about the lack of reviews
<zyga> I'll spend my whole day reading code, no writing today
<Chipaca> pedronisâ perhaps I could
<ogra_> hey, seeing suddenly each and ever project switch to meson ... do we have support for that in snapcraft yet
<ogra_> *every
<ogra_> seems to be the next famous thing
<Chipaca> http://mesonbuild.com/ ?
<ogra_> yep
<pedronis> Chipaca: thx
<pedronis> mvo_: once #3239 lands I'm down to two PRs, one should be ok but needs  re-review/reviews, the other needs a little bit of further work
<mvo_> pedronis: great, thank you
<ogra_> sigh,. what changed in the store ... the core builds constantly fail uploading with a proxy error
<mvo_> Chipaca: I like your suggestion about the --time help output. how about "Only show refresh time information" or "Only show refresh times information but not perform any refresh"?
<ogra_> cjwatson, did anything change over night ? i did hit the retry button 3 times for 5 snaps already, all fail
<ogra_> cjwatson, https://launchpad.net/~snappy-dev/+snap/core/+build/34833 or https://launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/34849
<zyga> mvo_: maybe `snap refresh --query`
 * zyga reads that branch now
<Chipaca> mvo_â ( show refresh schedule information | list packages that would be refreshed ) but do not perform a refresh ?
<Chipaca> zygaâ --query is weird, as you might expect its output to be that of --list
<zyga> Chipaca: hmm, I agree
<zyga> Chipaca: but --time is also weird in this context
<Chipaca> zygaâ remove all flags, add a single --dwim
<zyga> Chipaca: I don't like it when "command --option" does something that more feels like "command subcommand"
<zyga> Chipaca: --dwim?
<zyga> dowhatimean?
 * Chipaca nods
<zyga> no, wait, blue WHAAAM
<mvo_> Chipaca: works for me, thanks for the suggestion!
<Chipaca> mvo_â and i notice its prereq is gtg once green
<mvo_> Chipaca: indeed :)
<zyga> mvo_: added one question about 3240
<pedronis> notice that we already have snap refresh ---list
<pedronis> so that boat has sailed I think
<zyga> yes, it is somewhat unavoidable, and I suspect nobody is really bothered by this (just software being software)
<mvo_> zyga: uh, nice catch! thank yu
<zyga> mvo_: ah, I wasn't sure if this is some deliberate design!
<pstolowski> mvo_, added a test to #3235
<zyga> mvo_: I'll read the rest (I oftne start from the bottom for no other reason than that it feels less daunting) :-)
<cjwatson> ogra_: 502 means a problem within click-updown
<cjwatson> ogra_: so if something changed it was on the store side, not LP
<mvo_> pstolowski: \o/
<cjwatson> ogra_: raised on the OLS channel since our failure rate has definitely got a lot worse in the last day or two
<ogra_> cjwatson, yeah, it started around easter that i saw the first failures in a while, but it got massively worse during this week
<morphis> zyga: did you rebase my branch?
<morphis> zyga: the interesting thing is that I don't have tests/main/interfaces-openvswitch  in my tree
<zyga> morphis: no, I commented on what is in the PR
<zyga> morphis: I didn't even clone it locally
<zyga> morphis: merge master, fix the test and push
<zyga> morphis: maybe travis tests the merged branch as well as the branch itself
<morphis> zyga: done
<pedronis> "The job exceeded the maximum time limit for jobs, and has been terminated."Â is a bit frustrating :/
<zyga> yes, indeed
<zyga> especially since travis is there only to hand-hold spread and its army of VMs
<cjwatson> ogra_: There was a previous incident that was due to a large volume of logs being shovelled around within prodstack and swamping internal bandwidth, but that was fixed
<cjwatson> (we should possibly detect 502 and retry, but with the current failure rate I don't know that it'd make a whole lot of difference)
<Trevinho> jdstrand: can you try use snapcraft-preload from this branch https://github.com/3v1n0/snapcraft-preload/tree/string-appends-fixes ?
<Trevinho> it should fix the issues you were facing...
<Trevinho> jdstrand: applying http://pastebin.ubuntu.com/24459277/ should be enough
<jacekn> hello. How to "unpublish" snap from all channels?
<zyga> jacekn: "snapcraft close" I think
<jacekn> zyga: hmm ok, I may have to log in to do that (I was trying to avoid that)
<zyga> jacekn: I suspect you can do that from the web UI too
<zyga> jacekn: just not sure as I didn't try
<jacekn> zyga: does not look like it, when I untick all channels web UI says "This field is required"
<jacekn> zyga: ah alright so look like it's because the store must have something in edge and beta. I used snapcraft close and that just switched beta and edge to the same revision as candidate
<pstolowski> Chipaca, added 1 comment to your tab-completion
<Chipaca> woo
<pstolowski> chances are it's nonsense ;)
<Chipaca> oh the _other_ tab completion one
<Chipaca> :-)
<pstolowski> (my comment, not your PR)
<Chipaca> good question about empty :. Let me check.
<ogra_> cjwatson, well, the failure seems pretty reliable now ... in case anyone needs reproducers ... let me know ...
<pedronis> pstolowski: made a small comment in one of your interface hooks PRs
<zyga> mvo_: added one more comment to https://github.com/snapcore/snapd/pull/3240
<mup> PR snapd#3240: snap: add `snap refresh --time` option <Created by mvo5> <https://github.com/snapcore/snapd/pull/3240>
<Chipaca> pstolowskiâ basically parts[0] would be "", meaning we'll suggest any and all plugs :-(
<pstolowski> pedronis, yes, just saw them thanks!
<pstolowski> Chipaca, ha!
<Chipaca> pstolowskiâ i'll confirm this empirically in a moment
<pstolowski> Chipaca, should be easy to handle and make "" into "core" I guess, and let all the remaining logic do the job?
<mvo_> zyga: aha, another nice catch, thank you again
 * zyga is super slow with reviews, needs to switch into review mood
<Chipaca> pstolowskiâ ah, we don't offer everything, we offer nothing instead
<Chipaca> slightly better
<Chipaca> still, I'll force it to 'core' if empty
<pstolowski> Chipaca, :)
 * zyga breaks for some lunch and coffee
<zyga> brb
<niemeyer> Mornings
<mvo_> hey niemeyer, good morning!
<pstolowski> hey niemeyer
<mup> PR snapd#3241 opened: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3241>
<mup> PR snapd#2895 closed: client,cmd/snap: first pass at client messaging around modes <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2895>
<jacekn> anybody knows what the problem could be? http://pastebin.ubuntu.com/24459530/ if I revert to tag v1.5.2 it builds fine so must be someting on prometheus side but still snapcraft should allow me to build it?
<Chipaca> pstolowskiâ addressed
<pstolowski> ðð
<niemeyer> mvo_, pstolowski: Mornings!
<niemeyer> mvo_: Seeing the recent change in snapd#2833, isn't there a test missing there?
<mup> PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
<Chipaca> jaceknâ looks like a bug in prometheus indeed
<Chipaca> jaceknâ it's importing "context" from the wrong place
<Chipaca> jaceknâ that is an error from Go itself
<Chipaca> jaceknâ âpackage context: unrecognized import path "context" (import path does not begin with hostname)â i mean
<Chipaca> it is a strange one though
<mup> PR snapd#3239 closed: many: show alias changes on snap alias/unalias (aliases v2) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3239>
<jacekn> Chipaca: coudl the fact that snapcraft prepends improt-path with "./" ahve anythihng to do with it? 'go', 'get', '-t', '-d', './github.com/prometheus/prometheus/...']'
<Chipaca> jaceknâ it shouldn't, but it might
<Chipaca> jaceknâ give me a bit
<morphis> niemeyer: anything left to get https://github.com/snapcore/spread-images/pull/1 merged?
<mup> PR spread-images#1: Add debian-unstable-64 base image <Created by morphis> <https://github.com/snapcore/spread-images/pull/1>
<Chipaca> jaceknâ what happens if you run that by hand, adding a -v to it?
<jacekn> Chipaca: it will fail I'm pretty sure because of missing GO env variables but I can try setting it up
<pedronis> niemeyer: hi, snapd#3237 can be reviewed again
<mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
<Chipaca> pstolowskiâ hm, re-reading your comment, is it only ever :<slot>, never :<plug>?
<pstolowski> Chipaca, I think so yes, would need to check Resolve* methods again
<Chipaca> then i've got this wrong. amending.
<pstolowski> Chipaca, please double check in repo.go
<niemeyer> morphis: It's in
<morphis> niemeyer: thanks
<niemeyer> morphis: np
<niemeyer> pedronis: Looking
<morphis> niemeyer: another one for fedora is coming soon
<Chipaca> pstolowskiâ in connect, empty means core only for the slot; in disconnect, it's either
<mup> PR snapcraft#1281 closed: core: switch to version git <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1281>
<Chipaca> popeyâ about https://forum.snapcraft.io/t/broken-snap-breaking-snapd/401 zyga seemed to know what it was about (and there was a pr to address it)
<Chipaca> popeyâ i'll give him a shout to have him comment in there when he's around
<pstolowski> Chipaca, right
<popey> Chipaca: thanks
<niemeyer> pedronis: LGTM
<pedronis> niemeyer: thx
<ogra_> niemeyer, could you please enable travis for the core-build branch ?
<niemeyer> ogra_: Done
<ogra_> thanks :)
<niemeyer> Any time
<Chipaca> zygaâ hey
<Chipaca> zygaâ we're seeing more and more panics in the wild with the nil map
<Chipaca> zygaâ what is the status of that fix?
<zyga> Chipaca: let me see
<Chipaca> zygaâ and can you comment about it on https://forum.snapcraft.io/t/broken-snap-braking-snapd/401
<zyga> Chipaca: yes
<zyga> Chipaca: so the fix was merged by mvo long ago
<zyga> Chipaca: we should also review and merge https://github.com/snapcore/snapd/pull/3208 to stay proactive for future issues
<mup> PR snapd#3208: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <https://github.com/snapcore/snapd/pull/3208>
<zyga> Chipaca: done
<Chipaca> zygaâ what is the snap doing wrong such that it breaks snapd?
<zyga> Chipaca: just make a snap that has a "content" plug
<zyga> Chipaca: without anything else
<zyga> Chipaca: we go and sanitize that, notice the content type is empty so we go and say it is the same as the interface name
<mup> PR snapd#3242 opened: tests: tweak time for econnreset test a bit more <Created by mvo5> <https://github.com/snapcore/snapd/pull/3242>
<zyga> Chipaca: but then whaam, attr is a nil map
<zyga> Chipaca: I fixed that quite some time ago
<ahayzen> zyga, hey, you state to install the edge core snap to 'see the error go away', but i can't install the one from edge as the snapd service crashes as soon as it starts :-) is there anyway i can manually stop it trying to do the security profiles step ?
<zyga> ahayzen: aha, when you already have that snap installed
<zyga> ahayzen: I'm not sure actually
<zyga> ahayzen: (eventually, like in two weeks) the change will garbage collect and won't run anymore
<zyga> ahayzen: but I assume you meant for something better
<ahayzen> like it failed to install and there is a pending task that never completes todo the security profiles (which then crashes each time the service starts)
<ahayzen> zyga, right, yeah i was looking for a way to 'fix' my system :-) anyway i can force the garbage collect or something?
<zyga> Chipaca, mvo_: ^ any ideas?
 * zyga has none apart from moving the needle of time a little bit forward
<ahayzen> :-)
<zyga> mvo_: perhaps curious input to the repair assertion
<niemeyer> morphis: Do you have the fixes for the PR we discussed lined up?
<zyga> mvo_: I'd say that it would be good if we could send a repair assertion that repairs the state without sending 10MB binary
<niemeyer> morphis: Want to include in the board
<morphis> niemeyer: not yet
<niemeyer> morphis: Okay, can you put that up in the pipeline so we don't risk releasing without the fixes?
<pedronis> Chipaca: mvo_: snapd#3237 needs a 2nd review
<mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
<mup> PR snapd#3208 closed: interfaces: recover panics when sanitizing plugs and slots <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/3208>
<sil2100> Hello! We seem to be haunted today by sha mismatches today when getting the pc-kernel snap from the store - almos all our autopkgtests for ubuntu-image failed with this error:
<sil2100> error: sha3-384 mismatch for "pc-kernel": got 7873b5723739ece72e102f518ba4c3e4c8e656ea2f64f80759a4fcda0e0737ca1d13459ac97221a4a059fce357a2ca46 but expected 33d383ce8f59a0cc43905da29208d6152d8204dd7a90500d4dfd2f1586d440359796374f17778a88948561c002cc563a
<sil2100> Does anyone know if there are any outages/issues that could cause this?
<ogra_> sil2100, i wonder if thats related to the upload errors i see for the core snaps (proxy error)
<niemeyer> sil2100: Can you please open a topic in the forum under the store category?
<niemeyer> sil2100: Actually, I suspect we even already have a topic for that particular error
<Chipaca> pstolowskiâ pushed a thing to handle : in connect better
<Chipaca> sil2100â i'm willing to bet one of those hashes is the hash of '503 Service Unavailable'
<Chipaca> sil2100â or sth like that
<zyga> Chipaca: 504 Cure For Cancer Follows, but we only have the hash
 * ogra_ wonders if he needs to swing another magic wand to make https://travis-ci.org/snapcore/core-build/builds/225967248 start 
<ogra_> sits there since ages
<ogra_> hah !
<ogra_> complaining here helps it seems :)
<Son_Goku> ogra_, hitting it with a hammer helps too :)
 * Son_Goku hates Travis CI
<ogra_> well, once it runs it is fine
<mup> PR snapcraft#1283 opened: core: predetermine the magic path when a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1283>
<pstolowski> Chipaca, thanks
<pedronis> ogra_: we were pinged here
<ogra_> yeah
<pedronis> but there's a forum topic
<ogra_> yeah
<pedronis> so any suggestion will go there
<facubatista> question, does build.snapcraft.io build for several architectures?
<ogra_> armhf and amd64 i think
<facubatista> ogra_, thanks
<Chipaca> jdstrandâ thinking of changing the cat in complete.sh to \grep -v '[[:cntrl:];?*{}]'
<ogra_> poor cat
<zyga> Chipaca: does [[:cntrl:]] in any insane way depend on locale?
<zyga> (just checking)
<ogra_> nope
<Chipaca> zygaâ if it does, it's not insane :-)
 * zyga reads the aliases branch
<zyga> Chipaca: in nort korea space is a control character because they have little space
<Chipaca> zygaâ and way too much control
<jdstrand> Chipaca: that seems like a reasonable start (I've not started looking at the branch yet today)
<jdstrand> again yet...
<Chipaca> jdstrandâ I'm looking for something that's good enough to merge (so it can be in 2.25) even if we then make it better later
 * jdstrand nods
<jdstrand> I'll be getting back to this btw. just tending to review tools updates for the bad snap issue
<Chipaca> np
<niemeyer> morphis: not sure if you've seen that message: can you put that up in the pipeline so we don't risk releasing without the fixes?
<mup> PR snapd#2833 closed: many: allow core refresh.schedule setting <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2833>
<pedronis> mvo_: yay ^ !
<fgimenez> mvo_: while working on an extension of the system-observe interface test i've found that any snap, even if they don't declare any plug, can read /proc/meminfo, this can't be intended, right?
<mvo_> pedronis: \o/ indeed
<mvo_> fgimenez: hm, that is curious
 * mvo_ looks
<Chipaca> zyga, jdstrand, why am i getting âhsearch_r failedâ for things that used to work?
<fgimenez> mvo_: thanks, a simple snap like this is enough to check http://paste.ubuntu.com/24460232/, with that installed "system-observe-consumer cat /proc/meminfo" shows the contents (the name of the snap can be misleading, no interface involved)
<mvo_> fgimenez: I can confirm with hello-world.sh that I can read /proc/meminfo without special permissions. this is curious because "git grep meminfo" only shows an allow rule in the system-observer. maybe jdstrand knows more?
<pedronis> zyga: sounds like out of sync snap-confine vs sepcomp bits in snapd
<pedronis> sorry
<pedronis> Chipaca: ^
<pedronis> * in/from
<pedronis> Chipaca: we should have ways to avoid that but if you running things manually IÂ suppose it can happen
<mup> PR snapd#3171 closed: snapstate: normalize gadget defaults <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3171>
<mup> Bug #1619154 changed: Cannot adjust systemd service definition <Snapcraft:Opinion> <Snappy:Opinion> <https://launchpad.net/bugs/1619154>
<Chipaca> a'ight
<Chipaca> jdstrandâ I added https://github.com/snapcore/snapd/pull/3150/commits/6dcbcded52192f57dedb980872e6ad22a84a93e8 and all tests passed just the same
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<mvo_> morphis: do you need a hand with the xauthority PRs comments from gustavo? we need those for 2.25 (or revert the PR) so I'm keen to get things addressed  asap
<jdstrand> Chipaca: nice
<morphis> mvo_: no, working on them now
<morphis> mvo_: had to leave for a fire accident as I am a fire fighter; already started with them earlier today
<morphis> mvo_: sorry for the delay
<ogra_> another attempt of blowing up your city hall ?
<morphis> ogra_: not really .. we already had a bigger ship on fire on tuesday really early in the morning ..
<morphis> and today somebody decided to get light his shed :-)
<ogra_> oh my
 * niemeyer will feel safer with morphis around from now on
<morphis> :-)
 * ogra_ makes a note to not move to verden if not owning fireproof underwear
<mup> PR snapd#3243 opened: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
<morphis> ogra_: hehe, however I guess the rate of fire accidents is quite similar anywhere else too :-)
<ogra_> yeah
<morphis> we have about 20-30 alarms per year were only ~5 are real fires
<ogra_> the guy trying to blow up the city hall was unique though ... enough to make the news :)
<zyga> jdstrand: I made a small branch to fix a bug that was uncovered by CE
<zyga> jdstrand: added you as a reviewer
<morphis> ogra_: yeah ..
<ogra_> crazy germans ... :)
<morphis> ogra_: http://www.nonstopnews.de/galerie/25062 is what we had yesterday
<ogra_> oh man
<niemeyer> Lunch!
<pedronis> Chipaca: mvo_: I need a 2nd review of snapd#3237
<mup> PR snapd#3237: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <https://github.com/snapcore/snapd/pull/3237>
<Chipaca> on it
<pedronis> Chipaca: it's a small one
<mvo_> morphis: no worries, just wanted to make a friendly offer for help :)
<morphis> mvo_: thanks!
<mvo_> pedronis: I have a look as well
<Chipaca> pedronisâ what's the â! snap aliases | MATCH ... â thing?
<Chipaca> pedronisâ more exactly, what's the start-command-with-bang thing
<pedronis> Chipaca: it negates the whole pipeline, it succeed if the pipeline files
<pedronis> s/files/fails/
<Chipaca> TIL
<pedronis> it's an obscure bit
<pedronis> admittedly
<pedronis> Chipaca: man bash and search pipelines,  there's option [!] bit in there
<Chipaca> will do
<pedronis> Chipaca: thx
<mup> PR snapd#3237 closed: many: adjust /aliases and "snap aliases" to aliases v2, also some cleanup <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3237>
<mvo_> pedronis: 3220 has test failures that look unrelated (mirror on linode issues?). do you mind if I restart the test?
<pedronis> mvo_: I'm about to push a merged anyway
<mvo_> pedronis: even better
<pedronis> not that it will make it smaller, it's big mostly because of tests
<mvo_> pedronis: ok :)
<pedronis> I mean it's main prereq was already merged
<pedronis> mvo_: pushed now
<zyga> mvo_: can you consider https://github.com/snapcore/snapd/pull/3243 for 2.25 as a fix for CE, assuming that jdstrand gives it a +1
<mup> PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
<mvo_> zyga: we need input from jamie here, but yeah, I think thats ok. this really feels like we need the "snapd controls how snpa-confine behaves" changes we talked about
<zyga> mvo_: yes but this is just a bugfix, not related to any re-architecture
<zyga> mvo_: it was supposed to work like that but this was missed
<morphis> niemeyer, mvo_: https://github.com/snapcore/snapd/pull/3244
<mup> PR snapd#3244: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
<mup> PR snapd#3244 opened: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
<mup> PR snapcraft#1283 closed: core: predetermine the magic path when a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1283>
<mup> PR snapd#3245 opened: many: aliases v2 cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/3245>
<pedronis> mvo_: ^ this is the small cleanups branch IÂ mentioned at the standup, anyway current blocker is reviews for snapd#3220
<mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
<pedronis> mvo_: niemeyer: seems we are hitting archive or network fun in the tests now, IÂ got:
<pedronis> https://travis-ci.org/snapcore/snapd/builds/226053803
<mvo_> pedronis: :(   Unable to connect to mirrors.linode.com:http:
<mvo_> pedronis, niemeyer: it looks like we should open a support ticket on linode if their mirror times out?
<niemeyer> pedronis: Where did you see that message?
<niemeyer> mvo_: ^
<niemeyer> Looking at the error there I couldn't find it
<pedronis> niemeyer: last run for snapd#3220
<mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
<pedronis> niemeyer: some project prepare have "unable to locate pkg foo" and some have a bunch of those mirror errors
<niemeyer> pedronis: Yeah, sorry.. was looking at the Travis error and wondering about the message mvo_ pasted above
<niemeyer> Aha
<niemeyer> pedronis, mvo_: Mirror seems up now
<pedronis> I went through the list of PRs, IÂ think IÂ commented on the ones I could, some have feedback that nees acting on, some IÂ think need niemeyer input/opinion
<pedronis> I mean the PRs in the sprint post
<niemeyer> pedronis: Thanks!
<pedronis> niemeyer: snapd#3220 should be ready for reviewes btw,  also IÂ pushed the small cleanup PR IÂ mentioned in the standup
<mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
<niemeyer> pedronis: Thanks, will look into it next
<Chipaca> jdstrandâ how's it going?
 * pedronis going afk for a while, will check on things later
<morphis> Pharaoh_Atem: https://paste.ubuntu.com/24461436/ .. we're moving :-)
<Pharaoh_Atem> :D
<morphis> Pharaoh_Atem: still quite hacky but it works
<Pharaoh_Atem> it's a start!
<cjwatson> ogra_: LP->store uploads may be better now after IS stopped some swift migration jobs
<ogra_>  heh, ok, i'll try a re-upload
<ogra_> cjwatson, thanks!
<pedronis> linode:ubuntu-14.04-64:tests/main/econnreset is really quite flaky
<jdstrand> Chipaca: hey, going to get back to it just a sec
<jdstrand> mvo_: fyi, I approved https://github.com/snapcore/snapd/pull/3243
<mup> PR snapd#3243: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <https://github.com/snapcore/snapd/pull/3243>
<mup> PR snapcraft#1284 opened: extra verbose tests  <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1284>
<mup> PR snapcraft#1284 closed: extra verbose tests  <Created by cprov> <Closed by cprov> <https://github.com/snapcore/snapcraft/pull/1284>
<pedronis> niemeyer: I tried to address or answer the comments to snapd#3220
<mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
<niemeyer> pedronis: Cheers!
<pedronis> niemeyer: was the review sprint forum post synced recently ? I see some branches that were merged not marked as such
<mvo_> a second review for 3240 would be great
<niemeyer> pedronis: No, need to update.. currently running an errand but will update shortly
<niemeyer> pedronis: Updating, and also integrating a few of the new PRs that were pushed in the last two days
<niemeyer> pedronis: Updated
<niemeyer> pedronis: LGTM, thanks for the changes!
<jdstrand> Chipaca: ok, it took a while to get all the way through it to my satisfaction, but I've left my review feedback
<Chipaca> jdstrandâ thank you!
<Chipaca> niemeyerâ do you know if mvo is cutting the release tonight?
<jdstrand> Chipaca: it's going to look like a lot, but it is almost all requesting adding comments here and there. I tried to give comments you can copy/paste to help
<niemeyer> Chipaca: I don't think so.. aliases are still not in
<Odd_Bloke> I'm talking to someone who's trying to build images but they don't yet have an account ID because they haven't uploaded a snap; is there an easy way for them to generate one without messing around with actually building/registering a snap?
<Chipaca> niemeyerâ ah ok
<Chipaca> then i'm going to not address the review and instead sleep :-)
<niemeyer> Chipaca: Sounds like a good plan
<Chipaca> jdstrandâ appreciated. I'll get to them in my morn.
<jdstrand> Chipaca: goodnight! I feel like I can talk fairly intelligently about this now. hopefully it won't atrophy by morning :)
<Chipaca> jdstrandâ will you want to once-over it once I do so, or are you ok with it landing?
<jdstrand> Chipaca: I said 'request changes', so feel free to ping me when you do the changes and I'll go through it real quick
<Chipaca> ah ok
<niemeyer> Odd_Bloke: I suggest asking the question in the forum under the store category.. I know where we want to be, but I don't know what the status of account names is just now
<Chipaca> jdstrandâ and yes \foo in bash is a way to make sure you call the builtin (or external program) and not a function or alias
<jdstrand> Chipaca: a comment stating that would be cool :)
<jdstrand> Chipaca: do you sense a theme?
<Chipaca> jdstrandâ no
<Chipaca> no theme sensing
<jdstrand> hehe
 * jdstrand is big on commenting
 * Chipaca sucks at commenting almost as badly as he sucks at naming things
<jdstrand> Chipaca: you've won some sort of best/worst of with etelpmoc.sh
<Chipaca> \o/ <- winning!
<jdstrand> I mean it is brilliantly terrible
<jdstrand> it's perfect, yet horrible
<jdstrand> please take that as a compliment :)
<pedronis> niemeyer: thanks, should we rename refresh-aliases to refresh-auto-aliases?
<niemeyer> pedronis: I think refresh-aliases is fine
<niemeyer> pedronis: It may end up growing up some activity about manual aliases, even if it doesn't today
<pedronis> ok
<pedronis> ok, snapd#3220 needs a 2nd review and then we just have #3245 which after the former should be small and hopefully uncontroversial
<mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
 * pedronis -> rest
#snappy 2017-04-27
<sergiusens> jdstrand: I think he won it when we had the term husks in the snapd code base ;-)
<mup> PR snapcraft#1272 closed: tests: initial setup for the snapcraft snap tests with spread <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1272>
<mup> PR snapcraft#1279 closed: misc: rename the snap dir variable to prime dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1279>
<Trevinho> jdstrand: you can now go back to use normal snapcraft-preload as fix for you issue has been merged upstream
<mup> PR snapcraft#1238 closed: beta <Created by snappy-m-o> <Merged by elopio> <https://github.com/snapcore/snapcraft/pull/1238>
<pedronis> mvo: hi, I got a +1 from Gustavo for snapd#3220, maybe you can finish the review you were doing? some points IÂ addressed in snapd#3245
<mup> PR snapd#3220: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3220>
<mup> PR snapd#3245: many: aliases v2 cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/3245>
<mvo> pedronis: thanks, will do
<pedronis> mvo: any reason not to merge #3244, IÂ don't see anything controversial in there
<mvo> pedronis: I tihnk its fine to merge, gustavo asked for those changes so he might want to review but afaict its all addressed in this pr
<pedronis> mvo: no, now that IÂ look at those commetns, there's a couple of things missing
<beruic> Hi there. Has anyone experimented with making a build server for snaps?
<zyga> beruic: yes
<zyga> beruic: build.snapcraft.io
<zyga> beruic: :-)
<zyga> beruic: using snapcraft itself it is not that hard
<beruic> @zyga Awesome. I'm considering trying to distribute my companys Django project on Core using snaps.
<nothal> beruic: No such command!
<beruic> zyga Awesome. I'm considering trying to distribute my companys Django project on Core using snaps.
<beruic> Sorry for double posting
<beruic> Does anyone know of a Freenode client for Ubuntu? Preferably one that comes as a snap package ;)
<pedronis> mvo: there's just a couple minor things there now that IÂ looked more carefully
<zyga> beruic: I don't know of any, I'd love to see polari IRC from gnome but that may require some more work on gnome/gui side; irssi should be easy to snap
<pedronis> zyga: IÂ think there's a script to update the board, but gustavo needs to run it
<pedronis> it's semi-automated, not fully afaiu
<zyga> pedronis: aha, good to know
<pedronis> mvo: seems there's a few things for 2.25 that we didn't get to do (https://forum.snapcraft.io/t/next-snapd-2-25/197), right? IÂ suppose we didn't consider there was Easter
<beruic> I'm having trouble figuring out the following about build.snapcraft.io: 1. I'm pretty sure it only connects to GitHub (we use Bitbucket :( ) 2. Is it possible to publish snaps that are only internally available, or does build.snapcraft.io always publish for public access?
<zyga> beruic: I think it's meant for public snaps, you can build stuff yourself with snapcraft (from bitbucket) and as long as you don't push it to any channel you should be OK
<zyga> beruic: you can get more answers by asking on forum.snapcraft.io
<beruic> zyga: Thank you :)
<zyga> mvo: I see more sleep tweaks on https://github.com/snapcore/snapd/pull/3242
<mup> PR snapd#3242: tests: tweak time for econnreset test a bit more <Created by mvo5> <https://github.com/snapcore/snapd/pull/3242>
<zyga> mvo: is there a way to make that test reliable without that?
<pedronis> tests and sleep, almost always tears
<pedronis> mvo: IÂ made a suggestion on #3220 let me know what you think there?
<pedronis> mvo: what's the plan for 2.25?
<Chipaca> error: cannot get data for "complexion": [0xc82016e300 0xc82016e480 0xc82016e600]
<Chipaca> ^^^ WTF
<mvo> zyga: maybe, I think it will need a muchbigger snap
<zyga> Chipaca: hmm
<mvo> zyga: the problem is that there is a bit of a race, when the print happens it has not connected yet, I could make another debug print when its connected. we want to only retry on rst
<mvo> zyga: when rst happens in the middle not at the start
<zyga> Chipaca: that's the snap you added in your tests, right?
<Chipaca> zygaâ it's a snap, yes
<zyga> mvo: could we do something, anything, via a helper proxy that we control, to make the test easier to write
<Chipaca> zygaâ i did 'snap try complexion'
<Chipaca> it printed that
<zyga> Chipaca: what are those [] numbers?
<Chipaca> but that was apparently a success message? because the snap was installed after that
<Chipaca> zygaâ I have absolutely no idea
<Chipaca> zygaâ that was the output of 'snap try'
<mvo> pedronis: checking your suggestion now. the plan for 2.25 is to push it out once the aliases are ready. it looks like in the standup we can discuss what (if anything) else is a must for 2.25
<mvo> pedronis: definitly want to release today
<zyga> Chipaca: ./cmd/snap/cmd_snap_op.go
<Chipaca> $ sudo snap try complexion/
<Chipaca> error: cannot get data for "complexion": [0xc82016e300 0xc82016e480 0xc82016e600]
<pedronis> mvo: ok, aliases should be definitely in soon, mostly waiting on your feedback there ;) ?
<zyga> Chipaca: the list is %v of `snaps` which came out of cli.List()
<zyga> Chipaca: looks like wonky String method
<zyga> that doesn't take pointer receiver
<mvo> zyga: sending RST is tricky, the best way I found was via the iptables, however something like trickle might help to ensure the download is not too quickly over. or just a huge snpa, maybe I just go with that
<Chipaca> looks like snap.List returned three items despite being given a snap name
<zyga> Chipaca: yep
<Chipaca> wonky indeed D:
<Chipaca> why
<zyga> Chipaca: let's patch the string methodfirst
<Chipaca> all i wanted to do was manual testing of complexion
<mvo> pedronis: ha!  on it :)
<zyga> http://paste.ubuntu.com/24465628/
<zyga> Chipaca: try with this
<Chipaca> so this is something that's broken on master
<mup> PR snapd#3220 closed: many: implement snap prefer <snap>  (aliases v2) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3220>
<Chipaca> zygaâ it's a %v, I don't think String is called on it
<pedronis> Chipaca: mmh
<zyga> Chipaca: aha, that's also possible
<Chipaca> ah, look at that, it would be called
<zyga> ogra_: how can I watch your webinar?
<fgimenez_> hi mvo, this is the test i mentioned for the new local assertions capabilities of prepare-image https://github.com/mvo5/snappy/pull/16 it passes locally on your branch, let me know if i should change anything about it
<mup> PR mvo5/snappy#16: tests: add spread test for assertions in prepare-image's extra-snaps <Created by fgimenez> <https://github.com/mvo5/snappy/pull/16>
<morphis> mvo: updated https://github.com/snapcore/snapd/pull/3244 for pedronis comments
<mup> PR snapd#3244: many: fix review comments from PR #3177 <Created by morphis> <https://github.com/snapcore/snapd/pull/3244>
<mvo> fgimenez_: nice work, thats some  magic in there :) I have a look
<mvo> morphis: thanks, also special thanks to pedronis for double checking that one
<pedronis> mvo: snapd#3245 is ready for review, it contains some of the follow ups IÂ promised in previous reviews
<mup> PR snapd#3245: many: aliases v2 cleanups <Created by pedronis> <https://github.com/snapcore/snapd/pull/3245>
<pedronis> plus other cleanups
<pedronis> Chipaca: maybe you could give it a look as well? ^ (it's smallish, repetitive)
<morphis> Son_Goku: ping
<zyga> gah, I was debugging something that kept failing because I forgot to merge mater
<zyga> master
<mvo> fgimenez_: could you please merge master and push again in the prepare-image-assert-test branch? there is some unrelated diff and I updated my branch but it looks GH is not updating the diff until you push something too
<fgimenez_> mvo: sure on it
<mvo> ta
<mvo> morphis: static checks are failing in your x11 pr, should be a trivial fix .)
<morphis> mvo: ok
<morphis> mvo: fixed
<mvo> zyga: I will pull in 3243, jamie was asking for a test, maybe we can get one in a followup?
<zyga> mvo: yes, I'll do one in a follow-up
<zyga> mvo: I was looking at that already but it will need some extra mocking
<zyga> mvo: and this will make CE happy
<mvo> 3238 needs a second review
<mvo> Chipaca: maybe you -^ ? branch is very small
<mup> PR snapd#3243 closed: cmd/snap-confine: don't use apparmor if it is disabled on boot <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3243>
<pedronis> zyga: wasn't there a test we disabled about that?
<zyga> pedronis: yes but the test depends on an unreleased kernel, CE has a kernel that they can use this on already
<pedronis> ah, I see
<fgimenez_> mvo: fixed, now it shows only the test files https://github.com/mvo5/snappy/pull/16
<mup> PR mvo5/snappy#16: tests: add spread test for assertions in prepare-image's extra-snaps <Created by fgimenez> <https://github.com/mvo5/snappy/pull/16>
<Son_Goku> morphis: pong
<morphis> Son_Goku: you saw my patch recently for the rpm to enable unit tests for the vendorized build
<Son_Goku> yes
<Son_Goku> I wanted to ask you something
<morphis> shoot :-)
<Son_Goku> does the unit tests require internet access?
<mvo> fgimenez_: thanks, reading now
<Son_Goku> because if they do, then I'm not merging this
<morphis> Son_Goku: they shouldn't as far as I know
<zyga> Son_Goku: no, they don't
<zyga> Son_Goku: regular unit tests
<zyga> Son_Goku: spread requires internet access but that's not tested at package build time
<Son_Goku> okay, then
<Son_Goku> morphis, could you link me the patch again? I seem to have downloaded it on a computer that's not this one
<morphis> Son_Goku: sure
<ogra_> zyga, you got to ask thibautr__
<mup> PR snapcraft#1219 closed: kernel plugin: learn how to assemble the ubuntu config using kconfigflavour <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1219>
<Son_Goku> morphis, nvm, I found it
<morphis> Son_Goku: ok, was finishing something else but would have pasted it afterwards
<morphis> zyga: what do you think about https://github.com/morphis/snapd/commit/75888e9198aedda1a862b7db496733e308b38a49 ?
<zyga> morphis: that won't work
<zyga> morphis: /etc/ssl is a symlink
<zyga> no way to bind mount over one
<zyga> (sorry)
<morphis> sure but we have the target in /usr/share too
<morphis> zyga: you mean /etc/ssl is a symlink on suse?
<zyga> yes
<zyga> no cheap way out other than to stop sharing /etc
<morphis> ok that makes thing more complicate
<morphis> zyga: " What we will then see is a symlink from /etc/ssl./certs to /var/lib/ca-certificates/pem that is just broken (the symlink)."
<morphis> if I read that correct /etc/ssl/certs is the symlink
<morphis> not /etc/ssl
<zyga> morphis: aha, hmm
<zyga> morphis: maybe that will work then
<morphis> zyga: let me verify that
<zyga> morphis: I still don't like it but it looks like a smaller change
<zyga> morphis: please do
<morphis> zyga: it's a cheap fix for the meantime
<morphis> instead of taking quite some time to rework the rest
<Son_Goku> morphis, I don't have the patch you added to the spec, though
<morphis> Son_Goku: ah
<Son_Goku> morphis, which sort of makes this pointless :)
<Chipaca> mvoâ you're cutting the release, yes?
<pedronis> mvo: landed #3245
<mup> PR snapd#3245 closed: many: aliases v2 cleanups <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3245>
<morphis> Son_Goku: you mean 0001-many-fix-test-cases-to-work-with-different-DistroLib.patch ?
<Son_Goku> yes
<morphis> that one is merged into 2.25
<Son_Goku> I didn't even see that PR
<morphis> sorry, is up for merge
<morphis> Son_Goku: https://github.com/snapcore/snapd/pull/3222
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<thibautr__> zyga here you go for the webinar...
<thibautr__> https://www.brighttalk.com/webcast/6793/248379
<morphis> Son_Goku: 2.26 is more likely
<zyga> thibautr__: thanks!
<morphis> zyga: ok, /etc/ssl isn't a symlink on suse
<zyga> morphis: ha
<zyga> morphis: ok, let's do this, add this to suse build
<zyga> morphis: as a distro patch
<zyga> morphis: I'd love to see it work
<morphis> zyga: :-)
<Son_Goku> this patch makes no sense
<zyga> Son_Goku: why not?
<Son_Goku> not the suse one, the PR
<Son_Goku> I don't even know what you're changing in the suse one :)
<zyga> ah, sorry
<morphis> Son_Goku: ?
<Son_Goku> morphis: I left a comment in the PR, but I'm confused because it looks like you're testing the wrong thing now
<morphis> Son_Goku: no you don't
<Son_Goku> so why is everything changing from distrolibexec to corelibexec?
<morphis> Son_Goku: there are many reexec cases which were properly handleed
<morphis> but those are never used on fedora/suse
<morphis> so they were wrong for quite some time
<morphis> and rexec never would have worked
<Son_Goku> ah
<morphis> zyga: didn't you say you merged https://build.opensuse.org/request/show/490989 ?
<zyga> morphis: I thought I did
<Son_Goku> wtf is rcsnapd?
<morphis> Son_Goku: https://en.opensuse.org/openSUSE:Packaging_checks#suse-missing-rclink
<morphis> it's not really of any use anymore but rpmlint complains about it ..
<Son_Goku> that's a bug, actually
<zyga> morphis: aha, did that again
<morphis> Son_Goku: maybe
<Son_Goku> because they just decided to get rid of that stuff a couple of weeks ago
<morphis> Son_Goku: then we can drop this in the near future again
<Son_Goku> (yes, I'm involved in openSUSE, too :) )
<Son_Goku> the only distribution family I'm not all that involved in is Debian :)
<Son_Goku> I even have a somewhat tenuous link to Yocto
<morphis> Son_Goku: :-)
<Son_Goku> the reasons for not getting involved in Debian/Ubuntu are sadly long and terrible
<Son_Goku> I told mvo once, quite a while ago
<Son_Goku> oh, and ximion knows too :P
<Son_Goku> I guess if I get the time, I'll help Debian complete the transition to dracut
<Son_Goku> I already told ximion I'd help him on it, at least :)
<morphis> Son_Goku: any progress on the postrm script?
<Son_Goku> it needs reworking, but I think I'm nearly there :)
<morphis> great!
<mvo> Chipaca: release> yes, very soon. was thinking right after the standup so that we can discuss as a group if there is anything missing that must go in but I think we are good
<mup> PR snapd#3238 closed: cmd/snap-confine: re-enable re-assciate fix for CE <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3238>
<mup> PR snapcraft#1285 opened: kernel plugin: learn how to assemble the ubuntu config using kconfigflavour <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1285>
<pstolowski> mvo, my branch failed on econnreset test yesterday - https://s3.amazonaws.com/archive.travis-ci.org/jobs/225939208/log.txt?X-Amz-Expires=29&X-Amz-Date=20170427T104419Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJRYRXRSVGNKPKO5A/20170427/us-east-1/s3/aws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=014a53a5f0d9f89ee092ab7db9df6258e5f7cc3fa15bd68841c80719c2148446 - did you land any fixes since? shall I just retry?
<mvo> pstolowski: yeah, I'm working on making them more reliable
<mvo> pstolowski: sorry for that, just retry for now
<mvo> zyga: do you think you could look at 3232?
<mvo> zyga: a (nice) suggestion from samuele in there
<mvo> zyga: I think this can go in then
<mvo> (assuming it gets a second review)
<zyga> mvo: looking
<zyga> mvo: the "applied"?
<zyga> mvo: I'd rather not change that in this branch alone, it's much cleaner to change it in one patch across the whole tree (there are other places)
<mvo> zyga: ok, do you want to do a followup? works for me
<pstolowski> mvo, sure, np. thanks!
<zyga> mvo: yes, when other things land
<zyga> mvo: this is in 3 or 4 places (the wording)
<Son_Goku> morphis: alright, so I'm trying this now... https://koji.fedoraproject.org/koji/taskinfo?taskID=19231693
<morphis> Son_Goku: it's a vendorized build?
<Son_Goku> nope
<morphis> then it wont work
<morphis> Son_Goku: I still need to file bugs for updates to a few golang-* packages and we need https://bugzilla.redhat.com/show_bug.cgi?id=1444819
<morphis> so only the vendorized build works for now
<Son_Goku> then I'll test that locally
<morphis> Son_Goku: I will update https://bugzilla.redhat.com/show_bug.cgi?id=1444819 later today
<Son_Goku> okay
<pedronis> mvo: this fell through the cracks for 2.25 https://forum.snapcraft.io/t/gadget-snap-config-defaults-dont-work/409 I created the topic now, and marked upcoming (2.26)
<pedronis> mvo: don't know what else we missed in 2.25
<zyga> mvo: is 2.25 tagged now?
<Son_Goku> zyga: it's not tagged yet
<pedronis> zyga: he said after the standup
<zyga> aha
<zyga> I missed that , sorry
<mup> PR snapcraft#1280 closed: Added support for 'branches' in Store responses (release, close, and status) <Created by facundobatista> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1280>
<facubatista> yay
<Chipaca> raah rahh
<ogra_> moo?
<Chipaca> ogra_â bash is a bundle of sticks made entirely of poo
<jdstrand> Trevinho: sorry I didn't get a chance to test that sooner
<jdstrand> Trevinho: and thanks you for the fix! :)
<Trevinho> jdstrand: no worries..
<Chipaca> ooh, a jdstrand!
<ogra_> Chipaca, fully agreed :)
<jdstrand> hey Chipaca :)
<Chipaca> jdstrandâ in etelpmoc, change the ()s around the definition of comopt to {}s
<Chipaca> compopt*
<jdstrand> Chipaca: I couldn't stop thinking about bash completion after you left (sorry)
<Chipaca> jdstrandâ still debugging why it doesn't get it quite right, but that'll get the slashes and such
<jdstrand> Chipaca: does that give the 'ls' behavior
<jdstrand> ?
<Chipaca> jdstrandâ closer. it depends. yes? sorta.
<jdstrand> heh
<Chipaca> jdstrandâ it trips up and returns nothing as soon as it's quoted or there is a space in there
<Chipaca> jdstrandâ and i'm tracing that and very puzzled by it
<Chipaca> but, yeah, it wasn't setting compopt -o filenames, meaning you didn't get ls-like behaviour ever
<Chipaca> because, subshell /o\
<Chipaca> my bad there
<jdstrand> interesting
<zyga> Chipaca: does that mean the tab-completion feature is out of 2.25??
<Chipaca> I'm torn
<Chipaca> I think we should land it, and then iterate
<Chipaca> but I'm open to other people saying otherwise
<jdstrand> Chipaca: if we land it, please add '&' to the grep
<Chipaca> jdstrandâ will do
<jdstrand> however, if we land it as is, I'm quite sure someone will file a bug
<jdstrand> that's ok. we could pre-file it :)
<jdstrand> and even reference it in the code
 * zyga breaks for lunch :/
<niemeyer> Mornings
<jdstrand> niemeyer: good morning :)
<jdstrand> stgraber: hey, I just noticed that my lxd snap is not upgrading. I'm at 2.5 (r241). have you seen this?
<jdstrand> stgraber: fyi, https://forum.snapcraft.io/t/lxd-snap-not-refreshing-says-it-is-local-but-it-isnt/411
<jdstrand> mvo: sorry to bother you. this seems like something potentially bad ^
<mvo> pstolowski: 3242 is ready for a second review, should fix the econnreset tstuff
<mvo> jdstrand: looking
<pstolowski> mvo, thanks, approved
<mvo> jdstrand: that looks alarming indeed - last refresh was month and month ago
<mvo> jdstrand: I assume you installed this a long time ago? I suspect there is somehting missing in the state, would you mail the state file to me (privately) ? it may contain the macaroon so either edit it out or I can write something that just extracts the lxd information
<jdstrand> mvo: I was one of the first users of the lxd snap, so, 'yes'
<jdstrand> mvo: /var/lib/snapd/state.json ?
<jdstrand> mvo: should I stop snapd first or anything?
<mvo> jdstrand: yes, this one. should be fine
<pedronis> mvo: jdstrand: that error can happen only if the state has no snapid for that snap
<pedronis> we had some bugs around preserving side info on some ops, might be because of one of those
<mvo> pedronis: yeah, I hope the state give some more clues
<Chipaca> zygaâ do i have to do anything to have ./run-checks --static not complain about things in configure?
<zyga> Chipaca: try distclean in cmd but other than that, no :/
<zyga> Chipaca: I'm working on a way to switch away from automake
<zyga> Chipaca: sorry about that
<jdstrand> mvo: sent
<jdstrand> Chipaca: you might have to remove some stuff that distclean doesn't I don't know if that got cleaned up, but I have in my notes: cd cmd ; make clean ; make distclean ; rm -f aclocal.m4 config.sub config.guess depcomp configure snap-confine/snap-confine.apparmor snap-confine/Makefile snap-confine/Makefile.in snap-confine/tests/Makefile snap-confine/tests/Makefile.in ; rm -rf autom4te.cache
<mvo> jdstrand, pedronis: look like side-info is totally busted for this particular revision :/ http://paste.ubuntu.com/24466403/
<mvo> jdstrand: as a workaround you can snap rmeove lxd/snap install --candidate lxd
<mvo> jdstrand: the interessting question of course is what happend
<Chipaca> jdstrandâ I was a lazy bag of lazy stuff and moved ahead by putting my static check before the spellcheck
<Chipaca> jdstrandâ pushed a branch full of comments, and a &
<pedronis> mvo: yea, that seems the effect of disable/enable at some point I think
<pedronis> for example
<mvo> pedronis: aha, indeed - most likely that bug
<jdstrand> mvo: I'm kinda worried to remove it cause I don't want to lose my container. it has my whole build environment
<jdstrand> it is plausible I did enable/disable. I've done that before, but I don't know if I ever did on this snap. what if I disable/enable now?
<pedronis> jdstrand: it won't fix it
<pedronis> it lost the information
<pedronis> jdstrand: what you can do is stop snapd, edit that bit of state to put back the snapid, restart snapd and run refresh
<jdstrand> I'd much rather do that than remove/install
<mvo> jdstrand: yeah, was about to suggest the same, copy the snap-id from the pastebin
<mvo> jdstrand: with that you are hopefully back
<mup> PR snapd#3242 closed: tests: tweak time for econnreset test a bit more <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3242>
<jdstrand> mvo: I'm looking at a wall of text and I have the paste in front of me. you are saying replace '{"name":"lxd","snap-id":"","revision":"241"}' with '{"name":"lxd","snap-id":"id from paste","revision":"241"}'?
<mvo> jdstrand: correct
<mvo> jdstrand: and make a backup of the state file first :)
<mvo> jdstrand: (I guess you did by mailing it to me)
<jdstrand> mvo: ok, that worked. thanks! I updated the forum for some of this, but you guys might want to add more detail
<jdstrand> pedronis: thank you too :) ^
<mvo> jdstrand: thank you and sorry for the trouble
<mvo> jdstrand: I think we know which bug it caused, the issue is long fixed since but of course there is fallout :/
<jdstrand> mvo: do you have a json linter/checker? it seems like this could be detected programmatically. I'm not sure how many state.json issues there are that could benefit from a linter/checker, but it's an idea
<mvo> jdstrand: the issue here is that no snap-id is a legal state, it happens if you sideload without any assertions
<mvo> jdstrand: this makes it hard to cleanup
<jdstrand> mvo: yes, but the revision didn't start with an 'x'
<mvo> jdstrand: but I think we could be smarter actually - if it has a normal revision but no snap-id and there is a snapid available in the previous sequence its probably that bug
<mvo> jdstrand: yeah, was just thinking this too :)
<jdstrand> exactly
<Chipaca> hah! tests failed because i can't type
<ogra_> standup ?
<mup> PR snapcraft#1263 closed: lxd: pass through commands into the container <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1263>
<mup> PR snapd#3233 closed: packaging: remove current mount profiles when purging <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3233>
<mup> PR snapcraft#1278 closed: recording: save the snapcraft.yaml in the resulting snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1278>
<morphis> zyga: where is /var/lib/snapd/mount coming from?
<zyga> morphis: snapd writes it
<zyga> morphis: it's where mount profiles are stored
<morphis> zyga: getting: cannot perform operation: mount --bind /snap/core/current//var/lib/snapd mount /tmp/snap.rootfs_5lYRhE/var/lib/snapd/mount: No such file or directory
<morphis> none of the core snaps (stable, candidate or edge) has that directory
<zyga> morphis: it should be created by snapd
<bdx_>  /join #mailman
<morphis> zyga: how if the core snap is read-only?
<zyga> morphis: well, /var/lib/snapd is not
<zyga> morphis: is that the actual error message you see?
<morphis> zyga: yes
<zyga> that message looks wrong
<zyga> (I mean, the space)
<zyga> morphis: how did you get there?
<morphis> yeah, I typed it as somehow copying from my VM didn't worked
<zyga> ahh
<zyga> ok
<zyga> that's much better then
<morphis> that is on suse with the latest stable snap
<zyga> hmm hmm
 * zyga looks
<zyga> morphis: how did you make that happen?
<morphis> wondering if I just did things wrong with my build setup .. let me try again with the package in the repository
<morphis> zyga: hm, must be my build
<morphis> the package from the repository works fien
<zyga> morphis: aha, which distro is that?
<morphis> suse
<morphis> zyga: btw. https://blog.online.net/2017/04/27/scaleway-disruptive-armv8-cloud-servers/
<morphis> zyga: must have been a local change from me, will figure that out later
<zyga> morphis: oh nice
<zyga> morphis: btw, I got a v7 server but it was running some local kernel without any chance of changing that
<zyga> intereqesting forum post https://forum.snapcraft.io/t/local-snap-store/412
<mup> PR snapd#3244 closed: many: fix review comments from PR #3177 <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3244>
<mup> PR snapd#3156 closed: many: support debian in our CI <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3156>
<mvo> morphis: thank you very much for this branch
<mup> PR snapd#3231 closed: cmd/snap-discard-ns: remove current profile when cleaning up <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3231>
<mup> PR snapcraft#1286 opened: lxd: Setup image and target arch for cross-compilation <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1286>
<zyga> mvo: can you announce here when you are about to tag 2.25
<jdstrand> kyrofa: hey, I'm having some trouble with snapcraft cleanbuild. do you have a moment to help?
<mup> PR snapd#3232 closed: cmd/snap-confine: write current mount profile <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3232>
<niemeyer> zyga: Some notes on this one for a follow up ^^^
<niemeyer> mvo: Bash completion feels a bit optimistic if we want to cut 2.25 soon
<zyga> niemeyer: I saw, thanks!
<mvo> zyga: sure, can do.
<kyrofa> Sorry jdstrand, I got a late start this morning. I must have turned my alarm off in my sleep
<kyrofa> jdstrand, how can I help?
<mvo> zyga: anything particular you are waiting?
<jdstrand> kyrofa: no worries, I only asked a moment ago
<niemeyer> pedronis: Quick proposal on the aliases topic
<zyga> mvo: not really, just want to know when it's out :)
 * niemeyer lunches
<jdstrand> kyrofa: so, trying to use cleanbuild. I have a working lxd and containers, blah blah. cleanbuild creates a new container each time
<zyga> jdstrand: I think this is the design
<jdstrand> kyrofa: but it doesn't have networking. the snapcraft help tells me to go to https://linuxcontainers.org/lxd/getting-started-cli/
<zyga> jdstrand: aha, that's not designed :)
<pedronis> niemeyer: it's probably easy, but needs a quick branch, mvo?
<jdstrand> kyrofa: which I did. but that doesn't help. I either need to tell snapcraft how to invoke the creation or I need to tell it to use an existing conatiner
<pedronis> mvo: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18
<pedronis> mvo: https://forum.snapcraft.io/t/improving-the-aliases-implementation/18/26
<jdstrand> kyrofa: but I don't see how to do either
<mvo> pedronis: works for me, does not look like a big change
<mup> PR snapd#3246 opened: cmd/snap-confine: remove obsolete debug message <Created by zyga> <https://github.com/snapcore/snapd/pull/3246>
<kyrofa> jdstrand, when you create new containers, can they hit the network?
<kyrofa> jdstrand, by hand, I mean
<jdstrand> kyrofa: no. I have to create them use --profile=with-network
<jdstrand> using*
<kyrofa> jdstrand, ah, that's the problem them
<pedronis> mvo: niemeyer: let me try to make a quick branch
<jdstrand> yes
<kyrofa> jdstrand, snapcraft just runs `snapcraft launch <whatever> -e`
<kyrofa> Err.... lxc
<kyrofa> Not awake yet
<jdstrand> kyrofa: is it possible to add options to the launch? I really need --storage=default --profile=with-network
<jdstrand> even if it was just in a config file, that would work for me
<kyrofa> jdstrand, I don't think so, not right now anyway, but that seems like a perfectly valid use-case and worth a bug
<jdstrand> ok, I'll file a bug. I guess I can just cowboy a patch into /usr to see if it works
<kyrofa> jdstrand, snapcraft just shells out... you can just patch snapcraft for now too
<kyrofa> I can show you where if you like
<jdstrand> that would be great :)
<kyrofa> (it's easy to run from source)
<kyrofa> Okay, one second, coffee is ready
<mup> PR snapcraft#1287 opened: tests: minor cleanups on the spread tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1287>
<kyrofa> jdstrand, alright, do you want to run from source then?
<kyrofa> (or edit the installed snapcraft)
<jdstrand> kyrofa: I see it is snapcraft/internal/lxd.py
<kyrofa> jdstrand, yep, that's it
<jdstrand> kyrofa: I'll just modify deb files
<kyrofa> jdstrand, good deal. Just for reference, if you want to run from source, I recommend removing the snapcraft deb install first (leaving its deps in place), but then all you need to do is clone snapcraft and add its bin/ dir to the PATH
<jdstrand> kyrofa: yeah, otherwise files in /usr might be used. would have to play with PYTHONPATH iirc (see this with riview tools, et al)
<jdstrand> kyrofa: ok, thanks! cleanbuild is working now
<kyrofa> jdstrand, awesome! You can see from that code though how easy it would be to add the feature you request
<kyrofa> Please do log a bug
<kyrofa> The only problem to solve is how to best expose that functionality to the user from snapcraft
<jdstrand> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1686766
<mup> Bug #1686766: cleanbuild should allow specifying options to 'lxc launch' <Snapcraft:New> <https://launchpad.net/bugs/1686766>
<mup> PR snapd#3247 opened: many: use "SNAP.APP as ALIAS" instead of => when listing added/removed aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3247>
<kyrofa> Thanks jdstrand
<mvo> sergiusens: do you install snaps as part of the snapcraft testsuite? I see some error reports in errors.ubuntu.com that indicate someone tries to install spongeshaker on s390x. if that is the snapcraft tests, please set "SNAPPY_TESTING=1" in the environment, this will ensure no error reports are generated
<jdstrand> kyrofa: np. thanks for talking me through it
<pedronis> mvo:  niemeyer: snapd#3247
<mup> PR snapd#3247: many: use "SNAP.APP as ALIAS" instead of => when listing added/removed aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3247>
<kyrofa> Any time :)
<sergiusens> mvo: yes we install snaps as part of the suite, maybe that SNAPPY_TESTING needs to be mentioned on the forums :-)
<mvo> sergiusens: yes, I can do that
<jhobbs> is there a way to install different channels/revisions of the same snap at the same time on the same system, by giving them different names perhaps?
<jhobbs> so if i wanted juju edge i could run juju-edge.juju and i wanted juju-beta i could run juju-beta.juju or something
<mup> PR snapd#3248 opened: Fail early in the spread suite if trying to run it inside a container <Created by mvo5> <https://github.com/snapcore/snapd/pull/3248>
<kyrofa> jhobbs, I'm afraid not-- only one revision of a given snap can be active at once
<kyrofa> jhobbs, the only way to do something like that would be to have multiple juju snaps
<kyrofa> (named differently)
<jhobbs> ok kyrofa that's what i figured, thanks
<zyga> jdstrand: I let a small comment on https://github.com/snapcore/snapd/pull/2749
<mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<zyga> jdstrand: if you want I can take care of it
<jdstrand> Trevinho: ok, I finally tested your preload changes. it no longer segfaults. it is interesting that now there is different stderr output: http://paste.ubuntu.com/24467212/
<jdstrand> zyga: let me do it, thanks. I've been wanting to get this to pass the tests and this might be the key
 * jdstrand hasn't been able to get to his PRs due to other snappy reviews (sorry)
<zyga> no worries, we're all in the same boat :)
<zyga> jdstrand: I'll look at the netlink one now
<pedronis> mvo: that branch is waiting for its travis run , will take a while IÂ suppose
 * zyga will break in 40 minutes to visit friends
<mvo> pedronis: yeah, I have dinner in the meantime
<zyga> jdstrand: one small fixme
<Trevinho> jdstrand: are you sure you're using the proper script to launch it? It should be snapcraft-preload. As it seems it doesn't use it right now... Mhmh
<jdstrand> Trevinho: I did rename it:
<jdstrand> apps:
<jdstrand>   snap-review:
<jdstrand>     command: snapcraft-preload click-review
<Trevinho> Hmm
<Trevinho> I got that error when the lib wasn't preloaded...
<jdstrand> Trevinho: http://paste.ubuntu.com/24467447/
<jdstrand> and I see in command-snap-review.wrapper: exec "snapcraft-preload" click-review "$@"
<Trevinho> jdstrand: anyway... It seems that the tool doesn't cleanup temp on ctrl+c... When testing i had quickly filled it with gb of stuff... ;-)
<jdstrand> that might be part of the rename. ok, noted
<Trevinho> jdstrand: can you lsof -p it to check?
 * jdstrand has a number of other things to fix there
<Trevinho> jdstrand: don't redefine the part... Just add after: snapcraft-preload
<Trevinho> Plus the command
<jdstrand> Trevinho: python3 31889 jamie  mem    REG    7,3    28072      39 /snap/review-tools/x1/lib/libsnapcraft-preload.so
<Trevinho> Hm... So it indeed is there...
<Trevinho> Weird
<Trevinho> I wasn't getting that... But I'll try it tomorrow... It's past midnight here... ;-)
<jdstrand> Trevinho: I need to redefine it for the amd64 vs not-amd64 stuff (build-backages) I thought
<Trevinho> jdstrand: upstream version should work now
<jdstrand> honestly, I've not mastered snapcraft parts by any stretch
<Trevinho> jdstrand: it works in both amd64 and i386 here.
<Trevinho> jdstrand: but in case you can override remote parts things
<zyga> Trevinho: I may use your preload helper for classic confinement
<jdstrand> Trevinho: ok, thanks!
<Trevinho> zyga: Yeah... It's something I need to test too, but it should just work. As it prefers snap stuff over inaccessible elements
<Trevinho> Or not existent. But an access issue in apparmor gives a still some false positives
<jdstrand> Trevinho: ok, it seemed to build using 'after:\n- snapcraft-preload'
<jdstrand> Trevinho: I mean the build. still have the error output I pasted earlier
<zyga> mvo: are we missing the actual meat in that branch https://github.com/snapcore/snapd/pull/3241
<mup> PR snapd#3241: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3241>
<zyga> mvo: I only see the tests
<zyga> ah, odd, I see it after reloading
<jdstrand> Trevinho: speaking of apparmor-- I see denials for /etc/magic
<jdstrand> Trevinho: fyi for tomorrow
<zyga> mvo: dropped a comment on that branch
<zyga> Trevinho: I have a different goal, I'll let you know later when I start working on this
<ogra_> zyga, or mvo ... a second signoff on https://github.com/snapcore/core-build/pull/8 would be appreciated :)
<mup> PR core-build#8: add shellcheck test, fix code for shellcheck <Created by ogra1> <https://github.com/snapcore/core-build/pull/8>
 * zyga breaks
 * ogra_ looks for glue to fix zyga 
<kyrofa> nessita, is there a way to set up collaboration in the store only after having registered a name (prior to uploading anything)?
<zyga> ogra_: I'll check it out later, I need to run
<zyga> ogra_: sorry :/
<ogra_> zyga, no worries
<pedronis> niemeyer: it would be good I think to run the sync script again for the review sprint
<morphis> zyga: please see my last comment on https://github.com/snapcore/snapd/pull/3222
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis> zyga: looks like you were looking at a older revision
<morphis> mvo: thanks for merging the debian CI one :-)
<morphis> niemeyer: btw. did you do a snap for discourse?
<niemeyer> morphis: Of course! :)
<kyrofa> niemeyer, would be curious to see that
<niemeyer> Yeah, it's definitely an interesting one.. I'm actually using it as a testing bed for some ideas that we've been discussing
<niemeyer> The update experience is already much better than the upstream process
<morphis> niemeyer: nice, is it in the store?
<niemeyer> morphis: I've been working its way there
<morphis> niemeyer: and we're running forum.snapcraft.io with it?
<niemeyer> We won't be able to get it out of devmode for a while, but I've been fixing a few issues with jdstrand in multiple iterations
<niemeyer> morphis: Yeah
<morphis> niemeyer: nice, was wondering how mature it is and wanted to try it for a personal project
<niemeyer> morphis: It is pretty solid.. there's at least one more issue I need to solve for integrating the database migration on startup, but after that I'd be happy to have you as another tester for sure
<morphis> niemeyer: sounds great!
<ogra_> morphis, quietening the anbox telegram channel a bit by moving bits to a forum ?
 * ogra_ would appreciate that ... :)
<morphis> ogra_: was one thing I was thinking about ..
<ogra_> 1
<ogra_> err
<ogra_> +1
<morphis> but actually not sure if I want to spend time on administrating that
<ogra_> yeah
<ogra_> it is surely some extra work
<morphis> yeah, both in administration and social maintenance
<morphis> niemeyer: can you see why a certain linode instance failed to boot?
<niemeyer> morphis: I can try to..
<morphis> niemeyer: tried to spin up a fedora-25 instance on Spread-25
<niemeyer> morphis: Checking
<morphis> but connection timesout after a bit when the instance was already reported as booted
<niemeyer> morphis: It's powered off.. probably missed the -reuse flag?
<niemeyer> morphis: One detail that we probably need to address both on Fedora and the Debian images:
<niemeyer> morphis: By default Linode boots with a custom Linode kernel
<morphis> niemeyer: https://paste.ubuntu.com/24467648/ is what I used
<niemeyer> morphis: We can fix that by installing the kernel in the image itself, and booting with GRUB 2 as a "kernel" instead (that's how Linode sets it up)
<niemeyer> morphis: See details here for the several distros: https://www.linode.com/docs/tools-reference/custom-kernels-distros/run-a-distribution-supplied-kernel-with-kvm
<morphis> niemeyer: tought I've set "GRUB 2" for debian
<niemeyer> morphis: Could be.. I haven't checked really.. just reminded of the problem now
<morphis> niemeyer: https://github.com/snapcore/snapd/blob/master/spread.yaml#L59
<niemeyer> morphis: \o/
<morphis> niemeyer: did the same for fedora but maybe that is the issue here, let me try without "GRUB 2" for fedora
<niemeyer> morphis: Ah, yes, you most probably need to boot without it the first time
<niemeyer> morphis: I'll tweak the notes in the forum later to mention this detail
<morphis> niemeyer: worked for debian thought with "GRUB 2", however not sure if Fedora uses grub or not
<morphis> niemeyer: thanks!
<niemeyer> morphis: Problem is that the image needs to have the kernel inside it in the first place and grub be ready to take the boot there, otherwise it won't work
<morphis> niemeyer: ok, without "GRUB 2" it worked
<niemeyer> morphis:  Ubuntu won't work either, IIRC
<morphis> ok
<niemeyer> morphis: Ours work because I tuned
<niemeyer> Our images, that is
<morphis> ok
 * ogra_ imagines spoilers and chrome exhaust pipes on gustavos images ...
<niemeyer> ogra_: That's sooooo unlike me! ;)
<ogra_> heh
<niemeyer> I could see myself doing the opposite, taking a 69's beetle and bringing it to its original form :)
<niemeyer> But first I need to prepare for the sprint..
<niemeyer> Will step out and run some external life errands here.. back later
<morphis> niemeyer: can you snapshot Spread-26 as a fedora-25-64 image?
<mvo> ogra_: the shellcheck pr will probably be done tomorrow, still working on 2.25
<mvo> ogra_: final test is still not done
<niemeyer> morphis: Image is a bit large at 1800MB.. can we get it down a bit somehow?
<niemeyer> morphis: Note that the restore logic in spread.yaml drops data such as packaging information and packages themselves which were downloaded.. that needs tweaking for fedora and other rpm based distros
<niemeyer> This may be part of the bloat there
<niemeyer> Will being these point back into the forum so we can discuss async
<mup> PR snapcraft#1287 closed: tests: minor cleanups on the spread tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1287>
<jdstrand> Chipaca: ok, re-reviewed https://github.com/snapcore/snapd/pull/3150. I think it is quite close (depending on your opinion of how to handle _filedir, but I'm not blocking on that)
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<pedronis> mvo: snapd#3247 was running and passing but exceeded time limit :/
<mup> PR snapd#3247: many: use "SNAP.APP as ALIAS" instead of => when listing added/removed aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/3247>
<pedronis> mvo: I think we need to rethink something here, a CI process  that can take 3h+ to land something is not very C
<pedronis> mvo: you are also the one that suffers most, needing to wait through this for releases, and usually it gets worse exactly around releases
<kyrofa> Chipaca, was `snap install --revision=` only recently locked down to collaborators on that snap?
<kyrofa> (like, v2.24?)
<pedronis> kyrofa: it was always planned to work like that
<pedronis> it's the store that does that, in any case, is not a snapd change
<kyrofa> pedronis, I'm aware, but it wasn't like that until recently
<kyrofa> Huh, okay
<kyrofa> Would be nice to get a heads up when stuff like that happens, maybe a forum post
<pedronis> kyrofa: I'm really not aware that changed and was different before
<kyrofa> pedronis, I've never once had to run `snap login` before today, but have run `snap install --revision=` many times
<mup> PR snapd#3247 closed: many: use "SNAP.APP as ALIAS" instead of => when listing added/removed aliases <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3247>
<pedronis> mvo: ^ merged
<noise][> kyrofa: are you able to install the revision when you are logged in (as a collaborator on the snap) ?
<kyrofa> noise][, yes, the only issue is that the behavior seems to have changed without warning
<pedronis> niemeyer: I updated the docs to use  "command as alias" format as well
<pedronis> kyrofa: is this revision published in some channel? or was it published at some point?
<kyrofa> pedronis, it's the previously-stable revision
<noise][> kyrofa: understood, trying to find when that change happened
<noise][> and is on my agenda to start having store release notes on the forum
<Chipaca> kyrofaâ snap install --revision= never worked unless you were a collaborator or the revision was tip
<facubatista> kyrofa, you say that, after login, you can install a revision that is NOT currently published?
<kyrofa> Chipaca, then I must be insane, because I've done it many times to troubleshoot migration issues
<kyrofa> facubatista, if "not currently published" = "superceded by another revision in the same channel," yes
<Chipaca> kyrofaâ well, you could also specify --revision if you _had_ the revision
<kyrofa> Chipaca, what do you mean?
<Chipaca> kyrofaâ if you had it installed
<Chipaca> e.g. if you were on 2, refreshed to 3 (but still have 2), you can use --revision to move to 2
<noise][> i.e. in the last N (n=3?) that you had installed/updated-to?
<Chipaca> yep
<kyrofa> Ahhhhhh
<kyrofa> Yeah I bet that was it
<noise][> bingo!
<noise][> ok, glad we all are not crazy :)
<Chipaca> noise][â speak for yourself :-p
 * Chipaca is probably certifiable at this point
 * noise][ clarifies to only apply to this issue
<Chipaca> :-)
<cachio> niemeyer, hi, I was working on that https://forum.snapcraft.io/t/testing-console-conf/413/8
<cachio> niemeyer, I have a solution for that problem
<cachio> niemeyer, are you familiar with this topic?
<mvo> pedronis: yay, thanks
 * Chipaca sadfaces and moves tab completion to 2.26
<pedronis> Chipaca: hug
<mvo> pedronis: I'm too tired to release tonight, will happen first thing in my morning
<zyga> jdstrand_: it's in
<mup> PR snapd#2749 closed: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2749>
<jdstrand_> zyga: \o/
<jdstrand_> zyga: thank you :)
<zyga> jdstrand: I'll go through the netlink one but it has some more content
<zyga> jdstrand: and this may also be in the release :-)
<zaganator> hi got an issue
<zaganator> i'm trying 4 the first time to install snapApp un my system but where is a list of the installable snap?
<zaganator> guys no one can answer me
<zaganator> ???
<kyrofa> zaganator, you can use the software center, or use `snap find` to find snaps
<zaganator> i've did it but the few sofware i found are unuseful for me...
<zaganator> does some beta version are around to be tested
<kyrofa> zaganator, I guess it depends on what you're looking for
<jdstrand> zyga: thanks! :)
<zaganator> right... but i've found exactly 7 app (only)
<kyrofa> zaganator, this might be along the lines of what you're looking for: https://uappexplorer.com/apps?type=snappy
<kyrofa> That is an unofficial third-party site, but it indexes our store
<zaganator> woooooooooooooow
<zaganator> thanks
<zaganator> this is better just to try something "done" in snap
<kyrofa> niemeyer, do you know if LP: #1636934 was ever contained in a release?
<mup> Bug #1636934: snapctl seem to cache values even if snap is removed and then installed again <snapd:Fix Committed by stolowski> <https://launchpad.net/bugs/1636934>
<zaganator> leaving Grazie!!
<kyrofa> No problem zaganator, have a good one
<kyrofa> Ah, v2.24 it seems
<mup> Bug #1686852 opened: Can only run hello snap as root <Snappy:New> <https://launchpad.net/bugs/1686852>
#snappy 2017-04-28
<mup> PR snapcraft#1288 opened: store: collaboration UI for snaps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1288>
<mup> PR snapcraft#1289 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1289>
<mup> PR snapcraft#1289 closed: beta <Created by snappy-m-o> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1289>
<mup> PR snapcraft#1290 opened: tests: refactor tests with build and stage packages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1290>
<mvo> Pharaoh_Atem: hey, I'm working on a new snapd release currently and you mentioned you wanted some tarballs with vendor removed, do I remember this correctly?
<pedronis> mvo: hi, is the release draft missing mentioning release.schedule ?
<pedronis> sorry refresh.schedule
<mvo> pedronis: yes indeed, I need to add that
<zyga> o/
<zyga> mvo: hey, how are you feeling
<zyga> mvo: ready for the sprint?
<mvo> zyga: yes
<mvo> fgimenez: new beta snaps available for an early smoke test of 2.25
<fgimenez> mvo: great thanks! on it, will let you know how it goes
<mvo> fgimenez: and ubuntu-core as well
<fgimenez> mvo: ack, we have spread tests for it too, but yet no spread-cron branches up, i'll trigger them manually
<mup> PR snapd#3246 closed: cmd/snap-confine: remove obsolete debug message <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3246>
<mup> PR snapd#3249 opened: releasing package snapd version 2.25 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3249>
<zyga> pstolowski: can you have a 2nd look on https://github.com/snapcore/snapd/pull/3225 - I think I addressed your questions
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<zyga> pstolowski: if not just comment and I'll do my best
<zyga> I could also use a 2nd review on (trivial) https://github.com/snapcore/snapd/pull/3234
<mup> PR snapd#3234: overlord/snapstate/backend,interfaces/mount: move ns management code <Created by zyga> <https://github.com/snapcore/snapd/pull/3234>
<pstolowski> zyga, sure, will do in a moment
 * zyga -> breakfast
<zyga> day of code reviews
<mup> PR snapd#3250 opened: store: fix TestDownloadSyncFails for go1.8 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3250>
<abeato> ogra_, how is the initrd for a kernel snap built? where does snapcraft pull the sources from?
<mup> PR snapd#3251 opened: packaging: cleanup how built-using is generated  <Created by mvo5> <https://github.com/snapcore/snapd/pull/3251>
<zyga> re
<fgimenez> mvo: i'm getting an error with econnreset on all the platforms http://paste.ubuntu.com/24471739/ the timeout makes the execution stop, i'll retrigger all of them removing this test
<mvo> fgimenez: uh, strange
<mvo> fgimenez: strange because this was/is working ok in qemu and linode, wonder whats the difference with external
<fgimenez> mvo: let me run it isolated with -debug on amd64 to seee what's going on
<zyga_> pstolowski: some comments on https://github.com/snapcore/snapd/pull/3217#pullrequestreview-35302363
<mup> PR snapd#3217: snap: support for snap tasks --last= <Created by stolowski> <https://github.com/snapcore/snapd/pull/3217>
<pstolowski> thanks
<zyga_> Chipaca: hey, I see lots of completion failures on Debian: https://github.com/snapcore/snapd/pull/3150
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<mvo> pedronis: if you could have a look at 3241 that would be great. it misses tests but I would love to get a early sanity check of the idea. we may need it soon to help CE
<zyga_> mvo: sorry for my naive question but in https://github.com/snapcore/snapd/pull/3241#discussion_r113743668 does that mean the process could work offline?
<mup> PR snapd#3241: snap: make `snap prepare-image` read .assert files for local snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3241>
<mvo> zyga_: not quite
<mvo> zyga_: it could with some more work
<zyga_> aha, so this would just prime the rest of the code to do the right thing
<zyga_> ?
<mvo> zyga_: right now the way it works is that snap prepare-image gets some data from the store and then later fetches the assertions from the store
<mvo> zyga_: my branch just makes the code fish out most of the store info from the assertion. however it will still later contact the store
<mvo> zyga_: exactly
<zyga_> mvo: understood, thanks!
<mvo> zyga_: this is a bit of a quick fix for CE, I think we can do it fully offline with a bit more work
<zyga_> I just never looked at that code
<zyga_> mvo: one thing that I think would be interesting is a way to reproduce an image build given a manifest (with offline snaps and assertions)
<zyga_> mvo: but no ad-hoc design on IRC :)
<mvo> zyga_: yeah, I think with full offline capability this would be almost there
<pedronis> zyga_: we disussed that when discussing improving prepare-image (I have an email thread with Gustavo that IÂ need to port to the forum), he wasn't too keen on having a manifest on top of model assertions
<pedronis> though
<zyga_> pedronis: manifest could only capture a snapshot of what the model describes
<zyga_> pedronis: not as a way to create other things
<zyga_> pedronis: I think that it will be a common request from CE, to be able to reproduce image builds exactly, at specific revisions
<pedronis> zyga_: well a manifest is not enough (given how the store works atm and rules), you really need to cache what prepare-image used
<zyga_> pedronis: yes, I was thinkin about a full cache
<zyga_> pedronis: with all the snaps and assertions
<pedronis> ok
<pedronis> it's all a bit odd because if you don't change anything then it's pointless
<pedronis> you get the image you already got once
<zyga> Son_Goku: hey, how are you doing
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/3119 has two reviews
<mup> PR snapd#3119: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3119>
<zyga> pstolowski: can we merge it?
<pstolowski> zyga, no, I'd like niemeyer's +1
<mup> PR snapd#3252 opened: tests,cmd/snap-confine: port older snapd-discard-ns tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3252>
<zyga> pstolowski: ok
<Chipaca> ooh, el reg article mentioning snaps
<zyga> Chipaca: can you share the URL please
 * Chipaca clutches it close to his chest
<Chipaca> NO
<zyga> aww :-(
<Chipaca> zygaâ http://www.theregister.co.uk/2017/04/28/snap_flatpacks_the_future_of_desktop_linux/
<Chipaca> shame it sounds like they've only actually tried flatpaks
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> "the kernel is not going to be a flatpak any time soon"
<zyga> yeah, because it's a snap already
<ogra_> abeato, during the core snap build ....
<fgimenez> mvo: about the error on the boards using the external backend it turns out that now the files under /home/gopath/src/github.com/snapcore/snapd belong to the user created with console-conf and not to the "test" user, not sure why, a week ago this wasn't happen, i'll continue digging
<ogra_> abeato, https://github.com/snapcore/core/blob/master/live-build/hooks/25-create-generic-initrd.chroot
<abeato> ogra_, are not initramfs images built with the kernel?
<abeato> I mean, when building the kernel snaps
<ogra_> abeato, nope, it is generic ...
<ogra_> abeato, long term we want two initrds, a generic one with all scripts shipped in core and a specific one with only /lib/modules|firmware that the kernel ships
<mvo> fgimenez: thank you
<ogra_> abeato, currently the snapcraft kernel plugin still adds the modules to the generic one at build time though, downloading the core snap and pulling it from there
<abeato> ogra_, so how does it work to add those kernel specific files in the initrd? I see there is a "kernel-initrd-modules" list in kernel snapcraftyaml files
<ogra_> abeato, depends, do you need something specific  the official kernels work slightly different (not using the kernel plugin actually)
<Son_Goku> zyga, the kernel as a snap is pretty useless from a multi-distro point of view
<ogra_> if it is for your build, the kernel plugin simply re-packs it ... for official kernels we include whats needed in the /etc/initramfs-tools/modules file at build time
<zyga> Son_Goku: I didn't mean the corss distro POV, snapd itself is cross distro as it aims to liberalize what a distribution is
<ogra_> abeato, all managed via the initramfs-tools-ubuntu-core package from the PPA
<zyga> Son_Goku: and who knows, maybe we can teach snapd to install kernels on classic :)
<abeato> ogra_, no, just wondering how things are built, thanks for the info
<zyga> Son_Goku: it's just software
 * Son_Goku wonders what problem is being solved at that point
<abeato> ogra_, ok so we can add things for android-boot in that package as you suggested
<ogra_> abeato, the official kernels actually use the linux debs from the archive, install them in a chroot and copy the deb contents into the snap ...
<zyga> Son_Goku: common packaging environment, I could boot fedora kernels and you could boot ubuntu kernels without any repackaging :)
<ogra_> abeato, right, just another script
<Son_Goku> zyga: if the Linux world wanted that, we would have had a common packaging environment already
<ogra_> abeato, and a simple switch on the kernel cmdline to pick that instead of the default for booting recovery
<Son_Goku> God knows people tried
<zyga> Son_Goku: that's totally untrue ;)
<abeato> ogra_, why this difference between official kernels and what the kernel pluin does? Which approach should I take to build for a new board?
<zyga> Son_Goku: the linux world cannot want anything as there are always polarized opinions
<Son_Goku> at least we're down to ~4 systems instead of ~20
<zyga> Son_Goku: I'd say that technically it wasn't done correctly before
<zyga> Son_Goku: but it's not about desire at all
<ogra_> abeato, for secureboot we need the kernel binary signed by the archive key, using the existing deb is the easiest way for that
<pstolowski> zyga, addressed your comments to #3217
<zyga> Son_Goku: just add hrw and any other person into the "linux world" and they will disagree ;)
<zyga> pstolowski: thanks! looking
<Son_Goku> zyga: that's unfair
<Son_Goku> hrw complains about everything :)
<zyga> Son_Goku: see
<abeato> ogra_, got it, so if secureboot is not involved, it would be better to use kernel plugin, right?
<zyga> Son_Goku: "linux world" is not a measure of anything
<Son_Goku> zyga: If I *really* wanted to, i could boot Ubuntu kernels on Fedora
<zyga> Son_Goku: but the effort is non-trivial
<Son_Goku> yes
<Son_Goku> but snaps don't make that better
<zyga> Son_Goku: if you had any kenrel in a snap you could just do it casually
<Son_Goku> they make the process more opaque
<pstolowski> zyga, looking at your 3225, sorry it took so long
 * Chipaca sharpens his Stick of Poking and pokes at spread
<zyga> Son_Goku: I don't understand how
<Son_Goku> fundamentally, the kernel has to know a lot about what it's being built for
<ogra_> abeato, for everything but our default set of boards (for which we theoretically also have classic images and want to use the same kernel in both)... i.e. amd64, i386, rpi2/3 and dragonboard, you should use the kernel plugin
<Son_Goku> and things like rewriting how the version is constructed, what subsystems are enabled, what monkeypatching was done, etc. affect how it will work on a given userland
<abeato> ogra_, I see, thanks!
<ogra_> abeato, really depends if you want/need to build from source or can actually use an existing deb based kernel
<zyga> Son_Goku: I'm not sure I agree
<Son_Goku> the kernel influences the userland and vice versa, so changing expectations can have odd effects
<zyga> Son_Goku: if that were the case we didn't have generic x86 kernels
<Son_Goku> I'm not talking about at the hardware level
<ogra_> abeato, i.e. for the beaglebone community image i also use the linux-generic kernel simply because it fully supports the borad
<Son_Goku> I'm talking purely software interfaces
<abeato> ogra_, source-based in this case
<Son_Goku> and some of them are non-obvious ones
<ogra_> right, there you want the kernel plugin
<Son_Goku> for example, Ubuntu rewrites the version and bludgeons the upstream kernel version out of the kernel version
<Son_Goku> Fedora doesn't
<abeato> great
<zyga> Son_Goku: so what/
<Son_Goku> if tooling in a Fedora userland expects to check based on the upstream kernel version, that might have unexpected side effects with an Ubuntu kernel
<zyga> Son_Goku: sure but that's very unlikely
<Son_Goku> is it?
<zyga> Son_Goku: and totally irrelevant, every distributor did something similar for whatever reasons
<zyga> Son_Goku: yes, it's a nitpick, totally
<Son_Goku> but the point is that expectations are set based on a distribution convention
<zyga> what expectations?
<zyga> the version string, please!
<Son_Goku> hey, I know of plenty of scripts and things that check it
<Son_Goku> I personally had to write one for blacklisting bad kernel versions
<zyga> will a system stop booting because of those scripts?
<zyga> amyway
<Son_Goku> no, but maybe something will fire that shouldn't or something
<zyga> that was not the point
<zyga> (that's always possible anyway because FOSS has terrible QA)
<zyga> the point is that snaps have this already
<Son_Goku> but another thing is that Ubuntu kernels are unsigned and Fedora ones are
<Son_Goku> so a Fedora boot system wouldn't boot an Ubuntu kernel anyway
<Son_Goku> on UEFI
<zyga> you are looking for problems, not solutions IMO
<zyga> and ubuntu kernels are signed too AFAIK
<zyga> there are two sets
<Son_Goku> as far as I knew, on Ubuntu, only shim and grub are signed
<Son_Goku> maybe even only shim
<Son_Goku> I know in Fedora, we sign everything up to the kernel
<zyga> Son_Goku: no, the kernel is signed too
<Son_Goku> hm, then does Ubuntu's kernel just not do signature checking for kernel modules?
<zyga> Son_Goku: it does
<zyga> Son_Goku: you remember 14.04 stuff
<Son_Goku> ah
<Son_Goku> so this changed after then
<zyga> Son_Goku: FYI I had to sign vmware modules to load them on my machine
<Son_Goku> ah, so that's good
<zyga> Son_Goku: then enroll the key in UEFI
<Son_Goku> yeah, I know that process well :P
<zyga> mvo: artful-amd64?
<Son_Goku> zyga: anyway, I need to take a nap, and then I'll come back and start rolling 2.25
<Son_Goku> I've been up for too long
<zyga> Son_Goku: rest well :-)
<mvo> zyga: oh yes!
<zyga> Son_Goku: I'm cleaning up stuff in anticipation for 2.25
<zyga> mvo: what is artful? :D
<mvo> Son_Goku: rest well indeed
<zyga> mvo: what is that test about?
<mvo> zyga: its for 17.10
<Son_Goku> mvo: I hate live-build, so much
<zyga> aaah
<Son_Goku> debugging that makes me want to murder things
<mvo> zyga: its failing left and right
<zyga> 17.10 is artful something
<zyga> I forgot
<mvo> Son_Goku: everybody hates it
<mvo> Son_Goku: I would really like to kill it with fire
<Son_Goku> mvo: we were trying to use it for a project but it's horrible
<Son_Goku> so now I've moved onto fixing the Ubuntu support in KIWI and build things that way
<mvo> Son_Goku: :/ maybe we can chat after your nap, there must be better ways
<Son_Goku> it's not brain-dead and doesn't make me feel murderous
<Son_Goku> mvo: sure
<mvo> zyga: snapd tests are broken in 17.10, i.e. with go1.8 this is why I added the test machinery for it
<Son_Goku> zyga: Artful Aardvark
<zyga> Son_Goku: aaaaaaaaaaa-distribution
<mvo> zyga: to avoid getting a gazillion FTBFS mails when we try to build there
<mvo> plus I'm sure somewhere is a distro that already moved to go1.8 too
<zyga> mvo: are you on artful already?
<pedronis> mvo: well to be honest I would like us to use 1.8 everywhere ;)
 * zyga spends all of today in github.com/notifications and pull requests
<zyga> pedronis: yes, +100 on 1.8
<zyga> goodies all around
<pedronis> (because go doesn't care at mantaining old releases)
<zyga> Son_Goku: would fedora accept 1.8 toolchain for fc25?
<mvo> pedronis: look at it this way - adding artful tests is the first step towards this goal
<zyga> Son_Goku: e.g. if we wanted to build snapd with a more recent version
<mvo> also the go snap \o/
<zyga> mvo: go snap is an interesting concept but for building classic packages we need to do some heavy lifting to allow building a package with snap as a dependency
<pedronis> mvo: did you autopkgtests or something else?  (me is not paying attention, also IÂ have started to have strong mixed feelings about ever slower tests yesterday)
<pedronis> s/did you/did you add/
<mvo> mwhudson: I love your go snap (I think its yours, right?)
<mvo> pedronis: autopkgtest
<mvo> pedronis: so things will run in parallel at least
<mvo> pedronis: but we should definitely brainstorm during the sprint
<pedronis> ok
<mvo> pedronis: about the tests
<pedronis> yes, they get pretty terrible, especially around release
<pedronis> making your life not so fun IÂ think
<mvo> pedronis: did you see my earlier question about 3241?
<mvo> pedronis: absolutely, plus travis seems to take a nap in between sometimes too
<mvo> pedronis: i.e. we hit some limits there too it seems
<pedronis> yes
<pedronis> a mixture of things
<pedronis> but we need to do something, IÂ think I was starting to have stockholm syndrom but the pain is real
<mvo> lol
 * mvo hugs pedronis
<pedronis> mvo: what's the question 3241, I think IÂ missed it?
<pedronis> *about
<zyga> pedronis: if something hurts we should do it more so it stops and we fix and warts, I agree that tests are pretty unreliable now but the only answer is to fix them and get better infra if needed
<pedronis> well, IÂ don't think the issue is just unreliable
<mvo> pedronis: I was wondering if you could have a quick look at #3241 as a sanity check. if the approach looks ok-ish, I will write more tests etc. mostly asking because this allows us to move forward with CE
<pedronis> they are also too slow for something we run for each commit in the universe
<pedronis> I think
<zyga> morphis_: I'll re-review /usr/lib/linux/vmlinuz-4.8.0-46-generic.efi.signature
<zyga> er
<pedronis> slow+unreliable =Â the worst
<zyga> copy-paste fail
<mvo> yeah, its tricky to find the right balance
<zyga> https://github.com/snapcore/snapd/pull/3222
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> morphis_: just let me know when you are don with it
<pedronis> mvo: I'll try to look after lunch, IÂ also need to do some sprint prep (both travel but also writing some gdoc)
<zyga> pedronis: I wonder if it would make sense for spread to retry individual failing tests (say up to 5 times)
<zyga> but we'd have to fix travis time limit
<mvo> pedronis: thank you
<zyga> and really work on making tests better for a cycle
<morphis_> zyga: I just fixed the failing unit test
<zyga> morphis_: thanks
<zyga> ENOSERVERS
<zyga> throw more $$$ at linode
<zyga> in samsung we had a very nice system
<zyga> since any avereage office had easily about a thousand laptops/desktops for devlopers
<zyga> and they were mostly idle all day (editing = low cpu)
<zyga> they were all wired to gigantic distributed task system for compiling software
<zyga> so when you hit build, it'd really use 100s of machines around you for fantastic speedups
<zyga> I wonder if we could tap into our machines at home, to send tasks and distribute them among ephemeral test VMs
<zyga> so travis and linode are not that critical
<zyga> mvo: question about go 1.8, why did you have to switch to DeepContains?
<zyga> because of the pointer?
<mvo> zyga: I don't know
<zyga> mvo: aha, ok
<mvo> zyga: looking at this rightnow, but wanted to see if that is the only remaining failure
<zyga> mvo: yeah, testing on 1.8 is important, I wonder what else awaits us
<mup> PR snapd#3253 opened: cmd/snap-confine/spread-tests: discard useless --version test <Created by zyga> <https://github.com/snapcore/snapd/pull/3253>
<zyga> why is econnreset failing all the time?
<abeato> ogra_, did you remember to update core-build repo? it looks like some files are still missing
<ogra_> abeato, i am waiting for a second review for the tests PR, i wanted to use your change as an exercise for it once that landed
<abeato> ogra_, ok, please let me know when I can  propose the MP
<ogra_> oh, i have it locally already no need for yopu to do anything
<abeato> great :)
<ogra_> is there anything urgent ?
<abeato> no no
<ogra_> k
<abeato> just wanted to make sure this is not lost
<ogra_> nah
 * ogra_ loses keys and lighters, but rarely code ;)
<abeato> lol
<mup> PR core#36 opened: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <https://github.com/snapcore/core/pull/36>
<mup> PR snapd#3254 opened: tests: re-enable and moderninze /media sharing test <Created by zyga> <https://github.com/snapcore/snapd/pull/3254>
<robje> how to fix "cannot create user data directory: $path : Permission denied"
<Chipaca> robjeâ hey. Where are you getting this?
<zyga> robje: ls -ld ~/snap/
<zyga> robje: is that owned by root?
<zyga> robje: or is the home directory somewhere unusual?
<Chipaca> zygaâ ooh, maybe you should ask these same questions on #1686852
<mup> Bug #1686852: Can only run hello snap as root <Snappy:New> <https://launchpad.net/bugs/1686852>
<Chipaca> :-)
<ogra_> heh, i was about to paste the same :P
<robje> all files and dirs owned by my user and group.
<zyga> thanks, asking!
<robje> home is on NFS
<ogra_> aha
<zyga> robje: ok, can you please pastebin `dmesg | grep DENIED`
<zyga> robje: and `snap version`
<ogra_> "somewhere unusual" :)
<robje> and snap is a symlink to local storage
<Chipaca> people still use NFS <3
<robje> [ 1250.129323] audit: type=1400 audit(1493378981.364:156): apparmor="DENIED" operation="sendmsg" profile="/usr/lib/snapd/snap-confine" pid=24796 comm="snap-confine" laddr=172.28.4.67 lport=1003 faddr=172.28.4.7 fport=2049 family="inet" sock_type="stream" protocol=6 requested_mask="send" denied_mask="send"
<robje> [ 1250.129473] audit: type=1400 audit(1493378981.364:157): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/home/r.epping/" pid=24796 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=2124 ouid=2124
<zyga> robje: are you using NFS?
<zyga> oh
<zyga> you have a dot in your username?
<ogra_> zyga, he said so above :)
<zyga> robje: aha
<zyga> robje: that's unsupported, let me find you a bug report with a lot of details
<robje> yes I have a dot in my username
<zyga> robje: unfortunately there's a kernel limitation here
<zyga> robje: you can kind of work around this but I'm not sure if that's even possible now
<zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
<mup> Bug #1662552: snaps don't work with NFS home <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>
<ogra_> Chipaca, a second checkmark on https://github.com/snapcore/core/pull/36 would be appreciated (one line change)
<mup> PR core#36: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <https://github.com/snapcore/core/pull/36>
<zyga> robje: have a look at that report, let me know if you think I can help you somehow
<Chipaca> ogra_â what was it that had made us leave the binary last time?
<zyga> robje: the root issue is nfs leaks to various parts of LSM so confinement cannot be the same
<zyga> robje: the differences in where user directories are are easier to work around
<Chipaca> but
<Chipaca> zygaâ he doesn't have /snap in nfs
<Chipaca> his home is
<Chipaca> but /snap is a symlink
<Chipaca> now I know _that_ won't work :-) but
<zyga> Chipaca: NFS leaks everyhwere
<Chipaca> would it work to change it to be a bind mount?
<zyga> Chipaca: if you have something on NFS your process will be blocked by seccomp on sendmsg
<ogra_> Chipaca, no idea ... i think it was for some code in 15.04
<zyga> Chipaca: apart from that apparmor doesn't look at symlinks but at actual files
<zyga> Chipaca: so some things may need tuning
<robje> Chipaca $home/snap is a symlink to /local/snap
<zyga> Chipaca: and lastly snap-confine's appramor profile is special
<robje> i.e. on local hdd
<Chipaca> zygaâ ð©
<zyga> Chipaca: all in all it's not trivial to fix everything
<ogra_> Chipaca, iirc some snap code used to call dpkg --compare-versions
<zyga> Chipaca: I wish someone had fixed the kernel side
<zyga> Chipaca: before that I can really do little :/
<zyga> Chipaca: (or allow all network traffic to everything by default, but even then snapd doesn't control the apparmor profile of snap-confine)
<Chipaca> robjeâ right, but as zyga says as soon as there's a nfs element in the path that needs to be traversed to get to wherever, you sendmsg, and that's blocked
<ogra_> yay, time travellers!
<mup> PR core#36 closed: drop remaining dpkg binary (LP: #1686106) <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core/pull/36>
<zyga> ogra_: ?
<ogra_> zyga, i was commenting on Chipaca's PR comment :)
<jdstrand> the only somewhat approaching reasonable thing we could do is detect if /home is on nfs, if so, add snippets to default policy (with logging) allowing snap-confine to work
<robje> applied workaround in #1662552. now get "Too many levels of symbolic links"
<mup> Bug #1662552: snaps don't work with NFS home <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1662552>
<jdstrand> that's still not great cause if an admin wants a cli command from a snap and doesn't actually need the nfs /home, they still get it
<zyga> robje: that's a symlink loop then
<zyga> jdstrand: hey!
<jdstrand> it would perhaps be possible to have that opt-outtable
<jdstrand> zyga: hey :)
<zyga> jdstrand: are you going to the sprint next week?
<jdstrand> no
<zyga> jdstrand: aha, me neither, I plan to do some cleanups this cycle
<zyga> jdstrand: tests and cleanups
<zyga> jdstrand: all the interface PRs
<jdstrand> cool :)
<zyga> jdstrand: and more interface tests :)
<zyga> mvo: quick question about 17.10
<zyga> + /tmp/go/bin/spread -v autopkgtest:ubuntu-17.10-amd64
<zyga> 2017-04-28 11:09:50 Found /tmp/autopkgtest.vpoFef/build.lb0/snapd/spread.yaml.
<zyga> error: nothing matches provider filter
<zyga> mvo: does this make any sense to you?
<robje> moved $home/snap back to nfs home. now works, THNX
<zyga> it seems ubuntu-17.10-amd64 is not a spread target
<Chipaca> zygaâ tyler and emily are
<jdstrand> zyga: I still have a few sizeable reviews/investigations. hopefully no new ones will come in and I can get back to wayland
<zyga> jdstrand: can you summarize what we need to suppor wayland?
<Chipaca> zygaâ 1. eat humble pie
<zyga> jdstrand: can we "just open it" using unprivileged iface?
<Chipaca> zygaâ 2. more pie?
<zyga> Chipaca: as long as it has strawberries
<zyga> oh, btw, I have plenty of strawberries, home grown, on the terrace :)
<zyga> I need to ask the kids to eat them
<Chipaca> zygaâ are they tart?
<zyga> Chipaca: tart?
<Chipaca> if they're tart, make brexit
<jdstrand> zyga: well, some of this stuff is sprinkled in the forum, is this an official summary or just otoh between you and me?
<Chipaca> zygaâ acidic?
<zyga> Chipaca: no, sweet like crazy :)
<Chipaca> aw, boo
<Chipaca> :-)
<jdstrand> (eg, cause you're curious)
<zyga> Chipaca: if brexit strikes, move here :)
<zyga> jdstrand: beween us
<zyga> jdstrand: I can read the forum too
<zyga> I didn't know there was a thread
<zyga> jdstrand: I'm curious and I'm considering switching to 17.10
<Chipaca> zygaâ http://www.bbc.co.uk/food/recipes/etonmess_81082
<jdstrand> zyga: ok, so so far I've only looked at wayland and gnome-shell. there is one application, ghex that I've been focusing on as the start. the plan is to look at 'calculator-like' things (in terms of application simplicity) for gnome-shell, plasma and sway (all wayland DEs)
<zyga> Chipaca: strawberries :-)~~~
 * zyga nods
<Chipaca> works best when they are tart, to my tastebuds, but then i remembered some of the sweets my polish neighbour gave me and reckoned maybe sweet with extra sugar is more to your taste anyway
<jdstrand> zyga: gnome-shell uses this thing called mutter, which is gnome's compositor (ie, gnome-shell doesn't use weston, it uses mutter)
<zyga> Chipaca: I cannot imagine eating tart strawberries, are they like that because they are grown in cloudy places?
<jdstrand> mutter is not complete yet
<Chipaca> zygaâ different varieties
<zyga> jdstrand: aha, I didn't know mutter is still a thing, I thought all the magic moved to gnome-shell
<jdstrand> for example, mutter requires launching an XWayland for things such as input
<jdstrand> zyga: gnome-shell talks to mutter
<zyga> jdstrand: aha, interesting, so each app has its own xwayland wrapper?
<zyga> jdstrand: or is there one that just runs for whole shell?
<jdstrand> zyga: no. there is one shared Xwayland for all applications
<jdstrand> so, security wise there are a few things
<zyga> jdstrand: and do actual apps see X11 and DISPLAY or is that gone now and xwayland is hidden somehow?
<jdstrand> in terms of input, gnome-shell/mutter/wayland is ok about separating wayland client from each other and from fallback X clients
<jdstrand> because mutter requires X for somethings, all native wayland clients in gnome require X
<jdstrand> this means that native wayland cannot snoop each other, but they can snoop all fallback X clients
<jdstrand> and fallback X clients can all snoop each other
<zyga> jdstrand: but native wayland clients talk to any X parts or is that transparently done using wayland protocols now and X is just in the back as an indirect dep?
<zyga> jdstrand: aha
<jdstrand> native clients don't do anything with X directly
<zyga> jdstrand: well, I guess that depends on how many things are in the latter pool
<jdstrand> this is a mutter thing
<zyga> jdstrand: is a gnome-calculator-like app native now?
<jdstrand> so like ghex won't have the code to snoop on Xwayland clients, but a malicious ghex could and because Xwayland is required, we can't stop that
<zyga> jdstrand: I think that's fine, it's a progression of the concept
<jdstrand> zyga: ghex is the calculator-app I am targeting cause it is in the store
<zyga> jdstrand: over time there will be less of X around
<jdstrand> zyga: for some definition of 'fine'. it is better, but things get worse
<zyga> jdstrand: and if needed, we might think about that X proxy that
<ogra_> heh, high hopes
<zyga> worse?
<jdstrand> (eg, currently the browsers all need Xwayland. the browser is the single most important piece of desktop software, so wayland can sniff browsers)
<jdstrand> I guess epiphany...
<jdstrand> anyhoo
<jdstrand> not worse
<jdstrand> the other thing is the clipboard
<jdstrand> unfortunately, mutter is not handling the clipboard well at all
 * zyga nods
<zyga> heh
<zyga> all the modern software :)
 * zyga hugs all mutter devs
<jdstrand> there is a wayland clipboard, but mutter keeps things in sync (mostly) and it doesn't regulate who can grab the clipboard by focus, like unity8/mir did
<jdstrand> s/did/do/
<ogra_> just make the snapd conflict with all browsers ... problem solved ;)
<ogra_> *the snapd deb
<jdstrand> so, an x client can grab stuff from the clipboard in the background from a native wayland client
<jdstrand> so password managers are safe atm
<jdstrand> mutter could be changed to enforce focus, which is something I am going to be knocking on the desktop team's door about
<jdstrand> but atm, because all native wayland clients on gnome need X cause of mutter, it is basically a shared clipboard
<jdstrand> no worse than X, but that literally is saying nothing :)
<zyga> jdstrand: hehe, I see
<zyga> jdstrand: well
<zyga> jdstrand: little by little
<jdstrand> so, as a whole, it is a step in the right direction, but security-wise, mutter/wayland is not as far along as unity8/mirr
<jdstrand> mir*
<zyga> well
<zyga> maybe mir community will actually make more progress now
<zyga> I wound't be surprised
<ogra_> zyga, you mean with the attempt to port everything to wayland ? :P
<jdstrand> mir could go farther, sure. I don't see gnome porting mutter to mir
<jdstrand> and kde was pretty clear on that point too
<ogra_> (all unity8 community projects work towards having mir on top of wayland now)
<mup> PR snapd#3217 closed: snap: support for snap tasks --last= <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3217>
<zyga> ogra_: no, I mean by having a nice technology stack that has a nice desktop shell on top
<zyga> ogra_: real mir+unity8 (maybe sans the name)
<jdstrand> I'll also note that mutter is not bug free (what is!), but it can be challenging to use
<ogra_> zyga, i know what you mean ... i meant to point out that everyone moves in exactly the other direction
<zyga> ogra_: aha, I didn't know that
<ogra_> making mir a wayland client
 * zyga looks up magic fs 6e736673
<zyga> aha
<zyga> nsfs
<jdstrand> sometimes it gets confused by input events and you'll see stuff splatted out to different ttys on shutdown, and even worse, things like 'alt' and 'ctrl-c' end up going to the wrong place. I think they may have some invisible surface issues
<jdstrand> mutter/wayland has an interesting characteristic of not being able to be restarted (unlike mutter/X)
<jdstrand> so if mutter under wayland dies, your whole session goes *poof* and you login to a fresh new sesson
<jdstrand> ok, so, you are using gnome-terminal and all of a sudden ctrl-c isn't going to it, but somewhere else and your session goes *poof*
<jdstrand> let me tell you. *that* is very annoying
<mvo> zyga: it does, I will add this too
<zyga> mvo: thanks!
 * zyga breaks for quick lunch
<jdstrand> this doesn't happen all the time. I've not been able to reproduce reliably
<jdstrand> I've been running gnome-shell/wayland since before 17.04 release and yes, I'm reporting bugs upstream
<jdstrand> and lastly, I've not looked at plasma or sway yet
<jdstrand> and and lastly lastly, XDG_RUNTIME_DIR is all wrong for wayland and we have to rethink that (there is a forum topic)
<jdstrand> oh, and lastly lastly lastly, when I set everything up correctly to work around XDG_RUNTIME_DIR, gnome apps (ie, ghex) crash as snaps when run under wayland. guessing there is some desktop part stuff that needs to be added
<jdstrand> zyga: so, you asked a question and then left. don't think I didn't notice :P
<jdstrand> but that is my unofficial report as of today
<ogra_> zyga, or mvo, a second checkmark on https://github.com/snapcore/core-build/pull/8 would really be nice
<mup> PR core-build#8: add shellcheck test, fix code for shellcheck <Created by ogra1> <https://github.com/snapcore/core-build/pull/8>
<jdstrand> mvo: hi! btw, you mentioned talking about wayland at the sprint in the forum. did you see my reply in the forum? if you want a more complete (if informal) status, read backscroll here (also ratliff and tyhicks)
<jdstrand> mvo: though, what I said in the forum I think is sufficient for any discussions surrounding discussing wayland at the sprint (ie, backscroll is only if you are interested in excrutiating context, but it is unfiltered and unformatted :)
<mup> PR snapd#3255 opened: tests: set ownership of $PROJECT_PATH for the external backend <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3255>
<morphis_> zyga: spread passed on https://github.com/snapcore/snapd/pull/3222 now, would be nice to get another review
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<zyga> morphis_: ack
<jdstrand> zyga, Chipaca: fyi, https://forum.snapcraft.io/t/snaps-and-nfs-home/438
<Chipaca> heh
<Chipaca> "no NFS here", they say
<Chipaca> âfoo.bar.baz:/share 54G 2.1G 52G 4% /shareâ says mount
<Chipaca> or df is it
<Chipaca> anyway
<Chipaca> ~_~
<Chipaca> funny how these things come in waves
<zyga> jdstrand: niceee!
<zyga> niiiiice
<ogra_> jdstrand, i'm battling with the serial-port interface on the pi3 (for BT) ... but it doesnt get picked up somehow ... http://paste.ubuntu.com/24472828/
<ogra_> any idea why that could be hidden (all the gpio interfaces are listed in snap interfaces)
<jdstrand> ogra_: can you paste the complete yaml?
<ogra_> jdstrand, http://paste.ubuntu.com/24472859/ the inoput is at https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml
<jdstrand> ogra_: and 'snap interfaces' doesn't show pi-bluetooth but does show all those bcm-gpio-# interfaces?
<ogra_> jdstrand, right
<jdstrand> regexp.MustCompile("^/dev/tty(USB|ACM|XRUSB|S|O)[0-9]+$")
<jdstrand> that doesn't have AMA
<jdstrand> ogra_: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port.go#L53
<jdstrand> ogra_: is SanitizeSlot that is checked. You probably have "serial-port path attribute must be a valid device node" in your logs somewhere
<jdstrand> s/is/in/
<ogra_> Apr 28 12:57:00 localhost /usr/lib/snapd/snapd[1243]: task.go:303: DEBUG: 2017-04-28T12:57:00Z INFO snap "pi3" has bad plugs or slots: pi-bluetooth (serial-port path attribute must be a valid device node)
<ogra_> jdstrand, correct ...
<ogra_> and i was battling with gustavo to get some more generic regex there ... boooo
<ogra_> (he denied it)
<ogra_> zyga, ^^^ myth solved ...
<zyga> ogra_: nice
<ogra_> (but thatks for offering help)
<zyga> ogra_: review done
 * ogra_ hugs zyga 
<mup> PR core-build#8 closed: add shellcheck test, fix code for shellcheck <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/8>
<ogra_> and mvo
<ogra_> :)
<mvo> yw
<ogra_> jdstrand, funny ... looking at the code it seems the USB part of it simply accepts any device name, only the raw device code has such a check
<zyga> jdstrand: you may be interested in approving some of the snap-confine spread tests that I didn't port earlier
<jdstrand> ogra_: that's because the path attribute when using usb attributes isn't the same. it is the name of the symlink, not the device the symlink points to.
<ogra_> ah, k
<Chipaca> the PATH
<jdstrand> serialUDevSymlinkPattern is used for those
<Chipaca> the PPAAAATHTHTHHTHHHTHTHT </spittle>
<Chipaca> debian does not have the snippet that lets /snap/bin survive sudo
<ogra_> https://github.com/snapcore/snapd/pull/3256
<mup> PR snapd#3256: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <https://github.com/snapcore/snapd/pull/3256>
<jdstrand> zyga: I'll add to the list, but I already have several other reviews in from of that
<Chipaca> morphis_â
<zyga> jdstrand: no worries, they are not high-priority
<zyga> jdstrand: I just decided to use the next week for things like that
<zyga> Chipaca: ah
<zyga> Chipaca: indeed!
<mup> PR snapd#3256 opened: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <https://github.com/snapcore/snapd/pull/3256>
<zyga> Chipaca: it's good (tm) to test on !ubuntu :)
<zyga> Chipaca: (wait until we get to fedora)
<Chipaca> morphis_â is that a you thing, or is it a somebody else thing?
<zyga> Chipaca: it may not be approved in the end because 9 is frozen and people may nack it in sid
<Chipaca> zygaâ you only say that because it wasn't _your_ morning wasted :-P
<Chipaca> zygaâ https://www.youtube.com/watch?v=wTDUuBWGtpU
<jdstrand> ogra_: I commented
<ogra_> oh, tests ...
<zyga> Chipaca: not wasted, imagine all the happy people using debian that will benefit from _you_ finding this and not them having to find it
 * zyga searches youtube history for an appropriate response
<cwayne> zyga: heya, our fix in edge?
<zyga> cwayne: yes
<zyga> cwayne: in beta
<zyga> cwayne: it's in 2.25 now
<zyga> :-)
<zyga> cwayne: give it a try!
<cwayne> :D
<morphis_> Chipaca: which thing do you mean?
<jdstrand> Trevinho: hey, looking at your PR. how do I apply your patch to a snapcraft build?
<jdstrand> like, what's the proper way to do that?
<cwayne> zyga: yay, calling snaps from snaps seems to work :D :D :D
<zyga> cwayne: wooot :D
<zyga> let's hope it stays that way!
<cwayne> zyga: :)
<cwayne> if it does, I owe you many beers at the next sprint we're both at :)
<zyga> cwayne: I really hope this will ease the work for you guys
<zyga> I think this is the longest patch ever
<cwayne> zyga: it will indeed, well even more so for QA team, we can automate the crap out of testing now :)
<mup> PR snapd#3257 opened: tests: specify the auto-refreshable snap being tested <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3257>
<pstolowski> pedronis, can you have one more look at #3235? i did the simple renaming you requested
<pedronis> pstolowski: in a little bit
 * Pharaoh_Atem sighs
 * kyrofa sighs louder
<Pharaoh_Atem> zyga: welp, apparently I can't take vacations until *at least* June 9th
<Pharaoh_Atem> company mandate
<Pharaoh_Atem> starting from May 22
<Pharaoh_Atem> so no vacation allowed for May 22 - June 8
<zyga> Pharaoh_Atem: hmm hmm
<Pharaoh_Atem> zyga: so if there's a sprint in the first week of June and you guys want me there, I can't be there :(
<zyga> Pharaoh_Atem: add this to the forum, I think nothing is set in stone yet
<Pharaoh_Atem> zyga: done
<zyga> thanks
<pedronis> pstolowski: IÂ looked at it, it seems fine, but not sure whether Gustavo wanted to insist about the other test being done a bit differently
<pstolowski> pedronis, yes, i'm not clear on that either. i don't intend to land this without his +1
<Chipaca> morphis_â compare /etc/sudoers.conf on debian and ubuntu
<Chipaca> morphis_â in ubuntu we added /snap/bin to secure_path
<morphis_> Chipaca: hm, something we should better change
<morphis_> Chipaca: we should talk slangasek and mwhudson about that, they maintain snapd in debian
<ogra_> morphis_, well, it is a patch to ubuntus sudo ... thats nothing snapd can provide ... i fear the chances are rather low that debian would accept this
<morphis_> ogra_: hm
<morphis_> ogra_: what do we loose with not having it?
<ogra_> you need to give the full /snap/bin path when calling snap apps as sudo
<ogra_> the prob is that you cant really append anything to secure_path via a sudoers.d confiig snippet, so the change needs to be in the sudo config itself, cant just be shipped from snapd
<morphis_> hm
<ogra_> so the path really only exists for ubuntus sudo ... not sure if Pharaoh_Atem and zyga found any other way for fedora that you could use in debian
<Pharaoh_Atem> ogra_: since sudoers doesn't allow path expansion, there's no nice way to do it
<Pharaoh_Atem> otherwise we could have a drop in file in fedora that would allow it
<ogra_> Pharaoh_Atem, yeah ... except for the sudo package itself ... i suspected it is the same in fedora
<Pharaoh_Atem> ogra_: yep
<Pharaoh_Atem> sudo is one of those catch-22 programs
<ogra_> well, it is also more security relevant than others ... so in some places hardcoding is a given
<Pharaoh_Atem> I knew about it being an issue from my own testing, but given that classic snaps and so many other things for snappy don't work on Fedora due to no path relocation support for classic confinement, I figured it's fine that you can't sudo a snapped binary
<ogra_> except for a binary that wants sudo :)
<Pharaoh_Atem> but there's no chance of that existing in a snap that expects strict confinement
<jdstrand> kyrofa: I think Trevinho is eow, perhaps you could answer my question to him from earlier? Ie, I'd like to test https://github.com/sergiusens/snapcraft-preload/pull/14, but how do I do that in my snap using snapcraft?
<mup> PR sergiusens/snapcraft-preload#14: preload: don't cut the last char of the redirected path <Created by 3v1n0> <Merged by sergiusens> <https://github.com/sergiusens/snapcraft-preload/pull/14>
<ogra_> indeed there is
<Pharaoh_Atem> what?
<ogra_> we have lots of them
<Pharaoh_Atem> welp, they're broken then
<ogra_> on core ...
<ogra_> nope they arent
<ogra_> if youneed some administrative tool being run by the system user, you use sudo
<kyrofa> jdstrand, using the remote/cloud part (whatever we're calling them these days)
<jdstrand> kyrofa: or more specifically. I need to apply a patch to a part before the build
<kyrofa> jdstrand, oh
<morphis_> Pharaoh_Atem: somehing like sudo /snap/bin/nmcli
<kyrofa> jdstrand, what patch? You mean you want to test out his branch?
<ogra_> yeah
<kyrofa> Or something else?
<ogra_> or the wifi ap setup wizard
<morphis_> Pharaoh_Atem: there are a lot snaps which do that
<Pharaoh_Atem> sure, but none of them are for classic distros
<morphis_> or better said, the snaps don't do that itself
<morphis_> Pharaoh_Atem: ?
<ogra_> even on desktop distros ...
<jdstrand> kyrofa: I can do 'snapcraft' and that'll give me the parts directory and I can find preload.c fine, but I'm not sure the sequence of snapcraft commands to get the parts before building them
<jdstrand> kyrofa: https://github.com/sergiusens/snapcraft-preload/pull/14/commits/0675d4cba6f7cc2df2505d2aad1737a373e469ea
<mup> PR sergiusens/snapcraft-preload#14: preload: don't cut the last char of the redirected path <Created by 3v1n0> <Merged by sergiusens> <https://github.com/sergiusens/snapcraft-preload/pull/14>
<jdstrand> oh, it is merged already
<jdstrand> nm then :)
<kyrofa> jdstrand, yeah just rebuild using the remote part and it'll be picked up
<morphis_> jdstrand: NetworkManager, ModemManager, bluez snaps, all can be used on classic too
<jdstrand> kyrofa: it was still open when I initially asked
<morphis_> jdstrand: sorry, was for Pharaoh_Atem :-)
<kyrofa> Hmm, yeah looks like it was just merged
<jdstrand> kyrofa: anyway, yeah, I know what to do know. I just wasn't sure how to get parts/, patch, then build
<Pharaoh_Atem> morphis_: well, then, they're broken on Fedora
<morphis_> Pharaoh_Atem: we didn't invested much time it making that use case working well yet but there is nothing which prevents you from using them on a classic desktop
<Pharaoh_Atem> nothing I can do about it
<jdstrand> now*
<morphis_> Pharaoh_Atem: why?
<ogra_> Pharaoh_Atem, why ?
<ogra_> lol
<morphis_> :-)
<Pharaoh_Atem> because if they need sudo powers, then I need to get the maintainer of sudo to change sudo
<morphis_> the only thing which is broken that you need to call them with an absolute path when you want to call them with sudo
<Pharaoh_Atem> and he's not going to want to do that unless confinement works for snaps
<kyrofa> jdstrand, but for future reference, try creating a part named the same as the remote part, but don't specify a plugin
<ogra_> Pharaoh_Atem, you cn always call sudo /snap/bin/nmcli
<Pharaoh_Atem> ogra_: right, but you want sudo nmcli to work :P
<ogra_> Pharaoh_Atem, you can just not use sudo binaries without using the full path
<Pharaoh_Atem> not having people call /var/lib/snapd/snap/bin/nmcli
<kyrofa> jdstrand, then you might be able to use the prepare/build/install scriptlets to modify it. That's untested, but I think it'll work
<morphis_> Pharaoh_Atem: true, and that is what we have to fix
<ogra_> Pharaoh_Atem, but the snaps are not broken ... just harder to use
<Pharaoh_Atem> ogra_: the expectation is busted
<Pharaoh_Atem> and that's arguably worse
<ogra_> its a usability issue ...
<jdstrand> kyrofa: interesting
<slangasek> morphis_, Chipaca, ogra_: I don't see any way to get this added without patching the Debian sudo package; with Debian in freeze right now I think this is unlikely to land before release.  We could file a bug on Debian's sudo package, but I wouldn't push on it right now.
<morphis_> slangasek: but would it be generally possible even after the release as a bug fix?
<slangasek> morphis_: as a stable update? almost certainly not
<morphis_> slangasek: ok
<mup> Bug #1687079 opened: cannot change profile for the next exec call: No such file or directory <Snappy:New> <https://launchpad.net/bugs/1687079>
<zyga> re
<Chipaca> yusss! completion branch green again except for artful autosomal tests
<zyga> mvo: hey
<zyga> mvo: still around?
<zyga> mvo: anyway, I corrected #3250
<mup> PR snapd#3256 closed: add ttyAMA0 to allowed devices, needed for pi3 BT <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3256>
<stokachu> Facu: it happened again
<stokachu> Facu: just uploaded beta3 of conjure-up via launchpad and now the stable/candidate channels are not seen
<stokachu> snap info conjure-up
<stokachu> so i dont know what's going on
<stokachu> anyway i can't wait around for you guys i have to try and republish it
<ryebot> I'm trying to push a ppc64le snap with snapcraft, which snapcraft built, but the store isn't accepting the snap, saying "Invalid architecture specified in the manifest: ppc64le"
<nacc> ryebot: shouldn't it be ppc64el for debian/ubuntu ?
<stgraber> ryebot: I suspect the store expects to see "ppc64el" rather than "ppc64le"
<ryebot> fair enough -- any reason snapcraft doesn't seem to care during the build?
<nacc> ryebot: that i don't know :)
<ryebot> +1
<xMudrii> hi everybody!
<ryebot> thanks guys
<xMudrii> can I ask here a question about go plugin for snapcraft?
<xMudrii> anyways - i have snapcraft.yaml that I want to build using snapcraft. i'm planning to use it only for testing (for now) and not for releasing.
<xMudrii> problem is, when I run snapcraft, it tries to fetch golang-1.6 from ubuntu's repo
<xMudrii> can I set path to golang? i want to build it using 1.8.1 not with 1.6
<Facu> stgraber, I see 2.1.15 in stable & candidate
<stgraber> Facu: was that meant for stokachu?
<Facu> stgraber, yes, sorry
<stokachu> Facu: yea me too
<stokachu> Facu: is snap info arch dependant on host?
<Facu> stokachu, IIRC yes
<stokachu> hmm ok
<stokachu> lemme find out what arch they are on
<mup> PR snapd#3250 closed: many: fix tests with go1.8 / artful <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3250>
<cachio> jdstrand, hey, do you know if there is any way to delete an extrauser in ubuntu core?
<jdstrand> cachio: iirc, deluser doesn't undestand --extrauser yet (this is a foundations thing)
<jdstrand> cachio: you'd have to modify the files directly
<cachio> jdstrand, you mean make the deletion manually
<cachio> ?
<jdstrand> cachio: yes
<jdstrand> cachio: in /var/lib/extrausers/
<jdstrand> cachio: I'm eow and need to step away, but I'll check backscroll if you have other questions
<cachio> jdstrand, sure, thanks
<cachio> nice weekend
#snappy 2017-04-29
<mup> PR snapcraft#1290 closed: tests: refactor tests with build and stage packages <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1290>
<slangasek> could anyone here clue me in to why https://launchpad.net/~canonical-foundations/+snap/ubuntu-image/ is failing to upload to the edge channel in the store? I don't see anywhere in the LP interface that it specifies credentials to use for the upload
<mup> PR snapcraft#1285 closed: kernel plugin: learn how to assemble the ubuntu config using kconfigflavour <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1285>
<mup> PR snapcraft#1282 closed: parts: remove the deprecated snap keyword from the internal parts representation <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1282>
<mup> PR snapcraft#1168 closed: sources: add support for 7-zip files <Created by tim-sueberkrueb> <https://github.com/snapcore/snapcraft/pull/1168>
<mup> PR snapcraft#1291 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1291>
<cjwatson> slangasek: it might have been authorised by a team member who no longer has access.  Go to https://launchpad.net/~canonical-foundations/+snap/ubuntu-image/+authorize to reauth it
<bipul> C-a C-n
<bipul> I would like to know the SHA-1 Key for Ubuntu Core 16 image for Raspberry Pi 3
<ogra_> bipul, see http://releases.ubuntu.com/ubuntu-core/16/ for the stable images ... http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ for dailies from the edge channel ... there are SHA1SUM files
<bipul> ogra_: Thank you very much.
<bipul> Well i think i need to download a new fresh one formy Pi :)
<bipul> idk why my SHA1SUM is not matching with http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/SHA1SUM
<bipul> e3be4c09781f0d4d9b3832e7c24ed7e71944836d  ubuntu-core-16-pi3.img.xz
<bipul> is that fine? shall i install it?
<bipul> I have downloaded it from http://releases.ubuntu.com/ubuntu-core/16/
<ogra_> bipul, there is a separate SHA1SUM under http://releases.ubuntu.com/ubuntu-core/16/
<ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily-stable/current/SHA1SUM only matches for the images in that dir
<bipul> ogra_: Oh  Thank you once again to make it clear
<crabby> hello
<bipul> I have installed snappy now It's asking for Login and Password. I don't know what to do?
<bipul> I am installing*
<bipul> I just need a small help.
<bipul> When i am trying to login during installation time, it says "localhost login" I don't know what to type. I tried with my launchapd user id, still not working
<bipul> exiyt
<bipul> Well, thank's i got it
<slangasek> cjwatson: indeed, that was the case, but I didn't see anything in the UI about authorization - thanks
<mup> PR snapcraft#1292 opened: tests: fix the recording tests to work in multiple architectures <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1292>
#snappy 2017-04-30
<chatter29> hey guys
<chatter29> allah is doing
<chatter29> sun is not doing allah is doing
<chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
<mup> PR snapcraft#1293 opened: recording: record stage packages installed in the snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1293>
#snappy 2018-04-23
<mborzecki> morning
<zyga> good morning!
<Son_Goku> gah
<Son_Goku> why am I still awake...
<mborzecki> zyga: hey
<zyga> Hey
<zyga> Itâs much colder today
<mborzecki> zyga: and expecting rain in the afternoon as well
<zyga> Yeah, the âsummerâ is over
<zyga> Afk, walk
<mborzecki> i have #5073 open, but it's failing on linode, specifically ubuntu-16.04-32 and opensuse-42.2, looks like the linode images are gone and they do not boot anymore
<mup> PR #5073: set up journal streams in user session application autostart (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5073>
<mborzecki> master is using gce
<mborzecki> according to travis relase/2.32 branch is failing
<zyga> Hmmm
<zyga> Did we drop lindoe already?
<mborzecki> it looks like that only some images were dropped
<mborzecki> 16.04-32 and openssue, this is what's failing
<mborzecki> zyga: see the dial timeouts https://api.travis-ci.org/v3/job/368660863/log.txt
<mborzecki> and it keeps repeating
<zyga> Hmmm
<mborzecki> i've restarted 5073 numerous times now
<kalikiana> moin moin
<pstolowski> morning
<zyga> back from walk
<mborzecki> kalikiana: pstolowski: hey
<mborzecki> pstolowski: trivial review https://github.com/snapcore/snapd/pull/5078 :)
<mup> PR #5078: interfaces/builtin, daemon: cleanup mocked builtin interfaces in daemon tests <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5078>
<mborzecki> pstolowski: ta
<mup> PR snapd#5078 closed: interfaces/builtin, daemon: cleanup mocked builtin interfaces in daemon tests <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5078>
<Chipaca> mo'in all
<Chipaca> mborzecki: what am I missing for a +1 from you on #5066?
<mup> PR #5066: overlord/snapshotstate/backend: introducing the snapshot backend <Created by chipaca> <https://github.com/snapcore/snapd/pull/5066>
<pstolowski> morning Chipaca
<mborzecki> Chipaca: i'll go over it again once i'm done with the watchdog, iirc i left some more comments, but those might have been for the overlord pieces that were later pulled
 * zyga is stuck on the apparmor issue :/
<Chipaca> zyga: stuck how?
<zyga> there's something wrong with my logic but I cannot see it yet
 * zyga tries to summarise the problem
<zyga> when pawel tried to use a layout that had deep directory like /usr/a/b/c/d
<zyga> things were broken because our permissions were too strict and prevent us from making /usr writable
<zyga> I fixed that
<zyga> now what I find is that we make /usr writable but things subsequently fail to create /usr/a/b/c/d in a way I don't understand
<zyga> it seems that after making most of that path we end up with EROFS
<zyga> but.. how?
<zyga> http://paste.ubuntu.com/p/h8QkcWWQSy/
<zyga> on line 1120 we are done with making /bin writable
<zyga> (after writing a loot of things to a tmpfs mounted over /bin
<zyga> now on line 1141 we fail with EROFS
<Chipaca> is it meant to be mounting everything in /bin ?
<zyga> yes
<Chipaca> or is that just your test
<zyga> we re-create /bin in a writable place
<zyga> this is the writable mimic logic
<zyga> rbind /bin -> /tmp/.snap/bin
<zyga> mount -t tmpfs none /bin
<zyga> touch /bin/a && mount --bind /tmp/.snap/bin/a /bin/a
<zyga> (then all the way till we "mimic" everything over
<zyga> then mount /tmp/.snap/bin to clean up
<zyga> this works so far
<zyga> what is odd is next we try to mkdir /bin/very/weird/place
<zyga> and this works by opening / then /bin/ then /bin/very/ and so on
<zyga> (mkdirat'ing them as we go)
<zyga> owowow
<zyga> MAN
<zyga> how did I miss this
<Chipaca> zyga: because you don't have a sock puppet to talk to
<zyga> the error is for /snap/test-snapd-layout/x1/bin/very/weird/place
<zyga> not for /bin/very/weird/place
<zyga> the bug is completely different!!!
 * zyga is dumb
 * zyga hugs Chipaca 
<zyga> thank you John
 * Chipaca tries to make his eyes wobble like a good sock puppet would
<zyga> I see what the problem is now
<zyga> it's my silly test
<zyga> the bug is fixed now
 * zyga wonders if there's an emoji for <man holding hand on forehead>
<Chipaca> zyga: U+1F926
<Chipaca> zyga: (not quite, but close enough imo)
<zyga> haha, thank you :-)
<zyga> this will be my motto of the day
<zyga> I was looking at this issue all Friday :/
<Chipaca> zyga: unicode 9 so not in xenial Â¯\_(ã)_/Â¯
<zyga> fixed, fingers crossed
<mup> PR snapcraft#2095 opened: lxd: proper error classes for container errors <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2095>
<jamesh> zyga: so, is there anything that needs to be done before https://github.com/snapcore/snapd/pull/3963 can be merged?
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<jamesh> it got a tick from jdstrand
<zyga> I asked mborzecki or Chipaca to have a quick look just in case we missed something
<zyga> but otherwise no
<popeycore> grrr. installing a snap blew my x session up again :|
<zyga> I plan to merge it today
<popeycore> it blows up just at the point when it prints that its connecting the opengl interface
<jamesh> zyga: cool.  As written, it should have no effect when there isn't a .user-fstab file for a snap
<popeycore> Wimpress: getting coffee while my machine updates/reboots. back shortly :)
<Wimpress> popeycore: OK.
<mborzecki> any clue why NOTIFY_SOCKET set by system is @/org/freedesktop/systemd1/no
<mborzecki> tify/3197004134137770178 on 14.04?
<zyga> mborzecki: what is is normally?
<mborzecki> zyga: /run/systemd/notify
<zyga> 14.04 has older systemd, maybe that just was the thing at the time
<mborzecki> hmm service-watchdog assumed that the communication happens on a unix socket with filesystem path, not an abstract one
<mborzecki> then apparmor rules probably need to change too
<zyga> hmm
<zyga> apparmor_parser spins at 99%CPU
<mborzecki> zyga: does `unix (connect, receive, send) type=stream peer=(label=unconfined,addr="@/org/freedesktop/systemd1/notify*")` look ok to you?
<zyga> I think that's nog great
<zyga> mborzecki: yes though I honestly don't recall the syntax
<zyga> don't forget the trailing ,
<mborzecki> aah
<mborzecki> thx
 * Chipaca goes to see a man about a dog^W^W my back
<zyga> https://github.com/bartzaalberg/snaptastic
<zyga> interesting
 * zyga wrote a profile that makes apparmor_parser run for a very very long time
<popey> diddledan: fyi, i am backing up and deletingr repos from snapcrafters that are broken / never been published
<diddledan> right-oh - any I should take a look at to get working?
<popey> I put them in dropbox snapcrafters_deleted
<diddledan> coolbeans
<popey> the only one that would be nice to fix is wire
<diddledan> yup
<popey> it crashes, not looked at it for a while
<diddledan> it might be fixed by the work jdstrand did on converting seccomp kills to EPERMs
<popey> possibly, yes.
<diddledan> also the electron/chrome-style peer to peer thingy works now
<diddledan> (which fixed webtorrent!)
<popey> yay
<diddledan> not many files then : "Alan Pope just added 365 files"...
<diddledan> https://usercontent.irccloud-cdn.com/file/iybhSeuM/image.png
<mborzecki> zyga: intersting, 14.04 manpage for systemd mentions /run/systemd/notify as notification socket, yet snapd got something else
<popey> :D soz
<zyga> mborzecki: hmm
<zyga> dunno :)
<mborzecki> heh and /run/systemd/notify is not there in the system
<pedronis> the systemd enablement in 14.04 was a bit of  an adventure, not sure the manpages were updated
<zyga> so I can get my apparmor changes to work
<zyga> but with some manual tweaking
<zyga> there's something wrong with an expression apparently
<mup> PR snapcraft#2096 opened: tests: don't use os_release and repo from snapcraft <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2096>
<mborzecki> runnig systemd spread again, hopefully all of it works this time
<mborzecki> s/systemd/watchdog/
<mborzecki> also tiny default in Result property of services, when killed by watchdog i've seen it to be signal, or watchdog (recent sytemd) or core-dump (since it got SIGABRT)
<zyga> OMG
<zyga> so weird
<zyga> I mean
<zyga> apparmor parser and apparmor
<zyga> ok, fixed one more thing and running spread
<zyga> * matches files but not directories
<zyga> so to match anything in the /some/path
<zyga> you need /some/path/{*,*/}
<zyga> weird, huh?
<zyga> ** matches anything at all so it will match /some/path/dir/evil
<zyga> mborzecki, Chipaca: can you please review the user mounts PR, it is the oldest one around
<zyga> I'd like to land it but I think it deserves one more look
<cjwatson> ~/wg 54
<cjwatson> sorry
<mborzecki> hmm NOTIFY_SOCKET on ubuntu-14.04 changes with each reboot, @/org/freedesktop/systemd1/notify/13334051644891137417, the last element looks like a timestamp, meaning we cannot just put the path in apparmor rule :/
<zyga> well
<zyga> we can just put @/org/freedesktop/systemd1/notify/*
<zyga> ,
<mborzecki> yeah, just have the fact that it becomes a special case
<Kone> Hi, can someone explain/link how i can set start parameters for an app that is installed as a snap-package?
<mup> PR snapd#5079 opened: tests: update the bionic image to the latest one uploaded <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5079>
<mborzecki> well, ubuntu 14.04 systemd watchdog does not appear to work at all
<zyga> mborzecki: maybe it is compiled out partially?
<mborzecki> no clue, the service is not pinging systemd and it's not getting killed
 * cachio afk
<mborzecki> fwiw it works on 16.04+
<jdstrand> if the systemd-notify denial is @/org/freedesktop/systemd1/notify/13334051644891137417, you'll need a unix rule for that. eg: unix (receive, send) type=??? peer=(addr=@/org/freedesktop/systemd1/notify/[0-9]&, label=unconfined),
<jdstrand> err
<zyga> type=???
<jdstrand> ...addr=@/org/freedesktop/systemd1/notify/[0-9]*...
<jdstrand> I was going to say, I don't have the whole denial so can't say what it should be exactly
<jdstrand> I suspect type=stream, but I don't know
<zyga> ah, I get it now
<zyga> jdstrand: btw, I got that apparmor thing to work
<zyga> from last week
<zyga> just iterating to simplify now
<zyga> with spread passing and everything
<jdstrand> zyga: as for your CPU pegging profile, perhaps file a bug and try to write a rule that works better
<zyga> it was missing no-simplify-expr
<zyga> it's sad that is on
<zyga> it's pretty much broken IMO
<jdstrand> zyga: aiui, its utility is profile dependent. idr the details, but jjohansen would
<jdstrand> zyga: please test the rule on armhf though
<jdstrand> s/rule/profile/
<zyga> jdstrand: ack, will do
<jdstrand> zyga: we shouldn't have to worry about the performance of certain rules, but the reality is that some things compile faster than others
<zyga> the current profile compiles very quickly but I will test it on arm as well
<mup> PR snapd#5080 opened: many: support 'system' nickname in interfaces <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5080>
<mborzecki> off to pick up the kids from school
<mborzecki> jdstrand: i've updated the interface in https://github.com/snapcore/snapd/pull/4504/commits/6206e555fdbcd94680aa98103cc1aa50b120b840
<mup> PR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<zyga> jdstrand: hey, I published working fix for the apparmor + layouts issue from last week https://github.com/snapcore/snapd/pull/5074
<mup> PR #5074: many: allow mimics in parents of layout <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
<zyga> jdstrand: I marked the branch as blocked so please don't review it
<zyga> jdstrand: I will split it into a smaller chunk that I will ask you to review
<zyga> jdstrand: I also simplified the "xmas tree" code into a useful generic function that splits a path into read/write rules
 * zyga loves this week (starts well)
<zyga> but hates this evening (rain for the rest of the week starts today)
<zyga> no more biking :(
<zyga> biking in the rain when it is cold is an acquired taste I lack
<mup> PR snapcraft#2097 opened: packaging: include changelog for setup.py's version detection <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2097>
<mup> PR snapcraft#2098 opened: lxd: wait for on-going refreshes to finish <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2098>
<mup> Issue snapcraft#2099 opened: Issues building snap from my favorite and best GUI RSS reader, Feedreader <Created by sirredbeard> <https://github.com/snapcore/snapcraft/issue/2099>
<ads20000> Wimpress: could you get in touch with Discord about this (I think that's the right action here)? :) https://forum.snapcraft.io/t/discord-ptrace-apparmor-denials/5099/5?u=ads20000
<ads20000> or popey
<matlock> sergiusens I tried your advice on my snapcraft post, didn't sort it out, and then the forum blocked my post for spam for linking to github, so here is the status of the issue https://github.com/snapcore/snapcraft/issues/2099
<matlock> sergiusens I am running into 3 different issues trying 3 different approaches to build this snap, you suggested I just let cmake plugin handle everything, but if you will see #1 of my issues is that cmake is not properly handling nested cmake builds, thanks in advance for your assistance
<zyga> jdstrand: the chop tree PR: https://github.com/snapcore/snapd/pull/5081
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<mup> PR snapd#5081 opened: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<Chipaca> pedronis: niemeyer: #1766248 fwiw
<mup> Bug #1766248: snap install fails with 'cannot update disabled snap "core"' after 'snap refresh core' <snapd:New> <https://launchpad.net/bugs/1766248>
<cpaelzer> where would I look for snap install logs?
<cpaelzer> we are looking at a case wondereing why the install hooks did not run
<cpaelzer> Saviq: ^^ that is for the libvirt.conf in multipass
<kyrofa> cpaelzer, `snap changes` and `snap change` is the best I know of
<Saviq> cpaelzer: `snap change --last=install` has Â«Run install hook of "multipass" snap if presentÂ» here
<Saviq> nothing more
<Chipaca> kyrofa: Saviq: 'snap change' is an alias of 'snap tasks' fwiw
<kyrofa> Chipaca, i.e. snap tasks is the newer, shinier one?
<kyrofa> Is there also a `snap task`?
<Chipaca> kyrofa: we thought it better reflected what the thing does, yeah
<Chipaca> kyrofa: NO.
<kyrofa> Hahaha
<Saviq> cpaelzer: mystery solved - install hook only runs on (d'uh) installs - not refreshes
<cpaelzer> yep
<cpaelzer> that matches what I just posted to the forum
<cpaelzer> soemthing you can resolve on the next version
<cpaelzer> glad I could help to spot that
<cpaelzer> Saviq: thanks
<Saviq> yup, will be fixed before we release
<Saviq> cpaelzer: thanks!
<ogra_> hmm
<ogra_> https://forum.snapcraft.io/t/notepadqq-classic-confinement-request/5024
<ogra_> does "snap install --classic" for a strict confined snap suddenly turn it into a classic snap ?
<ogra_> or is that guy seeing a bug ?
 * ogra_ thought that wasnt possible at all 
<Chipaca> ogra_: you can install strict snaps with --classic
<cachio> niemeyer, hey, so I need a # SPREAD_GOOGLE_KEY to add to the .travis.yml for the spread-cron branches
<Chipaca> ogra_: if your snap is built appropriately, it'll even work
<cachio> niemeyer, not sure if this is the only one think we need
<cachio> and the other issue that you mention is already fixed
<cachio> the issue with the elopio keys that were deprecated on travis
<niemeyer> cachio: Ack
<jjohansen> zyga: yes simpify-expr is sub-optimal and needs to be rewritten, but on average it actually sitll improves most compiles. It isn't so important any more as other parts of the pipeline have been rewritten.
<jjohansen> Fixing it is on the long to do list, it just always seems there are other more important things
<zyga> jjohansen: I'd say it should be off by default, I haven't read the source to say what it does but it was spinning for 10m+ on my beefy box
<jjohansen> zyga: I haven't seen it do that
<jjohansen> can you shoot me the profile that triggered it
<zyga> yes, let me re-create it
<mup> PR snapcraft#2100 opened: build_providers: new build provider using multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2100>
<zyga> jjohansen: http://paste.ubuntu.com/p/hPcBjdnSwd/
<Facu> question, if I install a snap as "classic", the process runing from it should be able to see the whole system, right?
<nacc> Facu: yes
<zyga> Facu: yes
<Facu> nacc, zyga, it's strange... with sparkiegeek we're seeing that Pythons inside the snap are "installed" in a way that don't have access to system libraries... http://linkode.org/#iWFk2Akf4EU6owgbpH4hu1
<zyga> Facu: what I mean is that there's no confinement preventing that, what happens is that for classic snaps the PATH (or PYTHONPATH) is probably altered by snapcraft itself (snapd doesn't touch that) so the snaps "prefers" to see the things it shipped.
<zyga> As classic snap can always see what is on the system if it wants to
<nacc> Facu: right, you should check the PYTHONPATH from the snapped python
<nacc> Facu: and e.g., you might need to munge the environment if you need access to the 'host' env
<Facu> nacc, how can I check that?
<Facu> nacc, it's something in the installed snap, or in snapcraft when being built?
<nacc> Facu: something like `snap run --shell <snap>; python (or python3).` And at the interpreter, examimen sys.path ?
<nacc> Facu: both :)
<nacc> Facu: so you're a classic snap that wants to use python package from the host?
<Facu> zyga, nacc, this "the snap prefer to see the things it shipped" may be useful for snapping apps done in Python, not so much for Python itself (as it's the case of pypy3) or fades, whose purpose is automate virtualenv usage
<Facu> nacc, yeap
<zyga> Facu: my point is that snapd doesn't touch that
<zyga> it's snapcraft or the snap that needs to be investigated
<zyga> snapd doesn't constrain anything
<zyga> or doesn't change PATH
<nacc> Facu: right, what zyga is saying
<Facu> zyga, perfect! now I'm trying to understand how to fix this :)
<zyga> Facu: look at the generated launcher inside your prime/ directory
<zyga> it probably sets some environment
<nacc> Facu: so it's by virtue of how snaps are built, that results in their runtime behavior
<sparkiegeek> Facu: I think it's gonna need some twisting and poking of snapcraft to e.g. ditch the wrapper
<nacc> Facu: so, tbh, we build our own python in our snap -- because you get xenial's python of course, in all envs. Which may or may not work in all host envs.
<nacc> Facu: and because of things like you're seeing :)
<zyga> AFAIR there's an option to disable the wrappers
<zyga> but perhaps I'm wrong
<zyga> I rarely use snapcraft and typically construct my test snaps by hand
<nacc> but zyga is special that way :)
<nacc> and seems to not be dogfooding :-P
<zyga> well
<Facu> jajaja
<zyga> I'm dogfooding things snapcraft doesn't support yet :)
<zyga> but yeah
<nacc> heh
<zyga> I actually would like a simpler snapcraft
<zyga> that is less magic now
<zyga> but that's a story for another day
<nacc> zyga: +100
<nacc> zyga: it's 'smarter' now, but that has made it more fragile, it seems (and it's hard to know, IMO, what is changing each release from a snap owner perspective)
<Facu> zyga, with "generated launcher inside prime dir" you meant this exec? prime/command-fades.wrapper
<nacc> Facu: yeah, i think so
<Facu> exec "$SNAP/usr/bin/python3" "$SNAP/bin/fades" "$@"
<Facu> no PATH mangling
<zyga> can you run snap run --shell that thing
<zyga> and explore $PATH and $PYTHONPATH
<nacc> that implies there'
<zyga> and run your $SNAP/usr/bin/python3
<zyga> and explore that too
<nacc> *there's a python3 in your snap, separate from the one in the core snap?
<zyga> if you are building python from source it is doing one more thing
<nacc> Facu: are you ?
<zyga> when prefix is set to /foo it doesn't look in /usr
<zyga> just into /foo
<zyga> so that may be a side effect of your build
<nacc> yeah, that's something we have done in git-ubuntu (on purpose)
<Facu> nacc, I don't put (on purpose at least) a different python in my snap... what I'm packaging is just a lib/script that needs Python to run
<Facu> it has a     plugin: python
<Facu> (because it needs Python to be run, right?)
<nacc> oh maybe the plugin pulls it in; but i thought it didn't ...
<nacc> Facu: i thought it used the core snap's python (again, i might be wrong)
<Facu> nacc, it would be great if I can get that! the snap itself (the binary) will be much smaller
<sparkiegeek> Facu: FTR, using the python inside the snap, from that wrapper, then manually adding /usr/lib/python3/dist-packages to sys.path does the right thing
<nacc> sparkiegeek: right, that makes sense
<nacc> sparkiegeek: i assume your code is defensive enough for when an expected dist-package is not present, btw ? :)
<sparkiegeek> Facu, nacc: AIUI the python plugin always ships its own python because of the shenanigans that it does to Python to get the import path right
<Facu> zyga, nacc, I'm not sure how to use "snap run --shell"
<nacc> sparkiegeek: ah ... that could be
<nacc> sparkiegeek: it did not, at some point :)
<nacc> Facu: if you ran it, `snap run --shell <snap name>`
<sparkiegeek> Facu: snap run --shell fades
<nacc> it will put in a shell that is the same environemnt as your snap runs in
<nacc> `env | grep SNAP` to see what is set
<nacc> cd $SNAP to switch to the snap''s directory, etc.
<Facu> it doesn't, just ends
<nacc> Facu: what doesn't, what ends?
<nacc> Facu: the shell won't say anything
<nacc> Facu: it literally spawned a new shell process
<zyga> are you inside the snap run --shell shell by any chance?
<Facu> oh!
<Facu> no prompt change or anything?
<nacc> Facu: right :)
<Facu> pff
<zyga> I think we tried but it was not working well
<zyga> or is not in stable yet
<zyga> I forgot
<nacc> yeah, it's not something that is easy to do, in some sense, because what the prompt will be is sensitive to the snap's env now
<sparkiegeek> well, you might have a classic snap that wants to do something with $PS1 :)
<nacc> right
<nacc> or even to what 'bash' is :)
<Facu> nacc, zyga, snap env: http://linkode.org/#Txhr9JNzC4iueywyfA3bx3
<nacc> Facu: what is sys.path by default (run `python3` then import sys\nprint(sys.env) or so
<nacc> Facu: from what i can tell it's what sparkiegeek already said, though, the system paths are not in PYTHONPATH (sys.path at runtime)
<sparkiegeek> $ $SNAP/usr/bin/python3 -c 'import site; print(site.PREFIXES)'
<sparkiegeek> ['/snap/fades/169/usr', '/snap/fades/169/usr']
<sparkiegeek> I think that's the key point
<Facu> being inside the snap shell (confirmed) it looks that python3 is from the system?
<Facu> $ which python3
<sparkiegeek> Facu: $SNAP/usr/bin/python3 is what the wrapper uses
<nacc> Facu: right, so PATH isn't changed for classic snaps (iirc)
<nacc> Facu: unless you manually change it
<Facu> sparkiegeek, nacc, this looks like the responsible: SNAP/usr/lib/python3.5/sitecustomize.py
<Facu> forgot the $
 * sparkiegeek nods
<sparkiegeek> sergiusens: ^ that's deliberate right?
 * zyga -> break
<nacc> sparkiegeek: Facu: so what we do in our yaml is in the environment: field for the app, we set PYTHONPATH to something specific (in our case, internal to the snap). You could just as easily set it to something outside the snap, e.g. the host's python env)
<nacc> sparkiegeek: but i believe you are right, that is a deliberate thing (not 100%, i'm not a snapcraft developer :)
<sparkiegeek> nacc: trying to determine the target host's python env at "compile"-time is fraught with error though  :)
<Facu> nacc, but me, as a developer doing stuff in snapcraft, I don't know the host's python env for the all users running my snap
<nacc> you can do, iirc
<nacc> ORIG_PYTHONPATH: "$PYTHONPATH"
<nacc> in your environemnt yaml
<nacc> then you'd need to have your own wrapper
<nacc> now, i'm not sure if that's actually necessary, i'd wait for sergiusens :)
<nacc> but i believe it would work
<sparkiegeek> right, but once you go for 'have your own wrapper', the whole problem goes away AFAICS
<sergiusens_> sparkiegeek: not following, what is deliberate, using sitecustomize instead of PYTHONPATH? If that is the question, yes; there are multiple reasons, one is, using a staged python to build other parts, another a python application calling into another python application
<nacc> sparkiegeek: yeah :)
<mup> PR snapd#5079 closed: tests: update the bionic image to the latest one uploaded <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5079>
<sergiusens_> like snapcraft being a python application, if PYTHONPATH were set and we called into bzr (which is also python2) a mess will occur
<Facu> sergiusens_, we may have wandered badly around the original problem, maybe you have another POV on the original problem and may focus us better
<sparkiegeek> sergiusens_: basically the issue we're seeing is that a classic snap is not using the system python interpreter, and doesn't have the system python's environment
<Facu> sparkiegeek, which, written that way, may be a feature :/
<sparkiegeek> Facu: well... *classic*
<sparkiegeek> sergiusens: so Facu makes 'fades' which allows you to maintain virtualenvs. It has a --system-site-packages flag, which is broken, because the 'system' that it's seeing is the one inside the snap, which ain't all that helpful
<sergiusens> sparkiegeek: oh, yeah, the python plugin is meant to use an in_snap python; you'd need to roll your own for other things, then again, just `dump`
<Facu> sergiusens, "dump"?
<sergiusens> what if I `apt purge python`? will fades work?
<sparkiegeek> Facu: https://docs.snapcraft.io/reference/plugins/dump
<sergiusens> Facu: and  https://docs.snapcraft.io/build-snaps/pre-built
<zyga> pstolowski: I found one more interesting bug in layouts thanks to you. :-) we donât preserve permissions on directories mimicked as writable
<zyga> And some software complains when certain things get world writable
<zyga> I will fix it next
<Facu> sergiusens, sparkiegeek, ubuntu core already brings a Python, right? it's Py 3? does it have access to system's libs? may I use *that* from the snap?
<sergiusens> Facu: yes, you can, but not if it is classic as there will be ABI breakages when using that on a newer system such as 18.04
<Facu> sergiusens, well, I should leave "classicness" at some point
<sparkiegeek> Facu, sergiusens: right - that, plus it has similar issues
<sparkiegeek> ['', '/snap/core/current/usr/lib/python35.zip', '/snap/core/current/usr/lib/python3.5', '/snap/core/current/usr/lib/python3.5/plat-x86_64-linux-gnu', '/snap/core/current/usr/lib/python3.5/lib-dynload', '/snap/core/current/usr/local/lib/python3.5/dist-packages', '/snap/core/current/usr/lib/python3/dist-packages']
<sergiusens> it should have the same issues with different paths
<sparkiegeek> that's sys.path from the python in core
<sparkiegeek> sergiusens: indeed
<sparkiegeek> I mean, that's expected
<Facu> sparkiegeek, I'm not sure if we have a clean good solution for this :/
<Facu> sparkiegeek, not even a reasonable hack
<Facu> sparkiegeek, it will be great if there's a workaround a user (you) could do
<sparkiegeek> Facu: well I think nacc's suggestion of ORIG_PYTHONPATH might be reasonable
<nacc> sparkiegeek: Facu: the advantage of it is that it makes some sense that only the snap-generator knows about this nuance, and then the app wrapper itself
<Facu> sparkiegeek, but my PYTHONPATH doesn't include system libs
<nacc> oh it's your sys.path in the host environment, probably
<sparkiegeek> Facu: sure, I mean it doesn't *have* to be exactly like that but could be something like ' run python from the host, grab it's sys.path, add them to the one inside the snap'
<nacc> so your wrapper, could, technically do what sparkiegeek is suggesting
<Facu> sparkiegeek, and that at "snap install" time, right?
<sparkiegeek> Facu: no, that would be a wrapper for the command, which then invokes fades
<Facu> ah, everytime it runs?
<sparkiegeek> yes
<nacc> Facu: right it's part of your (snapped) app's definition
<nacc> which in this case, I think, makes sense
<nacc> and your app code wouldn't need to change at all, hopefully, as it's all in the yaml and the wrapper
<Facu> nacc, sparkiegeek, something like the following? export PYTHONPATH=`python3 -c "import sys, os; print(os.pathsep.join(path for path in sys.path if path.startswith('/usr')))"`
<nacc> Facu: why do you only want what is in /usr ?
<nacc> Facu: e.g., what if user is using some special python installation by default
<Facu> nacc, makes sense; I should just filter out the empty one
<nacc> Facu: yeah, i think that's sensible
<kyrofa> zyga, if I install a snap and get "error: cannot install snap file: snap is unusable due to missing files; contact developer"
<kyrofa> zyga, is there a way for me to determine what exactly is missing?
<zyga> Yes
<zyga> Just apps are inspected
<kyrofa> zyga, oh, it was seeing if the app actually exists?
<zyga> I think there is some more places where you can run a command and see
<zyga> But Iâm AFK now, chipaca would know
<zyga> Check your declared app command
<kyrofa> zyga, yep, that was it, thank you! Some nice feedback in that error (what the actual issue is) would be helpful
<mup> PR snapcraft#2101 opened: errors: implement an always option to send to sentry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2101>
<Facu> sergiusens, nacc, sparkiegeek, do you know about any doc to how provide wrapper changes/replacement?
<nacc> Facu: i did it with trial and error, but basiclaly in your app defintion, you chang ethe command: to point at some script you install into your snap
<Facu> nacc, currently the "command" points to a Python script called "bin/fades"... it looks it's building the wrapper around that... you say that if I change it to "bin/fades_wrapper_for_snaps.sh" it will not build a wrapper around it?
 * Facu tries
<nacc> Facu: well, it will, but the wrapper will call your script
<nacc> Facu: (iirc) -- and then your script calls bin/fades
<Facu> nacc, snapcraft crashes badly :/  http://linkode.org/#5b4uN7fV4HG2rbCTBkxtU3
<nacc> Facu: you have to be careful
<nacc> 'python3' in your snap wrapper is running in the context of the snap
<nacc> ah that's one reason not to do it in the wrapper i suppose
<Facu> nacc, what if I do /usr/bin/python3
<Facu> ?
<nacc> Facu: right, i'd try that
<Facu> in any case, you say that's why it crashes now?
<nacc> Facu: i'm not sure :/ -- but i'd use absolute paths for everything in your wrapper
<Facu> absolute path fixed, snapcraft still crashing
<nacc> Facu: hrm, it seems to think there is no pip installed in the part
<nacc> (iiuc)
<pstolowski> zyga: wow, amazing....
<niemeyer> Chipaca: #5066 finally reviewed..
<mup> PR #5066: overlord/snapshotstate/backend: introducing the snapshot backend <Created by chipaca> <https://github.com/snapcore/snapd/pull/5066>
<Facu> mmm... snapcraft just crashes, without any change in the project
<nacc> Facu: i was going to ask that next
<Facu> ja! my bad! I was using it where I played with PYTHONPATH
<nacc> Facu: :)
 * Facu slappes himself
<Chipaca> kyrofa: hello
<Chipaca> kyrofa: I'm past my EOD, but, when you get that 'cannot be installed' thing, the log will have the details
<Chipaca> kyrofa: the 'journalctl -u snapd' log
<kyrofa> Chipaca, ah, good to know, okay, thank you :)
<Chipaca> kyrofa: it's not just the apps
<Chipaca> it also checks that all of meta is sane
<Chipaca> (and things that count as 'not sane' include vim scratch files for example)
<Chipaca> kyrofa: let me know what you find
<mup> PR snapcraft#2102 opened: tests: use a common cache for the integration tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2102>
<mup> PR snapcraft#2103 opened: package: make use of snapcraftctl snapcraft features <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2103>
<mup> PR snapcraft#2097 closed: packaging: include changelog for setup.py's version detection <bug> <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2097>
#snappy 2018-04-24
<mup> Issue snapcraft#1982 closed: Update snaps_tests to use the testing tools from tests.integration <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1982>
<mup> PR snapcraft#2096 closed: tests: don't use os_release and repo from snapcraft <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2096>
<mup> PR snapd#5082 opened: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
<mborzecki> morning
<zyga> Good morning
<zyga> Man, after all the rain last night the plants and flowers outside smell like in some deep forest :-)
<zyga> Only if it was a few degrees warmer
<zyga> How are you doing?
<mborzecki> zyga: it's spring after all :) but yeah everything is in the crazy growth phase, i expect i'll be less than entertained when mowing the lawn this weekend
<zyga>  We donât have one to mow, maybe rent some sheep :-)
<mborzecki> sheep, i like mutton :)
<mborzecki> mvo: morning
<mvo> hey mborzecki !
<mvo> mborzecki: how are you?
<mvo> mborzecki: and how is snapd, any urgencies or fires?
<mborzecki> mvo: no fires afaik, zyga anything on-fire on your plate? :)
<zyga> Just hot breakfast
<zyga> Welcome back mvo
<zyga> There is one issue but not widespread and yet to be understood or reproduced
<mvo> zyga: no fires> I like that!
<mvo> zyga: which issue is that, do you have more details?
<zyga> Yeah, just not at my pc yet
<zyga> Apparmor profiles sometimes go away on boot for some apps
<mvo> zyga: heh, no worries
<mvo> zyga: oh, this one - from sergio, right?
<zyga> Yes
<mborzecki> mvo: 2.32 branch builds are failing on travis, there was a recurring issue allocating certain machines in linode
<mvo> mborzecki: ok, slightly unfortunate, lets hope we can put 2.32 to rest. with 2.33 it will all be gce based and great and all that
 * zyga done with kids, now dog and then just work :)
<mvo> mborzecki: did you notice the spread error of 5080? it looks real
<mborzecki> mvo: yes, i need to adjust the test, we're showing 'system' now in snap interface output
<mvo> mborzecki: cool, just wanted to make sure its known
<zyga> #5081 is interesting and short and will open the path for the three fixes to layouts I have pending in case
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> in case anyone wants to look :)
<jamesh> zyga: fwiw, I've got a follow-up PR for the user-mounts branch, that extends the use of Secure.BindMount to file bind mounts too: https://github.com/snapcore/snapd/pull/5082
<mup> PR #5082: cmd/snap-update-ns: use Secure.BindMount to bind mount files <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5082>
<zyga> jamesh: ack, I saw
<zyga> I am waiting for a review from Gustavo who expressed interest but I would love to merge your branch ASAP
<kalikiana> good morning
<pstolowski> mornings
<pstolowski> hey kalikiana
<zyga> good morning kalikiana
<kalikiana> o/
<mvo> zyga: if you don't have something ready I will look into the mountinfo issue (1763266) now
<zyga> mvo: the mountinfo with #
<zyga> mvo: if you want to, I planned to look at that after layout permission issue I found yesterday evening
<mvo> zyga: this mountinfo has a superblock options with a space
<zyga> oh
<zyga> do you have a sample?
<mvo> zyga: but yeah, looks like a nice morning task
<mvo> zyga: sure, its in the bug, one sec
<zyga> we handle spaces because they should be escaped
<zyga> (so not really spaces)
<mvo> 28 1 8:4 / / rw,relatime shared:1 - bcachefs /dev/nvme0n1p6:/dev/sda4:/dev/sdb4 rw,errors=continue,background_compression=zstd,foreground_target=ssd,background_target=rotational,promote_target=invalid group 2,fix_errors
<zyga> uh
<zyga> looks like a kernel bug :/
<mvo> zyga: the superblock options (promote_target=..) has spaces
<zyga> normally all spaces are escaped
<zyga> but this has to be done everywhere correctly
<zyga> looks like not here :/
<zyga> (I mean normally in the kernel)
<mvo> zyga: should we add a workaround or ask the kernel folks to fix it?
<zyga> double check the spec
<zyga> and add a workaround, we need to work on the kernels as they are
<zyga> I'd also send a patch to the kernel after confirming this is wrong
<mvo> zyga: fair enough, I have a look
<mvo> zyga: do you mean Documentation/proc.txt when you say "spec"? or is there more of a spec than this file?
<zyga> this and the man page
 * mvo nods
<mborzecki> hm played a bit with systemd-bootchard to check if we could somehow use it to debug some of the issues with slow startup, but i don't understand why it's discarding samples for some of the processes
<mborzecki> and not only processes from a snap, just regular processes too
<Chipaca> mborzecki: how are you using it?
<Chipaca> mborzecki: and how is it different from 'systemd-analyze plot'
<mborzecki> Chipaca: i've patched it to support filering by uid (--uid=123) and only sample new processes (--new), basically what i did is run systemd-bootchar from command line, start some snaps, view the graph ;)
<Chipaca> mborzecki: interesting
<zyga> mvo: remember we have a 2nd parser in C
<mvo> zyga: I do
<mvo> zyga: but I concluded its a kernel bug
<zyga> yes
<zyga> I agree
<zyga> what happens because of the bug?
<zyga> how do we misbehave?
<mvo> zyga: he says it does not start but  Ithink we fixed this
<mvo> zyga: it may still have problems when snap-confine runs though
<zyga> Ubuntu 4.15.0+bcachefs.git20180404.42e79d6-1-generic 4.15.15
<zyga> interesting, it's a custom build
<mvo> zyga: yeah, bcachefs is not upstream yet
<zyga> huh? I used it a few years ago and it was all in the archive
<zyga> maybe it was DKMS
<zyga> I don't remember
<mvo> zyga: I did a apt search bcache and did not find a dkms, also downloaded our kernel tree (deb) and greped but maybe I missed something?
<zyga> mvo: does "/var has 'other' write 41777" ring any bells
<zyga> it's not in our tree
<mvo> zyga: does not ring a well, where do you see this?
<Chipaca> zyga: cmd/snap-confine/seccomp-support.c:		die("%s has 'other' write %o", path, stat_buf.st_mode);
<zyga> mvo: when I run "true"
<zyga> via snap run stack
<zyga> oh!
 * zyga has poor grep skills somehow
<zyga> thank you chipaca
<Chipaca> zyga: :)
<zyga> I grepped through bash and dash
 * Chipaca is having a good dady so far
<Chipaca> day*
 * Chipaca jinxed it
<pstolowski> zyga: wow, that layout fix PR has grown quite a bit
<zyga> it's my working branch
<zyga> I chop bits and propose them separately
<zyga> I'm working on the third fix
<zyga> in reality it's not that long but there are several places that use a helper so tests changed
<pstolowski> i see; yes I see a lot of tests
<mvo> btw, did we figure out why `snap try` is/was so slow for cachio?
<zyga> mvo: not that I know of
 * mvo nods
<mup> PR snapd#5083 opened: image: support refreshing soft-expired user macaroons in tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/5083>
<pedronis> mvo: hi, welcome back
<mvo> hey pedronis - good morning!
<zyga> Chipaca: super trivial for you https://github.com/snapcore/snapd/pull/5084
<mup> PR #5084: osutil,interfaces: use uint32 for uid, gid <Created by zyga> <https://github.com/snapcore/snapd/pull/5084>
<mup> PR snapd#5084 opened: osutil,interfaces: use uint32 for uid, gid <Created by zyga> <https://github.com/snapcore/snapd/pull/5084>
<pedronis> mvo: was your comment a +1 or a question? if it was a question I tried to answer
<mvo> pedronis: its a compliment, its pretty cool that this can be added now in such a trivial way
<pedronis> well, I wouldn't call it trivial, it's kind of obscure, but until we know the roadmap a bit unclear how much to spend improving this
<mvo> pedronis: thinking about it, a small comment in the type toolingAuthContext might be good, something like "// ... is used to support refreshing of soft-expired user macaroons"
<mvo> pedronis: yes, fair point
<mup> Bug #1760841 changed: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1760841>
<pedronis> mvo: pushed, can you look again
<pedronis> rewrapped the comment now
<pedronis> also
<willcooke> zyga, remember the bug from a week or two back where classic snaps were killing the Wayland session?  I've just tested the new mesa and it works, but the problem seems to have been resolved by something else in the last couple of weeks.  Could be a new xwayland, but we don't think so.  Anyway - the problem is resolved in my testing.
<zyga> willcooke: is this released now? popey has his session being killed by snaps very often lately
<zyga> willcooke: I will try again on my system
<zyga> thank you for letting me know
<zyga> and is this only in bionic or also in xenial?
<popey> I'm getting my session killed when snap connects the opengl interface
<popey> hasn't happened since I updated to latest nvidia driver, fingers crossed
<popey> and I'm not using wayland
<willcooke> zyga, this is on my 18.04 machine (no Wayland by deafult on 16.04).  I just installed and upgraded (no proposed) and rebooted, logged in to the wayland session and made a Skype call.
<willcooke> If you can still crash it, could you try this ppa?  https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
<zyga> I will try my bionic machine first
<Chipaca> any chance of a second review of #4983 ?
<mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<zyga> me
<mup> PR snapd#5085 opened: many: fix false negatives reported by vet <Created by zyga> <https://github.com/snapcore/snapd/pull/5085>
<mup> PR snapd#5086 opened: osutil,interfaces,cmd: use less hardcoded strings <Created by zyga> <https://github.com/snapcore/snapd/pull/5086>
<thresh> I'm having a weird (?) confinement issue I think?  /home/thresh/snap/vlc/common/.cache is no longer writable by the vlc snap?
<thresh> kf5.kservice.sycoca: ERROR writing database "/home/thresh/snap/vlc/common/.cache/ksycoca5_en_NtlNTj_f3j_omvvKHGdLzPa9Q1A=" . Disk full?
<zyga> thresh: dimes | grep DENIED
<zyga> dmesg*
<thresh> don't see anything for that particular filepath
<thresh> however
<thresh> [197467.950484] audit: type=1400 audit(1524566792.497:2281): apparmor="DENIED" operation="link" profile="snap.vlc.vlc" name="/run/user/1000/snap.vlc/vlcRTFlpM.11.slave-socket" pid=17509 comm="vlc" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000 target="/run/user/1000/snap.vlc/#5640602"
<zyga> this is a separate issue, snaps cannot create sockets in /run without an interface
<thresh> that's on Debian Testing, snapd 2.30-5+b1
<thresh> oh ok, let me take a look which interface that is
<zyga> mvo: ^^^
<zyga> mvo: we need to hug debian
<zyga> thresh: 3.30 is very old, we are now at 2.32.5 with a ton of bug-fixes
<zyga> thresh: we need to update debian
<thresh> o ok
<mup> PR snapd#5087 opened: many: fix various issues reported by shellcheck <Created by zyga> <https://github.com/snapcore/snapd/pull/5087>
<thresh> should I file a bug so it won't be forgotten?
<thresh> (and where)
<zyga> thresh: yes, sure on launchpad.net/snapd
<thresh> speaking about /run, what's the interface name should I use?  I browsed https://docs.snapcraft.io/reference/interfaces and didnt find much relevant
<thresh> I guess I can manually backport snapd to Debian locally just to try it out too
<zyga> thresh: it looks like some sort of IPC for vlc itself
<zyga> I don't know
<zyga> do you know what is that socked used for?
<thresh> the one in the apparmor denial, I don't
<thresh> the ksysoca thingie is KDE stuff, happens when a file dialog is starting up under Plasma
<thresh> I suspet they might be related, since they happen at the same time
<thresh> +c
<Chipaca> of course running an exec.Command from a pinned thread doesn't work in 1.6 :'(
<Chipaca> works just fine in 1.10
<Chipaca> darn it
<Chipaca> mvo: mborzecki: does snapd as packaged depend on sudo?
<mborzecki> Chipaca: don't think so
<mborzecki> Chipaca: runuser?
<Chipaca> mborzecki: is that everywhere we support?
<mborzecki> Chipaca: it's in util-linux, so maybe, worth checking
<Chipaca> mborzecki: and does it take a numeric id
 * Chipaca tries that
<pedronis> Chipaca: I'm still blocking #4790, right ? I need to re-review
<mup> PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790>
<Chipaca> Â¯\_(ã)_/Â¯
<pedronis> too many open PRs
<zyga> Chipaca: reviewed 4983
<Chipaca> mborzecki: mvo: OTOH snapshots adds a dependency on 'tar', so maybe adding a dependency on sudo isn't too onerous
<zyga> Chipaca: wanna read "chopTree" PR? :)
<zyga> I really need it out to do more fixes for layouts
<zyga> mvo: I sent some trivial cleanup PRs for issues reported by run-checks --static
<mup> PR snapcraft#2104 opened: many: allow building in containers with no version in project <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2104>
<mvo> zyga: cool, thank you
<mvo> Chipaca: no need (on debian/ubuntu) to add a dependency to tar, tar is essential already
<mvo> Chipaca: sudo otoh is something we should depend on
<mvo> Chipaca: if there wasn't the "apt-get upgrade" issue
<Chipaca> mvo: and is util-linux essential?
<mvo> Chipaca: yes
<Chipaca> siiigh
<mvo> Chipaca: why?
<Chipaca> I'll use runuser then
<Chipaca> mvo: because runuser doesn't take numeric ids
<mvo> Chipaca: essential is good
<Chipaca> mvo: so I need to pass the username
<mvo> Chipaca: aha, I see, you need sudo for sudo --user ?
<Chipaca> mvo: nah, i can use runuser
<Chipaca> it's just that i'd prefer not to :-)
<Chipaca> mvo: just me being grumpy
<mvo> Chipaca: ok :)
<ackk> mvo, hi, is the SSL certs setup different in a snap? I added a self-signed cert to the chain and a curl on the host works, but an app in the snap fails fails to check the certificate
<zyga> ackk: hey
<zyga> ackk: where are the certificates stored?
<ackk> zyga, well I added it to /etc/ssl/certs and run update-ca-certificates , so it should be listed there
<zyga> I see
<zyga> ackk: we don't allow host certificates to be seen by snap applications
<zyga> ackk: they only see those that are shipped by the core snap
<ackk> zyga, and where are those?
<zyga> in /snap/core/current/etc/ssl
<ackk> zyga, also, how is that done? if I snap run --shell and list /etc/ssl/certs I do see my cert there
<zyga> I mean, the same location
<zyga> just baked as read-only in the core snap
<ackk> zyga, so if I list /etc/ssl/certs from a snap shell should  I see the dir in core?
<zyga> yes
<zyga> you will
<ackk> zyga, I don't seem to
<zyga> and what do you see?
<ackk> ack@maas:/home/ack/canonical/src/maas$ ls -la /etc/ssl/certs/ | grep ext-au
<ackk> lrwxrwxrwx 1 root root     12 Apr 24 09:58 8135fe7f.0 -> ext-auth.pem
<mup> PR #24: Renamed .bzrignore to .gitignore. Added .coverage. Removed the ./ in front of ignored paths <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapd/pull/24>
<ackk> lrwxrwxrwx 1 root root     12 Apr 24 09:58 a35f5088.0 -> ext-auth.pem
<ackk> -rw-r--r-- 1 root root   1159 Apr 24 09:17 ext-auth.pem
<ackk> zyga, ^ those are my certs
<ackk> zyga, (from snap run --shell maas)
<zyga> ah, is this a base18 thing?
<ackk> yeah
<zyga> ls
<ackk> core18 :)
<pedronis> then is undefined
<zyga> it should behave the same
<zyga> but...
<zyga> ackk: what is /etc/ssl on your host?
<zyga> is it a symlink?
<ackk> zyga, you mean outside of the snap? no, it's a dir
<zyga> hmm
<ackk> but it seems core18 doesn't have its own /etc/ssl
<zyga> yeah
<zyga> aha?
<ackk> yeah, it's not there
<zyga> in that case we don't hide it
<zyga> it should be your host's /etc/ssl
<zyga> sorry that this is confusing
<zyga> if I could change one thing we did years ago
<zyga> I'd make /etc an artificial fs maintained by snapd
<ackk> zyga, ok, so it it indeed the one of the actual system, but for some reason it seems apps are not getting certs from there
<zyga> ackk: no idea how SSL stack works
<pedronis> anyway the current behavior of core18 is likely not what we want
<ackk> zyga, ok, thanks for confirming the filesystem layout
<zyga> yes, I agree
<zyga> though the issue of SSL certs being a bit odd is still a valid one
<zyga> it's unclear how they work
<zyga> and definitely not documented that it is what we want
<pedronis> we have had requests to add certs
<zyga> yes, I recall
<pedronis> so really we want something that is the union of various things
<pedronis> I fear
<zyga> I mean we should be consistent and not unexpected
<zyga> and documented
<pedronis> just offering what's in the host in not what we want though
<pedronis> or at least not as default
<zyga> yes, I think we want to look at /etc
<zyga> to be ready for 20
<zyga> since 18 is a bit too soon
<ackk> zyga, pedronis fwiw I see a weird behavior, if I pass --ca-directory=/etc/ssl/certs to wget it works
<zyga> can you strace it
<ackk> but that should be the default (and indeed it works without outside the snap)
<zyga> to see where it goes normally
<ackk> zyga, not inside the snap
<zyga> it probably follows some config/symlinks or other magic
<zyga> ackk: snap run --strace ;D
<ackk> ooh
<ackk> zyga, but how do i run wget i the snap from snap run?
<zyga> just hack a command that has what you want to run
<zyga> snap run --stace maas.justesting
<zyga> --strace :)
<ackk> oh
<ackk> zyga, can I manually add a wrapper in a snap try snap and execute it ? :)
<zyga> yeah
<ackk> ah, nice
 * Chipaca -> lunch
<ackk> zyga, how do i do that? I created the wrapper file, and added a /snap/bin/maas.wget symlink but it doesn't work
<zyga> unpack your snap, add a command and snap try it
<ackk> zyga, do I need to add the command to some manifest?
<zyga> ackk: yes, to meta/snap.yaml
<ackk> aah, thanks
<ackk> zyga, I'm getting this error: cannot change profile for the next exec call: No such file or directory
<zyga> did you "snap try" after creating the new entry or before it?
<zyga> snap try should fix it (again)
<ackk> zyga, even if it's already mounted?
<zyga> yes
<ackk> ah, TIL you can do that
<ackk> I thought bad things would happen
<mup> PR snapd#5088 opened: tests: checking interfaces declaring the specific interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5088>
<ackk> zyga, ah, now I can snap run the command, but --strace just reports exit statu 1
<ackk> zyga, https://paste.ubuntu.com/p/kR8pwb6gSt/
<zyga> hmmm, no idea :/
<ackk> ok, thanks
<mborzecki> off to pick up the kids
<jdstrand> thresh (cc zyga): that socket denial is actually a 'file' rule for 'l'ock. we allow that in the default template. there might be a bug. can you file it either in the forum or at https://bugs.launchpad.net/apparmor/+filebug?
<zyga> oh
<zyga> hey jdstrand :)
<thresh> jdstrand, I can do it - which information should I include on the launchpad?
<jdstrand> thresh: please include the denial and the output of: grep '/run/user' /var/lib/snapd/apparmor/profiles/snap.vlc.vlc. then attach grep '/run/user' /var/lib/snapd/apparmor/profiles/snap.vlc.vlc
<jdstrand> whoops
<jdstrand> thresh: then attach /var/lib/snapd/apparmor/profiles/snap.vlc.vlc
<jdstrand> hey zyga :)
<jdstrand> thresh: oh, and the output of 'snap version' and 'cat /proc/version'
<zyga> jdstrand: I'm working on three layout issues, two are fixed and third is in progress (just some gardening needed and tests)
<jdstrand> yeah. I know you need 5081
<jdstrand> (and cool)
<zyga> jdstrand: it would help if you could look at 5081
<zyga> yes :)
<zyga> but no rush, maybe someone else will review it before
<zyga> I need to garden some testing helpers and add syscall.Lstat
<zyga> jdstrand: the third bug was that the mimic would not retain the ownership and permissions of the original directory
 * jdstrand nods
<thresh> woah, any idea what went wrong with firefox here:  http://thre.sh/stuff/2018-04-24-152506_1523x1011_scrot.png
<thresh> 59.0.2-1, refreshed in March .. :
<thresh> :|
<zyga> jdstrand: fortunately tmpfs can be mounted that way but adding that one extra Lstat call makes a lot of noise
<thresh> libreoffice does not start now, too
<jdstrand> thresh: are these snaps?
<thresh> jdstrand, yes
<jdstrand> (firefox and libreoffice)
<jdstrand> thresh: do you have security denials?
<thresh> I do not have that in dmesg
<thresh> snap run libreoffice reports "No fonts could be found on the system."
<jdstrand> thresh: fyi, normally looking at journalctl will give you a complete picture (eg, dbus denials are not logged in dmesg)
<jdstrand> s/dbus/some dbus/
<thresh> nothing new with sudo journalctl --folow and then snap run libreoffice
<jdstrand> thresh: I'm not sure what that issue would be (others in the channel can comment). it could be either the snaps, something changed on the system underneath them (eg, a dist-upgrade) or a bug in making the fonts available
<jdstrand> thresh: did you run a dist-upgrade?
<thresh> I did that a couple days back, but I've re-logged in since then
<thresh> maybe it's time for a reboot
<thresh> let me check if non-snapped GTK sotware works
<jdstrand> since it happened to two different snaps, I would suggest looking at snapd then. zyga can you think of why thresh has snaps that can no longer find fonts?
<thresh> well, thunderbird (non-snapped) works fine
<thresh> I'm on core 16-2.32.5, rev 4486
<zyga> thresh: what is your host? xenial?
<zyga> jdstrand: mount profiles are optional so if we fail to mount fonts we don't stop
<zyga> thresh: can you please run this:
<zyga> thresh: sudo /usr/lib/snapd/snap-discard-ns firefox
<zyga> (quit all firefox processes before)
<zyga> thresh: SNAP_CONFINE_DEBUG=1 snap run firefox
<zyga> thresh: and attach the output please
<thresh> zyga, debian 9, testing
<thresh> err
<thresh> s/ 9//
<zyga> debian sid?
<zyga> did you rebuild snapd form source then?
<thresh> debian buster
<thresh> I can no longer reproduce after a reboot, sorry
<thresh> no, I havent rebuild snapd
<zyga> I see
<thresh> snapd version is 2.30-5+b1, snap list core core  16-2.32.5  4486  stable    canonical  core
<zyga> is snapd on debian at 2.32.5?
<zyga> aha
<zyga> ok
<zyga> so just Sid is wrong
<thresh> I *did* have a weird issue with fonts on VLC too, but then it magically started working
<thresh> so will do that reporting next time I experience that, good to know - thank you
<thresh> I think Sid has the same snapd as per https://packages.debian.org/search?keywords=snapd
<mup> PR snapd#5089 opened: tests: adding google-sru backend replacing linode-sur <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5089>
<thresh> uhm, now that's confusing
<thresh> thresh@coal ~ $ snap version
<thresh> snap    2.32.5
<thresh> snapd   2.32.5
<thresh> dpkg -l snapd reports 2.30, though
<zyga> thresh: that's deliberate
<pedronis> you have reexec turned on
<thresh> thank you
<mup> PR snapd#5071 closed: tests: replace snap try when possible to speedup tests execution <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5071>
<mup> PR snapd#5090 opened: cmd/snap-update-ns: poke hokes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
<zyga> jdstrand: I opened a reasonably simple PR for the 2nd layout issue I found, it's now isolated from issues 1 and 3
<thresh> jdstrand, regarding vlc apparmor issue; the problem is, I'm shipping parts of KDE (kio, to be exact), so users' look and feel would be fine under K (think themed Qt)
<thresh> so I'm not really sure this belongs in an upstream vlc apparmor policy
<thresh> maybe I'm missing some plug
<jdstrand> zyga: ack. note I'm still work on sprint stuff
<zyga> jdstrand: ack
<zyga> that's fin
<zyga> fine
<jdstrand> thresh: well, the issue with vlc is that you are seeing a lock denial and the policy has a rule to allow it
<jdstrand> thresh: so there might be a bug in the parser or the kernel
<jdstrand> thresh: please report it so it can be investigated
<thresh> jdstrand, allright.
<thresh> grep '/run/user' /var/lib/snapd/apparmor/profiles/snap.vlc.vlc is nada, btw, there is no /run in that file whatsoever
<Chipaca> mvo: was https://github.com/snapcore/snapd/pull/4750#issuecomment-369862204 meant to be a +1?
<mup> PR #4750: store: getStructFields now take pointers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4750>
<cachio> mborzecki, zyga, please could you take a look to https://github.com/snapcore/spread-images/pull/10 again?
<mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
<cachio> thanks
<jdstrand> thresh: oh, well, then that isn't an apparmor bug. can you paste the profile somewhere? eg, http://paste.debian.net/
<mborzecki> cachio: just finished going though it :)
<thresh> jdstrand, there you go http://paste.debian.net/1021796/
<jdstrand> thresh: so, that profile indicates forced devmode and the lockfile should be handled by /** rwlkm. please file the bug. you can just paste the profile in the bug rather than attach it (since it is small; also leave out the grep for /run)
<jdstrand> thresh: really, show the denial and then everything in the paste :)
<cachio> mborzecki, tx
<thresh> jdstrand, a bug against apparmor then?
<mup> PR snapd#5091 opened: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<jdstrand> thresh: yes please
<thresh> uhm, that's weird, I never assumed it was devmode
<thresh> wonder why snap info vlc doesnt tell thatn then
<thresh> welp, snap install vlc --beta --devmode now shows it as "devmode" in snap info vlc;  however I still see security policies applied
<thresh> heheh
<thresh> and snap install vlc --beta --jailmode results in error: cannot install "vlc": this system cannot honour the jailmode flag
<mvo> Chipaca: that was a thank you for the extra explaination. I will reply to the PR but I'm really sitting on the fence about this one, it does not fell (to me and my ignorance) that we win much with the change. but let me read it again
<niemeyer> Chipaca: I'm off the call, and still have time left before my next activity.. please let me know when you're back
<Chipaca> niemeyer: i'mback
<zyga> cachio: after lunch, but sure :)
<cachio> zyga, tx
<niemeyer> mvo, Chipaca: Provided a small comment there too
<niemeyer> Chipaca: Cool, back to the standup?
<Chipaca> niemeyer: sure
<niemeyer> (sorry for the noise, it's still here)
<pedronis> mvo: your addition to the 5s topic,   we discussed also the maing of stop vs stop --disable for sockets and timers, which is probably something that work should take into consideration
<pedronis> s/maing/meaning/
 * cachio lunch
<pedronis> mvo: I can add something myself if that's ok
<mup> PR snapcraft#2084 closed: Osx travis <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2084>
<pedronis> Chipaca: IÂ wondered who would be the first to use Simple ironically ;)
 * zyga is back from school/dog/lunch break
<mvo> pedronis: sure, just add
<pedronis> mvo: done
<mvo> pedronis: sorry for the delay, was in a meeting
<mvo> pedronis: thank you
<zyga> cachio: https://github.com/snapcore/snapd/pull/5088 has issues in one interface test
<mup> PR #5088: tests: checking interfaces declaring the specific interface <Simple> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5088>
<zyga> cachio: https://github.com/snapcore/snapd/pull/5089 needs a trivial fix
<mup> PR #5089: tests: adding google-sru backend replacing linode-sur <Simple> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5089>
<mup> PR snapd#5083 closed: image: support refreshing soft-expired user macaroons in tooling <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5083>
<Chipaca> pedronis: I wonder why you wondered
<Chipaca> I blame zyga
<zyga> I blame zyga too
<Chipaca> zyga: this is about #5066
<mup> PR #5066: overlord/snapshotstate/backend: introducing the snapshot backend <Simple> <Created by chipaca> <https://github.com/snapcore/snapd/pull/5066>
<zyga> haha
<zyga> well, I didn't do _that_ :D
<Chipaca> zyga: simple means it's got no poles
<Chipaca> zyga: right?
<zyga> no poles or no slavs?
<Chipaca> zyga: it's hard to tell if you're running with the joke or thought i meant Poles, over IRC. Just to be clear: I meant no zeros in the complex plane, which are called poles
<Chipaca> bah. 1/f etc etc
<zyga> oh, I didn't run with that joke, I must have intersected with the real plane earlier
<Chipaca> zyga: https://en.wikipedia.org/wiki/Zeros_and_poles#/media/File:Gamma_abs_3D.png
<Chipaca> zyga: dem poles
<zyga> Chipaca: now I will be reading wikipedia for the next hour!
<Chipaca> psh. amateur.
<mup> PR snapcraft#2102 closed: tests: use a common cache for the integration tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2102>
<mup> PR snapd#5059 closed: tests: add pending shutdown detection <Go! Go! Go!> <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5059>
<kyrofa> Chipaca, if I run `snap watch --last=refresh`, it sounds like that will _not_ cover automatic refreshes, right?
<kyrofa> (since auto-refresh is also an item)
<Chipaca> kyrofa: do you have an auto-refresh change there?
<Chipaca> kyrofa: I'd have to go look through code to answer with confidence (and i'd rather not given my current stack)
<Chipaca> kyrofa: if you do, curl -s --unix-socket /run/snapd.socket http://localhost/v2/changes?select=all  | jq '.result[].kind'
<kyrofa> Chipaca, yeah there's an auto-refresh there
<kyrofa> It's done, though
<Chipaca> kyrofa: then that's the one you want to wait on, if you're looking at the same issue kalikiana was looking at
<Chipaca> kyrofa: if it's Done, then watch will return immediately
<kyrofa> Chipaca, ah, you're familiar with that issue? Yeah, kalikiana is using --last=refresh, my question is whether it should actually be --last=auto-refresh
<Chipaca> kyrofa: yeah probably
<Chipaca> kyrofa: it'll be harder to test for :-(
<Chipaca> but yes
<Chipaca> the situation as described was with an auto-refresh ongoing
<kyrofa> No reason we can't do both, but in a realistic scenario, I think the auto-refresh is the real problem
<kyrofa> Indeed
<Chipaca> as long as you ignore the error, yes
<Chipaca> (watch will error if there is no change of that kind)
<kyrofa> Oh, good to know
<Chipaca> kyrofa: try 'snap watch --last=potato'
 * Chipaca hopes he hasn't made anybody nervous with that
<kyrofa> Chipaca, it worked!
<kyrofa> (kidding)
<Chipaca> kyrofa: by the way, what was the reason for the validation error you were getting yesterday?
<kyrofa> Chipaca, the app command wasn't pointing at an existing file
<Chipaca> kyrofa: did you read that in the log?
<kyrofa> Chipaca, no, after zyga mentioned that apps were validated I just took a closer look. I had fixed it by the time you mentioned it was actually logged
<Chipaca> aw, ok
<Chipaca> kyrofa: I'll probably be adding a '(details in the log)' or something to help people find that info
<Chipaca> not any time soon though
 * Chipaca 's plate is full
<kyrofa> Chipaca, how quickly after first boot do you think snapd would try to autorefresh?
<kyrofa> Immediately?
<kyrofa> Or is there a delay or some sort?
<mvo> kyrofa: with the current snapd there is a delay of ~2h iirc
<Chipaca> there's a hold off of 2h i think, and then a random window
<Chipaca> kyrofa: see 'snap refresh --time'
<kyrofa> Can I hack around that for a test? Convince it to autorefresh?
<kyrofa> Oh, handy
<Chipaca> kyrofa: I think you should be able to give it a window small enough to be useful in a test, yes
<Chipaca> I never remember the syntax for it though
<kyrofa> Oh right, THAT feature, yeah let me look it up
<kalikiana> Chipaca: kyrofa It was my understanding `snap watch --last=refresh` covers automatic refresh. Is that indeed not the case?
<Chipaca> kalikiana: watch is fairly dumb and snap-side only, and it's a simple match on the change kind
<kalikiana> Hum
<kalikiana> Okay
<Chipaca> kalikiana: code is in cmd/snap/last.go if you want to look
<mup> PR snapd#5087 closed: many: fix various issues reported by shellcheck <Simple> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5087>
<mup> PR snapd#5092 opened: snap: do not use overly short timeout in `snap {start,stop,restart}` <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5092>
<pedronis> Chipaca: I reviewed #4790
<mup> PR #4790: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790>
<pedronis> Chipaca: it needs a different summary when merged
<Chipaca> pedronis: ack, thanks
<Chipaca> i'll probbaly get to it tomorrow
<mup> PR snapd#5084 closed: osutil,interfaces: use uint32 for uid, gid <Simple> <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5084>
 * kalikiana eod
<zyga> willcooke: sorry for the late response, I just logged into a fully up to date 18.04 wayland session and yes, Skype still kills it
<willcooke> zyga, interesting.  Did you try the canonica-x ppa too?
<zyga> willcooke: this is on a thinkpad t470 with just intel graphics
<zyga> gnome-shell segvfault https://www.irccloud.com/pastebin/I8gILg4y/
<zyga> no, I haven't
<zyga> I'm about to, just looking fot that PPA name
<willcooke> https://launchpad.net/~canonical-x/+archive/ubuntu/x-staging
<zyga> thank you
<willcooke> yw!
 * ogra_ guesses the times are over weher you could just blame microsoft and be done ...
<ogra_> *where
<ogra_> slangasek, when you initially created the pc-gadget, you didnt include a GPL boilerplate ... was that an oversight or is it actually not needed to include it (asking because of https://forum.snapcraft.io/t/gadget-snap-licenses/ )
<ogra_> (not that anybody bothered to include it later either ... )
<zyga> willcooke: crashed
<zyga> so no change
<zyga> let me know if anyone on your team needs any hands-on time with this
<willcooke> k, that sucks.
<willcooke> zyga, would you mind commenting on here please?  https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/1754693
<mup> Bug #1754693: Xwayland crashed with SIGABRT in st_renderbuffer_delete() <amd64> <apport-crash> <bionic> <reproducible> <ubuntu> <wayland-session> <mesa (Ubuntu):Confirmed> <https://launchpad.net/bugs/1754693>
<zyga> not at all, one sec
<slangasek> ogra_: I think at the time we were creating those gadget snaps it wasn't clear what the convention was for including license information; but the fact that it wasn't there at all, definitely an oversight
<ogra_> slangasek, ok, thanks .. just wanted to make sure it wasnt on purpose ... (because bootloaders are special or whatnot)
<slangasek> ogra_: bootloaders are not magically immune to copyright law ;-)
<ogra_> yeah, i thought so ... :)
<kyrofa> roadmr, I'm having trouble logging in with snapcraft, is there a problem?
<roadmr> there is
<kyrofa> I see a "Snap downloads interruption" but everything is green
<roadmr> kyrofa: at the very top of the page there's an announcement
<kyrofa> Right, that's what I'm talking about
<roadmr> I don't understand then.
<noise][> that shouldn't be affecting login though
<ogra_> oh, is that the reason why i'm bombed with store mails recently ?
<ogra_> Launchpad uploaded this snap package to the store, but the store failed to
<ogra_> scan it:
<ogra_>   __all__: The upload does not appear to be a valid package.
<roadmr> kyrofa, noise][ : I did see some sluggishness with unrelated store API accesses, that *might* have caused snapcraft login to barf
<ogra_> the 4th now in 20min
<roadmr> ogra_: yes, that would be the store being unable to download the snap for scanning
<nessita> kyrofa, what's the error you are getting?
<ogra_> ah, k
<kyrofa> nessita, 504
<roadmr> ogra_: if any of your snaps end up in a wedged state and you can't wrangle them out yourself, let me know. We should have fixed that, this is a trial by fire for our fix :D
<kyrofa> Took a long time to discharge, and now it's getting 504s on /dev/api/account
<ogra_> roadmr, fun fact ... nit even remotely "my snaps" :) thats snapcraft itself (i seem to be a collaborator for whatever reason)
<ogra_> *not even
<roadmr> ogra_: oh fun :)
<kyrofa> ogra_, yeah it's owned by snappy-dev or whatever that group is
<ogra_> yeah
<nessita> kyrofa, just calling snapcraft login?
<kyrofa> nessita, after entering my login info and 2fa, yeah
<kyrofa> Also happening with exported logins on travis
<nessita> kyrofa, ok so many that was the dashboard API for when getting the account details
<nessita> roadmr, ^
<mup> PR snapcraft#2104 closed: many: allow building in containers with no version in project <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2104>
<roadmr> righto
<mup> Bug #1766667 opened: commands in a container cannot write to inherited filehandles such as stdout <Snappy:New> <https://launchpad.net/bugs/1766667>
 * cachio afk
<zyga> mvo: does 5092 mean we need a .6?
<zyga> I'm about to EOD so I won't review it today
<zyga> but I was curious
<kyrofa> roadmr, nessita any progress? I still can't login, blocking work
<nessita> kyrofa, see is-outage, there is a network issue in the datacenter
<kyrofa> Do we have any communication around this? Tweets, forum posts?
<roadmr> kyrofa: our procedure calls for updating status.snapcraft.io (which we did, the announcement at the top), and post something sticky in the forum (we didn't, apologies - the procedure we have is newish)
<roadmr> kyrofa: we hadn't been asked to tweet about it :) if you were to look at twitter, where would you look?
<roadmr> (which account I mean - to e.g. decide if we use an existing one or create a new one)
<roadmr> kyrofa, nessita : as for the "everything is normal" thing on status.snapcraft.io - the thing is that we use an external provider for this
<kyrofa> snapcraftio, but snapcraftstatus or something would be even better
<roadmr> and they consider a service green if it responds to a small subset of queries, even if slowly (as is the case now)
<kyrofa> roadmr, I'm getting 504s, that's not slow, that's timeout
<roadmr> they are more lenient than our clients :) so that's why the dots all show green. Our IR will have an action to check if we can tighten those times
<roadmr> kyrofa: right - the monitoring service does NOT do "snapcraft login" so it wouldn't hit the code path that's timing out for you
<roadmr> kyrofa: so you would prefer a dedicated twitter account that only posts when the status changes? and not something buried in snapcraftio's normal feed?
<kyrofa> roadmr, I think of this as the ideal: https://twitter.com/githubstatus
<nessita> sorry for the missing post, that was my bad, here it is https://forum.snapcraft.io/t/slow-snap-store-downloads-and-slow-sso-interactions/5121
<kyrofa> roadmr, but that's just me, give it some thought
<roadmr> thanks for the ideas!
<kyrofa> Whatever the deal is with the dashboard, something's not right. That's all I wanted to say
<kyrofa> s/dashboard/status thing/
<kyrofa> nessita, should that be sticky?
<nessita> kyrofa, I'm not sure what sticky is in the forum, sorry
<roadmr> nessita: noise][ can make the post sticky if you point him to it
<roadmr> (means it'll appear at the top until unstickied)
<noise][> done
<nessita> thanks
<thresh> how are apparmor policies apply to binaries other than the main snap entrypoint running under the same namespace?
<kyrofa> thresh, depends on how the binaries are being run. By the "main entrypoint" ?
<kyrofa> If so, its confinement is inherited
<thresh> so what I do is I run snap run vlc,  then Qt (which VLC is linked to ) I guess forks some KDE-related processes
<thresh> I'm looking at what's hapenning with VLC beta snap on 18.04, and it's the same issue as I have on Debian, apparmor denials
<kyrofa> thresh, what does that KDE-related process do?
<kyrofa> This KDE-related thing must be something you're shipping in VLC? Do you need to (i.e. is it required?)
<thresh> correct, that's something I ship in VLC snap.  I need it for VLC to look nice under KDE (e.g. use Open File dialogs relevant to the platform it's launched on).
<thresh> as Qt shipped in Xenial is too bad with that, and I don't get any theming (well, only the default windows 95 one) on any platform except Unity.
<kyrofa> thresh, ah, the windows 95 one. Isn't minimalist "in" these days?
<kyrofa> thresh, do you get these denials on xenial as well? Or just 18.04 and debian?
<thresh> the apparmor messages on 18.04 are http://thre.sh/stuff/snaps/apparmor-issues/messages.txt
<thresh> I'm yet to test xenial, don't have it on my virtualbox yet
<kyrofa> thresh, this utility must be dbus-based?
<kyrofa> thresh, what is it called? I suspect we need an interface covering it
<kyrofa> Like xdg-open
<kyrofa> jdstrand, will know far more
<kyrofa> Darn hexchat. Minus the comma
<thresh> I have no idea
<thresh> thanks kyrofa, I guess my usecase is really weird
<thresh> but then I wonder what other Qt5 apps do when they want to look nice everywhere
<kyrofa> thresh, yeah great question. There must be similar functionlity for gtk, no?
<kyrofa> thresh, I can't pretend to be much of a desktop dev though
<kyrofa> kenvandine, are you around?
<kyrofa> (as much as I'd love to be sometimes... I miss qt)
<kenvandine> kyrofa, yup
<kenvandine> kyrofa, lol
 * kenvandine reads
<kyrofa> kenvandine, yeah starting around 12:48
<thresh> https://forum.snapcraft.io/t/how-do-people-build-qt-gui-applications-snaps/3714/4 says there is no good way, except using newer Qt5 than shipped in Xenial, which I do now
<kenvandine> thresh, so what's your question?  How to get better looking toolkit provided dialogs like the file picker?
<thresh> well, it all stems from there, yes.
<kenvandine> thresh, and you're bundling qt5 right?
<kenvandine> how's kde involved at all?
<thresh> the problem is, when I use newer Qt5 - from KDE Neon, built for 16.04, since I can not build VLC on anything newer that might have newer nicer Qt5, weird things are happening when running in snap.
<thresh> I am.  And to be able to utilize KDE support in newer Qt5, I also bundle some K* packages.
<thresh> without all that, I don't even get icons on VLC interface when running on anything else than Unity.
<kenvandine> probably better to ask greyback
<kenvandine> greyback, ^^
<kenvandine> thresh, and you use desktop-qt5 right?
<kenvandine> from the snapcraft-desktop-helpers
<thresh> yes.
<kenvandine> maybe that's trying to exec some k* process internally, and of course snap doesn't allow exec
<kenvandine> [ 1858.294589] audit: type=1400 audit(1524599246.290:314): apparmor="DENIED" operation="link" info="Failed name lookup - deleted entry" error=-2 profile="snap.vlc.vlc" name="/run/user/1000/snap.vlc/#34" pid=8907 comm="vlc" requested_mask="l" denied_mask="l" fsuid=1000 ouid=1000
<kenvandine> that's probably the most curious thing
<thresh> it seems like it does exec it yes, but I *do* see output from ksysoca and friends, so they are launched (but probably are confined so they cant open much?)
<kenvandine> yeah
<kenvandine> ultimately this is what xdg-desktop-portal is for
<thresh> 12:15:41 < thresh> kf5.kservice.sycoca: ERROR writing database "/home/thresh/snap/vlc/common/.cache/ksycoca5_ru_ukOlKAnKObXkPNxFifGg50oJz9A=" . Disk full?
<kenvandine> but we aren't quite there yet
<thresh> 12:16:26 < thresh> and Couldn't write "/home/thresh/snap/vlc/273/.config/kdeglobals" . Disk full?
<jdstrand> thresh: I forwarded the bug to jjohansen, who is apparmor upstream. on Debian and Ubuntu 18.04, they both have the 4.15 kernel. they also have the new apparmor userspace
<thresh> stuff like that
<jdstrand> thresh: so I suggest putting more info into the bug. it feels like a regression in lock rules
<thresh> thanks jdstrand!
<jdstrand> thresh: more info if you find new things
<jdstrand> that is
<jdstrand> jjohansen: fyi, http://thre.sh/stuff/snaps/apparmor-issues/messages.txt for more locking issues. I'm told that is with 4.15 from bionic
<thresh> I've attached that to the bugreport on launchpad, too
<jdstrand> jjohansen: s/locking/lock rule/
<jdstrand> thresh: cool, thanks
<thresh> kenvandine, oh yeah, I'll be more than happy if I wouldnt have to shipp all that since it's not exactly VLC domain :)
<kenvandine> thresh, we're close :)
<jdstrand> jjohansen: actually, thresh already attached that to the bug, so nothing new here it sounds like
<jdstrand> jjohansen: what is interesting is that, aiui, the 18.04 4.15 kernel is of course a strict profile, where the Debian 4.15 kernel has that wide open 'devmode' profile
<jdstrand> jjohansen: ('aiui' because I've not verified myself any of this)
<thresh> jfyi just tried keepassxc, and it doesnt even show any labels on my KDE, so yeah..
<thresh> thanks everyone, I appreciate it
<thresh> good night
<Chipaca> mwhudson: moin
<Chipaca> mwhudson: https://pastebin.ubuntu.com/p/7fx8cCKp36/ with go < 1.10 seems to point to a bug in Go, but 1.10 has changes in the area that seem to fix it (maybe by chance; haven't looked in detail). Do you think it's worth reporting?
<jbicha> kenvandine: I installed the gnome-characters 3.28 snap https://paste.debian.net/1021881/ is that a bug that it suggests I connect to the gnome-3-26-1604 snap?
<jbicha> and the gnome-3-28-1804 snap description says it's built using xenial
<mwhudson> Chipaca: national holiday today
<Chipaca> mwhudson: :-) enjoy
<kenvandine> jbicha, not a bug, that is built against gnome-3-26-1604
<kenvandine> jbicha, oh, you installed the beta
<kenvandine> the console output from the helpers needs to be made more generic, we won't be able to know which platform you need
<kenvandine> jbicha, we aren't quite ready to use the stuff based on 1804  :(
<jbicha> how come it can't know which platform is needed?
<kenvandine> the shell script won't know
<kenvandine> not without querying snap
<kenvandine> and that would slow down startup time
<jbicha> but wouldn't it only need to do if the snap failed to launch normally?
<kenvandine> maybe we can grep generated yaml in $SNAP/meta/
<kenvandine> true, only if the mount point is empty
<kenvandine> we'll do that
<jbicha> do you want a bug filed somewhere?
<kenvandine> https://github.com/ubuntu/snapcraft-desktop-helpers
<kenvandine> jbicha, please do
<kenvandine> with auto-connecting and auto-downloading we should actually never see that message :)
<kenvandine> real soon now
<jbicha> https://paste.debian.net/1021889/ strange response from snap
<kenvandine> jbicha, that's very odd
<kenvandine> jbicha, gnome-logs from beta won't work btw :)
<kenvandine> it crashes...
<kenvandine> core18 doesn't provide log-observe
<kenvandine> is my current theory
<jbicha> um, gnome-logs 3.28 actually runs hereâ¦
<kenvandine> from candidate it will
<kenvandine> not from beta
<jbicha> they're the same thing right now I think?
<kenvandine> oh
<kenvandine> ok, maybe i never pushed the broken one :)
<kenvandine> it must be the one using gnome-3-26-1604
<jbicha> that makes sense because I didn't even connect anything this time
<kenvandine> that is an odd message from snapd though
<kenvandine> i need to run though
<kenvandine> later!
<mup> Issue snapcraft#2037 closed: core refresh in container build breaks build <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2037>
<mup> PR snapcraft#2098 closed: lxd: wait for on-going refreshes to finish <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2098>
<mup> Issue snapcraft#1919 closed: Add Always support when sending errors <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1919>
<mup> PR snapcraft#2101 closed: errors: implement an always option to send to sentry <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2101>
<mup> PR snapcraft#2103 closed: package: make use of snapcraftctl snapcraft features <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2103>
#snappy 2018-04-25
<utxera> Hi there, anybody up?
<mup> PR snapcraft#2094 closed: storeapi: better handle network errors and retries <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2094>
<mborzecki> morning
<mup> PR snapd#5085 closed: many: fix false negatives reported by vet <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5085>
<zyga> Good morning
<mvo> hey zyga
<zyga> Man, what a terrible night
<mborzecki> mvo: zyga: hey
<zyga> Both kids stormed our bed at night
<zyga> We slept like sardines in a can
<mvo> hey mborzecki
<zyga> mvo: google images are out of date again
<zyga> we need to bump 18.04 snapshot date
<mvo> zyga: aha, yes. are you already on it? if not I push something in 1min
<zyga> yes, on it
<mvo> ta
<mborzecki> zyga: can you take a look at https://github.com/snapcore/spread-images/pull/10 i think cachio has addressed most of the issues
<mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
<mup> PR snapd#5093 opened: spread: bump bionic snapshot date <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5093>
<zyga> does anyone have access to edit other people's posts on the forum?
<zyga> mvo: maybe you? :)
<mvo> zyga: maybe, I can try. what post would that be?
<zyga> I would love if someone would add ``` around the big chunk here: https://forum.snapcraft.io/t/problem-with-network-access-in-strict-confinment/5059/4
<zyga> the seccomp profile is hard to read when it's full of OMG HEADER
<mborzecki> wow, that's one awkwardly formatted post
<mvo> zyga: please reload
<zyga> mvo: thank you very much!
<zyga> mborzecki: man, that's a long PR still
<zyga> mborzecki: did you spellcheck it?
<zyga> reading it quickly I suspect it's not fully clean yet
<zyga> but maybe shell is tricky on me
<zyga> mvo: https://github.com/snapcore/snapd/pull/5093
<mup> PR #5093: spread: bump bionic snapshot date <Critical> <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5093>
<mborzecki> zyga: non yamls parts looked fine, although i don't like how global variables come into play, but it's either that or sprinkling more checks around the code making it even less readable
<mborzecki> zyga: as for yaml, it'd be nice to have tool (niemeyer?) that extracts keys, dump that into temp files and run them through shellcheck, something we could use in our tests too
<zyga> yeah
<zyga> did you run spellcheck on the .sh parts?
<mborzecki> spellcheck? thought you meant shellcheck :)
<zyga> shellcheck
<zyga> sorry, spellchecker "corrects" things
<mborzecki> hahaha
<mborzecki> zyga: no i did not shellcheck it myself, but this commit looked like it's making shellcheck shut up https://github.com/snapcore/spread-images/pull/10/commits/ab849c9f1f8cb91cde4395fcf69e245c9e377b56 and those are legit issues flagged by the checker
<mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
<mborzecki> zyga: hmm `yq -r < spread.yaml .prepare | shellcheck -`
<zyga> oooooh
<zyga> man
<zyga> can we do that for all our jobs?
<mborzecki> yup, why not ;) there's only a handfull of keys that take shell scripts
<zyga> mborzecki: can you do it? :)
<zyga> find -name task.yaml -exec ...
<zyga> I would suggest to write spread-shellcheck helper
<mborzecki> zyga: yup, let me play with it a bit
<mvo> cool stuff!
 * mvo hugs mborzecki 
<mup> PR snapd#5094 opened: tests: testrun with debug to get to the bottom of the 18.04 failure <Created by mvo5> <https://github.com/snapcore/snapd/pull/5094>
<pstolowski> morning
<zyga> hmm
<zyga> mvo: why do we need the -extra package anyway?
<zyga> is it for squashfs? I hope not
<kalikiana> moin moin
<mvo> zyga: let me check
<mborzecki> zyga: so i have the script https://paste.ubuntu.com/p/2QWv85s5bG/ but fixing everything will be an arduous task
<zyga> mborzecki: let's add it but make it optional
<zyga> mborzecki: we can fix things little by little
 * zyga would love a review for https://github.com/snapcore/snapd/pull/5081
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<mvo> apw: hey, quick question - what happened to linux-image-extra-$(uname -r) in bionic? is that gone for good and should we use linux-image-extra-$(uname -r) now if we need this? the kernel package changelog is a bit sparse on details about this
<apw> mvo, i assume you mean linux-modules-extra-* ... and yes that is the new name, and there should be no circumstance where you need to know its name
<zyga> hmm :D
<zyga> reality disagrees but I will look from the side and listen
<mvo> mborzecki: I have two super long train rides in front of me in the next few days (4 actually in total). so fixing the scripts sounds prefect?
<zyga> mvo: 4 in total!?
<mvo> apw: oh, it is a normal dependency now?
<mvo> zyga: well, 2 trips with one inbound, one outbound
<zyga> ah, you have to change trains?
<apw> zyga,  was that for me?
<mvo> apw: for me
<apw> mvo, it is a normal dependency of the right meta package
<mvo> apw: cool, I will see if our tests are happy without and if it gets pulled in automatically. t
<mvo> apw: this is GCE so things might be a bit different
<apw> maybe indeed, but regardless that is the new naw
<apw> name if you need it
<mvo> apw: thank you!
<mvo> zyga: I was suspecting we need -extra for the broadcom asic test but it seems it is not in there (at least not under linux-kernel-bde.ko)
<zyga> ahhh
<zyga> makes sense
<mvo> zyga: anyway, test is running, we will know shortly :)
<mborzecki> mvo: i think i can automate some/most of the simple fixes
<mvo> mborzecki: cool
<mborzecki> it's basically adding #shellcheck source=tests/lib/<file> when sourcing, and quoting "$TESTSLIB" in redirects
<mvo> mborzecki: that is even better
<mvo> mborzecki: yeah, that sounds pretty good
<zyga> mborzecki: it would be nice if spread -shellcheck would be a thing
<zyga> mvo: what I find odd is that it worked before
<zyga> is that rename a thing that happened just now?
<mup> PR snapd#5093 closed: spread: bump bionic snapshot date <Critical> <Simple> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5093>
<mvo> zyga: it happend some days ago but I suspect is that gce kernenls packages are updated less often maybe
<zyga> aha
<mvo> zyga: 5094 was run without errors but for some reason the machine discard hung. I will restart, but it looks like this fixes the 18.04 issues
<zyga> fingers crossed, thank you for pursuing that
 * zyga is super sleepy today
<zyga> sorry folks, last night was not very good
<pstolowski> #5075 looks like a trivial PR, needs 2nd review
<mup> PR #5075: snap/env: fix env duplication logic <Simple> <Created by didrocks> <https://github.com/snapcore/snapd/pull/5075>
<mvo> 5094 is even more trivial and needs a review (with the added bonus of unblocking tests!)
<zyga> done
<mup> PR snapd#5094 closed: tests: drop `linux-image-extra-$(uname -r)` install in 18.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5094>
 * mvo hugs zyga 
<zyga> irccloud supports slack
<mvo> zyga: in 5075 you write: "it does not seem to work in practice". how did you test?
<zyga> I opened a terminal with dash in it
<zyga> echo'ed the expression
<mup> PR snapd#5095 opened: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/5095>
<zyga> and got an empty string
<zyga> and then confirmed that I have the desired value in the full variable already
<mup> PR snapd#4750 closed: store: getStructFields now take pointers <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4750>
<mup> PR snapd#4443 closed: [RFC] snap: improve error for snaps not available in the given context <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4443>
<pedronis> mvo: 4750 was too old, I think merging it broke master
<pedronis> I mean it was green but from too long ago
<pedronis> afaict it other things need fixing now
<pedronis> mvo: I get a panic on master trying to run store tests
<pedronis> (another issue of PRs being around forever)
<mvo> pedronis: uh, ok. let me have a look
<pedronis> mvo: the fix is trivial probably, mostly pointing out that we need to be  a bit careful with old green stuff :/
<mvo> pedronis: indeed, we should probably ask the old PRs to remerge master
 * Chipaca on a very flaky connection rn
<ogra_> mvo, hmm, on core installs my /snap dir carries fragments from the core snap build recently (not sure when this started) ... is that wanted ?
<ogra_> ogra@localhost:~$ ls /snap/
<ogra_> README  bin  XXXXXX  XXXXXX-kernel  core  manifest.yaml  snapcraft.yaml
<ogra_> (the XXXXXX snaps are customer snaps (kernel/gadget) ... i'm referring to the yaml files)
<Chipaca> ogra_: is that core getting built with snapcraft?
<ogra_> Chipaca, thats just core from the store
<ogra_> edge channel
<mvo> Chipaca, ogra_ - it is, I think the new snapcraft is dropping those files now
<ogra_> looks odd
<mvo> yeah, looks like we need some cleanup there
<ogra_> you might want to add info about these files to the README perhaps
<ogra_> (if they are wanted to be kept there)
<Chipaca> I don't know why, but yes, if it does the manifest thing snapcraft puts it in /snap in the snap
<ogra_> yeah
<ogra_> which in the core snap becomes /snap
<Chipaca> yes
<Chipaca> which is probably fine
<ogra_> well
<Chipaca> a little surprising, but having manifest.yaml is nice
<ogra_> ogra@localhost:~$ ls /snap/core/current/snap/
<ogra_> manifest.yaml  snapcraft.yaml
<ogra_> you haven them twp levels down as well :)
<ogra_> *two
<Chipaca> ogra_: d'oh
<ogra_> (though indeed they are the same files effectively)
<Chipaca> ogra_: so it's writable-paths copying them over
<ogra_> well ...
<Chipaca> ogra_: all your problems are initramfs-tools' fault
<ogra_> writable paths mounts core as / first
<ogra_> then bind-mounts writable on top and populated
<ogra_> *populates
<ogra_> so they *are* the same files
<Chipaca> ogra_: I think you're agreeing with me
<ogra_> no, i wasnt initially ... but after a test i do now :P
<ogra_> gra@localhost:~$ sudo touch /snap/manifest.yaml
<ogra_> ogra@localhost:~$ sudo touch /snap/core/current/snap/manifest.yaml
<ogra_> touch: cannot touch '/snap/core/current/snap/manifest.yaml': Read-only file system
<ogra_> so yeah, somehow they are copied around
<Chipaca> ogra_: so it's probably set to sync or compat or whatever and we don't want it to be
<ogra_> well, you want /snap/bin synced
<Chipaca> ogra_: you do?
<ogra_> and you want to have all the mountpoints and README too
<ogra_> well, you want it writable at least
<Chipaca> ogra_: /snap needs to be writable
<ogra_> right
<Chipaca> ogra_: because that's where we create /snap/ogras-killer-snap/
<Chipaca> ogra_: snapd creates the README i think (but i'm not certain), and /bin
<Chipaca> ogra_: i mean /snap/bin
<ogra_> yeah and the symlinks in there
<Chipaca> ogra_: so it _should_ just work if it's mounted to writable without any fanciness
<Chipaca> ogra_: the symlinks are created on snap install
<Chipaca> ogra_: they won't be in core
<ogra_> /snap                                   auto                    persistent  transition  none
<ogra_> not synced ... only persistent
<Chipaca> ogra_: wasn't "transition" the one that copied things over?
<ogra_> oh, right
<ogra_> so we want that dropped
<Chipaca> ogra_: i think we should try :-) wouldn't be surprised if people depended on it at this point Â¯\_(ã)_/Â¯
<ogra_> (well, set to none effectively=
 * zyga needs to take a break, back pain sucks today
<zyga> I cannot concentrate on anything
 * Chipaca hugs zyga 
<ogra_> mvo, bug 1766845
<mup> Bug #1766845: /snap/snapcraft.yaml and /snap/manifest.yaml in rootfs on ubuntu-core installs <snapd:New> <https://launchpad.net/bugs/1766845>
<mvo> ogra_: ta
<mup> PR snapd#5096 opened: snap: improve error for snaps not available in the given context <Created by mvo5> <https://github.com/snapcore/snapd/pull/5096>
<ogra_> (i'd have coocked a patch but i'm super busy with customer stuff)
<mup> PR snapd#5097 opened: store: getStructFields takes pointers now <Created by mvo5> <https://github.com/snapcore/snapd/pull/5097>
<mborzecki> off to pick up the kids
<mborzecki> i'm down to 95 tests that still raise shellcheck errors
<mup> PR core-build#27 opened: config/etc/system-image/writable-paths: do not transition /snap  <Created by mvo5> <https://github.com/snapcore/core-build/pull/27>
<mvo> ogra_, zyga: ^- this is hopefully all we need
<zyga> ack
<ogra_> yeah
<ogra_> (acked)
<zyga> mvo: looks good, do you know why it was transitional to begin with?
<mvo> zyga: I don't, I suspect cargo-culted
<pedronis> or it comes still from when building images really installed snaps?
<mvo> pedronis: yeah, I was thinking about this, it might be but that was really a long time ago. could still be a leftover
<mup> PR snapd#5097 closed: store: getStructFields takes pointers now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5097>
<mup> PR core-build#28 opened: new ubuntu-core-config 0.6.40+ppa49 upload <Created by mvo5> <https://github.com/snapcore/core-build/pull/28>
 * kalikiana out for a break, back in a bit
<Chipaca> mvo: i'm skipping the standup today: half my face is asleep, and the other half is in moderate pain
<Chipaca> mvo: i hope to be feeling better before eod though :-)
<mvo> Chipaca: uhh, ok. good luck and get well!
<Chipaca> niemeyer: about the tempfile thing we discussed yesterday, no can do (i just need the name, not an os.File). I might need to land it as is and then in a followup move it to use renameat2(2)
<niemeyer> Chipaca: I think as long as we're using something less predictable, it should be okayish
<Chipaca> mvo: getting well was the reason of the exercise, it's just painful the first few hours post
<Chipaca> niemeyer: k
<niemeyer> Chipaca: I'm not sure about how to do that and still some of the logic in there tho
<niemeyer> Chipaca: I mean, IIRC it's actually reading left-behinds
<Chipaca> niemeyer: it does a sanity check on the filename, which can still be done
<niemeyer> Chipaca: Cool
<Chipaca> niemeyer: in fact i can probably keep that bit the same
<Chipaca> niemeyer: just that instead of it adding .~N~ to the filename, with N sequential, it can be a 9-digit random thing
<niemeyer> Chipaca: Yeah, it's fine if it's known.. I wasn't sure if it was actually trying to read from disk, but I recall you mentioned follow ups actually use the state now
<mup> PR core-build#27 closed: config/etc/system-image/writable-paths: do not transition /snap  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/core-build/pull/27>
<kalikiana> re
<mborzecki> favourite piece from our tests so far:     echo "Ensure `snap advise-snap --command` lookup works"
<mborzecki> notice the backticks
<mup> PR core-build#28 closed: new ubuntu-core-config 0.6.40+ppa49 upload <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/28>
<zyga> mborzecki: NICE :)
<zyga> mborzecki: I think having shellcheck on tests has been long overdue
<zyga> kudos for figuring out a smart way to implement it
<mup> PR snapcraft#2087 closed: ci: setup AppVeyor <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2087>
<roadmr> hey folks, an announcement, snap store downloads are failing intermittently, we're investigating
<kyrofa> roadmr, my automated review is taking an abnormally long time as well, getting "
<kyrofa> Task c0daed77-5616-4837-9e5f-e7d972405a0f is waiting to be retried."
<zyga> roadmr: ack, thank you for sharing
<roadmr> kyrofa: yes, automated reviews require downloading the snap from the service that's having trouble.
<kyrofa> roadmr, makes sense, thank you
<sergiusens> kyrofa: fwiw I cleared the queue for snapcraft by discarding the offending snap with the task fail
<kyrofa> sergiusens, yeah this is DPL stuff
<sergiusens> ah
<mup> Issue snapcraft#2029 closed: Proper error for apt hash sum mismatches <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2029>
<mup> Issue snapcraft#2030 closed: Properly invalidate the cache if sources change <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2030>
<mup> PR snapcraft#2079 closed: repo: catch error updating the package cache <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2079>
<zyga> mborzecki: hey
<zyga> mborzecki: do you have `entr` command on your system?
<mborzecki> zyga: nope
<zyga> is it available in arch?
<mborzecki> zyga: it's in aur
<zyga> can you grab it please? :-)
<mborzecki> zyga: ok, got it now
<zyga> ok,
<zyga> can you fetch my remote please
<zyga> then checkout zyga/tweak/make-live-check
<zyga> and run make live-check
<roadmr> hello folks, (kyrofa) we believe the snap store download situation is under control, please do report any slowness/timeout issues you see
<kyrofa> Thanks roadmr
<zyga> roadmr: what was the issue?
<roadmr> zyga: the same as yesterday's :) only this time we got it under control much faster because we'd seen it yesterday
<zyga> oh, and what was broken yesterday?
<kyrofa> roadmr, downloads seem to be hovering around 150-200k, where typically they're like 8M
<roadmr> kyrofa: which snap are you looking at?
<kyrofa> Nextcloud
<kyrofa> Takes forever to get started, too
<roadmr> zyga: soma load balancing issues with our CDN which was slamming one of our origin servers
<roadmr> kyrofa: oh you mean when you do "snap install/download" it takes a moment to actually start? hmm.
<kyrofa> Yeah, just shows the snapd .oOo.oOo... ah, and now " Download snap "nextcloud" (6519) from channel "beta/pr-519" (received an unexpected http response code (503) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/njObIbGQEaVx1H4nyWxchk1i8opy4h54_6519.snap?t=2018-04-25T18:00:00Z&h=82184e2ff20695f22f99c8093efdc6c7086e970e)"
<zyga> roadmr: aha, interesting, thanks for sharing
<zyga> mborzecki: how do you like it?
<zyga> mborzecki: I'd like to propose it
<zyga> we'd have a skeleton makefile where we could again propose changes
<roadmr> kyrofa: oh wow... sorry about that, we're fiddling some knobs now, hang on
<mup> PR snapd#5098 opened: Makefile: add initial makefile with live-check command <Created by zyga> <https://github.com/snapcore/snapd/pull/5098>
<zyga> oho
<zyga> I think mborzecki's machine didn't like running unit tests that much
<zyga> pstolowski: how about you
<pstolowski> zyga: is it about zyga/tweak/make-live-check ?
<zyga> yep
<pstolowski> zyga: will give it a go in a moment
<zyga> thanks
<zyga> I have it set to half of my 2nd screen
<zyga> hmm
<zyga> and somehow I get this
<zyga> panic in store.go getStructFields https://www.irccloud.com/pastebin/KjSWfVjC/
<zyga> mvo: ^ does this ring any bells?
<mvo> zyga: yes, please merge master
<pedronis> yes, that's the thing that was broken on master for a bit
<pedronis> should be fixed now
<zyga> mvo: ah perfect
<zyga> yep, works now, thank you
<mup> Issue snapcraft#1707 closed: Implement deploy keyword for travis <enhancement> <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1707>
<pstolowski> zyga: what is entr there? i don't have that
<zyga> pstolowski: install it, it's a small helper that uses inotify
<zyga> invaluable tool once you know it :)
<pstolowski> zyga: allright, got it, running
<zyga> pstolowski: how do you like it?
<pstolowski> zyga: it's interesting idea and I can see how it may be useful for some; i personally prefer to run tests on request only, not on save - I save very often but only run tests when I know the code is more less ready
<zyga> pstolowski: the idea here is that you can save anytime you want but just glance at the other screen to see where you are
<zyga> and by the time you glance the tests may have finished
<zyga> (if we neuter the insanely slow seccomp test that dominates the whole test suite)
<pedronis> we have a lot of slow tests
<zyga> mvo: is there a way to tag that specific test (the one that compiles 10s of C files) as slow?
<pedronis> from some point of view
<zyga> pedronis: no, really, that's the slowest by far
<pedronis> IÂ find any suite that takes more than 1s kind of slow
<zyga> ah
<zyga> yeah but the general trend is that seccomp is slowest of the tree
<zyga> then other things are slower than they should be
<zyga> but not that terrible
<zyga> time to run tests per package https://www.irccloud.com/pastebin/Ps05PFvs/
<pedronis> anyway IÂ tend to often write tests first and be intersted only in the new ones
<pedronis> and then more in all
<zyga> oh, apparmor tests are slow
<zyga> they probably do something foolish
<zyga> like run real programs
<zyga> hmm
<zyga> odd, when I run apparmor tests alone they are not that lsow
<pedronis> at least here quite a few packates takes >10s
<zyga> what was that command that shows executables as they are started
<zyga> using netlink
<zyga> ha
<zyga> got it
<zyga> hmm
<zyga> no luck actually
<zyga> I don't know why that test is that much slower
<zyga> running the test (with prior compilation) https://www.irccloud.com/pastebin/ckQ1afb5/
<zyga> monitored processes/tasks during said test execution https://www.irccloud.com/pastebin/uPMQuQTe/
<zyga> pedronis: is there a nice way to profile go code?
<zyga> I tried using go tool pprof and go test -cpuprofile but it doesn't show anything sane
<zyga> the profile is 350~ bytes long usually
<zyga> and top10 shows nothing
<zyga> I also looked at https://bieker.ninja/go/2015/01/22/profiling-go.html but that confirms what I just did
<zyga> for the record:
<zyga> https://www.irccloud.com/pastebin/PJnCF5dM/
<mvo> zyga: I don't think we have a concept of slow tests currently
<zyga> mvo: yeah but golang does I think
<zyga> mvo: anyway, I think the goal is to fix the slow tests
<zyga> but maybe the seccomp one is more special
<zyga> I don't understand why tests are not showing up in any of the bechmark results
<zyga> mvo: offtopic, do you have time for a simple code review? https://github.com/snapcore/snapd/pull/5086
<mup> PR #5086: osutil,interfaces,cmd: use fewer hardcoded strings <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5086>
<Caelum> zyga: no response on the factory list either, I think we should just run the osc command to submit to factory, there are automated checks and that will give us some things to do
<zyga> Caelum: ack
<zyga> let's do that and let's see what happens
<zyga> thank you for trying
<zyga> it's sad that those MLs are so dad
<Caelum> no problem
<zyga> dead
<mup> PR snapcraft#2086 closed: tests: update metadata store integration test, no previous push required <Created by matiasb> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2086>
<mup> PR snapcraft#2105 opened: project_loader: recursively process after of remote parts <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2105>
 * kalikiana wrapping up for the day
<jdstrand> kenvandine: I did and will circle back around to it. note, there is a one week voting period so it isn't late yet
<jdstrand> kenvandine: oh heh, I answered your question from the other channel here :)
<kenvandine> lol
<kenvandine> that's cool :)
<mup> Issue snapcraft#2099 closed: Issues building snap from my favorite and best GUI RSS reader, Feedreader <Created by sirredbeard> <Closed by sirredbeard> <https://github.com/snapcore/snapcraft/issue/2099>
<mup> PR snapd#5099 opened: testutil: rename UNMOUNT_NOFOLLOW to umountNoFollow <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5099>
<mup> PR snapd#5100 opened: testutil: document all fake syscall/os functions <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5100>
<mup> PR snapd#5101 opened: testutil: don't dot-import check.v1 <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5101>
 * zyga wonders if anyone is up for three super trivial reviews
<mup> Issue snapcraft#1689 closed: Implement "on <arch> to" selectors (statements) in project_loader <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1689>
<mup> PR snapcraft#2088 closed: grammar: support compound on..to statement <enhancement> <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2088>
<jdstrand> sergiusens (cc sbeattie): hey, I've been working on the snap usn stuff. we noticed that libssl is in stage-packages for a ton of stuff. libssl is in the core snap. can you remind me why snapraft isn't defaulting to using the libs in core if they are there (excepting glibc, which I know snapcraft doesn't stage)
<sergiusens> jdstrand: we might not be cutting off the chain for stage-packages deps sooner than desired
<sergiusens> jdstrand: want us to have a sit next week and try things out to get to a better place?
<jdstrand> sergiusens: sure, we can chat about that
<kyrofa> Might be nice to have a solid contract about what is in the core snap/what we can rely on staying there
<kyrofa> I seem to remember things being removed in the past
<kyrofa> rsyslog?
<kyrofa> As I recall, we really have no idea what's in there. No manifest
<jdstrand> kyrofa, sergiusens: it was, then it was put back. there is a file in the core snap that cnapcraft could look at: /snap/core/current/usr/share/snappy/dpkg.list
<kyrofa> No way
<kyrofa> That's nice to see
<kyrofa> jdstrand, but what guarantee do we have that things won't be removed?
<kyrofa> Especially the way we need to stop apt's dependency crawling... it's kinda hard-coded and difficult to override
<jdstrand> kyrofa: that is a question for the snapd team, in particular mvo
<jdstrand> kyrofa: my understanding is that nothing is supposed to be removed
<kyrofa> That _was_ mine as well, until rsyslog
<kyrofa> If the snapd folks agree, then we're good
<jdstrand> I can't speak for them, but they put it back. I think it is understood that they can't just remove stuff once it is there
<jdstrand> I mean, not everyone uses snapcraft
<jdstrand> and people can 'organize' things away so they use the core stuff too
<jdstrand> so, we shouldn't be removing stuff anyway
<kyrofa> Yeah I agree
<jdstrand> iirc, rsyslog was a learning opportunity. it hasn't come up again
<zyga> jdstrand: hey
<zyga> jdstrand: how are preparations for next week?
<jdstrand> zyga: I think I have one in the bag (snap usns). the resquash with electron-builder I'll look at tomorrow
<zyga> woot, USN will certainly improve the ecosystem
<jdstrand> yes. looking at how many things are out of date, that is *definitely* true
<zyga> what's step two? mass mailing?
<zyga> jdstrand: if you feel like taking a 3 minute break I made some super short and trivial PRs and labelled them as "simple": https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+author%3Azyga+label%3ASimple
<mup> PR snapcraft#2106 opened: nodejs plugin: lazy load the required tarballs <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2106>
<sergiusens> jdstrand: oh yeah, I am happy to see that USNs are coming along!
 * zyga EODs
<diddledan> popey or Wimpress: https://forum.snapcraft.io/t/request-to-allow-classic-confinement-on-the-mget-snap/4999
<diddledan> (I don't think ev is in here is he?)
<jdstrand> zyga: not today. I'll try for tomorrow
<diddledan> jdstrand: is this user correct? they posit that /dev/stdout and /dev/stderr are blocked.. https://forum.snapcraft.io/t/how-do-i-get-service-logs-of-a-failing-ot-install-snap/3875/3
<jdstrand> diddledan: that's correct. we can probably allow that
 * jdstrand adds a todo
<diddledan> \o/
<diddledan> I totally think we should pronounce todo as toedoe. then my teenage self would have been reading it correctly all along
<jdstrand> heh
<diddledan> kalikiana: thankyou for fixing this one: https://github.com/snapcore/snapcraft/pull/2105
<mup> PR snapcraft#2105: project_loader: recursively process after of remote parts <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2105>
#snappy 2018-04-26
<mup> PR snapcraft#2106 closed: nodejs plugin: lazy load the required tarballs <bug> <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2106>
<mup> PR snapcraft#2100 closed: build_providers: new build provider using multipass <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2100>
<mup> PR snapcraft#2107 opened: Release changelog for 2.42 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2107>
<sergiusens> diddledan: if you can add notes to the PR and confirm it working it would be great
<mup> PR snapd#5102 opened: tests: new utility to save and restore the snap state <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5102>
<zyga> good morning
<mborzecki> zyga: hey
<zyga> mborzecki: I sent a few extra trivial PRs
<zyga> mborzecki: could you please look at them, they have a few lines to a few dozen at most
<mup> PR snapd#5101 closed: testutil: don't dot-import check.v1 <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5101>
<zyga> Thanks!
<zyga> I feel great today, hopefully this will be a good day for coding :-)
<mup> PR snapd#5099 closed: testutil: rename UNMOUNT_NOFOLLOW to umountNoFollow <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5099>
<mborzecki> the tests are shellcheck clean now
<mborzecki> 249 files changed, 1338 insertions(+), 797 deletions(-)
<mup> PR snapd#5086 closed: osutil,interfaces,cmd: use fewer hardcoded strings <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5086>
<zyga> Wooooot
<zyga> Send the patches!
<mborzecki> it's all here now https://github.com/bboozzoo/snapd/commits/bboozzoo/spread-shellcheck i need to chop the last patch into smaller, reviewable pieces
<zyga> Ok
<zyga> Use things that qualify for simple :-)
<mborzecki> ok, i need to go out for 2-3h now, will be back ~11
<zyga> Ok
<ogra_`> /join #ubuntu-release-party
<ogra_`> oops
<zyga> Oh
<mup> PR snapd#5100 closed: testutil: document all fake syscall/os functions <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5100>
<pstolowski> mornings
<zyga> Hey
<Chipaca> zyga: I think I addressed your concerns with #4983
<mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<zyga> looking
<zyga> Chipaca: done
<zyga> Chipaca: do you want to look at https://github.com/snapcore/snapd/pull/5081
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> I could use it to propose the fix for the 1st layout issue
<Chipaca> looking
<Chipaca> zyga: ok,  question time
<zyga> I'm all ears
<Chipaca> zyga: in /foo/bar/froz with depth 2
<Chipaca> zyga: see the doctor about that
<Chipaca> zyga: why is 'right' /foo/bar/{*,*/,froz} rw ?
<Chipaca> why even have froz there if you have *?
<zyga> that's just simplicity, yes, we could special case that last part
<zyga> since froz is covered by * and froz/ (if it was a directory) would be covered by */
<Chipaca> zyga: ok, how about, in /foo/bar/baz/froz with depth 2
<zyga> ok
<Chipaca> zyga: would right be /foo/bar/{*,*/,baz/froz} rw ?
<zyga> no
<zyga> it would be, /foo/bar/{*,*,baz/{*,*/,froz}
<zyga> (the rw, part is separate so I will omit it)
<zyga> ah., I missed } above :)
<zyga> it would be, /foo/bar/{*,*,baz/{*,*/,froz}}
<zyga> it would be, /foo/bar/{*,*/,baz/{*,*/,froz}}
<Chipaca> zyga: I definitely don't understand then
<zyga> sorry, this one should be it :-D
<Chipaca> it seems the right-hand thing could always be omitted
<zyga> omitted how?
<Chipaca> zyga: I don't remember if */ implies */* and  */*/
<zyga> * is any file, */ is any directory
<Chipaca> zyga: but even if it doesn't, it seems just using *s always covers the explicit case
<zyga> ** implies any file and directory recursively forever
<Chipaca> zyga: i.e. /foo/bar/{*,*/,*/{*,*/}}
<Chipaca> what does adding the explicit names give you, that this doesn't?
<zyga> it hands out different permissions
<zyga> note that this allows you to make /foo/bar/<any file or directory here but not deeper>
<zyga> expand the version as implemented
<zyga> and the one with */,*
<Chipaca> zyga: so it's any file or directory along this path but not parallel to it
<Chipaca> ie /foo/bar/baz/froz at 2 would let you do /foo/bar/boo, /foo/bar/baz/boo, but not /foo/bar/meep/vorp
<Chipaca> ?
<zyga> you can do /foo/bar/<anything here but not deeper> yes
<zyga> it's an abbreviation of multi-line variant of that
<zyga> I wanted to avoid **
<zyga> which is like _anything_ flies
<Chipaca> zyga: what's the use case for it? when do you want to allow this and just this?
<zyga> for writable mimics specifically
<Chipaca> zyga: also p.s. 'cnt' as a variable name reads wrong (just noticed) :-)
<zyga> count :)
<zyga> ok
<Chipaca> maybe i've just got a dirty mind :-)
<zyga> https://github.com/snapcore/snapd/pull/5074/commits/eb6d997ab607ecee966de5deffb87a83684e6fe3
<mup> PR #5074: many: allow mimics in parents of layout <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/5074>
<zyga> Chipaca: I will change it
<zyga> Chipaca: this is the consumer of that patch
<zyga> (probably needs small rebase)
<zyga> look at the writableMimicProfile there
<zyga> Chipaca: look at the test diff below
<zyga> it replaces a list of rules
<zyga> with one rule that expands to that and then some
<Chipaca> zyga: I still don't get why you need * if you already know the name
<zyga> because it may be at any earlier stage
<zyga> if we want to make a layout at /usr/share/magic/software
<zyga> but magic isn't in the core snap
<zyga> we need to construct a mimic at /usr/share
<zyga> and this rule grants that
<zyga> also let's say magic exists but software doesnt
<zyga> then we need to make one at /usr/share/magic
<zyga> this is a generalised way to make those
<Chipaca> but that would mean something like /usr/share/{,magic/{,software}}
<zyga> yes
<zyga> but then you realise what is needed to make a mimic
<zyga> you need to mount tmpfs on /usr/share
<zyga> then make *any file or directory there*
<zyga> and bind mount the originals back
<zyga> so you need the * and */ rules
<zyga> see?
<Chipaca> zyga: yes
<Chipaca> zyga: thanks
<Chipaca> zyga: mostly +1, holding off the actual +1 because I think it needs more tests
<Chipaca> zyga: should be easy to add them though :-)
<zyga> ack, looking
<zyga> Thank you for looking, this is tricky stuff :)
<Chipaca> zyga: it is, and some of the tests I ask for are probably silly _today_ :-) but might help us at some point down the road
<mvo> zyga: I got a report about a "apparmor="DENIED" operation="change_onexec"
<mvo> info="label not found" error=-2 profile="/usr/lib/snapd/snap-confine"" does that ring a bell? is that the "profiles vanish on boot" issue?
<mvo> "cannot
<mvo> change profile for the next exec call: No such file or directory"
<zyga> yes
<zyga> that or pre run-waits fix
<zyga> mvo: what more do you know?
<zyga> did you experience that/
<mborzeck1> re
<mborzecki> that took longer than i anticipated
<mvo> zyga: I forwarded you a mail with all the info I have
<zyga> checking
<mvo> zyga: thank you!
<om26er> popey: hey! android-studio has 3400+ installs (and ever growing), impressive ?
<popey> wow
<popey> thats great!
 * ogra_` is surprised that mjpeg-streamer ha over 1000 already ... 
<ogra_`> *has
<om26er> popey: how is sublime doing ?
<popey> We found that if we put an application in the featured list, it *always* jumps in userbase
<popey> om26er: over 4k!
<ogra_`> i wouldnt have thought such a trivial tool can be so popular
<mvo> sergiusens: re 1764998> is corebird a sideloaded snap?
<om26er> wow!
<om26er> for a tool like Android Studio that 3400+ is an impressive count, give that a few months and it'll surpass 10k
<sergiusens> mvo: no, if you have the bug report I believe I added snap info for corebird, I still see the issue btw
<mvo> sergiusens: always with the same snap?
<mvo> sergiusens: or is thta random?
<sergiusens> mvo: just that one
<mvo> sergiusens: and do you see any pattern? Like profiles vanish after auto-refresh ? or after boot? or anything?
<sergiusens> mvo: certainly after reboot, not consistent
<tomwardill> mvo, sergiusens: huh, that bug ticket and enable/disable just fixed my corebird. It's after reboot almost definitely for me, and sometimes after an app restart (maybe after a refresh while the app is open?)
<tomwardill> I also only see it on that snap
<sergiusens> mvo: this snap is feature packed with interfaces (including `content`)
<mvo> tomwardill, sergiusens thanks! that is useful information
<mvo> zyga: ^-- looks like a certain property of the snap makes it vanish
<zyga> hmm
<mvo> zyga, sergiusens fwiw, I installed corebird and rebooted 5 times, so far so good, I suspect more needs to happen to trigger it, I need to run in a bit but will try to figure out more
<ogra_`> sergiusens, bah ... whats that ? https://paste.ubuntu.com/p/zWP3m9ktMx/
<ogra_`> (the part is plainly using the make plugin, caring for the cross stuf on its own)
<ogra_`> is there a way to override that ?
<zyga> sergiusens: can you install this unit on your sytem
<zyga> lp-1764998.service https://www.irccloud.com/pastebin/GU7D0QRT/
<zyga> in case it happens again
<zyga> mvo: ^
<mvo> zyga: nice!
<zyga> journald contains the output so we can inspect it later
<sergiusens> ogra_`: create snap/plugins/x_make.py
<ogra_`> sergiusens, thanks ... found another solution (using the deb :P ... )
<zyga> Chipaca: I think https://github.com/snapcore/snapd/pull/5081 is ready for another look
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> hmmm
<zyga> I _may_ have theory
<Chipaca> zyga: +1, although I note you didn't add tests for wonky depths :-)
<zyga> Chipaca: because it's already there :)
<zyga> well
<zyga> not for negative depths
<zyga> that's a good idea
<zyga> https://github.com/snapcore/snapd/pull/5081/files#diff-16cc40a4b635e1e0e4c9d520342fd500R295 is deeper then than the number of directories
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> but yeah
<Chipaca> ah, the 4 is bigger
<Chipaca> k
<zyga> orders a beer, orders a "", orders 252341342352
<zyga> :-)
<zyga> I'll do it
<Chipaca> quite
<zyga> pstolowski: reviewed the Undesired field branch
<Chipaca> pretty much
<zyga> pstolowski: let's talk in 10 minutes
<zyga> I have an idea I want to run by you
<pstolowski> zyga: thanks, sure
<pstolowski> zyga: interesting remark about possibly dropping auto flag. hmm
<zyga> pstolowski: as I wrote below, not just the auto flag, all but the Undesired flag should be dropped
<zyga> (perhaps the interface type should remain as well but it is unclear what to do when it changes under us)
<mup> PR snapd#5103 opened: tests: shellcheck spread tasks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5103>
<mborzecki> basic setup for shellchecking spread files ^^
<Chipaca> mborzecki: hah. I'd added it to spread, your approach seems a lot more polite
<mborzecki> Chipaca: well, we could do it now ;) i have all the fixes
<mborzecki> jokes aside, shellcheck is terribly annoying with some of the warnings
<ogra_`> +1
<ogra_`> totally overzealous at times
<Chipaca> ogra_`: aren't we all
<ogra_`> i pretend not to ... (but i'm really bad at that)
<Chipaca> ogra_`: https://www.youtube.com/watch?v=mLRjFWDGs1g&t=16s
<ogra_`> hahahaha
<ogra_`> now i want a moustache !
<pstolowski> niemeyer: hey, can you clarify on the one open question in the https://github.com/snapcore/snapd/pull/4358 (the naming of connect-slot-task vs slot-hook-task etc)? that's the last point that I potentially need to address once agreed on
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<niemeyer> pstolowski: Yeah, on it
<pstolowski> thanks
<niemeyer> pstolowski: But the PR hasn't changed at all yet?
<niemeyer> pstolowski?
<pstolowski> niemeyer: it did, it's just this one aspect that I haven't changed, all other points addressed and pushed
<niemeyer> pstolowski: That's not what I see in the actual PR
 * kalikiana lunch
<pstolowski> niemeyer: https://github.com/snapcore/snapd/pull/4358/commits/804c1b3f38463da4892d56fc181d03945c36b94e is addresseing all your comments from last review
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<niemeyer> pstolowski: I'm literally looking at https://github.com/snapcore/snapd/pull/4358/files
<niemeyer> pstolowski: I can see both the code and the comment in the actual PR
<pedronis> niemeyer: I asked him to put hook in those names, because we have "connect" tasks and are not those tasks, so I find that confusing
<pstolowski> niemeyer: ah, you're right, looks like the Conversation summary didn't show them and I missed those... sorry about that
<pstolowski> niemeyer: so I missed some of your comments re formatting, will fix in a few moments
<pedronis> ah, I was confused too
<pedronis> pstolowski: there's  "load more" thing in the middle of the comment lists
<pstolowski> pedronis: hah, indeed
<pstolowski> totally unexpected
<pedronis> it's a recent change
<pstolowski> :)
<pedronis> (also github is kind of slow for me recently)
<pstolowski> yes for me too.. i just had to restart my browser as github slowed it down to a halt
<pstolowski> i need to run to school, bb for standup
<mup> PR snapd#5104 opened: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5104>
<niemeyer> pedronis: Ack, sounds fine then
<niemeyer> pstolowski: ^
<mup> PR snapd#5038 closed: data/systemd: helper service for waking up the main snapd service <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/5038>
<mup> PR snapd#4399 closed: rewrite snappy-app-dev <Decaying> <Created by jdstrand> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/4399>
<mup> PR snapd#5105 opened: testutil,cmd: rename test helper of Lstat to OsLstat <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5105>
<thresh> nice, new snapcraft store lookanfeel
<mup> PR snapd#5106 opened: testutil: add test helper for SysLstat <Created by zyga> <https://github.com/snapcore/snapd/pull/5106>
<kalikiana> re
<thresh> jdstrand, updated the apparmor/vlc/link bug with an info from ubuntu 16.04 - same thing is happening there it seems :O
<jdstrand> thresh: that's weird... jjohansen is watching the bug. thanks for the feedback!
<thresh> :)
<zyga> thresh: can you pass the URL please
<thresh> zyga, https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1766628 there you go
<mup> Bug #1766628: apparmor denies VLC to open files in devmode <apparmor (Ubuntu):New> <https://launchpad.net/bugs/1766628>
<thresh> it's quite hectic because I suck at bug reporting
<mborzecki> Chipaca: 1.9 breaks with your uid sample right?
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: if you hit a 'too many threads', reduce N to see the bug
<Chipaca> (also, get a slower cpu)
<Chipaca> (or was it a faster one)
<mborzecki> hmm broke very quickly ;)
<zyga> Chipaca: what do you think about https://github.com/snapcore/snapd/pull/5104
<mup> PR #5104: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5104>
<Chipaca> zyga: i'll look at it when i get back from the school run
<zyga> Thank you sir!
<thresh> should I file snapcraft bug at github or launchpad?
<zyga> launchpad please
<Chipaca> mborzecki: if it looks like a stack trace, it's not my bug
<thresh> allright
<Chipaca> mborzecki: mine is {something in brackets}
<Chipaca> mborzecki: main.Result{uidBefore:12345, uidDuring:12345, uidAfter:12345}
 * Chipaca runs
<mborzecki> Chipaca: yup, that's what I see, just made it a panic so it doesn't spam my terminal too much :)
<Chipaca> mborzecki: with all those goroutines it should be less spammy than a panic
<Chipaca> but, you do you
 * Chipaca really runs
<zyga> and in other news, when I'm not hacking on snapd I'm a super-hero on twitter ;-) https://twitter.com/keshavmail68/status/989503868730933248
<mborzecki> Chipaca: this looks really awkward https://paste.ubuntu.com/p/4q2wz2w739/
<zyga> mborzecki: who clones new threads when all threads are busy?
<zyga> which process does that
<zyga> is there a zygote in go?
<mborzecki> runtime does that, whenever all threads are blocked and you have runnable goroutine
<zyga> yeah but who is the parent
<zyga> it is relevant
 * cachio lunch
<mborzecki> GOMAXPROCS=1 makes it go away
<zyga> mborzecki: "let's all write in C" ;-)
 * zyga -> break
<zyga> it rains like crazy so  no walk for me
<zyga> but I can cook now :)
<mborzecki> race detector not very helpful, too many goroutines
<Chipaca> mborzecki: for extra fun, pass uid
<Chipaca> mborzecki: ie for uid:=1; uid<100000; uid ++ { go f(uid, ch)  }
<mborzecki> hm the channel buffer is short, so that's where the conetntion comes from, more threads spawned as goroutines can run, now if syscall is a scheduling point, could it happen so that a thread is spawned from a locked thread which is running under different uid?
<mborzecki> Chipaca: does that make any sense?
<Chipaca> mborzecki: if locked threads are still candidates for cloning yes
<sergiusens> mvo zyga btw, it is observable in lxd, the next exec call thing https://bugs.launchpad.net/snapcraft/+bug/1760514
<mup> Bug #1760514: cannot change profile for the next exec call: No such file or directory <Snapcraft:New for kalikiana> <https://launchpad.net/bugs/1760514>
<mborzecki> Chipaca: https://github.com/golang/go/blob/master/src/runtime/proc.go#L1835 so they check if a thread is locked
<mborzecki> (at least in 1.10)
<zyga> Ack, i am eating lunch now but I will check soon
<mborzecki> Chipaca: but not in 1.9? https://github.com/golang/go/blob/release-branch.go1.9/src/runtime/proc.go
<Chipaca> mborzecki: yeah, 1.10 saw work in this area
<Chipaca> mborzecki: there's a change in api which probably had them look at the code and go wtf :-)
<mborzecki> Chipaca: https://github.com/golang/go/commit/2595fe7fb6f272f9204ca3ef0b0c55e66fb8d90f
<zyga> Ha
<zyga> This answers my question
<zyga> The zygote/template thread
<zyga> Lack of that would explain what you saw
<Chipaca> heh
<mborzecki> Chipaca: le's avoid contention then
<Chipaca> //go:nocontention
<Chipaca> mborzecki: having a mutex held around the lockosthread?
<Chipaca> that seems to do the trick
<Chipaca> did I just kill the mborzecki
<zyga> - Download snap "test-snapd-openvswitch-support" (11) from channel "stable" (received an unexpected http response code (503) when trying to download https://068ed04f23.site.internapcdn.net/download-snap/Pe3FPk3JcUeEuBMT3As6sF5V9Yle5MBb_11.snap?t=2018-04-26T19:00:00Z&h=ee1bb7faf045ee33a046739c4f22f2a57fb01198)
<zyga> store is wonky again?
<Chipaca> zyga: who're you calling wonFIVE OH THREE
<roadmr> NO CARRIER
<Chipaca> I'm glad I got the tone right :-)
<tomwardill> zyga: unfortunately, yes. Recovering (hopefully) now.
<zyga> tomwardill: thank you for the note
<zyga> anyone wants to take a trivial rename: https://github.com/snapcore/snapd/pull/5105
<mup> PR #5105: testutil,cmd: rename test helper of Lstat to OsLstat <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5105>
<zyga> mborzecki: reviewed your spread checker
<mborzecki> zyga: thanks
<mborzecki> Chipaca: huh, tried to cherry-pick some relevant commits, ran into conflicts, cherry-picked more commits, more conflicts
<Chipaca> mborzecki: seriously a mutex around the lock-to-thread leaves me unable to reproduce the issue
<Chipaca> mborzecki: that's probably good enough :-)
<mborzecki> Chipaca: yup
<zyga> anyone? :)
<zyga> it's just a bunch of renames
<Chipaca> zyga: I'm against all renames for ever
 * Chipaca probably needs more tea
<mborzecki> Chipaca: at least it was fun to look into go runtime
<Chipaca> mborzecki: it is :-)
<zyga> Chipaca: you were saying?
<Chipaca> zyga: delete your account >:(
<zyga> pstolowski: replied
<zyga> Chipaca: thank you :)
<pstolowski> zyga: ty
<Chipaca> zyga: :-)
<Chipaca> I'm with pstolowski, let's get rid of all sucky stat calls
<zyga> s/sucky/portable/
<zyga> but yeah
<Chipaca> fstatat is where it's atat
<zyga> I have some of those done already but nobody will review a 3K branch
<pstolowski> niemeyer: naming question wrt your review comment - does AttrMap sounds ok for map[string]interface? or more verbose InterfaceAttributes?
<Chipaca> zyga: also, renameat2
<zyga> Chipaca: renameat2?
<Chipaca> zyga: renameat2.
<Chipaca> zyga: like renameat but with flags!
<zyga> yeah. I know it exists but are we using it?
<Chipaca> zyga: we are not, yet
<Chipaca> zyga: we would if we could but we can't so we don't
<Chipaca> a wild mvo appears!
<zyga> oh
<zyga> that's cool
<zyga> whiteout
<zyga> do you know there's DT_WHT
<zyga> but it's not used anywhere in the kernel
<mup> PR snapd#5105 closed: testutil,cmd: rename test helper of Lstat to OsLstat <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5105>
<pstolowski> he is watching us all the time
<zyga> hey, welcome mvo
<zyga> :)
<Chipaca> zyga: yes, whiteout might be good at some point; noreplace is the one that caught  my eye
<zyga> I like the exchange one
<zyga> I didn't know that such flags existed
<zyga> that's cool, thank you for sharing
<zyga> and about lstat
<zyga> our sponsor is this PR: https://github.com/snapcore/snapd/pull/5106
<mup> PR #5106: testutil: add test helper for SysLstat <Created by zyga> <https://github.com/snapcore/snapd/pull/5106>
<zyga> please click to know more :D
<roadmr> clickbait
<zyga> alleged clickbait
<roadmr> does anyone know if I can get snapcraft to show me raw http requests/responses via an env var or something similar?
<kyrofa> roadmr, no, debug mode will show you what APIs are being hit, but not raw
<niemeyer> pstolowski: Where is that?
<niemeyer> pstolowski: The Map suffix sounds unnecessary.. it also reminds me of a few other maps we already have there
<pstolowski> niemeyer: this was about passing map[...] to/from getDynamicHookAttributes and setDynamicHookAttributes
<Chipaca> var buf syscall.Stat_t
<niemeyer> pstolowski: I'm still not sure about what the question is
<pstolowski> niemeyer: yes, when we have a name for this map I can apply it in a few other places
<Chipaca> I mean, I know it's a buffer way down low, but calling it a buffer when it's a struct is a bit â¦ i dunno
<pstolowski> niemeyer: the question is about the name for the type
<zyga> Chipaca: can you bike shed on 5104
<zyga> mvo suggested something
<pstolowski> niemeyer: or maybe I misread your comment
<zyga> so if I'm going to tweak wording
<zyga> I want to know your opinion too :)
<pedronis> pstolowski: I think  it's about naming the return values (not their types)
<pedronis> if I remeber the comment
<pstolowski> niemeyer: ah, ok, i see
<Chipaca> zyga: hold my can of green paint
<Chipaca> #5104
<mup> PR #5104: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5104>
<pedronis> pstolowski: so } (plugAttrs, slotAttrs map[...
<pedronis> or something like that
<pstolowski> pedronis: yes yes i get that, just misread the intention
<pstolowski> thanks
<Caelum> zyga: if and when you do the osc command to submit to factory, let me know how it goes, or if you want, just add me to the devel project and I will do it myself, my obs id is rkitover
<zyga> Caelum: ah, I missed that I thought you had done it
<zyga> let me look
<zyga> submitting, just booting my opensuse box
<Caelum> awesome
<zyga> osc submitrequest system:snappy/snapd devel:languages:go
<zyga> created request id 601651
<sergiusens> ogra_: skull canyon is Intel
<mup> PR snapd#5106 closed: testutil: add test helper for SysLstat <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5106>
<zyga> popey: https://twitter.com/sysrich/status/989549287787909120
<zyga> Caelum: ^ I think we will have things to do soon :-)
<popey> zyga: yay
<zyga> Chipaca: thank you for the reviews!
<zyga> I just opened #5107 that fixes one of the three bugs pawel found
<mup> PR #5107: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
<zyga> it is now small and simple
<zyga> though I didn't use the simple tag :)
<mup> PR snapd#5107 opened: cmd/snap-update-ns,tests: mimic the mode and ownership of directories <Created by zyga> <https://github.com/snapcore/snapd/pull/5107>
<pstolowski> when I thought I found one bug, zyga turned it into three ;)
<zyga> pstolowski: with enough eyeballs all bugs are shallow
<pstolowski|afk> true that
<mup> PR snapd#5104 closed: overlord,systemd: store snap revision in mount units <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5104>
<roadmr> kyrofa: hm it may suffice, how do I enable debug mode?
<roadmr> (thanks btw!)
<kyrofa> roadmr, snapcraft -d <whatever>
<roadmr> thanks kyrofa !
<roadmr> kyrofa: ah interestingly - debug mode *does* give me a "Store error response:" and gives me a repr of the requests HTTPResponse object, which should contain what I need \o/
<kyrofa> roadmr, ah, you just wanted the response? Nice
<roadmr> yes, that should suffice for what I need :)
<om26er> is there going to be a Ubuntu Core 18 release today as well ?
<zyga> om26er: no
<zyga> om26er: core18 will still take some time to make
<zyga> there's a core18 snap but it's not the final version and it will grow and improve
<zyga> and it cannot be used for booting yet
<om26er> zyga: thanks!
<zyga> Chipaca: I killed the 15.04 references in systemd test
<zyga> Chipaca: should I go for it all and make that code consume snap.Info?
<mup> PR snapd#5108 opened: systemd: replace ancient paths with 16.04+ standards <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5108>
<Caelum> zyga: awesome
<zyga> google is having a bad SSL day: 2018-04-26 17:24:45 Cannot allocate google:ubuntu-18.04-64: cannot perform Google request: Get https://www.googleapis.com//compute/v1/projects/computeengine/zones: oauth2: cannot fetch token: Post https://accounts.google.com/o/oauth2/token: net/http: TLS handshake timeout
<mborzecki> bad-SSL-day, sounds like something taken straight out of Civilization series ;)
<kyrofa> zyga, cannot change profile for the next exec call: No such file or directory
<kyrofa> Help
<zyga> kyrofa: tell me
<kyrofa> zyga, looks like all that has happened recently is a few unrelated snaps automatically refreshed
<kyrofa> (not core, either)
<kyrofa> Getting this in syslog: Apr 26 10:56:01 Pandora kernel: [22703.874785] audit: type=1400 audit(1524765361.346:118): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="/snap/core/4486/usr/lib/snapd/snap-confine" name="snap.snapcraft-pr.init" pid=26853 comm="snap-confine"
<mup> PR #26: Feature/hw assign symlink <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/26>
<kyrofa> hw assign, that brings back memories
<zyga> kyrofa: can you please check if snap.snapcraft-pr.init apparmor profile is on disk
<zyga> I'm just debugging this issue with kissiel as we speak
<kyrofa> zyga, no, it seems not
<zyga> can you collect snapd logs please
<kyrofa> $ ls /var/lib/snapd/apparmor/profiles/*snapcraft-pr*
<kyrofa> ls: cannot access '/var/lib/snapd/apparmor/profiles/*snapcraft-pr*': No such file or directory
<zyga> from journald
<zyga> man
<zyga> what is the secret
<kyrofa> zyga, https://pastebin.ubuntu.com/p/Xyg4FJxPCr/
<kyrofa> Wait no, cut off
<zyga> that looks partial
<zyga> tip: | to cat
<zyga> pipe to cat to turn off "smart" features
<kyrofa> https://pastebin.ubuntu.com/p/htqqFMP4Sh/
<kyrofa> Indeed, journalctl always bites me with that
<zyga> man
<zyga> hmm hmm
<zyga> can you see that snap in "snap list"
<zyga> kyrofa: and can you please pastebin "snap changes"
<zyga> Apr 25 15:49:35 Pandora snapd[1892]: 2018/04/25 15:49:35.795290 helpers.go:217: cannot connect plug "network-bind" from snap "core", no such plug
<mup> PR #25: use the network-client cap instead of the old, deprecated networking cap <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/25>
<zyga> pstolowski|afk: ^ when would we show this message
<zyga> when the plug is gone
<zyga> it looks like the core snap has lost interfaces
<zyga> kyrofa: without rebooting, pease run "snap interfaces"
<kyrofa> zyga, https://pastebin.ubuntu.com/p/ZDYSfZ5GmD/
<kyrofa> Oh, sorry, doing snap changes now
<kyrofa> zyga, https://pastebin.ubuntu.com/p/4MZgmRmm97/
<kyrofa> zyga, and yes, snapcraft-pr is in `snap list`
<kyrofa> This has happened in the past, I do believe a reboot solves it, but I won't do that until you give me the go-ahead
<zyga> thanks
<zyga> hmm hmm hmm
<zyga> kyrofa: so let me put a timeline
<zyga> you booted
<zyga> did the snap work then?
<zyga> then you refreshed
<zyga> and noticed it is broken
<zyga> is that accurate?
<kyrofa> zyga, unfortunately it's a little more wishy-washy than that. I haven't rebooted for a day or two. I successfully used this snap yesterday, though. It has not been refreshed, but multipass has been, and I installed snapcraft (all yesterday). Other snaps seem to work fine, but I just tried using snapcraft-pr for the first time today, to be greeted by that
<zyga> ah, snapcraft-pr is a separate snap
<zyga> ok
<zyga> hmm hmm
<zyga> so
<zyga> I have a theory
<zyga> let me experiment for a sec
<zyga> can you ls -ld /var/lib/snapd/apparmor/profiles
<zyga> er
<zyga> sans the d
<zyga> so just ls -l ...
<zyga> if this is it than man
<zyga> I have screwed up badly
<kyrofa> https://pastebin.ubuntu.com/p/hCcxNXW2WS/
<zyga> thanks
<zyga> I wanted to see the timestamps mostly
<kyrofa> zyga, here is the `snap list` to compare against: https://pastebin.ubuntu.com/p/KspPkqMPqN/
<zyga> reproduced
<zyga> and I know what this is
<zyga> don't reboot yet though
<zyga> man
<zyga> I'm so so so ashamed of myself
<kyrofa> Haha, no problem
<zyga> in case I get under a bus
<zyga> this is the reason we need .6 https://www.irccloud.com/pastebin/KlGkPfRK/
<zyga> Chipaca: ^
<zyga> we will do 2.32.6
<zyga> please look to see if I got the same conclusion as you will
 * zyga curses silently
<zyga> it's a one char diff
 * zyga hugs kyrofa 
<zyga> I owe you and kissiel a beer for helping me find this
<zyga> this is not a new bug
<zyga> we had it since forever
<kyrofa> That would explain why I've hit it a few times, but typically just reboot
<kyrofa> zyga, oh no :P
<kyrofa> Hahahahahaha, I wondered if it was somehow related to that
<zyga> kyrofa: I just look at a patch that breaks it
<zyga> b1217a35b077ef67840cc2c6a18f2f7e9d3b3be7
 * zyga blames himself 
<zyga> sorry everyone
<kyrofa> fmt.Sprintf("snap*.%s*", snapName)?
<zyga> yes
<zyga> snap.%s.*
<kyrofa> Yep
<zyga> that's what's missing
<zyga> I'm reviewing the rest of the code for this
<zyga> and adding tests
<kyrofa> That's alright man, easy mistake to make
<zyga> and adding a commit message
<zyga> we have a helper that returns the right tinh
<zyga> (that I wrote)
<zyga> but I didn't use it
<zyga> man
<zyga> I suck
<zyga> niemeyer: bug fixed
<zyga> niemeyer: it's all my fault really, details in a PR soon
<kyrofa> zyga, I assume I'm okay to reboot now?
<kyrofa> Or, just reinstall it really
<zyga> kyrofa: yes
<zyga> but this won't fix it
<zyga> enable/disable
<zyga> but really
<zyga> man
<zyga> I'll have a fix shortly
<kyrofa> Yep, disable/enable worked
<kyrofa> I also just removed snapcraft. How dare it share my snap's name
<kyrofa> Even a portion
<Chipaca> kyrofa: snapcraft-pr, it's snapcraft but paginated
<kyrofa> Hahaha
<kyrofa> Better logging, of course
 * Chipaca wonders how many people actually use 'pr' these days
 * Chipaca is off to play stellaris for a while
<Pharaoh_Atem> zyga: you did the wrong thing here: https://build.opensuse.org/request/show/601651
<pedronis> zyga: https://github.com/snapcore/snapd/pull/4590#discussion_r166224513
<mup> PR #4590: many: allow constructing layouts (phase 1) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4590>
<pedronis> there seem to have also been a rebase there, so it's very hard to tell the story of how it was reviewed
<zyga> pedronis: that was subsequently removed
<zyga> and re-introduced with another PR
<zyga> but still, we missed that part in all the cases
<zyga> I took a break to setup a customer device but now I'm back to fixing this
<zyga> Pharaoh_Atem: yeah I got some feedback on twitter as well
<zyga> Pharaoh_Atem: I will resume this as soon as I fix this issue that kyrofa and kissiel helped me fijnd
<zyga> find*
<pedronis> zyga: I see, anyway not sure anyone is particularly to blame, all those PRs seems to have had the needed reviews, globs are dangerous, all of use need to keep it in mind
<zyga> yeah, I just feel bad about it
<zyga> finishing tests now
<zyga> I will review all backends next
<zyga> I let mvo know in case we do a .6 tonight
<pedronis> I see two glob1 in apparmor/backend.go
<zyga> yes, one for setup and one for remove
<zyga> I added a function and removed them both so that there's less places for this issue to re-surface
<pedronis> there's a lot of globbing of course going on all over interaces
<sergiusens> zyga, kyrofa: that seems to be the root of the corebird issue
<zyga> yes
<pedronis> is this right:    glob := fmt.Sprintf("snap.%s.*fstab", snapName)  ?    I would expected a dot before fstab.   or there's a case where *Â matches "" there
<pedronis> it's in mount/backend.go
<zyga> I think so
<zyga> it's not obvious
<zyga> let me see if there's a comment for this
<diddledan> if you're after literal dots and it's a regex, you need to escape them
<zyga> diddledan: it's a glob
<kyrofa> diddledan, it's globbing
<diddledan> ok
<zyga> pedronis: we used to have a per-app mount profiles
<pedronis> they are globs, we are mostly looking for missing dots or spurious *
 * diddledan goes back to sleep
<zyga> pedronis: if you add that dot there it becomes:
<zyga> ... value *errors.errorString = &errors.errorString{s:"cannot synchronize mount configuration files for snap \"snap-name\": internal error: EnsureDirState got filename \"snap.snap-name.fstab\" which doesn't match the glob pattern \"snap.snap-name.*.fstab\""} ("cannot synchronize mount configuration files for snap \"snap-name\": internal error: EnsureDirState got filename \"snap.snap-name.fstab\" which doesn't match the glob
<zyga> pattern \"snap.snap-name.*.fstab\"")
<zyga> in reality it's a single file now so we could drop the *
<zyga> but having the glob helps if you update from ancient snapd
<zyga> where we still had the per-app profiles
<zyga> with an epoch we could drop the *
<pedronis> as I said I wasn't sure, just wondered
<pedronis> it might merit a comment though
<zyga> yes, totally
<zyga> I will add it
<zyga> pedronis, Chipaca: https://github.com/snapcore/snapd/pull/5109
<mup> PR #5109: interfaces/apparmor: fix incorrect apparmor profile glob <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5109>
<mup> PR snapd#5109 opened: interfaces/apparmor: fix incorrect apparmor profile glob <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5109>
<mup> PR snapd#5110 opened: interfaces/apparmor: fix incorrect apparmor profile glob (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5110>
<zyga> niemeyer: ^ FYI
<zyga> that's that thing
<zyga> kyrofa: I will let you know when edge is fixed
<zyga> or where we have a beta release that has this
<zyga> sergiusens: ^
<kyrofa> Thanks zyga
<mup> PR snapd#5074 closed: many: allow mimics in parents of layout <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/5074>
<sergiusens> thatnks
<mup> PR snapd#5108 closed: systemd: replace ancient paths with 16.04+ standards <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5108>
<mup> PR snapcraft#2108 opened: HACKING: suggest snapcraft-pr for evaluating PRs <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2108>
<zyga> kyrofa: maybe wait until this is fixed
<zyga> kyrofa: ;-)
<kyrofa> zyga, hahaha
<zyga> cachio: did we remove our linode images now?
<zyga> a 2.32-based PR seems to have issue allocating certain systems
<cachio> zyga, linode images are still there
<zyga> ah, thanks I will retry
<cachio> I was using them to run sru
<zyga> FYI, I'm seeing some issues with governor sync
<zyga> quiet: govendor sync
<zyga> quiet: exit status 2. Output follows:
<zyga> Error: Remotes failed for:
<zyga> 	Failed for "golang.org/x/crypto/cast5" (failed to ping remote repo): unrecognized import path "golang.org/x/crypto/cast5"
<cachio> zyga, it is on linode?
<cachio> or google ?
<zyga> this was on google
<zyga> I restarted it
<zyga> let's see what happens
<Chipaca> zyga: +1ish
<Chipaca> man! /apps/!
<zyga> Chipaca: replied,
<zyga> I can do a quick follow-up here too
<zyga> I don't mind
<zyga> (too = in that PR)
<Chipaca> zyga: pedronis: ah, if it's just used like that, []string is the right thing
<zyga> yes, just like that
<pedronis> zyga: any reason btw why the code is not using the old code with SecurityTag helper?
<zyga> I was looking at that myself, it used to
<zyga> because snap-update-ns doesn't have a corresponding function
<pedronis> that's ok
<zyga> I wanted to move this down to individual backends
<pedronis> it doesn't need a real glob either
<zyga> now that dbus is the only remaining user of that function
<pedronis> I'm just noticing that there is duplication
<pedronis> there's another place that computes "snap-update-ns.%s" at least
<zyga> oh, where?
<pedronis> addUpdateNSProfile
<pedronis> I'm nit picking here, but the old code was doing  interfaces.SecurityTagGlob(snapName)
<zyga> yeah, I know, that's what I meant above
<pedronis> it seems the new code should do []string{interfaces.SecurityTagGlob(snapName), nsProfileName(snapName)}
<zyga> hmm
<zyga> that's nice
<zyga> I'll do that
<pedronis> they can still be inside a profileGlobs helper
<pedronis> it helps having a precise test
<pedronis> and then nsProfileName (or what we want to call it) can also be used in addUpdateNSProfile
<zyga> yep, exactly, doing that now
<zyga> pedronis: can you review https://github.com/snapcore/snapd/pull/5092
<mup> PR #5092: snap: do not use overly short timeout in `snap {start,stop,restart}` <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5092>
<zyga> mvo wants to pull that into .6
<zyga> he just told me that on telegram
<zyga> pedronis, Chipaca: 5109 updated as discussed
<zyga> if you give me a +1 I'll squash this to make 2.32 back port easier
 * zyga is hungry a little
<pedronis> I have reviewed both
<pedronis> would be good though if mvo or Chipaca also looked at 5109 again
<Chipaca> 's good, +1 stands
<pedronis> I wonder what else is on 2.32 since .5
<zyga> pedronis: I asked mvo
<pedronis> just test changes and the follow up to the stop-mode stuff afaict
<zyga> pedronis: he said that those two PRs should be enough as nothing else stands as critical
<zyga> mvo just said that he will review the rest but it will be likely just the two fixes (stop and this one)
<pedronis> did you rebase 5109?  instead of letting github squash merge?
<zyga> yes, to cherry pick it into 2.32
<pedronis> mmh
<zyga> they are now with the same patch
<pedronis> this kills the history in it
<zyga> I can undo that
<zyga> I have the history locally still
<zyga> I can leave 2.32 as is
<zyga> and restore history for master
<pedronis> I usually squash merge and then do the cherry pick
<zyga> WDYT?
<zyga> I opened both before I had the feedback, I worry that we may have issues with tests in 2.32
<zyga> (like last time)
<pedronis> it's more of a general comment,  rebasing before commiting leave a bit of confusing history in the PRs
<pedronis> I don't want to force anything either way atm,  the most important thing is to fix stuff vs risk breakage
<zyga> ack, understood
<zyga> let's rest and regroup tomorrow
<zyga> Thank you guys!
<om26er> who maintains docker snap, apparently its outdated .
<om26er> that was supposed to be a pretty important snap IMO.
<zyga> om26er: AFAIK it is docker itself
<mup> PR snapd#5109 closed: interfaces/apparmor: fix incorrect apparmor profile glob <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5109>
#snappy 2018-04-27
<zyga> Good morning
<zyga> I did an experiment and the glob issue cannot explain the bug reported by our customer
<zyga> I will focus on debugging that next
<zyga> also the 2.32 branches cannot land because spread has issues on linode
<zyga> many machine images don't pick up the ssh connection
<zyga> must be Friday :)
<mborzecki> morning
<zyga> hey
<zyga> mborzecki: there must be a 2nd bug
<zyga> mborzecki: what I saw and fixed cannot explain the issue reported by the customer
<zyga> mborzecki: I'd love to get to the bottom of 2.32 test failures
<zyga> mborzecki: it seems we cannot reach our booted images anymore.
<zyga> mborzecki: this is all on linode
<zyga> mborzecki: for logs see #5110
<mup> PR #5110: interfaces/apparmor: fix incorrect apparmor profile glob (2.32) <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/5110>
<mborzecki> globs everywhere
<mborzecki> had to double check what SecurityTagGlob looks like
<mborzecki> zyga: travis build failure is the same as in #5073, my guess is that the images do not work, iirc those were -32 ones
<mup> PR #5073: set up journal streams in user session application autostart (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5073>
<mborzecki> if we do .6 it woul dbe nice to get 5073 in as well
<zyga> mborzecki: I asked mvo about what else to include but IIRC he wanted critical things only
<mborzecki> ok
<zyga> I wonder why the -32 bit images broke on us
<mborzecki> hm 249 test files modified, if i split that into groups of 20, we'll get 12 PRs
<zyga> Sounds good
<zyga> Will the match list conflict?
<mborzecki> i'm afraid so, but if we land at least one of these PRs a day, we'll be done in 3 weeks :P
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> hey pawel
<zyga> mborzecki: maybe a .d directory for match could do it
<zyga> mborzecki: but maybe it is better to just review
<zyga> I'm a bit tired this morning, not sure why
<mborzecki> zyga: we have to review it either way ;)
<mborzecki> need to drop my dogs off at the groomer, bb in ~30 minutes
<zyga> I'm sleepy
<zyga> ok, coffee is ready
<zyga> let's fight
<zyga> mborzecki, pstolowski: can you guys please have a 2nd look on #4545
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<zyga> it's green and I'd like to merge it but a fresh set of eyes would help
<mborzecki> re
<mborzecki> pstolowski: can you take a look at https://github.com/snapcore/snapd/pull/5103 ?
<mup> PR #5103: tests: shellcheck spread tasks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5103>
<mborzecki> once we land it i'll open a PR with the first barch of fixes
<pstolowski> zyga: will do
<zyga> thank you
<pstolowski> pedronis: hey, do you have a moment for quick HO? i'd like to run an idea re hooks by you
<pedronis> pstolowski: finishing breakfast,  can in a little bit
<pstolowski> sure
<pstolowski> zyga: is the bug re incorrect glob responsible for the issue you discussed yesterday and were trying to reproduce?
<zyga> pstolowski: yes
<zyga> pstolowski: but I think there's another bug too
<pstolowski> zyga: yay!
<zyga> but I'm still zombified and think slowly
<zyga> I wrote a test that this bug fix from yesterday doesn't affect the case saw by our customer
<zyga> I have a device to test now
<pedronis> pstolowski: I'm available now
<pstolowski> pedronis: ok, standup HO
<zyga> actually
<zyga> I wonder now
<zyga> what is coming up
<mborzecki> zyga: hm?
<zyga> c-release
<zyga> cagey camel
<zyga> cheery chiru
<Chipaca> crispy civet
<Chipaca> croissant cat
<Chipaca> cuddly cockroach
<Chipaca> morning all
<mup> PR snapd#5089 closed: tests: adding google-sru backend replacing linode-sur <Simple> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5089>
<zyga> good morning :)
<mborzecki> cuddly cockroach
<zyga> haha
<mborzecki> instant +1 from me
<kalikiana> that's a bad idea. email filters will turn that into cuddly roach
<mborzecki> crispy courgette
<Chipaca> http://goodyfeed.com/wp-content/uploads/2017/06/cockroach3.jpg
<kalikiana> ha. that's the way to deal with filters :-D
<mborzecki> and make an official cooking recipe with it
<Chipaca> we should make a nsfwbuntu that was just ubuntu with a nsfw dev name
<mborzecki> heh, reminds me of fedora with their 'beefy miracle' thing
<Chipaca> ssh! don't say the b word
<Chipaca> it sets neal off
<Chipaca> mborzecki: what's your thoughts on the drop privs thing?
<mborzecki> go for the mutex
<Chipaca> mborzecki: option a) say "can't fix before we move to 1.10+"
<Chipaca> mborzecki: option b) put a mutex, with a comment that says "this can still end up with the wrong uid trying to do stuff but we couldn't reproduce  it so it's probably very unlikely"
 * Chipaca felt less and less confident about (b) as he wrote the comment for it
<Chipaca> in fact, let me try something
<Chipaca> mborzecki: https://pastebin.ubuntu.com/p/Mn8nF8VV62/
<Chipaca> zyga: cosmopolitan cockapoo
<mborzecki> Chipaca: seems to work now
<Chipaca> mborzecki: in which sense of the word 'work'?
<Chipaca> mborzecki: lots of dots, no asterisks?
<mborzecki> Chipaca: yes
<Chipaca> mborzecki: go < 1.10?
 * Chipaca hugs mwhudson for snapping go
<mborzecki> pfff, got a couple of terminal-width lines of dots, switched back now and asterisks :/ it did take longer though
<Chipaca> mborzecki: seems to vary, but yes
<Chipaca> mborzecki: not surprised that a race is racy though :-)
<mborzecki> not failed after 3 dots
<mborzecki> s/not/now/
<Chipaca> i'm very intentionally tripping the bug, there
<Chipaca> so in practice it'll be a lot less likely
<mborzecki> even if we get someone to packport the patches to 1.9, the previous releases will stay unpatched
<Chipaca> but with so many people using it, less likely is still quite likely
<Chipaca> mborzecki: mwhudson has backported some cherries for us :-) but that won't help potato linux
<Chipaca> an alternative that should work is to use cgo, clone a thread there, do the syscall there (we _don't_ want the libc wrapper)
<Chipaca> but, ew
<Chipaca> also the semantics of calling from cgo back to go are not nice
<Chipaca> niemeyer: would appreciate your thoughts on https://github.com/snapcore/snapd/pull/4983#issuecomment-384915539
<mup> PR #4983: osutil/sys, client: add sys.RunAsUidGid, use it for auth.json <Created by chipaca> <https://github.com/snapcore/snapd/pull/4983>
<Chipaca> niemeyer: (not on the PR, on the comment)
<mborzecki> Chipaca: do you recall if it's also the case in older releasese that if a goroutine exits in a locked thread, the thread will be terminated?
<mborzecki> zyga: conflicts in #5081
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<zyga> mmm
<mborzecki> Chipaca: ca you take another look at #5103 ?
<mup> PR #5103: tests: shellcheck spread tasks <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5103>
<zyga> fixed
<Chipaca> mborzecki: sorry was afk getting coffee (and maybe cake)
<Chipaca> mborzecki: it's very much _not_ terminated
<mborzecki> Chipaca: nice combo
<Chipaca> especially this cake :-)
<Chipaca> my mum's chocolate fudge cake
<uebera||> Hi. What is the equivalent of "apt-file list <package-name>" for displaying the contents of a snap package (e.g., "nextcloud") without having to install it first? (I'm using Ubuntu Xenial.)
<Chipaca> uebera||: there isn't one
<Chipaca> uebera||: what are you trying to do?
<Chipaca> uebera||: (outside of some corner cases, AFAIK the files in a snap are not that interesting)
<uebera||> I want to see what's inside the package "nextcloud" w/o installing it.
<Chipaca> uebera||: I meant one step back from that
<Chipaca> uebera||: I mean: what do you need this information for?
<uebera||> I don't understand. This is the only step. I do not intend to install the package using snap, I just want to see its contents in order to see what is included as a dependency (b/c I doubt that this is in line with what the documentation lists).
<Chipaca> uebera||: there isn't a way to do that without downloading the snap
<mborzecki> uebera||: snap download && unsquasfs -l probably makes most sense then
<Chipaca> or snap install and find :)
<Chipaca> it's a 200MB download, so I can understand not wanting to do it
<Chipaca> uebera||: is it really just this snap,  or is it a general problem?
<uebera||> Well, this is the first snap I want to inspect (the third one I've ever come across), but I'd consider it a general problem, yes. Unless there are public catalogues like for apt...
<Chipaca> uebera||: ok, as I said, there isn't a way (today) of doing this; we don't index that data
<pedronis> snaps are also much more fast moving than debs, so the information can be stale quickly
<Chipaca> heck yeah :-)
<uebera||> Well, if the above "snap download && unsquasfs -l" works, that's good enough for a start atm.
<Chipaca> why on earth is mysqld 200MB+
<Chipaca> uebera||: also -lls fwiw
<uebera||> However, having to start up a throw-away container just to inspect the contents of a snap in a safe environment is not convenient.
<Chipaca> uebera||: why would you need a container for download+unsquash?
<uebera||> Not for download, but for installation.
<mup> PR snapcraft#2107 closed: Release changelog for 2.42 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2107>
<uebera||> I.e., the "download/unsquash" method should be cited in a FAQ if it isn't already (I've missed it until now).
<Chipaca> uebera||: right, for installation i could understand it, as it's mounting the squash and you'd have to trust us that it's ok to do so
<Chipaca> uebera||: well, download is documented, as snaps are documented as being squashfs
<Chipaca> uebera||: the rest is just joining the dots
<Chipaca> s/as/and/
<didrocks> zyga: so, due to my classic snap segfaulting as I can only build it on bionic due to golang version, I heard there was a way to declare which core snap you are using, I don't find the reference for it in the doc, any hint?
<zyga> didrocks: "base: core18"
<zyga> but I don't know if snapcraft supports this yet
<zyga> it's very early
<zyga> didrocks: if you build your snap on bionic you must use a container
<mborzecki> uebera||: hm alternative would be to try https://uappexplorer.com/snap/ubuntu/nextcloud and download from there
<zyga> didrocks: and for classic snap you must use a xenial-abi-compatible build of go
<didrocks> zyga: the issue is that snapcraft doesn't allow you to select the go version if I'm correct
<zyga> didrocks: perhaps, kalikiana would know
<didrocks> sounds like bug #1616985 didn't really move
<mup> Bug #1616985: the go plugin doesn't use go build-snaps <isv> <plugin> <Snapcraft:In Progress by kalikiana> <https://launchpad.net/bugs/1616985>
<didrocks> so, basically, I'm between FTBFS and segfault :p
<Chipaca> didrocks: even with core18?
<didrocks> Chipaca: well, I'm unsure how to inject that in my snapcraft.yaml definition
<Chipaca> try "base: core18"
<didrocks> same level than grade: I guess?
<Chipaca> right next to "name: doesrocks"
<Chipaca> :-p
<zyga> yes
<didrocks> ;)
 * didrocks tries, thanks!
<Chipaca> didrocks: if it shouts at you let us know
<uebera||> mborzecki: Thanks, this is an alternative w/o using snap (though "snap download" worked like a charm)
<kalikiana> didrocks: That's not perfectly accurate. The go plugin insists on installing the deb, but it doesn't prevent you from using a remote part with your favorite version
<didrocks> Chipaca: at least, it downloads core18 when installing, good starting point :)
<Chipaca> uebera||: 'snap download' also gives you the assertions which can be helpful
<Chipaca> didrocks: huzzah
<didrocks> and it works! thanks Chipaca, zyga
<mborzecki> uebera||: a word or warning, iirc the search by architecture is broken in uappexplorer
<didrocks> kalikiana: yeah, that's what I read, but I prefer to avoid relying on something else like another snap or a ppa with a newer build
<kalikiana> didrocks: I can't parse that sentence. You want a specific go version that isn't in the archive, no?
<didrocks> kalikiana: exactly! It seems the only way right now is to have a part downloading go for you (from another snap or using adding a ppa as a build-dep)
<kalikiana> didrocks: My suggestion above was a remote part. Not a PPA. As in, "after: [go]   go:     source-tag: go1.7.5"
<didrocks> kalikiana: ah ok, nice that there is a remote part! I'll see between that or using core18â¦
<didrocks> thanks :)
<Chipaca> didrocks: i'd consider core18 'developer preview' quality, fwiw
<Chipaca> didrocks: tested for some very narrow verticals right now afaik
<Chipaca> so if you can get it to work without, you'll be happier
<didrocks> Chipaca: well, as it's for a classic snap, I think I only need an ABI compatible linker with my build
<didrocks> and as it's Go without Cgo, it's statically compiled (apart from accessing the network config)
<Chipaca> didrocks: in particular I'm entirely unsure how well core18 will play with classic, today
<Chipaca> didrocks: and 'base: core18' means installing your snap will download core18
<Chipaca> didrocks: so... let us know how it goes :-D
<didrocks> Chipaca: which we are going to do anyway soon AFAIK for 3.28 GNOME snaps
<didrocks> yeah, I'm happy to be the guinee pig here ;)
<didrocks> guinea*
<Chipaca> didrocks: I'm happy for you to be, as well
<Chipaca> as long as you know you are
<didrocks> heh, I know at least there is a fallback plan
<didrocks> I'll keep you posted in case I spot anything wrong
<Chipaca> didrocks: to be clear if it's going to fail anywhere it'll be on 16.04 (or 14.04)
<didrocks> yeah, I'll try testing there
<Chipaca> didrocks: if it's a desktop thing, don't try 14.04 :-)
 * didrocks will happily refrain thus!
<mborzecki> had to restart, master travis job again, and again it failed because not output was received
<Son_Goku> does anyone know why I default to the edge channel in Ubuntu Software?
<Son_Goku> snaps I install are apparently coming from edge by default
<Son_Goku> which is something I totally did not expect
<Son_Goku> or at least, it looks like they are
<Son_Goku> it says "stable" channel but gives me the version in the edge channel...
<mup> PR snapcraft#2109 opened: sources: clean up IncompatibleOptionsError <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2109>
<zyga> Son_Goku: that looks like a bug for sure
<zyga> it should be the opposite
<Son_Goku> zyga: it's very obvious with the blender snap
<ogra_> Son_Goku, it knows who you are !
<Son_Goku> meep
<ogra_> :)
<zyga> and after installing snap info says you are tracking edge?
<Son_Goku> zyga, nope
<Son_Goku> it switches back to stable
<Son_Goku> it's very strange and confusing
<zyga> yes
<zyga> but is the snap you got from edge?
<zyga> as in the revision matches what is in edge and not what it is in stable
<Son_Goku> no it matches stable
<zyga> hmm?
<Son_Goku> it looks like something's confused in ubuntu software
<zyga> so what is the bug
<Son_Goku> even when tracking stable, it's actually rendering info from edge
<Son_Goku> in ubuntu software
<Son_Goku> also, niemeyer, you really should fix the metadata for your blender snap
<Son_Goku> it's completely wrong :)
<Chipaca> Son_Goku: showing info from edge?
<Chipaca> Son_Goku: tell me moar
<Son_Goku> Chipaca, ubuntu software renders info from edge, even though it defaults to tracking stable
<zyga> https://www.youtube.com/watch?v=DOYRLdisrTE
<Chipaca> Son_Goku: in what case?
<zyga> (wrong video though ;)
<Son_Goku> snap not installed
<Chipaca> Son_Goku: i mean: what do you see as 'from edge'?
<Son_Goku> Ubuntu Software on 18.04, just open it up, and search for blender
<Son_Goku> well, the version
<sparkiegeek> yeah, reproducible here - gnome software it showing the version from non-stable (hard to see if it's edge, beta or candidate)
<sparkiegeek> but it's not in stable
<Son_Goku> also, Fedora 28 is GOLD
<Chipaca> sparkiegeek: Son_Goku: any example that isn't also a deb?
<Chipaca> Son_Goku: congrats!
<Son_Goku> Chipaca, not sure, I noticed it because the blender snap is missing so much data it shows up as separate from the deb
<Son_Goku> the vlc snap also shows the same issue
<sparkiegeek> Chipaca: just trying to check the snapd API, do you have the curl invocation to hand?
<Son_Goku> though it renders the beta channel's number
<sparkiegeek> Chipaca: reproducible for gitlptools (my snap)
<Chipaca> sparkiegeek: snap install http && http snapd:///v2/find name==thesnapname
<Chipaca> not seeing this in 16.04, fwiw
<Chipaca> gitlptools showing 388db20 as is proper
<sparkiegeek> Chipaca: http: error: InvalidSchema: No connection adapters were found for 'snapd://v2/find'
<Chipaca> eh
<Chipaca> sparkiegeek: forgot the extra /
<Chipaca> snapd:///v2/...
<Chipaca> wait, no i didn't
<Chipaca> you did :-D
<sparkiegeek> $ http snapd:///v2/find name==gitlptools
<sparkiegeek>  
<sparkiegeek> http: error: InvalidSchema: No connection adapters were found for 'snapd:///v2/find'
<Chipaca> sparkiegeek: which http
<sparkiegeek> ah ha!
<Chipaca> Â¯\_(ã)_/Â¯
<sparkiegeek> Chipaca: thanks, that was it
<zyga> so what is broken?
<Chipaca> completely in the dark guess? it's taking the first entry from the channel map instead of latest/stable
<Chipaca> (or just the one outside the channel map)
<sparkiegeek> Chipaca, zyga: it looks like version number outside of the channel map is reporting the wrong one
<sparkiegeek> right, the latter
<Chipaca> ah, ok
<Chipaca> then, yes, that.
<Chipaca> bug in store, already getting fixed
<zyga> thanks!
<Son_Goku> :)
<Chipaca> the snap client just happens to walk around the issue
<sparkiegeek> the snap that's installed is tracking stable though, and then gnome-software is reporting the installed version (as tested with blender)
<sparkiegeek> so I can't exactly reproduce what Son_Goku sees
<Chipaca> sparkiegeek: i thought it wasn't the installed version
<Son_Goku> oh, after install, it shows the right thing
<Chipaca> right
<Son_Goku> it was _before_ install it didn't
<Son_Goku> so it was just confusing
<sparkiegeek> Son_Goku: agreed
<Chipaca> easiest and quickest and most future-safe thing would be to tell snapd-glib (or was it glib-snapd) to grab the info from the channel map
<Chipaca> although...
<Chipaca> i should sit down with 'em and make it better
<Chipaca> they're having to jump through hoops to get their stuff done, and it's nasty
<Chipaca> i'll do that next week
<Son_Goku> Chipaca, snapd-glib
<sparkiegeek> Chipaca: right, but then they'd have to encode the channel map priorities - e.g. no guarantee of there being latest/stable
<Chipaca> Facu: remember the 'ha ha lol the store picks a revision at random to show the info if you say channel=""' thing we talked about? gnome-software in 18.04 hits it :-)
<Son_Goku> that explains why I get the beta version rendered for vlc
<Son_Goku> rather than edge, if it's "random"
<Chipaca> Son_Goku: well, it's not random, it's most-recently-pushed afaik
<Chipaca> it just seems random
<Son_Goku> now, if the store was open source... :P
<thresh> ugh, snap store shows vlc edge to install by default?
<Chipaca> thresh: no(ish)
<Chipaca> thresh: it installs stable; the version number is wrong
<Chipaca> thresh: in 18.04
<thresh> that's still bad
<thresh> don't want the user to have an impression they'll install vlc 4.0
<Chipaca> right
<Chipaca> we'll sort it
<Son_Goku> someday :P
<Chipaca> thresh: to be clear, it's gnome-software (and presumably other stores using snapd-glib but i haven't checked) in 18.04 that expose the bug
<thresh> good to know, fingers crossed on a swift fix :)
<Chipaca> we can argue about whether it's the store, snapd, or snapd-glib that have the bug -- but it's fixable in any of those places :-)
<thresh> also congrats on a release for everyone involved!
<Chipaca> thresh: i think everyone directly involved is off today :-)
<Facu> Chipaca, ugh
<Chipaca> Facu: :-)
<Chipaca> Facu: also, good morning
<Chipaca> Facu: sorry to greet you with that news
<Son_Goku> holy shit
<Son_Goku> VLC looks ugly
<Chipaca> Son_Goku: sshh! you'll make thresh cry :-(
<thresh> nah, I already cry daily
<Chipaca> Son_Goku: try saying the same thing but with kinder words
 * Chipaca hugs thresh 
<thresh> Son_Goku, what DE are you under?
<Son_Goku> GNOME
<Son_Goku> Fedora 28
<thresh> Son_Goku, can you please try beta?
<Son_Goku> sure, one sec
 * Son_Goku sighs
<Son_Goku> I can't do it from g-s
<Son_Goku> down the CLI we go!
<Son_Goku> oh we've gotten fancy now
<Son_Goku> overlaying progress bars
<Chipaca> Son_Goku: how long has it been since you used the CLI :-)
<Son_Goku> more months than it probably should be
<thresh> I'd release the beta to stable any time, but the UI (e.g. open file dialog) is completely broken on KDE
<Son_Goku> thresh, not better
<thresh> hmm, okay
<thresh> can you drop the output of env | grep XDG_ to pastebin somewhere?  or PM me?
<thresh> and a screenshot of VLC / menus
<Chipaca> thresh: also maybe 'snap run --shell vlc' and do the same in there
<Son_Goku> thresh: http://kinginuyasha.enanocms.org/downloads/screenshot-vlc-snap-about-20180427.png
<thresh> Son_Goku, what about the icons / general UI fonts?
<thresh> in the menu bar etc
<Son_Goku> thresh: http://kinginuyasha.enanocms.org/downloads/screenshot-vlc-snap-with-env-20180427.png
<Son_Goku> it's pretty bad
<thresh> ok, so it's an issue with the fonts
<Chipaca> Son_Goku: thresh: aren't themes and fonts working?
<thresh> the UI actually does not look like windows 95
<Chipaca> i thought they were
<thresh> Chipaca, I'm pretty sure I need to add something to my snap to enable it?
<Son_Goku> I thought they were too
<Son_Goku> but apparently no?
<sparkiegeek> Son_Goku: can you file a bug about the version info being wrong? i.e. ubuntu-bug gnome-software-plugin-snap
<Son_Goku> sparkiegeek, I don't have the Ubuntu 18.04 VM anymore :)
<Son_Goku> I only spun it up to check out g-s there ;)
<Son_Goku> because I heard there was funny business in g-s in Ubuntu
<Son_Goku> like the ability to select channels and permissions
<Son_Goku> neither of which I can do from g-s in Fedora
<Chipaca> zyga: do you know about fonts?
<zyga> Chipaca: is this a tricky question where I say yes and then go and dig through unholy C code that renders vectors?
<zyga> popey: https://twitter.com/zygoon/status/989835561639841797 :-)
<zyga> popey: it still needs some upstreaming on my part
<zyga> and packaging love
<zyga> and more
<Chipaca> zyga: I don't want you dissing metafont now
<zyga> but :-)
<popey> that skype snap isnt confined
<zyga> popey: yes but it's not because of opensuse
<popey> neither is slack
<popey> ok
<zyga> popey: look at the terminal
<zyga> but yeah, I see your point
<Chipaca> zyga: the work to let snaps access fonts from the local system, was that landed?
<popey> Sweet!
<zyga> Chipaca: yes
<zyga> but it's working partially by accident
<Chipaca> Son_Goku: FWIW i seem to recall that after agreeing that font metadata nearly never changes, it changed
<Chipaca> just too late to break 18.04, but in time to break fedora 28, if i remember well?
<Son_Goku> probably
<Son_Goku> it will probably break openSUSE soon too
<zyga> Chipaca: yes
<zyga> 2.13
<Son_Goku> yep
<Son_Goku> fontconfig-2.13.0-3.fc28
<zyga> (13 , see it's _bound_ to happen ;)
<thresh> what do I need to do to enable it?
<Chipaca> zyga: how were we going to fix that?
<Chipaca> zyga: and what thresh is asking is whether the snap needs to do anything to access the 'outside' fonts, and if so what :-)
<zyga> Chipaca: let me think, AFAIK the issue is the old fontconfing doesn't grok the new syntax so we must not share /etc/fonts (or something like that) and probably must synthesise per-core variant somewhere in /var/lib/snapd so that we can bind mount it into /etc
 * Son_Goku whispers fedora core snap to zyga 
<zyga> Son_Goku: I played with that, need more weekends to finish it
<zyga> Chipaca: which sucks because /etc/fonts may not be there
<zyga> may be a symlink
<zyga> or whatever
<zyga> I suspect we want a writable mimic with filtering
<zyga> over /etc
<zyga> so that we can assure /etc/fonts is something we control
<zyga>  Chipaca does that answer your question?
<Chipaca> zyga: it answers my first question -- thresh's question about how to use it still stands
<Chipaca> zyga: (with the caveat that it won't work on anything using fontconfig 2.13 because they hate us)
<thresh> I'll be more than happy to drop fonts from bloated vlc snap indeed :-)
<zyga> Chipaca: we need to write a tool (Alex expressed interest in cooperation there) that would take a fontconfig "config" file and convert it to a version appropriate for a given fontconfig major/minor release
<Chipaca> zyga: how. does. a. snap. author. use. this.
<zyga> no no
<Son_Goku> because fonts are evil
<zyga> it's for us
<zyga> snap authors don't need to do anything
<Chipaca> zyga: duuuude
<Son_Goku> Chipaca, it's intended to be automatic
<Chipaca> zyga: I create a snap
<pedronis> magic and pixie dust
<Chipaca> zyga: how do i tell it to use the system's fonts?
<Son_Goku> automagic :D
<Son_Goku> it Just Works(TM)
<zyga> if you use fonconfig and you use one of the desktop interfaces it is indeed automatic
<zyga> but that's what we _want_
<zyga> what is reality is more complex
<Chipaca> so vlc could drop its bundled fonts and it'd still work (except on fedora 28)?
<zyga> you can see the fonts and they are mounted where people expect them
<zyga> but from one system to another you many not be configured to use them
<zyga> because "configuration" is really not configuration, it is mandatory side-channel to tell fontconfig how to use a particular specific font correctly
<zyga> it's not "fonts are here", it's down to font substitution and other magic that makes the font actually useful
<pedronis> so we need to know what config version the snaps expect?
<mborzecki> w8, why are vlc fonts ok here then?
<Chipaca> mborzecki: because vlc bundles its fonts maybe?
<Chipaca> mborzecki: here == arch? you're on 2.13+?
<zyga> pedronis: it seems we need to know the expected format of fontconfig configuration per base, yes
<mborzecki> Chipaca: 2.13 to be exact
<Chipaca> mborzecki: or maybe you just like the cool 'everything is courier new' look
<zyga> mborzecki: not sure, perhaps vlc reconfigures the place for fonts because of one of the desktop helpers
<pedronis> zyga: well, unless the  snap bundles the relevant libraries? in which case is per snap
<zyga> (aka magic boxes we don't grok in this team)
<mborzecki> I see a bunch of warnings https://paste.ubuntu.com/p/RwdnCCTqZ6/ but that's that
<thresh> I'm on fontconfig 2.13, on debian testing, and the fonts are fine for me
<zyga> pedronis: yes but even then we can offer the older format fine
<zyga> pedronis: I think it could be something we convey on the desktop interface
<zyga> but it must be consistent inside the whole snap
<Chipaca> thresh: mborzecki: so, the problem with 2.13 is that it supports config stuff that <2.13 does not
<Chipaca> thresh: mborzecki: as long as you're not using that new stuff it still works
 * zyga gets back to debugging
<Chipaca> the problem AFAIR was that a brand new install does use that new config stuff
<mborzecki> https://i.imgur.com/tEIrLip.jpg
<zyga> I really don't know more about fonts than you guys :)
<Chipaca> I don't know the details, i'm just repeating what i heard in the standup :-)
<mborzecki> hmm
<mborzecki> maybe there's some decent fallback mechanism
<mborzecki> like picking the fallback fonts by name/type
<mborzecki> Son_Goku just happens to not have the right fonts installed or sth
<Son_Goku> this is literally the default font set for Fedora Workstation 28
<thresh> woah, I don't get any of those warnings
<mborzecki> the monospace one? :)
<Son_Goku> well, not that
<Son_Goku> that's the shit-tier font
<Son_Goku> it renders incredibly badly too
<Son_Goku> some parts aren't even readable
<thresh> and that's how it looks for me: https://dashboard.snapcraft.io/site_media/appmedia/2018/04/2018-04-26-161203_1126x899_scrot_yBFL55L.png
<mborzecki> yeah, i can see that the font i have is also slightly different (smaller?), it surely ignores the dpi/scaling settings
<thresh> I do use scaling though for QT apps
<thresh> QT_SCREEN_SCALE_FACTORS=1.5 and QT_AUTO_SCREEN_SCALE_FACTOR=0
 * zyga sighs
<ogra_> hrm
<ogra_> tyhicks, jdstrand, is the store tool that notifies me about outdated packages with USN your baby ? it semds emailÃ¶s without any timestamps at all it seems (making the mails end up in a special folder in my setup)
<nsg> I'm going crazy, all text in my snap is just squares. I'm not sure how to debug this. Works on Ubuntu, just squares on Debian and Solus. Any idea how to debug this?
<vidal72[m]> what is the status of this https://forum.snapcraft.io/t/firefox-please-create-the-track-esr/5006
<ogra_> nsg, include fonts (or even better use a desktop-helper)
<nsg> ogra_: I'm using the helper, and I think I have all the fonts I need. The application has also the option to change fonts ... any selected font is just squares.
<nsg> The interesting thing is, on Solus I only see 3 fonts: https://imgur.com/a/lEbReMW
<nsg> fc-list outside the snap lists more or less the same fonts like in my Ubuntu install. I'm using desktop-gtk2, unity7 and so on.
<nsg> A friend has reported the same problem on Debian, so I do not think it's Solus related, more non-Ubuntu related :)
<nsg> I'm just not sure what to do next ... have tried to get this thing fixed on my spare time for 2-3 weeks now.
<diddledan> nsg: have you plugged `desktop` and `desktop-legacy`?
<nsg> hm... not at the snap in the solus install... I will give that a try. These are new to me :)
<nsg> I will try to _add_ them and see what happens
<diddledan> they're automatically connected once the snap defines the interfaces
<zyga> jdstrand: hey, can you tell me why we chose to use /var/lib/snapd/apparmor/profiles over /etc/apparmor.d
<zyga> jdstrand: I'm working on opensuse down streaming and one issue I'm facing is that our profiles don't reload on boot
<zyga> jdstrand: I patched snapd locally to see what happens when we put our profiles in /etc/apparmor.d and ... it works okay
<jdstrand> zyga: because /etc/apparmor.d is for system profiles and profiles the admin uses. /var/lib/snaps/apparmor/profiles are managed by snapd
<zyga> yes I know but that is not upstream
<zyga> I'm trying to figure out what to do
<zyga> teach upstream apparmor about /var/lib/snapd/apparmor/profiles
<zyga> patch opensuse specifically
<zyga> or patch snapd on opensuse
<jdstrand> zyga: please join #apparmor. opensuse is redoing all their profile loading
<jdstrand> zyga: on OFTC
<zyga> one sec, I don't have that set up
<jdstrand> zyga: jjohansen from upstream apparmor has also been working on making all this easier to configure. today everyone uses their own apparmor init script. we want to have an 'upstream way' of doing it where you configure additional locations in various ways. this is good for precompiled caches, system profiles, admin profiles, service-managed profiles (snapd, lxd, libvirt, etc), ...
<Son_Goku> Solus completely rewrote how their aa profiles are managed too
<Son_Goku> they didn't like how Ubuntu or openSUSE did it
<Chipaca> Son_Goku: https://forum.snapcraft.io/t/5163
<vidal72[m]> zyga: # /usr/lib/systemd/system/apparmor.service.d/snapd.conf
<vidal72[m]> zyga: [Service]
<vidal72[m]> zyga: ExecStart=-/usr/bin/apparmor_parser --write-cache --cache-loc=/var/cache/apparmor -r /var/lib/snapd/apparmor/profiles/
<zyga> vidal72[m]: pastebin please
<zyga> vidal72[m]: does this unit run when you update apparmor-profiles?
<zyga> I know it's possible to load them ourselves but there are benefits when they are loaded by the main unit
<vidal72[m]> https://paste.ubuntu.com/p/z5bfPrbrbZ/
<vidal72[m]> zyga: they will be loaded by main apparmo unit
<Son_Goku> Chipaca: yay
<zyga> vidal72[m]: hmm, this probably won't be enough
<vidal72[m]> why?
<zyga> vidal72[m]: because services will start before snapd
<zyga> and they will fail because their confinement profile won't be present yet
<zyga> ah
<zyga> sorry, I misread what you wrote
<zyga> chaining this to apparmor will work
<vidal72[m]> it worked for me
<zyga> thank you for the suggestion, another option on the table
<Chipaca> raining cats and dogs and i need to do the school run
<pedronis> Chipaca: btw according to the dictionary both those pronunciations of ephemeral exists
<Chipaca> pedronis: i'll pronounce it "eph'g'meral" just to be sure
<Chipaca> that's a double glottal stop with a g thrown in for good measure
<pedronis> Chipaca: iphimeral or iphemeral (or something like that)
<vidal72[m]> zyga: this is what upstream suggested to me after I asked about snapd support
 * Chipaca -> school run
<Chipaca> pedronis: pretty sure people in the uk make decisions about the sort of person you are based on which one you use though
<Chipaca> so i should learn which one i want to be :-)
<zyga> vidal72[m]: which upstream?
<Chipaca> or use both and confuse people
 * Chipaca -> really off
<jamesh> zyga: hi.  I've addressed some of the review comments on https://github.com/snapcore/snapd/pull/3963 and replied to the others.  CI failed with a timeout though, but I think it is probably fine.
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<ogra_> jdstrand, seen my ping above ? if it isnt your tool, whom do i need to poke so the mails get a proper send-date in them ?
<zyga> jamesh: thank you, I think at this stage we are waiting for Niemeyer's review
<vidal72[m]> zyga: apparmor
<jamesh> zyga: he reviewed it earlier today
<zyga> oh, sorry I didn't know
<zyga> I was fire-fighting somewhere else
<zyga>  jamesh I restarted the build now
<jamesh> zyga: thanks
<zyga> I will merge it as soon as it goes green
<zyga> ok I need a break
<zyga> for food/dog/walk
<roadmr> that makes it ambiguous whether you'll eat the dog and then go for a walk or other possible combinations :P
<zyga> that makes it more interesting
<jdstrand> ogra_: that is me (tyhicks, ignore this)
<zyga> maybe the dog is typing
<jdstrand> ogra_: well, it is the security team, but I've done the initial implementation, so me :)
<jdstrand> ogra_: what is one of the affected snaps?
<ogra_> jdstrand, packageproxy and jtiledownloader
<jdstrand> roadmr: fyi, https://forum.snapcraft.io/t/notifications-for-out-of-date-stage-packages/5161
<roadmr> jdstrand: awesome! yes, Celso just got one!
<jdstrand> I imagine a lot of people did :)
<roadmr> I didn't, which is surprising because my snaps are all crap and haven't been rebuilt in ages
<ratliff> if you didn't get one and you are a snap publisher, give yourself a gold star and a pat on the back :)
<jdstrand> ogra_: I see a 'Date: Fri, 27 Apr 2018 14:08:20 +0100 (04/27/2018 08:08:20 AM)'
<mup> PR #2018: snapstate: pass errors from ListRefresh in updateInfo <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2018>
<roadmr> maybe that's why - they're so old they likely don't have manifest_raw :D
<jdstrand> roadmr: or build you snap with SNAPCRAFT_BUILD_INFO=1 ;)
<jdstrand> roadmr: *and* publish it to a channel :)
<jdstrand> ogra_: what is it that you want?
<roadmr> jdstrand: it is published (gnuchess). I guess I could fire a rebuild
<roadmr> jdstrand: oh so snapcraft doesn't manifest_raw by default? I thought it did... hmm. Will keep in mind!
<diddledan> did the forum just die?
<jdstrand> roadmr: I did the same thing this morning. had 3 snaps built without it so I rebuilt them
<roadmr> diddledan: wfm \o/
<jdstrand> roadmr: LP does manifest raw by default. snapcraft does not
<roadmr> jdstrand: gotcha, that must be the source of my confusion
<jdstrand> roadmr: but yeah, gnuchess is ancient by snapcraft standards, so it wouldn't have it no matter where you built it :)
<roadmr> I'll try to rebuild it
<jdstrand> ogra_: I'm confused by your request since there is a 'Date: ...' in the email. please clarify
<ogra_> jdstrand, https://imgur.com/a/fgZ6am
<ogra_> i want the question marks gone :)
<ogra_> i typicall yonly get these from spambot mails
<jdstrand> ogra_: 404
<ogra_> oops
<ogra_> jdstrand, https://imgur.com/a/fgZ6amU
<jdstrand> ogra_: that is weird. I'm using the same email client as you and don't see that
<sergiusens> jdstrand: nice email I just got from usn :-)
<jdstrand> ogra_: I see 'Content-Type: text/plain; charset="us-ascii"' in it but 'Content-Type: text/plain; charset="utf-8"' in other store-generated emails
<jdstrand> sergiusens: thanks! and thanks for the manifest.yaml. not sure if you saw, but fyi https://github.com/snapcore/snapcraft/issues/2093
<sergiusens> jdstrand: I did, you did not read the template ;-) (we will add it regardless) :-)
<jdstrand> sergiusens: whoops!
<jdstrand> ogra_: let me play with making that utf-8, then send you a test email
<ogra_> jdstrand, thanks
<kyrofa> Ooo jdstrand I'm seeing some interesting emails about the contents of my snaps
<roadmr> \o/
<jdstrand> kyrofa: yep :)
<cachio> mborzecki, hey, I noticed the arch linux images are not being discarded from google
<cachio> mborzecki, any idea why it could be happening?
<cachio> mborzecki, the image has not changed from long time
<cachio> and when I log into it, I don't see nothing weird
<ogra_> jdstrand, nope, same
<jdstrand> hmm
<ogra_> (teh 0a mail you just triggered)
 * jdstrand nods
<ogra_> *0ad
<ogra_> jdstrand, if it is really only me then feel free to ignore. i can handle it on my side ... perhaps my mailserver or spamassassin mess it up here
<jdstrand> ogra_: I just can't see any differences
<jdstrand> ogra_: emails to ubuntu-devel look ok?
<ogra_> yeah
<jdstrand> let me look at one of those
<ogra_> in general all other m,ails look fine
<ogra_> i occasionally get spam with broken date but thats about it
<jdstrand> ogra_: makes no sense. I looked in ubuntu-devel and other text/plain emails with charset of utf-8 and us-ascii and everything looks ok
<ogra_> yeah, lets blame my side unless you hear anything from others then
 * roadmr blames it on ogra_
<ogra_> :D
<jdstrand> ogra_: I wonder if it is evolution and the format of the date column... again, the date format is the same as other emails so don't know why that would happen
<ogra_> Content-Type: text/plain; charset="utf-8"
<ogra_> should that perhaps be charset=UTF-8 instead ?
<ogra_> hmm, no
<Chipaca> ogra_: no?
<Chipaca> i don't see anything about quoting it in Rfc 2046
<ogra_> i was more concerned about the non-capitalized vaersion there ... not about the quoting
<ogra_> *version
<ogra_> but digging throuhg mail sources i see both variants and both seem to work fine
<Chipaca> ah there it is, quotes are fine
<mborzecki> cachio: no clue, do you know if these were stated automatically due to a travis job or manually?
<mborzecki> cachio: is there even a difference, maybe there's some magic logic in gce that collects unused vms
<cachio> mborzecki, started by travis
<nsg> diddledan: "desktop" did the trick! Thank you, it works now on my Solus test VM.
<pedronis> Chipaca: when do we show the long help of commands?
<pedronis> Chipaca: I see that refresh and install ones is out-of-date but is also not shown
<Chipaca> pedronis: 'snap help --man | man -l -'
<Chipaca> pedronis: might help
<pedronis> Chipaca: but IÂ don't see it in "man snap" either
<Chipaca> pedronis: also master is not 2.23.5
<Chipaca> pedronis: that fixed text is new
<Chipaca> pedronis: go build -o /tmp/snp ./cmd/snap && SNAP_REEXEC=0 SNAPD_DEBUG=1 /tmp/snp install --help  :-)
<pedronis> I'm on master and not seeing it either
<Chipaca> pedronis: reexec
<pedronis> Chipaca: so it's recent?
<Chipaca> pedronis: not really
<pedronis> well, newer than 2.32.5 ?
<Chipaca> pedronis: 2018-03-14
<Chipaca> over a month old
<Chipaca> but, yes, not in 2.32.5
<pedronis> ok, it needs reviewing given that it doesn't match reality anymore
<pedronis> I was planning to fix the help but then saw that there's much more text, that I wasn't seeing
<pedronis> bit confused was I
<pedronis> maybe I can try anyway quickly
<mup> PR snapd#5111 opened: cmd/snap: update install/refresh help vs --revision <Created by pedronis> <https://github.com/snapcore/snapd/pull/5111>
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/5111
<mup> PR #5111: cmd/snap: update install/refresh help vs --revision <Created by pedronis> <https://github.com/snapcore/snapd/pull/5111>
<Chipaca> pedronis: you can also refresh to a local revision
<pedronis> I killed too much text?
<Chipaca> reading
<pedronis> it was not saying that before either
<Chipaca> ah, no, it didn't mention this before either
<pedronis> we can fix it though
<Chipaca> wording is tricky :-)
<pedronis> just trying to understand if I killed something that was there
<Chipaca> no, it's fine
<Chipaca> you even fixed the revision descr on refresh which i'd missed
<pedronis> ", unless is one of the previous locally kept revisions,"  ?
<pedronis> Chipaca:   https://pastebin.ubuntu.com/p/w3sTVMDQXv/  ?
<Chipaca> pedronis: hmm, that's rather awkward
<Chipaca> pedronis: leave it as is for now
<Chipaca> pedronis: we can iterate when my head is more into it
<Chipaca> sorry
<pedronis> that's fine
<pedronis> at least there's a PR
<pedronis> so we don't forget
<pedronis> and don't lie either
 * pedronis -> dinner
<Chipaca> ok, ttfn
<cachio_> zyga, https://github.com/snapcore/spread-images/pull/10
<mup> PR spread-images#10: New task to add debian-sid as a gce image <Created by sergiocazzolato> <https://github.com/snapcore/spread-images/pull/10>
<cachio_> could you please take a look
<cachio_> it is ready again
<cachio_> thanks
<cachio_> zyga, we have again working the builds in travis
<zyga> Thank you
<mup> PR snapcraft#2110 opened: tests: conditionally add python3-distutils <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2110>
<pstolowski> niemeyer: #4358 is ready for your re-review
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<niemeyer> pstolowski: Thanks!
<niemeyer> pstolowski: Not quite sure if we should merge it now, though, given that you'll be away most of next week.. we risk having issues in edge that won't be addressed before you're back
<pstolowski> niemeyer: valid concern
<pstolowski> niemeyer: perhaps jdstrand would like to have a look still.. not sure
<niemeyer> pstolowski: Not sure if that's required.. have we changed anything since his last review?
<pedronis> he didn't review it at all yet
<pedronis> IÂ think
<pedronis> mmh, github is giving me a unicorn
<pedronis> no, indeed, no review from him yet
<pstolowski> niemeyer: yes, as pedronis says, Jamie didn't look at it yet
<pstolowski> yes i've unicorns a lot today too
<niemeyer> pstolowski: Would be worth pinging jdstrand for a review then
<niemeyer> pstolowski: He'll have all of next week to have a look
<pstolowski> allright
<pedronis> he is at the sprint tough
<pstolowski> jdstrand: in case you'll be reviewing #4358, the most critical part is small changes around policy checks
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<pstolowski> ok, i'm signing off, have safe trips!
<jdstrand> pstolowski|eow: ack and noted
<zyga> jdstrand: are you in Europe already?
<magicaltrout> congrats to all you snappy folk for the new found 18.04 love! Well deserved.
<zyga> woot, snaps progressed quite a lot since 15.04 days :)
<thresh> they were available since 15.04?!
<thresh> you should really spend some $$$ on marketing ...
<jdstrand> zyga: leave tomorrow
<om26er> zyga: anything specific you noticed ?
<mcphail> Hmm. building on build.snapcraft.io: the amd64 build fails due to a compilation error, the i386 build completes successfully and then the arm build fails due to a different compilation error. No idea how to debug that one :(
#snappy 2018-04-28
<mup> PR snapcraft#2109 closed: sources: clean up IncompatibleOptionsError <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2109>
<DataLinkDroid> I noticed on the snapcraft.io website that about eleven languages are listed as having some kind of special support.
<DataLinkDroid> How hard is it to package up a snap for a language (like Ada/GNAT) that does not have this specific support in snapcraft?
<DataLinkDroid> Is it an easy matter to add such support? (Note that GNAT uses gcc.)
<zyga> DataLinkDroid: It should be pretty easy. Snapcraft has generic makefile/shell plugins that let you write any compiler rules you want
<zyga> The special support is just in using language native concepts such as supporting pip for python
<zyga> For compiled languages it is even easier
<DataLinkDroid> zyga: Thanks, yes I was just coming to that conclusion about using the make plugin.
<DataLinkDroid> How does the auto update from GitHub repo work? Does it do an automatic recompile of the source code that changes on GitHub?
<DataLinkDroid> That would mean specifying the build environment. Not sure how that would work. Perhaps a particular compiler is required for the build...
<DataLinkDroid> Or is the GitHub update only used for scripting languages like Python, where for all intents and purposes, the text *is* the "binary".
<DataLinkDroid> Sorry if I'm flooding with too many questions... :-)
<DataLinkDroid> Maybe I just need to try it and see how it all fits together.
<zyga> It is used for everything
<zyga> Snapcraft.yaml describes how to do everything
<zyga> The plugin system does most of the heavy lifting
<zyga> But everything can be specified manually too
<zyga> Build dependencies, etc
<zyga> Look at snapcraft documentation
<zyga> Also look at the forum, it has plenty of discussions to search
<DataLinkDroid> zyga: Cool. Thank you. Will do.
<ogra_> hmm, did the release page get cut down on dashbard.s.io ? i only get checkboxes for beta and edge in the release form
<ogra_> ah, silly me ... the snap had "grade: devel" ... (an error/warning/notice on the form page would have been really nice)
<Intruder777|1> hi. is there a way to run particular snap as non-root user
#snappy 2018-04-29
<Chipaca> ogra_: https://groups.google.com/forum/m/#!topic/rec.games.roguelike.nethack/XhcIrLlNzpA
<Chipaca> ogra_: you're slipping :-)
<ogra_> Chipaca, oh man ... lets see if that early-2015 package still builds then ...
<Chipaca> ogra_: i'm surprised it's that big
<Chipaca> ogra_: xbill is 2MB :-)
<ogra_> it brings all fonts, locale and input support with it
<Chipaca> fonts?
<Chipaca> wait, it's the graphical one?
<ogra_> yes, terminal fonts
<ogra_> no
<Chipaca> fonts for the linux console?
<ogra_> it uses a on for special chars ... there is a "stage-packages console-setup-linux ... and locales" ... and it generates all locales during build
<Chipaca> ogra_: i suspect you can trim some things down
<ogra_> *it uses a lot of fonts
<Chipaca> ogra_: for example, you might not need update-initramfs.8.gz
<ogra_> yeah, i guess
<Chipaca> ogra_: in the snap
<Chipaca> ogra_: I suspect if you started from upstream you could make it a lot smaller
<ogra_> yes
<Chipaca> ogra_: (and i don't think the snap is benefiting from having the console setup stuff in it)
<ogra_> it needs the game-locale properly< set to work at all
<ogra_> for that it needs quite a bunch of settings ... butu indeed there is a lot of cruft, i never bothered to fully clean it up
<Chipaca> anyhoo, i'm off to finish making lunch
<ogra_> Chipaca, thanks for the headsoup :)
<mup> PR snapcraft#2108 closed: HACKING: suggest snapcraft-pr for evaluating PRs <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2108>
<mup> PR snapd#5092 closed: snap: do not use overly short timeout in `snap {start,stop,restart}` <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5092>
<mup> PR snapd#5110 closed: interfaces/apparmor: fix incorrect apparmor profile glob (2.32) <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5110>
<zyga> Thank you
<mup> PR snapd#5112 opened: snap: do not use overly short timeout in `snap {start,stop,restart}` (2.32) <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5112>
<mup> PR snapd#5113 opened: cmdstate: add missing test for default timeout handling <Created by mvo5> <https://github.com/snapcore/snapd/pull/5113>
<mup> PR snapd#5112 closed: snap: do not use overly short timeout in `snap {start,stop,restart}` (2.32) <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5112>
<mup> PR snapd#5114 opened: release: 2.32.6 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5114>
#snappy 2019-04-22
<cachio> zyga, pstolowski|afk standup?
<zyga> cachio: holidays today
 * cachio afk
<cachio> for lunch
<brlin> https://forum.snapcraft.io/t/disabling-seccomp-sandbox-where-a-buggy-golang-seccomp-is-used/11054
<kenvandine> zyga: i'm working on adding Yaru-dark to gtk-common-themes and run into an issue
<kenvandine> upgrading gtk-common-themes to a snap that includes the additional theme doesn't actually show up for existing snaps that connect to it
<kenvandine> zyga: i had to disconnect and connect again
<kenvandine> and then it shows up
<zyga> kenvandine: please share instructions for me to try
<zyga> kenvandine: I'm on holidays today but I will check again
<zyga> jdstrand: fun stuff
<zyga> jdstrand: thank you for sharing, I think we should talk tomorrow for options
<jdstrand> zyga: yes. this is getting fairly frustrating
<zyga> jdstrand: I have a personal preference on what to do but it may be unrealistic in the short term
<zyga> jdstrand: but I will assist in the path picked by the team
<jdstrand> zyga: I can join the standup if it is at a compatible time. when is it?
<zyga> jdstrand: 15CET
<zyga> jdstrand: let me see if I can invite you
<zyga> jdstrand: sent you an invite
<zyga> jdstrand: see if you can join at the time
<jdstrand> it conflicts iwth something else, but I can move that tomorrow. thanks
<kenvandine> zyga: thanks
<kenvandine> zyga: once i get a CI build of the snap i'll point you at it
<zyga> jdstrand: ack
<zyga> jdstrand, kenvandine: I'm going out for a walk with Lucy, ttyl
<zyga> jdstrand: thank you for chasing the seccomp bug
<kenvandine> zyga: basically, $SNAP/data-dir/themes/Yaru-dark doesn't exist until i disconnect and connect again
<jdstrand> zyga: enjoy your day :)
<zyga> jdstrand: one request if you can: indicate which versions are affected
<kenvandine> zyga: enjoy!
<zyga> ttyl!
<jdstrand> zyga: I already did, so, 'ok' :)
<kenvandine> zyga: bug 1825883
<zyga> kenvandine: ack, thank you
#snappy 2019-04-23
<zyga> Good morning (perhaps)
<mborzecki> morning
<zyga> mborzecki: hey
<zyga> How was Easter?
<mborzecki> zyga: too short :)
<zyga> Today will be full of stuff :/
<zyga> In the bad sense I suspect
<mborzecki> zyga: hmm https://forum.snapcraft.io/t/disabling-seccomp-sandbox-where-a-buggy-golang-seccomp-is-used/11054
<zyga> Yeah, that is one
<mborzecki> zyga: do you know if the version in 29 is ok?
<zyga> I didnât check yet
<zyga> I will be in the office at around 8
<mborzecki> brb, got to reboot, new kernel
<mborzecki> zyga: has the mystery of broken seed.yaml been explained?
<mborzecki> zyga: seed.yaml from that alpha image has a slightly weird format like so https://paste.ubuntu.com/p/vM2MZjZN2t/ but the test i added to check that in the code seems to work fine, no nils
<zyga> No, we donât know anything more yet
<mborzecki> zyga: i did a clean install with the alpha iso, no issues
<zyga> We need to talk to foundations to ask who can help with the installer
<zyga> We donât know how the seed is made
<mborzecki> zyga: definitely the format is slightly awkward, so for instance this variant causes a nil https://paste.ubuntu.com/p/9N7CXZRtwv/
<zyga> Yeah
<zyga> This is regular yaml
<zyga> Nothing special
<mborzecki> zyga: fwiw, we could have used SeedSnap instead of a pointer
<zyga> Yes
<zyga> Not sure why we did
<mborzecki> i'll check f29 golang seccomp next, according to bodhi it was updated recent'y, but i'm not sure whether that's 0.9 tag exactly or some other commit
<mborzecki> didn't know you could embed lua in rpm macros
<zyga> Thanks
<zyga> I will look at a content bug
<mborzecki> zyga: something new?
<zyga> Yes
<zyga> Reported in response to a theme bug
<zyga> mborzecki: ok, in the office now
<zyga> obviously kids didn't want to go with the dog so I had to
<zyga> mborzecki: nothing in recent memory has made them more lazy than the teacher's strike
<zyga> mborzecki: is mvo working today?
<mborzecki> zyga: idk
<mborzecki> zyga: fedora's updated libseccomp-gois exactly 0.9 release, so the commit with the fix is not included
<mborzecki> zyga: filed a bug in fedora https://bugzilla.redhat.com/show_bug.cgi?id=1702169
<zyga> ack
<mborzecki> on centos we used vendored packages
<mborzecki> zyga: so i'm thinking, fedora & debian are the only 2 distros that do not bundle golang deps, once they are fixed, we may not need to disable seccomp dynamically at all
<zyga> mborzecki: jdstrand will join our standup today
<zyga> mborzecki: perhaps discuss with him then
<mborzecki> zyga: and a silly thought, since we already do the snap-seccomp version-info magic, maybe we could extend this to cover bpf output geenrated by the lib too?
<zyga> mborzecki: eh :)
<zyga> that's one rabbit hole IMOI
<mborzecki> zyga: i mean the problem is that even if they update snap-seccomp bindings, we may not renerate the profiles, because lib version and supported syscalls could stay the same
<zyga> yes, I was thinking about this earlier, all the effort we did
<zyga> it is really insufficient
<mborzecki> zyga: or we could get a pass from fesco or other body and just bundle that dep? :)
<zyga> mborzecki: good luck to get that approved in the next 60 days ;)
<mborzecki> anyways, golang deps are still arguably silly and don't fit the disto world (or iow the distro world did not catch up with golang/rust/node/python package handling yet)
<zyga> mborzecki: it cannot catch up
<zyga> mborzecki: but that's a separate conversation
<pstolowski> mornings!
<om26er> Hi! I opened that one https://forum.snapcraft.io/t/auto-connection-request-for-gpio-interface/11013 -- is that under the current store rules possible ?
<mborzecki> zyga: better had with a glass of beer :P (we should make a list of beer-topics fwiw)
<mborzecki> pstolowski: hey
<zyga> mborzecki: haha, a trello lane :)
<zyga> pstolowski: good morning, how are you doing?
<zyga> pstolowski: had enough mazurki over weekend? :-)
<zyga> om26er: yes
<pstolowski> zyga: i'm fine, and satiated :)
<pstolowski> how are you guys?
<zyga> pstolowski: depressed a little
<zyga> pstolowski: floodgates of bugs
<zyga> pstolowski: I want holidays that last 4 days :)
<pstolowski> oh... i need to catch up
<pstolowski> mborzecki: can you take a look at https://github.com/snapcore/snapd/pull/6728? that could land
<mborzecki> pstolowski: sure
<zyga> mmmmm
<zyga> hmmm
<zyga> bugs, bugs everywhere
<zyga> there is something wrong with slot attrs
 * zyga wants snap plugs and snap slots
<zyga> it's infuriating to debug
<mborzecki> zyga: shouldn't mei rule be /dev/mei[0-9]* ?
<zyga> mborzecki: why?
<mborzecki> zyga: because i don't see + in the manpage :)
<zyga> mborzecki: ?
<zyga> mborzecki: in apparmor re?
<mborzecki> zyga: yeah, the manpage is not too useful, but i don't see anything that uses +
<zyga> mborzecki: grep for + in interfaces
<zyga> perhaps it's a common bug
<zyga> apparmor RE sucks a little for being custom
<zyga> zyga@fyke:~/Documents/go/src/github.com/snapcore/snapd/cmd/snapd$ sudo ./snapd
<zyga> AppArmor status: apparmor is enabled and all features are available
<zyga> cannot run daemon: cannot obtain snap-seccomp version information: error: unsupported argument "version-info"
<zyga> mborzecki: how do I run snapd now?
<mborzecki> zyga: build snap-seccomp and put it in the same dir
<zyga> ok
<zyga> a bit meh
<zyga> eh
<zyga> not a great day
<zyga> pstolowski: we have a serious bug in interfaces
<pstolowski> zyga: uh, what is it?
<zyga> pstolowski: hold on, let me prepare everything first
<mborzecki> zyga: heh, looks like a bug in patterns, we have /dev/sr[0-9]* /dev/rtc[0-9]* /dev/input/event[0-9]* but only /dev/mei[0-9]+
<zyga> mborzecki: I disagree
<zyga> mborzecki: zyga@fyke:~/Documents/go/src/github.com/snapcore/snapd/interfaces/builtin$ git grep ']+'
<zyga> for me it shows much more than one item
<zyga> ah, sorry
<zyga>  we use go REs as well
<mborzecki> those are from go
<zyga> mborzecki: sanity check, apparmor, use of + is a bug?
<mborzecki> zyga: for all we know the parser does not complain :)
<zyga> mborzecki: the parser sucks
<mborzecki> zyga: fwiw, all other patterns use *
<mborzecki> i'll open a PR
<mborzecki> meh
<zyga> mborzecki: thanks, assign the bug to yourself too
<mborzecki> https://github.com/snapcore/snapd/pull/6762
<mborzecki> zyga: ^^
<mborzecki> back to pstolowski's review
<zyga> pstolowski: can you HO?
<zyga> pstolowski: need your eyes on something
<zyga> I'm in standup
<zyga> mborzecki: wanna see?
<cjwatson> diddledan: in case you didn't notice, https://github.com/diddlesnaps/gog-galaxy-wine/blob/master/snap/snapcraft.yaml has conflict markers in it and is thus failing to parse as YAML
<Chipaca> mborzecki: I don't know AARE; does * there mean "0 or more"? (the manpage is not clear to me -- it says "any number" which might include 0 or not)
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:fix/lp-1825883?expand=1
<zyga> Chipaca: -1
<zyga> ;)
<zyga> Chipaca: hey
<Chipaca> 'sup
<mborzecki> Chipaca: i think it's more like glob for file paths, so dev /dev/mei[0-9] matches mei0-mei9 followed by whatever that's not /
<zyga> Chipaca: fun day continues https://bugs.launchpad.net/snapd/+bug/1825883/comments/4
<mborzecki> Chipaca: unforunately apparmor.d manpage is most useless explaining AARE :/
<diddledan> thanks cjwatson
<zyga> Chipaca, mborzecki: my personal experience is that the documentation is only partial there
<zyga> the only way to learn more is to look at what the kernel reads
<zyga> which is non-trivial
<mborzecki> Chipaca: for reference, we allow `/dev/tty[0-9]* rw,` for x11 and other rules also follow [0-9]* patterns
<Chipaca> mborzecki: /dev/tty is a thing tho
<zyga> I failed mid way on that because of the representation of AARE is only documented in the C implementation as imperative code, there's no comment as to what the representation is
 * zyga wrote a partial apparmor decompiler at one point in the past
<mborzecki> Chipaca: fair enough, /dev/ttyUSB is not :) /dev/tty{USB,ACM}[0-9]*
<zyga> windy dat
<zyga> *day
 * zyga wants a set of debug commands that just display the data from the state 
<mborzecki> zyga: hm maybe we'll have libseccomp-golang updated in fedora sooner than expected -> https://bugzilla.redhat.com/show_bug.cgi?id=1702169
<mborzecki> which would be great imo :)
<zyga> mborzecki: report a debian bug too please
<zyga> pstolowski: so
<zyga> pstolowski: the problem is that snap connect is storing information that is never updated after the fact
<mborzecki> sore & forget
<mborzecki> store & forget
<pstolowski> zyga: right. we never call doConnect again, and with the new logic of storing static attrs in the state we don't refresh them, in the old implementation setup-profiles would pick the new attributes right?
<zyga> yes
<pstolowski> damn
<pstolowski> that's bad
<zyga> yes :)
<zyga> looking at what may be the best way forward now
<zyga> but first I want to add a system
<zyga> that records a trace of revision in the repo
<zyga> so repo will know what the revision of each snap is
<zyga> and will panic if those disagree
<pstolowski> zyga: we need to think, perhaps we should re-run all the interface hooks, that means disconnecting first and then re-connecting
<zyga> pstolowski: I think we need to take a step back and write some invariants
<zyga> pstolowski: hooks are both niche and complex
<zyga> pstolowski: I'd like to support them but going through the hook door first might just confuse us more
<pstolowski> zyga: maybe we should take step back and reconsider storing static attrs in state, and only use that for hotplug slots
<zyga> pstolowski: maybe, I will add consistency checks to the repo and see what we get
<pstolowski> zyga: i think setupProfilesForSnap needs fixing. it already does repo.Remove(snap) and Re-add(snap), and then reloadConnection which picks outdated attrs from state.
<pstolowski> zyga: if _, err := m.repo.Connect(connRef, conn.StaticPlugAttrs, conn.DynamicPlugAttrs, conn.StaticSlotAttrs, conn.DynamicSlotAttrs, nil); err != nil { ... in reloadConnections
<zyga> pstolowski: I agree this is where the error is triggered
<zyga> pstolowski: I'm not yet sure what is the best way to fix it
<popey> https://bugs.launchpad.net/snapd/+bug/1825956
<popey> This was reported to me by multiple people over the weekend
<popey> Feels somewhat critical (if it's not already known
<zyga> popey: this is a duplicate of another bug
<popey> ok
<popey> it's biting a lot of people because 19.04 just came out and lots of people are installing systems with no snaps pre-installed
<zyga> https://bugs.launchpad.net/snapd/+bug/1819318
<zyga> marked as such now
<zyga> popey: I agree
<zyga> popey: just ETOOMANYBUGS
<diddledan> bugs.reduce((status) => status.ignore());
<diddledan> :-p
<diddledan> that should be a map really
<diddledan> I suck at jokes
<popey> nerd jokes are best jokes
<popey> (for nerds)
<diddledan> :-)
<zyga> pstolowski: hmm
<zyga> never mind
<zyga> pstolowski: question, open interface manager's handlers.go and go to doConnect
<zyga> pstolowski: inside that function look at the call to repo.Connect
<zyga> pstolowski: it takes plugDynamicAttrs and slotDynamicAttrs, not taking static attrs (not sure why)
<pstolowski> zyga: looking
<zyga> pstolowski: now the questsion is, a few lines below that, we create connState and store plug and slot static and dynamic attrs using conn.{Plug,Slot}.{Dynamic,Static}Attrs() instead of what we passed to Connect
<zyga> why is that?
<zyga> aah
 * zyga is dumb
<zyga> sorry, this is correct
<zyga> we save what the connection gave us
<zyga> pstolowski: sorry for wasting your time
<pstolowski> zyga: no worries. NewConnectedPlug and NewConnectedSlot are special-cased for nils and take static attrs from plug/slot info
<pstolowski> zyga: i'm thinking a fix i suggested above for setupprofiles/reload connections is a potential solution, i'm happy to work on this, just let me know
<zyga> pstolowski: I'm still working on this, I'm not convinced that is enough (it would fix it but I want to be sure we've fixed all cases of this issue)
<pstolowski> ok
<pstolowski> zyga: if you're making repo rev-aware, then i think it would be great to keep it separate from actual bugfix (if possible), i think it's a bit orthogonal problem
<zyga> pstolowski: no worries :)
<zyga> pstolowski: the repo is not the problem
<zyga> pstolowski: I made that but id doesn't pick up the problem (obviously)
<zyga> pstolowski: I'm making connState rev aware
<zyga> pstolowski: we run the refresh hooks right?
<zyga> pstolowski: but on snap refresh we don't run interface hooks, do we?
<pstolowski> zyga: correct, except for autoconnects, those can run hooks
<zyga> hmm?
<zyga> how do you mean?
<zyga> pstolowski: so, I think we have two bugs now
<pstolowski> zyga: as part of install/refresh we run "autoconnect" to connect new interfaces (if applicable); it will run hooks
<zyga> I see
<zyga> the first bug is that the static attributes are stale, that's plain and obvious
<zyga> the dynamic attributes are equally out of date, if you setup a content connection hook you will most likely be able to see the revision in the path you observe
<zyga> if you refresh stuff those will be stale equally (so snaps will not see the accurate paths if they use hooks to update them)
<zyga> pstolowski: I will break now, take a walk and think about this
<zyga> pstolowski: my gut feeling is that we need to rethink refresh and interfaces
<zyga> pstolowski: we can "hack" to fix this issue
<zyga> pstolowski: but the core issue is more complex and I think what we do today is simply inconsistent with itself
<zyga> pstolowski: we need to find something that is correct and consistent
<zyga> pstolowski: and also not annoying or difficult to use for users
<zyga> pstolowski: (e.g. do you see a disconnect hook and a connect hook when your peer refreshes?)
<zyga> pstolowski: it's extra tricky for content because the snap will synchronously see the old and the new state and nothing in beteween
<zyga> pstolowski: so the hook is really "hey buddy, it changed" without a way to see the prior state
<zyga> pstolowski: I changed stuff enough in my branch to detect when the connection state is inconsistent with the repository
<pstolowski> zyga: for autoconnect we do plugStatic, slotStatic, err := initialConnectAttributes(st, plugSnapInfo, plugSnap, plugName, slotSnapInfo, slotSnap, slotName), that's what the hooks see, and that is from CurrentInfo() after link-snap
<pstolowski> zyga: that's in ifacestate.connect(..) that creates interface hook tasks
<zyga> pstolowski: forget autoconnect
<zyga> pstolowski: when you refresh a snap with an existing connection, the peers of that snap *never know about the refresh*
<zyga> pstolowski: and attributes encode the revision
<zyga> pstolowski: so if you use hooks to update internal snap config you are SOL
<zyga> pstolowski: I pushed some patches to https://github.com/snapcore/snapd/compare/master...zyga:fix/lp-1825883?expand=1
<pstolowski> zyga: i'll show you something
<pstolowski> zyga: https://github.com/snapcore/snapd/pull/5200/
<pstolowski> zyga: almost one year ago ;)
<pstolowski> zyga: see // on refresh re-connect existing connections and run their interface hooks (if applicable)
<pstolowski> zyga: there is even a spread test
<zyga> pstolowski: that's good in itself
<zyga> pstolowski: does this update connection state as well?
<zyga> pstolowski: https://github.com/snapcore/snapd/commit/fe3498a40ac38857142525f781ea808447b19c5e this errors whenever we would take a decision based on old data
<zyga> pstolowski: I'm happy to chat over TG but I need a walk now
<pstolowski> zyga: yes that old branch updates connstate because it disconnectes and then reconnects, so it runs disconnect hooks and then connect hooks
<pstolowski> zyga: it was parked back then :(
<zyga> pstolowski: Iâll run my branch on all current tests to see if something is already affected
<zyga> pstolowski: https://twitter.com/ismonkeyuser/status/1120568699168133120
<zyga> ;-)
<pstolowski> :D
<zyga> mborzecki: can you edit https://github.com/snapcore/snapd/pull/6762 to reference the bug report please
<mborzecki> zyga: was there one?
<zyga> mborzecki: I think so, no? was that just on the forum>
<zyga> mborzecki: then at least a Forum: ... entry next to signed-off-by
<mborzecki> zyga: i've only seen the forum post
<mborzecki> zyga: so you mean the commit message?
<zyga> mborzecki: yeah, or the PR merge message
<zyga> pstolowski: I patched my branch to only report an error when the static attributes actually differ
<zyga> pstolowski: we still have tests failing :/
<zyga> pstolowski: so we currently may depend on incorrect behivior
<zyga> *behaviour
<pstolowski> uhm
<pstolowski> i'm afraid the only correct way of dealing with this is to really re-run (reconnect) everything (like in my old PR, modulo comments from pedronis - namely the comment re hooks not knowning if it's initial connect vs reconnect). we need to discuss when he is back
 * pstolowski is kicking himself for not realizing significance of landing or not landing that old PR
<jdstrand> mborzecki: fyi, apparmor.d *does* have AARE: "AARE = ?*[]{}^"\nSee below for meanings"
<mborzecki> jdstrand: right, but the 'see below for meanings' is so informative
<jdstrand> mborzecki: the bit under Globbing?
<mborzecki> jdstrand: right, that one
<jdstrand> huh. I find that clear...
<jdstrand> how would you like to see it changed? I can fix it upstream
<Chipaca> jdstrand: in particular, it says Â«*   can substitute for any number of characters, excepting '/'Â», but doesn't say whether "any number" includes 0
<Chipaca> jdstrand: i.e. does /dev/foo[0-9]* match /dev/foo
<jdstrand> it's a glob
<jdstrand> so, 'no'
<jdstrand> but 'yes', I see what you mean
<Chipaca> :-)
<mborzecki> jdstrand: also it says globbing, vs me expecting something mentioning AARE (because that's how it's named above)
<jdstrand> I mean it does say 'File resources may be specified with a globbing syntax similar to that used by popular shells, such as csh(1), bash(1), zsh(1)." but it isn't as clear as it be
<jdstrand> mborzecki: yes. up above it says See below without referencing Globbing, and down below it talks about globbing but not AARE
<jdstrand> mborzecki: you probably saw that I approved and merged the pr
<jdstrand> mborzecki: thanks. I don't know how I missed that :\
<mborzecki> jdstrand: mhm, thanks!
<zyga> jdstrand: hey
<zyga> jdstrand: fun day
<Chipaca> jdstrand: eoan pronuciation guide: https://www.youtube.com/watch?v=iQXMdR0XDT8
<jdstrand> Chipaca: hahaha
<Son_Goku> mborzecki, how close are we to 2.39 release?
<mborzecki> Son_Goku: idk, i'd say not far, zyga do you know?
<zyga> Son_Goku: hard to say
<zyga> Son_Goku: I'd say we will postpone because of bugs
<zyga> but mvo is out so I cannot say with certainty
<Son_Goku> okay
<zyga> Son_Goku: it's  been a week of bugs
<roadmr> ððð
<zyga> roadmr: lol :)
 * zyga runs an errand, see you later
 * cachio afk
<om26er> Hi! Regarding requests for auto-connection of snap interfaces, how long does it generally take and also what number of +1's does it take for a request to go live ?
<om26er> case in point https://forum.snapcraft.io/t/please-allow-auto-connect-of-display-control-interface-for-deskconn/10831
<Chipaca> om26er: https://forum.snapcraft.io/t/process-for-aliases-auto-connections-and-tracks/455
<om26er> thanks Chipaca
<Chipaca> om26er: i've pinged @reviwers on that one as it's high time they looked at it
<Chipaca> om26er: but that topic explains # of votes, timeline, etc
<om26er> Chipaca cool, there is already a new +1 on that one ;-)
<Chipaca> I wonder if today's xkcd is about libseccomp
<jdstrand> heh
<zyga> Re
 * zyga looks at xkcd
<zyga> I guess  I should EOD
#snappy 2019-04-24
<mborzecki> morning
<zyga> Hey Everton
<zyga> Everyone even
 * zyga coffee
<mborzecki> zyga: hey
<mborzecki> zyga: jdstrand: verified that multi arg filtering issue is indeed fixed with the proposed libseccomp-golang package update in fedora 29
<mborzecki> mvo: welcome back
<mvo> hey mborzecki
<mvo> mborzecki: good morning! what did I miss?
<mborzecki> mvo: jdstrand has some interesting findings about libseccomp and go bindings
<mvo> mborzecki: oh? in the forum? in a PR?
<mborzecki> mvo: https://bugs.launchpad.net/snapd/+bug/1825052 and forum as well
<mborzecki> mvo: there's also https://github.com/snapcore/snapd/pull/6681#issuecomment-485930543
<mvo> mborzecki: woah!
<mborzecki> mvo: and a relevant forum topic https://forum.snapcraft.io/t/disabling-seccomp-sandbox-where-a-buggy-golang-seccomp-is-used/11054
 * mvo nods
<mvo> mborzecki: anything pending for 2.39 that needs a cherry-pick/backport?
<mborzecki> mvo: this probably https://github.com/snapcore/snapd/pull/6762
<mvo> mborzecki: yes, that looks like it
<mvo> mborzecki: doing that now, thank you
<mborzecki> mvo: maybe this one too https://github.com/snapcore/snapd/pull/6748 (spread jobs debugging help)
<zyga> Hey mvo
<zyga> mvo: yes
<zyga> mvo: interfaces have a serious bug
<zyga> mvo: also CE waits for firmware fix badly for 2.39
<mvo> zyga: do we need 2.38.2 for the seccomp issue?
<zyga> mvo: also snapd panics on 19.04
<zyga> mvo: you need to process all the bugs and decide
<mvo> zyga: what is the bugnumber for 19.04?
<mvo> zyga: it sounds very much like we need one :/
<zyga> One moment
<zyga> mvo: https://forum.snapcraft.io/t/snap-apps-not-working/11000/4
<zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1825437
<zyga> mvo: people are also affected by https://bugs.launchpad.net/snapd/+bug/1819318
<zyga> mvo: and yesterday we debugged https://bugs.launchpad.net/snapd/+bug/1825883
<zyga> but fixing it is not something easy
<mvo> zyga: thanks, looking
<mvo> 6720 needs a second review, it touches quite some bits so I would love to merge it soon to avoid conflicts
 * dot-tobias says hi
<zyga> mvo: done
<zyga> hey dot-tobias
<mvo> zyga: ta
<pstolowski> morning
<mvo> hey pstolowski !
<mborzecki> pstolowski: hey
<Chipaca> 'sup
<Chipaca> (morning!)
<zyga> pstolowski: hey, I wrote some thougts about the interface problem: https://bugs.launchpad.net/snapd/+bug/1825883/comments/6
<zyga> I would appreciate if you could have a look
<zyga> hey Chipaca, how are you doing?
<Chipaca> zyga: chipaca integrity is at 73%
<zyga> reverse booze polarity
<pstolowski> zyga: thanks, looking
<Chipaca> zyga: nah, lower back still not happy, but i'm a'ight
<zyga> mvo: updated https://github.com/snapcore/snapd/pull/6756
<zyga> https://github.com/snapcore/snapd/pull/6758 is super boring, just some code moving from place to place + new tests
<pstolowski> zyga: btw, i was wrong in one aspect re my earlier reconnect PR - disconnect was not run there (I misread the diff), reconnect was only re-executing prepare- and connect- hooks, so it was doing what you're suggesting (expect for prepare- step which was also run). i generally agree with the idea of (re)running interface hook(s) on refresh, but i think Samuele's comment to my original PR still stands. perhaps separate
<pstolowski> 'connection-updated' hook is the aswer to that question (although it still complicates the implementation of hooks for snap devs). also i think not updating dynamic attributes during refresh may be problematic, they may be derived from static attributes of either side of the connection so if static attrs change, dynamic ones can change as well
<zyga> pstolowski: re-connect vs initial-connect?
<zyga> simple, there's no parepare no disconnect
<zyga> pstolowski: hmmm, interesting observation about the dynamic attributes
<zyga> pstolowski: is there anything that could be used as an example?
<pstolowski> zyga: example is only theoretical at this point: snap A exposes some content, prepare- hook of snap B reads the exposed path attribute and sets own path attribute (i'm not sure content interface as is would support that, but that's the general idea)
<dot-tobias> Question about device intialization, specifically how to shorten its duration: https://forum.snapcraft.io/t/shorten-device-initialization-or-at-least-give-user-feedback/11081 ping ogra / mvo
<mvo> dot-tobias: thats an interessting one - we want to improve this (hopefully in the next cycle) by doing as much as we can in the image creation time. right now its slow (and a pain point for many)
<mvo> dot-tobias: would it help if we could make some led blink to show the users things are still going?
<mvo> dot-tobias: does the rpi has anything like this we could use (pardon my ignorance on this)?
<zyga> mvo: perhaps seeding the gadget to run boot splash is the way to go
<dot-tobias> mvo: Glad to hear, both that it's on the radar and that it's possible at all to move init to image creation ð The RPi has a âstatusâ LED which (I think) already blinks sporadically during init, but I fear a small LED would suffer the same fate as our hint âdon't worry if it takes > 8 minutesâ on our download page â easily ignored since most of our users are not that tech-savvy
<zyga> mvo: I agree with dot-tobias, let is not the good UX here
<zyga> ideally 1st boot would allow device makers to setup proper UX on the attached screen (if any)
<zyga> or perhaps 1st boot should really be in the factory
<zyga> and we should have post factory boot 2nd boot
<zyga> that does some custom stuff but is otherwise fast
<mvo> zyga: right, I agree :) was mostly wondering what we can do today to help
<mvo> dot-tobias: do your users have a screen attached?
<mvo> zyga: I like the screen idea
<mvo> Chipaca: what came out of this 2.38 snapd rest api issue that was reported on the forum last week?
<Chipaca> mvo: hmm... remind me?
<mvo> Chipaca: let me find the forum topic
<dot-tobias> mvo: Yes, the image is meant for display devices, so users have a screen.
<mvo> Chipaca: https://forum.snapcraft.io/t/snapd-2-28-rest-api-endpoints-with-large-response-issue/10968/3
<dot-tobias> zyga: Yeah, a splash screen would work â BTW, did I misunderstand or do Core18-images show a splash *without* psplash?
<mvo> dot-tobias: I wonder if (again - short term) something like a hook or an app that would monitor the snapd socket with progress would help
<Chipaca> mvo: ah! â some behavior in Nginx and does not necessarily need to be an issue in the Snapd REST API socketâ
<Chipaca> mvo: (from the last reply on that)
<mvo> Chipaca: aha, thanks. so just user confusion?
<zyga> dot-tobias: I don't know about core18 and pi and splash screens I'm afraid
<Chipaca> mvo: not sure if confusion is the right word, but the issue is in how they're proxying snapd, not in snapd
<Chipaca> mvo: AIUI; I half expect them to come back and ask "so when are you going to fix it"
<mborzecki> zyga: maybe some plymouth integration?
<Chipaca> because at no point did they say "oops my bad"
<zyga> mborzecki: dunno really, I would not marry the two concepts
<mvo> Chipaca: ok, somehting changed on our side with go-1.10 I guess and that confusd nginx?
<Chipaca> mvo: but some people are unable to say that Â¯\_(ã)_/Â¯
<mvo> Chipaca: did go1.10 switch to http2 by default?
<dot-tobias> zyga: Oh sorry â only first part of that message was a reply to you, second one was thinking while writing ð
<mvo> Chipaca: heh, yeah I guess that might happen (that they ask us to fix something)
<zyga> mborzecki: boot splash might as well be shown on a dot-matrix display attached to a gizmo
<mvo> Chipaca: to be fair - we did change something :/
<Chipaca> mvo: http2 is supported, but that's not new between 1.6 and 1.10
<mvo> Chipaca: ok, I have this feeling this will come back but its fine to shelve it for now I think
<Chipaca> mvo: we agree then
<mvo> Chipaca: especially with the things we need/want to finish before lyon
<Chipaca> mvo: lyon is next week?
<dot-tobias> mvo: re: hook/app to monitor snapd socket: Might be a short-term solution, but that wouldn't be able to output something until at least core, gadget and mir-kiosk are properly installed, if I'm not mistaken?
<Chipaca> mvo: (http2 is only supported if we're doing TLS, and we're not, so actually no http2)
<mvo> Chipaca: 13.05
<Chipaca> ah, phew
<mvo> dot-tobias: yeah, it would be late :/
<zyga> I think it must be some gadget specific thing
<zyga> before mire and all the stuff is up
<zyga> perhaps even a special hook that gets run
<mborzecki> mvo: dot-tobias: this really feels like some custom initramfs, with early boot splash via plymouth or somesuch, effectively device/appliance specific
<zyga> seeding-started seeding-done or something of the sort
<zyga> mborzecki: yes but it would be nicer if we could have this done via gadgets
<mborzecki> zyga: initrd is part of core though and we don't expect people to build a custom core*
<zyga> mborzecki: indeed, they can do custom bases but it would be pretty unfortunate if we would force people to add a lot of boot bases to have a splash screen
<mborzecki> yup
<Chipaca> ogra had boot splashes working
<Chipaca> how'd he do it?
<Chipaca> ogra: yes you :-)
<dot-tobias> mborzecki / zyga / Chipaca: My image uses psplash for a custom splash screen right now, see https://gitlab.com/glancr/gadget-snap-pi-kiosk (adapted from ogra 's examples of course ð )
<dot-tobias> Problems with this: a) The splash is not visible as soon as mir-kiosk is installed and started â black screen b) Changing the image after the initial boot has completed requires a separate psplash binary in /boot-assets/psplash.img (if I understand things correctly), so an initial âdon't touch, doing stuff for a whileâ screen would confuse users on subsequent boots
<dot-tobias> But my knowledge of these things is quite little, so I might just be overlooking simple solutions ð
<Chipaca> dot-tobias: instead of an image, just play https://www.youtube.com/watch?v=V4uV3icrmw0
<Chipaca> simples!
 * Chipaca runs off
<dot-tobias> Chipaca: That's plan B ð
<Chipaca> is it the default for Elementary to use the LimeNET store?
<mborzecki> dot-tobias: hah nice, looked at the gadget initrd part is loaded into the memory right after the actual initrd, nice trick
<dot-tobias> mborzecki: Full credit to ogra for this, his universal pi kiosk gadget snap was a huge inspiration (read: fork and customize) for me ð
<dot-tobias> mborzecki / zyga / mvo: Re: first boot â FWIW, I didn't mention that I use cloud-init in my image atm, e.g. to work around https://bugs.launchpad.net/snapd/+bug/1820060 . Came across it in https://forum.snapcraft.io/t/how-to-preconfigure-custom-image/4154/15 ; maybe this enables an interim solution for others. Couldn't find an approach for my specific issue though ð
<mvo> pstolowski: not sure you saw it, looks like 6755 needs a tweak in the spread test
<pstolowski> mvo yes, thanks, im fighting with it this morning
<mvo> pstolowski: uh, ok. good luck then .) !
<pstolowski> the trick with modyfing snapd.service file is a no-no on read only fs on core ;)
<mvo> pstolowski: yeah, its fine (for now) to exclude core
<mvo> pstolowski: alternatively we could bind mount a modified copy to the place on core
<pstolowski> mvo iâm playing with override.conf
<pstolowski> need to run a quick errand, afk for a while
<mvo> pstolowski: no worries
<mvo> pstolowski: yeah /run/systemd/system/... should also work
<mvo> pstolowski: and much simpler :)
 * mvo really likes this feature of systemd
<mvo> sil2100: I was looking at 1825437 just now - the seed.yaml on the image shortly before the release was wrong and that crashed snapd. do you happen to know what writes the seed.yaml and where I can file a bug? mostly for awareness so that we can add some sort of test to ensure the seed.yaml is correct
<mvo> zyga: re seed.yaml installer issue> the bugreport is a bit unclear, it sounds like this was a bug on an image before the release and the release image is fine. but that sounds suspicious and someone mentioned a race. do we know more? do we have more reports like this?
<mvo> zyga: or pointers to the code that writes the seed.yaml?
<zyga> mvo: some more on the forum
<zyga> mvo: I don't have that, kenvandine looked before and pointed us at foundations/desktop
<mvo> zyga: thanks! all over the place or in a specific thread?
<zyga> mvo: there are two more threads AFAIR
<zyga> mvo: but no more details
<zyga> mvo: people just carry on after removing that extra -
<Chipaca> are people particularly obtuse today, or am I especially grumpy?
<zyga> Chipaca: what's up?
 * zyga has a revalation about another bug
<zyga> I'm sorry, I'm a bit lost today
<Chipaca> zyga: "I tell it to put something in usr/bin, but then the thing is not in bin/"  "did you check usr/bin?"  "it's not in bin/"
<zyga> pstolowski: Repository.RemoveSnap doesn't remove connections!
<zyga> ah, sorry, it's all good :
 * zyga is stumbiling
<sil2100> mvo: hm, curious, wonder what happened there - all the seeding logic is implemented in livecd-rootfs itself
<sil2100> mvo: the seed.yaml is created there when seeding happens, so possibly take a look at live-build/functions and look for the snap_preseed family of functions
<mvo> sil2100: thanks, so nothing dynamic in the installer? thats cool
<sil2100> Curious
<mvo> sil2100: I have a look
<mvo> sil2100: we got reported from media-info 20190413
<mvo> so a bit before the final releease
<mvo> sil2100: ha! thanks, I have interessting pointers now
<sil2100> mvo: not that I'm aware of at least, we get the snap list from the seeds and then work through the list during build time, and I can't remember hearing about that changing
<mvo> sil2100: looking deeper, thank you :)
<mvo> sil2100: no worries, you helped a lot!
<sil2100> mvo: yw! Thanks for looking at this, indeed the wild '-' seems like something really really strange ;p
 * mvo looks at code/diffs now
<mvo> sil2100: there are changes in livecd-rootfs at exactly the relevant times so I bet its that
<mborzecki> another large'ish gadget update PR coming up, though most of it is tests
<Chipaca> degville: docs for the REST API are still the ones in the github wiki, yes?
<degville> Chipaca: yes.
<Chipaca> k
<degville> Chipaca: I need to bring them over, but also I need to get agreement on where they'll be located - partly as issue with the snap docs outline, and also where Core docs go and fit with the REST API docs.
<Chipaca> degville: as soon as you start doing that somebody'll point out that we shouldn't call them "REST API" anything
<Chipaca> degville: :-)
<Chipaca> not that they're _wrong_, just that names are hard
<degville> degville: of course :)
<Chipaca> degville: talking to yourself already? :-p
<degville> Chipaca: degville: uh oh - too long working from home will do that.
 * degville nods
<Chipaca> degville: run away! run away! to the coffee shop or sth :-)
 * Chipaca is immune to that though
<Chipaca> am not!
 * Chipaca is too!
 * degville checks the ring is safely hiddenses.
<mborzecki> https://github.com/snapcore/snapd/pull/6769 if anyone is interested in volume layout
<mborzecki> mvo: could you cherry-pick https://github.com/snapcore/snapd/pull/6715 to 2.39 too?
<mvo> mborzecki: done
<mvo> mborzecki: thank you!
<mborzecki> mvo: thanks!
<zyga>  pstolowski I am close to fixing that attribute issue
<zyga> At least enough to buy more time
<pstolowski> zyga: what did you do? setup-profiles fix?
<zyga> Yes
<zyga> It is not correct but also not more incorrect
<zyga> Equivalent to not catching static attractive
<zyga> With smoother change
<zyga> pstolowski: it's possible to craft actions that will give you different static attrs for the _same_ plug or slot among two connections
<zyga> yah
<zyga> I found more bugs
<zyga> ok
<zyga> let's stash those aside and fix one
<zyga> kenvandine: as an advice, please don't rely on snapd to create directories in $SNAP
<zyga> kenvandine: I found a serious bug in that area now
<jdstrand> mvo: hey, I will be in the standup in ~30 minutes. you don't need 2.38.2 for either issue imo
<jdstrand> erf, I merged from master and now seeing in fedora-29:
<jdstrand> RPM build errors:
<jdstrand>     Bad exit status from /var/tmp/rpm-tmp.VZ4h1y (%build)
 * jdstrand discards and tries again
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6770
<zyga> pstolowski: sorry for taking so long, I found a deeper bug in this and spent time exploring it
<zyga> mborzecki: the mount backend is hosed,
<zyga> mborzecki: I bet the solution is proper topological sort of mount entries
<zyga> mborzecki: it sucks to have this mid-refactor too
<mborzecki> zyga: heh, at least we know that now :)
<zyga> mborzecki: I have a way to reproduce this
<zyga> mborzecki: I'm 100% sure this is the ghost bug people were mentioning all the time
<zyga> mborzecki: but were unable to reproduce (which makes sense too btw)
<zyga> mborzecki: if I get hit by a bus today: writable mimic on $SNAP misbehaves
<zyga> mborzecki: refreshing a snap over itself (same snap reinstalled) shows abnormal outcome
<zyga> mborzecki: I will explore some more, I don't have all the answers yet
<zyga> mborzecki: but I'm happy to at least take a stab at that elusive bug
<pstolowski> zyga: ty!
<zyga> pstolowski: no unit tests, help appreciated
<jdstrand> zyga: s/if I get hit by a bus/if I win the lottery/ :)
<jdstrand> zyga: if you are going away, I'd much rather it be cause you have tons of $$
<jdstrand> s/\$\$/money/
<jdstrand> no need for you to be paid in USD
<Chipaca> jdstrand: Â¤Â¤
<pstolowski> zyga: thank you for that workaround, looks good, i'll help with unit tests after standuo
<kenvandine> zyga: i guess the gnome extension to snapcraft could create those directories
<Chipaca> ~$ snap install snap-with-complex-requirements
<Chipaca> error: https://i.imgur.com/z96dZ0x.jpg
<kenvandine> zyga: i'd rather not expect app developers to know to create all those dirs
<zyga> kenvandine: agreed
<zyga> kenvandine: I'll let you know more once I have the data
<zyga> Chipaca: are those files that we create from snapd? https://bugs.launchpad.net/command-not-found/+bug/1824000/comments/2
<Chipaca> zyga: yes
<zyga> looks like our bug then
<Chipaca> zyga: did 19.04 change ulimit?
<Chipaca> or sth?
<zyga> dunno
<zyga> maybe :)
<zyga> umask I presume
<Chipaca> yeah
<Chipaca> that one
<Chipaca> zyga: but the .metadata might imply that an update crashed? maybe
<Chipaca> not sure
<zyga> dunno
<Chipaca> hmmmm
<Chipaca> zyga: actually wait it might not be ours
<Chipaca> zyga: ours are under snapd
<Chipaca> zyga: /var/cache/snapd/commands.db  is ours
<Chipaca> zyga: soryr
<kenvandine> zyga: we've had some issues with content interfaces that have been really hard to reproduce
<kenvandine> maybe fixing these things you're finding will fix those :)
<zyga> kenvandine: I think what I found will fix that
<zyga> kenvandine: not 2.29 material, something that will take some time to do
<kenvandine> like how sometimes the mount is empty
<zyga> kenvandine: but I will get it done
<kenvandine> after a refresh
<zyga> yes, I reproduced that too
<kenvandine> we've never figured that out
<kenvandine> great
<cachio> zyga, hey, I see this error sometimes running the failover test
<cachio> zyga, https://paste.ubuntu.com/p/2CqKNTfz47/
<cachio> this is on a pi3
<cachio> then the device doesn't boot anymore
<cachio> it is stuck
<zyga> cachio: I don't know anything about that, perhaps the kernel has crashed, if you see that again try pinging the kernel, it's a simple way to check if the system has failed entirely
<cachio> zyga, ok
<cachio> thanks
<om26er> roadmr Hi! Do you think https://forum.snapcraft.io/t/please-allow-auto-connect-of-display-control-interface-for-deskconn/10831/ is good to go live now ?
<roadmr> om26er: I think so but usually jdstrand is the one who wrangles auto-connects
<om26er> roadmr ah, ok.
<jdstrand> I'm a bit behind but hope to run through everything today
<Chipaca> cachio: do you remember which pr it was that fixed the core18 remove thing?
<Chipaca> ah, #6753
<pstolowski> zyga: i've unit tests for your fix, how would you like it proposed?
<fryfrog> Hi, I'm a support person for a project and someone has made a snap package I'm trying to understand. Specifically, they're recommending files be owned by root because it runs as root inside.
<fryfrog> https://github.com/albertodonato/sonarr-snap
<cachio> Chipaca, correct
<Chipaca> fryfrog: daemons that come in snaps run as uid 0 for now, yes
<fryfrog> :o
<pstolowski> zyga: pushed here https://github.com/stolowski/snapd/tree/lp-1825883-unittests ; please take a look and feel free to incorporate into your PR
<fryfrog> Chipaca: how does one deal w/ that *outside* the snap?
<Chipaca> fryfrog: I'm not sure what you need to deal with
<Chipaca> (i don't know your snap at all)
<Chipaca> s/snap/project/
<fryfrog> Any files it needs to read/write, would either need to be owned by root, root would need to be in the group or ... i guess at least permissions don't matter :)
<Chipaca> fryfrog: it'll create them as root, but it'll be able to read them anyway yes
<fryfrog> There is no way to specify the UID a daemon runs as?
<Chipaca> fryfrog: no (seccomp arg filtering is only just becoming usable _now_ -- we're working on it!)
<fryfrog> I'm glad to hear it is in the pipeline :)
<fryfrog> Thanks for helping me understand :)
<Chipaca> fryfrog: there's also the issue of no user other than root being 'universal' across distros, but we're tackling that as well
<Chipaca> (initial use of the arg filtering thing will be via enabling a 'daemon' user, which most distros have and those that don't will get a warning on install)
<fryfrog> Docker "fixes" this by not actually caring about the user *name*, they just allow passing in a UID/GID
<Chipaca> yeah
<Chipaca> but then your innocent pvr ends up running as the same uid as postgres or sth
<Chipaca> anyway, yes, there's a bunch of silly gotchas we need to care about
<Chipaca> it's all planned out afaik (there's a forum topic layout out the steps and stages of it)
<Chipaca> laying out*
<fryfrog> Cool :)
<zyga> pstolowski: thank you!
<pstolowski> woot, #6755 is green
<cachio> Chipaca, when you have time could you please take a look to this one? #6694
<Chipaca> cachio: LGTM
<Chipaca> cachio: as I said there, some day sergiusens and I will be able to spec out (and implement/use) 'snap download --plz-put-the-snap-here=<blah>', but until then, what you've done is best
<cachio> Chipaca, nice, thanks for the review
<cachio> zyga, please could do take a look to #6694
<cachio> it is almost ready and I need that to validate 2.39
#snappy 2019-04-25
<tasker> I'm having issues getting "core" to install because the snap daemon is looking explicitly for "mount.squashfs" and "umount.squashfs". what package provides those? and, perhaps a better question, why can't the code simply look for "mount"?
<tasker> I should explain that I can't install "core" because those two utilities don't exist on my system.
<mborzecki> morning
<zyga> Good morning
<mvo> zyga: hey, good morning
<zyga> Hey :-)
<zyga> Just drinking coffee
<zyga> A bit sleepy still
<mborzecki> mvo: zyga: hey
<mvo> hey mborzecki !
<pstolowski> morning o/
<mvo> hey pstolowski !
<mvo> pstolowski: does 6669 or 6712 need further samuele input? I saw he commented on both but it looks like you addressed all his input. would like to see if we can move forward here
<pstolowski> mvo: no, i think we could move forward with them, i don't think there is anything controversial there; i can tweak in a followup if Samuele finds anything after it lands
<mvo> pstolowski: cool, thanks
<zyga> in the office, finally
<pstolowski> mvo: btw not sure if you saw my comment to https://github.com/snapcore/snapd/pull/6755
<pstolowski> mvo: one of the dns-related messages that we use in retry code ("Temporary...") seems to be coming from glib (I grepped glib sources) and i think it can be translated :(
<mvo> pstolowski: uhoh
<mvo> pstolowski: I have not seen it :/ thats annoying for sure
<pstolowski> mvo: perhaps we should simply catch *net.DNSError and don't try to be too smart wrt error message
<mborzecki> pstolowski: glibc right?
<pstolowski> mborzecki: right
<mborzecki> pstolowski: actually an interesting problem, whether the error message by the time it's accessible in Go, is translated according to locale :/ that would be most unfortunate
<pstolowski> mborzecki: i haven't actually verified that. just found the error in the code, and then in all po/*po files of glibc. don't know how the error is propagated to go
<pstolowski> mborzecki: i'll actually cook something to check that under PL locale
<brlin> 430.09 NVIDIA graphics driver seems to broke OpenGL support: https://forum.snapcraft.io/t/call-for-testing-obs-studio-snap/4298/39
<zyga> brlin: ack
<brlin> zyga: Tks!
<zyga> brlin: we have poor support for nvidia and have roadmap item to improve that but it will likely slip a little
<brlin> (not really care much as I use intel graphics)
<pstolowski> mvo, mborzecki : ok, false alarm with translated error msg, i think we're good. under pl locale i'm getting:
<pstolowski> $ ping www.sadaa.pl
<pstolowski> ping: www.sadaa.pl: Odwzorowanie nazwy jest chwilowo niemoÅ¼liwe
<pstolowski> but with go test:
<pstolowski> panic: Get https://asjhdaksdjhka.org/get: dial tcp: lookup asjhdaksdjhka.org: Temporary failure in name resolution
<pstolowski> it seems only the standard cli utils get the translated messages
<mborzecki> zyga: added some notes under https://github.com/snapcore/snapd/pull/6759 looks like something fishy with go toolchain, and not 1.10 specific
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6759#issuecomment-484931067
<zyga> mborzecki: if you remove the need for C, go build defaults change
<zyga> mborzecki: I observed this when working on BuildID originaly
<zyga> *originally
<mborzecki> zyga: hm the resulting test binary is still dynamically linked and gcc is involved in the build process, so it's not exatly the same as CGO_ENABLED=0
<zyga> what was that pixel font...
<Chipaca> zyga: pixel font?
<zyga> yeah
<zyga> whenever I work on low-dpi screen I use that font
<zyga> anyway
<zyga> I found something good enough for now
<Chipaca> zyga: neep alt?
<Chipaca> in xfonts-jmk
<zyga> offtopic: it would be good to be able to ship fonts in snaps
<zyga> and have them work on the host
<zyga> I would really like that
<pstolowski> zyga: can we land https://github.com/snapcore/snapd/pull/6777 or do we need to verify CLA?
<zyga> pstolowski: 1) typos are not significant contribution that is protected by copyright and 2) we have automatic CLA verification in travis
<pstolowski> zyga: ah ok
<Chipaca> zyga: pstolowski: the travis CLA verification does have a "don't know" result which does not block
<Chipaca> so you shold look at the output if you're unsure about a contributor
<zyga> I didn't know that
<zyga> but anyway, in this case this is clearly not copyrightable because it is not a creative work
<Chipaca> in this case, it's not brlin's first contribution :-)
<brlin> I thought I already signed the CLA...?
 * brlin Checking it out so it won't be a problem
<Chipaca> brlin: yeah, your first one wouldn't've gone in if not
<pstolowski> would be great to land https://github.com/snapcore/snapd/pull/6717
<pstolowski> needs 2nd review though
<zyga> pstolowski: I'm reworking your test
<zyga> pstolowski: I will push there in 10 mintues
<zyga> ahh
<zyga> wrong branch
<zyga> yes
<zyga> please review and let's land that
<zyga> mvo: will you be handling cherry-picking for 2.39?
 * zyga is puzzled
<mborzecki> need to drop the kids at school for some extra classes, back in ~30
<Chipaca> "extra classes" is parent-speak for "torture"
<zyga> lol
<pstolowski> mvo: https://github.com/snapcore/snapd/pull/6733 can land?
<mvo> pstolowski: looking
<mvo> zyga: sorry for the delay, had a meeting - yeah, I take care of 2.39 cherry picks in general, anything I should cherry-pick?
<zyga> thank you
<zyga> mvo: I'm not done yet, ideally tomorrow morning
<mvo> pstolowski: yes, thank you!
<mvo> pstolowski: that was just waiting for the second review :)
<mvo> zyga: cool! thanks
<pstolowski> btw https://github.com/snapcore/snapd/pull/6712 needs second review (hint! hint! ;))
<mvo> pstolowski: :) yes, its on my list but not super high (yet) unfortunately
<mborzecki> re
<mborzecki> Chipaca: that would 'piano classes' or somesuch
<Chipaca> mborzecki: 'culture appreciation classes'
<mborzecki> hahaha
<zyga> pstolowski: I found that the stale fix is insufficient
<zyga> pstolowski: working on a bit of more code to do it
<zyga> pstolowski: I expanded your unit test and found the issue
<pstolowski> zyga: oh interesting
<zyga> pstolowski: I was unsure about the unit test so I started tweaking it towards "more obvious"
<zyga> pstolowski: essentially more than one thing calls backend.Setup
<pstolowski> uhm
<pstolowski> cachio: hey, can https://github.com/snapcore/snapd/pull/6710 be updated for 19.04 now?
<cachio> pstolowski, checking
<cachio> pstolowski, still I need to fix the test snap-handle-link
<cachio> which fails on 19.04
<pstolowski> cachio: ack, thanks
<zyga> Chipaca: https://explainshell.com
 * Chipaca pastes etelpmoc.sh in
 * Chipaca is thwarted by 414 Request-URI Too Large
 * Chipaca lunches
<mborzecki> zyga: https://explainshell.com/explain?cmd=false+%7C%7C+%3A
<cachio> zyga, hey, if you take a quick look to this one #6694 would be really nice
<mborzecki> that site is not too helpful
<mborzecki> zyga: mvo: are you on 19.04? can you check if that appears? https://forum.snapcraft.io/t/selinux-warning-when-running-lxc/11100
<zyga> mborzecki: I'm on 19.04
<mborzecki> zyga: do you see this warning?
<zyga> mborzecki: let me check, don't know
<zyga> or can I queue this
<zyga> my mind is set for attribute work now
<mborzecki> zyga: sure
<mvo> mborzecki: I'm on 19.04, I can check after lunch
<mborzecki> mvo: thanks
<mborzecki> off to pick up the kids, back in 30
<cachio> mborzecki, hey
<cachio> I am researching the issue related to the xdg-open on 19.04
<cachio> mborzecki, I found that it works well https://paste.ubuntu.com/p/jq2ZnkXPtB/
<cachio> when we don't install the package evolution-data-server
<cachio> mborzecki, otherwise it fails
<cachio> like this https://paste.ubuntu.com/p/bqGhTbhSbj/
<cachio> mborzecki, any idea why it could be happening?
<mborzecki> re
<mborzecki> cachio: will take a look
<cachio> mborzecki, thanks
<cachio> I have debug session open
<cachio> if you want to use it
<cachio> for both scenarios
<jdstrand> mvo: remind me. say I want to create a test snap and have it in the store, I know that I put its source in tests/lib/snaps, but after I snapcraft register and upload, who should I add as a collaborator?
<jdstrand> it seems like mvo and Chipaca
<jdstrand> that's cool
<Chipaca> jdstrand: cachio also maybe?
<Chipaca> jdstrand: i'm not collab on all of 'em fwiw
<Chipaca> nobody invites me to the fun parties any more :-p
<jdstrand> hehe
<cachio> jdstrand, yes please
<jdstrand> I looked at hello-world and classic :)
<cachio> add me too
<jdstrand> cachio: sure, np
<cachio> jdstrand, thanks
<mvo> mborzecki: I did not get this warning when just running lxc
<mborzecki> mvo: interesting, thanks
<mborzecki> cachio: can you check whether installing evolution-data-server somehow pulls in gnome-software? if not, then whether gnome-software is installed before the test actually executes
<cachio> mborzecki, https://paste.ubuntu.com/p/Pjm2gr6FpN/
<cachio> just suggested
<cachio> but a lot of gnome-* stuff
<cachio> Chipaca, when you have time, could yo uplease take a look to https://github.com/snapcore/spread/pull/70 ?
<zyga> F**************L
<mvo> zyga: ?
<roadmr> falayaralfalil?
<zyga> mvo: just realized the test shows the bug is deeper than I thought on refresh :)
<zyga> mvo: the unit tests I added were good enough to show it would still be broken in one case
<Chipaca> roadmr: frontosphenoidal
<mborzecki> cachio: mhm, so maybe we need to run some mime update thingy
<jdstrand> cachio: hey, so I have the ability to create amd64, i386, arm64 and armhf snaps, so I am doing that for the new test-snapd-setpriority snap. I was thinking that I wouldn't worry about ppc64el or s390x unless you felt otherwise. if you do feel otherwise, what is the recommended way to provide those?
<tasker> I'm having issues getting "core" to install because the snap daemon is looking explicitly for "mount.squashfs" and "umount.squashfs" both of which I don't have on my system. what package provides those? and, perhaps a better question, why can't the code simply look for "mount"?
<cachio> jdstrand, I usually create those on launchap
<xnox> jdstrand, launchpad can build snaps for all architectures, include ppc64el & s390x. Or are you building without launchpad?
<cachio> jdstrand, on this project https://code.launchpad.net/~snappy-dev/snappy-hub/
<Chipaca> tasker: mount always looks for mount.<filesystem> afaik
<xnox> jdstrand, and they are not special arches at all, anybody can enabled them on anything.
<cachio> jdstrand, we store all the snapd to build
<Chipaca> tasker: bah, dunno
<Chipaca> tasker: I don't have a mount.squashfs here and things work
<Chipaca> tasker: maybe it's trying that because your kernel doesn't support squashfs?
<tasker> Chipaca: it does.
<jdstrand> cachio: I looked there and did not see other test snaps
<Chipaca> tasker: can you pastebin the output of 'snap version'?
<cachio> jdstrand, most of the tests snaps are there
<jdstrand> xnox: right, I realize that and do it all the time. this is a spread test snap and I didn't see/know where LP builds of test snaps are is all
<cachio> jdstrand, for example lp:~snappy-dev/snappy-hub/test-snapd-profiler
 * jdstrand looks again
<xnox> ah
<xnox> ok
<jdstrand> cachio: I might've benn looking in git
<jdstrand> been*
<jdstrand> heh, I typoed as 'snappy-hug'
<cachio> hehehe
<jdstrand> cachio: yeah, I looked at git. ok, I'll do the bzr dance and go from there. thanks
<cachio> jdstrand, np
<cachio> jdstrand, yaw
<tasker> Chipaca: http://dpaste.com/1EQZGDW
<Chipaca> tasker: what do you get in 'dmesg' when the snap fails to mount?
<tasker> nothing
<Chipaca> tasker: what error do you get from snapd when you try to install?
<tasker> I'm going back through the strace again. maybe the mount utilities aren't the problem.
<tasker> Chipaca: http://dpaste.com/07T5MHT
<cmatsuoka> mup_: you're so quiet, are you alive?
<Chipaca> tasker: that's strange, but ok, let's back up a bit
<Chipaca> tasker: try this: snap download core (more to follow when that's done)
<tasker> Chipaca: done.
<Chipaca> tasker: now try to mount the .snap file, e.g. sudo mount core_6673.snap /mnt
<mborzecki> tasker: also try 'grep squashfs /proc/filesystems'
<tasker> yes. I can mount squashfs.
<Chipaca> tasker: that 'mount' worked, then?
<tasker> yes, thank you.
<Chipaca> tasker: ok, can you pastebin the output of 'snap tasks --last=install' please?
<Chipaca> tasker: (feel free to umount that snap)
 * Chipaca very puzzled at this point
<tasker> Chipaca: http://dpaste.com/3AMJJ9D
<mborzecki> tasker: can you post `journalctl --since 8:44`?
<Chipaca> --system, also
<mborzecki> tasker: right, journalctl --system --sice 8:44
<tasker> I cannot. don't have journalctl.
<Chipaca> tasker: what
<tasker> and if you follow up with "snap won't work without systemd", I'm done with this experiment.
<Chipaca> tasker: snap does not work without systemd
<tasker> . )
<tasker> okie doke!
<tasker> thanks a bunch.
<Chipaca> tasker: we delegate a lot of stuff to systemd Â¯\_(ã)_/Â¯ including the mounting of stuff
<Chipaca> we're open to people writing different backends for other init systems, but so far nobody has offered
<tasker> I'm not mad. saddened, perhaps, but not mad.
<tasker> good luck!
<tasker> thanks again for your help.
<Chipaca> why would you be mad?
<zyga> mvo, pstolowski: I'll grab coffee and lunch
<zyga> I'll share what I have after that
<roadmr> zyga shares his coffee and lunch? :)
<zyga> changes have some impact so not great
 * zyga is happy to share that too :)
<roadmr> :D
<pstolowski> :)
<mborzecki> guys, i'm out of ideas, what could we do about a setup like this: https://forum.snapcraft.io/t/selinux-warning-when-running-lxc/11100/
<mborzecki> it's a mix of custom mainline kernel, which somehow got selinux enabled, plus selinuxfs is somehow mounted during boot
<mborzecki> but userspace tools are missing (as in https://github.com/PowerShell/PowerShell/issues/9252 ) or the userland is totally unprepared for selinux (i.e. missing policy and so on)
<mborzecki> i suspect this will break with 2.39
<mborzecki> Chipaca: wow, that kerlen that you linked, i looked at the config patches, +CONFIG_DEFAULT_SECURITY="selinux" +CONFIG_DEFAULT_SECURITY_SELINUX=y in debian.master/config/config.common.ubuntu
<Chipaca> mborzecki: detect a selinux with no policies as part of 'not supported'?
<Chipaca> mborzecki: ouch
<Chipaca> mborzecki: maybe ask kernel people about this then
<Chipaca> maybe we're dropping apparmor for 5.0 :-p
 * Chipaca hides
<mborzecki> i seriously wonder how did the system even boot properly
<Chipaca> Zombie processes detected, machine is haunted.
<Chipaca> ^ bofh knows all
<mborzecki> psdoom window pops up
<Chipaca> man why are we not packaging psdoom
<zyga> back from coffee
<zyga> sorry, sleepy since I slept so little last night
<Chipaca> apology accepted
<zyga> https://memegenerator.net/img/instances/64599905/apology-accepted.jpg
<zyga> like this? :D
<mborzecki> Chipaca: as far as selinux enabled detection is concerned: https://github.com/SELinuxProject/selinux/blob/master/libselinux/src/enabled.c#L11-L21
<jdstrand> mvo: thinking through how to require that golang-seccomp is patched, since daemon user will have terribly incorrect bpf otherwise
<jdstrand> mvo: I'm having trouble. golang-seccomp doesn't declare anything that we can use in system-key (eg, a version or something)
<jdstrand> mvo: we could try to generate a tiny bpf and they see if it is correct, but that is kinda yucky
<jdstrand> mvo: I do know that golang-seccomp is adding a new func called GetApi() for the new libseccomp call. that was added after the patch to AND
<zyga> pstolowski: I'm running spread after adjusting unit tests
<jdstrand> mvo: so, in theory, we could reference that somewhere in the code and then snapd would fail to build. this would force people to update (we would fetch/merge into the vendored code)
<zyga> jdstrand: can we vendor golang-seccomp in snapd to the extent that we only depend on libseccomp and have a slimmed-down version of golang-seccomp for just the functions that we use?
<zyga> pstolowski: I'd like to proceed as follows
<zyga> pstolowski: I have some changes to unit tests in ifacestate
<zyga> pstolowski: those should hopefully not depend on the fixes that are coming after them
<jdstrand> zyga: we already vendor it. the problem is fedora and debian strip it out and use the system golang-seccomp. if we vendored everything, there is no problem
<zyga> pstolowski: the motivation is simple: lots of tests use a common consumer/producer yaml that has lots of quirky attributes and hooks
<zyga> jdstrand: not vendor in that sense
<jdstrand> zyga: debian and fedora should be fixed soon, but I'm worried about other systems
<zyga> jdstrand: make it a part of snapd tree
<zyga> jdstrand: strip rest of the code
<zyga> jdstrand: drop the vendored dep
<jdstrand> oh
<jdstrand> hrm
<jdstrand> you mean an embedded code copy
<zyga> jdstrand: yes, but much reduced
<jdstrand> zyga: it wouldn't be 'much reduced'. it is already small and we are using most of the api
<zyga> jdstrand: well, perhaps there would be still something to shed
<zyga> I like the fact that it removes one moving part
<zyga> and changes it to something we can instantly correct as we need to
<jdstrand> zyga: a) I wouldn't necessarily want to just chop up golang-seccomp. I think it is fine to import wholesale and sit on it, which is what we are effectively doing now for most systems
<jdstrand> zyga: b) but for the ones we don't do it on (eg, fedora and debian), they aren't going to be too keen on the embedded code copy since it is just circumventing their policy
<Chipaca> jdstrand: AFAICT using GetApi would also force using 2.4.0
<Chipaca> 2.4.0+ i mean
<zyga> hence the simplification, I really mean a one-way copy and integration
<jdstrand> Chipaca: yes
<Chipaca> which is probably fine, but i thought we wanted to support but downgrade <2.4.0?
<jdstrand> zyga: I know what you are saying. I'm saying I know distros and the whole reasons they balk at vendoring the way we do now are still there with an embedded code copy
<zyga> mhm
<zyga> but at some point it does become a gray area
<jdstrand> Chipaca: there are a spectrum of options. one is failing the build. one is trying to detect at runtime and degrading. I wanted to see if GetApi() was available for use at runtime, but it doesn't seem go supports that. reflect doesn't help cause it isn't an obj. it is a package function. If I could be proven wrong, I would go that route
<jdstrand> zyga: for the distros that are enforcing not vendoring, there is no gray
<jdstrand> zyga: again, if we embedded, I would strongly advocate *not* changing the imported code
<jdstrand> we use like 90% of the api. maybe more
<zyga> mmm
<zyga> well
<zyga> or we can rewrite it :)
<zyga> I would love to over summer holidays
<jdstrand> please stop suggesting that :)
<Chipaca> haha, like zyga takes holidays
<jdstrand> it has taken years for people to get it to the point that it is working now
<zyga> haha, yes,
<zyga> jdstrand: well, I honestly think it's not something that is hard to do :-)
<jdstrand> I know you don't ;)
<zyga> also we'd need a subset of real functionality and we'd have flexibility of doing more things
<jdstrand> but if you look at the seccomp library, it is hairy, tricky code
<zyga> I still think the API is quirky, the results are (now) good but were not good before
<zyga> and I think way more can be done
<zyga> I did read libseccomp before, I didn't check the rewrite but I was honestly surprised by how complex that was, not for a good reason
<zyga> the only valuable parts of libseccomp are: linux doesn't expose syscall numbers to userspace so libseccomp has to carry those, libseccomp has fallback code for multiplexers and deprecated syscalls (but even those are surprising IMO)
<zyga> but that's an orthogonal discussion
<jdstrand> I can't express strongly enough that rewriting a complex library that deals with various arch quirks and kernels that has wide industry adoption is a bad idea
<zyga> jdstrand: and is written in C
<jdstrand> this doesn't help my daemon user PR
<zyga> jdstrand: that same library was fundamentally broken for years <- this wasn't sent somehow
<zyga> yes, I agree
<zyga> I'm just casually exploring the topic
<zyga> I don't argue towards doing this for the daemon work
<zyga> but doing this could remove *all of* snap-seccomp
<jdstrand> Chipaca: do you know of a way to detect if a package implements a function at runtime?
<zyga> and make it all a part of snapd
<jdstrand> I don't know how else I can express 'bad idea' :)
<Chipaca> jdstrand: I looked into it a bit, and no, sadly, not at the package level without doing horrible things
<Chipaca> jdstrand: if there were a method on a struct that we could look for, that, yes
<zyga> jdstrand: dlopen?
<jdstrand> Chipaca: yeah, I spent too much time on it this morning already
<jdstrand> zyga: dlopen what?
<zyga> jdstrand: dlopen the so file, look up the symbol,
<zyga> <jdstrand> Chipaca: do you know of a way to detect if a package implements a function at runtime?
<jdstrand> zyga: there isn't an so. I'm talking about golang-seccomp
<zyga> I see
<zyga> in go that's impossible AFAIK
<zyga> well, there's reflect but I don't see the value
<zyga> it's a compile time thing
<jdstrand> zyga: there are libseccomp bugs. I can and have worked around that because I dan downgrade if GetLibraryVersion is < 2.4
<jdstrand> zyga: but the golang-seccomp bug... there isn't version info in the package and I can't seem to do a cheap check at runtime
<zyga> jdstrand: make that a runtime choice?
<zyga> aha
<zyga> well
<Chipaca> oooh, ooh
 * zyga waits for Chipaca's idea
<Chipaca> jdstrand: so you could do this
<pstolowski> zyga: sounds good, yeah, all those consumer/producer yamls there grew organically and out of control
<zyga> pstolowski: +1 preparing a patch now
<zyga> sorry, got distracted by family discussion that for some reason moved into the office
<pstolowski> :)
<jdstrand> zyga: also, if you see above, reflect doesn't work cause it is a func in a package, not a func on an object with a method
 * jdstrand is curious about Chipaca's idea
<Chipaca> sorry, putting it into code
<zyga> jdstrand: indeed
<Chipaca> jdstrand: seccomp.ScmpAction(6).String()
<Chipaca> jdstrand: the commit that changes the result of that, is the same that adds GetApi
<mvo> jdstrand: was in a meeting will read backlog
<Chipaca> or the one just before it?
<Chipaca> jdstrand: but I think that gets us there
<Chipaca> oh no, drat
<Chipaca> Date:   Thu Sep 21 03:14:51 2017 +0000
<Chipaca> i read that wrong :-(
<Chipaca> bah, dunno
<Chipaca> these are all old commits
 * zyga recommends just rewriting it all in Go
 * Chipaca whaps zyga over the head
<Chipaca> jdstrand: the commit that adds GetApi is from
<Chipaca> Date:   Wed Oct 25 05:44:14 2017 +0000
<Chipaca> is the one in distros really older than this?
<jdstrand> Chipaca: ah, hmm. let me look
<Chipaca> jdstrand: if it is, then checking that String would work (it's not the same commit but it's probably good enough)
<jdstrand> well you know, I could also just look for the actlog stuff
<Chipaca> jdstrand: that's what that String does
<jdstrand> Apr 19 2017 is the magic day
<Chipaca> it's either ActLog or Unrecognised
<jdstrand> Chipaca: ah right. we even do that in snap-seccomp. billiant :)
<Chipaca> hah
<jdstrand> I can work with that. thanks :)
<jdstrand> Chipaca: I don't know why I got focused on the other stuff. thanks for listening and setting me straight :)
<Chipaca> jdstrand: it even mentions GetApi in snap-seccomp :-) now that i know what to look for
<jdstrand> mvo: Chipaca set me straight. we are all good
 * Chipaca would gladly have set jdstrand queer, but thinks this is what they wanted
<jdstrand> hehe
 * cachio lunch
<mvo> jdstrand: cool
 * mvo hugs jdstrand and Chipaca 
<Chipaca> :-)
<alan_g> jdstrand, any thoughts on the best name for this? https://forum.snapcraft.io/t/negotiating-a-vt-session-with-logind-needs-a-new-interface/10969
<alan_g> greyback and I have kicked around variants of "session" "login-session" & "logind-session"
<zyga> pstolowski|afk: https://github.com/snapcore/snapd/pull/6779/files
<zyga> aw, he's gone :|
 * mvo grumbles about build failures of the snapd snap
<jdstrand> alan_g: I suggest starting with 'login-session-control' and we can iterate in the PR
<alan_g> jdstrand, WFM
<zyga> mvo: I'll EOD now given that my branch is blocked by 6779
<zyga> mvo: the essential fix is in https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c
<zyga> it's stacked on top of that
<zyga> I spawned a swarm of test machines to see if it breaks anything
<zyga> and I will go out for a bike ride now
<zyga> mvo: let's try to attempt to fix the stale tools bug tomorrow
<mvo> zyga: thank you!
 * jdstrand hrms
<jdstrand> sandbox/seccomp/compiler.go:27:2: build constraints exclude all Go files in /Users/travis/gopath/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang
<jdstrand> this is with the brew build
<jdstrand> halp
<jdstrand> zyga: did you do anything with brew? ^
<jdstrand> zyga: (in the past that is; I need to adjust sandbox/seccomp/compiler.go I guess
<Chipaca> jdstrand: that's the osx build
<Chipaca> jdstrand: why is the osx build pulling in seccomp :-)
 * Chipaca looks at the diff
<jdstrand> apparently my PR did that
<jdstrand> https://github.com/snapcore/snapd/pull/6780
<jdstrand> I need to use golang-seccomp to check for ActLog in check_snap.go
<Chipaca> jdstrand: so, move GoSeccompCanActLog out to a compiler_linux.go file
<Chipaca> that should do the trick? probably
<Chipaca> jdstrand: you can test locally by doing GOOS=darwin go build ./cmd/snap
<jdstrand> ok
<jdstrand> Chipaca: should I create a compiler_???.go with GoSeccompCanActLog?
<jdstrand> if so, what is ??? ?
<Chipaca> jdstrand: compiler_linux.go, as i said?
<Chipaca> or am i missing something
<jdstrand> Chipaca: yes, but then osx will not have GoSeccompCanActLog()
<Chipaca> jdstrand: and what uses that?
<jdstrand> check_snap.go
 * cachio afk
<jdstrand> Chipaca: sorry. this pr is to support a check in the daemon user pr
<jdstrand> Chipaca: for this pr, sure, compiler_linux.go
<Chipaca> jdstrand: osx only builds cmd/snap, nothing else, if that helps?
 * Chipaca tries to understand but is a little tired
<jdstrand> Chipaca: but in the daemon user pr, check_snap.go from overlord/snapstate is going to call that
<Chipaca> jdstrand: ah, but cmd/snap doesn't use that
<Chipaca> jdstrand: overlord isn't built for osx
<jdstrand> Chipaca: I see
<Chipaca> so you won't need a compiler_other.go
<jdstrand> I was thinking that it would be in there since it is happening during snap install
<jdstrand> gotcha. thanks again! :)
<Chipaca> jdstrand: anything that tries to talk to snapd errors out, on osx
<jdstrand> ack
<jdstrand> Chipaca: that fixed it right up. thanks again :)
<zyga> jdstrand: I did something with brew long time ago but not recently
<Chipaca> zyga: all fixed now
<zyga> Chipaca: cool, thank you!
<Chipaca> well, allegedly
 * zyga just returned from a walk
<Chipaca> :-)
<zyga> now tempted to go on a bike ride
<zyga> to close the "rings" :)
<zyga> I'd love to land https://github.com/snapcore/snapd/pull/6779
<zyga> if anyone wants to look at boring changes
<zyga> but not today, today is rest day
<Chipaca> i'm off to the shops
<Chipaca> gonna get me some curry or sth
<zyga> thank you Chipaca !
<Chipaca> o/
<zyga> mvo: if you want to help, please land ^
<mvo> zyga: oh, interessting? what is the background there?
<zyga> mvo: it's spelled out in the PR :)
<zyga> but the extra description is as follows
<zyga> lots of tests just use "consumerYaml" and "producerYaml"
<zyga> and happily add extra crap to the definitions
<zyga> so now they are a monster with all kinds of apps hooks plugs and stuff
<zyga> and crazy hard to follow tests result from that
<zyga> as I worked on https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c
<zyga> I realized it would impact tests less if I change some of the existing tests
<zyga> to use a smaller version of consumer/producer yaml
<zyga> which has ... well, just what the test needs
<zyga> so there's less noise in changes
<zyga> as you can see in the patch I linked to, it changes two existing unit tests
<zyga> but only those tests because only those tests meaningfully interact with what is changed
<zyga> without the yaml patches from that PR it would also affect a random collection of tests that just happen to have random properties added to consumer/producer yaml that is shared and grew organically over time
<jdstrand> zyga: I thought I remembered you did which is why I asked; figured you'd at least point me to the right person, but, Chipaca to the rescue :)
<zyga> jdstrand: yeah, I was the ssh-to-macos-du-jour ;)
<zyga> jdstrand: I wondered if this is a CVE
<zyga> https://github.com/zyga/snapd/commit/e1bddc9d74fe5c08c7dd2c23f1312a6e31b1b25c
<zyga> jdstrand: if you have a browser with sandbox and then refresh but stay on the stale attribute forever
<zyga> or something along the same vein
<zyga> anyway, I need to make tea
<zyga> I'll check back later
<zyga> jdstrand: it's enough to read the commit message to get an idea about the impact
<jdstrand> zyga: it's definitely a bug worth fixing (thanks!). in the grand scheme of things, I don't consider it a cve. In isolation, arguably so, but considering the store and snap declarations, probably not since the publisher was granted use of the attribute and can remove and add at will.
<jdstrand> zyga: it would affect a snap declaration that revoked, but that isn't terribly different from the old bug where a user disconnected and then on refresh the interface was connected again
<zyga> +1
<jdstrand> zyga: I say just fix it and be done with it. if someone argues for it to be one, we can reconsider
<jdstrand> zyga: you probably noticed we finally have CVEs for those 2 snap-confine issues. I think I cc'd you on the email to oss-sec
<jdstrand> zyga: just fyi
<zyga> I noticed, thank you!
<zyga> Yes, I started following the ML
<jdstrand> zyga: in other news, making the world a better place: https://github.com/seccomp/libseccomp-golang/issues/32
<zyga> jdstrand: oh indeed, thank you
<zyga> And Iâm sorry about my desire to rewrite all external deps as a part of snapd :-)
<jdstrand> hehe
<zyga> Apparmor parser is in that list as well
<zyga> Ultimate way to both understand something and control it
<jdstrand> I know it is
<jdstrand> :)
<jdstrand> erf
<jdstrand> sandbox/seccomp/compiler_linux.go:22:2: build constraints exclude all Go files in /home/ubuntu/gocode/src/github.com/snapcore/snapd/vendor/github.com/mvo5/libseccomp-golang
<jdstrand> I keep hitting this no cgo thing
 * jdstrand make it a snap-seccomp command and calls out to it
<jdstrand> makes*
<zyga> jdstrand: do you want a shell on my iMac pro?
<jdstrand> zyga: compiler_linux.go fixed brew. now I'm hitting this with CGO_ENABLED=0
<jdstrand> so the approach is not viable
 * jdstrand sighs
 * zyga hugs jdstrand
 * zyga merged and opened a new PR from his phone
<roadmr> but can it make phone calls? ;-|
<zyga> roadmr: who knows, is that a feature? :-)
<roadmr> well it enables me to not have a landline, so I'd call it a feature :D
<roadmr> interestingly, the cell phone company does NOT allow you to put one of their numbers as your primary contact number - they still assume you have a landline or other bootstrappy phone. My primary contact number with them has been out of service for 8 years :)
<roadmr> (as soon as I got the cell phone, I cancelled that other number)
<zyga> We hardly call anyone on phone numbers now. It is mostly spam calls and more spam calls
<zyga> Intro family calls are all telegram and FaceTime
<zyga> Intra
<roadmr> hehe nice
#snappy 2019-04-26
<mborzecki> morning
<zyga> Hey :-)
<mborzecki> zyga: hey hey
<zyga> Hey mvo :-)
<mvo> hey zyga
<mvo> it looks like we have failures in the testsuite in fedora / centos right now
<mvo> or is it just my PR?
<zyga> My stuff was ok last night
<zyga> Iâm getting breakfast still
<mborzecki> mvo: hey, more selinux crap?
<mborzecki> btw. https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1826460 is the same story as https://forum.snapcraft.io/t/selinux-warning-when-running-lxc/11100/
<mborzecki> i seriously don't know what to think of it, oh and 2.39 breaks totally there
<mborzecki> i reproduced the problem with disco cloud image and installed that weird kernel from the kernel-ppa
<mvo> mborzecki: aha, is that the stacked LSM kernel?
<mborzecki> mvo: i don't think so, the kernel seems to have AA disabled, and SELinux enabled and default
<mborzecki> mvo: oh, and once you install the kernel, none of the selinux utils are pulled in
<mvo> mborzecki: woah
<zyga> Stacking?
<mvo> zyga: there is this work to allow selinux and apparmor in parallel, I was wondering if its that kernel
<zyga> mvo: disco has it
<zyga> It landed at the same time as another lxd related bug with shiftfs
<mborzecki> shitfs?
<mborzecki> ah, that's for uid/gid on fs
<mborzecki> anyways, i don't think it's this kernel
<pstolowski> heyas
<mborzecki> pstolowski: hey
<mborzecki> left a note under https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1826460/comments/3
<zyga> hey PaweÅ :)
<mborzecki> idk, maybe we could somehow guess the system is using a default policy, meaning, nothing probably works an then stop any attempt to use selinux
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6781 <- 2nd version of static attr fix
<pstolowski> zyga: yes, i saw it, thank you, will get to it shortly
<zyga> pstolowski: tha main difference is that the changes are made in reloadConnections, not in setup profiles, because this catches system key regeneration
<zyga> thanks!
<mborzecki> still don't get why someone who's not a kernel developer or test would install some kernel package from a random PPA
<zyga> mborzecki: I know why
<zyga> mborzecki: sergiusens does it because it makes his surface work
<zyga> mborzecki: AFAIK people do it to get modern vega working on older releases
<mborzecki> zyga: well, but sergiusens is more than capable of making it work
<zyga> mborzecki: some people do it to follow vanilla kernel development
<zyga> mborzecki: but not all people are sergiusens :)
<mborzecki> zyga: also, if you provide a kernel package for ubuntu, one would expect that it's soemwhat tailored for the distro :P
<zyga> mborzecki: there's an official vanila kernel ppa
<zyga> mborzecki: not tailored at all
<mborzecki> zyga: it's like someone provided a kernel package from COPR for fedora, which defaults to AppArmor, that'd be fun
<zyga> but what do I know :)
 * zyga could use a 2nd review for https://github.com/snapcore/snapd/pull/6758
<zyga> promise not to push more today ;)
 * zyga does more reviews
<pstolowski> zyga: reviewed static attrs PR
<zyga> pstolowski: thank you!
<Chipaca> mvo: morning sir. Working with sergiusens for a bit yesterday we were both surprised that #6532, which landed in master on 7/3, wasn't in 2.38 which was cut 21/3. My memory of (and, granted, attention to) the release is very poor, so I was hoping you'd know why this was this way
<Chipaca> https://github.com/snapcore/snapd/pull/6743 could use a second review if anybody is hankerin' to do one
<mvo> Chipaca: uh, that sounds fishy!
<mvo> Chipaca: aha, I see now. 2.38 was actually branched earlier, 2019-03-05 and at this point we only cherry-picked things targeted for 2.38 :/
<Chipaca> mvo: i suspected something like that
<Chipaca> mvo: but didn't have dates :-)
<Chipaca> a shame, but ok
<Chipaca> (sergio was all ready to use that feature :) )
<mvo> Chipaca: it wil be in 2.39 which is not that far away
<Chipaca> yep
 * pstolowski running quick errand, afk for a while
<zyga> heh
<zyga> Chipaca: I wanted to review https://github.com/snapcore/snapd/pull/6743 but I noticed I already did
 * Chipaca hugs zyga 
<Chipaca> zyga: thank you
<zyga> Chipaca: wanna do a quick 2nd +1 for https://github.com/snapcore/snapd/pull/6758 ?
<zyga> a part of an ongoing refactoring
<Chipaca> zyga: where is NewUserProfileUpdateContext used for, that it's public?
<zyga> it's used from main.go
 * zyga checks
<zyga> probably in subsequent patches
<zyga> Chipaca: in 2 patches from this one: https://github.com/zyga/snapd/commit/1ffaae4478d680566b78ead86f3911c5784893ea
<zyga> Chipaca: so not yet, but soon :)
<zyga> Chipaca: https://github.com/zyga/snapd/commits/feature/user-mount-ns-20.9-split-rebased -
<Chipaca> zyga: that's in the same package, isn't it?
<zyga> yes
<zyga> but we may need to put it into a library soon-ish so I'm slowly building towards that
<zyga> (for a new binary)
<zyga> snap-update-ns and snap-bootstrap-ns
<zyga> would share most of the code but would behave differently and bootstrap would do some new things too
<zyga> (bootstrap would also not need the horrid C bootstrap logic)
<zyga> (as in bootstrap.c, the name overlap is unfortunate)
<Chipaca> zyga: reviewed, mostly. Almost a +1.
<zyga> reading
<zyga> Chipaca: replied
<zyga> if it seems I'm relucant to change it it's partially true and because of the changes stacked on top; I can rework locking if you feel strongly about it but even there I would prefer to append a patch to this series (that was tested and "polished" rather than rebase it, mostly to avoid the extra cost
<pstolowski> re
<zyga> pstolowski: hey
<zyga> question to you sir:
<zyga> is this what you expected? https://www.irccloud.com/pastebin/CoMWt6SB/
<zyga> I would have to add the pair of unrelated snaps for this test to preserve that connection
<Chipaca> zyga: yes I think the lock/unlock pair would be better, but also yes no problem for it to be done further down the series
<pstolowski> zyga: yes, that's what i expected. do you need to add those snaps because something is unhappy about them missing?
<zyga> Chipaca: in that model, the unlock state would be simply stored in the context, right?
<Chipaca> zyga: yes
<zyga> pstolowski: not unhappy, as the comment states, they are removed on manager startup
<zyga> pstolowski: note that the order of manager startup vs adding snaps is essential
<Chipaca> zyga: or you could just embed the locker
<pstolowski> zyga: you could add them to the state after instantiating the manager and before carrying on with the test, no?
<zyga> No
<zyga> Because manager removes unused connections on startup
<zyga> I would have to add the unrelated snaps before starting the manager
<zyga> I can do that, just asking if that is what you expected
<pstolowski> zyga: yes, but that happens in Manager - initialize, when you instantiate the manager in the test. you can alter the state afterwards?
<pstolowski> zyga: ah i see
<pstolowski> zyga: perhaps the second test is better to do this
<pstolowski> zyga: the one that creates a task for setup-profiles
<zyga> Mhm
<pstolowski> zyga: sorry, you're right about the one i commented on
<pstolowski> zyga: btw https://github.com/snapcore/snapd/pull/6751 is pending some rework right?
<zyga> pstolowski: looking
<zyga> pstolowski: well, it needs tests
<zyga> pstolowski: but I think the place is right
<pstolowski> ok
<mborzecki> pstolowski: some quick fixes for the policy https://github.com/snapcore/snapd/pull/6783 that were caught in 6778
<zyga> mborzecki: man, selinux is comple
<zyga> complex*
<mborzecki> zyga: or just different conceptually
<Chipaca> zyga: ððððð£ð¤ð¥ðð¥ððððð¥ ð¸ððð£ð¥
 * mvo hugs zyga for "the computer says NO"
<zyga> lol :)
<zyga> pstolowski: updated https://github.com/snapcore/snapd/pull/6781
<zyga> the new thing is https://github.com/snapcore/snapd/pull/6781/commits/dd739571c24e659d0449c0c0ca6314719f301777
 * Chipaca goes out for a bit
<zyga> mvo: I think you should review https://github.com/snapcore/snapd/pull/6781
<mvo> zyga: full of meetings today but will do
<mvo> zyga: once I get the chance
<pstolowski> zyga: ty, will look in a bit
<zyga> Chipaca: something like this? https://github.com/zyga/snapd/commit/328b4b471e22609d60b4b4e430a4aa648963c714
<zyga> mvo: thank you!
<zyga> mvo: about https://github.com/snapcore/snapd/pull/6756 - should I rework it to return an error or leave as-is?
<zyga> Chipaca: https://bet365techblog.com/open-sourcing-jingo-a-faster-json-encoder-for-go <- maybe worth prototyping a switch to see what we'd save?
 * zyga quick lunch
<zyga> my body demands coffee
<zyga> my mind demands coffee
<zyga> I shall make coffee
<zyga> though going outside for a bike ride seems lovely too, it's so warm already
<zyga> pstolowski, mborzecki: I have 28C outside, you?
<mborzecki> 28-29
<pstolowski> zyga: 27 outside. 28 inside.. /o\
<zyga> desktop-portal-filechooser fails
<zyga> la la la
<mborzecki> out to drop the kids off at school for some extra classes, back in 30
<jdstrand> mborzecki: hey, can you look at https://github.com/snapcore/snapd/pull/6780#discussion_r278914233
<jdstrand> mborzecki: in 30 :)
<zyga> jdstrand: I pushed some things to https://github.com/snapcore/snapd/pull/6714
<zyga> hey :)
<zyga> jdstrand: (also replied to all the comments there)
<zyga> jdstrand: the /tmp thing has left one question in my mind
<zyga> jdstrand: on regular systems with classic packages /tmp is not private
<zyga> jdstrand: so if an app invoked by another user on this system drops a file that just happens to be readable by my user, well, tough luck, it'd better not contain secrets
<jdstrand> that's just normal dac
<zyga> jdstrand: the question is: why is snap /tmp different? could we just make /tmp/snap.$SNAP_NAME/ with 01777
<jdstrand> the /tmp should still be 1777 root:root
<zyga> jdstrand: note, in my question I eliminate the presence of intermediate root:root 0700 base directory
<jdstrand> it doesn't really need to be different. iirc, you are doing 0700 at that point only to bind mount on it and then later chmod 1777
<zyga> hmmm, we don't bind mount on it AFAIK
<zyga> or perhaps we do but that's something that we could change
<jdstrand> you are otherwise it wouldn't be known as /tmp in the mount namesapce... ?
<zyga> that is, we could mkdir 01777 and then bind mount that over /tmp (so not over /tmp/$RANDOM/tmp but over constructed-snap-rootfs/tmp
<zyga> yeah, but we construct the root filesystem in a different way now (on the side) and the very old code that manages /tmp could be adapted to that style too
<zyga> we could even mount a tmpfs there and call it a day (no visibility from initial mount namespace) but I think that was ruled out because of space constraints
<jdstrand> I'm not opposed to that changing. the main thing is, the result needs to be root:root 1777 and the getting there needs to be race-free
<zyga> jdstrand: can you expand on the race-free aspect?
<jdstrand> zyga: I don't think we want to mount a tmpfs there
<zyga> jdstrand: (agreed on tmpfs)
<jdstrand> zyga: we are actively not doing that because a tmpfs can take up to 50% of ram and those cause low memory
<jdstrand> thus*
<jdstrand> zyga: race free> yeah, however we get there, there can't be a possibility of an unprivileged user (or a snap at all) to to symlink attacks, etc
<zyga> mhm
<zyga> we protect against some of the attacks on mount with our special mount code in snap-update-ns but we don't have a C equivalent AFAIK
<zyga> jdstrand: as far as I'm aware only mount is really susceptible to a race attack, out of the primitives we use
<mborzecki> re
<zyga> jdstrand: I'm trying to find a solution that would be devoid of edge cases, correct, not insecure (see what I did there :), and usable for people
<jdstrand> zyga: I think you are not taking my point as intended
<jdstrand> zyga: we have a property now where we are race free. with the rename to a fixed dir or the rewrite you are sugggesting, we want the same property
<zyga> jdstrand: no disagreement there
 * jdstrand takes deep breath
<jdstrand> why is sid failing to build all of a sudden: https://paste.ubuntu.com/p/k9nYZkrSgP/
<zyga> jdstrand: where are you seeing this?
<zyga> in the sbuild test?
<jdstrand> I can't get out from under constant problems with this PR... /o\
<jdstrand> zyga: I saw it didn't build here: https://travis-ci.org/snapcore/snapd/jobs/524707744
<zyga> jdstrand: hey do you remember user mounts? :D
 * zyga looks
<jdstrand> zyga: it did not have great logs, so I tried in a local qemu
<zyga> jdstrand: it's going to be all right, it's just one of those moments where you improve things for many people, not just snap users, by fixing bugs blocking your work
<jdstrand> use -debug with spread and then rewound and did:
<jdstrand> cd /home/gopath/src/github.com/snapcore/snapd
<jdstrand> cd _build && go install -gcflags=all=\"-trimpath=/home/gopath/src/github.com/snapcore/snapd/_build/src\" -asmflags=all=\"...
<jdstrand> as shown by the -debug output
<jdstrand> zyga: yes, that's true. it is just been nuts
<jdstrand> thanks
<jdstrand> in this case, I don't know what bolt is. I do know what libseccomp-golang is, and I'm puzzled why sid is not working with the distro golang-seccomp
 * jdstrand shakes fist
<jdstrand> it seems to not be installed. why?
<zyga> how we ignore errors in some places? https://www.irccloud.com/pastebin/4jf6qJKw/
<jdstrand> </rhetorical>
 * jdstrand looks
<zyga> jdstrand: I'm trying to make sense of that but I see more magic
 * jdstrand is puzzled. these packages are in the build-depends
<zyga> src/github.com/snapcore/snapd/cmd/snap-seccomp/main.go:655:10: undefined: seccomp.ActLog <- this seems to say that golang-seccomp is older?
<zyga> jdstrand: build-depends vs vendorized
<jdstrand> I'm wrong, it is installed
<jdstrand> zyga: ah. ok. yes
<zyga> package from debian took priority?
<jdstrand> zyga: man I skipped right over that
<jdstrand> ok, I see what to do
<jdstrand> mborzecki: do you think if I just added the 4th field to system-key it wouldn't be a big deal?
<zyga> jdstrand: but does that mean we won't be able to build de-vendorized in sid?
<zyga> jdstrand: the sbuild test should show that btw, if that breaks next we need to update golang-seccomp in debian
<jdstrand> zyga: I can make it work. it worked before
<zyga> jdstrand: system key is flexible, just check how costly it is to compute because snap run does it
<jdstrand> I made a small changge to tyhicks initial patch which apparently broke it
<jdstrand> zyga: adding the 4th field couldn't be cheaper. it is that string match
<mvo> zyga: sorry for the delay - 6756 is afaict no longer needed, the change that landed recently checks for nil and returns an error now
<zyga> mvo: oh, where was that?
<zyga> mvo: please comment in the PR and feel free to close it
<mvo> zyga: thanks, will do
<jdstrand> mborzecki: nm, I'm going for it
<mborzecki> jdstrand: i wouldn't mind, it's an implementation aspect, not user facing, but nothing i would block on
<zyga> jdstrand: I will be much happer once, one day, I will replace all of snap-seccomp with pure go code
<mborzecki> jdstrand: though once it's collected & parsed in backend init, you could do whatever later on in the code, no need to call snap-seccomp once again
<mborzecki> (unless for compilation obviously)(
<zyga> jdstrand: and can remove that from system key for that extra oomph speed for snap startup :)
<zyga> mborzecki: note that snap-run does this every time AFIAK
<mborzecki> zyga: yes, it also picks up build ids and so on
<zyga> so-many-reviews
<jdstrand> zyga: well, I think you cannot do that without removing libseccomp cause libseccomp is C code and CGO_ENABLED=0, but I don't want to go there
<zyga> mborzecki: does it mean snap-run will run snap-seccomp with some query argument each time on every run?
<zyga> jdstrand: yes, that's what I meant
<zyga> but don't worry, I'm sure we will slowly get there, with enough checks to be confident we are producing the same bpf as before
<mborzecki> zyga: it's part of system-key, so yes
<zyga> mborzecki: would be good to time that
<zyga> (on a pi for example)
<jdstrand> zyga: I can't say how worried I am about that any more than I have. we should *not* reimplement libseccomp. the world has standardized on it and it is tricky code. we will trade one set of problems that everyone faces and has a desire to fix for another that only you could fix and no one else cares
<mborzecki> zyga: afaik we call apparmor_parser too, woulnd't expect snap-seccomp to be slower than that
<jdstrand> but I don't have time to debate this
<Chipaca> showoffs
<Chipaca> oops, wrong place
<mborzecki> offshows :)
<Chipaca> that was a comment about you and zyga having ~28C
<Chipaca> didn't notice i was scrolled way up
<zyga> haha
<Chipaca> zyga: looking at your locking code now
<zyga> Chipaca: I pushed a 2nd branch that fixes a typo in the branch name but it's otherwise identical
<Chipaca> zyga: calling Unlock when it's not locked would usually be a panic()
<zyga> Chipaca: +1, easy change
<Chipaca> zyga: either implicit or explicit I don't mind :-)
<mborzecki> hmm a bunch of snaps mounted locally, somehow udisks insists on showing 2 of them as normal disks, wtf?
<zyga> mborzecki: that's a local patch to udisks or you lost your mtab state
<Chipaca> mborzecki: that seems to happen when something is using and old core
<jdstrand> mborzecki: jdstrand: though once it's collected & parsed in backend init, you could do whatever later on in the code, no need to call snap-seccomp once again
<mborzecki> Chipaca: yes, that would be it
<jdstrand> mborzecki: I recall looking at that and had some trouble. what are you suggesting?
<jdstrand> mborzecki: reading it off the disk?
<Chipaca> my typo-ing rate today is quite high
<Chipaca> seem to be typing phonetically a lot
<mborzecki> jdstrand: iirc version info is kept in seccomp backend struct
<jdstrand> mborzecki: (this was the bit where I said 'there were multiple ways of doing this' in my PR
<jdstrand> mborzecki: that isn't available way out in overlord/snapstate
<jdstrand> mborzecki: I was hoping to extract it from somewhere via interfaces/system_key.go but resorted to a callout to snap-seccomp
<Chipaca> augh. There's a Jesse Lenton somewhere in Winnipeg that's receiving some documents via a secure online thing, but they've given my email for it â¦ so if anybody wants to find out some dirt about some employees of some random corp in canada, hit me up
<jdstrand> mborzecki: afaict, snapd doesn't maintain system-key in memory. it has it on disk and at strategic times, recalculates and compares to waht is on disk
<mborzecki> jdstrand: hm that's probably easier, the cache info is well hidden under interfaces :/
<jdstrand> yeah
<jdstrand> mborzecki: but I could read it from disk
<jdstrand> mborzecki: I was somewhat hesitant of that though
<jdstrand> I mean, it *should* be ok
<mborzecki> jdstrand: imo calling the compiler again sounds reasonable
<jdstrand> mborzecki: ok, that is where I landed. I'll add the fourth field then I just have the one callout
<mborzecki> jdstrand: unless, there would be like an instance of seccomp.Compiler() set up to use snap-seccomp kept somewhere
<mborzecki> jdstrand: hm otoh, that microoptimization is probably not worth it, so a second call to snap-seccomp sounds ok to me
<jdstrand> mborzecki: again, where I landed with 'picked something that made sense to me' :)
<jdstrand> mborzecki: thank you for discussing this here
 * Chipaca wanders off to make tea
<zyga> Chipaca: thanks for sharing that error talk!
<zyga> I'm very interested in error handling in both Go and C
<Chipaca> zyga: there's also a very good one about constants I think you'd enjoy
<Chipaca> zyga: https://www.youtube.com/watch?v=pN_lm6QqHcw
<zyga> Chipaca: opened in another tab
<zyga> https://github.com/snapcore/snapd/pull/6785 is green
 * zyga uses social engineering tricks to get reviews
 * Chipaca hires a russian bot farm to -1 zyga's PRs and thwart his social engineering campaign
 * Chipaca buys some sweets with the change
<zyga> Chipaca: we could move code review to twitter and facebook :D
<zyga> Chipaca: so can we start to stop using fmt.Erorrf :)
<Chipaca> zyga: well we shouldn't :-)
<Chipaca> because they hacked fmt.Errorf :-D
<Chipaca> (continue the talk)
<zyga> drat, that's like we watch a movie together but you know the ending :D
 * zyga watches
<Chipaca> as long as it's fmt.Errorf("yadda yadda %v", err), or %s err, it'll DTRT
<zyga> oh
<zyga> tricky
<zyga> it groks the argument is the wrapped error?
<Chipaca> zyga: also the error crawls up its butt and explodes it from the inside
<zyga> and stores it as well?
<Chipaca> something like that? i haven't tried it :-)
<zyga> juju/errors :)
<zyga> nice
<zyga> Chipaca: so will golang 2.0 switch to spaces and ban tabs?
<zyga> or will it be something we can reasonably be on in the next 12 months after it ships?
<Chipaca> all those big 2.0 features are getting worked into 1.x
<Chipaca> that was one of the things that came out of the 2.0 discussions
<zyga> so what will 2.0 bring?
<zyga> that's not in 1.x?
<zyga> interesting
<Chipaca> zyga: actual incompatible things left over?
<zyga> using interfaces is so natural in go
<Chipaca> zyga: basically they don't want to be python
<zyga> that's a neat idea
<zyga> Chipaca: a bit of what I'm hearing starts to feel like objc
<Chipaca> zyga: i haven't used objc in anger, so i don't have a strong opinion of it either way
<Chipaca> zyga: but i also don't know what you mean :-)
<zyga> Chipaca: the highly dynamic aspect
<Chipaca> i think the only time i've used objc it was actually c with some weird bits (rather like how i've used c++)
<zyga> the errors.As thing is odd, why on earth is it returning a boolean?
<mborzecki> zyga: sounds like you really want that pkg/errors package :)
<zyga> mborzecki: not sure yet
<zyga> I see their point about how those are weak
<Chipaca> zyga: errors.Is returns a boolean
<zyga> Chipaca: yes, but As ?
<zyga> Chipaca: I was expecting some form of casting but perhaps I misunderstood that
<Chipaca> https://tip.golang.org/pkg/errors/#As
<Chipaca> zyga: so you tell it the type by passing it a thing, so it sets that thing to the matching one and tells you that it succeeded via the bool
<zyga> ah, so it writes to the target
<zyga> I thought it just uses that for type information
<zyga> that makes sense now
<Chipaca> ye
<zyga> though ugly because golang and generics but that's all right
<Chipaca> zyga: (?i) makes the (containing sub)regexp case-insensitive from there to end or (?-i)
<zyga> yeah
<zyga> I read the replies from Maciej
<zyga> mborzecki: +1
<Chipaca> zyga: you can also do (?i:regexp) and have that subregexp be case-insensitive
 * zyga liked the RE_I flag or whatever that was called in other systems 
<Chipaca> zyga: other systems also support these flags
<Chipaca> i mean, this is taken from perl regexp syntax
<Chipaca> perl, python, and pcre all also support making it case insensitive outside of the regexp though
<Chipaca> and yes that is clearer, to me
<Chipaca> but Â¯\_(ã)_/Â¯ go's purportedly-perl-compatible regexps (which aren't) have that nice predictable non-pathological time characteristics, so that's nice instead
<Chipaca> btw perl's regexp support for unicode is _still_ unmatched
 * Chipaca looks into outsourcing reviews
<zyga> Chipaca: those russian trolls, do they do reviews too? :)
<Chipaca> zyga: i'm sure they do
<zyga> CHA-CHING!
<cachio> mvo, could you please include this pr #6694 to next 2.39
<cachio> mvo, you merge all the PRs with milestone 2.39 right?
<cachio> mvo, otherwise I can provide you a list of PRs which I need on 2.39
<zyga> Chipaca: watched both now
<cachio> jamesh, hi
<cachio> jamesh, I am testing snapd on 19.04 and 1 test is failing https://paste.ubuntu.com/p/YN44WYGCM5/
<cachio> doing xdg-open snap://package
<cachio> jamesh, I was researching and found that it fails when the package gnome-settings-daemon is preinstalled
<zyga> mvo: can we merge https://github.com/snapcore/snapd/pull/6717
<cachio> jamesh, were you aware of this problem?
<Chipaca> hmmmmm
<mvo> zyga: looking
<mvo> zyga: scopedTracker is a strange name
<zyga> mvo: perdronis changed it
<Chipaca> mvo: do you know why we allow installing ubuntu-core still?
<mvo> zyga: yeah
<zyga> mvo: so I guess it is his informal +1
<mvo> Chipaca: wuuut? we do?
<zyga> mvo: wrt to name
<mvo> zyga: yeah
<zyga> (insert chipaca emoji)
<mvo> zyga: hahaha
<zyga> I don't care, it's important to fix the bug more than to have a fun name
<mvo> zyga: I'm with you on that
<Chipaca> mvo: yes we do. Needs to be part of a multi-snap install; we block it for single snaps
<zyga> mvo: shall I merge it then?
<mvo> zyga: yes, looks sane
<Chipaca> zyga: there is as yet no chipaca emoji. But we've got a mate emoji, so the chipaca can't be far behind!
<mvo> Chipaca: aha, I see
<Chipaca> mvo: i'll fix
<zyga> mvo: merging, thanks!
<mvo> Chipaca: thank you
<Chipaca> mvo: https://github.com/snapcore/snapd/pull/6786 fwiw
<mvo> thanks Chipaca
<zyga> Chipaca: s/also//
<zyga> Chipaca: +1 though a spread test would be nice
<Chipaca> zyga: why no also?
<zyga> it reads oddly, not sure ;)
<zyga> saying
<Chipaca> ah ok
<zyga> saying "daemon: verify snap instructions for multi-snap requests" reads better
<Chipaca> boom
<zyga> thanks!
<Chipaca> i also removed the extra space your regexp left behind
<zyga> darn, I was thinking about that
<zyga> :D
<zyga> ok
<zyga> last thing of the day: spread test for the mount bug
<Odd_Bloke> jdstrand: I'd love your thoughts on https://forum.snapcraft.io/t/potential-additions-to-account-control-interface/11123/1
<Chipaca> Odd_Bloke: is the snap you're building only for use on ubuntu core?
<Odd_Bloke> Chipaca: At the moment, I'm just doing exploratory work to see what would be required to strictly confine cloud-init; this was one of the things that I found I had to add a `system-files` interface for, despite us having an interface that sounds like it would include them.
<Chipaca> Odd_Bloke: account-control is all about core tho
<Odd_Bloke> There is nothing in the docs that indicates that to be the case, AFAICT?
<Chipaca> the docs might need updating; it's an old interface
<Chipaca> # Only allow modifying the non-system extrausers database
<Chipaca> ^ that's from the code
<Odd_Bloke> The docs say "account-control allows managing non-system user accounts."
<Chipaca> yes i can read
<Chipaca> sigh
<Chipaca> Odd_Bloke: sorry, not sure where that came from
<Chipaca> Odd_Bloke: yes the docs might need updating, if I've got this right
<Chipaca> i'm not an expert on this bit of the code, jdstrand was the right person to ask
<Chipaca> but, from what's in the code, this will only work in core
<jdstrand> I responded
<Odd_Bloke> Thanks!
 * cachio lunch
<jdstrand> ok, rewrote the actlog PR: https://github.com/snapcore/snapd/pull/6787
<jdstrand> it was a more involved pr, but cleaner in the end, so I thing that is a good thing
<Chipaca> zyga: hostname-control might need a similar warning?
<Chipaca> zyga: OTOH if they're only for core, why have them in classic at all?
<zyga> Chipaca: TIF
<Chipaca> !
 * Chipaca goes
<Odd_Bloke> I think hostname-control is useful on classic?
<Odd_Bloke> It gives write access to /etc/hostname and exec on hostnamectl.
<jdstrand> Odd_Bloke: sure. it has no restrictions like that (just rememeber to snap connect it)
<jdstrand> (it is manually connected by default, which can be adjusted with a snap declaration)
<Odd_Bloke> I also had to add a few system-files rules to allow me to manage networking from cloud-init (on classic); is network-control expected to be a core-only thing, or is that worth opening up a topic for?
<jdstrand> Odd_Bloke: it is for anyone. please open a topic
<Odd_Bloke> Will do.
<jdstrand> Odd_Bloke: I'll be doing some profile bug fixes for 2.39 and will add that to the list
<Odd_Bloke> Oh, actually, I hadn't seen network-setup-control until I typed in my topic title, let me see if that makes a difference.
<Odd_Bloke> OK, that's simple enough to just read.
<zyga> jdstrand: does https://forum.snapcraft.io/t/snapping-a-font/11122/2?u=zyga sound sensibly?
<jdstrand> zyga: it would help. with fonts it probably isn't bad. with arbitrary content like images, sounds, movies it would be rather heavyweight
<Odd_Bloke> jdstrand: https://forum.snapcraft.io/t/network-control-network-setup-control-doesnt-enable-running-netplan-generate-on-classic/11126
<zyga> jdstrand: fonts contain full VMs nowadays, you know?
<Odd_Bloke> ISTR there were font cache versioning problems recently, too?
<Odd_Bloke> That might make fonts a little trickier?
<Odd_Bloke> (I recall none of the details.)
<zyga> Odd_Bloke: yes, at runtime, but not for distributing the font by itself I think
<zyga> but yeah
<zyga> it compounds the problem
<Chipaca> zyga: wrt fonts etc, couldn't we sanity-check them server-side?
<zyga> Chipaca: that's an interesting idea, perhaps we could
<zyga> Chipaca: but it would be tricky for one reason
<zyga> Chipaca: when you find that you were not checking for something that is evil and you said it was fine before you have to revoke that decision
<zyga> Chipaca: in a filter approach you can provide a refresh to the filter package and re-generate content
<Chipaca> zyga: yeah
<zyga> Chipaca: thereby neutering the invalid blob
<zyga> Chipaca: I think it's all a scale of paranoia
<zyga> one could say that some type of content is plausibly ok to ship without a filter
<Chipaca> CM fonts
<Chipaca> \o/
<zyga> Chipaca: some things can be chameleons and can be interpreted as many things at once
<zyga> it's complex but for some stuff I'd love to have it
<zyga> wallpapers and fonts are a good candidate
<Chipaca> fonts should be shipped only as metafont instructions, launchpad builds it into a snap that's gtg
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/6787#pullrequestreview-231254474
<Chipaca> i now have two (2! which is also 2) PRs that are green and just need another +1 to land
 * Chipaca also has more prs than just those, but these two are Special
 * Chipaca puts the PRs in the short bus
<zyga> Chipaca: wanna read https://github.com/snapcore/snapd/pull/6785 ?
<zyga> I could bug mvo for +2 and then open the next chunk :)
<zyga> (only about 5 left)
<zyga> this is a +12 â13 PR so pretty painless
<ijohnson> jdstrand: any chance you'll get a chance to review 6697 (about daemon-notify) soonish? if not that's fine I can workaround it but it would be better to know ahead of time if that workaround is likely to be necessary
<Chipaca> zyga: why is 1000 the right thing instead of os.Getuid()
<Chipaca> zyga: ?
<jdstrand> ijohnson: the workaround is likely necessary. possibly next week
<zyga> Chipaca: because the test uses 1000 a line above :)
<zyga> it's a fixed value
<zyga> Chipaca: read the 2nd commit plase
<zyga> *please
<zyga> Chipaca: sorry for the lag, I went upstairs to stretch and found pizza lefttovers :D
<zyga> *leftovers
<zyga> mvo: pretty please a 2nd review on https://github.com/snapcore/snapd/pull/6785
<zyga> Chipaca: thank you!
<zyga> Chipaca: for on this line https://github.com/snapcore/snapd/pull/6785/commits/0917f2460ae1d8dbe19823c32d79773add5addb1#diff-fca81d6060b39fa4cf7450a9d05bd004R384
 * zyga EODs
<ijohnson> jdstrand: ack thanks
#snappy 2019-04-27
<zyga> degville: https://docs.snapcraft.io/snapcraft-parts-metadata/8336 <- look for "Advanced grammar", the URL is deae
<zyga> *deae
<zyga> *dead even :)
<zyga> sergiusens: snapcraft question: I'd like to use snapcraft's source thing to download a file that is not a tarball
<zyga> sergiusens: and use a custom plugin (or make or something simple) to process it further
<zyga> sergiusens: any advice?
<degville> zyga: thanks for the heads-up. I've just been through the doc and can't find the missing link though (5 references to advanced grammar). I also did an invalid link scan. Could have been a temporary blip (sometimes this happens when the docs are updated). Could you check again and let me know?
<zyga> degville: it's not a href link
<zyga> if you check the source it's just an anchor
<zyga> <a>text</a>
<zyga> without the href attribute
<degville> zyga: ah, ok. got it - thanks! I'll fix it.
<zyga> not sure how that gets created
<zyga> thanks :)
<zyga> degville: using license: proprietary (straight from the docs) results in validation error
<zyga> error: cannot validate snap "xxx": cannot validate license "proprietary": unknown license: proprietary
<zyga> sergiusens: ^
<degville> zyga: good find, thanks. I'll look into it.
<zyga> degville: I think it's a cross-team issue
<zyga> the docs are correct but something along the way in the stack says "no"
<degville> zyga: I must admit, I've not tried putting proprietary in there, but yeah, I can add a caveat until it works.
<zyga> heh, it's probably the 1st thing non-foss people will try :D
<zyga> but yeah, I can understand why nobody tried it from the team
<degville> ahaha! true!
#snappy 2019-04-28
<brlin> https://forum.snapcraft.io/t/a-blocking-xdg-open-alternative/11141
<brlin> https://bugs.launchpad.net/snapd/+bug/1826747
#snappy 2020-04-20
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: good morning!
<mborzecki> hmm something for zyga https://paste.ubuntu.com/p/fMmRQNryVs/
<zyga> mborzecki, mvo: we must disable parallel instances for classic
<zyga> mborzecki: that is already excluded, I suspect someone ran a PR from earlier master
<zyga> althouhh
<zyga> *although
<zyga> 2020-04-17T20:30:19.4282018Z + find /run/snapd -user test '!' -path '*/user@12345.service/*'
<zyga> interesting, so there's another form on 20.04 now
<zyga> oh well
<zyga> I'll exclude that one too
<zyga> thanks
<mvo> thanks zyga
<zyga> https://bugs.launchpad.net/snapd/+bug/1873701
<mup> Bug #1873701: support for parallel instances on classic breaks all snap remove in lxd <snapd:New> <https://launchpad.net/bugs/1873701>
<mborzecki> zyga: what's broken with paralle instances?
<zyga> mvo: I believe this is urgent
<zyga> mvo: not security related
<zyga> mvo: it's just a bug that is particularly annoying, you cannot remove snaps, system is in a broken state
<mvo> zyga: right, when does it happen? it's behind a experimental flag so how easy is it to trigger?
<zyga> mvo: IIRC the flag is enabled on master now
<zyga> mvo: basically using edge breaks when you try to remove snaps
<mborzecki> zyga: iirc it's still experimental on master
<zyga> mborzecki: hmmm then something is broken
<zyga> mborzecki: we may not respect the flag then
<zyga> mborzecki: it definitely takes effect on edge
<mvo> zyga: also why did we not caught this in tests :/
<zyga> mborzecki: try the bug instructions please
<mvo> zyga: what bugnumber is that again?
<zyga> mvo: just above
<zyga> mvo: 1873701
<zyga> mvo: in other news snapd is entirely unusable in a 14.04 lxd container
<zyga> mvo: due to at least three bugs
<mborzecki> zyga: hm not sure i see it, how's that parallel instances?
<zyga> mvo: not sure if we want to be explicit about that
<zyga> mborzecki: it's the /snap mount point
<zyga>  ââ/snap /dev/sda5[/var/snap/lxd/common/lxd/storage-pools/default/containers/sid/rootfs/snap]
<zyga> we created this for parallel instances
<zyga> mvo: and there's a typical duplication of entries it causes
<zyga> er mborzecki ^
<mborzecki> zyga: ok, see that now, isn't that the shared code in s-c?
<zyga> yes
<mvo> zyga: oh, interessting. we sometimes hat "cannot umount ..." errors, do you think that could explain it?
<zyga> mborzecki: I think it just runs
<zyga> mvo: perhaps
<zyga> mvo: would have to look at a specific instance
<zyga> mvo: related to your work, another bug: https://bugs.launchpad.net/snapd/+bug/1873703
<mup> Bug #1873703: snapd doesn't start in a Ubuntu 14.04 container <snapd:New> <https://launchpad.net/bugs/1873703>
<zyga> mvo: this one I believe affects 14.04 in general, I cannot explain why it doesn't fail in our tests
<zyga> mvo: it's also easy to reproduce
<zyga> mvo: one more https://bugs.launchpad.net/snapd/+bug/1873704
<zyga> mvo: I guess we just never tested this case
<mup> Bug #1873704: snapd cannot be used in a Ubuntu 14.04 container - no squahsfuse <snapd:New> <https://launchpad.net/bugs/1873704>
<zyga> mvo: there's one more bug that I didn't report, 14.04 containers do not have loopback control device, making it impossible to mount any snap, even with side-loaded snap/squashfuse
<zyga> but I want to ask stgraber about it first
<zyga> in other news, good morning
<mvo> zyga: the lxd one is confusing
<zyga> sorry to bring bad news up front
<mvo> zyga:  dpkg -L snapd |grep fuse
<mvo> /usr/bin/snapfuse
<zyga> mvo: where? it's not in the archive package
<mvo> zyga:  apt list --installed snapd
<mvo> Listing... Done
<mvo> snapd/focal,now 2.44.3+20.04 amd64 [installed,automatic]
<zyga> mvo: perhaps I messed something up but it was definitely not there when I tried
<mborzecki> zyga: / wasn't shared under lxd, was it?
<zyga> mvo: that's a focal package :)
<zyga> mborzecki: correct
<zyga> mvo: 14.04 package is older and doesn't have it
<mborzecki> zyga: right, so this is where the bind mount /snap -> /snap comes from
<mvo> zyga: maybe it's another instance of 14.04 deb needing an update, I pushed something some weeks ago and then it lost with the people who can actually update things in 14.04 :/
<zyga> mborzecki: I see
<mvo> zyga: old pkg> aha, yes, then that's the case
<zyga> mborzecki: I wonder what's the new thing then, was removing snaps in containers always broken
<zyga> mborzecki: can you reduce my reproduction case to something smaller
<zyga> maybe the edge snapd there is not required?
<zyga> mborzecki: it was kind of late when I reported it
<mborzecki> zyga: looking at the pr with classic & parallel, the change was to have that mount ns setup when we're running a !classic snap || the experimental flag is set
<mborzecki> zyga: then we make sure that /snap is shared bind mount if / isn't
<mborzecki> (so lxd case?)
<mborzecki> the experimental flag would also trigger /var/snap mount
<zyga> indeed!
<zyga> mborzecki: so I guess the interesting combination is the edge refresh
<zyga> mborzecki: this code used to be absent
<zyga> mborzecki: right?
<mborzecki> zyga: hmm i would think a scenario like this, install (mount appears), you run a snap (/snap -> /snap appears), refresh happens (new mount appears), remove only unmounts /snap/foo/{n,n+1}, the original /snap/foo/{n} mount hidden by the /snap -> /snap is still present?
<zyga> mborzecki: I don't think so, the app snap has only one revision
<mborzecki> zyga: isnt't that similar to the problem we tried to solve with snap.mount unit that broke things on upgrade?
<zyga> mborzecki: it's the core snap that gets refreshed
<mborzecki> zyga: ah core, ok, but the app snap was run, and it triggerd /snap -> /snap bind mount
<zyga> yes, that part is essential
<mborzecki> zyga: then the mount /snap/open-watcom that had the /snap->/snap as its parent was cleaned up, but one that was under / was not
<zyga> that's how I understand it as well
<mborzecki> hm it'd be intersting to check that on older snapd, but that shared / check was present for a long time
<zyga> mborzecki: perhaps we should do something else, detach everything and remount / attach
<mborzecki> wonder if we call it earlier now
<mup> PR snapd#8522 opened: asserts: introduce ModelGrade.Code <Created by pedronis> <https://github.com/snapcore/snapd/pull/8522>
<pstolowski> morning
<mborzecki> pstolowski: good morning!
<mup> PR snapd#8523 opened: image,seed/seedwriter: support redirect channel aka default tracks <Created by pedronis> <https://github.com/snapcore/snapd/pull/8523>
<mup> PR snapd#8524 opened: bootloader: use binary.Read/Write <Simple ð> <UC20> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8524>
<pedronis> mvo: mborzecki: hi, I proposed some small PRs, two are UC20 related, one is the default track fix for prepare-image
<mvo> pedronis: thank you
<pedronis> mborzecki: is #8487 ready for reviews?
<mup> PR #8487: gadget, cmd/snap-bootstrap: MBR schema support <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<mborzecki> pedronis: yes, please do
<zyga> re
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8525
<mup> PR #8525: tests: ignore user-12345 slice and service <Created by zyga> <https://github.com/snapcore/snapd/pull/8525>
<mup> PR snapd#8525 opened: tests: ignore user-12345 slice and service <Created by zyga> <https://github.com/snapcore/snapd/pull/8525>
<zyga> mborzecki: I think that should fix it
<zyga> I need a review for https://github.com/snapcore/snapd/pull/8525
<mup> PR #8525: tests: ignore user-12345 slice and service <Created by zyga> <https://github.com/snapcore/snapd/pull/8525>
<zyga> er wait
<zyga> bad paste
<zyga> https://github.com/snapcore/snapd/pull/8515
<mup> PR #8515: testutil: add NewDBusTestConn <Created by zyga> <https://github.com/snapcore/snapd/pull/8515>
<pstolowski> mvo: hey, found one issue in your initramfs PR; i'm testing it this morning and something is still not quite right, same symptoms as before with cloud-init ð§
<pstolowski> (to be clear, your change takes effect and does the thing)
<mborzecki> meh everything is red
<mvo> pstolowski: aha, do you have more details? or maye the image so that I can run it myself?
<pstolowski> mvo:  cloud-init is not run, extra-users are not created, don't have any other clues yet. i can share the image, give me a moment. nb ubuntu-image will need a change afaict, atm i'm moving system-defaults to the proper location alongside system-data and user-data manually
<mvo> pstolowski: yeah, sharing the image would be ideal, if it's not too much effort
<mvo> pstolowski: that should allow me to peek at things
<mvo> pstolowski: might be something silly, I really want to write this spread test but didn't had time yet :(
<pstolowski> mvo: aaah i think i know
<pstolowski> mvo: i didn't update writable-paths
<mvo> pstolowski: no update it in what way?
<pstolowski> mvo: ah nvm, got confused. of course i'm not writing to /etc/systemd anymore, so not an issue. hmmm
<pstolowski> mvo: ok i uploaded the image
<mvo> pstolowski: please share the link
<pstolowski> mvo: sent you gdrive link
<mvo> pstolowski: checkin
<mvo> g
<mvo> pstolowski: downloading now
<pstolowski> mvo: actually, it seems it didn't copy the rsyslog symlink from system-data-defaults to system-data (but did run, .done is there). it doesn't explain why cloud-init didn't run though
<mvo> pstolowski: interessting
<mvo> pstolowski: booting mine now
<pstolowski> maybe i did a mistake somewhere
<mvo> pstolowski: inspecting now, looks like something funny/funky with cloud-init
<mvo> pstolowski: fwiw, I see the /dev/null symlink in /etc/systemd/system/rsyslog.service
<pstolowski> mvo: yes. but this might have been created by configure hook later
<mvo> pstolowski: aha, ok
<mvo> pstolowski: thanks, that's good to know
<pstolowski> mvo:  we should see rsyslog -> null symlink in system-data/etc/... as well, copied from system-data-defaults afaiu?
<mvo> pstolowski: yes, I see it there
<mvo> pstolowski: I don't see the var/lib/snapd/features there but that's because snapd cleans this dir on restart
<pstolowski> mvo: ah jeez, you're right it's there. i must have been blind
<mvo> pstolowski: no worries, let me look at cloud init some more
<pstolowski> mvo: interesting (about features)
<zyga> pstolowski: to remove features future snapd wrote but we don't know abut
<pstolowski> zyga: yes, makes sense
<mvo> pstolowski: and I suspect the state has this opiton not set (the experimental robust...)
<zyga> mvo: note, robust is now default
<zyga> when uset
<zyga> unless you explicitly disabled it it should be enabled
<zyga> unless this snapd is simply older
<mvo> pstolowski: as for cloud-init, it seems like it cannot found a data source, is there a cloud init no-cloud data file somewhere in this image?
<mvo> zyga: aha, thanks
<pstolowski> mvo: ahh, i forgot to copy cloud-data onto the image!
<mvo> pstolowski: hopefully that is the missing piece of the puzzle!
<pstolowski> mvo: yep. sorry about that! lots of hops and manual steps
<mvo> pstolowski: if it looks good after this test I will update my core-build PR and also provide this for core20
<mvo> pstolowski: yeah, no worries
<pstolowski> mvo: note the .done bug
<mvo> pstolowski: yeah, thanks for spotting this, silly me
<mvo> pstolowski: that's what I meant with "will update my pr" :)
<pstolowski> mvo: afaiu we also need to update ubuntu-image
<mvo> pstolowski: please remind me for what bits?
<mvo> pstolowski: could config?
<pedronis> we need to keep it as synced for UC 16/18 because we don't know what people did with hooks
<pedronis> so u-i should still work
<pedronis> for them
<pedronis> we want to clean this up a bit but shouldn't be a blocker, or so I think
<mvo> yeah, this is why I'm asking, I wonder if there is more
<pstolowski> mvo, pedronis it doesn't seem to take system-data-defaults directory at the root level (alongside user-data and system-data)
<pstolowski> unless i messed something
<pedronis> ah
<pstolowski> atm i writing them under system-data and move manually before booting for the first time, jsut for the test
<pedronis> that's different and might need fixing
<pedronis> it also works differently in UC16/18 vs UC20
<pstolowski> i didn't dig into u-i python code yet
<pedronis> the directory structure is different
<pstolowski> pedronis: should we put defaults under system-data to simplify?
<mup> PR snapd#8524 closed: bootloader: use binary.Read/Write <Simple ð> <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8524>
<pedronis> pstolowski: maybe, something to discuss with mvo
<pstolowski> mvo: success!
<pstolowski> mvo: cloud-init works
<pstolowski> mvo: ^ so the last bit to consider is what i just discussed above with Samuele
<zyga> brb, a small break
<mup> PR snapcraft#3060 closed: V2 npm plugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3060>
<pedronis> mborzecki: I reviewed #8487
<mup> PR #8487: gadget, cmd/snap-bootstrap: MBR schema support <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<mborzecki> pedronis: thanks
<mup> PR snapd#8523 closed: image,seed/seedwriter: support redirect channel aka default tracks <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8523>
<mup> PR snapd#8526 opened: image: improve/adjust DownloadSnap doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/8526>
<mup> PR snapd#8527 opened: seed: clearer errors for missing essential snapd or snap <Created by pedronis> <https://github.com/snapcore/snapd/pull/8527>
<mvo> pstolowski: aha, indeed, I think this needs fixing in u-i
<mvo> pstolowski: let me think about this for a moment - we could use /system-data/.defaults
<zyga> mvo: FYI: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/+bug/1873797
<zyga> mvo: I didn't look deeper
<mup> Bug #1873797: add_mountroot_fail_hook is either buggy or not used properly, causes boot problems <initramfs-tools-ubuntu-core (Ubuntu):New> <https://launchpad.net/bugs/1873797>
<mvo> zyga: nice, thanks
<pstolowski> zyga: should https://bugs.launchpad.net/snapd/+bug/1872115 be re-assigned to core? i don't know what to do about it tbh
<mup> Bug #1872115: [UC16] log rotation doesn't properly restart rsyslogd <snapd:New for stolowski> <https://launchpad.net/bugs/1872115>
<zyga> pstolowski: sure, feel free to reassign
<zyga> pstolowski: I can look after beta
<zyga> mvo: ^ if you agree
<mvo> pstolowski: +1
<mvo> pstolowski: how do you feel about /writable/system-data/.defaults (cc pedronis) - this avoids the need to modify u-i I think
<pstolowski> mvo: yes, this works for me, it's more less what i was suggesting
<pedronis> mvo: any particular reason to make it hidden?
<mvo> pedronis: no real reason, mostly worried about potential future clashes but probably a bit silly to worry about this
<mvo> pedronis: if not hidden, maybe /writable/system-data/config-defaults even ?
<pedronis> I actually think that making it hidden makes clashes a bit more likely
<pedronis> I have a /.cache which I don't know what makes it
<mborzecki> pedronis: updated 8487
<mvo> pedronis: ok, not-hidden is fine for me
<pedronis> mvo: pstolowski: let me think a bit about the name
<mvo> ok
<pedronis> mvo: all other directories there are meant to be bind mounted, right?
<mvo> pedronis: correct
<mvo> zyga: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools-ubuntu-core/+bug/1873797 is about the new initramfs code, right?
<mup> Bug #1873797: add_mountroot_fail_hook is either buggy or not used properly, causes boot problems <initramfs-tools-ubuntu-core (Ubuntu):New> <https://launchpad.net/bugs/1873797>
<zyga> mvo: I don't know, it's just something that flashed through my inbox
<mvo> zyga: it's the old stuff
<mvo> zyga: meh, thanks!
<zyga> presseding error on ubuntu 20.04 https://www.irccloud.com/pastebin/GMvrEUtj/
<zyga> mvo: ^ the log
<mup> PR snapd#8525 closed: tests: ignore user-12345 slice and service <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8525>
<mvo> zyga: yeah, I saw it, I suspect it's because something changed (lxd from using core->core18?)
<zyga> ah, inded
<zyga> that did happen just recently
<zyga> ENOTEA
<zyga> I'll eat lunch and make some tea
<zyga> ttyl
<ijohnson> mborzecki: you said you were going to try and pick up the ubuntu-boot grub.cfg writing from snapd? this is also needed for the pi4 boot, since when we run makeBootable20RunMode during install mode, we need the ubuntu-boot uboot.env to be there during the reboot's initrd, otherwise snap-bootstrap can't find a bootloader
<ijohnson> mborzecki: what I was going to do in the short term until we rewrite the ubuntu-boot boot assets like this was to just have the pi gadget install it's empty uboot.env to ubuntu-boot, so that the gadget partition creation effectively installs an empty uboot.env there
<mup> PR snapcraft#3063 opened: cli: update command names to new design <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3063>
<pedronis> ijohnson: to be clear, hard coding boot config is only for grub for now
<ijohnson> pedronis: why only grub ?
<pedronis> ijohnson: because we measure thing only with grub atm
<ijohnson> pedronis: but we basically have the same need for i.e. u-boot too for uc20?
<ijohnson> not for measuring
<ijohnson> but just for booting
<pedronis> we don't  measure
<pedronis> so there no a deep constraint
<pedronis> also there's more variability on uboot land
<pedronis> not sure there will be one uboot.cfg
 * cachio afk -> bank
<ijohnson> mborzecki: did you see my messages above?
<ijohnson> mborzecki: I am pushing forward with just having the gadget put a uboot.env on ubuntu-boot, and pedronis doesn't think it's necessary so probably for now if you pick up my branch just make non-grub bootloaders no-op on that
<mup> PR snapd#8528 opened: tests: naive fix for preseeding failure <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<mup> PR pc-amd64-gadget#43 opened: Clean up cmdline, after initrd&core land <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/43>
<pedronis> mborzecki: I re-reviewed #8487, couple small comments
<mup> PR #8487: gadget, cmd/snap-bootstrap: MBR schema support <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<ijohnson> pedronis: should I re-review that PR?
<ijohnson> my original changes in the PR are probably not relevant
<mborzecki> pedronis: thanks, i'll push it in a minute
<pedronis> it does need a 2nd review
<mborzecki> ijohnson: sorry missed that, let me check the backlog
<ijohnson> I'll try to review it today then, I'll also re-test it with the pi today
<mborzecki> ijohnson: right, grub.cfg for now
<ijohnson> mborzecki: yep
<pstolowski> cachio: ping
<cachio> pstolowski, hey
<pstolowski> cachio: do you have a moment for HO?
<cachio> yes
<pstolowski> cachio: ok, in standup HO
<pstolowski> pedronis: having small issue with the gadget + system-files plug + install hook approach as gadget is modified/unasserted, so no autoconected, also connections: in gadget yaml has no effect. not sure if there is any way around this :}. would devmode make sense?
<pedronis> pstolowski: do you know why connections in gadget don't work?
<pstolowski> pedronis: i suppose snapid is not avilable
<pstolowski> at least this is my understanding of the code atm
<pedronis> ah, yes
<ijohnson> mborzecki: https://github.com/snapcore/snapd/pull/8487#pullrequestreview-396608940
<mup> PR #8487: gadget, cmd/snap-bootstrap: MBR schema support <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<pstolowski> pedronis: i suppose i could update seed.yaml with devmode for the gadget (so the plug wouldn't be needed).. but that's slightly terrible
<pedronis> pstolowski: it's terrible but is the only thing that will work short term I fear, so it's  ok, the confinment of the hooks is not really what the test is about
<pstolowski> mhm
<pedronis> ?
<pstolowski> pedronis: no disagreement
<bdx> @reviewers bump https://forum.snapcraft.io/t/classic-confinement-request-for-nhc-snap
<pedronis> pstolowski: also preseed tests are failing on 20.04
<pedronis> 2020-04-20T16:49:24.6022877Z + CORE_IMAGE=
<pedronis> 2020-04-20T16:49:24.6023208Z + unsquashfs ''
<pedronis> 2020-04-20T16:49:24.6023431Z Could not open , because No such file or directory
<ijohnson> pedronis: seems he quit
<ijohnson> pedronis: I thought I saw zyga send a PR for that
<mup> PR snapcraft#3061 closed: plugins: introduce v2.RustPlugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3061>
<mup> PR snapcraft#3064 opened: cmake v2 plugin: rename configflags to cmake-parameters <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3064>
<pedronis> ijohnson: yes, but it says it actually breaks in a different way
<ijohnson> ah I didn't actually read the PR, I just saw the notification
<mborzecki> ijohnson: pushed a fix, thanks for catching this
<pedronis> so the issue is that cloud images now carry snapd snap, not the core snap
<pedronis> I disable those preseed tests on 20.04 for now
<pedronis> mmh, do we even need the hacks anymore
<mup> PR snapcraft#3065 opened: tests: fix local plugin spread test to be multi-arch aware <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3065>
<mup> PR snapcraft#3031 closed: build_providers: pass through SNAPCRAFT_{BUILD,IMAGE}_INFO to container or VM <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3031>
<mup> PR snapd#8529 opened: cmd/snap-bootstrap/initramfs-mounts: support non-ebl bootloaders <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8529>
<ijohnson> pedronis: I opened ^ it would be great if you could review it in your AM and we land it ASAP, I think it's the last bit we need in the initrd specifically to support uc20 on raspi
<mup> PR snapd#8522 closed: asserts: introduce ModelGrade.Code <UC20> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8522>
<mvo> ijohnson: thank you so much for this
<ijohnson> yaw mvo
<ijohnson> I will have 1 maybe 2 other PR's in addition to this to get the pi working, but those are just for snapd proper
<pedronis> ijohnson: mmh
<pedronis> ijohnson: I think we should really avoid to touch unrelated tests
<ijohnson> pedronis: ?
<pedronis> the Bootenv16 hack
<ijohnson> pedronis: hmm I guess I can get around that, what do you think the uc20 tests that want to use uc16 style thing should look like?
<pedronis> there is probably a simple way to do it without having to touch unrelated tests
<ijohnson> pedronis: how about `boottest.MockUC20LegacyKernelBootenv(bootloadertest.Mock("mock", c.MkDir()))` ?
<pedronis> also we should try to agree how to call the thing, because legacy is kind of misleading
<pedronis> we are stuck with this
<pedronis> and also it's using kernel_status
<ijohnson> yes I really don't know what to call it
<ijohnson> what I called it in 8512 is "pure env"
<ijohnson> because it just strictly uses the "bootenv"
<pedronis> ijohnson: and sorry I'm coming from this angle, instead of great, yay progress. I suppose the touching of unrelated tests tend to put me in a slightly critical state of mind
<ijohnson> pedronis: it's okay
<ijohnson> pedronis: I understand, wdyt about my proposal to use "pure env"
<ijohnson> ?
<pedronis> ijohnson: so there are two things to it, right? one is that is using the env and no symlinks, the other is that the extracted kernel is not one image but a bunch of files in dirs?
<ijohnson> pedronis: yes that is true, but note that there's nothing that specifically says we don't have a single image
<ijohnson> pedronis: all the code I've written/worked with are just about using env and no symlinks
<ijohnson> I don't think we have any assumptions that aren't uboot specific about having multiple files
<ijohnson> but maybe I'm forgetting something
<pedronis> no, it's likely so
<pedronis> ijohnson: I'm just trying to find something that is not too far from ExtractedRunKernelImageBootloader
<ijohnson> pedronis: maybe ExtractedRunKernelImage is wrong
<ijohnson> pedronis: maybe we should change that to something like ExtractedRunKernelImageSymlink ?
<ijohnson> or ExtractedKernelSymlink
<pedronis> ijohnson: no, it's right because Image means one file
<ijohnson> mmm
<pedronis> but there are nuances we lose either way
<pedronis> unless we use unbearably long new names
<ijohnson> how about we just drop run and have ExtractedKernelImageSymlinkBootloader ?  then for this other one it would just be ExtractedKernelEnvBootloader ?
<ijohnson> I mean I don't think we get to have short names given the subject matter and the specificity we desire
<pedronis> anyway it also not the time to rename the other one I think
<ijohnson> okay, how about ExtractedKernelEnvBootloader for this new thing ?
<ijohnson> it doesn't necessarily need to be an actual bootloader.Bootloader yet
<ijohnson> but we would just call that kind of thing an "extracted kernel env" thing ?
<pedronis> but the kernel doesn't need to be extracted, as you said
<pedronis> it is though in practice
<ijohnson> well I may have mis-spoke, I think we do require it to be "extracted" in that it can't be in a .snap
<ijohnson> it needs to be extracted from the snap
<ijohnson> but not really any more extracted
<pedronis> EnvRefExtractedKernelBootloader
<ijohnson> sure that's fine
<ijohnson> so then for mocking we would have
<ijohnson> boottest.MockUC20EnvRefExtractedKernelRunBootenv(bootloadertest.Mock("mock", c.MkDir()))
<pedronis> yes
<ijohnson> a mouthful, but good enough
<ijohnson> give me a few minutes to update the PR to not change the other tests
<ijohnson> and use this new thing
<pedronis> I mean you can probably cheat and use/change Bootenv16 if useful as long as it's not visible to the test using it
<ijohnson> yes that's exactly what I've done
<pedronis> I mean the MockUC16 shouldn't take new params
<ijohnson> yes
<ijohnson> but the struct now has an additional unexported member that is what status var
<ijohnson> to use
<pedronis> that's fine I suppose
<pedronis> we don't make it directly
<ijohnson> pedronis: okay updated back to just 3 files changed
<ijohnson> I am going to rename the things in#8512 too to match this new name
<pedronis> ijohnson: why is the first new test separate from the rest? is creating a bit of a confusing diff
<ijohnson> pedronis: as I explained in the commit msg / PR description ideally we shouldn't test this additional dimension of type of bootloader here in snap-bootstrap, we should test that in the boot pkg when all this logic goes there
<ijohnson> pedronis: so for now just to get adequate coverage / assurance things are working I just copied all the kernel tests we have and ported them to use that bootloader name we just invented
<ijohnson> pedronis: I apologize for the diff thing, I don't know why github does that
<ijohnson> it's more sensible if you look at just the commit
<ijohnson> i.e. https://github.com/snapcore/snapd/pull/8529/commits/1619e0824b62649e5957050ef7c70570bb0ed008
<mup> PR #8529: cmd/snap-bootstrap/initramfs-mounts: support EnvRefExtractedKernelBootloader's <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8529>
<pedronis> ijohnson: that's not my question, my questions is why is TestInitramfsMountsRunModeStep2LegacyKernelBootstate all alone
<pedronis> and all the other Legacy are later
<ijohnson> oh hmm I dunno
<ijohnson> I can move it if you like
<ijohnson> I guess I wrote that one first from scratch then just copy pasted all the other ones and changed the relevant bits
 * ijohnson has already forgotten
<pedronis> ijohnson: heh, it's ok, by yes if you don't have a strong reason to have it where you put it, having it together with the rest is preferable
<ijohnson> sure I can push another commit moving it by the others
<ijohnson> one second
<pedronis> ijohnson: did you rename them away from Legacy ?
<ijohnson> ahhhhhh I will now :-)
<pedronis> ijohnson: jusrt s/Legacy/EnvRef/
<pedronis> don't think we want super long names
 * ijohnson glares at TestInitramfsMountsRunModeStep2EnvRefKernelBootstateUntrustedTryKernelSnapFallsBack
<pedronis> ijohnson: reviewed
<ijohnson> ack, thanks for the review
<pedronis> ijohnson: thanks for working on making the diff a bit more digistible
<ijohnson> no problem , re the TODO, is the TODO just about not returning a Bootenv16 or is it about not using that at all for the implementation of MockUC20EnvRefExtractedKernelRunBootenv ?
<pedronis> ijohnson: it's about no returning a Bootenv16, I can see various ways, anyway is not an immediate concern, but is a bit confusing to use a thing called 16 related to 20
<ijohnson> pedronis: ack that makes sense
<pedronis> ijohnson: next I should review #8512 ?
<mup> PR #8512: boot/bootstate20: add EnvRefExtractedKernelBootloader bootstate20 implementation <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8512>
<ijohnson> pedronis: yes, I will have the last PR open later tonight
<ijohnson> but 8512 is the next one, then the one I am yet to open
<pedronis> ijohnson: ok, I'll look at 8512 in my morning, if you have a moment you should s/Legacy/EnvRef/ in the mostly test names there
<ijohnson> ah yes, forgot about the tests there too
<ijohnson> have a good night pedronis
<pedronis> thanks, have a good end of the day
<mup> PR snapcraft#3066 opened: autotools v2 plugin: rename configflags to autotools-configure-parameâ¦ <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3066>
<mup> PR snapd#8530 opened:  boot: enable makeBootable20RunMode for EnvRefExtractedKernel bootloaders <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8530>
<mup> PR snapcraft#3063 closed: cli: update command names to new design <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3063>
<mup> PR snapcraft#3067 opened: requirements: uprev python-apt <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3067>
<mup> PR snapd#8531 opened: secboot,cmd/snap-bootstrap: add model to pcr protection profile <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
<mup> PR snapcraft#3065 closed: tests: fix local plugin spread test to be multi-arch aware <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3065>
<mup> PR snapcraft#3067 closed: requirements: uprev python-apt <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3067>
#snappy 2020-04-21
<mup> PR snapcraft#3064 closed: cmake v2 plugin: rename configflags to cmake-parameters <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3064>
<mup> PR snapcraft#3066 closed: autotools v2 plugin: rename configflags to autotools-configure-parameâ¦ <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3066>
<mup> PR snapcraft#3068 opened: cmake v2 plugin: default to -DCMAKE_BUILD_TYPE=Release <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3068>
<mborzecki> morning
<zyga> o/
<mvo> hey zyga
<zyga> hey mvo
 * zyga needs coffee
<mup> PR snapd#8526 closed: image: improve/adjust DownloadSnap doc comment <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8526>
<mup> PR snapd#8532 opened: tests: install new snapd deb into preseed image <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8532>
<mborzecki> zyga: mvo: morning guys
<mborzecki> zyga: yeah, coffee sounds like a plan
 * zyga was unable to sleep last night, collapsed after 2AM
<mborzecki> coffee iv then ;)
<mborzecki> s/coffee/caffeine/
<mborzecki> in the meantime: https://forum.snapcraft.io/t/centos-8-snapd-install-of-authy-doesnt-show-up-in-applications-folder/16684/5 despite all the tricks we pull, looks like XDG_DATA_DIRS is still not in the env sometimes
<mborzecki> funnily enough, it's in the terminal, but that's probably a result of /etc/profile.d bits
<mborzecki> mvo: do you want to take a look at the latest changes in #8487 before i land it?
<mup> PR #8487: gadget, cmd/snap-bootstrap: MBR schema support <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8487>
<mvo> mborzecki: let me quickly look
<mup> PR snapd#8487 closed: gadget, cmd/snap-bootstrap: MBR schema support <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8487>
<mborzecki> yay!
<mup> PR snapd#8529 closed: cmd/snap-bootstrap/initramfs-mounts: support EnvRefExtractedKernelBootloader's <UC20> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8529>
<zyga> re
<zyga> 0.5 coffee
<mup> PR core20#46 opened: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
<pstolowski> morning
<mvo> pstolowski: good morning - just fyi, i pushed https://github.com/snapcore/core20/pull/46
<mup> PR core20#46: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
<pstolowski> mvo: great, thank you
 * pstolowski is going to look at the 20.04 preseed test hang issue in a few moments
<pedronis> pstolowski: the issue is that the 20.04 cloud images have snapd snap, not the core snap now
<pedronis> but I'm not even sure we need the hack or not (do they have 2.44 ? now)
<pstolowski> looking
<zyga> pstolowski, pedronis: I fixed that locally
<zyga> I'll send an update to my PR in a moment
<pstolowski> zyga: yay!
<zyga> fruit of last night sleeplessness
<zyga> pstolowski: one interesting thing that changed is that the revisions are no longer unset (in the task log)
<zyga> is that expected?
<zyga> or is that a consequence of just using asserted blobs
<pstolowski> zyga: if the hack is removed and we no longer taint the snap then yes
<zyga> thanks, I was wondering about that
<pstolowski> zyga: if the test was failing because of that then i suppose hanging was (again) caused by restore/qemu-nbd stuff
<zyga> pstolowski: actually I never got to the bottom of why it hanged
<zyga> pstolowski: I disabled the call to setup_preseeding and adjusted the MATCH rules below to reflect new reality
<zyga> weird
<zyga> interactively it would not hang
<pstolowski> zyga: yes the hang is misterious and i couldn't figure it out before, it's the 3rd time it bites
<pstolowski> zyga: it is something in the qemu cleanup
<zyga> hmmm
<zyga> I think I see what it may have hanged
<zyga> root       20047  0.7  0.2 466144  8244 ?        Ssl  07:31   0:00 qemu-nbd -c /dev/nbd0 cloudimg.img
<zyga> this process must die
<pstolowski> zyga: as you say interactively it works
<zyga> right but this process must die :)
<pstolowski> zyga: but qemu-nbd -d should do it afaiu?
<zyga> yes
<pedronis> mvo: hi, I reviewed Ian's #8512
<mup> PR #8512: boot/bootstate20: add EnvRefExtractedKernelBootloader bootstate20 implementation <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8512>
<zyga> oh drat, I passed -shell again
<zyga> pstolowski: I figured it out
<zyga> pstolowski: such a simple mistake :DDDD
<pstolowski> \o/
<pstolowski>  /o\
<zyga> look at restore
<zyga> what is missing?
<zyga> the test just failed
<zyga> we are running restore
<zyga> reset test is equally broken
<pstolowski> yeah i'm not surprised, they reuse same patterns
<pstolowski> i probably spent too much on these tests to see the problem :/
<pstolowski> what is it?
<zyga> https://github.com/snapcore/snapd/pull/8528/files#diff-c6e01e719c875585769d5445f3982ecbR21
<zyga> restore ran on failure
<mup> PR #8528: tests: naive fix for preseeding failure <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<pstolowski> zyga: noooooooo
<zyga> eh sorry
<zyga> https://github.com/snapcore/snapd/pull/8528/files#diff-c6e01e719c875585769d5445f3982ecbR31
<zyga> and ran umount_ubuntu_image without sourcing the definition
<zyga> I made prepare/restore handle the mounting
<pstolowski> drat
<zyga> so it was that process :)
<zyga> it was the only possibility
<pstolowski> zyga: thank you!
<zyga> happy insomnia was productive
<pstolowski> manual/preseed may need a tweak too
<zyga> pstolowski: thanks, I'll look
<zyga> done
<pedronis> mvo: I did a pass on #8530 as well, some questions there
<mup> PR #8530:  boot: enable makeBootable20RunMode for EnvRefExtractedKernel bootloaders <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8530>
<pstolowski> zyga: let me know when i should review
<zyga> pstolowski: sure
<zyga> pstolowski: I'll open the draft soon
<mvo> pedronis: thanks, looking
<pstolowski> zyga: we need to be careful about 19.10 in these tests, it may not be updated the same way
<zyga> pstolowski: yeah, I'm running the more complete set to see what fails
<pedronis> mvo: mmh, I didn't notice #8531, I made a comment there, we also to think how to keep the info around for run mode
<mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
<pstolowski> zyga: jamesh proposed a PR for preseed test as well
<jamesh> pstolowski: mine was mainly just exploring to see if that might fix it
<jamesh> pstolowski: one of my other PRs changes some packaging (adding some directories), which caused the preseed-reset test to fail since the image had an old snapd in it
<pstolowski> jamesh: i see. yes, that test is very picky about snapd directories, i updated it recently for 19.10 vs 20.04
<jamesh> pstolowski: the comments about certain images containing too old versions made me think it would be better to test the image with the snapd version under test installed.
<jamesh> pstolowski: although that resulted in some complaints about some files under /var/cache/apparmor
<pstolowski> jamesh: this is certainly a fair point, otoh it's good to test that we support existing ubuntu images (once they have recent enough snapd but lag a little bit). it's the transition period that's a little annoying but it should stabilize soon
<jamesh> pstolowski: it seems like the kind of thing that will destabilise any time snapd changes sufficiently though.
<pstolowski> jamesh: maybe i need to rethink this test; maybe it could look into debian dirs to see what's actually expected atfer a reset
<jamesh> pstolowski: would that be the debian dir of the snapd under test or the old snapd in the image?
<zyga> pstolowski: I have one more tweak that addresses the hang
<pstolowski> jamesh: hmm that's a good question. current reset code is "cheating" and has a simplified view of that and resets for the snapd under test
<jamesh> pstolowski: that's probably good enough in practice though: a system you reset is eventually going to get the new snapd anyway
<pstolowski> jamesh: true, and the key point is that we don't leave files around (empty directories should be harmless)
<zyga> pstolowski: hopefully this will shed some light as to why it was hanging and how to address such problems in general
<zyga> pstolowski: (earlier I spoke too soon, the small mistake in the restore was not everything)
<pstolowski> zyga: mhm
<pstolowski> zyga: thank you for looking into it. a fresh look at these tests helps
<zyga> pstolowski: it passed now
<zyga> pstolowski: I'll run the rest
<pstolowski> nice
<zyga> I have a small problem at home
<zyga> my internet quota for the month is almost gone
<zyga> I have a backup but I need to find the extra modem and connect everything :/
<zyga> pstolowski: you may find this interesting https://github.com/snapcore/snapd/pull/8528/files#diff-2a7ec7462b6ff35150bfb39e2b01fc83R18
<mup> PR #8528: tests: fix for pre-seeding failures <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<pstolowski> zyga: woot. it affects ssh?
<pstolowski> ?
<zyga> the other way around
<zyga> maybe I should rewrite the comment
<zyga> and there's a typo there
<zyga> blargh :)
<pstolowski> zyga: do you know why is it a problem?
<zyga> yes
<zyga> one sec, cannot typpe
<zyga> pstolowski: because each stuff spread runs is done so in a new ssh session: https://github.com/snapcore/spread/blob/master/spread/client.go#L337
<zyga> that session will terminate when the remote side descriptors are closed
<zyga> but they are not closed because they get inherited into "background" tasks
<zyga> systemd-run handles descriptors and closes anything that is not explicitly forwarded
<zyga> pstolowski: please look https://github.com/snapcore/snapd/pull/8528
<mup> PR #8528: tests: fix for pre-seeding failures <Created by zyga> <https://github.com/snapcore/snapd/pull/8528>
<pstolowski> zyga: i see, thank you
<zyga> jamesh: I'll push the change you requested along with the shellcheck quote fix in a moment, I just want to see it pass for real
<zyga> jamesh: pushed
<zyga> mborzecki: there's a failure in selinux lxd test on centos8
<zyga> mborzecki: IIRC it is something new
<zyga> I collected some samples last time I saw this
<zyga> type=SYSCALL msg=audit(1587118309.956:1881): arch=c000003e syscall=9 success=yes exit=139877378064384 a0=0 a1=4caf68 a2=5 a3=802 items=0 ppid=1371 pid=2743 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="snap-update-ns" exe="/usr/libexec/snapd/snap-update-ns" subj=system_u:system_r:snappy_mount_t:s0 key=(null)
<zyga> type=AVC msg=audit(1587118309.956:1881): avc: denied { execute } for pid=2743 comm="snap-update-ns" path="/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1" dev="loop2" ino=5726 scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:object_r:snappy_snap_t:s0 tclass=file permissive=1
<zyga> type=AVC msg=audit(1587118309.956:1881): avc: denied { map } for pid=2743 comm="snap-update-ns" path="/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1" dev="loop2" ino=5726 scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:object_r:snappy_snap_t:s0 tclass=file permissive=1
<zyga> mmap?
<mborzecki> hmm probably wonder why libcrypto got pulled in
<mborzecki> zyga: iirc snappy_mount_t should have all the permissions to execute/mmap/open from snappy_snap_t
<mborzecki> zyga: we don't expect it to be statically compiled
<zyga> mborzecki: no idea, maybe more nsswitch?
<mborzecki> zyga: do you have shell? can you ldd /usr/libexec/snapd/snap-update-ns?
<zyga> no I don't -- that was last week
<zyga> it's not a priority, centos8 is in the unstable group
<mborzecki> hm so crazy idea abou tthe native endian check
<mborzecki> zyga: how about we have a dbustest2_amd64.go with `func init() { nativeEndian = binary.LittleEndian } dbustest2_other.go that just sets nativeendian = whatever?
<zyga> mborzecki: happy to in a follow up
<zyga> I'm trying to get the big one merged
<zyga> mborzecki: I was thinking that endianness could be a package somewhere
<mborzecki> zyga: nothing urgent, you could just leave it as it is now
<zyga> as its not just this place
<pstolowski> mvo: one more annoynace... https://github.com/snapcore/core-build/pull/59/files#r412081969
<mup> PR core-build#59: initramfs: add new handle_writable_defaults() <Created by mvo5> <https://github.com/snapcore/core-build/pull/59>
<pstolowski> mvo: it's shocking how easy it is to get things wrong in shell
<mvo> pstolowski: thnaks!
 * zyga focuses on review for jamesh 
<zyga> pstolowski: cp "$srcpath/"*
<mvo> pstolowski: yeah, plus missing tests :/ I think this needs a test, I will have a look
<pstolowski> zyga: right
<mup> PR core20#46 closed: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/core20/pull/46>
<zyga> pstolowski: the preseed test has different behavior in 19.10 and 20.04
<pedronis> mborzecki: not there is really a question whether it should be boot/uboot or just uboot,  we don't have boot/uboot in boot or do we?  do we want boot/boot/uboot at runtime?
<zyga> because of core / snapd
<zyga> pstolowski: I kind of switched gears now so if you want to attack that feel free
<pstolowski> zyga: yes, this is expected (if you mean the MATCH parts), that's what I tried to convey before
<zyga> I forgot to run the suite on 19.10 again
<zyga> oh well :)
<pstolowski> zyga: sure i can take it from you and fix that
<zyga> pstolowski: thanks!
<pstolowski> zyga: ty!
<zyga> pstolowski: I guess it's just the match and count that has to change
<pstolowski> zyga: have you pushed everything?
<zyga> pstolowski: yes
<pstolowski> zyga: yes, i think we need big if/else there and keep the old matches
<zyga> indeed
<pstolowski> zyga: okay, i need lunch soon, will get to it after standup i suppose
<pstolowski> where do we assign bugs to core, LP?
<zyga> actually github
<zyga> because $reasons
<zyga> but also on lp
<zyga> so dunno
<pstolowski> mhm
<mborzecki> pedronis: so with recovery|noslashboot: true you'd rather use `uboot` as basedir?
<pedronis> mborzecki: maybe, I wonder what .scr expects and what we do in ubuntu-boot
<mborzecki> pedronis: if i'm reading this right, ubuntu-seed has boot/uboot, but ubuntu-boot will be mounted at /boot, so we'll ahve /boot/boot/uboot?
<pedronis> pedronis: yes, exactly, something seems off
<pedronis> but I don't know what the .scr does exactly
<mborzecki> pedronis:the bind mount is /run/mnt/ubuntu-boot -> /boot right?
<pedronis> that's what I would expect yes
<pedronis> I'm double checking how this looks on amd64 atm
<mborzecki> pedronis: there's EFI/ubuntu iirc
<zyga> jamesh: https://github.com/snapcore/snapd/pull/5822#pullrequestreview-395477722
<mup> PR #5822: wrappers: allow user mode systemd daemons <:birthday:> <Needs Samuele review> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<mup> PR snapd#8527 closed: seed: clearer errors for missing essential snapd or core snap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8527>
<zyga> mborzecki: FYI https://github.com/snapcore/snapd/pull/7825#discussion_r412110567
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pedronis> mvo: mborzecki: google:ubuntu-core-20-64:tests/core/basic20 from master is getting stuck on me, it's printing Reboot on apr211119-149277 (google:ubuntu-core-20-64:tests/core/) is taking a while... since 20 mins+
<mborzecki> pedronis: probably failed in initramfs/grub
<pedronis> did we break something?
<mborzecki> it'd be great to ahve a way to store those artifacts
<zyga> mborzecki: did you say artifacts? :)
<pedronis> mborzecki: we have a new kernel from today in edge and beta fwiw
<mborzecki> ayy
<mborzecki> initramfs changes? :P
<mborzecki> i'm checking out rhel8/centos for popey, i'll build and image and check what's going on after
<mup> PR snapd#8533 opened: [WIP] image, tests: core18 early config test <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<mup> PR snapcraft#2911 closed: [experimental] package-management repository configuration <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2911>
<mup> PR snapd#8534 opened: tests: 16.04 and 18.04 now have mediating pulseaudio (again) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8534>
<zyga> google:ubuntu-16.04-64:tests/main/interfaces-audio-playback-record keeps failing :/
<zyga> aha
<ijohnson> morning folks
<zyga> I think I see why
<zyga> https://github.com/snapcore/snapd/pull/8534#pullrequestreview-397296420
<pedronis> does #8534 by jdstrand relates?
<zyga> hey ian :)
<ijohnson> zyga: hey
<mup> PR #8534: tests: 16.04 and 18.04 now have mediating pulseaudio (again) <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8534>
<zyga> pedronis: indeed!
<pedronis> anyway everything is terrible
<zyga> pedronis: I think people are great, despite the fact we are all stressed and the release is looming
<ijohnson> what a great way to start my day
<ijohnson> :-D
<zyga> mvo: https://github.com/snapcore/snapd/pull/8534 is important, please get it into any . releases you may need
<mup> PR #8534: tests: 16.04 and 18.04 now have mediating pulseaudio (again) <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8534>
<pedronis> ijohnson: hi, google:ubuntu-core-20-64:tests/core/basic20 doesn't seem to work on master atm
<pedronis> there was a new kernel
<pedronis> I'm trying to run it manually and it doesn't get out of reboot
<ijohnson> ah
<ijohnson> pedronis: I'll look into it
<ijohnson> I don't know what the problem is, but I have a hunch it might be related to the initrd things from yesterday
<mvo> zyga: oh, ok
<zyga> cachio: add a cron timer to run tests on master once a day
<zyga> cachio: it's better than nothing and costs very little
<cachio> zyga, we can run using spread cron as welll
<zyga> cachio: actions are better
<zyga> cachio: they update master status
<zyga> cachio: they notify everyone automatically
<zyga> cachio: and they are managed in the repository
<cachio> zyga, ok
<zyga> cachio: you can then see it the status alongside each commit that was tested
<zyga> mvo: can you please override https://github.com/snapcore/snapd/pull/8534
<mup> PR #8534: tests: 16.04 and 18.04 now have mediating pulseaudio (again) <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8534>
<cachio> zyga, ok
<cachio> I'll add that so we have runs on master
<mup> PR snapd#8534 closed: tests: 16.04 and 18.04 now have mediating pulseaudio (again) <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8534>
<zyga> mborzecki: I tweaked the code, it's pretty interesting how everything can fail in various cases. I didn't push yet but I think this is "the" way
<zyga> mborzecki: the thing I learned is that we may have a session bus
<zyga> mborzecki: but it may be entirely malfunctioning
<zyga> mborzecki: because socket activation of dbus is not always going to work
<zyga> mborzecki: because some systems package that separately
<zyga> :)
<zyga> mborzecki: so I tweaked the logic to cope with "late" failure, after we get the connection, it may turn out to be just "bad"
<zyga> mborzecki: I treat this the same as session bus being unavailable now, for uid == 0 go to system bus
<zyga> in the end some things got simplified and all error and debug handling is in once spot
<zyga> mvo: I need to run an errand soon, going to visit my parents to pick up the LTE modem they are not using, I ran out of my 1TB quota /o\
<roadmr> I don't know what's more mind-boggling, that you have a 1TB quota on LTE or that you exhausted it ð
<mvo> zyga: ok, thanks for letting me know
<mup> PR snapcraft#3069 opened: make v2 plugin: make use of make-parameters <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3069>
<mup> PR snapcraft#3068 closed: cmake v2 plugin: default to -DCMAKE_BUILD_TYPE=Release <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3068>
<cmatsuoka> mvo: up and running again
<ijohnson> cmatsuoka: isn't today supposed to be your day off :-P
<mvo> cmatsuoka: great!
<mvo> cmatsuoka: welcome back
<cmatsuoka> ijohnson: I don't have many places to go actually
 * cachio lunch
<ijohnson> cmatsuoka: haha fair enough
<cmatsuoka> but it's possible that I could be a bit slower today
 * zyga is AFK
<pedronis> #8512 needs a 2nd review
<mup> PR #8512: boot/bootstate20: add EnvRefExtractedKernelBootloader bootstate20 implementation <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8512>
<ijohnson> anybody else seeing github 500s?
<roadmr> launchpad.net is perfectly stable ;)
<cmatsuoka> ijohnson: is it the roadrunner cliff fall error page?
<ijohnson> cmatsuoka: yes
<cmatsuoka> ijohnson: saw it a couple of days ago but not today
<mvo> ijohnson: ssame error, also pushing is very unhappy
<ijohnson> yes frustrating
<zyga> github is down?
<zyga> I was trying to push a patch I wrote for libzt while in the car
<zyga> and man
<ijohnson> I dunno if it's down but it's real slow and not working well
<zyga> interestingly I get new IP addresses for each git push
<zyga> maybe they are scrambling to deploy
<zyga> "minor service outage"
<zyga> oh well
 * zyga looks through the window instead
<cmatsuoka> maybe with the lockdowns everyone got bored and started to use github
<zyga> maybe they did their planned outage testing but nobody was home ;)
<pstolowski> i'm getting weird failures with GC ^on spread prepare
<zyga> the day that azure, gce and aws died ;)
<roadmr> :(
<cmatsuoka> ijohnson: unicorn error page for me now
<ijohnson> yeah I can't get to any real page now, it's just the cliff or a unicorn
<roadmr> or a clifficorn
<cmatsuoka> that would be scary!
<pstolowski> anyone with rhel or centos to try https://bugs.launchpad.net/snapd/+bug/1872368 (but docker may play a role in this)?
<mup> Bug #1872368: Cannot enable snapd.socket in RHEL 7.8 <redhat> <rhel> <systemd> <snapd:Triaged> <https://launchpad.net/bugs/1872368>
<ijohnson> pstolowski: if they are running inside docker then this is 100% not our bug to fix
<pstolowski> ijohnson: thanks for commenting on it!
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#51, core-build#58, core-build#59
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145, core18#151
<mup> PR # opened: core18#43, core18#72, core18#90, core18#126, core18#134, core18#144, core18#146, core18#148
<mup> PR # closed: snapd#5822, snapd#6258, snapd#7129, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7728, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8123, snapd#8143,
<mup> snapd#8247, snapd#8271, snapd#8301, snapd#8317, snapd#8334, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8414, snapd#8424, snapd#8436, snapd#8455, snapd#8464, snapd#8468, snapd#8475, snapd#8496, snapd#8499, snapd#8508, snapd#8512, snapd#8513, snapd#8515,
<mup> snapd#8519, snapd#8520, snapd#8521, snapd#8528, snapd#8530, snapd#8531, snapd#8532, snapd#8533, snapd#8535
<pstolowski> mhm
<cmatsuoka> ijohnson: now it's back, but not reflecting the current repository state
<ijohnson> cmatsuoka: hmm
<mup> PR core20#47 opened: hooks: use explicit /sbin/init to run systemd multi-user.target <Created by anonymouse64> <https://github.com/snapcore/core20/pull/47>
<mvo> pstolowski: fwiw, I updated the core18 initramfs pr and hope to get to zyga pr later tonight
<ijohnson> mvo do you know if https://github.com/snapcore/snapd/pull/8529 has landed in whatever ppa ubuntu-core-initramfs builds from ?
<mup> PR #8529: cmd/snap-bootstrap/initramfs-mounts: support EnvRefExtractedKernelBootloader's <UC20> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8529>
<ijohnson> I thought there was some other ppa that we use when building ubuntu-core-initrmafs
<ijohnson> like snappy-edge or something?
<zyga> Mvo thank you
<zyga> Iâm returning home with additional modem to setup my backup network
<pstolowski> mvo: ty
<mup> PR snapcraft#3070 opened: plugins v2: update plugins so they have a similar behavior <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3070>
<mvo> ijohnson: unfortunately I don't know how the initrd gets the snap-bootstrap, I'm a bit in the dark about this
<mvo> ijohnson: did you figure it out by now?
<ijohnson> mvo: well the ubuntu-core-initramfs debian package is in the snappy image PPA
<ijohnson> but I thought that it got snap-bootstrap from the snapd deb, but the snapd deb it got was from some other PPA
<mvo> ijohnson: :( how does it get to this other ppa?
<ijohnson> mvo: isn't there some other PPA that builds snapd?
 * ijohnson doesn't know and doesn't remember
 * cmatsuoka will try to eat something, bbl
<mvo> ijohnson: there is ubuntu/snappy-dev/edge
 * mvo tries to find the initramfs ppa
 * ijohnson -> lunch 
<ijohnson> mvo ah that's the ppa I think
<mvo> that one should be up-todat
<mvo> e
<mvo> last build there is 5h old
<zyga>  /me is back home
<mup> PR core20#46 opened: static: add new handle_writable_defaults() to handle-writable-paths <Created by mvo5> <https://github.com/snapcore/core20/pull/46>
<mup> PR snapcraft#3071 opened: repo: fix decoding of CalledProcessError output <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3071>
<mup> PR snapcraft#3072 opened: schema: minor tweaks/fixes for package-repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3072>
<mup> PR snapcraft#3073 opened: storeapi: remove strict additionalProperties from store responses <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3073>
<mup> PR core20#47 closed: hooks: use explicit /sbin/init to run systemd multi-user.target <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/core20/pull/47>
<mup> PR snapcraft#3074 opened: specifications: add package-repositories draft spec <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3074>
<mup> PR snapcraft#3070 closed: plugins v2: update plugins so they have a similar behavior <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3070>
<mup> PR snapcraft#3072 closed: schema: minor tweaks/fixes for package-repositories <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3072>
<mup> PR snapcraft#3071 closed: repo: fix decoding of CalledProcessError output <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3071>
<mup> PR snapcraft#3073 closed: storeapi: remove strict additionalProperties from store responses <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3073>
<mup> PR snapd#8536 opened: store,asserts,many: support the new action fetch-assertions <Created by pedronis> <https://github.com/snapcore/snapd/pull/8536>
<mup> PR snapd#8537 opened: store: handle error-list in fetch-assertions results  <Created by pedronis> <https://github.com/snapcore/snapd/pull/8537>
<mup> PR snapcraft#3069 closed: make v2 plugin: make use of make-parameters <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3069>
<mup> PR snapd#8538 opened: overlord: have a variant of Mock that can take a state.State <Created by pedronis> <https://github.com/snapcore/snapd/pull/8538>
<pedronis> ijohnson: ^ 8538 is a small change I had to do locally to experiment with something, in case you wonder, it touches test code but is not used as such in the code base
<ijohnson> pedronis: mmm interesting
<pedronis> ijohnson: I'm going to call it a day
<ijohnson> ttyl pedronis
<mup> PR pc-amd64-gadget#43 closed: Clean up cmdline, after initrd&core land <Created by xnox> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/43>
<mup> Bug #1874156 opened: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1874156>
#snappy 2020-04-22
<mup> PR snapd#8539 opened: tests: update encrypted partition creation test <UC20> <â Blocked> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8539>
<mborzecki> morning
<zyga> Good morning
<zyga> Chilly morning
<mborzecki> zyga: hey, yeah only 6C here
<zyga> Currently outside in shorts
<mborzecki> hahah
<zyga> Is everything red today?
<mborzecki> zyga: idk, looking at uc20 prs only atm
<mborzecki> those are red more often ;) so nothing out of the ordinary
<zyga> Iâm feeling pretty bad today
<zyga> Had some heart issue all evening
<zyga> Hope it passes :/
<mvo> zyga: hey, good morning!
<zyga> Good morning
<zyga> (It passed... away, said the narrator)
<zyga> There are git CVEs
<zyga> Update your systems!
<zyga> Our cloud stuff is up to date
<mup> PR snapd#8538 closed: overlord: have a variant of Mock that can take a state.State <Simple ð> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8538>
<mup> PR snapd#8535 closed: daemon: fix error message from `snap remove-user foo` on classic <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8535>
<mup> PR snapd#8512 closed: boot/bootstate20: add EnvRefExtractedKernelBootloader bootstate20 implementation <UC20> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8512>
<pstolowski> morning
<mvo> good morning pstolowski
<mborzecki> pstolowski: mvo: hey
<mvo> mborzecki: it looks like you are almost happy with 7825? I'm inclinded to merge, the remaining issues looks like cosmetics, or am I missing something in the 4323431 comments in there :) ?
<mvo> mborzecki: and good morning!
<mborzecki> mvo: left some questions for zyga there
<pstolowski> mvo: one last remark about initramfs PR and +1
<pedronis> mborzecki: hi, now that the initramfs changes were incorporated should we try #8464 again?
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mborzecki> pedronis: yes
<mborzecki> pedronis: i'm fixinig one more thing in #8530, installbootConfig for uboot does not look at options
<mup> PR #8530:  boot: enable makeBootable20RunMode for EnvRefExtractedKernel bootloaders <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8530>
<mborzecki> and a missing test probably too
<pedronis> ah
<pedronis> mborzecki: maybe makebootable tests should check for that too
<mborzecki> pedronis: heh, so there's a unit test, but checks the wrong location, looking at ian's plan the agreement was to have $systemseedrootdir/uboot.env
<pedronis> yes
<pedronis> mborzecki: we have code in grub, I suppose uboot needs similar
<mborzecki> pedronis: fixed that already, pushing in a bit
<pedronis> maybe we can reorg a bit the code, not sure, maybe later
<zyga> mborzecki, mvo: yeah, iterating
<mvo> pstolowski: woah, your hunch was right, one more bug found and tests improved, shell is hard
<pstolowski> mvo: oh wow, i didn't expect a bug...
<pstolowski> shell is terrible
<mvo> pstolowski: [ -e ... ] will break on broken symlinks :)
<mvo> pstolowski: or your idea of adding a broken symlink uncovred it
<mvo> pstolowski: I doubt it would actually have hit us for real as the broken-symlink would have to be in the toplevel dir but a bug is a bug
 * mvo hugs pstolowski 
<mborzecki> mvo: we should write in tcl instead :P
<mborzecki> pedronis: pushed a fix to #8530
<mup> PR #8530:  boot: enable makeBootable20RunMode for EnvRefExtractedKernel bootloaders <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8530>
<pedronis> mborzecki: looks good to me
<pstolowski> mvo: right, -e, drat
<mvo> mborzecki: *cough* tcl *cough*
<pstolowski> mvo: i reckon it just became harder to convince you to do initrd version check in shell vs go :}
<mvo> pstolowski: lol
<zyga> just use C, at least you will get *excellent* reviews from jamie :)
<zyga> mvo: one of the workers in canonistack was lost due to btrfs corruption due to disk space exhaustion, remaining workers are moved to a new volume that has more space
<mborzecki> zyga: haha it's still a thing?
<mvo> zyga: in a meeting, will get back to you
<mborzecki> thought this was fixed in btrfs a while ago
<mborzecki> brb, quick errand
<mborzecki> re
<mup> PR snapd#8530 closed:  boot: enable makeBootable20RunMode for EnvRefExtractedKernel bootloaders <UC20> <â  Critical> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8530>
<mup> PR snapd#8540 opened: o/snapstate: tweak "waiting for restart" message <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8540>
<zyga> mborzecki: eh, go-dbus spawns dbus-launch and leaves it running
<zyga> mborzecki: and they pile up
<mborzecki> omg
<zyga> mborzecki: what a terrible idea
<zyga> mborzecki: :|
<zyga> mborzecki: anyway, those -failure tests are sure fun
<zyga> mborzecki: I found one more funny bugg
<zyga> mborzecki: but more in how we use it
<mup> PR snapd#8541 opened: devicestate: add support for cloufg.cfg.d config from the gadget <Created by mvo5> <https://github.com/snapcore/snapd/pull/8541>
<zyga> ok, I have a good understanding of what I need to write for the test
<zyga> I'll take a break to stretch and think about how to write that in one nice test
<zyga> mborzecki: I still have to tackle the leaking dbus-launch, it's such a shame go-dbus doesn't allow one to configure this
<mborzecki> zyga: there's Connect where you can pass address
<mborzecki> zyga: so we could inspect the relevant env/files ourselves
<zyga> mborzecki: yes I know
<zyga> that's unavoidable
<mborzecki> zyga: that's probably all we can do :/
<zyga> just look at the amount of code that is behind SessionBus()
<zyga> until Connect
<zyga> but yeah, I know
<mup> PR snapd#8542 opened: boot: store model model and grade information in modeenv <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8542>
<mup> PR snapd#8543 opened: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8543>
<mborzecki> pedronis_: ^^
<pedronis> mborzecki: reviewed
<pedronis> mborzecki: unit test failure though
<mborzecki> hmmm
<mborzecki> heh, yeah, splitting patches is fun
<mborzecki> w8, actually, there's patches in master that broke the unit tests /o\
<pedronis> mborzecki: can you remind me what mounts boot data etc at install time?
<mborzecki> pedronis: we ask snap-bootstrap to do it by passing --mount
<mborzecki> (along with the rest of create-partitions parameters)
<pedronis> ah, I was looked at the wrong point
<mborzecki> pedronis: partitions are mounted at /run/mnt/<fs-label>
<pedronis> mborzecki: that's interesting, so we override the original tmpfs ubuntu-data ?
<pedronis> mborzecki: we probably really need your PR (for sanity)
<mup> PR snapcraft#3075 opened: Edge staged <do-not-merge> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3075>
<pedronis> mborzecki: some comment son #9543
<pedronis> heh, #8543
<mup> PR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8543>
<jdstrand> xnox: hey, I'm trying to use http://cdimage.ubuntu.com/ubuntu-core/20/edge/20200421/ubuntu-core-20-amd64.img.xz in a vm ,
<jdstrand> xnox: but it isn't working right. 'invalid signature'. is there documenation on how to use it?
<jdstrand> mvo: ^ (I'm trying to do this to test the firewall-control interface (it needs some updates)
<jdstrand> maybe 20200421 was busted
 * jdstrand tries 20200422
<mvo> jdstrand: in a meeting right now, can get back to you
<jdstrand> no, same issue
<jdstrand> mvo: thanks!
<mvo> jdstrand: kvm -m 1500 -snapshot -bios /usr/share/OVMF/OVMF_CODE.fd -drive if=virtio,file=ubuntu-core-20-amd64.img works for me it seems
<jdstrand> mvo: ok, it was the OVMF bit I needed. thanks!
<jdstrand> xnox: nm
<cachio> mvo, I see this error on sbuild test https://paste.ubuntu.com/p/tKrXvmjQDw/
<cachio> I remember you tald you were working on that
<zyga> hey jdstrand, good to see you :)
<mvo> cachio: hm, this one is confusing
<mvo> cachio: no error beside E: Build failure (dpkg-buildpackage died)
<mvo> cachio: is there any debug output or anything?
<pedronis> there are some UC20 milestone 2.45 PRs that needs 2nd reviews
<cachio> mvo, yes https://paste.ubuntu.com/p/HprXqxGS56/
<cachio> mvo, I see similar output
<mvo> cachio: I think we need more + tail -n 100 ./snapd_2.44.3-1_amd64-2020-04-22T13:07:36Z.build
<mvo> cachio: more than 100 lines :(
<mvo> cachio: because the failure is in the unit tests
<cachio> mvo, ok, I'll do that
<cachio> thanks
<mvo> cachio: so we should probably grep FAIL /snapd_2.44.3-1_amd64-2020-04-22T13:07:36Z.build
<mvo> cachio: but the full log is probably best
<cachio> I'll print the full log
<mvo> cachio: thanks
<cachio> mvo, to you
<jdstrand> hey zyga :)
<zyga> jdstrand: those tests are useful, I found some interesting bugs in the cases where it fails
<zyga> jdstrand: more later today, I'm still making it readable/pretty
 * zyga breaks for lunch now 
<zyga> jdstrand: hey, I have a quick idea I wanted to run by you
<zyga> jdstrand: I was thinking about adding an environment variable that lets an application know snapd is tracking it
<zyga> jdstrand: perhaps something like SNAP_$something=tracked
<zyga> jdstrand: it would help in testing but it also might be useful to allow desktop applications that do their fancy pants custom checks to easily know about this and behave in a special way over time
<mup> PR snapcraft#3076 opened: remote-build: fix case where build log url is None <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3076>
<jdstrand> zyga: I'm not opposed to it, but it isn't really needed after it isn't experimental. plus I thought there was going to be an api or something for snaps to query (am I making that up?)
<zyga> jdstrand: there's snapctl based api but not for the sort of thing I'm thinking about
<zyga> jdstrand: it's really mainly for testing
<zyga> jdstrand: right now my test greps for the debug message
<jdstrand> zyga: I wonder if this could be generalized. eg: SNAP_EXPERIMENTAL_FEATURES=refresh-app-awareness
<jdstrand> zyga: so we expose via env what experimental features core has enabled
<zyga> that's interesting but there's a difference, you can have it enabled but it may not really work
<jdstrand> zyga: I might be missing something. I didn't think you would do SNAP_$something=tracking-broken
<zyga> I would do the reverse,
<zyga> SNAP_EXECUTION_ENVIRONMENT=,...,tracked
<zyga> (the name is entirely arbitrary now)
<jdstrand> zyga: or are you saying if the stars are aligned, only then you get 'tracked'?
<zyga> correct
<jdstrand> zyga: considerations the limitations of this, that might make sense, sure
<zyga> I probably won't add it today because I'm kind of set with debug for now but as we go into snapctl territory it might be something that's going to show up in a PR
 * jdstrand nods
<zyga> - Fetch and check assertions for snap "core" (9138) (cannot get device session from store: store server returned status 400 and body "{\"error_list\":[{\"code\":\"invalid-assertion\",\"message\":\"invalid assertion: could not validate model assertion (revision 0 is already the current revision)\"}],\"errors\":[\"invalid assertion: could not validate model assertion (revision 0 is already the current
<zyga> revision)\"],\"result\":\"error\"}\n")
<zyga> I haven't seen this kind of error beore
<zyga> pedronis: ^ just a random spin up of a test that is fixed on a git revision from yesterday
<pedronis> zyga: interesting, that might be a new bug
<mup> PR snapd#8544 opened: interfaces/firewall-control: allow -legacy and -nft for core20 <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8544>
<pedronis> zyga: thanks for spotting this, is likely a real issue
 * cachio afk -> bank
<zyga> pedronis: thank you!
<zyga> I need a second review for test helper code: https://github.com/snapcore/snapd/pull/8515
<mup> PR #8515: testutil: add NewDBusTestConn <Created by zyga> <https://github.com/snapcore/snapd/pull/8515>
<zyga> jdstrand: nice
<zyga> uh so the assertion issue seems to be more serious
<zyga> I guess snaps are busted now
<pstolowski> yeah
<pstolowski> Fetch and check assertions for snap "core" (8935) (cannot get device session from store: store server returned status 400 and body.....
<om26er> https://paste.ubuntu.com/p/xcMfkfwNjZ/
<om26er> I am seeing that inside multipass ^ is that an issue in the backend or my setup ?
<Saviq> om26er: status.snapcraft.io/
<pstolowski> om26er: yeah, store
<Saviq> https://status.snapcraft.io/ even
<roadmr> give it a try now folks :)
<Saviq> yup, works here :)
<om26er> roadmr, thanks works for me too
<roadmr> glad to hear, sorry for the inconvenience
<zyga> roadmr: thank you!
<mup> PR snapcraft#3077 opened: pluginhandler: skip plugin clean_pull for PluginV2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3077>
<mvo> has anyone looked at our tests? it looks like we have a bunch of unhappy runs, is the store a bit unhappy?
<pedronis> mvo: one issue was related to the deploy of the generic serial code, that has been reverted in the store now
<pedronis> it will be fixed and re-deployed
<pedronis> there were more transient store issues as well
<mvo> pedronis: thanks
<pedronis> I don't know if there are other issues
<zyga> error: cannot query the store for updates: got unexpected HTTP status code 503 via POST to "https://api.snapcraft.io/v2/snaps/refresh"
<zyga> roadmr: ^
<zyga> roadmr: is that expected?
<roadmr> zyga: sorry :( we're seeing a lot of load and tweaking things to cope
<zyga> ack, understood
<zyga> man I really need to start using that proxy
<roadmr> :)
<zyga> roadmr: good luck! (to the whole team)
<roadmr> thanks
<mup> Issue core20#48 opened: python3 from base causes segfault for confined snaps <Created by sergiusens> <https://github.com/snapcore/core20/issue/48>
<zyga> jdstrand: ^ is interesting
<zyga> jdstrand: did we miss the whole time64 move>
<zyga> I cannot even think about how many syscalls are involved there :<
<ijohnson> :-(
<zyga> I will soft-EOD and go on a bike ride (we can now)
<zyga> in about 30 minutes
<mup> PR core20#49 opened: fix broken symlinks in /etc/writable <Created by mvo5> <https://github.com/snapcore/core20/pull/49>
<mup> PR snapcraft#3078 opened: meson v2 plugin: ignore any staged python when installing meson <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3078>
<mup> PR snapcraft#3077 closed: pluginhandler: skip plugin clean_pull for PluginV2 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3077>
<mup> PR snapcraft#3079 opened: cli: add plugin help for core20 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3079>
<mup> PR snapd#8544 closed: interfaces/firewall-control: allow -legacy and -nft for core20 <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8544>
<mup> PR snapd#8542 closed: boot: store model model and grade information in modeenv <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8542>
<mup> PR snapd#8540 closed: o/snapstate: tweak "waiting for restart" message <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8540>
<jdstrand> zyga: I'm looking at the seccomp thing. is https://github.com/snapcore/snapd/pull/8496#issuecomment-617993863 something you could do or is that an mvo thing?
<mup> PR #8496: interfaces/apparmor: use differently templated policy for non-core bases <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8496>
<zyga> jdstrand: checking
<zyga> only mvo
<zyga> :/
<jdstrand> ok
<mup> PR snapcraft#3080 opened: repo: fix for multi-arch stage-package scenario <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3080>
<mup> PR snapcraft#3078 closed: meson v2 plugin: ignore any staged python when installing meson <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3078>
<mup> PR snapd#8545 opened: cmd/snap-bootstrap/initramfs-mounts: mount ubuntu-seed first, other misc changes <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8545>
<ijohnson> pedronis: cmatsuoka: opened ^
<cmatsuoka> ijohnson: great, thanks!
<mup> PR snapcraft#3081 opened: make v2 plugin: also pass make-parameters to install <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3081>
<mup> PR snapd#8546 opened: seccomp: add get_tls, io_pg* and *time64/*64 variants for existing syscalls <â  Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8546>
<mup> PR snapcraft#3079 closed: cli: add plugin help for core20 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3079>
<mup> PR snapcraft#3082 opened: cli: add list-plugins for core20 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3082>
<mup> PR snapcraft#3076 closed: remote-build: fix case where build log url is None <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3076>
<mup> PR snapcraft#3081 closed: make v2 plugin: also pass make-parameters to install <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3081>
<mup> PR snapd#8545 closed: cmd/snap-bootstrap/initramfs-mounts: mount ubuntu-seed first, other misc changes <UC20> <â  Critical> <Created by anonymouse64> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/8545>
<mup> PR snapcraft#3082 closed: cli: add list-plugins for core20 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3082>
<mup> PR snapcraft#3080 closed: repo: fix for multi-arch stage-package scenario <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3080>
<cmatsuoka> ijohnson: I landed your PR and merged master back to the lock access PR, refactoring some common parts in the process
<cmatsuoka> ijohnson: you may want to verify if it looks correct
<cmatsuoka> ijohnson: will push soon
<ijohnson> Thanks cmatsuoka I'll take a look in a bit
<cmatsuoka> ijohnson: I'm just creating an image here to make sure it still boots
<cmatsuoka> yep, it does
<cmatsuoka> oops, some merge errors
<mup> PR snapcraft#3075 closed: Edge staged <do-not-merge> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3075>
<cmatsuoka> ijohnson: will be afk for 20min or so, feel free to push to that PR if you feel necessary
#snappy 2020-04-23
<zyga> o/
<zyga> good morning
 * zyga tracks a small anomaly
<zyga> in other news everything is hard
<mborzecki> morning
<zyga> hey
<zyga> somehow 16.04 can do things 18.04 cannot
<zyga> I think I just learned something new
<zyga> session startup, you'd think stuff would wait
<zyga> mborzecki: how are you feeling today?
<mborzecki> zyga: meh, tired, i should go for a bike ride or sth
<zyga> yeah
<zyga> I feel the same
<zyga> but also this damn allergy
<zyga> I need to go to a pharmacy today
<zyga> heh
<zyga> I think I start to understand
<mup> PR snapd#8546 closed: seccomp: add get_tls, io_pg* and *time64/*64 variants for existing syscalls <â  Critical> <Created by jdstrand> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8546>
<zyga> So we will have another point release
<zyga> ok, breakfast and one more patch
<zyga> and it is ready
<mup> PR snapd#8496 closed: interfaces/apparmor: use differently templated policy for non-core bases <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8496>
<mborzecki> mvo: hey, can you take a look at https://github.com/snapcore/snapd/pull/8543 ?
<mup> PR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8543>
<mvo> mborzecki: sure
<pstolowski> morning
<mvo> pstolowski: good morning
<mvo> happy release day
<pstolowski> ha, likewise :)
<pedronis> mborzecki: mvo: hi, #8513 needs another review
<mup> PR #8513: snap-bootstrap: lock access to sealed keys <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8513>
<mborzecki> pedronis: i'll take a look
<mborzecki> looks like uboot.env is still a mess
<pedronis> mborzecki: in which sense?
<mborzecki> pedronis: looking at ijohnson's standup notes, he wrotne we cannot have /uboot.env (?)
<pedronis> mborzecki: yes, it's complicated, but we have a plan
<mvo> pedronis: yeah, saw your push there, thanks for this
<mborzecki> pedronis: i see, /uboot/ubuntu/uboot.sel, should be rather simple, i can work on a pr
<pedronis> mborzecki: mvo: I think we should try to finish the tpm stuff
<mvo> +1
<mborzecki> ok
<pedronis> mborzecki: I think Ian's might have work in progress on the uboot stuff
<pedronis> not sure
<pedronis> mborzecki: mvo: now secboot should have all the helpers we need
<pedronis> mborzecki: #8464 is still not working, right?
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mborzecki> pedronis: yeah, i see some wip commits with /uboot/ubuntu in one of the new branches in ian's repo
<mup> PR snapd#8543 closed: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8543>
<mborzecki> yay
<mborzecki> btw. have you guys noticed that there's like 2-3 emails when tests finish per pr now?
<pedronis> yes, we something fails
<pedronis> s/we/if/
<pedronis> mborzecki: actually, you didn't push master to #8464 again yet? it has conflicts atm btw
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mborzecki> pedronis: heh, right, i merged and fixed conflicts yesterday but forgot to push
<mborzecki> pedronis: anyways, ther's new conflicts to fix today
<pedronis> there might be more conflicts now
<pedronis> mvo: have you played with calling bootstrap.Run directly ? we need to decide what to do with #8531
<mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
<mvo> pedronis: I did, I can create a proper pr, the most simple version that just moved bootstrap.run into overlord and leave strange imports is very small
<pedronis> mvo: we have the spread tests though
<mvo> pedronis: right, we could build the needed command for testing in the spread test
<pedronis> yea, that sounds reasonable
<mvo> I can poke at this now, I just did half a review of 8513 but this PR seems equally important
<pedronis> mvo: please finish 8513
<pedronis> it's kind of hard to progress on that side before it is in
<pedronis> because of code placement questions
<mvo> pedronis: https://paste.ubuntu.com/p/yr8zqHPyqK/ is the absolute minimium without tests to call run directly
<mvo> pedronis: sure, will do the 8513 now
<pedronis> mvo: that looks reasonable, we'll need a way to mock it
<pedronis> instead of the command as we do now
<mvo> pedronis: yeah, that should be easy as it's pratcially the same as the commdnline
<mvo> pedronis: but yeah, will work on it right after 8513 - should I try to move the imports too ?
<pedronis> mvo: no, not right now, we have both boostrap and partition to deal with, and I'm not sure what to do exactly atm
<mvo> ok
<zyga> is master green now (is it worth merging master to unstuck PRs)?
<pedronis> zyga: i'ts better but still lots of weird failure, I just got failures on amazon linux, not sure about what
<mborzecki> can we trim the standup doc? it's 148p long atm
<ijohnson> hey folks
<ijohnson> mborzecki: I see you found my wip branch for "text" ubootenv stuff, are you working on that now? I think it was mostly there except for tests and some changes to bootloader.Find sprinkled around
<mborzecki> ijohnson: no, looking at some PRs atm
<ijohnson> mborzecki: ok I will finish that up now then
<mvo> ijohnson: good morning! isn't it like terrible early?
<ijohnson> good morning mvo
<ijohnson> it is fairly early yes, but I didn't finish everything yesterday so I wanted to wrap it up now
<ijohnson> it's a bit quieter in the house now :-)
 * mvo hugs ijohnson 
<mvo> ijohnson: woah!
<mvo> ijohnson: thanks so much!
<mborzecki> pedronis: i suppose next step is adding MeasureSnapModelToTPM for run mode?
<mborzecki> and https://github.com/snapcore/snapd/pull/8531 ?
<mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
<pedronis> mborzecki: yes, but we need the lock keys one landed to have a place for the first thing
<pedronis> mborzecki: also we need to write model to modeenv still, right?
<mborzecki> pedronis: this landed already
<mborzecki> pedronis:  i mean model to modeenv
<pedronis> mborzecki: really ?
<pedronis> I'm confused
<mborzecki> pedronis: hm both #8542 #8543 landed
<mup> PR #8542: boot: store model model and grade information in modeenv <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8542>
<mup> PR #8543: overlord/devicestate: preserve the current model inside ubuntu-boot <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8543>
<mborzecki> i think we should have everything we need now
<mborzecki> zyga: hey, can you take a look at https://github.com/snapcore/snapd/pull/8520/checks?check_run_id=611343459 wth happened there?
<mup> PR snapd#8513 closed: snap-bootstrap: lock access to sealed keys <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8513>
<mup> PR #8520: data: fix shellcheck warnings in snapd.sh.in <Created by jelovac> <https://github.com/snapcore/snapd/pull/8520>
<zyga> sure, looking
<zyga> mborzecki: I think jamesh knows this issue
<zyga> mborzecki: the check is wrong, it assumes a specific history
<mborzecki> why isn't gh actions merging the branch to master or master to the branch?
<zyga> jamesh: ^ can you explain what's the problem with the CLA check
<zyga> the action checks out the code as is
<zyga> the cla check workflow is different as it gets more history IIRC
<jamesh> zyga, mborzecki: I think the problem is that the revision under test is a merge that allows fast forwards.  So the assumption that it has two parents is wrong
<zyga> mborzecki: we could code an action that merges first
<jamesh> in the fast forward case, we can't determine the base revision from the head revision
<mborzecki> jamesh: i have this pr open: https://github.com/snapcore/snapd/pull/8455 maybe you know the proper way to pass the commit range from github context
<mup> PR #8455: tests/lib/cla_check: expect explicit commit range <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
<jamesh> mborzecki: I think we'd need an additional step to fetch the github.base_ref branch into the local repo
<zyga> mborzecki: did MATCH NOT get merged?
<mborzecki> zyga: hm?
<zyga> jamesh: the checkout action has some options
<zyga> jamesh: perhaps we could use something it already offers
<zyga> mborzecki: the spread MATCH extension you proposed
<mborzecki> idk
<mborzecki> zyga: i think someone else proposed that
<zyga> ah
<zyga> it's NOMATCH
<zyga> thanks !
<jamesh> mborzecki: I've added a comment to your PR with a possible solution
<mborzecki> jamesh: thanks, let me check that
<mborzecki> zyga: jamesh: btw the checkout action does something weird, in one PR it's doing: `/usr/bin/git checkout --progress --force refs/remotes/pull/8455/merge`, in one from a contributor it does `/usr/bin/git checkout --progress --force -B master refs/remotes/origin/master`
<mborzecki> in the first case it's using that magical ref that github has for 'merged' PR
<mborzecki> no clue why it's not used in the 2nd case
<jamesh> mborzecki: check the source maybe?
<jamesh> mborzecki: looks like it treats "refs/heads/**" references different to "refs/pull/**" ones: https://github.com/actions/checkout/blob/master/src/ref-helper.ts#L29
<mborzecki> jamesh: heh, that's what, the magic happens here i'm doing https://github.com/actions/checkout/blob/master/src/ref-helper.ts#L8-L58
<mborzecki> ah, so we're reading the same code ;)
<mborzecki> anyways, more important stuff to deal with atm :/
<mborzecki> https://news.ycombinator.com/item?id=22953506 quite a bit of comments from people not so happy about snaps
<jamesh> Just tell them that snapd is written in Lisp.   Then they'll love it
<zyga> and it's a lisp VM implementing haskel
<zyga> then they will die with a smile on their faces
<jamesh> snapd has all of the parentheses
<mborzecki> all you parens belong to us
<zyga> on the upside, all my tests now pass on core and classic
<zyga> and I found something I don't know the answer for yet
<zyga> jdstrand: app tracking works on 16.04, doesn't work on 18.04 (for the non-root user) - I presume it is the kernel version responsible
<zyga> jdstrand: and that 18.04 kernel has the extra hardening on cgroups that 16.04 lacks
<zyga> mborzecki: I replied to some comments there, it's not that negative actually
<zyga> (and for context, it works on 16.04+ but in the desktop session)
<zyga> my comment was not about the desktop session
<mup> PR snapd#8547 opened: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<zyga> jamesh: FYI, core-* doesn't have dbus.socket for users
<zyga> jamesh: perhaps it should?
<zyga> it kind of cripples user sessions
<mvo> pedronis: 8547 is the minimal move we talked about for snap-bootstrap create-paritions, I look at the tests now
<mvo> (spread tests)
<pedronis> mvo: thanks, afk for a bit, but I will look soon
<mup> PR snapd#8548 opened: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>
<pedronis> mvo: thank you, did a pass on #8547, some small comments
<mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<mup> PR snapcraft#3083 opened: repo: revert logic to get deb_arch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3083>
<pedronis> mborzecki: thanks, some comments on #8548, a comment got messed up there
<mup> PR #8548: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>
<zyga> mvo: can you merge 8515 please
<caribou> Hello everyone, I'm hitting a rather peculiar situation with snapd initialization on first boot from a Focal Ubuntu Cloud Image.
<caribou> If I copy files in /usr/local/bin in the QCOW2 prior to booting, everything works fine. If I untar the same files in the images, snapd is unable to complete its seeding
<zyga> caribou: can you please share the state of the system when snapd tries to seed
<zyga> but also this is not the best moment, everyone is swamped with work :/
<caribou> zyga: very first boot off a slightly modified UCI
<jamesh> zyga: perhaps, but 16.04 classic also doesn't ship those units (it has the session bus managed by a user instance of Upstart)
<caribou> zyga: I'm aware of that
<zyga> jamesh: indeed
<caribou> so don't hesite to overlook the request for now
<jamesh> zyga: it would be pretty easy to add to core (install dbus-user-session), but it might not be worth it.
<zyga> jamesh: FYI, I pushed this test
<zyga> https://github.com/snapcore/snapd/pull/7825/files#diff-61f3c400c3c80345d518c7ff0d0b3953R1
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> jamesh: this feature is really really really hairy
<zyga> "what could go wrong" :|
<zyga> I will run a smoke test to see what happens if it's on by default
<caribou> zyga: don't bother with my request, I'm working on figuring out a workaround. I'll come back on calmer days :)
<zyga> ok
<zyga> caribou: sorry and thank you for understanding
<jamesh> zyga: I doubt it would break anything: it would have zero effect on classic systems, and I doubt anyone starts systemd user sessions on Ubuntu Core 16 devices
<zyga> I agree
<mborzecki> is vendor.json showing up as modified for you guys, despite calling govendor sync?
<mborzecki> it's like govendor does not know about git reset or sth
<zyga> mborzecki: nope?
<zyga> what does it show
<jamesh> zyga: looking at that spread test, is the plan to continue using adding processes to the freezer cgroup on v1 systems?
<zyga> yes because that is done for different reasons (mount raciness)
<zyga> though we could probably invest in the new mount APIs at some point
<zyga> where we could drop that
<jamesh> zyga: so I guess the check would be to look for the substring "/snap." in the empty and name=systemd cgroups, or starting with "/snap."  in freezer cgroup?
<zyga> mmm, sorry, got distracted
<zyga> can you expand on this?
<jamesh> zyga: this is for a quick "is this process a snap?" check
<zyga> ahhh
<zyga> yes
<zyga> I will send a small patch here to reverse the UUID and security tag bits
<zyga> as jamie asked for that and I think -- at this point -- this branch can take anything
<jamesh> could I skip the name=systemd group?
<jamesh> or would it be good to continue including that?
<zyga> I would not skip it, you should look at freezer (on v1), at name=systemd or at v2 pure cgroup,
<zyga> either freezer or pure v2 will always be reliable
<jamesh> right.  That's why I was wondering if I could ignore name=systemd
<zyga> ah, I see
<zyga> I guess... yeah
<zyga> but I would check all three
<zyga> until phase out of v1 is more better understood
<zyga> in case there's a future window where freezer is gone
<zyga> but we are still on v1
<jamesh> fair enough.
<jamesh> including all three is not much of a problem
<mup> PR snapd#8549 opened: tests: fix a typo in nested.sh helper <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8549>
<mup> PR snapd#8515 closed: testutil: add NewDBusTestConn <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8515>
<zyga> ta!
<ijohnson> pedronis: so I have the ubootenv + bootloader changes finished with tests (still need full system test on my pi which I will do in a moment), do you want me to split it up to propose just the "text" format support, then a followup using that format, or shall I just bundle them all together?
<zyga> brb, neet to stretch back
<zyga> the full run of refresh-app-awareness enabled by default is progressing and seems to be all good for now (fingers crossed)
<zyga> I don't anticipate anything specific but I wanted to give it some broader check, even if it's disabled now
<pedronis> ijohnson: how big it the diff?
<ijohnson> 461 lines added, 334 removed
<ijohnson> pedronis: ^
<pedronis> ijohnson: seems fine as one PR, unless you think some bits are potential controversial
<pedronis> mborzecki: I have govendor messing with vendor.json too, I didn't dig though
<ijohnson> pedronis: mmm my ubootenv changes could be contraversial but hell let's give it a shot I'll open it all in 1 PR, give me a moment
<mborzecki> pedronis: does git diff show that checksumSHA1 is changed in your system too?
<mborzecki> (in vendor.json file)
<pedronis> mborzecki: yes
<pedronis> mborzecki: for secboot and x/sys/unix
<mborzecki> pedronis: yup, same here
<mup> PR snapd#8550 opened: ubootenv, uboot: support new uc20 style text bootenv <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8550>
<ijohnson> pedronis: opened at ^
<mborzecki> maybe they changed what goes into the checksum
 * ijohnson takes a break for a bit
<pedronis> mborzecki: what does govendor --version prints for you?
<mborzecki> oh and https://github.com/kardianos/govendor is marked as archived
<mborzecki> pedronis: 1.0.9
<pedronis> same
<pedronis> yea, we should move to modules but need to consider when
<pedronis> it terms of options and go we need to support
<pedronis> ijohnson: can you set milestone 2.45, that's the way we/I track beta (UC20+2.45)
<ijohnson> pedronis: sure
<pedronis> ijohnson: thx, its in my queue now, I'll look in a bit, kind of finishing lunch break
<pedronis> *it's
<pedronis> mvo: good news #8547 passed on core 20 but lots of "random" red
<mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<mvo> pedronis: good and bad
<mvo> pedronis: I will address your point in a wee bit, just pushed the test update
<mup> PR snapd#8551 opened: snap-bootstrap: remove create-partitions and update tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/8551>
<pedronis> mvo: actually is not random
<pedronis> mvo: we have the issues of build on any distro but ubuntu
<pedronis> we need the nosecboot tags
<pedronis> used properly for this
<pedronis> mvo: snap-boostrap was built only on ubuntu, but of course snapd is built everywhere
<pedronis> mvo: do you need help with that?
<mvo> pedronis: uh, yes please
<mvo> pedronis: that will be a bit annyonig and I need to get lunch in a wee bit
<pedronis> mvo: I'll see what I can do there
<mborzecki> hm maybe we shouldn't build s-b on non ubuntu at all and skip the tests that fail?
<mvo> pedronis: thank you!
<pedronis> mborzecki: we don't build s-b, on non-ubuntu, but mvo has moved a bunch of it inside snapd
<pedronis> now
<pedronis> that's the issue
<pedronis> I'll work on it
<pedronis> mvo: not at simple as adding tags, there is something else going on with the build
<pedronis> blargh, we rm  cmd/snap-bootstrap in some build
<mup> PR snapd#8548 closed: cmd/snap-bootstrap: cleanups, naming tweaks <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8548>
<mup> PR snapcraft#3083 closed: repo: revert logic to get deb_arch <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3083>
<pedronis> ijohnson: have you forgotten to add some files?  I see a openNativeFormat that is not defined
<pedronis> ijohnson: I also if possible would try to minize the diff
<pedronis> of env.go, it's fairly unreadable atm
<pedronis> mvo: I pushed fixes for fedora etc, but debian is a bit messy and needs more work
<mvo> pedronis: ok, I have a look
<pedronis> mvo: I'm actually trying a fix, maybe it works
<jdstrand> zyga: I tested it on 18.04 and saw that the scope was being created and pids added to it?!?
<zyga> jdstrand: hey!
<jdstrand> zyga: note, my testing was done via terminal cli commands and not things launched from a desktop file, but that shouldn't matter
<zyga> jdstrand: I just pushed a little bit of an update that adds some more explanation
<jdstrand> zyga: hey :)
<zyga> jdstrand: how do you like the -failure test?
<zyga> jdstrand: please check the new pair of XXX comments starting at https://github.com/snapcore/snapd/pull/7825/files#diff-61f3c400c3c80345d518c7ff0d0b3953R184
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> jdstrand: I will take the deb and play with it on VMs representing each desktop and server
<zyga> jdstrand: I also did an experiment to see what would happen to our test suite if this was enabled out of the box, the results were interesting, there were some failures but they are all legitimate change in behavior (we refuse to refresh or install snaps while there are apps running)
<jdstrand> zyga: I've not looked at it yet. I've got several meetings this morning but will look at this today. I'll try to peek now real quick
<zyga> jdstrand: nothing failed in ways that would not be sensible IMO
<zyga> jdstrand: thank you!
<jdstrand> zyga: that's cool :)
<zyga> jdstrand: just two theories, I'll explore this interactively now
<zyga> jdstrand: I _hope_ it will be green and I can merge it
<zyga> I have some follow ups to do
<jdstrand> zyga: ahhh! you weren't talking about new failures (phew), you were talking about explaining the existing failure
<zyga> yes!
 * jdstrand gives a sigh of relief
<jdstrand> zyga: my whole body tensed up for a second ;)
<oSoMoN> pedronis, can you hide/delete an offensive bug comment? https://bugs.launchpad.net/snapd/+bug/1776873/comments/39
<mup> Bug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>
<pedronis> oSoMoN: not afaik,  mvo do you know ^
<jdstrand> zyga: imho, you could land the PR with the cgroup-tracking-failure as a followup. based on what you said about wanting understand all of this before updating features.go for what is supported/not supported at this time, that could also be in the same followup. I'll leave that up to you
<jdstrand> but yes, I'll be looking at this today
<pedronis> mvo: seems I fixed debian too, the fix is ugly but is like the code already there
<mvo> oSoMoN: I'm afaraid not, I guess someone in #launchpad might be able to help
<mvo> pedronis: removing files?
<pedronis> yes
<oSoMoN> pedronis, mvo:Â IÂ asked there first, and c_j_watson suggested that being the project bug supervisor, you have powers to do that yourself
<jdstrand> zyga: Conversation: 201. Commits: 123. Files changed: 25. Impressive! (7825)
<mvo> pedronis: it's all because of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956783
<mvo> oSoMoN: oh, let me try to figure out how then, I never used that feature
<oSoMoN> mvo, pedronis is the project bug supervisor, so IÂ guess only him can do that
<mvo> oSoMoN: aha, ok - I was wondering, I can't see the right button :)
 * zyga runs to check some family hurdle at home
<pedronis> mvo: https://paste.ubuntu.com/p/CPvpyJQnjV/ is the diff, good enough?
<mvo> pedronis: totally
<pedronis> oSoMoN: I don't see any button either
<pedronis> I'm maybe looking at the wrong place
<mvo> pedronis: push away
<oSoMoN> cjwatson, can you advise how to hide a comment for a project bug supervisor? ^
<cjwatson> pedronis: There should be a green "Hide" button at the bottom right of the comment
<cjwatson> pedronis: Oh, but you need to look at https://bugs.launchpad.net/snapd/+bug/1776873, not on the /comments/39 page
<mup> Bug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>
<cjwatson> (I'm suggesting that it be hide + explicit warning to user, btw)
<pedronis> cjwatson: not seeing green buttons either place
<cjwatson> Ugh
<cjwatson> Well, if I hide it could you warn them?
<cjwatson> Some kind of code of conduct warning
<cjwatson> I've hidden it now
<pedronis> cjwatson: you mean in the bug comments, or over email? (sorry my brain is very partionated in its capabilities today)
<cjwatson> In the bug comments
<pedronis> ok
<cjwatson> That would be my suggestion anyway, since the bug comment will have been emailed to subscribers
<cjwatson> And it's good to be public about what the societal expectations are
<jdstrand> mvo: thank you for merging the base policy PR :)
<jdstrand> and thanks to all for the reviews :)
<mup> PR snapd#8552 opened: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
<jdstrand> mvo: I don't know if you are doing another 2.44 point release (thought I saw that in reference to my syscalls PR), but if so, can you also cherry-pick https://github.com/snapcore/snapd/pull/8544 ?
<cmatsuoka> cachio: is the uc20 test working now?
<mup> PR #8544: interfaces/firewall-control: allow -legacy and -nft for core20 <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8544>
<mvo> jdstrand: we don't plan another 2.44 but happy to cherrypick just in case
<jdstrand> mvo: ack, thanks again :)
<cachio> cmatsuoka, I am running right now
<pedronis> mvo: I pushed btw
<pedronis> mborzecki: thanks, can you mark that PR UC20 and 2.45
<mborzecki> ah forgot
<abeato> sil2100, hey, I was wondering, do you have an example on how the --cloud-init option in u-i can be used? what would it be used for?
<mvo> pedronis: \o/
<oSoMoN> cjwatson, pedronis:Â thanks for handling this
 * ijohnson pedronis: sorry I forgot to commit those files, added them to the PR now
<mup> PR # opened: snapd#5822, snapd#6258, snapd#7129, snapd#7168, snapd#7205, snapd#7414, snapd#7417, snapd#7436, snapd#7570, snapd#7586, snapd#7590, snapd#7603, snapd#7614, snapd#7700, snapd#7728, snapd#7825, snapd#7869, snapd#7900, snapd#7927, snapd#7982, snapd#8079, snapd#8123, snapd#8143,
<mup> snapd#8247, snapd#8271, snapd#8301, snapd#8317, snapd#8334, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8414, snapd#8424, snapd#8436, snapd#8455, snapd#8464, snapd#8468, snapd#8475, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8528,
<mup> snapd#8531, snapd#8532, snapd#8533, snapd#8536, snapd#8537, snapd#8539, snapd#8541, snapd#8547, snapd#8549, snapd#8550, snapd#8551, snapd#8552
<mup> Issue # opened: core20#12, core20#32, core20#34, core20#48
<mup> PR # opened: core20#11, core20#43, core20#45, core20#46, core20#49
<ogra> ah, it isnt only me having issues with github today ...
 * ogra hugs mup 
<stgraber> anyone has an idea of what's going on here? https://discuss.linuxcontainers.org/t/snap-lxd-snap-hooks-configure-snapctl-not-found/7525
 * ogra shakes fist towards github and goes to take a break .... too many gateway timeouts :(
<ogra> stgraber, smells like a bug in the archlinux package or so ...
<mborzecki> stgraber: replied in the snapcraft forum topic
<ogra> who is doing the snap translations ? i noticed in focal i actually get german strings but they often look/feel like google translation ones
<ogra> s/snap/snapd/
<zyga> ogra: anyone can
<ogra> heh ... well i was wondring "who does" :)
<zyga> there are no curated translations that we merge back to snapd
<zyga> ogra: my point is that nobody curates this
<ogra> right, so it isnt going through rosetta (launchpad) as all our other translations (which get peer reviews)
<ogra> i'm just noticing it shows ...
<zyga> I think it does
<zyga> but we never merge them to snapd, verify, alter or anything
<zyga> we have 0% translations in tree
<zyga> but actually
<zyga> you gave me a crazy idea
<zyga> gettext that google-translates each string
<zyga> MASHIN LERNIN ;)
<ogra> yeah, that will surely improve the quality !
<zyga> and consistency ;)
<ogra> but i think it should be a two step thing ... first translate to xhosa ... then to the target language ...
<ogra> that definitely gets the funnier outcome
<pstolowski> cachio: can you take a look at https://github.com/snapcore/snapd/pull/8549 ?
<cachio> pstolowski, sure
<zyga> ##[warning]Failed to download action 'https://api.github.com/repos/actions/checkout/tarball/v2'. Error Response status code does not indicate success: 500 (Internal Server Error).
<zyga> must be a good day to release
<ogra> yeah GH is stuttery today
<ogra> it is intermittent though ... so restarting the build/test/whatever eventually works
<ogra> i havent seen a 500 yet though ... only lots of 504's
<ogra> (GW timeout)
 * zyga breaks for some time then
<zyga> jdstrand: I have a patch piled that reverses the UUID as you wanted
<zyga> jdstrand: but I will not send it to this branch, it's extra huge already
<zyga> jdstrand: I'll start piling fixes, tests and stuff into a new one
<mup> PR # closed: core#38, core#107, core#108, core#110, core#111
<mup> PR # opened: core#38, core#107, core#108, core#110, core#111
<pedronis> mvo: can you work more on #8547 or should cmatsuoka pick it up? either way maybe cmatsuoka can review it
<mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<cachio> xnox, I see these errors on uc20 https://paste.ubuntu.com/p/SKBqVNyyMN/
<cachio> xnox, lines 693 and 1340
<cachio> xnox, it could be related to the removal of the snapd-shutdown helper
<cachio> xnox, could you please take a quick look?
<jdstrand> zyga: sounds great
<mvo> pedronis: I'm not working on it right now, I think you raised some points that still need adressing. I can probably work on those in a couple of minutes, just de-conflicting 8541
<mvo> pedronis: either way is fine, I need to take a 15min break now though
<cmatsuoka> fyi I just built an image from that branch and partitions are created correctly
<xnox> cachio:  they are not errors
<xnox> cachio:  it's confirmation that finalrd is doing the shutdown correctly
<xnox> cachio:  and that the bad snapd shutdown hook is correctly disabled
<cmatsuoka> mvo: and ssh works
<cachio> xnox, ok, thanks
<cachio> cmatsuoka, I see this message in the log Please enter the recovery key for disk /dev/disk/by-label/ubuntu-data-enc: (press TAB for no echo)
<cmatsuoka> cachio: you shouldn't see that, let me try to reproduce here...
<pedronis> cmatsuoka: great, please do a review of the PR itself
<ijohnson> pedronis: I added a response to your point on my ubootenv PR re Recovery in InstallBootConfig, it does mean something different but we don't currently have a real use case for that yet so I could just drop that tbh
<cmatsuoka> pedronis: already did a pass, it seems that there are many things to do to have it done properly but functionally it works, will add some notes there
<pedronis> ijohnson: the issue is that afaik we might still have to write a boot.sel or not
<pedronis> we don't know, depends what's inside that uboot.env
<ijohnson> pedronis: good point, I think that ideally we should still write a boot.sel in this case in addition to the uboot.env from the gadget we install
<pedronis> ijohnson: it might be easier if we don't have a use case to return an error for now, and do something when we have a use case
<cachio> cmatsuoka, if you run spread -debug google-nested:ubuntu-20.04-64:tests/nested/core20/
<cachio> you will see that
<ijohnson> pedronis: sure that would be easiest
<cachio> once the test fails
<ijohnson> pedronis: also I forgot to write this in the PR I think, but we still have a need for the gadget.yaml in the 20 pi snap to install boot.sel onto ubuntu-boot, because otherwise bootloader.Find() in makeBootable20RunMode won't recognize any uboot bootloader on ubuntu-boot
<ijohnson> pedronis: I think that's fine, it's pretty similar to what we do for grub too, but it's a bit unexpected / weird given that snapd writes the file for ubuntu-seed, but the gadget has to create the file for ubuntu-boot
<ijohnson> pedronis: I wasn't sure how better to handle it though without adding methods to the bootloader interface somehow
<pedronis> ijohnson: yes, I think we are a bit carrying on with legacy logic
<ijohnson> yeah
<pedronis> ijohnson: in a sense we should pick a bootloader kind based on seed and apply it to boot
<ijohnson> mmm that's a good idea
<pedronis> but it might not be the right time to change
<pedronis> I mean, for sure not in that PR
<ijohnson> agreed now is not the right time to do this change
<ijohnson> pedronis: do you think it's fine for beta to have the gadget snap install boot.sel onto ubuntu-boot ?
<pedronis> ijohnson: it's ok, but it sound weird at face value, but let's get everything else working first
<ijohnson> ack
<cmatsuoka> cachio: running it
<cachio> cmatsuoka, nice
<cachio> I am having lunch now
<cmatsuoka> cachio: ok, I'll leave comments here if I find something
<pedronis> ijohnson: I understand the cleanliness of introducing nativeenv.go, but I think it would be maybe quicker to do just have env.go with the interface at the top and trying to keep as much of the rest as possible and textenv and do the splitting in a 2nd PR
<ijohnson> pedronis: you mean just puteverything in the same file?
<pedronis> ijohnson: no, have two files
<pedronis> keep most of env , and Env there
<pedronis> have the new stuff in textenv.go
<ijohnson> ah ok
<ijohnson> sure I can do that, give me a bit though trying to get this pi test running, needs a bit of hand holding
<pedronis> ijohnson: at the moment the diff of env.go is horrible, and nativenv.go is kind look I need to review code tha is actually old code
<ijohnson> I see
<pedronis> ijohnson: in general in this kind of situation is best to either do splitting before (if possible) and/or minimize the diff, and do renames or splits as a separate step
 * cachio lunch
<mvo> pedronis: when you have a moment, is https://github.com/snapcore/snapd/pull/8547#discussion_r413680649 what you have in mind?
<mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<pedronis> mvo: I would say no
<mvo> pedronis: ok, it did not feel right so I wanted to ask, what am I missing ?
<mvo> (and sorry to burden you with this :(
<pedronis> mvo: have you done more in that PR or just started there?
<mvo> pedronis: I updated the other bits, let me push
<mvo> pedronis: the other comments where clear, this one I had a bit of trouble
<pedronis> mvo: something like this https://paste.ubuntu.com/p/xyRmBhjwrX/  (the other change is optional)
<mvo> pedronis: aha, I see. feel free to commit, I have a meeting now, otherwise I will commit when the meeting is done
<pedronis> mvo: pushed
<mvo> pedronis: thanks!
<cmatsuoka> cachio: it failed here in a NOMATCH line in core20/basic/task.yaml (which should now be a not MATCH I believe) but otherwise it seemed to run ok. I'll break for lunch now and bbl
<cachio> cmatsuoka, in that case it was fixed with a new pc-kernel or gadget
<cachio> cmatsuoka, thanks
<pedronis> cmatsuoka: so we should base #8531 on #8547 now, Options should contain directly a Model *asserts.Model ... the command can take a --model <model> and read it
<mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
<mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<cmatsuoka> pedronis: ack, will do that after lunch
<pedronis> cmatsuoka: thank you
<pedronis> cmatsuoka: asserts.Decode can be used to make an assertion out of []byte, then you can check the Type() and then cast
<mup> PR snapd#8541 closed: devicestate: add support for cloud.cfg.d config from the gadget <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8541>
<pedronis> so #8464 failed on core 20 still
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<pedronis> we are also having failures because of GH atm
<mup> PR snapd#8553 opened: github: use "continue-on-error" for the spread-unstable systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/8553>
<mvo> zyga: did the bit-cacher got restarted? I guess there were some restarts since this was last installed :/
<mup> PR snapd#8549 closed: tests: fix a typo in nested.sh helper <Simple ð> <Skip spread> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8549>
<zyga> mvo: yes, I rebooted the system once since installation
<zyga> We maybe basic persistency?
<mvo> zyga: maybe, given that the cache fix is on the usptream radar, maybe it's not urgent
 * mvo gets dinner - please let me know if there is anything I should merge
 * mvo will read backlog
<ijohnson> pedronis: I did as requested in 8550 and disabled for now the traditional uboot.env that we don't have clear idea on yet, and I also move nativeenv.go back into env.go
<cmatsuoka> pedronis: thanks, will use that
<pedronis> ijohnson: did we lose import tests for native ? or am I confused by the diff?
<ijohnson> uhh I don't think so? I literally just moved all the stuff in nativeenv.go to the bottom of env.go
<ijohnson> let me look again, but to confirm you are looking at the full diff in the github view?
<ijohnson> also seems I forgot to update the prepare-image tests in image_test.go, I'm doing that now too
<pedronis> ijohnson: there was a thing called Import that seems to be gone
<pedronis> tbh it was not used
<ijohnson> pedronis: that function is now in textenv.go
<ijohnson> sorry maybe I should move that one back to env.go too
<pedronis> I don't know
<ijohnson> the tests are the only thing that used Import, and I refactored it slightly so that Import is now called ImportTextReader
<pedronis> was it a test helper?
<ijohnson> yes it's a test helper
<ijohnson> well sorry let me clarify
<ijohnson> it was a pure test helper and had a separate implementation from everything else
<ijohnson> I re-wrote it to share the actual implementation in parseData
<pedronis> but it was exported
<ijohnson> and now it is used by textEnv
<ijohnson> and it is exported in export_test.go now because it's not used directly anywhere other than the tests for ubootenv
<pedronis> ijohnson: as far as I can on master is not a test helper, it's an actual method of envs
<pedronis> that nothing uses
<ijohnson> yes
<ijohnson> that's my point is that nothing actually used it outside of tests
<pedronis> it's not used by tests
<ijohnson> I don't know why it was originally written as a method on env and not just a test helper
<pedronis> it's tested by tests
<pedronis> on master
<pedronis> to me that's two different things
<ijohnson> mmm I see your point
<ijohnson> I guess I didn't quite grok that, and since nothing actually uses it outside of tests I didn't think it necessary to keep the method around
<ijohnson> do you want me to resurrect it as a method in the Env interface?
<pedronis> I would like to drop, but maybe somebody has a tool around using it
<ijohnson> I'd say let's drop and if someone has a dire need for it, it's easy enough to resurrect
<pedronis> that's fine, maybe mvo know more, apparently this all code lived somewehre else
<pedronis> and was ported into snapd at some point
<ijohnson> right
<ijohnson> pedronis: ok sorry that took longer than expected to fix that image test, I was very confused about it, but all clear now
<ijohnson> jdstrand: any idea where to put this bug? I don't know where the ubuntu security tips this is referring to comes from tbh https://bugs.launchpad.net/snappy/+bug/1874156
<mup> Bug #1874156: Outdated docs on "Ubuntu security tips" for seccomp <snap-docs> <Snappy:New> <https://launchpad.net/bugs/1874156>
<cjwatson> https://docs.ubuntu.com/core/en/guides/intro/security
<cjwatson> (I just web-searched for some of the quoted text)
<ijohnson> ah thanks cjwatson
<cjwatson> That links to https://bugs.launchpad.net/snappy/+bugs?field.tag=snap-docs for reporting bugs on the docs
<cjwatson> Which is exactly where this bug is :)
<ijohnson> haha so it seems I am exactly in the same place to fix this as the reporter
<ijohnson> degville: would you know where issues for https://docs.ubuntu.com/core/en/guides/intro/security should get forwarded to?
<ijohnson> I feel like this is now on github somewhere iirc
<degville> ijohnson: https://github.com/canonical-web-and-design/ubuntu-core-docs/issues
<ijohnson> thanks degville!
<ijohnson> maybe we should also file an issue there for fixing the "report an issue on the docs" button too
<degville> ijohnson: good point.
<degville> ijohnson: It's me that will try and fix these things though, as they're the core docs I'm trying to update.
<jdstrand> ijohnson: I do and I know where and how to fix it. it is on my todo to fix. feel free to assign to me
<ijohnson> degville: right I realized that after looking at the url, I just have never seen the security tips page before so I didn't realize this is part of the core docs :-p
<ijohnson> cool, jdstrand I'll assign the LP bug to you
<jdstrand> degville: I may ask for review/etc, but I'll take care of it. it should be coming from a forum doc that I wrote
<om26er> What are the chances for a snap to be allowed auto-connect permissions for raw-usb interface. It is required by https://e.foundation/ project to flash Android devices and adb-support interface is not sufficient in that case
<degville> jdstrand: thank you, that would be a huge help!
<pedronis> ijohnson: if you could move back parseData and iterEnv around where they were original it would be best, you can move them in a follow up
<ijohnson> pedronis: ok, give me a minute I can do that right now
<pedronis> ijohnson: let's also drop Import as discussed
<ijohnson> pedronis: do you mean drop importTextReader ?
<pedronis> yes
<ijohnson> ok
<pedronis> the thing that is not quite what it was, and anyway the thing that was wasn't used
<pedronis> (or so we hope)
<pedronis> ijohnson: and sorry, but my goal is to make reviewing the diff as much as a no-brainer as possible
<ijohnson> no problem I understand
<zyga> re
<ijohnson> pedronis: done (and I even ran the static-checks this time BEFORE I pushed, how good am I?)
<pedronis> :)
<pedronis> ijohnson: thanks, looking in a sec
<pedronis> ijohnson: thanks, I'll do the proper review now, thanks for bearing with me about making the diff small and obvious
<ijohnson> no problem, I am about to break for lunch, so be back in a little bit
<mup> PR snapcraft#3084 opened: repo: fix for multi-arch virtual-packages <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3084>
 * mvo heard his name and wonders if he can be helpful?
<mup> PR snapd#8553 closed: github: use "continue-on-error" for the spread-unstable systems <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8553>
<mup> PR snapcraft#3085 opened: build providers: dist-upgrade the environment on bootstrap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3085>
<pedronis> ijohnson: reviewed
<ijohnson> cool let me look
<mvo> cachio: I think I have an idea why sbuild fails, testing the fix now
<cachio> mvo, great!!
<cachio> thanks for digging
<cachio> cmatsuoka, can't connect through ssh sometimes to the uc20 vm
<cachio> cmatsuoka, you said you had a similar problem right?
<cmatsuoka> cachio: yes, but it doesn't seem to be deterministic
<cachio> cmatsuoka, right
<cachio> same happening here
<cmatsuoka> cachio: I saw it happening a few days ago then this morning
<cachio> sometimes work sometimes not
<cmatsuoka> cachio: did you report it to dimitri?
<cachio> cmatsuoka, no
<mup> PR snapd#8554 opened: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/8554>
<cmatsuoka> cachio: ok, I pinged him
<mvo> cachio: the pr 8554 is the one that should fix the nightly sbuild
<mup> PR #8554: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/8554>
<cmatsuoka> cachio: I just tried to reproduce here but it's starting correctly, if it fails for you try to preserve a log
<mvo> happy release day, lot's of 403 from the store it seems :/
<zyga> mvo: indeed
<zyga> mvo: I'm sure while we are stressed on release features the store team is scrambling to make it all work today :)
<mvo> zyga: yeah, it's not meant in a bad way, it just shows how popular ubuntu is
<zyga> happy release day mvo :)
<zyga> remember command-not-found?
<zyga> long way eh?
<cmatsuoka> good news everyone! it seems that #8547 + #8531 + #8552 is working end-to-end
<mup> PR #8547: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8531>
<mup> PR #8552: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
 * cmatsuoka is really not used to things working that easily so he will test it again
<oSoMoN> pedronis, another candidate for the "hide comment" feature:Â https://bugs.launchpad.net/snapd/+bug/1776873/comments/43
<mup> Bug #1776873: Whitelisted allowedURLschemes breaks some desktop apps <snapd:Triaged by pedronis> <chromium-browser (Ubuntu):Confirmed> <https://launchpad.net/bugs/1776873>
<mvo> zyga: totally remember it, I still maintain the thing that build the db :)
<pedronis> cmatsuoka: sounds great news though :) , let me know when I should re-review 8531
<pedronis> 8552 needs tweaks but is good to know things work together
<cmatsuoka> pedronis: will push soon, I'm just running a test commenting out the model measurement to make sure it's working :)
<mvo> pedronis: can I land 8547 to unblock people? just looking at the failures, looks like it's a bad case of "search" failing with 403, nothing real
<pedronis> mvo: I gave my +1 no? or you asking if you can override ?
<mvo> pedronis: yeah, if you are ok with landing it, I take that as a yes
<mvo> pedronis: I review the failures, so far all "failing search"
<pedronis> mvo: if you looked at the errors and seem unrelated, yes happy for it to land
<xnox> cachio:  cmatsuoka: please file bug reports on github.com/snapcore/core20
<mup> PR snapd#8547 closed: devicestate: do not use snap-boostrap in devicestate to install <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8547>
<cmatsuoka> pedronis: pushed to 8531, with master already merged in
<pedronis> cmatsuoka: thanks, will look in a little bits
<cmatsuoka> pedronis: thanks
<cmatsuoka> cachio: could you file a bug for xnox? I'm not being able to reproduce the problem here
 * cmatsuoka will take a 30min break
<mup> PR snapcraft#3085 closed: build providers: dist-upgrade the environment on bootstrap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3085>
<mvo> fwiw, I updated 8551
<mvo> (but not in the critical path)
<pedronis> cmatsuoka: reviewed
<pedronis> mvo: yea, we should land 8531 before 8551
<pedronis> mvo: if you are still around can you look also at 8531 ?
<pedronis> ah, actually you reviewed it already
<mvo> pedronis: yeah, your input on my points would be great
<mvo> pedronis: maybe I went over-the-top a bit
<mvo> (if so, appologizes)
<pedronis> mvo: 8531 ?
<pedronis> or somewhere else?
<mvo> pedronis: yes, the question about if we want cmd_create_partitions changes and if we do I think we want to add them to the spread tests, no?
<pedronis> mvo: we can pass a model in the spread test, it will mostly test that is accepted and nothing explodes
<pedronis> but the test doesn't really check the policy as such because there is no unsealing
<pedronis> mvo: the e-2-e uc20 tests with secboot, tpm will test this
<pedronis> but I don't think we have one yet
<mvo> ok
<pedronis> mvo: sorry, that was vague
<pedronis> mvo: I think we want the spread test mostly because the coverage of bootstrap is very low atm
<pedronis> and because it tests actual partition level stuff
<pedronis> not so much sealing details
<mvo> pedronis: ok, then we should probably update it, it's not updated to test the model yet
<pedronis> snap model --assertion > model  and use that I suppose
<pedronis> or whatever way works to get a model really
<mvo> ok
 * mvo looks at this
<pedronis> mvo: ah, no, we need a model with a grade
<pedronis> maybe
<pedronis> should work without but maybe saner with one that has grade
 * pedronis break
<cmatsuoka> pedronis, mvo: thanks for the review, I'll check/fix
<mvo> cmatsuoka: ok, let me quickly push my first tiny tweak
<cmatsuoka> mvo: sure
<mvo> cmatsuoka: I will leave the other bits to you then :) sorry for being pushy. once the spread bits are added I will updated 8551 but it's not in the critical path
<mvo> cmatsuoka: done, it's all yours again :)
<cmatsuoka> mvo: thanks!
<cmatsuoka> mvo: and thanks for 8551 too, it will make things much cleaner
<mvo> cmatsuoka: thank you
<mvo> cmatsuoka: actually, don't worry about the spread test in 8531, just fix the cosmetic bits from samuele, we can add the spread thing in 8551
 * mvo takes a break now too
<mvo> cmatsuoka: unless you have it already or it's almost done or trivail etc :)
<pedronis> mvo: it's tests/nested/manual/uc20-create-partitions-encrypt
<cmatsuoka> mvo: I only have the cosmetic bits so I'll stop there
<pedronis> cmatsuoka: also it's still marked draft
<pedronis> you should switch that
<cmatsuoka> pedronis: will unmark it, I forgot that, thanks
<pedronis> np
<mvo> pedronis: yeah, I will add the test as part of 8551 in my morning
 * mvo will stay around a bit to help landing 8531
<ijohnson> pedronis: the ubootenv PR is ready again with your comments addressed, and I confirmed that it now works properly on the pi
<ijohnson> pedronis: I didn't go through the full battery of trying failing kernel snap upgrades etc. but I was able to upgrade the kernel perfectly fine
<ijohnson> pedronis: the one thing that I'm just now realizing however is that we need to truncate the boot.sel file when we write it since it could be smaller (and in practice it will end up being smaller after a successful upgrade), which it seems like is less than ideal for robustness against fs corruption
<cmatsuoka> mvo: pushed
<pedronis> ijohnson: yes, any suggestion?
<ijohnson> pedronis: well tbh I'm starting to think maybe we should just use the normal native uboot format instead of the text one precisely because it's fixed size :-/
<ijohnson> pedronis: the other thing we could do is pad the file with newlines or whitespace, as the parser currently ignores empty lines without any flags
<pedronis> ijohnson: is that true for uboot itself though?
<ijohnson> pedronis: mmm good point I could test it later tonight
<ijohnson> I need to step out shortly to go get groceries before the store closes
<pedronis> ijohnson: anyway,  can we specify a size for the native format? like 4096 instead of 128k , is the 128k only for the main uboot.env ?
<ijohnson> pedronis: yes 128k is only for the main uboot.env, this other one could be whatever size we want, as long as it's not _too_ big for some definition of too big
<ijohnson> but I think the "too big" comment is like in megabytes
<mvo> +1
<pedronis> ijohnson: I suppose for this dave's script just need small tweaks ?
<ijohnson> pedronis: yes it would just be like 1-2 lines change to not drop the \0 anymore, otherwise the boot.scr looks exactly the same cause it's the same commands afaict
<pedronis> ijohnson: what are the -t on env import ?
<ijohnson> pedronis: I can't seem to find exactly what that flag does, waveform what does the `-t` flag do for `env import` ?
<ijohnson> oh he's not here
<pedronis> it's quite late for him, I wonder if it means -t"ext"
<pedronis> or something else
<ijohnson> pedronis: I was just talking to him in the other channel
<ijohnson> I don't think it's ext format because the fs isn't ext
<pedronis> ijohnson: no, I mean -t as contraction for -text
<ijohnson> ah could be ys
<ijohnson> *yes
<ijohnson> this is all the usage command says: `env import [-d] [-t [-r] | -b | -c] addr [size] [var ...] - import environment`
 * mvo really needs to leave, I will land 8531 in my morning
<pedronis> ijohnson: anyway it also means we don't need to support text format, which maybe is a plus
<pedronis> (less code)
<pedronis> bit of a roundabout adventure
<ijohnson> pedronis indeed it is a bit of a circular adventure
<ijohnson> It would be a lot less code however that we need to merge now
<pedronis> ijohnson: yes, I said this: (less code)
<ijohnson> I really need to get to the store now but I will start early tomorrow again if you want to discuss options
<ijohnson> A bit sad we probably won't be able to land everything today and build tomorrow but oh well
<ijohnson> Maybe builds can happen over the weekend
<ijohnson> If we land tomorrow that is
<ijohnson> I'll try to open a branch later tonight that does everything with native and maybe you and mvo can pick what to do tomorrow
<mup> PR snapcraft#3084 closed: repo: fix for multi-arch virtual-packages <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3084>
<mup> Issue core20#50 opened: Ssh server fails to start after core snap refresh <Created by cmatsuoka> <https://github.com/snapcore/core20/issue/50>
#snappy 2020-04-24
<mup> PR snapcraft#3086 opened: repo: restore marked-install strategy for apt-cache <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3086>
<mup> Issue core20#34 closed: please provide dbus-launch <Created by zyga> <Closed by xnox> <https://github.com/snapcore/core20/issue/34>
<mup> PR core20#43 closed: extra-packages: add dbus-user-session for user-session dbus <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/43>
<mup> PR snapd#8555 opened: bootloader/uboot: use secondary ubootenv file boot.sel for uc20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8555>
<mborzecki> morning
<mup> PR snapd#8531 closed: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8531>
<mborzecki> damn wasps
<mborzecki> already flying everywhere
<mborzecki> errand, back in a bit
<zyga> mborzecki: wasps?
<zyga> szerszenie?
<zyga> I wonder if I should merge master to resolve those build failures from yesterday
<zyga> mborzecki: perhaps we should patch the search test to skip on release weeks? :P
<mvo> centos-8 is still busted, I had no chance to look at htis yet
<pstolowski> morning
<pedronis> mborzecki: mvo: hi, I'm staring at #8552 and thinking what to do there
<mup> PR #8552: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
<mvo> pedronis: thank you
<zyga> hey mvo, pedronis, pstolowski
<mvo> good morning zyga
<zyga> mvo: should I review the UC20 branches that samuele mentioned yesterday or work on the GUI for refresh?
<mvo> zyga: what uc20 PR did he ask you about? if he did not ask you specifically I would say GUI is more important
<pedronis> I think we are ok, most things that could land have landed
<zyga> no not me
<zyga> during the standup
<zyga> ok, I think the gui is within reach today
<pedronis> what's left atm need a bit more than reviews
<zyga> assuming we can land things today
<zyga> ok
<pedronis> mvo: mborzecki: can we have a quick sync in 10 mins?
<zyga> I need a review for the GUI front-end https://github.com/snapcore/snapd/pull/7700
<mup> PR #7700: many: wait while inhibition file is present <Created by zyga> <https://github.com/snapcore/snapd/pull/7700>
<zyga> I will work on the glue logic now
<mvo> pedronis: I don't think mborzecki is around just then
<mvo> mborzecki: but I can be there if you want
<pedronis> mvo: ok, let's do one quick and we might need one with him later though. I want to bounce some ideas before I go off on a tangent
<mvo> pedronis:  but I can be there if you want, just need 1min
<mvo> pedronis: ok, let me just push this one PR and I'm there (1min)
<zyga> mvo: he said he's out on an errand
<mup> PR snapd#8556 opened: tests: ensure $cache_dir is actually available <Created by mvo5> <https://github.com/snapcore/snapd/pull/8556>
<pedronis> mvo: I'm in the standup HO
<mborzecki> re
<mborzecki> i'll grab a coffe and back to work
<zyga> installing windows is slow, snaps are faster ;-) (this is a joke with extra meanings)
<mborzecki> pedronis: sync in 5-10?
<pedronis> mborzecki: yes
<mborzecki> pedronis: mvo: i'm in the standup HO
<pedronis> omw
<ijohnson> Good morning folks
<zyga> hey ian :)
<ijohnson> Hey zyga
<pedronis> mvo: btw, the refactoring is goinf well, but we have a ton of those MockOsutilIsMounted
<mvo> pedronis: could we make it part of the suite setup?
<pedronis> not really
<mvo> pedronis: but I'm in a meeting right now so might be a bit slow to reply
<pedronis> just saying it takes a while to refactor
<mvo> pedronis: +1
<mup> PR snapd#8556 closed: tests: ensure $cache_dir is actually available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8556>
<mup> PR snapd#8557 opened: c/snap-bootstrap: have a small struct for checking mount states <Created by pedronis> <https://github.com/snapcore/snapd/pull/8557>
<pedronis> mvo: mborzecki: done ^
<zyga> afk, small child invasion
<mup> PR snapd#8550 closed: ubootenv, uboot: support new uc20 style text bootenv <UC20> <â Blocked> <Created by anonymouse64> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/8550>
<zyga> mborzecki: now my vendor.json does change
<zyga> weird
<mborzecki> zyga: govendor --version?
<zyga> 1.0.9
<zyga> the changes I see are on secboot and sys/unix
<mborzecki> master was updated with a PR from claudio, and vendor.json changed
<mborzecki> zyga: checksum?
<zyga> es
<zyga> yes
<mborzecki> hm maybe cmatsuoka had a differetn govendor version?
<mborzecki> idk, way over my head :P
<mvo> pedronis: thank you
<zyga> is master broken, is should I hold with any new PRs/
<mborzecki> xerrors.Is() is kinda silly with os.PathError or i'm doing something wrong here
<mborzecki> cmatsuoka: what's you `govendor --version` ?
<zyga> mborzecki: what are you doing with path error?
<zyga> maybe you pass some syscall result?
<mborzecki> zyga: maybe i'm doing/reading it wrong, but xerrors.Is(err, &PathError{}) compares whether *(err(*os.PathError)) == *(&PathError{})
<mborzecki> zyga: while i really want to know wetherh os.PathError is wrapped somewhere in the error stack
<zyga> hmmm
<zyga> just looking at it quickly
<zyga> either err is really PathError
<zyga> or you need to provide Unwrap
<pedronis> mborzecki: xerrors cannot really do it's job if the go stdlib isn't collaborating
<zyga> to look deeper into err
<pedronis> mborzecki: it gives you some of the future, but if go itself is too old some things won't work
<pedronis> I think
<zyga> mborzecki: you could manually repackage an error you get from somewhere
<zyga> into something that implements the Wrapper interface
<pedronis> though Chris has given Unwrap to some stuff
<zyga> then you could have "nice" properties from that point on
<pedronis> or maybe only something else I need to check
<zyga> but it's some extra work in a specific ase
<zyga> *case
<pedronis> there are different orthogonal things you can provided
<pedronis> for Is vs As
<mborzecki> pedronis: yeah, As seems to work for now
<cmatsuoka> mborzecki: hmm, 1.0.8. Too old?
<mborzecki> cmatsuoka: looks like it's generating a different checksum that 1.0.9 does
 * cmatsuoka updates
<cmatsuoka> mborzecki: are you using the edge snap?
<mborzecki> cmatsuoka: the edge snap?
<mborzecki> of govendor?
<cmatsuoka> I was using stable, switched to edge now
<mborzecki> cmatsuoka: idk, i go get'ed it
<zyga> oh there's a snap for that?
<cmatsuoka> mborzecki: I don't mind using any version but we should agree on a standard one
<pedronis> well it's archived
<pedronis> we should use the latest
<pedronis> available
<pedronis> and switch to modules when possible
<cmatsuoka> ok, I switched to 1.0.9 from the archive
<mup> PR snapcraft#3087 opened: meta: remove snapd workaround for classic for core20 onwards <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3087>
<mup> PR snapd#8558 opened: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<ijohnson> mborzecki: so the issue with the /run/mnt/data PR is that it hangs after booting run mode in the initrd?
<ijohnson> mborzecki: should I just give it a try and see what falls out?>
<mborzecki> ijohnson: sure, go ahead and play with it
<mborzecki> ijohnson: i've merged master there this morning, so it shoudl be fairly up to date
<ijohnson> okay thanks mborzecki I'll let you know how it goes
<mborzecki> ijohnson: cool, thanks!
<mup> PR snapd#8424 closed: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8424>
<mborzecki> hmm looks like there's a problem during reboot with the measurement PR on uc20
<mborzecki> but pc-kernel & snapd snaps repacked with snap-bootstrap still work, wth?
<pedronis> mborzecki: are they using the right version?
<ijohnson> mborzecki: did it ask you to enter a recovery key ?
<mborzecki> ijohnson: pstolowski: the nodes hang on reboot for some reason, i'm tying to download the image and check it locally
<pedronis> we don't have tests that encrypt
<pedronis> there's might be a tpm though and things explode
<mborzecki> pedronis: yeah we have /dev/tpm0 in gcp
<pedronis> mborzecki: maybe write a small bit of code that does the two measurements and see how it fails there
<mborzecki> hm somewhat unsuprisingly, the image i downloaded works locally
<pedronis> mborzecki: given the changes in your PR, I expect you need to try the same stuff on gce
<cmatsuoka> mborzecki: definitely something wrong in the image I created from current 8552, will debug/bisect after lunch to see what's happening
<mborzecki> cmatsuoka: where does it hang?
<cmatsuoka> mborzecki: somewhere inside the-tool
<mborzecki> meh :/
<mborzecki> cmatsuoka: is there a write up of what i need to try the emulated tpm with qemu locally?
<pedronis> mborzecki: the difference with the previous code is that you don't ignore all connect error no?
<pedronis> mborzecki: maybe you can revert to that but log the error somewhere that stays
<cmatsuoka> mborzecki: I think we don't have it documented, but this is the script I use: https://pastebin.ubuntu.com/p/Nd9642FkgR/
<cmatsuoka> will be back after lunch
<mborzecki> cmatsuoka: thanks, i'll try that
<cmatsuoka> mborzecki: you won't need the -serial stdio, I added it to debug things recently but it's not needed anymore
<pstolowski> fwtw i still have no luck running basic test on master. running for over 25 minutes (a few ssh attempts so far). no sure if this is the same problem?
<pstolowski> (i mean core20/basic)
<mborzecki> fwiw the split out bit that measures epoch and model does not return any errors when i run it manually
<mborzecki> and it's definitely touching /dev/tpm0
<pedronis> mborzecki: on gce ?
<mborzecki> pedronis: yes, i'm calling this basically https://paste.ubuntu.com/p/DWrPSgDqR4/
<pedronis> and it makes the stamps?
<mborzecki> pedronis: yup, i'm looking at strace too, quite some traffic on the fd that /dev/tpm0 was opened with
<pedronis> ok, so maybe the tpm stuff is not the issue and is some other change?
<mborzecki> uhh and can't installs swtpm-mvo snap, because the store times out
<mborzecki> ha ok, i see a bug now
<mup> PR snapcraft#3088 opened: repo: add interface to get packages from base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3088>
<pedronis> I made some comments on the PR, let me know what the bug is
<ijohnson> mborzecki: do you think you might be able to review #8555 before you EOD?
<mup> PR #8555: bootloader/uboot: use secondary ubootenv file boot.sel for uc20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8555>
<mborzecki> pedronis: i'm using incorrect path to recovery system model, ubuntu-seed/<label>/model instead of ubuntu-seed/systems/<label>/model
<pedronis> mborzecki: ah
<pedronis> mborzecki: you don't need to do that at all
<pedronis> we have the model
<pedronis> sorry, I should have spotted this
<mborzecki> np
<mborzecki> ah right, we open the seed, but it's a bit later than the measurements are done
<pedronis> mborzecki: yea, the code optitmized this away
<pedronis> but we can change it
<mborzecki> i'll leave a note
<pedronis> mborzecki: when is your eod?
<mborzecki> 6-7 probably
<pedronis> mborzecki: can you try a quick fix?
<pedronis> then I can take care of fixing the PR
<mborzecki> pedronis: yeah, i'm working on it right now
<mborzecki> wow, measuring the model takes a while
<mvo> cachio: the nightly sbuild test with master should work now
<mup> PR snapd#8554 closed: packaging: add "$TAGS" to dh_auto_test for debian packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8554>
<mborzecki> mvo: pedronis: cmatsuoka: i've updated https://github.com/snapcore/snapd/pull/8552
<mup> PR #8552: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
<mborzecki> need a review from too
<mborzecki> from chris too ofc
<mborzecki> gh is down again?
<ijohnson> mborzecki: not down for me
<mborzecki> my git push origin was stuck
<mborzecki> well, C-c and it isn't now :P
<cachio> mvo, nice, I'll run it again
<cachio> mvo, thanks!!
<mvo> mborzecki: thanks for this update
<cmatsuoka> mborzecki: running a test in the updated branch
<pedronis> mborzecki: thanks, I will look at it and see if it makes sense to apply other small tweaks but maybe best to land it and do a follow up
<mborzecki> argghh store hiccups
<mborzecki> - Download snap "go" (5551) from channel "latest/edge" (received an unexpected http response code (502) when trying to download https://canonical-lcy01.cdn.snapcraft.io/download-origin/canonical-lgw01/Md1HBASHzP4i0bniScAjXGnOII9cEK6e_5551.snap?interactive=1&token=1587758400_1ca872f971102f9a91dd0bf85533f334a428a91a)
<mborzecki> omg, shellcheck snap install failed too
<mborzecki> looks like it will be a wasted run :/
<pedronis> yes, lots of errors
<pedronis> I also was running something locally and it died for unexpected store errors
<mborzecki> https://status.snapcraft.io/ hm refresh endpoint down?
<cmatsuoka> mborzecki: current 8552 booted correctly to console-conf in run mode
<mborzecki> cmatsuoka: yup, same here :P
<mborzecki> cmatsuoka: i guess you ahve the setup for secureboot, can you try and modify the `ubuntu-boot/model` file and reboot?
<cmatsuoka> mborzecki: sure, trying that
<cmatsuoka> mborzecki: changing an irrelevant field does nothing as expected, changing a relevant field makes the-tool to fail and the boot process is halted
<mborzecki> cmatsuoka: cool, thanks for checking!
<cmatsuoka> mborzecki: should we ask for the recovery key at this point, like we do if other things fail?
<mborzecki> cmatsuoka: if it's run mode, we should reboot to recovery (?)
<cmatsuoka> mborzecki: this was the final state: https://pasteboard.co/J5ju6fG.png
<mvo> pedronis: are you ok with me merging 8414 even though there is a comment from jamie that we may need to address later?
<cmatsuoka> mborzecki: could be, I think it's only a matter of user experience in case of this kind of failure
<mborzecki> cmatsuoka: yup, i think we should try to address it for 1.0 somehow
<pedronis> mvo: yes
<mvo> pedronis: thanks, will wait for spread and then go ahead
<pedronis> as I said I have plan if people want really the other behavior
<mvo> :+1:
 * mvo breaks while waiting for spread
<pedronis> so #8552 is missing some tests, because now we masure things in many more scenarios
<mup> PR #8552: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8552>
<pedronis> not a blocker but I would prefer to add them before we forget
<cmatsuoka> mborzecki: I regenerated an image and now install mode failed, it might not be completely stable
<cmatsuoka> mborzecki: again it blocked in the-tool
<mborzecki> cmatsuoka: got log?
<mborzecki> pedronis: pushed some unit tests for install/recover mode measurements
<cmatsuoka> mborzecki: so it spent a lot of time there, and then it continued to install, which is quite odd
<mborzecki> pedronis: and it caught a typo you noticed
<pedronis> mborzecki: thanks
<cmatsuoka> mborzecki: it looks like something in timing out there
<cmatsuoka> s/in/is/
<mborzecki> cmatsuoka: yes, i saw that too, it's like it's stuck for a little while doing measurements or mounts, and then it proceeds just fine
<cmatsuoka> ah ok
<pedronis> is opening the tpm slow?
<pedronis> maybe it needs entropy?
<pedronis> if it's slow and needs entropy maybe we should try to open it only once
<pedronis> (just guessing here)
<pedronis> I suppose somebody should run that script you made on gce and measure where time goes
<pedronis> and strace
<cmatsuoka> it's strange because even if it needs entropy qemu is getting it from the host system
<cmatsuoka> which should have plenty
<cmatsuoka> so now it opens tpm earlier, but it's only for measurements and then it keeps an external state to do it only once, right?
<cmatsuoka> because in maciek's original code it also opened tpm for measurements, but I didn't see any timeout in multiple test runs
<pedronis> it current code opens the tpm multiple times
<cmatsuoka> ah I see
<pedronis> that's why it would be interesting to measure where the time goes
<pedronis> mborzecki played with this earlier: https://paste.ubuntu.com/p/DWrPSgDqR4/
<mborzecki> i'm off ot pick up a package, back in 30 or so in case there's anything urgent
<cmatsuoka> mborzecki: ack
<mup> PR snapcraft#3087 closed: meta: remove snapd workaround for classic for core20 onwards <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3087>
<mborzecki> https://status.snapcraft.io/  snap downloads is down :(
<noise][> mborzecki: we are fighting to keep up with a massive increase in downloads from the release
<mborzecki> noise][: thanks for the info, figured as much :)
<noise][> 3x normal volume in some cases today, even with some throttling in place :/
<mborzecki> does the mouse cursor still look different in certain snaps like chromium?
<mup> PR pc-amd64-gadget#44 opened: grub-recovery.conf: don't make run mode default just because ubuntu-boot exists <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/44>
<mup> PR snapcraft#3088 closed: repo: add interface to get packages from base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3088>
<mup> PR snapd#8555 closed: bootloader/uboot: use secondary ubootenv file boot.sel for uc20 <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8555>
<ijohnson> \o/
<mup> PR snapd#8559 opened: boot, bootloader: adjust comments, expand tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8559>
<mup> PR snapd#8560 opened: tests: disable "searching" test <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8560>
<zyga> ijohnson: ^ if around
<zyga> I also CCd jdstrand
<ijohnson> zyga: looking now
<zyga> ijohnson: I think we need that to make any progress without mvo's overrides
<ijohnson> zyga: approved, sorry got distracted reviewing uc20 things
<ijohnson> zyga: I'll merge later when tests are done and I can open a followup re-enabling it, thanks for this
<zyga> thanks
<zyga> eh opensuse needs fixes
<zyga> pkgconf-pkg-config instead of pkg-config
#snappy 2020-04-25
<mup> PR pc-amd64-gadget#44 closed: grub-recovery.conf: don't make run mode default just because ubuntu-boot exists <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/44>
<mup> PR snapcraft#3089 opened: ci: move staging store tests to spread <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3089>
<mup> PR snapcraft#3089 closed: ci: move staging store tests to spread <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/3089>
<mup> PR snapcraft#3090 opened: ci: move staging store tests to spread <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3090>
<mup> PR snapd#8414 closed: o/configstate: core config handler for persistent journal <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8414>
<mup> PR snapd#8561 opened:  many: put the sealed keys in a directory on seed for tidiness <Created by pedronis> <https://github.com/snapcore/snapd/pull/8561>
<mup> PR snapd#8552 closed: cmd/snap-bootstrap: measure epoch and model before unlocking encrypted data <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8552>
<mup> PR snapd#8561 closed:  many: put the sealed keys in a directory on seed for tidiness <UC20> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8561>
<mup> Issue core20#50 closed: Ssh server fails to start after core snap refresh <publication> <Created by cmatsuoka> <Closed by xnox> <https://github.com/snapcore/core20/issue/50>
<mup> PR snapcraft#3091 opened: ci: install the snapd snap when preparing spread systems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3091>
#snappy 2020-04-26
<mup> PR snapcraft#3086 closed: repo: restore marked-install strategy for apt-cache <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3086>
<mup> PR snapcraft#3086 opened: repo: restore marked-install strategy for apt-cache <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3086>
<exit70> https://snapcraft.io/cookie shows up as proprietary in 18.04 "Software" despite the fact that description says "Open-source ..."
<mup> PR snapcraft#3092 opened: repo: filter stage-packages using base's manifest (core20) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3092>
<mup> PR snapcraft#3086 closed: repo: restore marked-install strategy for apt-cache <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3086>
<mup> PR snapcraft#3091 closed: ci: install the snapd snap when preparing spread systems <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3091>
<mup> PR snapcraft#3093 opened: Match <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3093>
<mup> PR snapcraft#3093 closed: Match <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3093>
<mup> PR snapcraft#3094 opened: tests: add tests for python with stage and python-package dep <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3094>
<mup> PR snapcraft#3094 closed: tests: add tests for python with stage and python-package dep <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/3094>
<mup> PR snapcraft#3092 closed: repo: filter stage-packages using base's manifest (core20) <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3092>
<mup> Bug #1875232 opened: with overlayfs on /tmp: cannot open base directory /tmp/snap.hello-world: Permission denied <Snappy:New> <Debian:New> <https://launchpad.net/bugs/1875232>
