#snappy 2015-05-11
<thesheff17> lantins: 1) I don't think so...2) I'm not sure...I'm also trying to get it to work without going to the store
<thesheff17> haha sorry terrible answers :)
<thesheff17> but yea I would love to know as well
<thesheff17> oh these were asked by ryanprior sorry
<lantins> thesheff17: I was watching a video from eariler this month, they said the kernel would become a snap package, available from the store, along with the base system itself
<lantins> so, if that happens, im _guessing_ you could swap in your own kernel
<thesheff17> ah nice
<lantins> thesheff17: another video also mentioned that you could host snap packages privately, but no other details were provided
<lantins> my vagrant install of snappy seems to be failing on me, so I've not had a chance to play around with the command line tools, it could be as simple as pointing it to your own URL
<lantins> but then i question how updates would happen auto-magically
<thesheff17> yea I'm a little confused by how the packages work...do you just provide your own binaries in bin and the build the snappy image?
<lantins> my gut feeling is telling me, snappy ubuntu core is 12+ months off being production ready
<lantins> thesheff17: yeah, it seems that way
<thesheff17> well as far as I know the updates require a reboot from revision to revision
<thesheff17> yea I def want to see snappy in production...but yea you are prob right its going to be a while
<lantins> the transactional updates, using deltas is what appeals to me :)
<lantins> would be good for low bandwidth situations
<lantins> i just hope its not all too tied into 'the store', that' ive NFI how you even 'browse'....
<thesheff17> absolutely for me as well...apt-get works well enough now but I'm always scared its going to break something
<thesheff17> yea my company prob wouldn't want the scripts public or in ubuntu store
<thesheff17> I also wonder how kernel 4.x will work since it no longer requiring reboots...I haven't really scene anyone testing it yet.
<lantins> company isn't a problem for me, customers however would not want it public, since they are paying good money for it ;)
<thesheff17> haha right
<thesheff17> also why did they name it snappy...it totally collides with a google snappy compression package
<thesheff17> its hard to search right now on google
<lantins> these days, every name is taken :)
<lantins> but yeah, its a right pain to google for things
<thesheff17> this is also really interesting http://insights.ubuntu.com/2015/05/06/live-migration-in-lxd/?utm_source=ubunteu&utm_medium=url_shortner&utm_term=PQfLe3&utm_campaign=shortner
<lantins> I'm thinking, for my planned use case, rolling something from ubuntu core may be the way to go
<thesheff17> having live migration of snappy running instances would be so cool
<thesheff17> yea I have tested a bunch of docker...it kinda fits into my environment but I don't think I have the resources to implement it
<lantins> to implement snappy?
<thesheff17> to implement docker
<lantins> ah
<thesheff17> also its a little strange docker was like the first package for snappy
<lantins> docker is cool, ive only ever 'played', never done anything in production :)
<lantins> yeah, i dont quite get why...
<lantins> since they can, kinda, be used for the same thing
<lantins> _kinda_
<thesheff17> right
<thesheff17> yea I have 1 docker server in amazon running 1 stage service for my developers but just getting that working was not fun
<lantins> thesheff17: https://daniel.holba.ch/blog/2015/05/the-snappy-online-summit-is-in-full-swing/ - links to the videos i mentioned above, may be of interest
<thesheff17> cool I will def check them out
<lantins> videos are only a couple of days old, so its fairly uptodate ;)
<thesheff17> lantins: cool yea if you are a python guy check out this link http://www.wefearchange.org/2015/04/creating-python-snaps.html I'm slowly trying trying to duplicate this article... I use pip for almost everything I do
<lantins> ta :)
<lantins> okay, so python is already installed in snappy, because part of the tools are wrote in python, i wonder how you'd do something like say... Ruby? would every dependancy be rolled into the snap package?
<lantins> my actual use case would be a go app, so that's easy being a binary
<thesheff17> yea I'm guessing this pex package for python basically builds custom binaries or what packages you want included in your snappy image
<thesheff17> *of
<thesheff17> yea I almost wish you could say take an entire lxc container and make a snappy image out of it...
<dholbach> good morning
<JamesTait> Good morning all; happy Monday, and happy Twilight Zone Day! ð
<beowulf> o/
<beowulf> Chipaca: you around today?
<Chipaca> beowulf: yes, but was at kids' dentist until just now
<ogra_> you should talk to your health insurance if they dont let you go to a grown up one ...
<Chipaca> ogra_: i'm not sure whether to mention this dentist specialises in ASD kids or not
<dholbach> https://code.launchpad.net/~jamesodhunt/ubuntu/vivid/ubuntu-core-upgrader/bug-1435774/+merge/256562 is in the sponsorship queue... is the bug still valid?
<davidcalle> Can someone have a quick look at https://bugs.launchpad.net/developer-ubuntu-com/+bug/1453781 ?  I believe the bug reporter is right, but I'd like a confirmation before fixing. Thanks !
<davidcalle> (snap format doc bug)
<Chipaca> davidcalle: I don't think the bug is right
<davidcalle> Chipaca, glad I asked :)
<Chipaca> granted, the website isn't entirely correct either
<Chipaca> :)
<Chipaca> but that description is correct as things are currently documented
<Chipaca> escaping a dot inside a character class being necessary depends on the regex language being used
<Chipaca> and adding a backslash just makes it harder to read
<Chipaca> so leave it without
<davidcalle> Chipaca, I was more concerned about the lack of + at the end
<Chipaca> hah
<Chipaca> give me a minute
<Chipaca> davidcalle: the documentation in the project is correct
<Chipaca> davidcalle: can you change the documentation on the website to match the one in the project?
<davidcalle> Chipaca, yep
<Chipaca> it describes the version field thus: âthe version of the snap (only `[a-zA-Z0-9.+~-]` are allowed)â
<Chipaca> the description of the name *is* missing a quantifier, and has no wording to avoid the absence
<Chipaca> but the version one is correct thanks to the language :)
<Chipaca> interestingly, it doesn't look like we enforce this in the client
<davidcalle> Chipaca, I've fixed the regexes and added a link to the full format reference we also have on the site (which is an export of the in-package doc)
<Chipaca> double plus good
<Chipaca> davidcalle: are your changes live?
<davidcalle> Chipaca, they are
<Chipaca> davidcalle: hm. you changed the regex for the version, but not the wording, meaning it's wrong; if you're going to word it like that you need to change the regexp
<Chipaca> davidcalle: version should match ^[a-zA-Z0-9.+~-]+$
<davidcalle> Chipaca, oh right, I see what you mean match/allowed
<Chipaca> actually, it'd probably be a good idea to force version to not start with a period, but that can wait
<Chipaca> get out of the smartassery of creating a package with version ".."
<Chipaca> i'll file a bug
<vmayoral|pc> greetings
<vmayoral|pc> ogra_: ping
<ogra_> vwhey hey+
<ogra_> eh
<ogra_> vmayoral|pc, hey hey
<vmayoral|pc> ogra_: hope everything's going fine
<vmayoral|pc> i'd like to run through you some thoughts if that's fine
<vmayoral|pc> so, we've been putting a lot of time into creating a ROS framework for snappy that allows developers to create snaps that use ROS
<ogra_> ok
<vmayoral|pc> so far results look quite promising but we are constantly twisting things to basically fit everything in the writable partition (instead of touching system-a)
<vmayoral|pc> i quite like the approach followed here http://www.piware.de/2015/01/snappy-package-for-robot-operating-system-tutorial/ with a chroot. Would you recommend doing so or would you rather resize the partitions (e.g.: assign 2 GB to system-a so that it can contain libboost and other necessary libraries)
<vmayoral|pc> for the general developer (familiar with ROS) the second approach would work better but maybe the first one is preferrable from a Snappy perspective?
<ogra_> vmayoral|pc, i personally would perfer to be able to independenly upgrade core from the ros ...
<ogra_> so keep ROS a snap ... this also saves you from tinkering with partitions
<ogra_> vmayoral|pc, did you talk to pitti about it yet (he wrote that howto) ... probably he feels like making it an official snap in the store
<ogra_> (i see he is not around though)
<vmayoral|pc> ogra_: that makes sense, i'll try to reach him at some other time then, thanks
<ogra_> hey pitti :)
<pitti> hey ogra_ :)
<vmayoral|pc> pitti: i was asking ogra_ about his opinion for ROS support on snaps
<vmayoral|pc> we've been putting a lot of time twisting things to get everything in the writable partition but your approach seems pretty handy as well. I'm just concerned about the traditional ROS users that would expect everything under /opt...
<pitti> vmayoral|pc: yeah, I wish snappy wouldn't change the entire FHS, but right now we can't have /opt
<pitti> vmayoral|pc: however, with the specified "private overlay mounts", snaps can actually put stuff wherever they want again, including /opt (just visible within the snap's mount namespace)
<vmayoral|pc> that's interesting
<vmayoral|pc> pitti: what we are trying to do, besides releasing a snap with a ROS distro
<vmayoral|pc> i to release the whole chroot
<vmayoral|pc> so that users can develop/compile their own packages in the BBB
<vmayoral|pc> pitti: how do you feel about this? (what we are trying to avoid here is that a developer  compiles from source all the ROS packages every time they want to develop something on top of ROS)
<tbr> does anyone happen to know if this has made it into some image that I could test? https://bugs.launchpad.net/snappy-ubuntu/+bug/1425370 - after all it says merged
<tbr> or short of that, how do I build my own image
<tbr> disregard the second question, just remembered that tit's impossible.
<ogra_> not impossible :)
<ogra_> but really hard to set up
<ogra_> tbr, it says "In Progress" ...
<ogra_> so it did not land anywhere yet
<tbr> ogra_: "factually impossible, especially for me"
<tbr> ogra_: https://bugs.launchpad.net/snappy-ubuntu/+bug/1425370
<ogra_> yes
<tbr>  Merged into lp:goget-ubuntu-touch at revision 172
<ogra_> you look at the wron thing :)
<ogra_> (teh code is merged, but not released anywhere yet)
<ogra_> look higher up :)
<tbr> ok, so the answer to my initial question is no then
<ogra_> right, as long as the bug status is not "Fix Released" it wont be in any image
<tbr> ogra_: so even if there would be a CI image from something that is tracking trunk it would be "fix released"?
<ogra_> usually as soon as someone uploads the deb for it he will set it to that
<ogra_> or the launchpad automation will ... deducted from a changelog entry
<tbr> I'm not a complete moron, even if it might look like it. I'm just unfamiliar with the ways of working, so I end up asking questions to verify my understanding. I'm terribly sorry for that.
<tbr> ok. so I'll watch that bug to go into released.
<ogra_> huh ? i didnt mean to attack you or something
<tbr> not taken as such. it's just whenever I try to ask questions to understand processes someone goes "duh, y u no see, it obviuz". That doesn't get me any closer to understanding how things work as I feel that me asking questions that get me closer is unwelcome
<ogra_> totally not unwelcome
<ogra_> just ask away :)
<tbr> thanks
<tbr> is there such a thing as a description of the usual workflow in ubuntu? I really have a hard time as I only see web interfaces here and there and then there is lots of non-obvious glue and magic that confuses me.
<ogra_> tbr, well, the usual workflow is to have a bug ... if the bug applies to multiple places (i.e. yours is against a package and a toplevel project (system image)) ass the respective tasks ... if someopne does a merge on launchpad mentioning that bug you see the branches in the bug (with their state ... i.e. merged in your case) ... if i am a clever developer, i mention the bug in my .deb cahngelog so that as
<ogra_>  soon as i upload LP will automatically close the bug task for this package
<tbr> ogra_: yeah, that bit I understood. Just wondering if there is "Ubuntu workflows for outsiders" or something like that. A coherent document that would explain most cases. Would also save us both lots of questions/answers and time
<ogra_> yeah, i'm not sure there is ...
<ogra_> technically it all boils down to launchpad merge proposales nowadays, the bugs are just the accompanying paperwork
<ogra_> i.e. you find an issue ... file a bug, grab the source tree, write a patch and push to a private branch that you proposed for merging via the LP UI
<ogra_> *propose
<ogra_> oh, and private in the sense of "owned by you" not meaning "secret branch"
<kyrofa> sergiusens, can I access the webdm API discussed in the README after snappy install-ing webdm? Or do I need something else?
<tbr> ogra_: sure, but then where does a merge get released to, who decides that, how do debs get built, where are they accessible, etc. there's a pile of knowledge that is completely indiscoverable to a newcomer. :-(
<rsalveti> tbr: we have a lot of docs all around, for ubuntu you can check https://wiki.ubuntu.com/UbuntuDevelopment
<rsalveti> also feel free to ping the community team and dholbach when he's around
<rsalveti> https://developer.ubuntu.com/en/ has a lot of info as well, but mostly when building apps and such
#snappy 2015-05-12
<tbr> rsalveti: I'm trying to understand how I'd be supposed to do this: https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1425370/comments/4 - It has been established that building your own image is effectively impossible and as the image doesn't contain dpkg.
<dholbach> good morning
<Chipaca> tbr: what are you trying to do?
<tbr> Chipaca: ultimately I'd like to boot snappy on this embedded linux device that has uefi based firmware.
<tbr> that says there is a fix and even built, but that points to a package, how do I go from that to a snappy image.
<JamesTait> Good morning all; happy International Nurses Day! ð
<Chipaca> tbr: goget-ubuntu-touch is the project that holds ubuntu-device-flash
<Chipaca> tbr: does that answer your question?
<Chipaca> JamesTait: ooh! i should call my mum
<tbr> not really
<Chipaca> tbr: tell me more :)
<JamesTait> Chipaca, your mum is a nurse?
<Chipaca> JamesTait: yep
<Chipaca> JamesTait: well, she's now an OAP, but once a nurse always a nurse, right?
<tbr> Chipaca: so, for x86_64 there is this: http://releases.ubuntu.com/15.04/ubuntu-15.04-snappy-amd64-generic.img.xz - it doesn't support UEFI.
<Chipaca> tbr: did you install that package?
<Chipaca> tbr: ubuntu-device-flash is what you use to build the images
<tbr> Chipaca: I thought there was no dpkg on those images?
<Chipaca> tbr: you don't install that package on the target, you install it on the host
<tbr> ok. I'll have to install it and try to figure that out then
<Chipaca> tbr: sudo ubuntu-device-flash core rolling --output amd64.img --developer-mode --channel edge
<Chipaca> tbr: once you've got the ppa set up
<Chipaca> tbr: that'll give you an "amd64.img" that you can run with kvm, or dd onto a device
<Chipaca> tbr: to set up the ppa, you do this:
<Chipaca> gah, can't link it
<Chipaca> gimme a sec
<Chipaca> tbr: well, it's explained in https://launchpad.net/~snappy-dev/+archive/ubuntu/tools?field.series_filter=vivid
<tbr> don't worry
<tbr> I can manage a ppa
<Chipaca> tbr: basically, sudo add-apt-repository ppa:snappy-dev/tools  && sudo apt-get update && sudo apt-get install ubuntu-device-flash
<Chipaca> tbr: ah, ok
 * Chipaca always wonders why add-apt-repository doesn't do the update itself
 * tbr wonders why add-apt-repository only reasonably works with PPAs and not with adding other repositories, but that's completely unrelated
<tbr> oh, that's in 15.04 of that ppa only. time to boot a vm with that...
 * tbr prefers LTS as the main machine
 * Chipaca is upgrading to wily today
<Chipaca> well, actually maybe next week when the rest of my team is back
<tbr> ok, so one step closer.
<tbr> it boots, but I have to manually kick fs0:\EFI\BOOT\BOOTX64.EFI
<tbr> easily addressed by "echo fs0:\\EFI\\BOOT\\BOOTX64.EFI >startup.nsh" in the root directory of the EFI partition. Not sure if there is a "nicer" way
<beowulf> Chipaca: would you like a review? i added a bem linter for webdm's css https://code.launchpad.net/~stephen-stewart/webdm/post-css-bem-lint
<Chipaca> beowulf: on it
<Chipaca> beowulf: http://pastebin.ubuntu.com/11094443/
<beowulf> Chipaca: ooo
<soothran> hey folks!
<soothran> I am bit confused reading about snappy!
<soothran> how can i (or can I) install Ubuntu snappy core in 32-bit pc?
<soothran> not as a kvm image but directly.
<thesheff17> I don't think you can right now soothran
<thesheff17> its also server only really at this point
<soothran> hmm..so why does it say it can be in x86 here (https://www.linux.com/news/embedded-mobile/mobile-linux/804659-ubuntu-snappy-leads-mobile-linux-migration-to-iot)
<soothran> also in ubuntu website it says "Ubuntu Core can be installed directly on X86 or ARM devices" https://developer.ubuntu.com/en/snappy/
<thesheff17> it might eventually have ISO but its super alpha right now
<beuno> soothran, you can on amd64
<beuno> the x86 builds have been failing lately
<beuno> but I'm sure we'll get around to fixing them soon
<beuno> not a lot of 32bit users left out there though!
<soothran> i know it can be in ARM..but it is the x86 part that confuses me..
<beuno> soothran, it works on intel as well
<beuno> but just 64bit atm, the 32bit builds have been failing and we haven't gotten around to fixing them yet
<soothran> thanks beunno..so my plain question will be "if i have a x86 intel laptop, is it possible to directly install ubuntu snappy core?
<thesheff17> even if you could I would consider it very alpha
<soothran> that's oke
<thesheff17> why so set on installing snappy on old hardware?
<soothran> I am not going to anyways, just wanted to know if it is possible
<beuno> soothran, yes you will
<beuno> all new laptops are 64bit
<soothran> AFAIK, i am not able to burn the 64-bit snappy image from the repo (http://ftp.arnes.si/pub/mirrors/ubuntu-cdimage/vivid/)
<soothran> into a usb and boot it. i think this is just hte kvm image or something?
<soothran> that's why i was wondering how can i install it 'directly' in a computer
<davmor2> soothran: why would you? if you want to experiment with snappy just install it in kvm, you will not have a desktop and you will have very limited set of applications.
<davmor2> soothran: what's your actual plan for snappy
<soothran> as i said i am not planning to do this thing..i am missing something here.
<davmor2> soothran: and is this a throw away laptop, ie is it one that is sat there doing nothing and you want to put it to some use?
<davmor2> soothran: if so then you can try just dd'ing the img file only the hdd not sure if that will work or not as I don't think there is an actual installer for it yet
<soothran> nothing to be honest..all i wanted is a clarification on few sentences that I read. first one "Ubuntu Core can be installed directly on X86 (or ARM, i am sure about arm part)"
<soothran> this one is from here ---> https://developer.ubuntu.com/en/snappy/
<soothran> but there is no resources that points to a x86 image (or 64-bit image for that matter)  that can be 'directly' installed in a PC
<davmor2> soothran: https://developer.ubuntu.com/en/snappy/start/ say kvm only
<soothran> how about this one -----> https://www.linux.com/news/embedded-mobile/mobile-linux/804659-ubuntu-snappy-leads-mobile-linux-migration-to-iot
<soothran> says "...while any x86 computer or VM should do the trick on the x86 side. (Here's a Dustin Kirkland tutorial on loading Snappy on the BeagleBone Black.)"
<soothran> what's with the "any x86 computer" part?
<davmor2> soothran: no idea I can only go by the stuff on the Ubuntu website as that will actually be updated but the fact that you can run in kvm on any x86 system might be what they are mis-understanding maybe
<tbr> even the 64bit image  is not quite there yet for use outside kvm (with bios) and legacy bios HW. UEFI support is only getting added.
<soothran> hmm
<soothran> yeah may be
<vmayoral|pc> pitti: I'm trying to figure out a way to create a snap from a ROS package. Do you have any thoughts on this?
<vmayoral|pc> pitti: i guess that the most straightforward way is to scan the CMakeLists.txt of the ROS package and fetch/place the binaries under src/ of a new snap.
<jdstrand> dholbach: hi! fyi, docs/security.md has been updated-- can you update the site? also, if you compare https://developer.ubuntu.com/en/snappy/guides/security-policy/ and https://developer.ubuntu.com/en/snappy/guides/frameworks/, you can see that the security page is not formatted correctly (there is no whitespace border around the page)
<dholbach> I think davidcalle looked into this earlier? ^
<jdstrand> dholbach: fyi, this is also pending: https://code.launchpad.net/~jdstrand/snappy/snappy.bus-name-docs/+merge/258894 (meta.md and frameworks.md)
<dholbach> thanks jdstrand
<dholbach> I'll talk with davidcalle tomorrow to think of a better solution than this
<davidcalle> dholbach, +1
<jdstrand> dholbach: I don't know if you want to review that MP so I can commit it and people can update those three pages at the same time
<davidcalle> jdstrand, ouch for the security page, looks like a broken import. Fixing.
<jdstrand> dholbach, davidcalle: thanks for looking into this
<dholbach> jdstrand, I'm a bit preoccupied right now
<jdstrand> dholbach: not a problem at all
<dholbach> thanks jdstrand, thanks davidcalle
<jdstrand> davidcalle: https://developer.ubuntu.com/en/snappy/guides/security-policy/ looks pretty again
<davidcalle> jdstrand, :)
<itsme_> so i am trying to install "wily-preinstalled-core-http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/i386.tar.gz " from
<itsme_> how to i go about creating a live USB with this file?
<itsme_> is it possible at all?
<pitti> vmayoral|pc: ah, hello; (tried to reply this morning, but you weren't online)
<pitti> vmayoral|pc: my initial gut feeling would have been to build the ROS core as a framework, and make ROS apps depend on it, so that you don't always have to build/duplicate everything
<pitti> vmayoral|pc: but apparently that very duplication is "by design" now :/
<pitti> vmayoral|pc: as for building, I figure the tutorial build script that I did a few months back should be by and large apply to other modules too
<pitti> join #ubuntu-meeting-2
<pitti> oops
<jdstrand> Chipaca: oh, you know, if the launcher is doing all the env var setting, then the bin-path and systemd bits go away and things are always in sync
<jdstrand> Chipaca: you probably thought of that already, so, nice job! :)
<Chipaca> jdstrand: :)
<Chipaca> you'll laugh at the bit of code that made me avoid doing this in this mp before
<Chipaca> it's the mkdir -p
<jdstrand> heh
<Chipaca> i've got to: make sure the appname and version have no /. build /tmp/snap.$UID. mkdir that. add the appname. mkdir that. add the version. mkdir that. add tmp. mkdir that. kill me now.
<Chipaca> each thing with its error checking of course
 * Chipaca bites the bullet
 * Chipaca gets bogged down
 * Chipaca EODs while tests pass
<jdstrand> mterry: did your question regarding snappy.bus-name-docs constitute a review?
<mterry> jdstrand, sure?  It was the only thing I noticed.  I'm not qualified to comment on content itself, but for presentation, that's all I saw.  rest is good  :)
<jdstrand> mterry: thanks
<mterry> jdstrand, I noticed you pushed the other branch directly -- do we not use CI for snappy?
<jdstrand> tbh, I think I am the only person qualified to comment (I implemented/designed said feature and wrote the review tools checks :)
<jdstrand> mterry: not currently
<jdstrand> I imagine that is something that might change in the coming weeks as we got more organized
<jdstrand> there is tarmac
<jdstrand> I should probably set to 'approve' and let it do its thing
<mterry> jdstrand, and as for my comment about quotes -- is that line the same with or without quotes in yaml?
<jdstrand> of course, in this case, it is only docs changes
<jdstrand> mterry: oh I commented on that-- it should've been quoted. fixed
<mterry> jdstrand, so what would it be if yaml parsed it without the quotes?  (i.e. how does it parse bus-name which doesn't have quotes?)
<jdstrand> mterry: quotes force it to be parsed as a string. '<' and '>' are apparently special in yaml, so we should quote
<mterry> jdstrand, ok.  so bus-name will be recognized as a string since it's not an int and doesn't use reserved chars.  So doesn't *need* the quotes
<jdstrand> right
<jdstrand> just like with 'name'
<mterry> cool
 * mterry is not super familiar with yaml
<ogra_> it is like txt :)
<jdstrand> yeah, I'm not either. getting better at it
<jdstrand> I guess I should say that I am familiar with it these days
<jdstrand> but not an expert
<bjf> i'm trying to build an amd64 image for an intel nuc. i'm looking for a device tar ball to use. where do i find one?
<beowulf> ogra_: using node-snapper, it's complaining that the vivid images can't be found, s/vivid/wily seems to work
<c-nv-s> test
#snappy 2015-05-13
<tbr> bjf: does your particular NUC have a legacy bios mode or only UEFI? UEFI doesn't work quite yet.
<tbr> bjf: In my case to get the latest tools and preliminary UEFI support I did on 15.04: "apt-add-repository ppa:snappy-dev/tools" "sudo ubuntu-device-flash core rolling --output amd64.img --developer-mode --channel edge" only works on 15.04 tho for uefi
<rsalveti> tbr: mind updating the bug with the issues you still had with latest u-d-f that is available at this ppa?
<rsalveti> and yeah, this extra logic is not part of the rootfs, so we need to change the flashing tool
<tbr> rsalveti: I'm still unclear about the underlying issues, but yeah, will do
<tbr> if it would be more clear I'd have done already
<rsalveti> thanks, yeah, not so familiar with that setup still, maybe slangasek can help you a bit more with that
<rsalveti> since he did the initial uefi support
<slangasek> UEFI does work, for 64-bit systems that don't require secureboot and if you're using the right udf
<tbr> slangasek: for me 'works' means in a very narrow context: in qemu with UEFI firmware and by manually executing grubx64.efi or writing a startup.nsh
<slangasek> https://launchpad.net/~snappy-dev/+archive/ubuntu/tools/+packages shows that goget-ubuntu-touch has only been updated for vivid, not for trusty or utopic; that's a sergiusens question
<tbr> on a minnowboardmax however boot fails and I'm not sure why
<slangasek> tbr: no, udf installs the bootloader to /EFI/boot/bootx64.efi
<slangasek> which is the path UEFI expects to find for a removable disk
<slangasek> you shouldn't even have a grubx64.efi installed by udf
<tbr> or it was called bootx64.efi
<bjf> tbr, got part of my question answered earlier. thanks.
<tbr> anyway, both on qemu and on minnow I end up in the EFI shell with the image
<tbr> if I then run it manually it will boot in qemu, but not on the minnow
<slangasek> well I can't reproduce the behavior you're describing under qemu, the images booted straightaway for me with no configuration required
<dholbach> good morning
<tbr> slangasek: well, something is obviously different then. I've documented what I did in the bug.
<tbr> the qemu is 2.0.0+dfsg-2ubuntu1.10 and ovmf 0~20131112.2590861a-2  - though that shouldn't matter as behaviour is the same on the minnowmax too.
<JamesTait> Good morning all; happy Alison Hargreaves Day! ð
<ogra_> beowulf, oooh, thanks, fixing
<beowulf> ogra_: i was wondering if node-snapper should look in package.json (or npm-shrinkwrap) to find deps, at correct semver, and maybe the easiest way to do that would be to allow passing in package.json as an argument and using that in the chroot where 'npm install' is called? does that sound ok?
<ogra_> beowulf, do you mean .deb deps or npm deps ?
<beowulf> ogra_: i mean npm deps
<ogra_> ah, yeah, sounds sane
<beowulf> parsing package.json could MY_EXECUTABLE from "main"
<ogra_> yeah
<ogra_> if you use paths from there you need to substitute them thouh
<ogra_> *though
<vmayoral|pc> hey there, I'm trying to get snappy-tools set up in and amrhf chroot running something like https://gist.github.com/vmayoral/b9d84522e1b28b54f028
<vmayoral|pc> however it seems like: "E: Unable to locate package snappy-tools"
<vmayoral|pc> the package is available though http://ppa.launchpad.net/snappy-dev/tools/ubuntu/dists/vivid/main/, right?
<ogra_> vmayoral|pc, hmm, i fear there is no armhf deb for them
<ogra_> (are you running that on armhf ?)
<vmayoral|pc> ogra_: yes
<ogra_> http://ppa.launchpad.net/snappy-dev/tools/ubuntu/pool/main/s/snappy-tools/
<ogra_> vmayoral|pc, bug 1454619
<ogra_> (why is there no ubottu here ... tsk)
<vmayoral|pc> thanks ogra_
<vmayoral|pc> ogra_: i got the tools from the BBB image you guys released but this is hardly scalable for other developers. Until there're armhf devs, is there a simpler way to get snappy-tools? Maybe from the sources? If so i'd really appreciate if you could walk me through
<ogra_> you could do "apt-get build-dep snappy-tools && apt-get source -b snappy-tools"
<ogra_> with the ppa enabled ... on an armhf device
<ogra_> (not sure how well that works, theoretically it should though :) )
<ogra_> (armhf chroot *should* work, but i'm not sure how the go compiler will behave in a qemu chroot)
<ogra_> bug 1454619
<ubottu> bug 1454619 in snappy-ubuntu "snappy PPAs should provide armhf packages" [Undecided,New] https://launchpad.net/bugs/1454619
<ogra_> \o/
<beowulf> dpm: hi! would you be interested in a couple of typos i spotted while reading https://developer.ubuntu.com/en/snappy/guides/config-command/?
<dpm> beowulf, definitely (sorry, I'Ve been in calls until now). Would you mind pointing them out to me and davidcalle? ^
<davidcalle> dpm, beowulf, actually that means they are in snappy trunk as well, since that's a doc we imported. I'll make a mp with what you have found.
<beowulf> dpm: davidcalle: not sure what's the best way to do this, but...
<beowulf> " The application is repsonsible to provide a configuration handler that can transform yaml into the apps native configuration format. "
<beowulf> responsible*
<beowulf> app's*
<beowulf> and i'd argue it should read "is responsible for providing a configuration handler"
<beowulf> " The current list of values that must be supported (if the feature is used:"
<beowulf> missing closing para?
<beowulf> " When the configuratin is applied the service will be restarted by snappy automatically(?). "
<beowulf> configuration*
<beowulf> and not sure about that "(?)"
<beowulf> dpm: davidcalle: also i wasn't sure about the config examples, they confused me a little
<beowulf> but the last one:
<beowulf> " snappy calls meta/hooks/config with empy input "
<beowulf> empty*
<beowulf> dpm: davidcalle: if you want to point me at somewhere i can branch and propose an mp i'm happy to do that
<davidcalle> beowulf, snappy trunk https://code.launchpad.net/snappy the text is in docs/config.md
<davidcalle> beowulf, thanks :)
<beowulf> davidcalle: https://code.launchpad.net/~stephen-stewart/snappy/fix-typos-in-config-docs/+merge/259027
<davidcalle> beowulf, super nitpicking, but do you mind dropping the extra space between sentences on l18 of the diff ? "editing of config.  The format"
<davidcalle> beowulf, I'm going to apply these changes to the website a bit later today, since they LGTM, thanks again
 * davidcalle relocates
<dpm> thanks beowulf!
<mterry> To run ./run-checks from lp:snappy, do I need to install into GOPATH first?
<Chipaca> mterry: I think you need to work in a go workspace
<Chipaca> mterry: e.g., mkdir -p ~/canonical/snappy/src/launchpad.net && cd ~/canonical/snappy/src/launchpad.net && bzr branch lp:snappy && cd snappy && GOPATH=~/canonical/snappy ./run-checks
<mterry>  Chipaca: Oh hmm, OK.  I have to be *inside* GOPATH for it to work then?
<Chipaca> mterry: it needs a hand in finding itself, yes
#snappy 2015-05-14
<tbr> hmmm 2001:6b0:e:2018::1337 as used by releases.ubuntu.com seems down
<tvoss> o/
<tbr> good moaning tvoss
<tvoss> o/
<tvoss> I'm not really around :)
 * tbr is closer to understanding the mechanics of UEFI boot of snappy now...
<JamesTait> Good morning all; happy Golf Day! ð
<svij> can anyone give me a hint, why snappy doesn't want to boot from my beaglebone black? When powering on there are only USER LEDS 0-2 contantly lighting up and nothing happens. I've tried two different sd cards, other images (like a ânormalâ ubuntu 14.04.2 image) do boot normallyâ¦ any ideas?
<ogra_> svij, did you try holding donw the button ?
<ogra_> (S2 i thinnk)
<svij> ogra_: yeah, than there a no lights and nothing happens (well no lights except the power  led)
<ogra_> well, do you have a serial cable ?
<svij> no I don't
<svij> ~20$ oO
<ogra_> woaah, where do you look ?
<ogra_> should be below 10â¬ on amazon
<svij> oh
<svij> I checked this page: http://elinux.org/Beagleboard:BeagleBone_Black_Serial
 * ogra_ currently uses http://www.amazon.de/SainSmart-Serial-Debug-Console-Raspberry/dp/B00KVUSI30/ref=sr_1_1?ie=UTF8&qid=1417690697&sr=8-1&keywords=FTDI+Cable+3.3
<ogra_> sadly sold out, i found that to be most compatible
<svij> any suggestions for another one?
<ogra_> any 3.3V FPGA should do ... make sure to get the four loose cable ends, not a 4 prong plug
<ogra_> that way you can use it on other boards too in case they need a different order for the plug
<beowulf> Chipaca: any recommendations on where to buy a bbb in uk?
<Chipaca> beowulf: amazon
<svij> ogra_: this one? http://www.amazon.de/Neuftech-PL2303HX-Konverter-Converter-Adapter/dp/B00R76SCJ6/ref=sr_1_1?ie=UTF8&qid=1431596874&sr=8-1&keywords=USB+to+TTL+Serial+Cable
<beowulf> Chipaca: 50 snoops, a raspberry pi 2 is 30... any reason to go for one over the other?
<Chipaca> beowulf: what's "50 snoops"?
<ogra_> svij, looks good .... (dont use the red one (VCC) on the beagle ;) you only need RX,TX and GND)
<beowulf> Chipaca: you know, snoops
<svij> ogra_: alright, I'm not really familiar this stuff. Ordered and thanks. :)
<Chipaca> beowulf: mmm... nope, no idea :) but the bbbs are all pretty much the same afaict. Also don't forget a usb serial thingie
<ogra_> svij, great, serial cables are kind of an essential tool when working with arm boards :)
<svij> ogra_: ok! :)
 * svij now tries to build a snappy image for a raspi 2â¦
<tbr> ogra_: indeed they are #essentialtools
<ogra_> :)
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (7 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/webdm/post-css-bem-lint/+merge/258696 | No reviews (5 days old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (5 days old)
<nothal> https://code.launchpad.net/~stephen-stewart/snappy/docs-tidy-up-package-metadata/+merge/259050 | No reviews (less than a day old)
<nothal> https://code.launchpad.net/~stephen-stewart/snappy/fix-typos-in-config-docs/+merge/259027 | No reviews (less than a day old)
<Chipaca> why isn't there a markdown linter that doesn't depend on node?
<beowulf> Chipaca: huh?
<Chipaca> beowulf: a markdown linter? a thing that told us when we weren't following some kind of 'markdown best practices' or whatever (basically, that it would work on most markdown flavours)
<beowulf> Chipaca: ah, but markdown is many different things
<beowulf> a django markdown linter would be required here, but that's not the same as a github markdown linter, i guess
<Chipaca> beowulf: AIUI our markdown goes to three different places: django, github, and pandoc
<beowulf> i think the docs would be helped with a proper nav to the side, instead of a top breadcrumb style nav
<beowulf> also, <tt> and <code> need clearer styling
<beowulf> Chipaca: github, really? editing would have been so much easier there...
<Chipaca> beowulf: i think it's only sergiusens that cares about that one, for now :) although i hear mterry is also a fan
<beowulf> Chipaca: but then, the markdown for developer.u.c needs to be django flavour, unless we change that
<Chipaca> dholbach was usig pandoc for ... dunno where, at this stage :)
<beowulf> also the docs could consider linking to snappy-examples where relevant, like for snappy config we have two examples that would help i think
 * beowulf is throwing words to the void, probably
<Chipaca> beowulf: linked, or include?
<beowulf> Chipaca: include && link
<beowulf> Chipaca: i tried to find the source of https://developer.ubuntu.com/en/snappy/guides/appliance-builder-guide-webcam/ but failed, but it's missing some <p>'s
<Chipaca> beowulf: poke the holbach
<Chipaca> beowulf: (gently)
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (7 days old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (5 days old)
<nothal> https://code.launchpad.net/~chipaca/snappy/log-command-failure/+merge/258669 | Approve: 1 (5 days old)
<nothal> https://code.launchpad.net/~chipaca/snappy/no-more-log/+merge/258667 | No reviews (5 days old)
<nothal> https://code.launchpad.net/~chipaca/snappy/different-logger/+merge/258664 | No reviews (5 days old)
<vmayoral|pc> greetings
<vmayoral|pc> can anyone from Canonical take a look at https://myapps.developer.ubuntu.com/dev/click-apps/2641?
<beuno_> vmayoral|pc, hi. It seems to need some fixes in the packaging
<beuno> vmayoral|pc, can you make sure you're using the latest tool from the PPA?
<rsalveti> morning
<mterry> Let's say that ~mir-team wants to upload a package for Mir in the snappy store.  Which developer account uploads that?  We can't have team accounts upload a package, right?  Do they just make a dummy user account with a shared password?
<ogra_> mterry, hmm, i think the webapps team and core-apps teams handle that case somehow ... ask popey :)
<vmayoral|pc> greetings beuno_, i can't find snappy-tools, within the packages installed in my BBB image https://gist.github.com/vmayoral/0cd0c7cb7cb70494c72c
<vmayoral|pc> beuno_: mind pointing out how can I update the packaging tools?
<vmayoral|pc> i'm hoping that this bug https://bugs.launchpad.net/snappy-ubuntu/+bug/1454619 ends up having snappy-tools available as an armhf .deb which will simplify updating the snappy tools for our BBB images
<ubottu> Launchpad bug 1454619 in snappy-ubuntu "snappy PPAs should provide armhf packages" [Undecided,New]
<vmayoral|pc> ubottu: thanks, updated the threads. Still unable to set it up. Apparently due to "snappy-remote"
<ubottu> vmayoral|pc: I am only a bot, please don't think I'm intelligent :)
<rsalveti> vmayoral|pc: I believe I might need to trigger a rebuild for those packages
<rsalveti> vmayoral|pc: will take care of this later today
<vmayoral|pc> rsalveti: awesome! was trying to get snappy-remote built with not real good results https://gist.github.com/vmayoral/80906b27d92f96f87153, thanks!
<jkridner> asac: we going to get you on this weekly technical call some time?
<jkridner> asac: we keep missing you.
<jkridner> asac: rcn-ee and I are on the call now.
<ogra_> jkridner, he is on vacation this week
<jkridner> thanks ogra_
#snappy 2015-05-15
<dholbach> good morning
<JamesTait> Good morning all; happy Friday, and happy Nylon Stockings Day! ð
<Chipaca> @reviewlist
<nothal> https://code.launchpad.net/~chipaca/ubuntu-core-launcher/unshare/+merge/258367 | Approve: 1, Needs Fixing: 1 (8 days old)
<nothal> https://code.launchpad.net/~sergiusens/webdm/queryPackageNames/+merge/258640 | No reviews (6 days old)
<nothal> https://code.launchpad.net/~mterry/snappy/allow-more-dots/+merge/259181 | Approve: 1 (less than a day old)
<nothal> https://code.launchpad.net/~chipaca/snappy/log-command-failure/+merge/258669 | Approve: 1 (6 days old)
<nothal> https://code.launchpad.net/~chipaca/snappy/no-more-log/+merge/258667 | No reviews (6 days old)
<vmayoral|pc> rsalveti: thanks for yesterday's changes. It seems the we are still missing some dependencies https://gist.github.com/vmayoral/3be25ea9026a8d73568e. Mind taking another look please?
<ogra_> vmayoral|pc, ouch ... thats a bit trickier to solve
<rsalveti> yeah, the problem is see is mixing up vivid with trusty
<ogra_> well, the problem is as well that we dont have android-tools for armhf
<rsalveti> I think we do
<ogra_> and u-d-f depends on that ...
<rsalveti> at least I was able to install snappy-tools on my meizu yesterday
<rsalveti> but using vivid
<ogra_> ah
<vmayoral|pc> let me retry bootstrapping a vivid file system and i'll provide feedback
<rsalveti> after rebuild the packages
<rsalveti> *rebuilding
<ogra_> ah, right, i see them on the phone
<rsalveti> let me reflash vivid, got wily while trying to get vivid
<ogra_> heh, yeah
<rsalveti> this channel mess we had yesterday
<ogra_> i'm currently re.working all my bot scripts ...
<davmor2> rsalveti: no really
<ogra_> not only the channels changed ... buit versions were re-set too
<davmor2> rsalveti: you'll need a new channel but I'm not telling you what :)
<rsalveti> davmor2: rc/ubuntu-developer right?
<rsalveti> or yet another channel
<ogra_> no, thats wily
<rsalveti> trying with mako
<ogra_> ubuntu-touch/rc-proposed/bq-aquaris.en
<rsalveti> even for mako?
<ogra_> that seems the only vivid channel left
<ogra_> there is a mako subdir
<rsalveti> haha, interesting
<ogra_> ogra@anubis:~/irc-json-daemon$ ubuntu-device-flash query --channel=ubuntu-touch/rc-proposed/bq-aquaris.en --device mako --list-images|tail -1
<ogra_> 5: description='ubuntu=20150515,device=20150210,custom=mako-1.1,version=5'
<ogra_> wow, we havent re-built android since feb.
<rsalveti> yeah, need to rebuild that, was waiting a few patches to land in code-phablet first
<rsalveti> like the aosp apns update
<rsalveti> ogra_: seems to be working: http://paste.ubuntu.com/11147470/
<ogra_> yeah
<mterry> Chipaca, what is the snappy project's code review flow?  For example, on lp:~mterry/snappy/allow-more-dots, you did an approve comment with a small comment request.  (I made that change)  Should I top-approve?  Do I need more than one approval?  Do we manually push to trunk or does tarmac do that for us?  We don't seem to have a CI instance I note
<Chipaca> mterry: usually, if a branch is fine i'd +1 and top-approve; when it has comments i'd +1 and let you top-approve once you'd considered the comments (or come back to me and ask to re-review if it ended up being less-than-cosmetic)
<mterry> ChickenCutlass, makes sense.  If top-approved, does it automatically land in trunk or do we use silos etc?
 * Chipaca hugs ChickenCutlass 
<mterry> whoops
<mterry> :)
<Chipaca> mterry: it lands in trunk
<mterry> Chipaca, OK.  So only one approve needed, auto-lands in trunk.  But no CI hooked up yet?  Reviewers manually run tests?
<Chipaca> mterry: it runs run-checks before landing to trunk
<Chipaca> mterry: no CI yet; selftest needs work for that (not much though)
<mterry> Chipaca, neat, great.  I'm out of questions  :)
<Chipaca> mterry: you could also run go fmt as a precommit hook
<Chipaca> mterry: congrats on your first landing :)
<mterry> Chipaca, I'm breaking out the beer now  ;)
<Chipaca> mterry: and now you've got (another) excuse!
<Chipaca> mterry: and, jsut so you don't get *too* high and mighty, need-fixing'ed your second mp
<mterry> :)
 * Chipaca ~> EOD \o/
<Chipaca> EOW, also
<ogra_> enjoy !
 * Chipaca might be lying
<Chipaca> no, not lying, promise
 * Chipaca definitely lying then
#snappy 2016-05-16
<mjs7231> Hey guys, I'm having trouble creating a snap that uses Gtk.  It seems everything is working fine, but when I try to run my Python script, I get "ValueError: Namespace Gtk not available"
<mjs7231> I'm probably missing a dependency, I tried gir1.2-gtk-3.0, gobject-introspection, and libgtk-3-0 -- nothing works.
<Mikaela> Is there anything like apt:url for snaps?
<zyga> o/
<sborovkov> Hi. Couple of questions about new security - is there a way now to say run root commands from snap? Particularly reboot. Also RPI specific - how would it be possible to be able to change config.txt which is a part of gadget snap from another snap?
<jdstrand> Trevinho: hi! did you happen to get hello-unity working?
<jdstrand> Trevinho: fyi, for the launcher API: https://github.com/ubuntu-core/snappy/pull/1173
<Trevinho> jdstrand: yeah...
<Trevinho> jdstrand: I mean, I got the hello unity thing working
<Trevinho> jdstrand: I wanted to push it, but I've not done it yet
<Trevinho> jdstrand: I'll do that in a bit
<jdstrand> Trevinho: thanks!
<Trevinho> jdstrand: do you happen to know why gtk apps get the anonymous path?
<Trevinho> jdstrand: it should be appid...
<Trevinho> That's something we also noticed at the desktop sprint
<jdstrand> no idea
<Trevinho> jdstrand: the only thing I don't get working in hello unity is the indicator icon... I didn't debug that much yet, though... But I believe it's libappindicator not being able to locate the icon (although I've all the caches set)
<jdstrand> Trevinho: intersting. If you want to commit what you have, I can verify what you have so far
<Trevinho> jdstrand: yeah, give me 10 minutes, since I've done that in a VM which is in a different machine from the one I'm on right now :)
<jdstrand> np, thanks again
<Kristbaum> Hello, is this the right place if I have questions about snappy?
<jdstrand> Kristbaum: yes
<Kristbaum> Okay thanks ;) I wanted to know what the "home" slot in "snappy interfaces" is about. I coudn't find anything elsewhere..
<jdstrand> Kristbaum: the docs are being worked on and are a bit behind atm on the website. You can see this though: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md
<Kristbaum> Ah thanks, so if I enable the "home" slot in the .yaml file, what happens if a user tries to install it?
<jdstrand> the interface is not (currently) autoconnected, so the access is denied
<Kristbaum> Can a User enable it?
<Kristbaum> with snap connect?
<jdstrand> the user would then need to do something like: snap connect <you snap name>:home ubuntu-core:home
<Kristbaum> But support for autoconnect is planned?
<jdstrand> autoconnect is there now
<jdstrand> it is explicitly set to not autoconnect
<jdstrand> aiui, the gadget snap would make that auto-connectable
<jdstrand> also, future snap assertions might make then autoconnect depending on how the store is set up (that is planned)
<jdstrand> them*
<jdstrand> also, tooling might improve to assist with connecting
<zyga> jdstrand: o/
<Kristbaum> Ah, so maybe in the future, there may be a Dialogue where the User decides if he want's to enable access tho his/her homefolder?
<zyga> jdstrand: I was off today, sorry for not realizing this earlier
<jdstrand> Kristbaum: it's conceivable
<jdstrand> hey zyga :)
<jdstrand> zyga: if you're off, why are you here now?
<ogra_> jetlaggers paradise ;)
<zyga> jdstrand: just talking to slangasek about a missed meeting
<jdstrand> Kristbaum: you might be interested in https://insights.ubuntu.com/2016/05/04/security-confinement-in-ubuntu-core/
<zyga> jdstrand: ohh, published now!
<zyga> jdstrand: cool
<jdstrand> zyga: that's niemeyer's blog post from a little while ago
<jdstrand> not the whitepaper
<zyga> ahh, too bad :)
<zyga> I look forward for the whitepaper
<jdstrand> Kristbaum: there is also http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<jdstrand> zyga: it will be nice to have up. I think it is in the community team's court at this point
<Kristbaum> jdstrand: Thanks for this ;) How exactly are the snaps on desktop Ubuntu updated at the moment? Do I have to hit refresh on ervery app?
<ogra_> there used to be an autorefresh feature, that was disabled and i currently re-worked
<ogra_> it will return eventually
<ogra_> (currently you have to use snap refresh)
<Kristbaum> Interesting. Do you know anything about how source code will be managed in the snappy store? Are there considerations on this? (In the sense of "apt source")
<ogra_> no, snaps are purely binary
<ogra_> you woud just host your code on github or wherever and aadd a snapcraft.yaml to the tree
<Kristbaum> Isn't this a Problem when you want a trusted, reproducable build?
<ogra_> why would you ?
<ogra_> the esssence of a snap is that it can be competely untrusted thanks to the confinement and the entry checks in the store
<Kristbaum> If, for example, I use a FIrefox snap to to 90% of my work, how do I know that the snap  is really only the sourcecode from Mozilla, not anything else.
<Kristbaum> ?
<ogra_> you cant ...
<ogra_> i mean ... iit is likely that it is unmodified if mozilla uploaded it to the store ... but there is no guarantee
<Kristbaum> Yeah, but isn't this a problem, or am I seeing this wrong?
<ogra_> and effectively it does not matter ... since you have to decide what you allow to that snap
<Kristbaum> But I do need to trust Firefox, because my work is in it, not in the Rest of the System. And if i can't check if it's really Firefox, how does this help me?
<ogra_> how do you know it today ?
<jdstrand> Kristbaum: that gets into the assertions stuff I referenced earlier
<Kristbaum> I guess I trust the Debian/Ubuntu Developers that took the source and put it in the repo, or I type apt source and check it myself.
<jdstrand> Kristbaum: the idea is that you'll be able to be confident that a snap comes from a particular publisher (eg mozilla). assertions have crypto the ensures that and that crypto could be used to verify your installed snap
<jdstrand> Kristbaum: that does not guaratee that the publisher built the snap from their source trees
<Trevinho> jdstrand: sorry for the delay, i'm pushing the thing soon... but i've just noticed that I've lost some of the things I was working on (damn me and staing on tmp), so... let me check i can get them back
<jdstrand> Kristbaum: Launchpad will grow functionality to build snaps, similar to ppas today, that can be triggered off source uploads. some of that is already in place
<ogra_> it already has it
<jdstrand> yes, but not autouploads to the store
<ogra_> as a button for a tree though ...
<Kristbaum> Oke, this isn't bad, so I can at least trust, it's from Mozilla. And will these Launchpad snaps be marked, so I know I can check the source if I want, and they directly are build from this source?
<Kristbaum> jdstrand: ^
<jdstrand> I'm not up on those details. Immediately you could download the snap from Launchpad, generate a hash of the file and compare that to what is on your system
<jdstrand> I know source builds are something that is desired; I just don't know how they tie into assertions
<Kristbaum> Ok, but it isn't on the roadmap yet? You would get a lot of "free-software-street-cred" if you implement this, I would presume. :D
<jdstrand> it is on the roadmap, I just don't know the plans
<jdstrand> Kristbaum: you might ask on the list-- you'll get more authoritative answers :)
<jdstrand> I think a lot of people are off today
<ogra_> at least we pretend to :)
<Kristbaum> Thanks, you helped me a lot ;) ! Very nice talking to you, I'll be off then, good night!
<qengho> jdstrand: it would be kind of cool to have reproducible builds and ship a snapcraft.yaml if it came from that.
<qengho> Ask user at upload time.
<qengho> Ask publisher, that is.
<jdstrand> I would love reproducible builds
<niemeyer> jdstrand, zyga: We need to work on a disc-drive interface of sorts, soonish..
<jdstrand> niemeyer: I have no details on that. can you file a bug?
<jdstrand> (with the snapd-interface tag of course :)
<niemeyer> jdstrand: Will do, although I don't have many details either ;)
<mhall119> sergiusens: where can I find the snapcraft.yaml for your telegram snap?
<niemeyer> jdstrand: The idea is just enabling applications that want /dev/cdrom etc
<niemeyer> mhall119: Under his GH username
<niemeyer> sergiusens/telegram-snap
<mhall119> thanks niemeyer
#snappy 2016-05-17
<Trevinho> jdstrand: it took some time (sorry, I had to rewrite some parts), but here it is: https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes
<Trevinho> mhall119: you might see that as well ^ (MP at https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858)
<niemeyer_> Would anyone have a snapcraft.yaml example that has a qt application working?
<niemeyer_> Trying to snap something and suffering at the moment
<niemeyer_> Got as far as realizing I needed to stage libqt5gui5 to get the plugins manually, and setting the appropriate enviornment variable to find these
<Trevinho> niemeyer_: I think you can get some at https://github.com/kyrofa/qt-example-snaps
<Trevinho> sergiusens: I know it's dirty (and probably ugly too :-)), but what you think of this: https://bugs.launchpad.net/snapcraft/+bug/1551716/comments/5 ?
<ubottu> Launchpad bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New]
<niemeyer_> Trevinho: Thanks!
<mhall119> Trevinho: thanks, but it's not working for me, can we work on it together tomorrow?
<zyga> o/
<morphis> zyga: morning!
<zyga> morphis: good morning :)
<morphis> zyga: hey!
<morphis> zyga: I've just pushed new changes to the network-manager interface PR
<zyga> morphis: shall we land it? :)
<morphis> zyga: please :-)
<zyga> morphis: I'll review it in a sec
<morphis> thanks!
<Trevinho> mhall119: it runs fine here, but you've to install it as --devmode for now
<Trevinho> or do you get issues while snapcrafting it?^
<sborovkov> Hi. Is it possible to allow snap to change config.txt on RPI? Which is a part of gadget snap
<ogra_> not yet, no
<ogra_> you will have to use an editor for now
<sborovkov> ogra_: is this a planned feature/is there a bug?
<ogra_> niemeyer, ^^^ did we actually plan an interface for that that other snaps can consume ?
<sborovkov> also we were told before in the time of old security that perhaps we should create script that can execute root commands (so that we can reboot device for instance). is that possible to do now?
<Olh> Hi guys! I have a question: I am working at scientific facility and we are switching soon to Ubuntu16 from Ubuntu12, and the thing is: do you think snappy can be a good approach to package management in the "industrial environment"?
<ogra_> definitely
<Olh> because from what I see it looks a little bit more like an end-user package management
<ogra_> snappy started completely focused on embedded and IoT ... it only grew into the other spaces over time
<ogra_> having snap support on the desktop enables you to actually test your development there very easily (beyond extending the delivery focus to endusers too)
<Olh> I see, ok, thanks, I have to test it out and see for myself if it's doing the job ;)
<ogra_> yeah
<sborovkov> ogra_: do you know about what I asked further up, about running root commands from the snap or do you know who I could ask about that? Thanks :)
<ogra_> Olh, there is also some marketing material if you like such stuff ;)  https://insights.ubuntu.com/2015/10/21/snappy-core-unlocks-iot-value-within-the-dell-edge-gateway-5000-series/
<ogra_> sborovkov, zyga perhaps ... he works on interfaces between snaps ... that would likely be something the ubuntu-core snap would have to provide
<Olh> @ogra_ thanks!
<nothal> Olh: No such command!
<Olh> ogra_ thanks! ;D
<ogra_> heh
<ogra_> welcome
<sborovkov> ogra_: understood, thanks. zyga: Hi, do you know if it's possible to run root commands in snap? can it be done somehow at all currently?
<morphis> zyga: ping
<zyga> morphis: pong
<morphis> zyga: you had time to look into the PR for network-manager?
<zyga> morphis: somewhat, I need to merge it and release
<zyga> morphis: I think we've switched to a weekly SRU now
<morphis> zyga: so from a review perspective no further comments?
<zyga> morphis: looks okay
<morphis> zyga: ok, do we want a last review from jdstrand on the desktop-side bits?
<zyga> morphis: you could run update-pot so that it's all green there
<zyga> morphis: I suspect he will anyway
<zyga> morphis: I think it's better to ship it now and iterate
<zyga> morphis: perfect security is a perfect enemy of usability :)
<jdstrand> hey now
<morphis> zyga: :-)
<morphis> jdstrand: hey!
<zyga> jdstrand: hey
<morphis> jdstrand: if you didn't saw the mails yet, I've updated desktop-support to the network-manager interface
<jdstrand> I'm not saying not to merge it
<jdstrand> but we have to be awfully careful shipping stuff that is too wide open
<jdstrand> just like we don't want to ship interfaces cause we can't take them away, we can't ship too open policy because we can't take those accesses away easily
<morphis> jdstrand: yeah
<zyga> jdstrand: I think that's a fine line, we should be just smart when we do, we can fix security bugs caused by initially too-wide-open things if there's no other choice
<jdstrand> there is a choice here
<jdstrand> you said you'd just merge it and that security is the enemy of usability
<jdstrand> the choice is, let me review it with the updated changes :)
<zyga> jdstrand: I didn't mean to merge it before :)
<zyga> jdstrand: I mean ultimately when we don't see holes we should just merge it
<jdstrand> ah, ok, then I misunderstood :)
<zyga> perhaps there are more holes
<jdstrand> of course
<jdstrand> I thought we were skipping a step is all
<jdstrand> I see now that I was wrong
<zyga> sorry, I'm still a bit jetlagged
<zyga> I mean well
<jdstrand> nw, sorry that I misunderstood
<morphis> :-)
<jdstrand> :)
<morphis> jdstrand: I've marked the line I've added for desktop support
<morphis> there might be a few things missing in terms of functionality but we will resolve those as we go
<jdstrand> morphis: ok, I'll be reviewing that today. I was going to review the previous changes but then saw that the desktop ones were requested so thought I'd wait
<jdstrand> I was most interested to see if we were going to ship different policy for desktop and core
<jdstrand> but I'll see that soon enough when I take a look at it
<morphis> jdstrand: thanks
<jdstrand> sborovkov: you can ship anything you want in your snaps, including stuff you want to run as root, but they will be subject to the security policy as defined by the connected interfaces when running as a service or from /snap/bin. it is possible for you to ship scripts that you run directly as the user under sudo (ie, sudo /snap/foo/current/bin/bar) outside of confinement
<jdstrand> sborovkov: but it sounds more like you would like interfaces for reboot and perhaps other things. If so, please file a bug and use the 'snapd-interface' tag
<jdstrand> sborovkov: then it/they can be discussed
<sborovkov> jdstrand: understood, thanks. Basically we need reboot, but since we are going in beta and don't know if something else might be required.
<sborovkov> jdstrand: is there already some interface for reboot specifically?
<jdstrand> sborovkov: no
<ysionneau> hi
<jdstrand> Trevinho: re https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes: thanks! :)
<ysionneau> it seems now the ubuntu-core-launcher is directly running the target binary instead of what was done before : running a shell wrapper which was exporting PATH and LD_LIBRARY_PATH
<ysionneau> so now the snap binary cannot use shared library from its own snap?
<Trevinho> jdstrand: np, I've noticed that also unconfined the sound indicator integration is not properly working, but for the rest it should work
<jdstrand> cool
<ysionneau> I've done my own wrapper ... but this was working before :o
<ngaio> ubuntu-calculator-app.calculator gives me an libGL error and fails
<morphis> zyga: one other thing I wanted to talk with you about is the pulseaudio interface
<zyga> morphis: yes?
<zyga> morphis: for native snap, I assume
<ssweeny> zyga, have you had a chance to look at https://github.com/ubuntu-core/snappy/pull/1118#discussion_r62386799 yet?
<morphis> zyga: so I am going to implement the slot side of this now, what is the current state of your PR? still being stalled on the trust-store discussion?
<zyga> morphis: I think that's something I need to ask jdstrand again about
<zyga> morphis: I'd like to land it
<zyga> morphis: because we have no other way, we can improve it next week or the week after
<zyga> ssweeny: looking
<zyga> ssweeny: I didn't read it yet, just catching up with jetlag today
<morphis> zyga: I think we shouldn't release it in a state where it allows audio recording
<zyga> morphis: this was discussed at the sprint briefly, if it takes us a lot of time to make it safer we should release it now
<zyga> morphis: because the alternative is --devmode anyway
<zyga> morphis: and this is better than nothing
<morphis> zyga: so releasing only with a change to pulseaudio to deny audio recording would be my vote
<zyga> morphis: apparently that's the whole trust store
<zyga> morphis: or if we can look at the apparmor label from p-a then yes, I agree
<zyga> morphis: it all depends on our ability to patch this and SRU
<morphis> zyga: not necessarily, we could start with simply denying audio for every request coming from a snap basing on the snap.* apparmor label
<zyga> morphis: +1000
<zyga> morphis: let's do it
<zyga> morphis: you have my support and I'm sure jdstrand will agree
<morphis> ok
<morphis> zyga: I can prototype something real quick in pa
<zyga> morphis: fantastic
<zyga> morphis: I have little knowledge of pa and yet less ability to patch it quickly
<morphis> zyga: ok
<niemeyer_> ogra_: About config.txt in the RPi, we didn't settle down on a design yet.. we know at least the gadget snap will be able to conveinently tap onto it
<ogra_> yeah, thats what i was remembering, there was no specific design yet
<ogra_> sborovkov, so for now an editor it is ...
<HollyRain> how does snappy is related to LXD? Are they complementary technologies or the opposite?
<zyga> HollyRain: different I would say :)
<HollyRain> zyga, If I understand both technologies,if you use a server with snappy then don't need LXD, right?
<ogra_> snaps do not run in containers by default ...
<zyga> HollyRain: I think they are orthogonal really
<zyga> HollyRain: as ogra_ just said, snappy doesn't put a container around apps
<ogra_> i.e. they run natively but in a guarded native environment ...
<ogra_> and they have to ship all their dependencies inside ...
<ogra_> you *can* use lxd in a snap if you feel like (or docker) ... but a normal snap is just a natively installed thing
<HollyRain> ok, then snappy is going to kill lxd, at least in servers
<ogra_> no
<ogra_> imagine a snap that simply uses multiple containers ... spawns them on demand etc ...
<jdstrand> morphis: I think I suggested something rather similar. I guess you are aware of the touch overlay pulseaudio that has identified the mediation points and reaches out to trust-store?
<morphis> jdstrand: yes
<morphis> jdstrand: I had a discussion with tvoss about this last week
<ogra_> just using ldx for a single instance is surely just over-engineering things ... but lxd definitely has its use in snaps
<ogra_> *lxd
<jdstrand> morphis, zyga: I'm totally fine with first iteration mic is blocked if connecting process has label starting with 'snap.'
<morphis> jdstrand: we have some kind of a plan in our heads how we could implement trust-store in snappy but that needs more time and discussion
<morphis> so blocking all snaps from mic is the best first thing we can do
<jdstrand> morphis: cool-- I pointed tvoss at my ideas in one of the PRs, glad people are discussing it :)
<morphis> jdstrand: I think your comment was the starting point for this :-)
<jdstrand> \o/
<jdstrand> :)
<sborovkov> ogra_: editor is not a possibility :-( Devices will be only remotely available. And without ssh
<ogra_> hmm, sounds risky, why/what do you need to edit ?
<ogra_> (i mean ... why on the fly)
<sborovkov> ogra_: Overscan might need to be enabled/disabled. Or for instance hdmi_mode and hdmi_group - in my case I connect monitor which has DVI only, no HDMI, rpi does not detect proper resolution
<ogra_> hmm, is there no sysfs interface that you could use after boot
<sborovkov> AFAIK it's all done with changing config.txt.
<sborovkov> Also let's say user wants to rotate screen
<sborovkov> that also needs chaning config.txt
<morphis> jdstrand: you have some code anywhere how I can determine the apparmor label for a given pid?
<tedg> morphis: man aa_gettaskcon
<morphis> tedg: thanks!
<tedg> morphis: Oh, just aa_getcon, then gettaskcon is there
<morphis> so something like aa_gettaskcon(my_app_pid, &out_label, &out_mode)?
<morphis> do I need any context init or so?
<tedg> No, I believe it just is a syscall to the kernel
<tyhicks> morphis: no context init is needed
<tedg> FWIW, adding this to UAL so that we can interpret between Click and Snap labels. As they're different.
<tyhicks> morphis: but keep in mind that using a pid to look something up is almost always racy
<tedg> (not sure what you're working on)
<morphis> tyhicks, tedg: just trying to pull the security label from within pulseaudio to deny audio recording for any snap app
<morphis> and the only thing I get upon connection is the pid
<tyhicks> morphis: perfect - you want to use aa_getpeercon() instead
<tyhicks> morphis: it is in the same man page
<morphis> tyhicks: ok
<tyhicks> morphis: it takes the socket fd as input instead of the pid
<zyga> tyhicks: o/
<tyhicks> hi zyga :)
<tyhicks> zyga: is there a feature bug covering bind mount support for interfaces?
<tedg> morphis: How are we doing the trust store integration with clicks? Is that a PA module?
<morphis> tedg: yes
<niemeyer_> jdstrand: Heya
<morphis> tedg: https://anonscm.debian.org/cgit/pkg-pulseaudio/pulseaudio.git/tree/debian/patches/0409-Trust-store-patch.patch?h=ubuntu
<zyga> tyhicks: nope, not yet
<niemeyer_> jdstrand: Do you have some input for that "Making a snap of an icon theme" thread?
<ysionneau> someone has the link to launchpad to the rpi2 kernel snap.yaml?
<niemeyer_> jdstrand: It's strange that the logs are showing denials despite the snap being in devmode
<niemeyer_> jdstrand: There are separate issues about making gsettings happy, but that on itself sounds awkward and worth looking
<tedg> morphis: Cool, thanks!
<sborovkov> Hi. Let's say I install snap in devmode - is it possible to lock them down remotely later? remove devmode with newer version of snap
<zyga> ysionneau: I may
<morphis> tyhicks: hm, need to see if I can unwrap the actual connection fd from within my pulse module
<zyga> ysionneau: https://wiki.ubuntu.com/SnappyHackerUsefulLinkCollection
<morphis> tyhicks: so when does retrival through the pid becomes racy? when the security label isn't yet assigned but the client has already connected to pulse?
<ysionneau> thanks zyga !
<tyhicks> niemeyer_, jdstrand: I just responded to the icon theme thread
<tyhicks> niemeyer_, jdstrand: AFAICT, the gsettings issue problems in devmode aren't caused by confinement
<tyhicks> zyga: seb128 was wanting to follow along with the progress - once one of us files a bug, we need to subscribe him
<seb128> zyga, tyhicks, thanks ;-)
<zyga> tyhicks: I can do it now
<tyhicks> zyga: that'd be good (I need to call into a meeting)
<Trevinho> jdstrand: you got hello-unity working?
<jdstrand> not yet, I've been arguing in #ubuntu-desktop
<jdstrand> and about to head to a meeting
<jdstrand> but after that, I will be looking at it
<Trevinho> jdstrand: ok
<jdstrand> morphis (fyi tyhicks): see https://trello.com/c/ftSp1Ogp/649-implement-aa-query-file-fd-to-fix-toctou-issues-with-using-aa-query-file-path for how to do it safely until the new api is in place
<jdstrand> actually, I can paste that
<tyhicks> jdstrand: that's a different problem
<jdstrand> http://paste.ubuntu.com/16475967/
<jdstrand> ah, ok
<morphis> jdstrand: thanks!
<tyhicks> morphis: that's for a different issue
<morphis> ah
<sborovkov> Is it possible to go from --devmode to usual settings with snap update? Without doing anything manually?
<tyhicks> morphis: sorry I missed your question earlier
<tyhicks> morphis: the use of the pid can be racy if you pull the AA context of the pid, using aa_gettaskcon(), decide that it should be allowed, and then that pid exits and gets reused
<morphis> tyhicks: ah
<tyhicks> morphis: the new process may not have the same AA context
<morphis> tyhicks: as long as we don't store the decision things should be fine then, right?
<tyhicks> morphis: probably so
<morphis> as with the implementation I did so far the label is retrieved again for any new request to record audio based on the pid and checked than if it starts with snap.
<tyhicks> morphis: that sounds ok
<morphis> tyhicks: thanks
<tyhicks> morphis: how are you getting the pid?
<morphis> tyhicks: pulse is handing it in on a connection attempt, need to check how it retrieves it but I guess it checks the credentials of the connecting peer
<zyga> tyhicks: https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1582781
<ubottu> Launchpad bug 1582781 in Snappy Launcher "snapd needs a way to control mount points " [Undecided,New]
<tyhicks> zyga: thanks! I'll do a brain dump of what I intend to implement in the launcher
<zyga> tyhicks: thanks!
<zyga> tyhicks: can we actually bind mount /usr/share/fonts over /usr bind mounted from os snap?
<zyga> tyhicks: I was thinking that it might be tricky :)
<tyhicks> zyga: that'll work but we need to get the ordering correct
<tyhicks> zyga: snapd will need to output the default classic bind mounts at the top of the fstab file
<zyga> tyhicks: what is the right order? /usr bind mount will hide /usr/share/fonts, no?
<tyhicks> zyga: /usr needs to be bind mounted first, then /usr/share/fonts can be bind mounted
<zyga> but, from where?
<zyga> that's the problem
<zyga> source is gone
<tyhicks> zyga: oh, I see
<zyga> could be tricky
<tyhicks> zyga: agreed
<zyga> we could create an empty / somewhere, populate it
<zyga> and chroot
<zyga> anyway
<zyga> "left as an exercise to the reader"
<tyhicks> yes
<tyhicks> I'll give it some thought (still in meeting)
<zyga> sure, no worries
<morphis> awe, zyga: first draft on the pulseaudio-snappy-policy impl: https://paste.ubuntu.com/16476981/
<morphis> not tested yet
<awe> thanks morphis
<morphis> awe: ah, I meant jdstrand :-)
<morphis> awe: but feel free to have a look too
<awe> haha
<morphis> more gaining pulseaudio knowledge is always what we look for :-D
<morphis> jdstrand, zyga: will test and finish this tomorrow, packages are at https://requests.ci-train.ubuntu.com/#/ticket/1428
<zyga> morphis: you should free the label obtained from aa
<zyga> morphis: around line 129 in the diff
<zyga> morphis: otherwise this leaks memory
<Facu> hello! I'm failing to understand how to connect an app to an interface, I'm kind of lost about what is a plug and what is a slot (specially because the "connect" section in "man snap" doesn't mention the app at all)
<zyga> Facu: hey
<Facu> hola zyga
<zyga> Facu: plug is the "using/consuming" side of an interface
<zyga> Facu: slot is the "providing" side
<zyga> Facu: you can use: snap connect snap-name:plug snap-name:slot
<zyga> Facu: to connect the plug to a slot, the snap names are typically different
<Facu> zyga, ok; so I do "sudo snap interfaces", and under the slot column there is ":home", but which snap provides that?
<zyga> Facu: ubuntu-core
<zyga> Facu: that will be quite a lot easier soon, just not in sru-2
<Facu> zyga, and how do I get from the app to the plug? my app is named  spongeshaker.sha3sum, but I tried  "sudo snap connect spongeshaker.sha3sum:home ubuntu-core:home"  and it tells me that:  cannot connect plug "home" from snap "spongeshaker.sha3sum", no such plug
<zyga> Facu: you don't connect apps, you connect snaps
<zyga> Facu: put the home interface on the appropriate apps in your snap
<zyga> Facu: then connect with: sudo snap connect spongeshaker:home ubuntu-core:home
<zyga> Facu: plug name is "snap-name.plug-name" not ".app-name"
<Facu> zyga, when you say to "put the home interface on the appropiate apps", that is in the .yaml before building the snap?
<zyga> Facu: yes
<zyga> Facu: http://www.zygoon.pl/2016/04/snappy-snapcraft-and-interfaces.html
<zyga> Facu: http://www.zygoon.pl/2016/04/snappy-interfaces-plugs-slots-connections.html
<zyga> Facu: that should help you
<Facu> zyga, awesome, thanks! I was reading here and didn't find anything regarding interfaces: https://developer.ubuntu.com/en/snappy/build-apps/snapcraft-syntax/
<zyga> Facu: we're working on making developer.ubuntu.com docs much better
<jdstrand> morphis: nice! (though shouldn't line 122 be PA_HOOK_CANCEL? that's a scary conditional to say ok to)
<Facu> zyga, ah, ahora I see the plug listed in "snap interfaces", awesome
<mhall119> Trevinho: are you still around?
<jdstrand> tyhicks: how is this text: http://paste.ubuntu.com/16480381/
<HollyRain> at snapcraft, there a plugin for 'go', could be passed any argument to go compiler?
<tyhicks> jdstrand: sounds great
 * jdstrand posts
<jdstrand> tyhicks: thanks
<thomi> Hello everyone, does anyone know who I should talk to about debugging / fixing  https://bugs.launchpad.net/snapcraft/+bug/1582513 ?
<ubottu> Launchpad bug 1582513 in Snapcraft "snapcraft python3 plugin generates invalid snaps" [Undecided,New]
<thomi> sergiusens: perhaps you know? ^^
<jdstrand> Trevinho: I finally tried hello-unity and commented in the MP
<davidcalle> Facu: zyga: the Interfaces doc is located here: https://developer.ubuntu.com/en/snappy/guides/interfaces/
<Facu> davidcalle, thanks, found the .md in the repository for that :)
<davidcalle> Ok :)
<Facu> thomi, I just created a snap using python3, and it worked
<thomi> Facu: hmmmm. Any ideas what the issue might be? A virtualenv created for the same source doesn't pull in that library...
<Facu> thomi, I got the example from here: https://github.com/ubuntu-core/snapcraft/tree/master/examples/py3-project
<Facu> thomi, maybe you can try that one, and if it fails is something from your installation (or something from mine that luckily made it work ok)
 * thomi clones
<Facu> thomi, the snapcraft building worked ok; the example is useless because it doesn't declare the :home plug, but that's another issue
<thomi> Facu: are you willing to try the snapcraft.yaml file from the bug? I'm building the example now
<Facu> thomi, just put that alone in a dir and run snapcraft?
<thomi> Facu: yup
<thomi> Facu: iiiinteresting, the py3-project example pulls in that lib for me too
<thomi> https://www.irccloud.com/pastebin/7MXh7bMs/for%20example%3A%20
<Facu> thomi, http://linkode.org/FYzDlwbz8TbhilmWVO1nL7
<thomi> Facu: what does "find . -name "libmvec.*"" show?
<thomi> Facu: I can build the snap, but it fails review since it contains a symlink to that library for some reason
<Facu> thomi, http://linkode.org/FYzDlwbz8TbhilmWVO1nL7/4tbXGNxYHXnthEO6RbG5a2
<thomi> Facu: same as me. I bet if you try and upload the snap it'll be rejected :(
<Facu> thomi, upload through where?
<Facu> thomi, the web ui?
<thomi> Facu: yeah - but it'll fail since the name is registered to me.
<Facu> thomi, I can try staging
<thomi> ahh, good idea
<Facu> thomi, I think it all worked ok... it's public, you can see this AFAIK: https://myapps.developer.staging.ubuntu.com/dev/click-apps/681/
<thomi> Facu: nope, I get 403 - it worked though? That's odd - maybe I should try re-uploading it to prod
<Facu> thomi, you should be able to search for it, in staging, right?
<thomi> Facu: hmmm, how? The UIs all changed since i last looked.
<mhall119> sergiusens: ping
<Facu> thomi, so, upload fails for me too, as we saw
<Facu> thomi, that said, the snap works!
<thomi> yeah, any idea who I should ping about this?
<Facu> thomi, I mean, the example one, I installed and used it
<Facu> thomi, so it probably is not the snap that is wrongly built, but the automatic reviewer?
<thomi> Facu: that's part of sca, right?
<roadmr> thomi, Facu : jdstrand could tell you why the click-reviewers-tools script is failing a particular package
<thomi> jdstrand: I'm seeing lint-snap-v2:external_symlinks fail, both for my own python3 snap (http://paste.ubuntu.com/16482061/) as well as the py3-project example from the snapcraft repo
<thomi> jdstrand: the symlink it's complaining about is libmvec
<Facu> jdstrand, note that I built the py3-project example, installed locally, and it works
<Facu> thomi, roadmr â
<jdstrand> may I see the review tools error?
<thomi> jdstrand: sure, one sec
<Facu> jdstrand, "package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks"
<thomi> beat me to it :D
<jdstrand> right
<jdstrand> that indicates a real problem with your snap
<jdstrand> it is pointing to something outside of itself
<thomi> jdstrand: this is using the example py3-project snap from the snapcraft repo
<jdstrand> sounds like a bug in the snapcraft repo
<thomi> jdstrand: any idea who to talk to about that?
<jdstrand> kyrofa (cc sergiusens (just for bacscroll, stay away on holiday)): ^
<Facu> jdstrand, thomi, I opened the snap: it looks like there are a lot of symlinks pointing to outside: http://linkode.org/y6AKZ3Iq9Hzsoi0Ic0nui4
<jdstrand> iirc, some are required
<jdstrand> there is a list and the review tools won't complain about ones in that list
<Facu> in any case, the libmvec looks like pointing outside, indeed:  libmvec.so -> /lib/x86_64-linux-gnu/libmvec.so.1
<Facu> so, snapcraft is building badly the .snap
<jdstrand> but the libmvec.so might need to be one of those
<jdstrand> I see that it is part of libc6
<jdstrand> can one of you file a bug against snapcraft and add a click-reviewers-tools task?
<thomi> I'll add a test to https://bugs.launchpad.net/snapcraft/+bug/1582513
<ubottu> Launchpad bug 1582513 in Snapcraft "snapcraft python3 plugin generates invalid snaps" [Undecided,New]
<thomi> jdstrand: done
<jdstrand> thanks
<thomi> thanks for your help Facu , jdstrand
<Facu> thomi, thank you!
<Facu> jdstrand, roadmr, thank you too :)
<thomi> Hopefully we can find a solution soon, I really want to upload my snap to the store :D
<roadmr> I did nothing :)
#snappy 2016-05-18
<zyga> good morning
<qengho> zyga: good...morning
<ngaio> hi all good morning / afternoon. Hey how do I minimize the amount of packages being pulled down when I do a pull. I'm on a metered Internet connection and pay by the MB. I'm taking my first steps to building a snap, and it seems when I pull one part, it downloads all over again the same packages for another part
<qengho> ngaio: Could you not clean up the part that downloads a lot?
<ngaio> qengho, I didn't clean anything
<ngaio> all I did was one pull, then another
<qengho> ngaio: what kind of section do you have that lists packages?
<ngaio> where can i copy & paste a sample?
<qengho> paste.ubuntu.com
<ngaio> http://paste.ubuntu.com/16486317/
<ngaio> there is a problem with the pyzmq package-- i can't figure out how to specify the version
<ngaio> it's failing there
<ngaio> but that's a different problem
<qengho> probably "pyzmq=15.1.0", fwiw
<qengho> That's an APT-ism.
<ngaio> I couldn't find that anywhere in the online docs or in the comments in the plugin source
<qengho> Oh, but that's not the package you mean.
<ngaio> no it's not an ubuntu package.... it's a pypi package
<qengho> Different kind of package, right?
<qengho> Right.
<qengho> ngaio: For development, I think you can probably put a full local filename path instead of Ubuntu packages, and perhaps of Python packages, and your local cached files will be used instead. I think. Maybe. Possibly.
<ngaio> qengho, that would be a big help when it comes to my internet usage, if it works!
<qengho> ngaio: I have never tried it for "package" things, just for large source tarball sources.
<qengho> ngaio: The snapcraft sources are not too hard to read. You should look into what the python source does, to see if it takes a version.  $ dpkg -L snapcraft
<qengho> ngaio: And if versions are a common thing to specify, then file a bug report to ask for it.  $ ubuntu-bug snapcraft
<qengho> And even "debpackage=version" doesn't work. Sigh.
<qengho> Bed time.
<ngaio> qengho, thanks for your help... I'm looking at the source now
<morphis> zyga: ping
<zyga> morphis: o/
<zyga> morning
<morphis> zyga: morning
<morphis> zyga: have a first draft for a pulseaudio slot part of the interface
<morphis> zyga: but wondering if we don't want to do an audio interface too which abstracts the kernel access for audio devices
<zyga> neat! what's the pull request number?
<zyga> morphis: like alsa?
<morphis> zyga: no PR yet
<morphis> zyga: like also, yes
<zyga> morphis: so pulse would consume alsa and expose pulse?
<morphis> yes
<zyga> mmm, I guess the answer is, perhaps
<zyga> but I'd wait with that for a real consumer
<zyga> and for hooks
<morphis> ok
<zyga> e.g. you assign alsa, cannot use pulse yet
<morphis> then lets add those things to the pulse interface for now
<zyga> it's sensible just more complicated to model
<zyga> yep
<morphis> sth like hw-assign doesn't exist anymore, right?
<zyga> morphis: correct
<morphis> good
<morphis> zyga: either I base my PR on top of yours or I do a new one covering yours and mien at the same time
<zyga> morphis: is there an actual difference?
<zyga> morphis: do you have an idea when we can land pulseaudio record lockout?
<zyga> morphis: and I wonnder if you saw my message about the memory leak last night
<morphis> zyga: (message) saw it and fixed the leak
<morphis> zyga: the change needs testing and review
<morphis> zyga: and need to find out who maintains pulse these days :-)
<morphis> maybe seb128 knows
<zyga> morphis: do you have a plan to SRU it anytime soon?
 * seb128 doesn't know anything
<seb128> hey there :-)
<zyga> seb128: hey :)
<morphis> zyga: no concrete
<morphis> seb128: hey
<seb128> morphis, zyga, TheMuso maintains pulseaudio for us
<seb128> you can find him on #ubuntu-desktop/devel
<morphis> seb128: thanks!
<seb128> but he's .au based might be off for the evening already
<seb128> yw
<morphis> zyga: I must say I never did a real SRU yet
<morphis> so would be good if we could just hand this to somebody
<seb128> morphis, zyga, I can help you ... what serie do you want to SRU to?
<morphis> seb128: xenial
<seb128> just get a bug on launchpad with the patch
<zyga> morphis: can you build pulse in a ppa somewhere
<seb128> and give me the number
<seb128> we can handle the SRU process
<zyga> morphis: or just listen to seb128
<morphis> seb128: sounds great!
<morphis> seb128, zyga: have it in https://requests.ci-train.ubuntu.com/#/ticket/1428 already but still under testing
<seb128> morphis, we need a bug anyway for SRU process
<morphis> seb128: ok, let me create one then
<fgimenez> hey mwhudson, i'm getting http://paste.ubuntu.com/16486677/ while trying to execute snappy's integration test suite and have been told that you could help me with that
<fgimenez> mwhudson, sorry if that's not the case :) could you please have a look at it?
<zyga> morphis: is there any tiny app we can use to demo the fact that recording is forbidden
<morphis> zyga: on the way building one
<morphis> seb128, zyga: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/1583057
<ubottu> Launchpad bug 1583057 in pulseaudio (Ubuntu) "Deny audio recording for all snap applications" [Undecided,New]
<seb128> morphis, thanks
<seb128> morphis, zyga, lol, I though you guys wanted to fix a leak ... adding a new module is not going to be as easy by SRU rules
<zyga> seb128: it's data privacy leak ;)
<zyga> seb128: can we get help somewhere?
<zyga> summon some super powers or something?
<morphis> seb128: :-)
<seb128> zyga, no, need to play by the rules, https://wiki.ubuntu.com/StableReleaseUpdates
<seb128> zyga, but basically could you put the rational/test case/regression potential
<seb128> like rather is "needed for snappy"
<seb128> we can get it uploaded&co
<seb128> I'm just unsure the SRU team is going to be too happy about it
<zyga> seb128: understood, we'll do our best
<mwhudson> fgimenez: huh
<mwhudson> fgimenez: go version?
<zyga> morphis: I think we should test this thoroughly on random non-snappy apps to ensure there's no impact
<zyga> morphis: and play the only-affects-snappy card as a regression potential
<mwhudson> fgimenez: also, reproduction instructions?
<mwhudson> fgimenez: i guess it must either be s390x or yakkety?
<morphis> zyga: that is the plan
<morphis> zyga: the module shouldn't have any impact on non-snappy apps
<morphis> and still simply allows recording
<morphis> zyga: you have time to test this one too?
<zyga> morphis: yes, I will gladly help
<morphis> great
<zyga> especially now when I'm just about as sleepy as I can
<morphis> zyga: :-)
<fgimenez> mwhudson, yes, yaketty, more about the environment http://paste.ubuntu.com/16486953/
<fgimenez> *yakkety
<mwhudson> fgimenez: ok, i think that should be working so i'll have a poke
<fgimenez> mwhudson, ok thanks, to reproduce from a working $GOPATH "mkdir -p ./github.com/ubuntu-core && cd ./github.com/ubuntu-core && git clone https://github.com/ubuntu-core/snappy && cd snappy && go run ./integration-tests/main.go"
<fgimenez> in fact from $GOPATH/src
<mwhudson> fgimenez: well hooray, it works for me
<mwhudson> fgimenez: can you run go run -x ./integration-tests/main.go and show me the output
<fgimenez> mwhudson, sure http://paste.ubuntu.com/16487054/
<mwhudson> fgimenez: doesn't look like you're running /usr/bin/go
<mwhudson> fgimenez: /home/fgimenez/src/go/pkg/tool/linux_amd64/compile
<mwhudson> fgimenez: i don't maintain that one :-)
<fgimenez> mwhudson, oops thanks! will try with the package version, sorry for the noise
<mwhudson> fgimenez: heh nw
<sborovkov> Hello, asked this question yesterday, but no one answered. May be better luck today. Let's say I install snap in --devmode. If I upgrade to newer version of snap - can I automatically remove --devmode somehow
<kyrofa> Good morning
<morphis> zyga: you had time to take a final look at https://github.com/ubuntu-core/snappy/pull/1036 ?
<zyga> morphis: not fully but I think we should land it
<morphis> zyga: ok, then lets do that
<morphis> zyga: so when you merge it today, when will we have it in xenial?
<zyga> morphis: next week
<zyga> morphis: every Wed AFAIR
<morphis> end of next week?
<zyga> morphis: we have one SRU in the pipe now
<zyga> morphis: if it lands now it will be released next week
<zyga> jdstrand: do you have any last comments on n-m interface?
<noizer> Hi zyga
<noizer> zyga how are you?
<noizer> zyga I have a strange problem with copying the armel build (chroot) to my snap
<noizer> zyga here you got a minified yaml file of my snap http://paste.ubuntu.com/16490708/
<noizer> zyga and thats the error [Errno 2] No such file or directory: '/home/ubuntu/software3003/parts/
<noizer> staticfiles/build/./armel/usr/share/zoneinfo/localtime'
<jdstrand> zyga: I want to go through the recent comments, yes. I have a couple of meeting so it will be a couple of hours
<jdstrand> meetings*
<zyga> jdstrand: sounds good, thank you
<zyga> noizer: hey :-)
<zyga> noizer: sudo won't work there
<zyga> noizer: as in, in is not allowed
<zyga> noizer: I would suggest you to put this into a wrapper script and not put everythiong on one long line
<noizer> zyga ok but my snapcraft build won't build :s
<zyga> noizer: why?
<noizer> zyga  [Errno 2] No such file or directory: '/home/ubuntu/software3003/parts/
<noizer> staticfiles/build/./armel/usr/share/zoneinfo/localtime'
<zyga> noizer: I'm not sure what that error means, perhaps this should be reported to snapcraft
<noizer> zyga Wait I will try some other things and then report it if it is nec.
<zyga> noizer: I would also suggest you to make the snap manually
<zyga> noizer: just use mksquashfs on it, put meta/snap.yaml in place
<zyga> noizer: and see what happens
<morphis> zyga: how do I get the bot to run all tests on my PR?
<morphis> wasn't there a command to do that?
<zyga> morphis: "retest this please"
<zyga> but it may be picky as it may not let you do it
<zyga> let me run that for you
<noizer> zyga Ok I'll try that
<zyga> morphis: running now
<zyga> morphis: n-m one
<morphis> zyga: thanks
<Facu> question: when packaging a snap, where should I put the "man" page?
<qengho> Facu: it doesn't matter, because outside "man" can't find it.
<Facu> qengho, how the man pages, or this kind of documentation in general, is handled in the snap world?
<qengho> Facu: You might want to add a new app: help: command: cat $SNAP/formatted_man_page
<morphis> zyga: do we have any possiblity to populate udev rules from a snap?
<morphis> and not as part of an interface?
<Facu> qengho, ack, thanks
<zyga> morphis: no, but an interface can
<zyga> morphis: what do you need?
<zyga> morphis: (so a permanent snippet on a slot could do it)
<morphis> zyga: for modem-manager we have device specific udev rules
<morphis> and putting them into a interface is not what we should do
<zyga> morphis: hmmmmm
<zyga> morphis: perhaps it is, just in the slot definition itself
<zyga> morphis: we talked about having device specifc stuff in a slot, (pinging ricmm for context if needed)
<zyga> morphis: think about it
<morphis> zyga: you mean as parameter?
<zyga> morphis: we could have a "hardware-enablement" interface or similar
<morphis> yes
<zyga> morphis: and we'd stick it on the kernel snap
<zyga> morphis: and connect to mm
<zyga> morphis: (so the plug would gain the real power)
<zyga> morphis: but the slot would say what the powers are
<morphis> hm
<morphis> zyga: kernel / gadget snap sounds like a possible thing
<zyga> morphis: I'm going to pick up kids from school now, bbl
<zyga> morphis: ping me with details please or use email
<morphis> zyga: will do
<kyrofa> elopio, are you around today?
<zyga> re
<jdstrand> mhall119 (CC Trevinho): hey, you said in https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 'and am also getting some apparmro denials' -- what were they? if they are the ones I mentioned in the MP then I think there is more work to do on the MP
<didrocks> hey kyrofa, how are you?
<kyrofa> didrocks, hey! How's Texas?
<kyrofa> And I'm doing well :)
<didrocks> kyrofa: rainy :p
<kyrofa> Yikes
<kyrofa> All legs of my flight were delayed because of thunderstorms over that area
<kyrofa> And it's still going?
<didrocks> no, it's stopped right now
<kyrofa> Oh, okay
<didrocks> but it was quite impressive :)
<kyrofa> I bet it was!
<didrocks> yeah :)
<didrocks> I was wondering how you generally approach this: I'm trying to snap galculator, but as most of project, they hardcode datadir at compile time to fetch resources at runtime
<didrocks> but ofc, then, nothing is available at runtime on /share ;)
<kyrofa> Ah yes
<kyrofa> Pretty typical problem
<didrocks> and ofc, changing datadir in the configure flag make it install relative to that path
<didrocks> so that doesn't even workaround the issue
<didrocks> (be installed in /snap/galculator/current/snap/galculator/current/share/foo for instance)
<kyrofa> So the way I solve it typically depends on the project. Lots of projects that need to reach out like that also support configuration files. No go there?
<didrocks> well, I can setup datadir=/snap/galculator/current as a workaround for now
<didrocks> but
<jdstrand> zyga: hey, I had a number of PRs for unity7 interface that I was hoping would be in 2.0.4, but it seems they weren't committed. should I be doing something differently?
<didrocks> then, it influences the installation path
<jdstrand> aiui, I request, it gets a review, but then I was told someone else needs to commit
<kyrofa> didrocks, yeah, I see what you mean
<didrocks> kyrofa: apart from patching upstream, I don't have a good idea on how to resolve this
 * seb128 is interested as well
<kyrofa> didrocks, so no config file, and no runtime flag available either?
<didrocks> nothing that I saw in the code
<kyrofa> didrocks, I've not actually encountered a project that was so inflexible
<kyrofa> didrocks, yeah the only option I see left is to maintain a fork and try to move a runtime flag upstream
<kyrofa> (or a config file, if you like that better)
<ogra_> hexedit !
<kyrofa> ogra_, hahaha
<didrocks> kyrofa: no way to patch I guess?
<kyrofa> didrocks, not yet, but you're not the first to ask
<zyga> jdstrand: no, I guess just bash me more often
<zyga> jdstrand: 2.0.4 is last Friday
<didrocks> which is making taking all goodness of getting things from last upstream hard
<kyrofa> didrocks, it needs some thoughtful design
<zyga> jdstrand: 2.0.5 aka 2016W20 is next week so don't worry, we'll just merge them
<seb128> didrocks, kyrofa, Trevinho made a quilt plugin in https://code.launchpad.net/~3v1n0/snappy-playpen/hello-unity-fixes/+merge/294858 to apply a patch at build time
<seb128> sharing one of the existing workarounds invited by people around
<Trevinho> it's hacky, eh...
<seb128> Trevinho, good morning! ;-)
<Trevinho> seb128: hey... Sort of :)
 * zyga wonders where is the person that was working on arch support
<didrocks> thanks seb128, Trevinho, kyrofa
<didrocks> kyrofa: yeah, it's quite hackish and will need to rewrite a good part of upstream
<didrocks> and I bet GNOME is mostly the same
<didrocks> seb128: do you have any GNOME app snapped at all? (and working :p)
<seb128> didrocks, https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap
<seb128> didrocks, our list if issues is on https://bugs.launchpad.net/ubuntu/+bugs?field.tag=snap-desktop-issue
<Trevinho> jdstrand: mhmh... I've got the thing running here unconfined, but yes... maybe it doesn't work unconfined because it can't access to some local files.. .I didn't check that yet...
<seb128> didrocks, the branch from Trevinho I just pointed has some improvement I'm looking at now
<kyrofa> didrocks, which files are we talking about here?
<seb128> like generating caches are runtime
<ogra_> zyga, blackout24 you mean ?
<Trevinho> jdstrand: probably hello-unity python installer has something wrong...
<jdstrand> Trevinho: right, I'm talking about when not using --devmode
<ogra_> (obviously not here atm)
<Trevinho> or it's wrong the way snapcraft handles it
<jdstrand> Trevinho: and the accesses indicate it is using some weird paths
<didrocks> kyrofa: lp:~didrocks/+junk/galculator-snap for instance, here is the output (installed with --devmode): http://paste.ubuntu.com/16494689/
<Trevinho> seb128, didrocks: my plan was to move those script in something like a build plugin that can generate something at build time
<zyga> ogra_: thanks!
<didrocks> seb128: yeah, like the gdk pixbuf issue as well ^
<Trevinho> since something (like gsettings cache, or mime or icon cahces) can be done at that level
<Trevinho> seb128: it would be quite easy to do. We can do it.
<kyrofa> didrocks, ah, so indeed something gnome-specific
<didrocks> kyrofa: well, Mate for this case, but yeah
<seb128> gtk*
<Trevinho> seb128: however, as discussed in bug #1551716, we should fix snapcraft to allow patching in a native way (or imho, just runing a script in between source pulilng and building). sergiusens if you can comment in what's your preferred approach in that, I could come with a PR.
<seb128> didrocks, seems like we are getting bind mount interfaces though, so that are going to be able to make things like mimetypes or pixbuf loaders work
<ubottu> bug 1551716 in Snapcraft "snapcraft does not allow vendor/platform patching of upstream sources (aka: add patch phase to lifecycle)" [Undecided,New] https://launchpad.net/bugs/1551716
<didrocks> seb128: oh, so we will be able to bindmount some files?
<seb128> Trevinho, imho we require to apply patches to upstream code to work on snap we loose
<zyga> didrocks: we're getting support for that
<seb128> didrocks, seems o
<seb128> so
<zyga> didrocks: there is a bug open on snappy and ubuntu-core-launcher
<zyga> didrocks: ~ next week
<kyrofa> didrocks, yeah, we need that for fonts, locales, etc.
<didrocks> kyrofa: zyga: ok, that wouldn't help that .ui file though (which is part of upstream's project)
<didrocks> basically in one Makefile.am:
<didrocks> uidir = $(datadir)/galculator/ui
<zyga> though note that it's not a way to just load random files from classic
<didrocks> so changing datadir change uidir, which is where things are stored
<seb128> didrocks, the --prefix=... should work for that case though?
<kyrofa> Trevinho, seb128 yeah at least from my perspective I keep getting conflicting requests about patching/not patching and how it relates to contributions upstream
<Trevinho> jdstrand: yeah... it's weird that those paths are hardcoded. Not sure what's doing the setup.py under the hood, but it doesn't seem anything particular hard... However I just focused in getting compoments to run. So... if you want o check the code further, I leave that in hold for a while
<didrocks> seb128: hum, using --prefix=/snap/galculator/current/ ?
<kyrofa> sergiusens may have more information-- he'll be back on Monday
<seb128> didrocks, yes
<zyga> didrocks: note that /snap might change some day, it's better (though harder) to really understand $SNAP
<seb128> didrocks, otherwise get upstream to use gresources and have the .ui including in the binary ;-)
<Trevinho> kyrofa: well, patching is something we need to provide... People can't just fork a project when a patch can live without having to care about pulling at every upstream update.
<seb128> zyga, well, those are defined at buildtime
<seb128> zyga, those being the code function calling things on a path
<Trevinho> kyrofa: and Mark gave is +1, if I read correctly that bug.
<seb128> same for locales and bindtextdomain()
<seb128> they do
<seb128> bindtextdomain ("domain", LOCALEDIR)'
<zyga> seb128: and all of that can be moved
<didrocks> zyga: yeah, but here, we are quie in a blocked situation
<zyga> seb128: note that snap name can be changed too
<seb128> zyga, so what do you suggest doing?
<didrocks> seb128: sure, that's totally doable for delivering that this weekâ¦
<zyga> this is fine for a short term solution but IMHO patching the world to understand $SNAP in various low-level toolkits would be best
<kyrofa> Trevinho, ah, so did gustavo. Okay, that clears things up, I guess I missed that conversation
<seb128> that's bong
<seb128> we message snap as a way for upstream to ship their code unmodified by distro
<zyga> seb128: why?
<seb128> and now we tell them they need distro patches to work on our system
<seb128> head -> desk
<zyga> seb128: that doesn't mean some middleware layer must stay oblivious to what snaps are
<zyga> seb128: we had to patch nearly all major pieces
<zyga> seb128: (ask morphis)
<seb128> well, you loose adoption at this point
<seb128> the interfaces yes
<zyga> seb128: well, what is your suggestion?
<jdstrand> Trevinho: I may be able to work with what it there
<zyga> seb128: no, for paths
<seb128> but if you need to patch "randomcalc" code to change it's paths
<zyga> seb128: --prefix is never correct for a snap (it can move around)
<jdstrand> zyga: ack, thanks
<seb128> I suggest fixing that ^
<seb128> and making a predictable prefix
<zyga> seb128: that's a design decision that we've commited to
<zyga> seb128: this is not my decision but we shouldn't build everything against that
<seb128> well, it's fine
<seb128> it's just going to slow down adoption
<seb128> if upstream need to "fix" their code to work on snappy
<zyga> seb128: I suspect that is true
<zyga> seb128: but only for middleware pieces
<zyga> seb128: (most things should not care much)
<seb128> they do though
<zyga> seb128: but I agree in principle
<seb128> any gettext program calls
<seb128>  bindtextdomain ("domain", LOCALEDIR)'
<seb128> to read translations
<zyga> seb128: well, we could patch glibc (we plan to anyway)
<seb128> where LOCALEDIR is $prefix/usr/locale
<zyga> seb128: and a few other things to make that code correct in a snappy context
<seb128> and to fix calculator loading its .ui from $prefix/usr/share/ui you patch calculator
<seb128> you fork the world and end up maintaining patched versions of everything
<zyga> seb128: with $SNAP being relocatable, we have no other choice really
<didrocks> seb128: I don't see that specific issue (hardcoded paths) being in the bug list, should I open one or did I mis it?
<seb128> sounds like deb based ubuntu :p
<zyga> seb128: I mean that all of those patches should end up upstream
<zyga> seb128: or at least in ubuntu as patches for deb-based snaps
<seb128> didrocks, I mentioned it on https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1576282 which is one of those cases
<ubottu> Launchpad bug 1576282 in snapcraft (Ubuntu) "Snaps built from deb can't be gettext translated" [Undecided,New]
<zyga> seb128: anyway, sorry for derailing your discussion
<seb128> didrocks, but yeah, feel free to open one
<didrocks> seb128: let me open an explicit bug about it, shall we?
<didrocks> yeah
<seb128> thanks
<didrocks> ok, building with --prefix, and see how it goes
<seb128> zyga, it's not derailing, don't worry
<seb128> zyga, I'm ready to bet that you are going to figure out at some point that you need a way to fix that path problem other than asking every app in the world to patch their code to have a if (getenv(SNAP...)) hacks
<seb128> but let's see
<zyga> seb128: a kernel patch perhaps? :)
<zyga> something like /proc/self
<seb128> yeah
<zyga> seb128: though I think smart patches in glibc could do 90% of the work
<seb128> or maybe you need to divert libc and other libs in a wrapper changing the paths on fly for you :p
<zyga> seb128: we though ot LD_PRELOAD library or a runtime helper (added at link time) to "cure" some common issues
<seb128> I can see how one gets there
<seb128> but you are working around in hackish way for issues selft created :-/
<seb128> well the bind mount is at least going to solve a part of those
<seb128> locales, mimetypes, fonts, etc
<zyga> seb128: until we do personal and we expect those snaps to still work
<zyga> seb128: we have to be careful with bind mounts
<zyga> seb128: there's a reason we bind mount the os snap over regular ubuntu today
<didrocks> seb128: hum, modifying prefix modify destdir as wellâ¦
<seb128> didrocks, you can make install DESTDIR=..., which is what deb do
<kyrofa> seb128, that's what the autotools plugin does
<didrocks> yeah, unsure you can do that easily with snapcraft, kyrofa ^
<zyga> (sooner or later you will start patching, this is barganing phase of kubler-ross :/
<didrocks> kyrofa: hum, maybe I'm doing something wrong, but here is what I changed:
<didrocks> kyrofa:     configflags: ["--prefix=/snap/galculator/current/usr/"]
<kyrofa> didrocks, have you tried doing this standalone? Make sure the build system actually respects DESTDIR correctly?
<didrocks> and nothing else
<kyrofa> didrocks, because I've run into a few that don't
<kyrofa> didrocks, ohh, wait, try this
<morphis> seb128: this problem does not only affect us but also apps for xdg-app need adjustments from what I saw
<kyrofa> didrocks, there are two ways to install something. Set a prefix and install (in which case is goes to the prefix), or use DESTDIR to put it where you want it to go
<zyga> kyrofa: prefix and destdir serve different purpose but I'm sure you know that
<didrocks> kyrofa: yeah, I know that, did packaging for years ;)
<morphis> seb128: I don't see that $SNAP should be part of every opensource software but every software should be relocatable and not hardcode any paths
<seb128> morphis, most are relocatable but the destination is defined at build time
<morphis> seb128: right, and that is something which has to change somehow
<kyrofa> didrocks, yeah I figured you knew that from autotools, but what I mean to say is that the autotools plugin also supports that
<didrocks> kyrofa: what's the right combination then? I did try to set install-via desdir
<didrocks> destdir
<seb128> morphis, that's not going to change overnight and sort of conflicting with the goal of what main apps to be snapped by next week
<didrocks> (you have the branch, right?)
<kyrofa> didrocks, so: was there another flag you can use instead of prefix to get it using the right file?
<zyga> morphis: very true, this is a dual transition: from debs to snaps and from fixed prefix to "portable" installation
<morphis> seb128: I know that somebody tried something like overlayfs but somehow that didn't worked out
<zyga> morphis: overlayfs breaks aa
<zyga> seb128: would it change anything if we gave each app process a bind mount to /snap
<zyga> seb128: I mean to $SNAP
<didrocks> kyrofa: uidir is defined from datadir, which is set from prefix
<morphis> seb128: for network-manager/modem-manager/bluez we're patching things to understand $SNAP for now
<zyga> seb128: like /snap/self
<didrocks> but setting prefix seems to change make install dest directory
<morphis> seb128: but we're not putting those patches into any debian package
<zyga> seb128: being always bind mounted to /snap/$SNAP_NAME/$SNAP_REVISION/
<morphis> seb128: see https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/
<kyrofa> didrocks, eh... let me clone this thing. Hold on
<morphis> seb128: somewhat is this an interim solution
<zyga> (or perhaps a symlink though that is harder)
<morphis> zyga: yeah
<morphis> seb128: and something like --prefix=/snap/galculator/current/usr didn't really worked for us
<seb128> zyga, yeah, I guess having a stable path would make things much easier
<roadmr> jdstrand: hey, click-reviewer-tools r651 is finally out on the store. Apologies for the dlay
<zyga> seb128: we should be able to at least prototype something like that next week but I cannot promise the design will be approved
<morphis> as that will still end up as /snap/galculator/current/snap/galculator/current/usr
<seb128> morphis, you are getting n-m/bluez/etc upstream to take patches snap specific?
<morphis> seb128: if you don't strip the prefix again
<morphis> seb128: no
<morphis> seb128: we will not bring those patches upstream
<morphis> seb128: but longer term upstream needs to be relocatable at runtime
<seb128> right
<zyga> patch glibc, qt, gtk and you'll see most people not noticing
<zyga> (with a grain of salt)
<zyga> people bundle gtk/qt on windows so it has to "work"
<morphis> zyga: glibc/qt/gtk should be fine mostly
<zyga> morphis: yeah? including things like locale and fonts?
<morphis> seb128: and you can also write wrapper scripts like https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/bin/networkmanager to adjust things like HOME or LD_LIBRARY_PATH
<morphis> zyga: that is why I said "mostly" :-)
<kyrofa> didrocks, any chance you have your snapcraft recipe pushed somewhere?
<seb128> didrocks, hum, the --prefix= thing doesn't work because make install is going to install in that dir as well and you end up with having /snap/galculator/current/snap/galculator/current/usr as morphis said
<zyga> morphis: one more thing, we're getting support for controling environment variables from interfaces
<zyga> morphis: so we'll be able to pre-seed sensible variables for the most common stuff
<zyga> morphis: and also use interfaces to influence that
<morphis> zyga: sounds good
<seb128> morphis, right, that's we do, e.g http://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc
<zyga> (e.g. set something to see classic fonts when classic font interface is connected)
<morphis> zyga: I have a feeling that we two should sync up somewhere soon on what is coming and planed etc.
<morphis> feel like there are certain things we're really interested in
<seb128> morphis, that's quite hackish though, I doubt any upstream maintainer is going to find that being clean/something they can to do :p
<didrocks> kyrofa: sure, it's at lp:~didrocks/+junk/galculator-snap. I did try then multiple combinations of prefix and destdirâ¦
<didrocks> seb128: exactly
<morphis> seb128: I would simply ignore the "clean" part of this for now and get it working
<morphis> seb128: I remember that loic started with binary search&replace on NetworkManager coming from a deb
<seb128> morphis, that's what we are doing, but are also asked to get upstream adoption, which is more difficult in that case
<morphis> seb128: absolutely
<didrocks> kyrofa: another way is to move the whole datadir directory after install, even setting an incorrect prefix
<morphis> zyga: https://bazaar.launchpad.net/~ubuntu-desktop/+junk/gnome-calculator-snap/view/head:/calc#L3 is something we should provide from snappy
<kyrofa> didrocks, yeah, but then you're talking custom plugin or yucky makefile (I had to do that for apache)
<didrocks> yep
<didrocks> kyrofa: any better idea for now? :p
<kyrofa> didrocks, experimenting, give me a minute
<zyga> OMG :)
<zyga> morphis: thanks!
<morphis> jdstrand: you already had time to look on the nm interface?
<zyga> morphis: https://bugs.launchpad.net/snapcraft/+bug/1583259
<ubottu> Launchpad bug 1583259 in Snappy Launcher "Snappy needs to influence environment variables in applications " [Undecided,New]
<zyga> jdstrand: ^^
<zyga> tyhicks: (we talked about this at the sprint) ^^
<zyga> tyhicks: and gustavo wants it so I think we have agreement for the general direction
<zyga> seb128: ^^ I'd love to know if you have suggestions on what some defaults might be when people connect the unity7 interface to make more things work out of the box
<morphis> zyga: sounds good
<morphis> zyga: couldn't we also add a set of env variables from the gadget snap?
<zyga> morphis: that's somewhat more risky, can you give me a use case as a thought experiment?
<morphis> zyga: like on Ubuntu Touch we're supplying different env variables directly from the device tarball to adjust runtime behaviour
<zyga> morphis: remember nobody will review gadget snaps
<zyga> morphis: that's a lot of power
<morphis> zyga: like the device specific GU value
<zyga> morphis: I see, that's an interesting case
<morphis> zyga: why that?
<zyga> morphis: is that something mir consumes or something that each snap needs to have set?
<morphis> and we're adding more of them like to adjust the wifi management for different BSPs etc.
<zyga> morphis: why nobody will review gadget snaps?
<morphis> yes
<zyga> morphis: because we want many people to make devices and reviews don't scale
<morphis> same would apply for snaps, right?
<zyga> morphis: so the only choice is to confine and limit gadget snaps and let us land them without review
<zyga> morphis: yes but specifically the gadget snap has a very strong power over each device, we should not just let arbitrary things to go through it
<zyga> morphis: perhaps a gadget snap could announce meta-data that each snap could see?
<morphis> possible
<zyga> morphis: and snaps could then opt-into loading some things (just a random idea)
<morphis> yeah
<morphis> off to the future
<zyga> morphis: I see the need for this but I don't see a solution that's not a compromise over something
<zyga> yep
<morphis> zyga: most important thing for us will be udev rules supplied by either the gadget or kernel snap
<zyga> morphis: can you open a bug on that and add some back story (enough for us to drive the design discussion)
<zyga> morphis: I think this will be a gadget/kernel-snap (both perhaps) hardware-specific interface but I may be wrong
<zyga> morphis: specifically if snaps have to specifically connect to it
<zyga> morphis: and what exactly should be in those udev rules
<morphis> zyga: sure, can open that tomorrow
<zyga> morphis: thanks
<ssweeny> zyga, I'm trying to genericise the slotAppLabelExpr function and my go-fu is weak. Is there a way to make that function take either a slot or plug or do I need to make wrapper functions to call that logic?
<jdstrand> morphis: been in meetings all morning (both on the schedule and impromptu). I'm done with those for the day so going to eat then look at all the PRs, starting with nm
<morphis> jdstrand: great!
<jdstrand> zyga: interesting. I'm going to point tyhicks at that too since he is looking at something related to env handling
<oparoz> Will installing snaps on Ubuntu on Windows be supported?
<ogra_> heh
<ogra_> unlikely
<oparoz> OK :)
<ogra_> unless windows grows some kernel fetures
<ogra_> *features
<oparoz> Yeah, I was wondering what would be limiting the concept. Systemd might be another issue
<ogra_> systemd, apparmor, seccomp
<kyrofa> oparoz, yeah basically our entire confinement story is missing there, I imagine
<oparoz> That's a bit too much to make it work :)
<zyga> ssweeny: no generics in go, you need to fork it
<ssweeny> zyga, ack, thanks
<zyga> ssweeny: you might be able to move the common part to a helper that just takes the raw data (apps AFAIR)
<ssweeny> zyga, yeah that's what I was thinking. Just wanted to make sure I wasn't missing some idiomatic go thing that would be super easy :)
<zyga> ssweeny: I'm still new to go but I'm pretty sure there's no generics around
<ssweeny> zyga, apparently you can switch on type which is neat but I'd still have no idea how to pass the slot/plug in without them implementing the same interface at least
<zyga> ssweeny: you cannot switch types, you can "upcast" interface{} to a real type but you cannot "cast it" to something totally different
<ssweeny> zyga, I meant you can switch ON type like switch foo(type) case bool: <do stuff> case int: <do other stuff>
<ssweeny> syntax is probably wrong but that's the idea
<zyga> ssweeny: ah, yes you can do that
<zyga> ssweeny: switch foo.(type) AFAIR
<ssweeny> that's it
<ssweeny> but still no way to say "this function takes a plug or a slot and I'll figure out which it is in the body"
<ssweeny> I'll go ahead and factor the common stuff out
<zyga> ssweeny: well you can have it take an interface{}
<zyga> ssweeny: but that's not type safe then
<ssweeny> right
<zyga> ssweeny: I think that's the best we have for now
<zyga> ssweeny: we toyed with an idea to have a private base class for plug and slot but that wouldn't help you much
<ssweeny> zyga, I guess I could make an interface that covers the needed fields but by that point I've done more work than just factoring out the common code
<tyhicks> zyga: fyi regarding the env var bug> mvo is having trouble with the "... and ubuntu-core-launcher (to actually apply those variables to each started process)" part
<zyga> with the "..." and"?
<zyga> well, I don't suppose we can assume the env is really inherited
<tyhicks> zyga: some variables, such as LD_LIBRARY_PATH are being scrubbed when the launcher execs the app
<zyga> because that doesn't work on all the variables
<zyga> right
<zyga> oh?
<zyga> execs?
<tyhicks> right
<zyga> can we still set it after forking:?
<zyga> (I assume we must)
<zyga> both do it and must be really able to do it, otherwise shell would break too
<tyhicks> some vars are scrubbed because the launcher is setuid root
<zyga> right but I'm not talking about inheriting environment
<tyhicks> but the launcher should, I think, be able to set those vars itself
<zyga> just loading it from a file
<zyga> exactly
<tyhicks> right now, that's not working
<tyhicks> I'm looking at it
<tyhicks> zyga: I'll keep you updated when I make progress
<oparoz> Is there a kernel for core which include grsecurity or do we have to compile one ourselves?
<kyrofa> oparoz, you probably need to build that yourself
<oparoz> Thanks kyrofa
<jdstrand> morphis, zyga: I responded to the nm PR. I think it is fine pending a comment from zyga
<jdstrand> morphis: note that I asked you something as well (but it isn't blocking)
<jdstrand> plars: hey, how did you create the snap in https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/9 ?
<ubottu> Launchpad bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,New]
<plars> jdstrand: with snapcraft, on a branch I have at https://github.com/plars/snappy-tests
<jdstrand> ack, thanks
<plars> jdstrand: if you want to build yourself, it may take running it a second time. For some reason it tries to build the go code rather than just the tests. I haven't sorted out why just yet, but rerunning snapcraft does it right if it hits an error the first time
<plars> jdstrand: basically it's just a compiled version of the tests in the snappy source tree
<jdstrand> ok
<jdstrand> I'm having some issues with embedded paths that I think is a snapcraft python issue. I've seen the same thing with hello-unity for example
<jdstrand> since I just want the tests to run, I figured if I recreate it locally I could run it locally
<plars> jdstrand: I can try to rebuild the snap later too if you like - I'm just tied up trying to get some progress on another thing right now
<jdstrand> plars: I have the snap. should snappy-tests -check.f homeInterfaceSuite be run under sudo?
<jdstrand> plars: and that is /snap/bin/snappy-tests ?
<jdstrand> doesn't look like it on either
<plars> jdstrand: no, sudo shouldn't be required
<jdstrand> plars: installed with --devmode?
<plars> jdstrand: if there's still a problem, we may need to check with elopio and see if they are still having issues - yes, I did install with --devmode
<plars> I think it should be require for those tests to have any chance at running
<jdstrand> panic: runtime error: invalid memory address or nil pointer dereference
<jdstrand> let me try one more time with your snap
<jdstrand> plars: fyi https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1579135/comments/11
<ubottu> Launchpad bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,Incomplete]
<jdstrand> plars: fyi I'm EOD now so feel free to comment in the bug
<jdstrand> jjohansen: fyi, ^
<plars> jdstrand: will do, thanks for taking a look. Very possible that snappy and/or the tests have changed since then
<plars> elopio: are you hitting errors like that with the tests now? ^
<jjohansen> plars: I am building a test kernel, with what I hope is the fix. Is a deb good enough for you to test or do you need it in a ppa?
<jjohansen> plars: this is for bug 1579135
<ubottu> bug 1579135 in apparmor (Ubuntu) "kernel BUG on snap disconnect from within a snap" [Undecided,Incomplete] https://launchpad.net/bugs/1579135
<plars> jjohansen: well it sounds like something is preventing reproduction of the bug. I would need to test it in snappy, so any chance I could get it as a kernel snap?
<jjohansen> plars: uhmm, no :)
<plars> jjohansen: but I'll need to try reproducing again first, and check with QA if they are seeing the new problem in their test runs or if it is something unique to running it this way
<plars> jjohansen: heh, ok
<jjohansen> I'll look into it, I've never done a kernel snap before
<plars> jjohansen: me neither, I'm happy to try, just would need to do some rtfm
<plars> jjohansen: in any case, no rush... I'm already going to be swamped for most of the night on other problems
<jjohansen> right, let rephrase the kernel snap won't happen right away
<jdstrand> jjohansen: you'll want to talk to ogasawara for a kernel snap-- I think she can point you to someone. I think there is tooling to convert a deb to a snap, but I might be making that up
<jjohansen> jdstrand: ack thanks
#snappy 2016-05-19
<thefinn93> how can i get curl onto Ubuntu Snappy?
<thefinn93> oh, wow, internet sez write a python script to do it
<thefinn93> :/
<Trevinho> thefinn93: are you using snapcraft? you culd include it as a dependency...
<thefinn93> i have no idea what that is
<thefinn93> i was given a raspberry pi and told to put something called ubuntu snappy on it and set it up for easy access, which in this case means dynamic DNS. i guess i foolishly assumed curl'ing the DDNS provider would be the way to go about that
<Trevinho> thefinn93: ah, ok... well you need to install a curl snap then if you want to use curl.... I guess it's not provided yet, but you can easilty build one with snapcraft
<thefinn93> okay... i'll just make a ghetto DDNS client in python
<thefinn93> from reading rando blog posts that seems like it'll work
<thefinn93> could proly give it some basic logic too, like, check if we really need to update
<ogra_> mvo, thanks for the uploads (i totally slept in ... unplanned (hey jetlag)) .... the images boot on pi2 and dragon ...
<mvo> ogra_: \o/
<kyrofa> Good morning
<seb128> hum, what /etc are snaps seeing?
<seb128> the host system one?
<seb128> or a "merge" of the system + what is in the snap?
<kyrofa> seb128, talking desktop, I assume?
<seb128> yes
<seb128> is there a difference there?
<seb128> basically doing a snap install hello-world on xenial desktop
<seb128> and hello-word.sh
<seb128> ls /etc
<kyrofa> seb128, yeah, there is. In ubuntu core the host system is the OS snap, in which case I can definitely say the /etc seen by a snap is that of the OS snap
<kyrofa> seb128, but on the desktop, snaps still use the OS snap, but then you have the actual host system
<seb128> it's weird
<kyrofa> seb128, so unless something is bind-mounted somewhere...
<seb128> like /etc seems the real system one
<seb128> but /usr/lib isn't
<seb128> mount doesn't list /etc
<seb128> snaps are still magic to me :p
<seb128> is there a document somewhere explaining how is the snap install "constructed"?
<kyrofa> seb128, yeah this is best answered by mvo. I'm not sure what all is bind mounted into the OS snap on the desktop right now
<seb128> $ mount | grep usr
<seb128> /var/lib/snapd/snaps/ubuntu-core_113.snap on /usr type squashfs (ro,relatime)
<seb128> $ mount | grep etc
<seb128> $
<seb128> I would expect the /etc to be the one of the snap (or ubuntu-core + snap) but doesn't seem to be the case
<kyrofa> seb128, you mean if any old snap shipped a `etc` folder within it? I don't believe that's the case
<seb128> old snap?
<kyrofa> seb128, I mean any snap contains apps, not an OS snap
<seb128> no, as said, install hello-world, run hellow-world.sh, ls /etc
<seb128> what do I see
<seb128> ?
<seb128> is that the pure host system one unmodified?
<kyrofa> seb128, either that of the host system or that of the OS snap. Not sure which :)
<seb128> kyrofa, is there an OS snap in the context of a xenial desktop install?
<kyrofa> seb128, indeed, that's what I was trying to say
<seb128> things are still confusing to me
<seb128> like /etc is the real one
<seb128> but /usr is the ubuntu-core one
<seb128> it seems
<kyrofa> seb128, that's why locales don't work-- the folder in which they'd normally exist is not bind-mounted into the OS snap, so snaps don't see them
<seb128> right
<seb128> I'm just surprised that the real /etc is under /etc
<seb128> seems inconsistent
<seb128> trying to understand the logic
<kyrofa> seb128, perhaps a bit of a whack-a-mole-- maybe networking didn't work without /etc bind-mounted?
<seb128> could be
<seb128> kyrofa, thanks for the replies
<seb128> kyrofa, do you know if there is a place where all the architectures choices are explained/described?
<mvo> seb128: the /etc is from the host, we need quite a bit of data from there, e.g. hostname, timezone and stuff like that
<kyrofa> seb128, not that I know of
<seb128> mvo, isn't that potentially leaking infos like my service configs, users db, etc?
<mvo> seb128: yes
<mvo> seb128: it comes down to /etc is a mess that contains a lot of stuff that really should not be there
<jdstrand> mvo: thanks for the merge of the unity7 PR. There are a few other related ones it looks like you've requested restesting on-- it would be great to have those in 2.0.5-- is that the plan?
<mvo> seb128: fwiw, a lot of the potential leaking is managed by apparmor
<seb128> mvo, I see, thanks
<mvo> jdstrand: 2.0.5 just went out, unless I need to redo that 2.0.5 is final, but there will be another one next week
<mvo> seb128: anything specific you are concerned about?
<jdstrand> I see
<seb128> mvo, no, I'm just trying to understand how the snap "view of the world" is made, what comes from the system, what comes for the ubuntu-core snap, what comes from my app
<seb128> mvo, is there any document describing the architecture?
<seb128> mvo, seems that by default it sees the host but has bits overwriten by squashfs mounts (like /usr mounted from ubuntu-core) + apparmor restrictions? (and the .snap being mounted in its /snaps dir)?
<mvo> seb128: its the hostfs with /lib,/usr,/bin/,/sbin,/lib64 from ubuntu-core to have clean libs and commands. the host /etc and /media and /var. plus apparmor (of course) to prevent snaps to poke at stuff they should not. no document afaik, I think it would be good to write one. the idea behind it is that its a super thin layer of abstraction/hidding so that hardware tools still work and you can still use the raw network and all that
<seb128> mvo, that makes sense, thanks (was just trying to figure out what is available exactly and where)
 * mvo nods
<seb128> mvo, I'm looking forward having the bind mounts of more specific dirs btw! (learnt earlier this week that's it got on the plan now ;-)
<seb128> mvo, I was concerned about how hackish getting things like locales/translations/fonts etc working was before
<mvo> seb128: yeah, there is a plan to open certain dirs for fonts etc up
<mvo> seb128: its all still not super nice, its tricky to get right
<seb128> right
<seb128> well still an improvement
<mvo> we fight 30years of legacy here :)
<mvo> indeed!
<seb128> some weeks ago ogra said that those had to be shipped in the snap and that it was by design
<seb128> so good to see that the line of thinking is changing slightly
<mvo> seb128: :)
<mvo> seb128: would be a bit silly of all snaps would ship all fonts
<seb128> yeah
<seb128> or libc locales definitions
<mvo> yeah
<ogra_> seb128, well, once there will be a fonts snap that provides an interface
<ogra_> today there isnt ... so you have to ship what you need
<ogra_> (or wait for the interface ... or use --devmode)
<mvo> yeah, I think thats it, ogra_ is describing the "today" but I think we want to get something better for "tomorrow"
<seb128> ogra_, right, that's good ;-) (your responses a few weeks ago was "it's a feature/by design, there is no intention to provide things like locales for you, that would make snaps not independant enough")
<ogra_> right
<seb128> mvo, right, well that was not his position
<seb128> but I'm happy with the current line of thinking ;-)
<ogra_> seb128, well, in core there are no plans to add the loaclaes to the image
<seb128> right, that's another topic
<seb128> core needs to be small/restricted
<ogra_> well
<ogra_> we want desktops on top of core too at some point
<seb128> unsure who would like that
<ogra_> well, phones are supposed to be snappy eventually ...
<seb128> having every app bundling the world including all existing fonts, locales definitions, etc doesn't seem compeling
<ogra_> nah
<ogra_> there you will have a desktop snap that provides an interface or some such
<ogra_> though these are post-16 things
<seb128> right, let's see when we get there
<seb128> hum
<seb128> did anyone look a providing a XDG_RUNTIME_DIR (/run/user/<uid>) in the snap env?
<seb128> mvo, ^ do you know?
<seb128> jdstrand, ^ or you?
<jdstrand> seb128: I did not look at that
<seb128> jdstrand, I commented on the gsettings bug saying it's needed for dconf to work
<seb128> jdstrand, unsure if we should have a bug specific about that?
<seb128> that = /run/user
<seb128> I guess so
<ogra_> wasnt there a discussion led by ted about having it in the launcher ?
<seb128> could be, I was not around/where it was discussed
<seb128> tedg, ^?
<ogra_> similar to /tmp handling we have today
<ogra_> yeah, it was a while ago
<tedg> It should probably be in the bash file generated for GUI apps.
<ogra_> we definitely have open bugs where people worked around it by setting it to SNAP_DATA in their wrapper scripts
<tedg> I'm not sure there should be a bunch of XDG variables set for apps that don't need them.
<ogra_> well, on classic you kind of want to provide them
<ogra_> i assume
<tedg> Not sure you want to for the postgres server :-)
<tedg> *probably* won't harm things, but eh.
<ogra_> why not, as long as it is confined its just a tmpfs
<ogra_> you dont want to point it to the real /run ... everything else should be safe
<tedg> At some point you have no way to reject an environment variable then. If you'll say that you'll set any value for any use-case. What is the case where an env wouldn't be put there?
<ogra_> (you could also just hard-map it to /tmp/run/)
<seb128> ogra_, tedg, but today we do need some things from the real /run to get things working though
<ogra_> that needs urgent fixing i guess :)
<tedg> seb128: I realize. I'm just saying that we're headed to a "junk drawer" situation of environment variable. I don't think you have a choice other than to include it.
<tedg> seb128: You might be able to use the bindmounting thing that tyhicks is working on if you only want a few entries from there.
<seb128> right
<ogra_> well, the current target is --devmode snaps ... and grow the missing bits over timwe
<tedg> ogra_: Or switch to a desktop that doesn't have all these legacy interfaces not designed for confinement ;-)
<ogra_> this should definitely be high on the list ... but we know in advance we cant fulfill all requirements immediately
<ogra_> tedg, like wm2 or ion3 ?
<tedg> ogra_: I'm still running fvwm95
<ogra_> heh
<ogra_> already having antialiased fonts ?
<tedg> I don't waste GPU resources with eye-candy like that.
<ssweeny> zyga, is there anything left for me to do on the location interface?
<jdstrand> beuno: hi! I have a ufw snap for series 16. AIUI, people want it uploaded under the canonical account (fine). I have a ufw.jdstrand in 15.04 store. will I be able to create a ufw project under the canonical account and upload it to the store for series 16?
<beuno> jdstrand, great question!
<beuno> nessita will know
<nessita> jdstrand, you should be able1
<nessita> let me know if that is not the case
<jdstrand> ok, let me try
<jdstrand> whoa
<jdstrand> the store is a lot prettier all of a sudden :)
<beuno> sorry
<beuno> blame beowulf
<jdstrand> I'm not complaining :)
<beowulf> YES! FEED ME YOUR PRAISE!
<kyrofa> beowulf, I second the praise-- it's quite nice ;)
<beowulf> kyrofa: it's the best i could do in between the beatings from beuno
<jdstrand> nessita, beuno: it worked! :)
<qengho> beowulf: that Downloads graph threw me for far too long. Your Y axis direction broke my brain.
<niemeyer_> jdstrand: ping
<mvo> jdstrand, tyhicks: how can I disable environment scrubbing in the apparmor profile of the ubuntu-core-launcher?
<tyhicks> mvo: it shouldn't be happening
<mvo> tyhicks: interessting
<mvo> tyhicks: its my best theory so far :)
<tyhicks> mvo: there are no exec rules that should trigger env scrubbing of the launched apps in that profile
<tyhicks> mvo: I have some more investigation to do based on your new findings :)
<mvo> tyhicks: thanks!
<mvo> tyhicks: sorry, if the scrubbing is a red-herring, all I know is that with apparmor the LD_LIBRARY_PATH is gone and when I unload the profile around the launcher it works :)
<tyhicks> mvo: apparmor can request secureexec which will cause env scrubbing
<tyhicks> mvo: it shouldn't be requesting secureexec based on the launcher's profile
<mvo> tyhicks: fwiw, with  https://code.launchpad.net/~mvo/ubuntu-core-launcher/environment-file/+merge/295237 and bzr-buildpackage; sudo dpkg -i ../build-area/*1.0.29*.deb its easy to test. just install hello-world and add /var/lib/snapd/environment/hello-world.env with LD_LIBRARY_PATH=/something
<mvo> tyhicks: then hello-world.env|grep LD_ will either show up or not, depending on apparmor. this is what I used to test this
<mvo> tyhicks: anyway, not urgent, just an interessting puzzle :) I will get some dinner now
<tyhicks> mvo: ack - thanks
<niemeyer_> jdstrand: reping
<plars> jdstrand: jjohansen: well, I did a fresh build of the tests and they seem to run ok for me. Did that patch land already maybe?
<jdstrand> niemeyer_: hey, sorry I was out for a little bit
<qengho> Hi. How should we have apps that can write beneath SNAP_DATA that a service reads? sudo from outside doesn't have snap bin in the PATH, normally. I don't think I can sudo from inside the snap app.
<jdstrand> you can't sudo from within a snap
<qengho> Right.
<jdstrand> /snap/bin not in PATH has an open bug
<qengho> Ah.
<qengho> Thanks.
<jdstrand> sudo /snap/bin/foo works fine
<qengho> I assumed not in PATH was intentional.
<jdstrand> plars: I'm quite sure the kernel patch has not landed anywhere
<klow> So Ubuntu Core is a minimal OS,  Snappy is a transactional udpdate system,  and snapcraft is sortof a Docker alternative for packaging apps to run on Core,  and Core also Supports Docker apps ? Am I understandinf that right?
<kyrofa> klow, sort of. Snaps aren't quite as fat as docker containers, they're just isolated
<kyrofa> klow, but yes, one can package docker in a snap
<niemeyer_> jdstrand: Are we both here now? :)
<jdstrand> niemeyer_: I think so :)
<niemeyer_> Sweet
<niemeyer_> jdstrand: Can we quickly go over the status of these interfaces we have up for review?
<niemeyer_> jdstrand: We can start by network-manager..
<jdstrand> sure
<jdstrand> nm is committed last I saw
<jdstrand> there is a little fine-tuning I want to do, but that isn't hugely important or blocking
<jdstrand> niemeyer_: ^
<niemeyer_> jdstrand: Hmm
<niemeyer_> jdstrand: I'm trying to find the comment where you point out it was very open.. I'm probably mixing up interfaces
<jdstrand> niemeyer_: that was location service
<niemeyer_> jdstrand: Ah, ok
<niemeyer_> jdstrand: So how's that one going?
<jdstrand> niemeyer_: specifically, the bus policy says that all the dbus interfaces can be used. this is in contrast to say, nm which had fine-grained bus policy
<jdstrand> niemeyer_: I don't consider that blocking. if that is how the api is designed, apparmor will mediate the access.
<niemeyer_> jdstrand: What sort of APIs exist under that interface?
<jdstrand> niemeyer_: the issue with location service was zyga's and my interaction
<jdstrand> niemeyer_: that's a good question. looking at the apparmor policy there are things to start and stop 'velocity, heading and position updates' (I guess that is to say whether or not you want to get positioning info) and then to receive position, heading and velocity from the service
<jdstrand> and then Getting and Setting all properties
<klow> Are snaps more fitting for apps which need persistent storage, example: a Snap containing SOGo (Apache, database + Postifx/Dovecot and persistent mailbox with virtual users from a remote LDAP server)
<jdstrand> I think we'd need ssweeny to comment on everything that is available
<klow> vs Docker
<jdstrand> klow: snaps are designed to support persistent data conveniently
<niemeyer_> jdstrand: Anything dangerous you can identify there?
<ssweeny> jdstrand, niemeyer_ the API is pretty much what's shown in the apparmor rules
<niemeyer_> ssweeny: ^
<jdstrand> klow: each snap gets an app-specific writable area that it can do whatever it wants with, and upgrades are handled to
<klow> Is there a full blown book on the snap architecture available yet? So I can really dig in and contrast it with other methods ?
<klow> I see. That sounds pretty cool .  Arbritarily configurable size for the write area I assume?
<jdstrand> klow: the community team is developing the docs. you might ask on the status when dpm or dholbach are around (both seem offline atm)
<jdstrand> klow: there are no quotas, so no issues there
<jdstrand> ssweeny: well, yes but I don't know what is in the Get and Set methods
<niemeyer_> jdstrand, ssweeny: Indeed, and who would use them to Set things
<niemeyer_> Do we need location-control in addition to location
<niemeyer_> ?
<niemeyer_> These seem slightly different
<klow> Is there any UI , Web or otherwise so one can see which versions of snaps are on that particular server, and update them if desired ? I assume server can be configured as to allow only snaps from a private snap repository to be installed ?
<ssweeny> jdstrand, ah, so the properties available are:                 "   is_online [get/set]\n"
<ssweeny>                 "   does_satellite_based_positioning [get/set]\n"
<ssweeny>                 "   does_report_wifi_and_cell_ids [get/set]\n"
<ssweeny>                 "   visible_space_vehicles [get]",
<klow> sorry for so many questions I am tasked with going from manual sysadmin to package/container deployment wiz ASAP on a huge crunch :)
<jdstrand> ssweeny: the non-Set/Get apis seem all related to just setting up a session to obtain positioning info. I wouldn't mind Get as part of that based on what you just listed, but it seems odd to be able to Set some of those if this is just about access to positioning
<ssweeny> jdstrand, right, as niemeyer_ said it might make more sense to have those in a separate controller interface. There's a command-line client which mostly makes use of those
<jdstrand> klow: yes. 'snap list/snap refresh' and the webdm snap. as for private snap repo, I'll let others comment
<niemeyer_> ssweeny: Can we split that up?
<jdstrand> niemeyer_: now I wonder if this should be s/location/location-observe/ and then add location-control
<niemeyer_> ssweeny: We can start by having that branch in just with the consumer side of things, which is likely the vast majority of cases
<ssweeny> niemeyer_, sure. Would the dbus rules need to change as well?
<jdstrand> as written, it was 'all of location' but you make a good point on splitting I think
<niemeyer_> jdstrand: Yeah, that sounds nice
<niemeyer_> ssweeny: To constrain the set side, I suppose..?
<jdstrand> ssweeny: in terms of policy, I think just remove Set from location-observe and add it to location-control
<jdstrand> ssweeny: you'll likely need a couple of org.freedesktop accesses in location-control
<jdstrand> but I think we are saying that you can observe (plugs location-observe), you can control (plugs location-control) or you can observe and control (plugs location-observe, location-control)
<jdstrand> which is a long way of saying-- location-control is not all of location-observe + Set, it is pretty much just Set
<jdstrand> (and whatever is needed to support Set, of course)
<jdstrand> niemeyer_: beyond that ^, there is this comment which I think needs zyga's input: https://github.com/ubuntu-core/snappy/pull/1118/files#r63869816
<ssweeny> jdstrand, ack
<niemeyer_> jdstrand: Can I get a quick overview of the problem being covered there in terms of the actual snippets?
<niemeyer_> jdstrand: How would the combined snippet look like?
<jdstrand> niemeyer_: foo and bar want to connect to location, so the Plugs snippet has label={snap.foo.*,snap.bar.*}
<jdstrand> niemeyer_: that works fine
<jdstrand> niemeyer_: but the Slots snippet should also have label={snap.foo.*,snap.bar.*} in some rules, but it cannot currently
<jdstrand> ConnectedSlots to be precise
<jdstrand> (and I'm taking zyga's work that it cannot currently)
<niemeyer_> jdstrand: Would duplicating the same statement not work?
<niemeyer_> jdstrand: that is, one with label A, another with label B?
<jdstrand> niemeyer_: that would be totally fine
<niemeyer_> jdstrand: Would it add, or would it replace?
<jdstrand> it would add
<niemeyer_> zyga: Not clear what's the problem then?
<jdstrand> dbus ... label={foo,bar} is the same as dbus ... label=foo, dbus ... label=bar
<jdstrand> I'll be honest, I was confused that there was a problem after the comment on (I think it was) the nm PR
<jdstrand> where I thanked zyga for the clarification
<klow> Is snappy ubuntu proprietary, are there any restrictions or costs associated with its use commercially ?
<jdstrand> so yes, I'm curious too
<jdstrand> klow: just to answer you quickly, it is open source, there are open source reference kernel snaps that can be used and the os snap is open source
<jdstrand> you can have proprietary stuff on it, and there are certain things that you need to be Ubuntu certified, which can be used in various ways with the store
<klow> Could my company run our own store for our own apps and have our devices/servers run only apps we have pushed to our private store?
<jdstrand> but, you may want to ask specific questions of Canonical or others on this list if you are using this commercially (I'm not the authoritative answer on all that)
<jdstrand> I'm not up to date on that. beuno ^
<jdstrand> s/this list/this channel/
<jdstrand> niemeyer_: did you have other questions regarding location or other interfaces?
<niemeyer_> jdstrand: What else do we have up for review?
<jdstrand> pulseaudio
<jdstrand> I have an open question for you on that one
<jdstrand> regarding shm
<niemeyer_> jdstrand: Ah, sure?
<jdstrand> let me find it
<jdstrand> actually, there are two things
<jdstrand> 1. recording
<niemeyer_> jdstrand: On network-manager, one question I had was about whether we'd need some sort of separation too
<jdstrand> I think it is probably fine to not block on that
<jdstrand> but to SRU morphis' pulseaudio 'snap.' check soonish
<jdstrand> niemeyer_: you mean something along the lines of network-manager-observe vs network-manager-control? if so, I think probably not. nm isn't really designed that way and its API is vast and libraries (eg, qt) rely on being able to access all of it. I think 'network-manager' with no autoconnect is correct
<niemeyer_> jdstrand: It's a slightly trickier one because we have conflicting (?) rules for network-observe and control, but it feels like we need the same sort of "lightweigh" vs "dangerous" case there
<niemeyer_> jdstrand: Well, sort of
<jdstrand> niemeyer_: but then we bring on safe interfaces like connectivity-api
<niemeyer_> jdstrand: What's the proper way to find network status?
<jdstrand> niemeyer_: the proper way is connectivity-api :) that was something the security team recommended the Touch guys write. it is an easy api, has a plugin into qt. it is a service that has a properly designed dbus api. you ask it, it asked nm
<jdstrand> niemeyer_: but for nm, there isn't really a 'safe' one cause the libs pound scores of API calls to see if you are online, which reveals all kinds of sensitive info
<niemeyer_> Hmmm.. interesting
<jdstrand> niemeyer_: which is also why there is such a complicated bus policy and polkit policy around nm. it unfortunately isn't a well designed api... :\
<jdstrand> and the bus policy/polkit stuff assumes a trusted client is connecting
<jdstrand> sdoc is a weird hybrid though
<niemeyer_> jdstrand: Really? Wow
<jdstrand> on Touch we needed to be locked down. on iot, same thing. sdoc... it might be possible to tease out a few things that are ok, but I fear it isn't going to be very useful
<jdstrand> for example, in Ubuntu, polkit (probably only if you have a seat), will allow you to add/remove wife connections
<niemeyer_> Alright, in the spirit of our priority agreements, I'm happy to move with it too
<thomi> jdstrand: does kyrofa's answer on https://bugs.launchpad.net/click-reviewers-tools/+bug/1582513 allow us to move forwards fixing this? If not, is there someone other than s3rgiusens we can ask (I believe he's on holiday?)
<ubottu> Launchpad bug 1582513 in Snapcraft "click-reviewers-tools fails on all python3-based snaps" [Undecided,New]
<jdstrand> we can always re-assess once people are using it
<niemeyer_> jdstrand: So location is blocked on zyga's feedback
<jdstrand> yes
<niemeyer_> jdstrand: and on the split of control vs. observe
<jdstrand> right
<jdstrand> pulse is we need to agree on recording and the other question I had
<niemeyer_> jdstrand: Anything pending for pulseaudio?
<jjohansen> plars: sorry, no turns out my fix was no good
 * jdstrand goes to find that
<jdstrand> niemeyer_: did you see my comments on recording, above?
<niemeyer_> jdstrand: Unless there's an easy way to control recording vs. not, I think we should move forward
<jdstrand> niemeyer_: ok, I think you missed what I said
<kyrofa> thomi, I expect you'll need to wait for sergiusens-- he's currently the only snapcraft dev
<niemeyer_> jdstrand: I did.. still looking for it
<thomi> kyrofa: ok, thanks
<niemeyer_> jdstrand: I cannot find the comments, sorry.. can you paste?
<jdstrand> niemeyer_: morphis has a PoC for pulse that blocks recording if the connecting process' security label starts with 'snap.'. I suggest: we not block the interface on that, but SRU that change in the coming weeks. then, refine that check into a proper interface (perhaps a recording attrib?)
<niemeyer_> jdstrand: Sounds great
<jdstrand> ok, I'll comment on that in the PR
<niemeyer_> jdstrand: That's what I was going to suggest as well, despite not knowing a plan was already underway
<niemeyer_> jdstrand: we can do pulseaudio-recording too
<jdstrand> niemeyer_: then there is my other shm question
<niemeyer_> or pulseaudio-record, actually
<jdstrand> niemeyer_: right, we can discuss which is best
<niemeyer_> following observe ,control etc
 * jdstrand nods
<niemeyer_> jdstrand: But you're right, this may be the first case that an attribute might make sense.. let's see
<jdstrand> niemeyer_: the other comment was really a clarification of: https://github.com/ubuntu-core/snappy/pull/1133#discussion_r63693432
<jdstrand> niemeyer_: that is your comment. please see that then read mine
<niemeyer_> jdstrand: the dev/shm?  What's the question on it?
<niemeyer_> Looking
<niemeyer_> jdstrand: Yes, I think we're on the same page
<niemeyer_> jdstrand: I'm happy for both of them to go in.. the background is this:
<niemeyer_> jdstrand: One of them gives a way its own playground without having to ask for interfaces or anything, at the price of changing its shm file name
<niemeyer_> jdstrand: The other gives the process a way to communicate with other processes without changing its shm filename, at the price of having an interface well defined
<niemeyer_> Both seem good
<niemeyer_> I wish there was a way to unify them further, but given the semantics of /dev/shm, I'm not optimistic
<niemeyer_> We'll probably need to patch the system more aggressively for anything better than this
<jdstrand> yeah
<jdstrand> ok, cool
<jdstrand> niemeyer_: I'm of the same opinion. I reopened the other PR. it would be great if you could LGTM it (or whatever is appropriate :)
<jdstrand> niemeyer_: since we're on the topic of shm, I have an unrelated to pulse or that other PR question. this is on bug #1577514
<ubottu> bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed] https://launchpad.net/bugs/1577514
<jdstrand> ShR3K: I can summarize
<jdstrand> err
<jdstrand> ShR3K: nm
<jdstrand> niemeyer_: I can summarize
<niemeyer_> jdstrand: Which one?
<niemeyer_> jdstrand: Sorry, I mean.. reopened which one?
<jdstrand> niemeyer_: the chromium content api has a hardcoded path of /run/shm/.org.chromium.Chromium
<jdstrand> niemeyer_: lemme get you that
<jdstrand> oh, hmm
<jdstrand> gimme a sec
 * jdstrand can't find it any more
<jdstrand> oh, someone committed it
<jdstrand> heh
<jdstrand> I didn't see the email
<jdstrand> niemeyer_: nm! :)
<niemeyer_> jdstrand: It's in, isn't it? :)
<niemeyer_> jdstrand: Ok, so the chromium case.. what's the trick there?
<jdstrand> https://github.com/ubuntu-core/snappy/pull/1135
<jdstrand> yes, you merged it ^
<jdstrand> thanks!
 * jdstrand will have to check his filters on why he didn't see the email
<jdstrand> niemeyer_: ok, on to chromium
<jdstrand> niemeyer_: so, chromium is hard-coding .org.chromium.Chromium
<niemeyer_> Ok, I've read some of the content in the links you provided above
<jdstrand> that doesn't fit snap.<name>. of course
<jdstrand> and I'm not sure how to solve that
<jdstrand> chromium content api is a bear to build
<jdstrand> so asking people to patch for s/.org.chromium.Chromium/snap.<name>./ seems onerous
<jdstrand> we could patch our stuff
<jdstrand> (eg, oxide)
<jdstrand> but then electron wouldn't be fixed
<niemeyer_> jdstrand: The problem I see with adding to existing interfaces is that we'd have to do one of two things:
<niemeyer_> 1. Allow anyone access to .org.chromium*
<niemeyer_> 2. Allow only a single snap access to it
<niemeyer_> Both sound bad
<niemeyer_> The first means snaps can read each other, so we're doing much really
<jdstrand> the only thing I can think of is allowing /run/shm/.org.chromium.Chromium.*, but that is imprecise and is not app-specific
<niemeyer_> The second means we have system-wide per snap rules, which is pretty bad
<niemeyer_> jdstrand: Where is that path defined, and how is it used?
<jdstrand> niemeyer_: hard coded in the source
<niemeyer_> jdstrand: Of every single app, or of chromium proper only?
<jdstrand> niemeyer_: I believe it is used to coordinate between the renderer process and the 'chrome' (outer process)
<niemeyer_> jdstrand: So it's internal only, rather than a way to share
<niemeyer_> (share across snaps)
<jdstrand> niemeyer_: anything that uses the chromium content api. so, our webview, our webbrowser-app, kde's webcontent thingie, opera, electron apps, etc
<niemeyer_> jdstrand: Across them, or internally to them?
<jdstrand> niemeyer_: it is intended as internal only, yes and chromium is coded such that it uses a tmpfile style (ie, its defensively coded)
<jdstrand> niemeyer_: internally
<niemeyer_> jdstrand: Okay, so I think the easiest is LD_PRELOAD + /dev/shm/snap.$SNAP_NAME.*
<jdstrand> ie, our webbrowser-app by using chromium content api create /run/shm/.org.chromium.Chromium.XXXXXX
<jdstrand> wel
<jdstrand> we could actually
<jdstrand> but chromium uses open() not shm_open
<jdstrand> so we'd LD_PRELOAD open(), which we could do, but since we'd be doing a string match on the path (if path starts with .org.chromium.Chromium.* then use snap.<name>)
<jdstrand> but that feels kinda icky to do with open()
<jdstrand> I mean, open() is used in just a few places :)
<niemeyer_> jdstrand: No strong emotions on my side :)
<jdstrand> I wonder about the performance impact...
<jdstrand> but it can be explored
<niemeyer_> jdstrand: Very hard to believe
<niemeyer_> jdstrand: We're talking about a couple of long jumps that are about to go into a freaking syscall
<niemeyer_> jdstrand: The CPU delays are most probably completely irrelevant compared to the cost of the syscall
<jdstrand> I'm happy to summarize this conversation in the bug and followup with zyga, who I think already has an implementation for shm_open
<jdstrand> niemeyer_: I think that's it
<niemeyer_> jdstrand: Sweet, looks optimistic! :)
<jdstrand> indeed!
<ssweeny> jdstrand, niemeyer_ I've pushed up the location-observe rename. I can add the -control interface to this branch tomorrow or to a later merge
<jdstrand> niemeyer_: you might be interested in https://bugs.launchpad.net/snappy/+bug/1583514/comments/1
<ubottu> Launchpad bug 1583514 in Snappy "firewall-control and ip[6]table_filter module loading" [Medium,Confirmed]
<niemeyer_> jdstrand: Ah, there's also the cups interface
<niemeyer_> ssweeny: Looking
<jdstrand> oh right
<jdstrand> the cups one scares me as is
<niemeyer_> ssweeny: This was just the rename.. is closing it down to actually only observe quick?
<niemeyer_> ssweeny: If so we can probably get it in imminently
<niemeyer_> ssweeny: Otherwise I need to leave soon
<ssweeny> niemeyer_, already removed the properties stanzas
<ssweeny> they aren't necessary for clients
 * jdstrand notes that location also needed zyga's comment
<niemeyer_> ssweeny: Hmm.. shold Get be there, though?  jdstrand?
<jdstrand> I think Get is fine. there is nothing sensitive there
<ssweeny> niemeyer_, clients work without it
<niemeyer_> ssweeny: Can we please get Get back?
<jdstrand> so either way is ok
<ssweeny> niemeyer_, I can do that
<niemeyer_> ssweeny: Thans!
<niemeyer_> ks!
<jdstrand> thomi: that answer means the problem is in snapcraft which I think means either s3rgiusens or kyrofa
<jdstrand> niemeyer_: did you see my scary comment regarding cups?
<niemeyer_> jdstrand: Yeah, I like your idea of having it as cups-control
<thomi> jdstrand: ok, thanks.
<jdstrand> niemeyer_: note that it is also possible to do the exact same thing with cups as pulseaudio. the problem would be finding all correct mediation points in software that gets a lot of CVEs...
<jdstrand> I think cups-control is the fastest option. I can also adjust snappy-debug to mention ipp:localhost:631 if trying to use the socket so developers have the option to update their code
<jdstrand> the nice thing about pulseaudio it it seems to have a decent hooks interface. cupsd does not
<jdstrand> anyhoo
<ssweeny> niemeyer_ pushed with those stanzas back in
<niemeyer_> ssweeny: The comment is wrong.. (sorry, but since we're at it)
<ssweeny> gah
<ssweeny> niemeyer_ fixed
<niemeyer_> ssweeny: I need to step out now anyway, and we need to let those tests run.. I'll have a look again when I'm back and if it's all green, it'll be merged
<ssweeny> niemeyer_ sounds good. Thanks!
<niemeyer_> ssweeny: Thanks a lot for this and for all the great work you've been doing on interfaces. Seriously appreciated.
<mmstick> Are Rust projects supported by Snappy?
<zyga> niemeyer_: based on the conversation, since apparmor is additive I think there is no problem anymore
 * zyga still goes through backlog
<qengho> Man, I wish "snap" were more resilient to my control-c's.
<jdstrand> niemeyer_: please comment if I didn't get the summary right: https://bugs.launchpad.net/snappy/+bug/1577514/comments/2
<ubottu> Launchpad bug 1577514 in Snappy "Allow out of the box use of chromium based apps" [Undecided,Confirmed]
<jdstrand> tyhicks: fyi, I think I need to bump up the priority of the review tools 'confinement' check since I'm seeing PRs and landings related to this in other areas
 * jdstrand bumps it and queues for tomorrow
<tyhicks> jdstrand: ack - seems reasonable as the surrounding work is moving fast
 * jdstrand nods
<jdstrand> with weekly snapd SRUs, I'm thinking there isn't the 3 weeks time initially thought
#snappy 2016-05-20
<liuxg>  I am now trying to development a simple snap app on 16.04 desktop. I met a problem. whenever install my snap app onto my desktop, it takes quite a lot of space since I get all of the Qt stuff. the problem is that it get different versions in my hard disk, and each takes that space. How can I remove the versions that i do not need any more? thanks
<nhaines> ls
<zyga> o/
<shuduo> ogra_: hello, may i know where is official kernel repo for rpi2 snappy image?
<ogra_> shuduo, ppisati maintains it on kernel.ubuntu.com (i always forget the exact branch name)
<shuduo> ogra_: got it. let me find it. :)
<shuduo> ppisati: ping
<ppisati> shuduo: pong
<shuduo> ppisati: may i know what kernel tree and branch is being used for snappy on raspberry pi 2?
<shuduo> ppisati: i cloned it from  git://git.launchpad.net/~p-pisati/ubuntu/+source/linux and see   remotes/origin/x-raspi2
<shuduo>   remotes/origin/x-raspi2_rtlfix
<shuduo>   remotes/origin/x-raspi2_rtlwififix
<kyrofa> Good morning
<qengho> jdstrand: what does the "unconfined" security plug look like these days? Still old-security?
<jdstrand> qengho: it looks like --devmode :)
<jdstrand> qengho: more seriously, it was decided that unconfined isn't a thing any more
<jdstrand> people can use --devmode to be unblocked and file a bug for what they need (please add snapd-interface tag)
<ppisati> shuduo: that's my personal git tree
<ppisati> shuduo: use this:
<ppisati> shuduo: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/log/?h=raspi2
<shuduo> ppisati: got it. thanks.
<morphis> jdstrand: first step towards slot support in the pulseaudio interface: https://github.com/morphis/snappy/commit/08da30f860ab68cf9ed866e10874e8b353894d36
<morphis> needs cleanup and then I will push that as PR next week
<niemeyer_> ssweeny: ping
<jdstrand> morphis: nice! :)
<morphis> jdstrand: however policy might be too in open in some points, we need to figure those things out once I open the PR
 * jdstrand nods
<Kristbaum> Hello people, is it intentional that the same snap can be run multiple times at once? E.g the Telgram-Snap can be executed 50 times on my system.
<ogra_> file a bug ... i guess that needs some discussion
<ogra_> (if it was a terminal app you probabl ywould want it to start multiple times .... apps that use login credentials probably not so much ... might need a field in snap.yaml/snapcraft.yaml for the dev to define)
<Kristbaum> Can I also file a bug, concerning the "repoducable Builds" thing, or would this be more anoying, than helpful?
<kyrofa> Kristbaum, are you talking about bug #1582417
<ubottu> bug 1582417 in Snapcraft "snapcraft doesn't create binary-identical reproducible builds" [Undecided,New] https://launchpad.net/bugs/1582417
<Kristbaum> Oh, very nice, I thought I needed to create one first ;) Is there also one about linking to sources, so that you can verify, that you are running the correct software (in case it's opensource), or did I also miss that?
<kyrofa> Kristbaum, not that I know of
<ogra_> thats really up to the developer, iirc the store app page pffers you to specify a source url and homepage when you register your snap
<Kristbaum> ogra_: But the source on the Website doesn't have to macht the final snap image, right?
<ogra_> nothing has to match a snap ... but if you are OSS developer you can indeed specify your git tree and homepage
<ogra_> snaps really only care about binary ...
<ogra_> everything else would be added meta data for the store side
<ogra_> there arent even any requirements that you have the source for what you put inside your snap (assumed you are allowed to distribute it indeed)
<Kristbaum> Okay, and we can agree that is a problem? Because, e.g. there is a Telegram app out there (wich I cant find the source for), how do I know it isn't sending out all I write to somebody? Or another example: The Keepassx snap, can't send anything because it has no network plug, but but how do I know if it really encrypts it correctly?
<ogra_> you dont
<ogra_> (afaik that telegram app is actually the binary from telegram.org ...)
<Kristbaum> ogra_: okay so this is a problem.. Should I bug report this, or is this more of a management decision?
<ogra_> i dont see where it is a problem
<ogra_> the snap design is only built around binaries ... how you produce them is in your responsibility
<ogra_> it tries to give everyone the most freedom it can ... by not enforcing such stuff
<ogra_> what it enforces is the security model ... no app should be able to access any data or service you havent explicitly authorized
<ogra_> weather the source code that binary was initially built from is open or not doesnt matter ... a good OSS dev would indeed mention where the code comes from and give you a reciepe how it is built ... but thats totally not mandatory
<Kristbaum> I think the whole concept (at the moment), works really great for proprietary software. But for Free Software people, and Security minded ones it isn't really a step forward, because you can't check the software you are using. Isn't this a contrast to the whole security story?
<ogra_> well, you cant check whet the single binary does, but you have full control about its outside connections
<ogra_> be it disk, network, sensors on your phone or whatever
<Kristbaum> Thats right, but in a OSS binary I want to trust the binary too. And I can't if i can't verify if it's the same code as on the website.
<ogra_> you can if the developer tells you how it was built and points you to the source code
<ogra_> if you are concerned about that you will have to check the details of the respective snaps you use
<ogra_> but after all, do you actually do that for ... say the desktop you use ?
<ogra_> i.e. do you know the filemanager you use doesnt come with a keylogger inside
<Kristbaum> Thats right, but considering that it's quite easy in apt, snaps are kind of a step back. There is a really high chance that somebody will build a malicous e.g. Telegram app and there will be no checks possible, and when sobody finds out it will be a mess etc.. And no ofcource I am to lazy to ever check the source of my software, but I trust you and all the other Ubuntu/Debian developers that they have access to th
<ogra_> well, the hope is indeed that telegram uses a snapcraft.yaml in its tree and simply provides an official snap
<Kristbaum> We woudn't need to hope on every company to to this, if there would be something like a automated trustet OSS snap build service, where oss developers provide a link to the source and a .yaml file, and it gets built, and we can check it if needed with something like snap source telegram-sergiusens.
<ogra_> thats called launchpad ;)
<ogra_> (such an LP feature exists already)
<ogra_> but still, it is optional
<ogra_> the telegram-sergiuens snapcraft.yaml wouldnt help you much though ... i'm 90% sure it doesnt build the source
<ogra_> afaik it just pulls the latest binary from upstream and snaps it
<Kristbaum> But the Version in the store already is behind?
<ogra_> and there will likely be many snapcraft.yaml files like this
<oparoz> LP snap builders, when they work, are great. You can even build partials
<ogra_> did they stop working ?
 * ogra_ hasnt had issues yet
<ogra_> Kristbaum, well, ask sergiusens :)
<ogra_> if he feels like updating
<ogra_> or just hit the update button inside the running app ;)
<Kristbaum> But still, can people check if they want to, with this LP plugin?
<ogra_> sure
<Kristbaum> the Update Button chrashes it :D
<Kristbaum> Maybe it is malicions :D
<ogra_> it gets updated, but cant restart for whatever reason
<ogra_> if you start it newly it is up to date
<Kristbaum> Nope, it's the same as before
<ogra_> https://code.launchpad.net/~ogra/+junk/ircproxy is a branch of mine (bit outdated, i'm waiting for "snap config" to come back) ...
<ogra_> https://code.launchpad.net/~ogra/+snap/ircproxy are the snap packages created from that branch
<ogra_> on the branch summary page i have a "build snap" button ...
<Kristbaum> Interesting indeed. But there is still the risk of a malicous person taking x/y oss app (modify it in a bad way), load it up in the store, and noone would notice. Snaps are a redirection of trust in the hands of the person that uploads it, and non officail app can be trusted.
<ogra_> it depends ... i assume if you woulld use a snappy based desktop install you would still trust canonical as much as you do today
<jdstrand> Kristbaum: to expand on/reiterate what ogra said: snappy itself doesn't enforce anything regards to sources or builds from source, just like debs don't either. snaps and debs are a packaging format. Launchpad is used to build Ubuntu binaries from deb source packages. Launchpad has facilities for building snaps from source packages as well
<ogra_> and that PPA guy from whom you install packaages to your system ... you trust him enough to give him root on your machine
<jdstrand> Kristbaum: and aiui there are plans to make building from sources even easier for open source projects and devs
<ogra_> it shuffles the trust around indeed ... but also adds a massive amount of safety and security in the end
<Kristbaum> No way :D That also no a good solution but at least I can go to the launchpad site and check it, and I know it is the same, as is running on my system.
<jdstrand> Kristbaum: then there *will* be a way to verify the origin-- there will be sha512 sums of the generated snap that can be compared against Launchpad, etc
<ogra_> and if an OSS dev wants you to have that info today he can already put a link to the tree and a build HOWTO in the package description
<jdstrand> and aiui, all this is going to get easier and better
<ogra_> jdstrand, well, the origin for the binary
<ogra_> i can slap a bunch of downloaded binaries together in a snap and just upload them from my desktop ... you can probably track it to me via that ... but you wont know if i built a thing of it from source
<jdstrand> ogra_: I'm saying that if someone uploads a source/build from source, the resulting binary's sum can be verified against what is installed on the device
<ogra_> indeed
<jdstrand> uploads and builds on LP that is
<ogra_> but so can my binary blob collection
<ogra_> ah
<ogra_> right, if you build it there too, thats indeed different
<jdstrand> so a security minded person might make a personal or site-specific decision-- I will only install snaps that are built on LP, etc
<ogra_> right
<jdstrand> I can imagine snapd and the store gaining functionality to make that all convenient
<Kristbaum> Okay, thats a start ;) I really love the snappy concept in every way, this is the only thing that still bothers me. I think it's great that I will be able to at least check projects build on lp,
<Kristbaum> And marking the trusted OSS snaps would be nice to
<jdstrand> reproducible builds and builds from source are important concepts that will be supported. the minimum bits are, more will come
<Kristbaum> I know you have a lot to do these days, I just hope noone gets bad ideas and builds malicious snaps. Because this could really damage the reputation early one, despite it beeing a grat idea.
<ogra_> i actually hope people do :)
<ogra_> it will prove the security setup
<Kristbaum> Maybe we should do a challenge to try and test the limity of snappy.
<ogra_> definitely ... and indeed file bugs for everything
<Kristbaum> The snappy challenge, who can get the most keyloggers to people :D Has UBuntu-Marketing an IRC channel?
<ogra_> well, keylogger and Xorg vulnerabilities would be a bit unfair until Mir is there
<ogra_> since it is a known open hole
<Kristbaum> okay, fair point
<ogra_> i'd start with a headless challenge ;)
<Kristbaum> Would In-App-Keyloggers be allowed?
<ogra_> why not
<Kristbaum> ok, maybe I find somebody in marketing that likes the idea :D
<ogra_> :)
<ssweeny> niemeyer_, sorry I missed your ping earlier
<slvn> Hello! Just wondering about this issue which seems to lack attention. Some snap can't be validated because of invalid checksum ... https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1577333
<ubottu> Launchpad bug 1577333 in squashfs-tools (Ubuntu) "snap-review failed with "checksums do not match"" [High,Confirmed]
<kyrofa> jdstrand, how do the review tools check that ^^? Uncompress and recompress and compare checksums?
<ogra_> do you need to uncompress ?  the sum should be in the meta data ...
<ogra_> so you just need to compare the squashfs sum vs meta
<kyrofa> ogra_, ah, I didn't realize that. What would cause them not to match?
<ssweeny> jdstrand, if I'm writing a dbus rule to allow getting/setting a particular property what would that look like? Would the interface be /com/ubuntu/location/service/<property> or would it be /org/freedesktop/dbus/properties with the destination com.ubuntu.location.service.<property>?
<ogra_> recompressing them ??
<ogra_> dunno
<jdstrand> kyrofa: there are 3 bugs related to this that I'll be getting to after the interfaces, doc and devmode work
<kyrofa> jdstrand, ah, okay. I just noticed that you reassigned to squashfs-tools, so you must know what's going on there. I wasn't sure if snapcraft was doing something wrong or what
<kyrofa> slvn, ^^ FYI
<jdstrand> kyrofa: to answer your question specifically, I updated squashfs-tools to add an option to unsquashfs to grab the fs time from a snap. then I added an option to mksquashfs to injuect that time into the superblock. in this manner, we can resquash
<jdstrand> kyrofa: however, there are a couple of issues where timestamps are causing trouble, and perhaps something not timestamp related
<jdstrand> no, snapcraft is fine
<kyrofa> jdstrand, ah, I see, okay
<jdstrand> it works a lot of the time but unfortunately it isn't 100% yet
<slvn> kyrofa, I don't fully understand ... it seems to me *all* my packages systematically fails the checksum test.
<jdstrand> slvn: you might be hitting one of the three different bugs
<slvn> jdstrand, hmm ok! so all is under control :)
<jdstrand> I'll be updating the review tools for something else, I should turn this check off until it is reliable
<jdstrand> well, yes, though it'll still be a little while before it is fixed. but let me make it better for people
<jdstrand> (ie, make the check temporarily non-fatal
<jdstrand> )
<jdstrand> tyhicks, beuno: fyi, I just committed 'turn resquash test into info for now until the squashfs-tools bugs are fixed and this is a reliable check' to address ^
<tyhicks> jdstrand: ack - I hope we can get to those bugs soon and reenable the checks
<jdstrand> me too :|
<beuno> jdstrand, ack
<ssweeny> jdstrand, for the location-control interface I have apparmor rules that enable "{Get,Set}" for properties. You mentioned expanding the dbus rules as well but I'm not sure what that should look like
<jdstrand> ssweeny: I was only saying that in general-- ie, whatever org.freedesktop.... accesses you might need to have Get and Set work
<jdstrand> ssweeny: maybe that is nothing beyond what the dbus abstractions already give (I just didn't know)
<jdstrand> ssweeny: (when location-control is standalone)
<ssweeny> jdstrand, ah, that makes more sense. I don't think it's possible to do what I thought you meant (i.e. enumerate the properties themselves in the policy)
<jdstrand> ssweeny: oh no, we can't mediate on message contents, no
<ssweeny> jdstrand, ok, thanks!
<jdstrand> roadmr (cc beuno, nessita and tyhicks): can you pull r664 of the review tools for devmode support?
<jdstrand> roadmr: and hi! :)
<roadmr> jdstrand: sure! I'll work on it, hello :)
<jdstrand> roadmr: it can be next week if needed
<jdstrand> roadmr: thanks :)
<roadmr> jdstrand: well it's fri evening so unless we escalate the hell out of it, it will be next week :(
<roadmr> jdstrand: I'll get the ball rolling though :)
<jdstrand> hehe
<jdstrand> roadmr: right, please don't escalate the hell out of it :)
<jdstrand> hehe
<roadmr> \o/ thanks :)
#snappy 2016-05-22
<zyga> o/
<mcphail> Hi. I can't remove the ubuntu-calculator-app from the command line on desktop 16.04. The command output is at http://paste.ubuntu.com/16596031/ and just churns repeatedly. The output of systemctl status "snap-ubuntu\\x2dcalculator\\x2dapp-5.mount" is at http://termbin.com/2ns3z . How can I proceed?
<darnis> anyone here?
#snappy 2017-05-15
<jobot> Hello, I have a beaglebone black. I'm running a snappy image by ogra. I also have a wifi adapter (https://www.logicsupply.com/uwn100/) but I don't know how to install the drivers. I have a guess, but it requires writing to the device storage. However, it seems that snappy is unwritable by default. Is there any guidance on this issue? thanks
<zyga> good morning
<olympionex> what mechanism does snapcraft use by default to set the directories where a snap command searches for shared libs?  All of a sudden, i have this problem where my command can't find libraries, but they exist in $SNAP/usr/lib.  If I shell into the command (snap run --shell command), I can manually set the LD_LIBRARY_PATH to $SNAP/usr/bin and it works fine.  I've tried adding an environment key to the snapcraft.yaml to set the LD_L
<olympionex> IBRARY_PATH, and while it does get set, for some reason it doesn't work unless I do it manually inside the shell
<olympionex> good morning
<zyga> olympionex: good morning
<zyga> olympionex: I believe snapcraft puts this in the generated command wrappers
<zyga> olympionex: after building your snap please look at meta/snap.yaml
<zyga> olympionex: you will see that the command: parts are re-written
<zyga> olympionex: and you can look at what they contain for insight
<olympionex> thanks, i'll have a look.  The command wrappers themselves seemed pretty empty, but now there are binaries in /snap/bin
<zyga> olympionex: the inaries in /snap/bin are just symlinks to 'snap'
<mup> PR snapd#3319 opened: wrappers: don't convert between []byte and string needlessly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3319>
<zyga> olympionex: those essentially do the same as "snap run $SNAP.$APP'
<Chipaca> zyga: good morning!
 * Chipaca off to get more coffee
 * Chipaca on 0hs of sleep, because Â¯\_(ã)_/Â¯ 
<zyga> Chipaca: omg, really?
<zyga> Chipaca: take some care :/
<Chipaca> yeah, gave up trying to sleep at 5am
<zyga> Chipaca: I'll be working on the road today, going to some magnificent places :)
<Chipaca> zyga: :-) nice!
<Chipaca> working on the road many years ago was when i realised i was in the future :-)
<zyga> something odd is going on with image building
<Chipaca> anyway, got most of the services work mapped out in my head, just need to make it happen now
<zyga> the i386 image has the new version
<zyga> the amd64 image does not
<Chipaca> hmm
<olympionex> zyga: hmm , ok -- I see.  Yeah its just calling the wrapper, but my wrappers have nothing except 'exec "command" "$@"'  I have an older working snap and those wrappers have the LD_LIBRARY paths set
<zyga> olympionex: interesting, can you look at any environment section that may be there? perhaps snapscraft has changed how it conveys the environment variables to snapd
<zyga> (I'm not a snapcraft developer)
<olympionex> zyga: yeah, it must have changed -- i'll have to either revert snapcraft or dig through and figure out what they changed
<olympionex> zyga: where are you driving to?
<zyga> olympionex: to girona :)
<zyga> olympionex: the whole city is full of flowers and flower scupltures and flower themes
<zyga> olympionex: it's amazing (when I mean the wohle city I do mean the whole city)
<olympionex> Catalonia?
<zyga> Chipaca: can you please have a look at https://github.com/snapcore/snapd/pull/3311
<mup> PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
<zyga> olympionex: yes
<olympionex> zyga: do you live in Spain or somewhere else?
<zyga> olympionex: most people here would say I live in Catalonia :)
<olympionex> haha
<zyga> olympionex: just on the coast, very close to Girona
<olympionex> nice
<olympionex> it is evening here and i've only been to work
<zyga> olympionex: https://www.youtube.com/embed/fAL90qLfGQA
<zyga> olympionex: (ad for the event)
<olympionex> its also winter...
<olympionex> so all those things look nice =)
<olympionex> that looks very  nice
<zyga> I must say that ajuntament did a very good job :)
<zyga> olympionex: yeah, summer is getting here in full force, the weekend was very hot
<Chipaca> olympionex: from a quick look at snapcraft, it should still be adding LD_LIBRARY_PATH
<Chipaca> olympionex: can you share your snapcraft.yaml? or is it secret :-)
<Chipaca> i also am not a snapcraft developer, fwiw
<olympionex> zyga: sorry, had to tend to dinner for a second
<zyga> olympionex: no worries :)
 * zyga thinks it would be good to have a snapcraft developer in this timezone
<pedronis> zyga: hi, did you push writable-localtime to snapcore/snapd by mistake?
<olympionex> its proprietary, so i removed/changed some of the critical bits -- https://pastebin.com/41d79JT4
<zyga> pedronis: no, that was ogra
<olympionex> as i said, a very similar snap i compiled recently has the LD_LIBRARY_PATH in the wrappers
<zyga> pedronis: I just pushed it there again to fix spread
<olympionex> but now i'm on 2.29 on this machine and it doesn't
<olympionex> checking on another machine with 2.27.1
<olympionex> hmm, the 2.27.1 wrappers don't have any library paths either
<zyga> Chipaca: if you have spare cycles we could also use a review on https://github.com/snapcore/snapd/pull/3271
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
<morphis> zyga: for https://github.com/snapcore/snapd/pull/3307 , you really want to have one environment: stanza per system definition in spread.yaml which repeatidly defines SNAPMOUNT/LIBEXECDIR? if we would do that for Ubuntu we would have that 31 times repeated
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<morphis> ah sorry, 35 times
<zyga> morphis: kind of yes, because that means I don't have to do it in task.yaml's
<zyga> morphis: but that's just one vote, see what others say
<zyga> morphis: ideally spred would have environment-script: section that lets us do this programmatically on 3 lines in one place
<morphis> zyga: I am in for not doing it in task.yaml but we should repeat the same key/value pair more than a single time
<morphis> zyga: right that is what I was proposing
<morphis> zyga: lets keep it as is for now and I will look into adding an environment-script/environment-include part to spread
 * zyga nods
<zyga> morphis: I merged master into some of your branches
<zyga> to fix conflicts and to re-start tests that were broken by new version string on the core snap
<morphis> zyga: thanks
<morphis> fgimenez: time to look into https://github.com/snapcore/snapd/pull/3307 and https://github.com/snapcore/snapd/pull/3308 today?
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<fgimenez> morphis: sure! :) will be on it in a bit
<morphis> fgimenez: thanks!
 * zyga goes for breakfast
<olympionex> zyga: since i'm building a classic mode snap, is snapcraft just expecting my to use ld.so.conf.d scripts maybe?  Still not sure why this snap i built sometime in the past has the exports and works and when i build now it doesn't
<zyga> olympionex: ah
<zyga> olympionex: classic confinement snap?
<olympionex> yeah
<zyga> olympionex: in that case there is no help, no love, no wrappers AFAIK
<zyga> olympionex: how are you buidling your snap contents?
<zyga> olympionex: is it using stage-packages?
<zyga> olympionex: https://new.zygoon.pl/post/state-of-classic-confinement/
<zyga> olympionex: have a look at this please
<olympionex> its dumping a deb that I made
<zyga> olympionex: that will not work correctly
<zyga> olympionex: the blog has the details
<olympionex> hmm, ok
<olympionex> it must have changed at some point
<olympionex> i have the working .snap i made in the past with the wrappers
<olympionex> and its classic confinement
<olympionex> but i'll read and see whats different
<Chipaca> zyga: âWith those three assumptions you and the bag of predictable low-level libraries [...]â
<zyga> Chipaca: ah s/you//
<zyga> morphis: can you please have a look at https://github.com/snapcore/snapd/pull/3311/files -- it needs a 2nd +1
<mup> PR snapd#3311: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <https://github.com/snapcore/snapd/pull/3311>
 * zyga really goes to eat something now
<Chipaca> morphis: in snapd#3271, why are you droppping tests/regression/lp-1580018?
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <https://github.com/snapcore/snapd/pull/3271>
<morphis> Chipaca: it is merged with the other test case I am modifying
<morphis> Chipaca: check the environment: part
<olympionex> zyga: Thanks for the info.  Looks like 2.26 was the last version that adds the LD_LIBRARY_PATH to classic snaps.  I have to use classic (afaik) because i have a daemon whose source I don't control and it has to write a .pid file to /var/run/ueyed.  Maybe there is a better way, but I haven't found it yet
<Chipaca> morphis: yeah
<zyga> olympionex: an interface :)
<zyga> olympionex: do you have the source for the daemon?
<olympionex> zyga: no, its a library for a camera we use.  I'm just snapping it to ease deployment.  It seemingly has a parameter to specify the PID path, but it doesn't seem to like if I write it anywhere else - I think it might be a bug in the daemon.
<zyga> olympionex: that will not be approved for a classic confinement snap
<olympionex> zygs: i'll look at interfaces again, I couldn't find great documentation last year, but it seems like there may be some new stuff
<olympionex> zyga: its not for the store
<zyga> olympionex: well, I'm here if you need me ;)
<olympionex> zyga: i only sideload it on our systems
<zyga> olympionex: but if you don't have the source it could be bad anyway, I'd suggest talking to your software vendor to help, it should be a simple fix for that pid parameter
<olympionex> zyga: yeah -- i notified them and haven't gotten a report back.  I guess they don't expect people to do funny things with their software...
<morphis> zyga: looking
<olympionex> zyga: they aren't in the FOSS spirit, their latest libraries use some kind of code protection deb I also have to install
<zyga> olympionex: vote with your money and even more reason to confine it
<zyga> morphis: thank you
<morphis> zyga: commented
<olympionex> zyga: haha, well my company votes with its money, but unfortunately there aren't a lot of great industrial 3D cameras to choose from.  This is just the driver for their camera
<olympionex> zyga: o
<olympionex> zyga: i'm off to dinner as well
<olympionex> zyga: hope i didn't interrupt your meal too much1
<zyga> morphis: replied
 * zyga nods
<zyga> olympionex: good luck then
<fgimenez> morphis: done, LGTM with small suggestions about systemd-escape
<morphis> fgimenez: how do you feel about the discussion I have with zyga on https://github.com/snapcore/snapd/pull/3308 ?
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<fgimenez> morphis: i like more the centralized approach proposed in the PR, will drop a line
<morphis> fgimenez: thanks
<mup> PR snapd#3311 closed: difs,interfaces/mount: add support for locking namespaces <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3311>
<mup> PR snapd#3318 closed: overlord/snapstate: Enable() was ignoring the flags from the snap's state, resulting in losing "devmode" on disable/enable. This fixes that <Created by chipaca> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3318>
<morphis> Pharaoh_Atem: ping
<Chipaca> pedronis: thanks!
<pedronis> Chipaca: np, I think zyga's remark about DeepEquals is right though if you want to change it in some follow up
<Chipaca> ok
<Chipaca> pedronis: what do you think about his suggestion on snapd#3292?
<mup> PR snapd#3292: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292>
<Chipaca> (if you looked at that at all)
<pedronis> Chipaca: IÂ think serviceName in the rewritten code has the same problem as app
<pedronis> mmh, maybe not
<zyga> hmm
<zyga> we need a generic "run-from-core-or-from-distro re-exec helper"
<Chipaca> pedronis: no, it's defined inside the loop
<pedronis> Chipaca: yea, sorry
<Chipaca> i still prefer the one with a slice though
<Chipaca> :-)
<Chipaca> OTOH, I'll be moving some of these around
<Chipaca> maybe I should do this after that
<Chipaca> hrm
<Chipaca> OT*O*OH I could make this work with helper funcs passing &err
<Chipaca> which might make it better
<pedronis> that sounds obscure
<Chipaca> yes
<Chipaca> pedronis: zyga: I'm going to close #3292
<Chipaca> reshuffle add/start/stop/remove
<Chipaca> (because they're wrong in subtle ways anyway, afaict)
<Chipaca> and then redoing 3292 after fixing that should be cleaner
<Chipaca> ok?
<zyga> Chipaca: +1
<pedronis> Chipaca: master should failed on tests/main/completation
<pedronis> https://travis-ci.org/snapcore/snapd/builds/232346364
<mup> PR snapd#3292 closed: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3292>
<Chipaca> pedronis: key gen
<Chipaca> timeout in prepare
<Chipaca> pedronis: what triggered this travis run?
<pedronis> Chipaca: my merge of your branch
<pedronis> :)
<Chipaca> pedronis: the expect script sets a timeout of 60s for the key gen
<Chipaca> and that timed out :-/
<pedronis> well we need to do something about entropy like we do on debian
<Chipaca> should I just re-run?
<pedronis> fgimenez should look into that IÂ suppose
<fgimenez> pedronis: yep, we can modify the images to include rng-tools and configure it to use /dev/urandom, for the time being we could do that on prepare-project too
<fgimenez> pedronis: i'll prepare a branch
<Chipaca> fgimenez: I think pollinate is part of the fix also, somewhere
<Chipaca> not sure if the linode hosts are using pollinate
<Chipaca> (I'm assuming the guests eat from the host's pool)
<Chipaca> pedronis: objections to restarting that travis build?
<fgimenez> pedronis: Chipaca ok i'll take a look, btw is it possible to snap download for an architecture different from the calling one?
<Chipaca> not currently
<fgimenez> or at least get the assembled .assert file
<fgimenez> Chipaca: aha, ok thanks, i find myself doing nasty things with the files dropped in var/lib/snapd/seeed/assertions by snap prepare-image :)
<zyga> morphis: hey, is cmd/cmd.go something that needs changes (for /snap vs /var/lib/snapd/snap) ?
<zyga> morphis: look at oldCore vs newCore
<mup> PR snapd#3316 closed: make /etc/localtime writable in timezone_control <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3316>
<morphis> zyga: nothing which any test covered so far
 * zyga shakes fist at openvswitch tests :/
<zyga> morphis: I think it's broken but we don't know because we re-exec where we use /snap anyway
 * zyga -> small walk
<pedronis> fgimenez: Chipaca: yes
<morphis> zyga: will have a look
<pedronis> fgimenez: set the envvar UBUNTU_STORE_ARCH
<fgimenez> pedronis: great, thanks a lot! just for snap (ie global env), not snapd right?
<Chipaca> oooh :-)
<pedronis> yes, this works only with snap download
<leeboby> Is there anyone have debug alsa in ubuntu core
<leeboby> The good codec device ported to ubuntu coer, but can't working normal
<mup> PR snapd#3320 opened: tests: improve entropy also for ubuntu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3320>
<fgimenez> pedronis: Chipaca snapd#3320 extends morphis' entropy solution to ubuntu classic systems, works fine on local executions
<mup> PR snapd#3320: tests: improve entropy also for ubuntu <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3320>
<morphis> fgimenez: nice!
<AdamH_> Hello, is there any current issues with ports.ubuntu.com? I get the error message about it not being resolvable
<diddledan> cjwatson: moving a conversation from #snapcraft on rocket.ubuntu.com: popey_ thinks there might be something in the build.snapcraft.io system that is rewriting my URLs - I use jhbuild in my snap as a subprocess to handle the build of my part but it is failing only on build service because a url has lost a / from http://
<diddledan> https://build.snapcraft.io/user/diddledan/corebird-snap/38228
<diddledan> relevant log line: jhbuild list: failed to parse /bacfbbd4b618017965cf05163fa2626f-xenial/parts/corebird/jhbuild/usr/lib/python2.7/site-packages/modulesets/http:/ftp.gnome.org/pub/GNOME/teams/releng/3.25.1/gnome-apps-3.25.1.modules: [Errno 2] No such file or directory:
<diddledan> u'/bacfbbd4b618017965cf05163fa2626f-xenial/parts/corebird/jhbuild/usr/lib/python2.7/site-packages/modulesets/http:/ftp.gnome.org/pub/GNOME/teams/releng/3.25.1/gnome-apps-3.25.1.modules'
<diddledan> oops
<diddledan> that was supposed to be a link
<diddledan> my snap is at https://github.com/diddledan/corebird-snap
<cjwatson> That is rather deeply unlikely ...
<diddledan> strange then that it works on a snapcraft cleanbuild locally
<cjwatson> Nothing in BSI or even in Launchpad really digs into the build at a low enough level that it could affect that kind of thing.
<cjwatson> You sure it's not the three lines immediately above the one you quote?
<cjwatson> id: âjhbuildâ: no such user
<cjwatson> python-gobject not found
<cjwatson> dbus-python not found
<diddledan> no, they're normal
<cjwatson> Could be just missing build-packages or something.
<cjwatson> Or maybe jhbuild uses HTTP code that fails to deal with proxies correctly.
<Chipaca> pedronis: https://travis-ci.org/snapcore/snapd/builds/232346364
<cjwatson> diddledan,popey: I'm pretty certain that the URL thing is a red herring.  jhbuild builds a local cache for remote URLs it needs to fetch, so that'll just be where it decides to stash them.
<diddledan> ok, that makes sense. I guess it's failing to download then due to the proxy
<cjwatson> It's just Python, so that is a *bit* surprising.
<cjwatson> But I have no better guess at the moment.  I have branches in flight to simplify the proxy setup from the client point of view.
<cjwatson> You're welcome to file a bug against https://bugs.launchpad.net/launchpad-buildd if you want more detailed investigation
<diddledan> thanks, I'll try a few more things first I think
<diddledan> one thing I can immediately do, is replace the git checkout of jhbuild with a release tarball
<diddledan> it might be that they broke it upstream
<morphis> zyga: /snap in cmd/cmd.go isn't yet a problem as we have reexec support explicitly disabled on fedora
<cjwatson> diddledan: (It's also possible to set up launchpad-buildd locally, though still a non-trivial amount of work ...)
<zyga> morphis: right, I agree
<zyga> morphis: idea: snap tool update-ns
<zyga> morphis: snap tool discard-ns
<zyga> (tool would be a hidde command)
<zyga> morphis: not sure this is necessary but I was thinking about it
<morphis> why not `snap update-ns` ?
<zyga> morphis: because there would be many of those and that would just clutter the top-level namespace
<zyga> morphis: and you could have nice stuff on `snap tool` like --no-reexec or --reexec or others
<zyga> morphis: useful for testing mainly
<morphis> as long as they stay hidden, that shouldn't be a problem
<zyga> morphis: it also has the `go tool` feeling which I like :)
<morphis> :-)
<mup> PR snapd#3282 closed: hooks: default timeout <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3282>
<morphis> zyga: mvo suggested something similar for the `snap forced-managed` command but waiting for feedback from niemeyer on that
<diddledan> lol, cjwatson, was that a trigger? I see you've just this second released a new launchpad buildd :-p
<zyga> morphis: aha
<zyga> morphis: that might make sense (the debug command I presume)
<morphis> yes
<cjwatson> diddledan: Nah, I sent the ticket for that on Friday afternoon, just tidying up now :)
<diddledan> co inky dink (coincidence)
<AdamH_> Any body else get the following when trying to install classic snap? Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/xenial/InRelease  Could not resolve 'ports.ubuntu.com'
<pedronis> that sounds very snap specific, is it trying to do some apt get stuff behind the scenes?
<AdamH_> It installs the snap and then start to see the errors the first time you use the snap sudo classic
<pedronis> ah, classic snap, not a classic snap
<mup> PR snapd#3319 closed: wrappers: don't convert between []byte and string needlessly <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3319>
<pedronis> sounds a question for mvo
<zyga> can someone do a (trivial) 2nd review on https://github.com/snapcore/snapd/pull/3315 please?
<mup> PR snapd#3315: spread.yaml: rename host's http proxy env vars <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3315>
<zyga> AdamH_: looks like a DNS issue (so far), can you ping ports.ubuntu.com?
<AdamH_> zyga: Yes I can resolve and ping ports.ubuntu.com
<mup> PR snapd#3315 closed: spread.yaml: rename host's http proxy env vars <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3315>
<zyga> AdamH_: intersting, so it may be something deeper
<AdamH_> zyga: Also works fine doing a sudo apt-get update once the snap has been setup, just fails on the initial setup for lsb-release
<pedronis> pstolowski: could you adjust the tests in snapd#3235  ? it seems very close
<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>
<morphis> zyga, pedronis, Chipaca, niemeyer: can you guys also have a look on https://github.com/snapcore/snapd/pull/3260 ? would like to get some eyes on the Go code before I spend to much time to getting the tests passing
<mup> PR snapd#3260: daemon: implement --user instance for snapd <Created by morphis> <https://github.com/snapcore/snapd/pull/3260>
<zyga> morphis: looking now
<pstolowski> pedronis, yes, will do
<morphis> zyga: thanks
<morphis> fgimenez, niemeyer: a review on https://github.com/snapcore/spread-images/pull/2 would be nice
<mup> PR spread-images#2: Add fedora-25-64 image <Created by morphis> <https://github.com/snapcore/spread-images/pull/2>
<fgimenez> morphis: sure, i'll have a look
<morphis> fgimenez: thanks
<zyga> morphis: done
<zyga> morphis: and done
<mup> PR snapd#3271 closed: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3271>
<zyga> is mvo around today?
<zyga> so https://github.com/snapcore/snapd/pull/3225 is now under testing, I'd like to land it and iterate on more tests
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<morphis> zyga: didn't you want a review from jdstrand_ on https://github.com/snapcore/snapd/pull/3271 ?
<mup> PR snapd#3271: cmd/snap-confine: use /etc/ssl from the core snap <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3271>
<zyga> morphis: yes but 1) it's the beginning of the cycle and 2) jdstrand said he is pretty busy on a new project now
<zyga> morphis: and I want to see it fix suse :)
<morphis> zyga: good
<zyga> morphis: the conference is coming up, we should do a .1 just for suse
<zyga> morphis: all those nice snaps should work :-)
<morphis> zyga: sure, wanted to get that PR merged and will add that patch to the suse pkg soon
<pstolowski> pedronis, i'm not sure what's wrong with #3235, seems like travis got confused, the tests are green but the status is not
<zyga> pstolowski: yeah, this happens sometimes
<pstolowski> indeed I saw this once in the past
<pedronis> pstolowski: no,  I was referring to Gustavo's comment, to not change the common fake hook handler
<pstolowski> pedronis, ah, sorry, my bad, I went to wrong PR
<zyga> Chipaca: around?
<mup> PR snapd#3320 closed: tests: improve entropy also for ubuntu <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3320>
<zyga> Chipaca: completion failure https://travis-ci.org/snapcore/snapd/builds/232387046?utm_source=github_status&utm_medium=notification
<Chipaca> zyga: around
<Chipaca> zyga: in tests/main/completion, during prepare?
<Chipaca> zyga: timeout creating a key
<zyga> Chipaca: ah, so that will go away (hopefully) with the branch I just merged
<zyga> thanks!
<zyga> Chipaca: how are you feeling? you said you didn't sleep at all
<Chipaca> zyga: i napped for about an hour, and have just finished lunch
<zyga> Chipaca: feel like doing a review for 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>
<Chipaca> feeling sleepy and weird but ok
<zyga> Chipaca: I'd like to land it and give it some real-world testing on anything I can think of
<Chipaca> zyga: that needs a review from gustavo :-)
<Chipaca> a re-review, even
<Chipaca> ah but he's not here
<Chipaca> hrm
<zyga> Chipaca: I addressed all of his feedback
<zyga> Chipaca: I wanted to just get it in and iterate on anything we find
 * zyga wishes it was less hot
<zyga> it's 28C easily now
<zyga> and only getting hotter
<zyga> morphis: https://github.com/snapcore/snapd/pull/3225 has conflicts
<mup> PR snapd#3225: cmd/snap-update-ns: add actual implementation <Created by zyga> <https://github.com/snapcore/snapd/pull/3225>
<zyga> morphis: shall I resolve them?
<morphis> zyga: isn't that your PR?
<zyga> no
<zyga> oh
<zyga> bad paste
<zyga> https://github.com/snapcore/snapd/pull/3307
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<zyga> I meant this one
<morphis> no, I will do that
<zyga> thanks!
<zyga> I'll re-review it once it is green
<zyga> pstolowski: hey, any updates on https://github.com/snapcore/snapd/pull/3120 ?
<mup> PR snapd#3120: interfaces/hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/3120>
<pstolowski> zyga, no, I didnt' have time to work on it yet; focusing on snapctl-outside-of-hooks branch still
<zyga> pstolowski: OK
<zyga> Chipaca: anything I can do to move the patch problem forward?
<zyga> Chipaca: or to cheat and get the InstallPath into sideinfo?
<zyga> Chipaca: (or similar that postpones the patch problem)
<Chipaca> zyga: the patch problem?
<zyga> Chipaca: AFAIK the patch system is currently unusable
<zyga> Chipaca: because we have no unpatch that allows rollback
<zyga> Chipaca: correct?
<Chipaca> zyga: because having unpatch that allows rollback implies rewriting the past
<pedronis> zyga: Chipaca: I'm getting run-checks --static errors/warning about spellings on master
<pedronis> relared to cmd/* stuff
<Chipaca> pedronis: where?
<pedronis> stuff like:
<pedronis> Checking spelling errors
<pedronis> cmd/config.sub:118:2: "nto" is a misspelling of "not"
<pedronis> ...
<pedronis> cmd/configure:1195:55: "includ" is a misspelling of "include"
<pedronis> Chipaca: just get master and run  ./run-checks --static ?
<Chipaca> pedronis: â( cd cmd && make distclean )â
<Chipaca> :-)
<mup> PR snapd#3321 opened: wrappers: service start/stop were inconsistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/3321>
<pedronis> Chipaca: thx, interestngly IÂ had not Makefile
<pedronis> s/not/no/
<Chipaca> heh
<cjwatson> popey: Did your home-assistant repository move somewhere else?  I'd like a handy test case for https://github.com/canonical-ols/build.snapcraft.io/issues/497
<Chipaca> pedronis: standup
<cjwatson> popey: though I guess I can use https://github.com/stuartlangridge/ColourPicker
<diddledan> is build.snapcraft.io down?
<cjwatson> diddledan: shouldn't be, though I just upgraded it.  what's up?
<diddledan> it's timing out
<cjwatson> seems fine from here
<diddledan> hmm
<diddledan> let me try a different browser
<diddledan> ok, seems that browser is b0rked - ms edge
<cjwatson> has it worked with BSI before?
<diddledan> yup, it was when I hit refresh that it didn't come back
<cjwatson> diddledan: OK, can you please file an issue on https://github.com/canonical-ols/build.snapcraft.io with whatever details you have?
<cjwatson> we should find out if that's consistent or what
<diddledan> ok, it's back now. I have no idea what's happened there
<diddledan> I've opened https://github.com/canonical-ols/build.snapcraft.io/issues/768 and noted that it seemingly works again now
<sborovkov> Chipaca: hi, question about rest api. {"type":"sync","status-code":200,"status":"OK","result":{"id":"12","kind":"configure-snap","summary":"Change configuration of \"core\" snap","status":"Doing","tasks":[{"id":"82","kind":"run-hook","summary":"Run configure hook of \"core\" snap","status":"Doing","progress":{"label":"","done":1,"total":1},"spawn-time":"2017-05-12T09:51:34.973297068Z"}],"ready":false,"spawn-time":"2017-05-12T09:51:34.973459255Z"}}   So it
<sborovkov> says "doing" but if I look at "progress" inside "done" is 1?
<sborovkov> so what should I actually be looking at that job is done
<Chipaca> pstolowski: do you remember offhand what the progress info means for the configure hook?
<Chipaca> sborovkov: wrt knowing whether it's done, it changes to status:Done
<Chipaca> ah!
<Chipaca> sborovkov: a total of "1" means there isn't progress information
<Chipaca> i.e., just spin
<sborovkov> hmm alright thanks
<pstolowski> Chipaca, no, but I just had a quick look and I don't see it doing anything about progress, so yes as you say it's (0,1) -> (1,1)
<Chipaca> yep
<zyga> re
<zyga> Chipaca: (sorry for disconnecting earlier)
<zyga> Chipaca: so what is the path forward for patch?
<Chipaca> zyga: a time machine
<zyga> Chipaca: do we have anything better?
<zyga>  :D
<zyga> Chipaca: question, is golint right or are we right?
<zyga> bootstrap.go:48:2: error var noNamespaceError should have name of the form errFoo
<Chipaca> ah! no, my bad
<Chipaca> i got confused
<Chipaca> zyga: ErrFoo is for values, FooError is for types
<zyga> Chipaca: aha
<Chipaca> zyga: wrt patches, the problem is that we want them to not be flagday events, ie we want them to be undoable
<Chipaca> zyga: for which we need to enable let past snapds undo patches of future snapds
<Chipaca> which is doable, but super easy to over-engineer
<zyga> Chipaca: aha
<zyga> Chipaca: hmm
<zyga> Chipaca: undo could be simply a snapshot we roll back to
<Chipaca> and i don't see a way out of having either a single epoch when we implement this thing, or having one last flagday
<zyga> Chipaca: e.g. /var/lib/snapd/state.json -> state.patch21.json
<zyga> Chipaca: but "past" snapd could read the symlink and say "gee, this sucks", I'll use state.patch20.json
<Chipaca> zyga: right, but we want to let a person revert a day (a week) after they got refreshed into something they didn't notice wasn't working
<zyga> Chipaca: devil is in details, specifically if you rollback just after upgrade
<zyga> Chipaca: or after collecting 100 extra changes
<zyga> Chipaca: indeed
<zyga> Chipaca: but how can future snapd downgrade non-programmatically?
<zyga> Chipaca: could we ask snapd to downgrade state to given patch level?
<Chipaca> easily (the problem is _past_ snapd :-p)
<zyga> Chipaca: e.g. snap set core patch-level=10
<zyga> Chipaca: then rollback
<Chipaca> I think it's doable and there should be a generic, simple, straightforward and correct way of expressing transformations to the state
<Chipaca> but making it have all those attributes is hard
<zyga> Chipaca: "generic simple straightforward", gee, sounds like a turing machine :D
<zyga> Chipaca: the question is this
<zyga> Chipaca: should we describe a transformation of state
<pedronis> zyga: so far we cheat with one shot Ensure stuff
<zyga> Chipaca: and teach current snapd to process the transformations
<zyga> pedronis: (yes)
<zyga> Chipaca: or should we do something (anything) else
<pedronis> if you need something today that's the way
<pedronis> maybe at the sprint we can discuss something else
<zyga> pedronis: mmm, I think this can wait for the sprint
<zyga> pedronis: it's for the oldest open branch:
<zyga> ah, 2nd oldest
<zyga> https://github.com/snapcore/snapd/pull/2837
<mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<zyga> I think that to fix it we need to store extra stuff about "try" snaps
<pedronis> not so clear what why we need to fix the past there though
<pedronis> it's broken atm
<zyga> pedronis: yep
<zyga> pedronis: so... maybe I can use a patch :)
<pedronis> and try stuff is ephemeralish
<zyga> pedronis: the tricky thing is that I'm not sure a patch can fix anything
<pedronis> well, more do nothing for old stuff
<zyga> pedronis: as we just don't have any state today there
<pedronis> just fix it for new stuff
<zyga> pedronis: I just want to start collecting more state
<zyga> pedronis: yep
<Chipaca> zyga: 3225 gtg once green
<zyga> pedronis: I think you are right
<zyga> Chipaca: thank you!
<zyga> Chipaca: I'm working on unit tests now
<Chipaca> zyga: pedronis: in any case, I think _backwards compatible_ changes (i.e. additions to structs) should be fine
<zyga> once it hits edge we should rally people on the forum to do some dedicated testing
<Chipaca> that is, we should be able to do those without having to bump patch level i think?
<pedronis> kind of
<pedronis> you need to redo them
<zyga> redo?
<pedronis> if you go back and forward
<pedronis> but maybe I'm not understanding what Chipaca is saying
<Chipaca> pedronis: I think you are
<Chipaca> i mean, yes you'd have to redo them on rollback/re-refresh
<pedronis> so you don't need a patch level for those but something
<Chipaca> because they're backwards compatible, we get away with their undo being a NOP
<Chipaca> but you still need to (re)do them when moving forwards
<zyga> Chipaca: here I think this is tricky because the forward path is also a nop
<zyga> Chipaca: as we cannot just guess the data easily
<zyga> Chipaca: (we might but I would argue not to as the cost outweights the benefit)
<Chipaca> zyga: how is the forwards a nop?
<zyga> Chipaca: because of zero values
<pedronis> as I said I see no reason to use a patch that might brick you to fix a development case
<Chipaca> if the patch do is a nop, and the undo is a nop, then there is no patch :-)
<zyga> Chipaca: we'd add a new field to a struct
<zyga> Chipaca: quick comment on https://github.com/snapcore/snapd/pull/3321
<mup> PR snapd#3321: wrappers: service start/stop were inconsistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/3321>
<popey> cjwatson: oh, did I delete that, sorry. Yes, Stuarts is a good alternative
<AdamH_> Not sure if i am going mad here, but has syslog been taken out of the latest edge builds?
<Pharaoh_Atem> morphis: pong
<kyrofa> AdamH_, indeed it has
<kyrofa> AdamH_, more details here: https://forum.snapcraft.io/t/change-in-logging-behaviour-on-ubuntu-core/591
<AdamH_> kyrofa: By design? Only noticed when trying to get mir-kiosk-apps to run and they fails as well.
<pedronis> Chipaca: I think I have hit some variant of aborting on seeding explodes problem in a test
<AdamH_> Thanks
<pedronis> Chipaca: good and bad
<Chipaca> ...?
<pedronis> Chipaca: well good I have a reproducer of something, bad it's a distraction from my current task
<Chipaca> pedronis: http://i.imgur.com/rQIb4Vw.gif
<pedronis> anyway good but will ignore for a bit
<Chipaca> man, *all* the tests that create keys are timing out :-(
<zyga> Chipaca: I'll look at that
<zyga> Chipaca: maybe the hwrng thing isn't helpin
<zyga> g
<Chipaca> is it done already?
<zyga> I think so
<zyga> yep
<zyga> yes, tests are rather red now
<Chipaca> do linode hosts even have a hwrng
<Chipaca> i still think we need pollinate
<zyga> Chipaca: I think recent intel and amd hardware have cpu instruction for that but I agree we need polinate
<zyga> or pollinate even
 * zyga reads https://forum.linode.com/viewtopic.php?t=2311%3E
<Chipaca> zyga: I doubt we're running on hardware
<zyga> Chipaca: that's okay, it's just an instructions any VM can use
<zyga> (given recent hardware)
<zyga> still reading though
<AdamH_> Looks like the latest edge build breaks the mir-kiosk-apps demo with [QPA] QMirClientClientIntegration: connection to Mir server failed. Mir returned: ""
<zyga> AdamH_: any denials?
<AdamH_> zyga: Nope not seeing any
<zyga> did the snap itself change/
<AdamH_> zyga: Not that I am aware of, we use it as a baseline to test mir-kiosk install when we have issue with the builds of our own app. Hence noticing the error
<zyga> Chipaca: heh, forum suggests to run this in a separate terminal: >while true ; do mandb ; done
<zyga> Chipaca: as source of entropy ;D
<Chipaca> /o\
<zyga> AdamH_: does it work on stable core/
<AdamH_> zyga: No because vc4 is missing from the build so mir-kiosk does not start on rPi3
<AdamH_> so been running on the edge build which includes vc4
<zyga> AdamH_: do you have an edge revision where id still worked?
<morphis> Pharaoh_Atem: you had time to rework the snap-mgmt script?
<Chipaca> FWIW, we do seem to have /dev/hwrng
<Pharaoh_Atem> morphis: I was going to after you sent me that list of files
<morphis> Pharaoh_Atem: ah, right
<morphis> I knew that I forgot something ..
 * zyga merged update-ns!
<zyga> now for real world feedback
<zyga> and those unit tests :)
<zyga> but first hwrng :((
<AdamH_> zyga: Unfortunately not
<mup> PR snapd#3225 closed: cmd/snap-update-ns: add actual implementation <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3225>
<zyga> if anyone notices something funky with the content interface, let me know please
<zyga> fgimenez: did you see https://blog.travis-ci.com/2017-05-11-introducing-build-stages?utm_source=broadcast&utm_medium=notification
<zyga> fgimenez: anything we could benefit from
<zyga> ??
<fgimenez> zyga: yes, not sure if it makes too much sense for snapd suite though
<fgimenez> zyga: don't really know :) what do you think?
<zyga> fgimenez: I was thinking about running some quick smoke test early on (say unit tests) and then run the spread suite only if that fist thing passes
<zyga> fgimenez: so sequential check then parallel spread
<zyga> fgimenez: maybe even just run unit tests as an early warning systme
<zyga> *system
 * zyga is tired and takes a break
<fgimenez> zyga: i think we can do that without stages, we do something similar now with the static tests, unit are more expensive and that would impose an upfront delay to all the builds, currently we are making good use of spread paralellization by executing the unit tests as a regular task
<fgimenez> zyga: but yes, maybe it is good to have that early warning system, there are always tradeoffs and perhaps the benefits of having it are better than having the execution time improvements
<fgimenez> mmm i'm getting a panic on pi3 (2.26) http://paste.ubuntu.com/24581419/
<AdamH_> zyga: mir-kiosk-apps works when using the beta channel if that helps
<Chipaca> fgimenez: is there a particular reason you make rngd use /dev/urandom ?
<Chipaca> fgimenez: (in other words, if I changed it to use /dev/hwrng if present, would that be ok?)
<fgimenez> Chipaca: yes i think so, morphis did that changes though, i just enabled them for ubuntu, he can confirm if that is ok
<Chipaca> ah
<morphis> Chipaca: just because that is available everywhere, qemu, linode, ..
<Chipaca> morphis: afaict hwrng is also available in those places
<Chipaca> (on debian you need to load a module)
<morphis> Chipaca: not on qemu unless you enable that with the qemu cmd line
<Chipaca> in any case, i'll propose a branch (if this change makes debian happier)
<Chipaca> morphis: strange, i see it in qemu in both ubuntu (by default) and debian (after the modprobe)
<morphis> Chipaca: really? I had to add -device virtio-rng-pci to get the host hwrng forwarded
<Chipaca> morphis: and if you modprobe tpm-rng?
<morphis> guess that still needs a tpm, either emulator by qemu (which it may does by default) or forwarded from the host
<morphis> Chipaca: but let me try that
<elopio> cjwatson: is it possible to retrigger a build in build.snapcraft.io?
<cjwatson> elopio: not at the moment
<cjwatson> (this is a bug IMO, though not sure if it's been filed)
<elopio> cjwatson: I couldn't find it, so I will report it. And is there a plan to do this with an API? For some cases, I want to trigger the build from travis.
<cjwatson> elopio: Thanks in advance for the report.  My feeling is that if you're getting to the point where you need an API then you should be using the underlying Launchpad facilities directly, not via BSI.
<elopio> cjwatson: that works for me. However, the UI is a lot nicer on this side. I would appreciate a nice dashboard even for the ones that are hooked to my weird CI.
<cjwatson> elopio: You can certainly request it (though in a separate issue, please).  Just telling you that APIs aren't a priority at the moment.
<elopio> cjwatson: I will leave somebody else (who actually needs it) to report it, because launchpad indeed solves my use case.
<cjwatson> OK
<Chipaca> morphis: gah, modprobe works, device gets created, but rngd fails to read it :-(
<morphis> :-)
<Chipaca> morphis: (also, there's a rng-tools5 that seems to be ubuntu's rng-tools; rng-tools in debian is ancient)
<morphis> Pharaoh_Atem: https://paste.ubuntu.com/24581840/
<morphis> Pharaoh_Atem: also looks like the snaps didn't got unmount now with my installation of the snapd 2.25 package on F25 (fresh install)
<morphis> Pharaoh_Atem: for the paste I unmounted them manually
<Pharaoh_Atem> hmm
<Pharaoh_Atem> I didn't change anything regarding that
<mup> PR snapd#3322 opened: overlord: make config defaults from gadget work at also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
<mup> PR snapcraft#1248 closed: snap: include asset tracking details in snap/snapcraft.yaml <Created by josepht> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1248>
<mup> PR snapd#3323 opened: overlord/snapstate: avoid creating command aliases for daemons  <Created by pedronis> <https://github.com/snapcore/snapd/pull/3323>
<mup> Bug #1690880 opened: test_snappy_version fails on artful <cloud-init:New> <Snappy:New> <https://launchpad.net/bugs/1690880>
#snappy 2017-05-16
<elfgoh> Hi i am trying todo a snap login
<elfgoh> get an error error: cannot get snap access permission from store: Post https://myapps.developer.ubuntu.com/dev/api/acl/: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) (see "snap login --help")
<mup> PR snapcraft#1318 opened: tests: refactor the travis jobs using stages <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1318>
<morphis> mvo: morning!
<morphis> mvo: can you have a look at https://github.com/snapcore/snapd/pull/3308 and https://github.com/snapcore/snapd/pull/3307 ?
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<mvo> hey morphis! good moring. sure, I have  alook now
<morphis> mvo: thanks!
<zyga> AdamH_: specifically apparmor/profiles, seccomp/profiles
<zyga> 07:49 < zyga> AdamH_: intetesting, yes that does help
<zyga> 07:49 < zyga> AdamH_: can you use beta and collect all the security profiles? go to /var/lib/snapd/
<zyga> 07:49 < zyga> AdamH_: and in each directory look for a file named after the application
<zyga> 07:49 < zyga> AdamH_: intetesting, yes that does help
<zyga> 07:49 < zyga> AdamH_: can you use beta and collect all the security profiles? go to /var/lib/snapd/
<zyga> 07:49 < zyga> AdamH_: and in each directory look for a file named after the application
<zyga> AdamH_: then go to edge and collect the same set of files
<morphis> zyga: btw. we should add a page on snapcraft.io which explains how to collect necessary debug material
<morphis> zyga: we do something similar for our stack documentation (e.g. https://docs.ubuntu.com/core/en/stacks/network/network-manager/docs/report-bug)
<zyga> morphis: good idea, I will write something like that!
<zyga> morphis: how is everything so far, any fires?
<morphis> zyga: no fires I know of :-)
<zyga> good :)
<morphis> zyga: only fire is that my spread/qemu setup times out a lot today ..
<zyga> morphis: on a specific test or on preparation?
<morphis> zyga: it times out when running "dnf update"
<morphis> must be my network or such a like
<zyga> morphis: maybe setup a local proxy?
<Son_Goku> morphis, zyga: can you guys get robert ancell to properly tag releases on GitHub
<Son_Goku> it's very annoying that he's making releases that don't exist :/
<morphis> Son_Goku: sure
<zyga> Son_Goku: huh? in what way?
<morphis> Son_Goku: can you just drop him a mail with zyga and me in CC?
<morphis> zyga: snapd-glib
<Son_Goku> I mean, he's making the tarballs on LP, but they don't have corresponding git tags
<morphis> I guess he just releases into the lp/archive
<Son_Goku> yeah
<Son_Goku> it's just annoying because while I can "guess" where the tarball comes from
<Son_Goku> I don't know it
<morphis> Son_Goku: not very professional, I know
<morphis> Son_Goku: if you don't want to write a mail, a forum topic would be good too
<Son_Goku> I'll send an email later
<Son_Goku> as it is, I'm desperately trying to go back to sleep
<Son_Goku> it's 2:24am here :(
<morphis> Son_Goku: do that!
<morphis> pedronis, mvo: https://forum.snapcraft.io/t/gadget-snap-config-defaults-dont-work/409/5 should be added to https://forum.snapcraft.io/t/next-snapd-2-27/572 , shouldn't it?
<mvo> morphis: Ã¼1
<mvo> morphis: +1
<morphis> mvo: actually is there a list of things planed for 2.27?
<morphis> mvo: ah sorry, it is already in the post :-)
<zyga> mvo: good morning :)
<mvo> hey zyga
<mvo> morphis: :)
<morphis> mvo: too early :-)
<mvo> morphis: no problem at all
<abeato> mvo, quick question, is snapd 2.26.1 in the edge core snap already?
<mvo> abeato: yes
<zyga> mvo: something is wrong with core
<mvo> abeato: well, it should be, looks like there is a upload bug in our edge snap right now, let me double check what is going on
<mvo> zyga: with core uploads?
<zyga> mvo: amd64 core (edge) is still pre-version change
<abeato> mvo, ahm, ok
<zyga> mvo: and in fact gets no updates
<mvo> zyga: I think its the new version string
<zyga> mvo: well, I wish I had the new version string, I think it didn't build since
<zyga> mvo: note that i386 did build
<mvo> zyga: but that should have got fixed last week, so maybe something less is broken
<mvo> zyga: oh?
<mvo> woah
 * mvo looks
<zyga> mvo: are you on edge?
<zyga> mvo: I'm on edge and I have 1909
<zyga> refreshed:   2017-05-12 06:20:00 +0200 CEST
<mvo> zyga: what does snap version tells you?
<zyga> snap    2.26.1+201705112259.git.e719341~ubuntu16.04.1
<mvo> zyga: ok, at least abeato gets a pretty recent snapd this way :) but yeah, edge-edge is 5 days old :/
<zyga> mvo: btw, update-ns landed
<abeato> mvo, recent enough for us, thanks :)
<zyga> mvo: but I noticed we don't run any tools from core (discard-ns, update-ns)
<mvo> zyga: holly cow
<zyga> mvo: so it will be broken
<zyga> mvo: I'm fixing that now
<mvo> zyga: please describe it in the forum post for 2.27, thats a huge thing
<zyga> mvo: not in tests but in practice
<zyga> mvo: yes, I was planning to already :)
<mvo> zyga: ok
<mvo> zyga: thank you :)
<zyga> mvo: I'll be fixing the run-from-core aspect of discard/update ns as I watch the town hall
<mvo> zyga: TestLokcUnlockWorks fails in traivs
<mvo> zyga: meh :(
<zyga> mvo: oh? missing dependency or something else?
<zyga> mvo: do you have a log?
<mvo> zyga:
<mvo> https://travis-ci.org/snapcore/snapd/builds/232709633?utm_source=github_status&utm_medium=notification
<mvo> zyga: it looks like its simply not working for whatever reason, not super important right now, I will just skip the test on travis for now, but slightly strange
<mup> PR snapd#3324 opened: Androidboot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324>
<zyga> mvo: thanks, I see now
<zyga> mvo: weird, it passed tests before
<mvo> zyga: we did not run the unit tests for a while on travis
<mvo> zyga: only inside spread indirectly
<zyga> mvo: aaah
<zyga> mvo: I see
<zyga> hum hum hum, maybe weird filesystem
<zyga> mvo: interesting find
<mvo> zyga: anyway, just wanted to mention it, its not a big deal right now :)
<fgimenez> hi mvo good morning :) during the 2.26.1 validation at beta i had two panics on pi2 http://paste.ubuntu.com/24581585/ and pi3 http://paste.ubuntu.com/24581419/, it would be great if you could take a look
<pstolowski> morning
<mvo> fgimenez: thanks, checking now
<zyga> mvo: ah, obvious bug :/
<zyga> mvo: we don't check for the length of l
<zyga> mvo: probably data corruption but could be something else
<mvo> zyga: obvious bug in the above pastebins or flock or something else :) ?
<fgimenez> mvo: thank you, i also wanted to mention, i've been using the new --extra-snaps capability of prepare-image (to include assertions along with sideloaded snaps), it works fine but i have an issue, probably it is expected, if i download the kernel snap from stable and then create the image with --channel beta, then kernel tracks beta and is automatically refreshed to the latest version on that channel
<zyga> mvo: yes
<zyga> mvo: in the pastebins from fgimenez
<mvo> fgimenez: indeed, that is expected behaviour
<mvo> zyga: aha, ok
<zyga> mvo: do you want me to propose a PR?
<fgimenez> mvo: ok thanks
<mvo> zyga: sure, if you have it all tracked down already +1
<zyga> great :)
<mvo> zyga: I have not even looked yet properly :)
<zyga> mvo: interestingly we vendor an older version of your package
<zyga> mvo: but your package is also panicking in master
<zyga> mvo: is api brakage acceptable?
<mvo> zyga: hm, any chance we could avoid it :) ?
<zyga> mvo: yes, let me tweak things
<zyga> ah, it's just internal API, no worries
<zyga> all good :)
<mvo> fgimenez: any idea why this crash is triggered now, did we just not test before?
<mvo> fgimenez: test for this before?
<mvo> fgimenez: the code in this area has not really changed recently afaict
<mup> PR core#42 opened: fix version number length <Created by mvo5> <https://github.com/snapcore/core/pull/42>
<fgimenez> mvo: yes we executed the same tests before (there have been changes in the suite but not much disruptive), no idea why this is happening now
<fgimenez> mvo: i created the image using the new prepare-image capability, is the only difference i think
<zyga> mvo: FYI the crash looks like data corruption on the card
<fgimenez> zyga: aha thanks! but it happens on two different cards and boards (pi2 and pi3), is it possible that both are corrupted?
<zyga> fgimenez: maybe, though less likely
<zyga> fgimenez: can you do a dump of the uboot environment file please?
<fgimenez> zyga: sure, i need to reproduce first, (now i'm running the tests after refreshing from stable) will ping you when i have it
<zyga> fgimenez: if it was random it may not happen again
<mvo> fgimenez: thank you. keen to see the dump
<zyga> mvo: https://github.com/mvo5/uboot-go/pull/2
<mup> PR mvo5/uboot-go#2: Detect and return errors from Open in case of malformed data <Created by zyga> <https://github.com/mvo5/uboot-go/pull/2>
<mvo> zyga: the api of uenv should not allow to write something without "=" but maybe something else is going on :/
<zyga> mvo: well, whatever you write, you may read smurfs back
<zyga> mvo: have a look at the PR
<mvo> zyga: yeah, your fix is great
<zyga> mvo: separately I think we want two more changes
<zyga> mvo: a change that lets open skip malformed data
<zyga> (better than failing outright)
<zyga> mvo: and an update to snapd vendor commit
<zyga> mvo: shall I make those?
<mvo> zyga: yes, thank you!
<mvo> zyga: first branch is in
<mvo> zyga: quick review for https://github.com/snapcore/core/pull/42 would be great
<mup> PR core#42: fix version number length <Created by mvo5> <https://github.com/snapcore/core/pull/42>
<zyga> mvo: looking
<zyga> mvo: done
<NicolinoCuralli> hi guys, what part of gpg bundle snapcraft register-key upload on the store?
<mup> PR core#42 closed: fix version number length <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/42>
<pedronis> NicolinoCuralli: only the public bits
<NicolinoCuralli> pedronis: thanks
<zyga> mvo: https://github.com/mvo5/uboot-go/pull/3
<mup> PR mvo5/uboot-go#3: Add OpenWithFlags and OpenBestEffort flag <Created by zyga> <https://github.com/mvo5/uboot-go/pull/3>
 * zyga thinks about breakfast
<mvo> zyga: very nice, thank you!
<zyga> mvo: I'll get the snapd copy updated now
<mvo> zyga: \o/
<Chipaca> o/
<Chipaca> mvo: spread has "residual artifacts"
<mvo> Chipaca: aha, interessting. you mean for the coverage results?
<Chipaca> mhmm
<Chipaca> https://github.com/snapcore/spread#residue
<Chipaca> you then have to decide which of the 8 coverage files we get you want :-)
<Chipaca> eee
<mvo> Chipaca: I can look into that, however I also kind of like the run of the unit tests in an extra step mostly because if something is wrong there things fail early
<Chipaca> our first codecov report came in :-D
<mvo> Chipaca: weeeee
<Chipaca> 77% :-/
<mvo> yeah
<Chipaca> that's dropped a lot since we looked at it last
<mvo> this is why I want it :)
<Chipaca> mvo: thanks for doing this :-)
<ogra_> oh, mondrian pictures!
<mvo> spamming the comments is maybe not that great, I wonder if that can be disabled
<Chipaca> mvo: the problem with doing it in a different step is that we eat up a travis slot
<mvo> Chipaca: its being done in the same travis run, it just takes a bit of extra time
<zyga> fgimenez, mvo: https://github.com/snapcore/snapd/pull/3325
<mup> PR snapd#3325: vendor,partition: fix panics from uenv <Created by zyga> <https://github.com/snapcore/snapd/pull/3325>
<Chipaca> ah!
<Chipaca> that's alright then :-D
<mup> PR snapd#3325 opened: vendor,partition: fix panics from uenv <Created by zyga> <https://github.com/snapcore/snapd/pull/3325>
<mvo> Chipaca: I will look how much extra time exactly
<Chipaca> mvo: we could always have it in spread just after --static
<mvo> Chipaca: indeed, this is what I did now
<zyga> mvo: I'll focus on run-from-core for internal tools now
<Chipaca> oh?
<mvo> zyga: thank you
 * Chipaca clicks 'view all'
<mvo> Chipaca: or was I just dreaming this ?
<zyga> Chipaca, mvo: FYI: travis has added "build stages", that may be of some help to you (perhaps)
<Chipaca> mvo: no, it's there
<Chipaca> mvo: it's early
<Chipaca> mvo: i thought i was looking at spread.yaml :-)
 * ogra_ sees the core uploads succeed and hugs mvo 
<mvo> :) no worries
<mvo> ogra_: yay
<mvo> more cores!
<ogra_> :D
 * zyga looks at delta update for core
<zyga> niiiiice :)
<zyga> mvo: hmm
<zyga> mvo: I broke edge
<zyga> - Setup snap "core" (1934) security profiles (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented)
<zyga> mvo: (this is the thing I mentioned)
<zyga> mvo: we may want to revert edge to previous for a sec
<zyga> mvo: and land a change that fixes this first
<zyga> mvo: (update-ns runs from distro)
<zyga> mvo: not from core
<Chipaca> zyga: dude, you owe us so much cake
<mvo> zyga: ok
 * ogra_ guesses zyga was just distracted by the townhall :P
 * Chipaca forgot about the town hall, but slept 8 hours \o/
<zyga> Chipaca: it would be caught by the upgrade test but those don't run on each PR
<zyga> (i think)
<ogra_> it still running, IoT just up right now
<ogra_> *it is
<fgimenez> zyga: thanks for the branch! trying to get the dump in a bit, will let you and mvo know how it goes
<mvo> fgimenez: if you can not get the dump but just the binary uboot.env that is fine too
<fgimenez> mvo: ok thanks
<Chipaca> zyga: could you finish your review of snapd#3321?
<mup> PR snapd#3321: wrappers: service start/stop were inconsistent <Created by chipaca> <https://github.com/snapcore/snapd/pull/3321>
<Chipaca> then i can land that and be happy
 * Chipaca penciled in 6 hours of being happy today
<Chipaca> pencilled*
<zyga> Chipaca: yes, after the tools from core branch
<mvo> Chipaca: wdyt, a single coverage report that is kept being updated is ok? codecov will not spam, it will have one report per branch and keeps updating it. do you think this is acceptable?
<Chipaca> mvo: yes, i think that's fine (also i don't mind it posting the report as a comment on the pr)
<Chipaca> because only the author of the pr, and people who've already commented, will get that email
<mvo> Chipaca: ok, I will bring it up in the standup
<Chipaca> ok
<Chipaca> mvo: will you add the widget?
<mvo> Chipaca: I can :)
<mvo> Chipaca: the badge you mean?
<Chipaca> yeah
<mvo> Chipaca: let me add it
<Chipaca> i'm a sucker for badges
<mvo> Chipaca: hahaha
 * mvo hugs Chipaca
<mvo> Chipaca: badge added now
<Chipaca> mvo: yep! thanks :-)
<Chipaca> tried to add a <3 to the commit, but github won't let me
<mup> PR snapd#3326 opened: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326>
<zyga> mvo: can you please look at https://github.com/snapcore/snapd/pull/3326
<mup> PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326>
<zyga> mvo: the main/listing test needs update again
<zyga> mvo: and with lower priority, can you look at https://github.com/snapcore/snapd/pull/3308 - this will define how all our spread tests look like in wake of support of non-debian distributions;
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<zyga> mvo: I feel somewhat strongly about it but I will accept your call
<morphis> zyga: asked mvo already this mornign to have a look :-)
<mvo> zyga, morphis it is on my list, unfortunately its a longish list but I will definitely get to it today
<morphis> mvo: no hurry
<morphis> mvo: don't need a full review yet, just your call on the discussion I had with zyga on it
<mvo> morphis zyga: you are mostly interessted in the centralized vs non-centralized approach?
<morphis> mvo: yes
<zyga> mvo: thank you
<mvo> thanks, I will read the PR and scratch my head a little bit over it
<NicolinoCuralli> hi guys another question about signing : what ubuntu-image deposits on image of gpg bundle?
<zyga> is anyone handling the main/listing test?
<zyga> mvo, Chipaca, fgimenez: ^
<Chipaca> zyga: what's going on with main/listing?
<zyga> Chipaca: new edge version broke it
<zyga> again :)
<Chipaca> augh
<Chipaca> 16-2.26.1+201705151555.git.d15bf would do that, yes
<Chipaca> that's a nasssty version number
<Chipaca> (also, is that a unique hash, or has it been truncated?)
<zyga> truncated :/
<Chipaca> hash snippet i mean
<zyga> mvo: I'd say we should drop the date
<zyga> and just go with the hash
<ogra_> we really need to drop the time from the timestamp
<zyga> yes
<ogra_> date is totally enough if we keep the hash anyway
<zyga> well, hash has the date if you git show it ;)
<mvo> zyga: I think there was a discussion with gustavo about that, he was keen to keep the timestamp but considered the git hash clutter
<Chipaca> ok, i'll fix the test
<mvo> Chipaca: truncated
<Chipaca> I think the timestamp is more immediately useful
<mvo> Chipaca: so we can cut it out
<Chipaca> mvo: is this long version ever going to leave edge?
<Chipaca> (should it?)
<mvo> Chipaca: no, only edge will have ugly versions
<Chipaca> ok
<mvo> so yeah, I can push another PR to kill the git hash :)
<zyga> mvo: so how will we do beta builds?
<zyga> mvo: separately from edge builds?
<Chipaca> mvo: let me know what it will look like, so i can fix the listing test to match
<mvo> zyga: right now all beta builds are syncronised with uploads of a snapd with a proper version number
<mvo> Chipaca: I think just 16-2.26.1+201705151555
<mvo> zyga: not sure if this reply makes sense, I can write more if its unclear :)
<ogra_> zyga, well, athe actual plan was to do different chasnnels from different archives (beta/stable without PPA) ...
<ogra_> but we're still far from that
<ogra_> which is why mvo makes sure to have a stable snapd in the PPA before a beta snap gets rolled atm
<zyga> mvo: I think the git hash would be more useful
<zyga> mvo: than the date
<zyga> mvo: certainly to answer "is this commit in that build already"
<mvo> zyga: fair enough, we can discuss this in the standup. I would like to have both but there is no enough space on this margin for this wonderful version
 * ogra_ also thinks to remember that in the last discussioon we agreed to cutting the date shorter and leave the hash instead
<mvo> hm, maybe
<zyga> mvo: another idea, let the version be whatever but teach snap info to publish key-value meta-date like git-hash build-date and other nice stuff
 * mvo looks at it
<zyga> mvo: no need to cram it into version and also useful for other
<ogra_> we want a clear distinction between stable and non stable builds in the snap version too though
<zyga> fine, I bet we can do that somehow too
<ogra_> (so that you dont need to actually run an image to determine the version)
<mup> PR snapd#3327 opened: tests/main/listing: tweak core version regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/3327>
<Chipaca> zyga, mvo: ^
<zyga> reviewed
 * zyga -> coffee break
<Chipaca> zyga: i'm going to need a timeframe on "this test needs to be different because this thing will change at some time when the stars align" :-)
<pedronis> mvo: hi, could you look at snapd#3323 again ?
<mup> PR snapd#3323: overlord/snapstate: avoid creating command aliases for daemons  <Created by pedronis> <https://github.com/snapcore/snapd/pull/3323>
<mvo> Chipaca, zyga, ogra_: how about this as a compromise? http://paste.ubuntu.com/24586017/
<zyga> Chipaca: hmm?
<Chipaca> mvo: does it fit one more character?
<mvo> Chipaca: yes
<Chipaca> in fact does it fit five more :-(
<mvo> Chipaca: no
<mvo> Chipaca: ;)
<Chipaca> figured as much
<zyga> mvo: do we really need the date?
<Chipaca> mvo: zyga says the 16-2 at the start will change to 16-2.24.1
<Chipaca> at which point this will not fit
<mvo> zyga: I thought we did but I may misremember
<morphis> zyga: did you saw you're going to look into the problem with the unnecessary bind call snapctl issues and then gets killed by seccomp?
<mvo> zyga, Chipaca: we could shorten 2017 to 17 and get two chars
<mvo> Chipaca, zyga: but I think we should keep it as is for now (fix the test of course) and talk about it in the standup, I have the feeling in the discussion there it may change anyway (because high bandwidth discussion etc)
<zyga> morphis: yes, I recall this but I need to fix update-ns run-from-core and unit tests first
<zyga> mvo: 17 will look confusing, how about just date and hash?
<morphis> zyga: so something you're going to look into for 2.27?
<zyga> mvo: 16-2.24.1-20170516+git....
<zyga> morphis: yes, certainly
<morphis> zyga: ok, lets add that to https://forum.snapcraft.io/t/next-snapd-2-27/572/2
<morphis> will see if there is a bug
<morphis> mvo: can you add https://bugs.launchpad.net/snappy/+bug/1644573 to the 2.27 page?
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573>
<Chipaca> zyga: mvo: agreed to not change until discussed, seems there are lot of options
<Chipaca> zyga: mvo: and not sure at this point what questions we want to answer from that information :-)
<zyga> Chipaca: one option is to raise the limit :)
<Chipaca> if we have just the timestamp, you need to check master to see what commit we were at at that timestamp, and then check if that contains whatever branch it is you're interested in
<Chipaca> whereas if what you're wanting to answer is "is this edge from last night", you're done
<Chipaca> if you have the commit, you need to check master to see if that commit contains whatever it is you're after
<mvo> morphis: sure, will do. the page should be a wiki so you can also add it if you want
<Chipaca> and if you're wanting to answer "is this edge from last night", you need to check what commit it was
<morphis> mvo: last time I checked, I couldn't
<Chipaca> or rather, you need to check if that commit is one of the ones from last night
<Chipaca> which means looking for one random string in a collection of random strings, which is worse
<Chipaca> which is why i prefer the timestamp
<mvo> morphis: that means I suck, let me fix it
<mvo> morphis: maybe something else is funny, it is marked as a wiki
<mvo> morphis: added it now
<morphis> mvo: maybe just for a few people?
<mvo> morphis: good question
<mvo> fgimenez: any news on that uboot.env file? just curious because I'm slightly worried about this one
<fgimenez_> mvo: not yet, still running the scenario in which we execute the suite after upgrading from stable, it'll finish soon though (91/116 pi3 and 57/116 pi2)
 * Chipaca takes a coffee break
<zyga> re
<zyga> Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3326 when you're back please
<mup> PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326>
<Chipaca> zyga: i didn't get to leave yet
<Chipaca> looking
<zyga> Chipaca: I need to re-add some of the logging
<zyga> Chipaca: for tests to be happy
<zyga> Chipaca: but this (or similar) has to land to unbreak edge
<Chipaca> zyga: having a list of distros not to reexec in seems weird
<Chipaca> (yes i know that's already there)
<zyga> Chipaca: yes but there's a good reason for that for now
<zyga> Chipaca: once we have CI I'd like to pop fedora from that list
<Chipaca> zyga: which is that reason?
<zyga> Chipaca: snap-confine still has some build-time choices
<Chipaca> zyga: it sounds to me like we should have a list of distros to reexec in, not the other way around
<zyga> Chipaca: and we must build snap-confine in a way to have more flexibility there (talk to snapd)
<Chipaca> OTOH, infinite derivatives
<zyga> Chipaca: I think this list can be removed soon
<zyga> Chipaca: it's more like "do I ship with patches"
<zyga> Chipaca: and "is snap-confine from core useful to me"
<zyga> Chipaca: but those can be patched in the distro as well :)
<pedronis> Chipaca: so master is broken ?
<zyga> Chipaca: we also don't re-exec in places that are not tested, it makes it more likely that we get a working result
<Chipaca> pedronis: well, there's a failing test
<zyga> pedronis: master is broken wrt the new core version
<zyga> pedronis: and edge is broken wrt update-ns not running from core
<zyga> pedronis: (but not broken in any test)
<pedronis> well, I see this too:  subprocess.CalledProcessError: Command 'tail -n 10 /var/log/syslog' returned non-zero exit status 1
<pedronis> in interfaces-log-observe
<pedronis> is that fixed somewhere
<pedronis> zyga: we don't have CI for core ?
<pedronis> or not enough of it
<pedronis> I mena the project
<pedronis> s/mena/mean/
<Chipaca> pedronis: as soon as snapd#3327 lands we're good again
<mup> PR snapd#3327: tests/main/listing: tweak core version regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/3327>
<Chipaca> pedronis: ah. ouch.
<pedronis> Chipaca: is log-observe stuff already fixed?
<Chipaca> no
<pedronis> :(
<Chipaca> i'll fix that when i come back from my break
<Chipaca> but now, i'm going to go take that break
 * Chipaca has been trying for a while now :-)
<zyga> pedronis: our upgrade tests are very basic and don't catch this issue
<pedronis> zyga: sounds like core project CI should run all the spread tests too, before we break snapd own development (maybe base snaps will claritfy this)
<zyga> pedronis: all from that version, yes
 * zyga runs spread locally to fix some issues
<Chipaca> i'm going to piggyback the log-observe fix on the listing fix
<zyga> Chipaca: I'll merge master into my fix, hopefully this will unbreak everything
<zyga> (when your branch lands)
<Chipaca> here's hoping
<fgimenez> mvo: zyga the crash happened again while executing the suite on a pi2 stable image with core refreshed to beta, this is uboot.env https://dl.dropboxusercontent.com/s/8c4yfyfca5rldza/uboot.env?dl=0, the output of fw_printenv http://paste.ubuntu.com/24586332/ and syslog http://paste.ubuntu.com/24586332/  let me know if you need anything else
<zyga> fgimenez: ! thank you
<zyga> fgimenez: I think the sylong link is incorrect
<zyga> heh
<zyga> incrementing URL by one yields some homework
<fgimenez> zyga: mvo yep sorry, this one http://paste.ubuntu.com/24586341/
<zyga> thanks
<fgimenez> there's also this failure in the execution of tests/main/ubuntu-core-classic http://paste.ubuntu.com/24586382/ it happens before the crash and seems unrelated
<zyga> fgimenez: interesting, that doesn't fail with master (I can load the file)
<zyga> fgimenez: (master uboot-go)
<zyga> fgimenez: I'm checking what the problem might be
<zyga> still, the panic is in parseData as before
<zyga> May 16 08:46:18 localhost snapd[1174]: github.com/snapcore/snapd/vendor/github.com/mvo5/uboot-go/uenv.parseData(0x34e68005, 0x1fffb, 0x3fdfb, 0x5d18aa1)
<zyga> Chipaca: rewrote your branch description a little
<zyga> fgimenez, mvo: this is actually fixed by an earlier commit that we didn't simply use in snapd
<zyga> fgimenez: 69978a3e4b05cca9d7cfee489b3453dfed45e72c fix incorrect handling of \0\0 EOF in a uboot.env fil
<zyga> fgimenez: so simply syncing vendor.json will fix it
<zyga> fgimenez: we should add a periodic task to sync vendor.json on each new dev cycle
<zyga> mvo: ^^
<zyga> (and review the changes)
 * zyga vents mind 
<fgimenez> zyga: sounds very good, i'll prepare a spread-cron branch for it, do you think that proposing a PR to snapcore/snapd should be ok?
<mvo> zyga: yeah
<mvo> zyga: thanks for investigating
<mvo> zyga, fgimenez: we just need to make sure we carefully review those dependency updates, but +1 otherwise
<zyga> fgimenez: yes, I think this is even better as long as we review it carefully each time
<Chipaca> zyga: go go go
<zyga> Chipaca: thanks!
<mup> PR snapd#3327 closed: tests: fix failing tests (snap core version, syslog changes) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3327>
<zyga> Chipaca: 2nd review on https://github.com/snapcore/snapd/pull/3289 will make us have just 20 PRs open :)
<mup> PR snapd#3289: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <https://github.com/snapcore/snapd/pull/3289>
<mup> PR snapd#3321 closed: wrappers: service start/stop were inconsistent <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3321>
<zyga> mvo: can you please do the 2nd review on https://github.com/snapcore/snapd/pull/3326
<mup> PR snapd#3326: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <https://github.com/snapcore/snapd/pull/3326>
<zyga> mvo: this will unbreak edge builds
<zyga> mvo: and once it lands we should try to build another core snap
<mup> PR snapd#3289 closed: daemon: do not allow to install ubuntu-core anymore <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3289>
<NicolinoCuralli> hi guys another question about signing : what ubuntu-image deposits on image of gpg bundle?
<zyga> NicolinoCuralli: what is "gpg bundle"?
<zyga> NicolinoCuralli: ubuntu-image drops assertions into the image
<zyga> NicolinoCuralli: and assertions are signed with various keys
<NicolinoCuralli> zyga: thank, you mean "sudo ubuntu-image -c beta -o pi3-test.img pi3.model" drops assertion pi3.model into the image pi3-test.img
<zyga> NicolinoCuralli: yes, it drops a feed of assertions that snapd imports on first boot
<NicolinoCuralli> zyga: the previous question is preparatory to another about serial-assertion , serial-vault configuration and Store
<NicolinoCuralli> how  store check that serial assertion is signed from the same key which signed model assertion? it seem a feature of brand store
<zyga> NicolinoCuralli: I think this is a pedronis question
<pedronis> NicolinoCuralli: that's not exactly what the store checks,  what the store can check is that the brand store brand matches the authority-id of the serial
<pedronis> and that the serial embedded key is the key of the device
<NicolinoCuralli> how the device key is generated?
<pedronis> at the moment is a software key, but we do plan to support hardware keys at some point
<NicolinoCuralli> is this device key unique for device ?
<pedronis> yes
<pedronis> of course the store also checks that the signature of the serial itself was done with one of the authority-id == brand keys
<Chipaca> looks like we'll be supporting the android bootloader soon \o/
<pedronis> NicolinoCuralli: there are 3 flows involved here,  device registration  that produces the serial,  then exchanging a serial + device key proof with a device session, and then using of the device session
 * zyga lunch
<Chipaca> lunch! what a good idea
 * Chipaca is feeling lazy today though
<NicolinoCuralli> pedronis: is it a good idea open a thread about this on forum ?
<pedronis> NicolinoCuralli: it's all in the code
<NicolinoCuralli> yes, i see but it is more accessible explain the flow with a sequence diagram ( i can make it)
<pedronis> NicolinoCuralli: ah, IÂ misunderstood your question
<NicolinoCuralli> i wiould like open a thread on forum with answer from you about my previous question and describe the process with a sequence diagram
<pedronis> NicolinoCuralli: yes, you can open a forum topic
<NicolinoCuralli> another question: in Serial Vault what is the paramenter for pointing the private part of gpg key
<pedronis> NicolinoCuralli: that's configured  afair
<pedronis> model -> private key
<dragly> Hi. Is there a way to get the real home path of the user inside a snap?
<dragly> File dialogs are currently broken because the Home-button doesn't take the user to the real $HOME directory, but the shadowed one that points to $HOME/snap/appname/version.
<NicolinoCuralli> pedronis: it means here serial-vault:8080/models/keypairs/new?
<ogra_> there is an interface for accessing home, yes
<ogra_> but not sure that influences the default path of the file manager
<pedronis> NicolinoCuralli: yes, somewhere there
<zyga> dragly: hey, not yet
<zyga> dragly: I was thinking about this actually and I'll add something
<zyga> ogra_: it doesn't
<ogra_> yeah, thought so
<zyga> dragly: I think home cannot change back and forth (environment cannot be changed in existing processes)
<zyga> dragly: but we should expose the old value of HOME
<dragly> zyga: Great! In the meantime we will just `export HOME=/home/$USER`
<dragly> or does that break everything? :-)
<zyga> dragly: well, that will break everyrthing
<zyga> dragly: and that will never be the proper fix
<dragly> yes, I figured something was wrong when it ended up exposing all the hidden files in $HOME as well
<dragly> app config files are also loaded non-sandboxed
<zyga> dragly: I think that the long-term proper fix is to use xdg portals
<zyga> dragly: but we can teach specific software, during a transition phase, to load say $SNAP_OLD_HOME
<zyga> dragly: but this is very very specific to special cases
<zyga> dragly: and won't work as a generic solution
<zyga> dragly: for that morphis is looking at portal code
<dragly> zyga: seems like a security issue though. snap developers can give their apps access to hidden files by setting $HOME in their launcher scripts.
<dragly> zyga: yes, seems like Qt, Gtk and alike also would need to use a different env variable for the home button in their dialogs.
<zyga> dragly: no
<zyga> dragly: security is totally not dependant on HOME
<zyga> dragly: for qt and gtk they are already being made to use portals
<pedronis> mvo: hi, would appreciate a review of #3322  , do you some PRs that neeed my review ?
<pedronis> snapd#3322
<mup> PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
<mup> PR core#43 opened: remove generated logs, cleaner lsb-release removal <Created by ogra1> <https://github.com/snapcore/core/pull/43>
<mup> PR snapd#3328 opened: Snapctl outside hooks v2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/3328>
<morphis> mvo, ogra_: do we support cloud-init today on our ubuntu-core iamges?
<mup> PR snapcraft#1311 closed: add missing VCS dependencies to HACKING.md <Created by felicianotech> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1311>
<mup> PR snapcraft#1312 closed: state: fix the name of the source details <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1312>
<ogra_> morphis, kind of (if we dont yet, it is definitely in the works)
<morphis> ogra_: kind of means I can sideload a cloud-script and it gets executed on boot?
<ogra_> morphis, we recently landed a bunch of changes from rharper that are supposed to make clud-init fully work
<ogra_> iirc your gadget needs to ship the initial config ... not sure about sideloading
<morphis> hm
<ogra_> morphis, talk to rharper
<morphis> ogra_: so not possible to put one into the writable partition?
<morphis> rharper: ping :-)
<ogra_> (i assume you could just put it there, after all the gadget does the same ... but i dont know if ubuntu-image does anything additionally)
<mup> PR snapcraft#1309 closed: meta: read and write the desktop file with utf-8 encoding <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1309>
<mup> PR snapcraft#1308 closed: allow capital Y to accept the dev agreement <Created by felicianotech> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1308>
<dragly> zyga: that is strange, because when we override $HOME, we were able to access hidden folders. The only difference was that it was installed with dangerous AFAIK.
<dragly> I can see if I'm able to reproduce it with a minimal example
<pedronis> dragly: it was probably devmode?  (dangerous doesn't control confinement)
<dragly> No, it was strict
<pedronis> weird
<dragly> Haven't tested devmode in weeks
<zyga> dragly: that means that confinement is off
<zyga> dragly: no need to reproduce
<zyga> dragly: --dangerous installs your snap with confinement set to non-enforcing mode
<zyga> dragly: --dangerous implies --devmode AFAIR
 * zyga looks
<zyga> ah, the reverse
<zyga> what does snap info that-snap-name tells you
<dragly> Oh... But how do you test confinement? I can't installinstal local snaps without dangerous because of signing.
<dragly> I'll check when I'm at my machine
<zyga> dragly: I was wrong,
<zyga> dragly: it should be confined
<zyga> --devmode implies --dangerous, not the other way around
<pedronis> yes
<Facu> elopio, sergiusens, may I get feedback on https://forum.snapcraft.io/t/in-progress-snapcraft-2-30/347/13 ? I'm interested into knowing if that work would be relased into 2.30 or not
<Facu> roadmr, â
<mup> PR snapcraft#1304 closed: cleanbuild: set the container language to C.UTF-8 <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1304>
<zyga> mvo: http://paste.ubuntu.com/24586959/
<zyga> mvo: this is the diff if we sync all vendorized bits
<zyga> pedronis: it also includes golang.org/x/crypto
<mup> PR snapd#3292 opened: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292>
<pedronis> zyga: if we are doing this there's a couple we can remove
<pedronis> I think
<zyga> pedronis: yes, I think we can drop a few
<zyga> let me see if govendor helps with this
<zyga> (websocket I think)
<zyga>  vu github.com/gorilla/websocket
<zyga>  vu github.com/testing-cabal/subunit-go
<zyga> we can drop those
<zyga> mvo: do you want a PR that removes those?
<mvo> zyga: yes please
<AdamH_> zyga: Apologies been away from the desktop. If providing those files is still useful let me know and will sort out
<mup> PR snapd#3329 opened: vendor: remove unused pacakges <Created by zyga> <https://github.com/snapcore/snapd/pull/3329>
<zyga> AdamH_: yes, it might be useful though if you don't want to just report a bug about this with enough details
<pedronis> zyga: Chipaca: main change seems we get some assembler opt for sha3 on amd64, hopefully the code is correct
<zyga> pedronis: amd64 or arm64?
<pedronis> amd64
<zyga> pedronis: ok, if you want I can propose a isolated patch for that
<pedronis> ?
<zyga> pedronis: for that part of vendor.json
<rharper> morphis: here, what's up ?
<pedronis> zyga: that change is from Dec 2016, so it's been out a bit
<pedronis> as you prefer
<mvo> fgimenez: what revision is the pi2 gadget snap of the failing image?
<fgimenez> mvo: let me check 1sec
<pedronis> even earlier actually
<fgimenez> mvo: in pi3 it is rev6 http://paste.ubuntu.com/24587045/ i'm currently using the pi2 for double checking 2.25, i can reflash it later with 2.26 if needed
<mvo> fgimenez: is the https://dl.dropboxusercontent.com/s/8c4yfyfca5rldza/uboot.env?dl=0, from the pi2 or the pi3?
<mvo> fgimenez: pardon my ignorance here
<rharper> morphis: reading backscroll,  there are a few things to be resolved before it's all blessed;  Testing the edge image last week, ran into this issue https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1689944, will need to get that fixed in cloud-init or workaround it by creating one of the two files/dirs checked already by cloud-init;  Next is for now, when building images, snap prepare will disable cloud-init unless
<rharper> you provide a config in the gadget;  I've a branch which would remove that given that current cloud-init won't automatically run anymore unless you provide it configuration;  (https://github.com/raharper/snapd/commit/3e83b3aa281f02bce9a230a812ad4f02d0d66c22) ;  both can be worked around with some massaging of the image in the short term;  I'm happy to help out there;  After that, it's a matter of supplying cloud-config via
<mup> Bug #1689944: util.system_is_snappy needs additional checks <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1689944>
<rharper> a ConfigDrive or some other DataSource that cloud-init understands (http://cloudinit.readthedocs.io/en/latest/topics/datasources.html)
<fgimenez> mvo: pi2, it is the last one that failed
<mvo> fgimenez: thank you, then lets wait for the results of pi2 with 2.25
<mvo> fgimenez: still a bit of a mystery :)
 * pedronis break
<fgimenez> mvo: yep :) let's see, will let you know how it goes
<Chipaca> rharper: when you say "cloud-init won't automatically run anymore unless you provide it configuration", does that really mean it doesn't run, or does that mean it starts up, sees it has no configuration, and exits?
<rharper> at systemd-generator time it checks for known cloud signatures and files which indicate there is data to consume;  this is non-python code which determins if we actually invoke /usr/bin/cloud-init later on in start-up
<rharper> this avoids invoking the python binary and library load unless you actually need to (ie, you have cloud configuration or user-data you want to apply)
<Chipaca> excellent
<morphis> rharper: ok, good to know, was using an image build from stable and did remove the flag prepare-image put in to disable cloud-init
<rharper> stable requires more work
<rharper> as it does not yet have an updated cloud-init
<zyga> spread is sad
<zyga> travis is sad
<zyga> are we using all test slots?
 * Chipaca hugs zyga 
<Chipaca> don't you be sad as well
<zyga> I see just two yellow boxes on PRs
<zyga> but travis is not starting
<mup> PR snapd#3330 opened: fail if unused dependencies are found <Created by mvo5> <https://github.com/snapcore/snapd/pull/3330>
<morphis> rharper: I see, but with edge I should get a cloud-config I supply with ubuntu-image working?
<mup> PR snapcraft#1319 opened: kernel plugin: config check: remove DMIID option <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1319>
<verterok> Hi, getting a weird (*new*) error while installing prometheus snap (using juju charm)
<verterok> basically the promtool binary is failing with: cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
<verterok> it gets "fixed" after rebooting the instance/machine
<zyga> verterok: hey
<verterok> zyga: hola!
<zyga> verterok: can you tell me more about your system, what does 'snap version' say?
<verterok> zyga: Chipaca told me you would be interested in that ^ :)
<zyga> verterok: hola :)
<verterok> zyga: it's trusty, let me get the version
<zyga> aha
<zyga> using 14.04 kernel/
<zyga> or LTS enablement kernel?
<verterok> zyga: http://paste.ubuntu.com/24587234/
<zyga> I see
<zyga> well that is interesting
<zyga> can you get me dmesg | grep DENIED
<verterok> zyga: this is prodstack4.5
<zyga> and is that the latest kernel you can get (from the 4.4 series)
<zyga> I want to eliminate known issues that may be lurking
<verterok> zyga: it's a freshly booted instance, let me apt update and see what is available
<zyga> verterok: please!
<zyga> verterok: and if you can also check dmesg
<zyga> verterok: I think it is most interesting here
<verterok> zyga: http://paste.ubuntu.com/24587246/
<zyga> verterok: and if you see a kernel upgrade available, take it and reboot
<verterok> dmesg ^
<verterok> zyga: it worked after rebooting
<zyga> oh
<zyga> [   16.794142] audit: type=1400 audit(1494943609.127:13): apparmor="DENIED" operation="change_onexec" info="label not found" error=-2 profile="unconfined" name="snap.prometheus.prometheus" pid=1020 comm="snap-confine"
<zyga> does prometheus (I don't know what it is) tries to run other snap commands?
<Chipaca> zyga: the son of iapetus
<zyga> Chipaca: well that fixes it ;)
<Chipaca> also of clymene
<Chipaca> got his liver eaten by a vulture
<verterok> zyga: prometheus is a timeseries DB + scrapper to collect metrics
<zyga> verterok: ok, is it a strictly confined snap?
<verterok> zyga: no idea, how can I check?
<zyga> verterok: snap list | grep prometheus
<ogra_> Chipaca, with apples and onions ?
<verterok> zyga: snap list | grep prometheus
<verterok> prometheus  1.5.2    11    jacek      -
<zyga> ok
<Chipaca> ogra_: also the guy that stole fire from olympus and gave it to mankind
<zyga> verterok: so this seems to be a strictly confined snap
<ogra_> yeah
<rharper> morphis: not yet, we need to fix the cloud-init bug I mentioned earlier ;  ogra_ do you know when or why the /etc/system-image/config.d directory got removed?  looking at the previous core snaps it had been present but empty;  was it just pruned?
 * Chipaca shuts up about the greeks
<zyga> verterok: but it seems to want to run apps from other snaps
<ogra_> heh
<zyga> verterok: do you have any idea why?
<Chipaca> zyga: âsnap list <snap name>â works :-)
<zyga> Chipaca: oh, thanks
<Chipaca> zyga: âsnap list [snap...]
<Chipaca> â
<verterok> zyga: it's failing to run an utility command provided by the prometheus snap itself
<ogra_> rharper, well, we havent used system-image since 15.04 ...
<ogra_> so that dir is a dead thing since quite a while
<zyga> verterok: looks like a bug in the snap
<verterok> zyga: worth noting it was working last week (I made a couple deploys of it)
<ogra_> writable-paths will soon move one level up and it will be gone completely
<zyga> verterok: that utility should be invoked using internal name
<zyga> verterok: not using the name exposed to the outside world
<nacc> Chipaca: i am looking at the new completion functionality. If I use python3-argcomplete, is there a trivial way to hook into it? Do I basically take what python3-argcomplete's global enable and make that may app's completer? Note that I have to have two completers, actually, because 'git-ubuntu' and 'git ubuntu' go through different executables. Is that supported?
<verterok> zyga: the juju charm fails while trying to tun: /snap/bin/prometheus.promtool version
<Chipaca> nacc: there's no support for aliases yet
<zyga> verterok: too many facts, I don't know all those snaps
<ogra_> rharper, do you mean between two stable versions ? i think /etc/system-image/config.d is gone since a lot longer already
<zyga> verterok: snaps cannot run commands from other snaps
<verterok> zyga: no idea what promtool is doing, but I think it's just a compiled go thing, no way to look inside easily
<zyga> verterok: or even from their own snap
<zyga> verterok: nothing from /snap/bin
<nacc> Chipaca: aliases in what sense? you mean that `git-ubuntu` and `git ubuntu` both work?
<Chipaca> nacc: but other than that, the completer is just the snippet you'd drop in /usr/share/bash-completion/completions
<nacc> Chipaca: that's default git behavior
<zyga> verterok: they can only run stuff they find locally (e.g. via $SNAP/bin/stuff)
<rharper> ogra_: interesting, so maybe it was always gone in edge for quite some time then ?
<ogra_> yeah
<zyga> verterok: default PATH should make that happen
<rharper> I had typically built with stable or beta
<Chipaca> nacc: sorry, maybe i misunderstood
<ogra_> did you use it for anything ?
<zyga> verterok: that is, for snap application /snap is not on path
<nacc> Chipaca: i already have (in my snap) `git-ubuntu` and `git ubuntu`.
<rharper> cloud-init used to determine if the system was ubuntu-core or not
<morphis> rharper: does cloud-init touch /etc/netplan?
<Chipaca> nacc: are you snapping "git-ubuntu"?
<ogra_> rharper, uuuh
<rharper> morphis: cloud-init support rendering netplan
<zyga> verterok: I'm wondering  why it sometimes "works" for you
<morphis> rharper: more concrete, /etc/netplan/00-snapd-config.yaml?
<zyga> verterok: can you tell me more about it
<nacc> Chipaca: yeah, and both commands become available via the same snap
<nacc> Chipaca: becuase of how `git` itself works (in a classic world where git is already installed, say)
<Chipaca> nacc: right, but not via an alias but because git does that magic?
<nacc> Chipaca: yeah
<verterok> zyga: not sometimes, let me explain :)
<Chipaca> nacc: and how does git plug into completion of its subcommands?
<rharper> morphis: , yes, http://cloudinit.readthedocs.io/en/latest/topics/network-config-format-v2.html
<verterok> zyga: I'm using juju to deploy a prometheus "service" juju deploy cs:~prometheus-charmers/prometheus
<nacc> Chipaca: right, it looks for me to add a shell snippet that defines _git_ubuntu into the .bashrc (or i think it if was in the completion directory that would work too)
<verterok> zyga: that boot a openstack instance (trusty)
<morphis> rharper: I enabled cloud-init in my image build with edge now and get an error in console-conf that the netplan file is invalid
<nacc> Chipaca: but `git-ubuntu`'s completion is different
<rharper> ogra_: at the time we added support it was the 15.04 image, (a/b partitions), then the new snaps came and os-release still had Xenial information;
<nacc> Chipaca: so can i hve two completers for the same 'app'?
<verterok> zyga: and run the prometheus charm, all that is classic stuff apt based
<morphis> rharper: ala "set-name requires match properties"
<ogra_> rharper, yeah, for 15.04 that was okayish ..
<verterok> zyga: then it install the prometheus snap
<morphis> rharper:  but could be console-conf too
<verterok> zyga: and tries to use it, which is when it fails
<rharper> morphis: that's a known issue with console-conf and cloud-init;  cloud-init recognizes the baked in snap config, and should remove it;  I've not yet determined why it failed to remove it, so you'll find two files in /etc/netplan/
<verterok> zyga: if I reboot the instance/machine, it works ok after
<rharper> the 00-snapd one, as well as one that cloud-init rendered
<morphis> rharper: ah I see
<verterok> zyga: but until the instance is reboot, it keeps failing
<zyga> verterok: wait, what is "it" in the sentence: < verterok> zyga: and tries to use it, which is when it fails
<Chipaca> nacc: to answer your last question, no
<verterok> zyga: the charm, think of it as a set of scripts to setup a service in a machine/instance
<nacc> Chipaca: ok :( I guess I could write one that sources my two? :)
<zyga> verterok: is any of this running inside containers?
<verterok> zyga: nope
<verterok> zyga: is all running in "real" VMs
<Chipaca> nacc: there is no way to define _git_ubuntu in the user's shell from inside the snap
<Chipaca> nacc: so that is not going to work, even if you did it
<zyga> verterok: hmm hmm hmm
<rharper> ogra_: I've a bug against cloud-init to add additional methods to detect cloud-init is on ubuntu-core (https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1689944) ;
<mup> Bug #1689944: util.system_is_snappy needs additional checks <cloud-init (Ubuntu):New> <https://launchpad.net/bugs/1689944>
<fgimenez> mvo: it looks that https://github.com/snapcore/snapd/commit/08f60b88c28416dc627308b619b6ffdbbb2cd593 somehow made it to the release/2.25 branch and is making tests/main/snap-connect fail (no --last option in 2.25's snap tasks), other than that the tests on pi2 are good so far (28/115)
<zyga> verterok: I need to play with this more, can you tell me how to reproduce this? I have 14.04 around
<zyga> verterok: just a few basic commands, maybe just the snap part
<zyga> verterok: the charm/juju side feels like not a factor
<verterok> zyga: indeed
<verterok> zyga: let me extract the commands run by the charm
<rharper> ogra_: would it be terrible in the core-build config to re-create the config.d dir (would something eles break if it were present but empty) ?
<Chipaca> nacc: OTOH, git-ubuntu is a classic snap, so it can do anything
<ogra_> rharper, it would be very ugly
<nacc> Chipaca: in classic there is, just not automatically
<rharper> ogra_: ok
<nacc> Chipaca: right :)
<ogra_> rharper, it shouldnt have been used in the first place really ... use os-release ... thats reliable ... or if you need the info earlier, use the cmdline
<Chipaca> nacc: if it's going to remain classic, I don't think the confined completion support really buys you anything
<rharper> ogra_: the os-release at the time it was added didn't yet differ from Xenial
<zyga> verterok: thanks!
<Chipaca> nacc: and it can do things automaticall by, for example, dropping a file in /usr/share/bash-completion/completions from the configure script
<ogra_> rharper, yes, but that was fixed :)
<ogra_> (actually in 15.04 already IIRC)
<nacc> Chipaca: are there explicit post-install steps? Or do you mean, I can just organize my snap to write there?
<Chipaca> nacc: (note we don't yet have an "uninstall" hook, so make it resilient to your snap not being there...)
<ogra_> /etc/os-release is definitely not dropping the ID=ubuntu-core
<NicolinoCuralli> pedronis:  i have some problem to understand where SerialVualt take the authority-id for build the serial assertion for a device
<rharper> ogra_: ok;  I'd appreciate a comment on that cloud-init bug w.r.t which you feel are the most stable moving forward, and we'll fix up the detection and likely include as many that are stable
 * rharper eyes another cloud-init sru to xenial 
<Chipaca> nacc: post-install steps, no. There's a configure hook.
<Chipaca> nacc: which is called on install
<nacc> Chipaca: ah i see it now
<nacc> Chipaca: sorry, wasn't there before (when i was using snaps earlier, i mean). Will read.
<Chipaca> nacc: https://github.com/snapcore/snapd/wiki/hooks#configure
<nacc> Chipaca: thanks!
<Chipaca> nacc: and AIUI there will be more hooks, better suited for what you want, but I might be wrong (haven't been paying attention), and no idea what timeframe
<verterok> zyga: it's basically this: http://paste.ubuntu.com/24587337/
<verterok> zyga: let me try to repro manually
<zyga> verterok: Thank you
<zyga> booting 14.04 now
<zyga> verterok: I have a theory but let me try it first :)
<pedronis> NicolinoCuralli: in which sense?  it's the brand-id in the serial-request
<pedronis> that comes from the model assertion of the device
<NicolinoCuralli> pedronis: brand-id is always equal to authority-id? what is the sense of duplicate use on serial assertion response?
<pedronis> NicolinoCuralli: all assertions have an authority-id (the authority emitting them, and right now also the signer)
<verterok> zyga: damn, I can't reproduce it manually (without juju and the charm) :(
<verterok> jacekn: ^ FYI
<nacc> Chipaca: thanks!
<morphis> Pharaoh_Atem: did my log help you to update the snap-mgmt script?
<zyga> verterok: aha,
 * zyga found the charger for his VM host laptop
<pedronis> NicolinoCuralli: we decided it was more consistent to repeat the info (than to have different fields for that per assertion in some cases)
<zyga> verterok: hmm hmm
<zyga> verterok: I can install a server image and do more if that helps
<Pharaoh_Atem> morphis: yeah, I'm going to prepare the 2.26.1 update during my lunch hour with the changes
<morphis> Pharaoh_Atem: nice!
<pedronis> NicolinoCuralli: also we are planning to support some cases where authority-id != brand-id (though atm they must be == )  for serial
<zyga> verterok: but please give me instructions on how to reproduce
<verterok> zyga: thanks, these are the full logs of my manual test: http://paste.ubuntu.com/24587397/
<ogra_> mvo, lloking at our images ... there is still init=/lib/systemd/systemd --- shouldnt we be able to finally drop that ?
<zyga> verterok: after installing manually you can add /snap/bin to path manually
<zyga> verterok: ah but this then works OK
<zyga> hmm hmm
<verterok> zyga: yup, now trying to reproduce with juju and charm. doing a capture of the full logs (at least what the charm logs)
<zyga> verterok: thank you!
<ogra_> mvo, testing with it dropped seems to work fine ...
<zyga> mvo: merged and iterating
<zyga> mvo: but edge should no longer be broken (just need a build)
<mup> PR snapd#3326 closed: cmd,interfaces/mount: run snap-update-ns and snap-discard-ns from core if possible <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3326>
<verterok> zyga: ok, I'm not crazy...it seems :) reproduced, collecting full logs now
<zyga> verterok: good!
<ogra_> mvo, oh ! ... seems i spoke to early
<mvo> zyga: thanks for unbreaking master. will you do a followup to 3326 with the review comments?
<ogra_> ogra@pi3:~$ snap list
<ogra_> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<ogra_> wow
<mvo> ogra_: yeah, its still 16.04 so init itself is still upstart
 * zyga goes to build core again
<dragly> zyga and pedronis: I am unable to reproduce the case where I had access to hidden files in $HOME now.
<zyga> dragly: good :)
<zyga> dragly: though it might be better if we did
<dragly> We were trying out --classic earlier, so it might just have been because of that.
<dragly> That we somehow had a version with --classic installed while testing.
<NicolinoCuralli> pedronis : a question: on SerialVault i can upload a different gpg bundle different from Store?
<pedronis> NicolinoCuralli: in which sense?
<pedronis> the store needs to check the signature of serials, so any key used to sign serials need to be registered with the store
<NicolinoCuralli> pedronis: it means the i need to upload one of the key uploaded to Brand store?
<pedronis> one of the keys registered (In snapcraft register-key) sense, yes
<NicolinoCuralli> i mean upload a Brand Store key to Serial Vault by Admin UI?
<pedronis> a brand key, registered with the store, yes
<pedronis> (public) keys are not per store
<NicolinoCuralli> pedronis : i mean one of gpg key registrered on the Brand Store
<pedronis> NicolinoCuralli: we are probably talking about the same thing, but keys are registered with the store, not a specific substore
<NicolinoCuralli> pedronis: ok we are talking about the same thing
<zyga> Chipaca, verterok: so FYI, this issue is caused by running on top of 3.13 before a reboot applies a new kernel
<verterok> jacekn: ^  this will surely affect new deploys using trusty. xenial is cool
<zyga> mvo: we need to do something smarter in snapd/snap; I'd suggest that we bail out if on Ubuntu 14.04 and we're not on a 4.x kernel
<zyga> with a simple message
<zyga> this would be unique to "snap run"
<zyga> which should catch "my snaps don't work at all"
<zyga> but I worry about installing and running hooks
<zyga> perhaps snapd should also refuse to do anything
<zyga> (which may mean it cannot update itself either)
<zyga> actually, it should not do anything at all (snapd)
<Chipaca> zyga: what is 3.13?
<zyga> mvo: ^^ I'll open a forum thread about this
<zyga> Chipaca: 3.13 kernel that 14.04 systems start with
<zyga> Chipaca: they only pull the LTS enablement kernel by installing snapd
<Chipaca> zyga: uh, so the "snap version" verterok posted was post-reboot?
<zyga> yes
<zyga> we got to the bottom of this in a private chat where we exchanged more logs
<Chipaca> verterok: so, yeah, installing a new kernel requires a reboot Â¯\_(ã)_/Â¯ :-)
<zyga> (we didn't want to leak any magic passwords or anything by accident)
<zyga> Chipaca: sure but snapd packaging make this unobviou
<Chipaca> zyga: that's fine
<zyga> Chipaca: and the effects will worsen with time
<verterok> Chipaca: I live in a world of ksplice and livepatch...never reboot! ;-)
<Chipaca> zyga: anything that gives me a reason to make fun of verterok is good
<Chipaca> zyga: (those chances are rare)
<ogra_> verterok, until the next systemd update indeed :P
<ogra_> (or upstart in case of 14.04)
<Chipaca> verterok: well, if it were something newer than 14.04, you could've kexec'ed :-p
<verterok> Chipaca: the problem is not snapd, but the charm that tries to use it right away and allow deploying on trusty :)
<Chipaca> 14.04, or as we called it back then, MCD.IV
<zyga> hmm launchpad times out for me...
<Chipaca> + su -c 'SNAPPY_USE_STAGING_STORE=0 snap prepare-image --channel edge --extra-snaps snapweb /tmp/root/model.assertion /tmp/root' test
<Chipaca> error: Please buy pi2 before installing it.
<Chipaca> I thought we'd gotten rid of the bug where it thinks it needs to buy something?
<verterok> zyga: something changed recently? this same deploy worked last week
<zyga> verterok: no
<zyga> verterok: well
<zyga> verterok: maybe
<verterok> maybe a bug fix? :)
<zyga> verterok: but "work" is exaggerated
<zyga> verterok: it's just it was never ever intended to work :-)
<verterok> zyga: quite probably :)
<zyga> verterok: as 3.13 is definitely too old to have working apparmor
<verterok> so, we "just" need a could image with 4.x cooked in
<zyga> verterok: for snaps, definitely
<zyga> verterok: in fact, this is some feedback for clould team
<zyga> verterok: for those that want 14.04 and snaps they need to start producing an image that works ootb
<zyga> verterok: (good kernel at least, but maybe snapd preinstalled too)
<morphis> mvo, niemeyer: shouldn't https://forum.snapcraft.io/t/in-progress-snapd-2-25/414 be marked as done?
<morphis> mvo, niemeyer: or does the "In progress" just confuse me?
<morphis> ah 2.25 isn't yet in stable
<rharper> ogra_: thanks for the comments
<ogra_> np
<pedronis> Chipaca: no, discussion was that it needs to be fixed on the store side
<zyga> pstolowski: feedback on 3328
<mvo> morphis: correct, not quite in stable yet
<pstolowski> zyga, thanks
<morphis> mvo: just got a bit confused by the forum, sorry for the noise :-)
<mvo> morphis: no worries
<zyga> pstolowski: tomorrow I'll find my work on regexp-free validation
<pstolowski> zyga, great, thanks!
<mup> PR snapd#3325 closed: vendor,partition: fix panics from uenv <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3325>
<zyga> mvo: +1 to merge coverage report?
<zyga> mvo: I'd love to see it
<mvo> zyga: +1
<mup> PR snapd#3313 closed: send things to codecov.io <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3313>
<zyga> mvo: do you have the time to voice your preference on https://github.com/snapcore/snapd/pull/3308
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<mvo> zyga: sorry :( looking now
<mvo> zyga: after I uploaded 2.26.2
<mup> PR snapd#3331 opened: tests: remove unit tests task <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3331>
<zyga> mvo: thank you for getting 2.26.2 out
 * zyga hugs mvo
<zyga> mvo: is 2.26.2 a .1 + cherry pick or master snapshot?
<zyga> mvo: I want to build snapd master and rebuild the core snap but I don't want to mess up your work
 * zyga wonders if this abbreviates to "I should EOD"
<Chipaca> zyga: you could review snapd#3292 if not
<mup> PR snapd#3292: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <https://github.com/snapcore/snapd/pull/3292>
<Chipaca> also could use one other review
<Chipaca> so feel free, other reviewers :-)
<zyga> or that :)
 * zyga does that now
<fgimenez> mvo: no crashes on the 2.25 execution http://paste.ubuntu.com/24587949/ the ubuntu-core-classic error also happened on 2.26.1, maybe something has changed in the classic snap
<pedronis> mvo: somebody was mentioning problems with classic snap the other day
<pedronis> mvo: <AdamH_> Any body else get the following when trying to install classic snap? Failed to fetch http://ports.ubuntu.com/ubuntu-ports/dists/xenial/InRelease  Could not resolve 'ports.ubuntu.com'
<Chipaca> imma gonna eod
<zyga> Chipaca: hey
<zyga> Chipaca: have a look
<zyga> I think there's a bug in your PR
<zyga> pedronis: it's a bug that people mention
<zyga> pedronis: but I don't know the cause yet
<zyga> pedronis: do you see any errors in journalctl?
<pedronis> zyga: where?
<zyga> pedronis: maybe we got hit by something like DNSSEC?
<zyga> pedronis: just run journalctl -f while this rusn
<pedronis> that's not me reporting that
<zyga> *run
<pedronis> it's a user
<zyga> pedronis: aaah
 * zyga misread that
<zyga> sorry ;)
<pedronis> well I misread  "a clasisic snap" vs "the classic snap" when he reported it
<pedronis> so fun
<mup> PR snapd#3329 closed: vendor: remove unused packages <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3329>
<pedronis> zyga: mvo: fun, just disovered timeutil.Next takes 1s+  when last is 0
<pedronis> because we have unittest now trying to schedule/running refreshes :/
<mup> PR snapd#3332 opened: interfaces/seccomp: document Backend.NewSpecification <Created by zyga> <https://github.com/snapcore/snapd/pull/3332>
<mup> PR snapd#3333 opened: vendor: refresh everything <Created by zyga> <https://github.com/snapcore/snapd/pull/3333>
<Chipaca> zyga: responded (with code!)
<Chipaca> zyga: basically, you're wrong, neener neener neener
<kenvandine> Issues while validating snapcraft.yaml: snapcraft validation file is missing from installation path
<kenvandine> snapcraft validation file is missing from installation path
<kenvandine> anyone know how to fix that?
<kenvandine> i can't build anything anymore
<kyrofa> kenvandine, are you running from source?
<kenvandine> kyrofa, no
<kenvandine> i'm on artful
<kenvandine> using the package
<kenvandine> it was fine a few minutes ago...
<kenvandine> made a little change to my snapcraft.yaml and hit this
<kenvandine> now i can't build anything
<mvo> pedronis: meh :/ not cool. thanks for finding this!
<pedronis> mvo: it seems we haven't really decided explicitly what to do when last-refresh is 0
<zyga> Chipaca: I'm glad to be shown wrong, thanks :)
<kenvandine> kyrofa, any insight?
<kyrofa> kenvandine, it should be looking in /usr/share/snapcraft/schema . Do you see anything in there?
<kenvandine> yes
<mvo> pedronis: indeed
<kyrofa> kenvandine, try running with `-d` to turn on debugging mode. You'll see where that exception is thrown. Do you see what file it's trying to open?
 * zyga really EODs
<zyga> take care!
<kenvandine> FileNotFoundError: [Errno 2] No such file or directory: '/snap/gedit/x16/share/snapcraft/schema/snapcraft.yaml'
<kenvandine> it thinks it should still be installed
<cachio> niemeyer, hey, here I have some results using the xunit branch https://platform-qa-jenkins.ubuntu.com/view/snapd/job/snapd-spread-full-execution/lastCompletedBuild/testReport/
<kenvandine> oh
<kenvandine> geez
 * kenvandine is in a snap run --shell :)
<kenvandine> sigh
<kenvandine> kyrofa, thx!
<kyrofa> kenvandine, hahahahahahaha
<cachio> niemeyer, of spread to run the snapd test suite on jenkins
<kyrofa> kenvandine, I NEVER would have guessed that
<mup> PR snapd#3334 opened: Release snapd 2.26.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3334>
<mup> PR snapd#3330 closed: fail if unused dependencies are found <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3330>
<mup> PR snapd#3323 closed: overlord/snapstate: avoid creating command aliases for daemons  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3323>
<pedronis> mvo:Â is there some problem with autopkgtests? except off ppc64el they seem to be running forever
<kyrofa> noise][1, I'm getting 504's when trying to view stats in dashboard.snapcraft.io
<noise][1> kyrofa: which snap?
<kyrofa> noise][1, nextcloud
<noise][1> i know we have perf. issues there still w/snaps with a lot of revisions
<noise][1> but i'll take a look
<kyrofa> noise][1, slow is okay. Perhaps timeouts simply need to be upped a bit
<kyrofa> And indeed, I can see stats on other snaps
<mup> Bug #1689301 changed: Can't set program_usb_boot_mode pi-config option <Snappy:New> <https://launchpad.net/bugs/1689301>
<mup> PR snapd#3335 opened: daemon: teach the daemon to wait on active connections when shutting down <Created by pedronis> <https://github.com/snapcore/snapd/pull/3335>
<pedronis> mvo https://forum.snapcraft.io/t/snapd-2-26-fails-to-start-in-lxd/651
<kyrofa> Now I'm getting proxy errors when trying to upload snaps. And status.snapcraft.io is all green
<kyrofa> Gotta be honest... I largely don't even look there anymore
<kyrofa> pedronis, is there currently a way for brand stores to be restricted to specific models?
<pedronis> kyrofa: yes, you need to ask for that to be turned on
<pedronis> and those models will need proper serials
<kyrofa> pedronis, a store-side assertion, then? How is it associated with the model in question?
<pedronis> kyrofa: not a store side assertion, store config that you need to ask for
<kyrofa> pedronis, ah, okay. How does that work? What information do they need?
<pedronis> kyrofa: store, brand,  model names as specified in the model assertions for those
<kyrofa> pedronis, alright, thank you :)
<jorian> Hello, I was wondering if snappy sounds like the right tool for this job.  I am trying to build some code that requires the boost library at a newer version than what is available in my distro's repository.  Since this code requires many libraries, it occurred to me that maybe it might be easier to build a snap with just the newer library and then build the full app normally.  Is it possible to have a snap
<jorian> that just exposes a library?  Or does it need to expose a binary? (like in the example's hello)
<nacc> jorian: snaps are confined and aren't (by default) visible to each other (there is some feature work here that maybe i'm not fully aware of)
<nacc> jorian: a libary is more like a 'part' in snap parlance than an app
<jorian> that was kind of the vibe i got
<jorian> thanks for clarifying
<nacc> jorian: snaps are more designed around packaging the application
#snappy 2017-05-17
<kyrofa> jorian, snap would be a good option for packaging your app _together_ with the newer lib
<diddledan> if anyone is familiar with locales in combo with snaps, is the folder usr/lib/locale important for an app, or can I omit it (presumably by not installing locales-all in stage-packages)?
<diddledan> it's 117MB is all so it's bloating my snap to rather large proportions
<diddledan> (117MB uncompressed)
<nacc> kyrofa: good point, sorry I didn't say that more explicitly
<mup> PR snapd#3334 closed: Release snapd 2.26.2 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3334>
<mup> PR snapd#3336 opened: Reease snapd 2.26.2 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3336>
<mup> PR snapd#3292 closed: wrappers: make StartSnapServices cleanup any services that were added if a later one fails <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3292>
<mup> PR snapcraft#1320 opened: store: send X-Ubuntu-Series, not X-Ubuntu-Release <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1320>
<mup> PR snapd#3337 opened: errtracker: try multiple paths to read machine-id <Created by morphis> <https://github.com/snapcore/snapd/pull/3337>
<morphis> mvo: ^^
<mvo> morphis: cool, thank you
<mvo> morphis: is there a leftover debug fmt.Prinln in there ;) ?
<morphis> mvo: yeah, could be :-)
<mvo> morphis: looks great otherwise, I will do a formal review in a bit, just fixing the image, shadow is out-of-sync with the archive
<morphis> mvo: oh wonderful, that just happened recently
<morphis> mvo: dropped the Println
<zyga> good morning
<zyga> mvo: hey, I'd like to trigger a build of the ppa that feeds edge, I'm looking at https://launchpad.net/~snappy-dev but I see quite a few archives there, can you give me a hand plese?
<zyga> mvo: perhaps we could close some archives (I suspect we don't need all of them at once)
<zyga> CC ogra_ ^^
<mvo> zyga: sure, let me check
 * zyga goes to garden PRs in the meantime
<zyga> thank you :)
<mvo> zyga: https://launchpad.net/~snappy-dev/+snap/core is what need if you want to trigger a new build
<mvo> zyga: please check that shadow build in the ppa:snappy-dev/image, would be good to have that fix in the iamge too
<zyga> mvo: I know the snap recipe, I was just struggling with the PPA part
<mvo> zyga: aha, ok
<zyga> mvo: thank you!
<mvo> zyga: ppa:snappy-dev/image is the relevant one
<mvo> zyga: I will trigger a new build now unless you want something else in there too?
<zyga> mvo: I'll talk to ogra about closing the remaining archives, they feel like just noise
<zyga> mvo: no, everyting is ready since yesterday
<zyga> mvo: please go ahead
<zyga> everything*
<mvo> zyga: I deleted some obvious ones, some are 15.04, if we are really sure we don't need 15.04 anymore for the previous snappy incarnation then those can go
<zyga> mvo: though when I refreshed core today (from edge) I got 2.26.2
<zyga> mvo: what about this one? https://launchpad.net/~snappy-dev/+archive/ubuntu/edge2
<zyga> or https://launchpad.net/~snappy-dev/+archive/ubuntu/beta ?
<mvo> zyga: checking
<mvo> zyga: I guess beta is fine to remove, the risk is always that if you delete a ppa you screw all the people who still have it in their sources.list
<mvo> zyga: but given that the latest archive in there that is still supported is trusty the risk is relatively low
<mvo> zyga: I will delete edge2 after this core build
<zyga> mvo: there is something wrong in the image
<zyga> https://travis-ci.org/snapcore/snapd/builds/233106199#L3814
<zyga> mvo: this is the 2.26.2 merge back to master
<zyga> we lack --extrausers
<zyga> it seems like the archive package has higher version number
<mvo> zyga: yes, the core build that is currently in process will fix it
<zyga> and we're not getting the patched one
<zyga> ah, perfect, thank you for handling this :)
<morphis> zyga: thanks for pushing to my PR but I will squash that change if you're ok
<morphis> was about to push the same
<zyga> morphis: no worries, do it
<zyga> morphis: I'd squash myself if I knew you wanted it :)
<morphis> :-)
<fgimenez> hi mvo: i've started with 2.26.2 validation, tests/main/listing and tests/main/interefaces-log-observe are failing on i386 (the first one that finished) this is expected (it seems that https://github.com/snapcore/snapd/pull/3327 is missong in the release branch), right?
<mup> PR snapd#3327: tests: fix failing tests (snap core version, syslog changes) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3327>
<mvo> fgimenez: meh, the listing test! we may need to backport that fix to 2.26 too
<mvo> fgimenez: interfaces-log-observe is  unexpected
<mvo> fgimenez: tests/main/listing will also fail in autopkgtest so we also need a new SRU :/
<fgimenez> mvo: i think interfaces-log-observe is fixed in the same branch, will check in the upgrade-from-stable scenario
<morphis> zyga: so moment of truth, running the entire main suite again for fedora, we should now close to 100%
<morphis> or better said close to 100% of those tests which apply to Fedora (disabled those which test re-execution or classic confinement which we don't support on Fedora yet)
<mup> PR snapd#3338 opened: tests/main/completion: source from /usr/share/bash-completion <Created by morphis> <https://github.com/snapcore/snapd/pull/3338>
<zyga> morphis: I'm very happy to see that :)
<morphis> :-)
<morphis> zyga: when you're leaving for the suse conference?
<zyga> next week
<zyga> 25th
<morphis> ok
<pedronis> mvo: why interfaces-log-observe is unexpected? did you build also with an older revision of core stuff
<mvo> pedronis: well, maybe it is not, I have not checked the log what exactly is failing. if it has a similar regex as the listing test then it is not unexpected
 * zyga hugs mvo - the SRU dancer
<mvo> pedronis: I will check as soon as I'm finished with the current code review
<pedronis> mvo: well we turned off rsyslog
<zyga> yep, that was bundled into chipaca's branch
<pedronis> at least that's why we had interfaces-log-observe issues on the mainline
<mvo> pedronis: aha, I must have missed that, thank you. that will also need to be ported then
<pedronis> mvo: here is the discussion https://forum.snapcraft.io/t/change-in-logging-behaviour-on-ubuntu-core/591/4  jdstrand still thinks it's bad backward compatibility wise
<mvo> pedronis: fwiw, I agree with that
<mvo> pedronis: if it changed from 2.26 to 2.26.3 that would also be very bad
<mvo> pedronis: thanks for raising it, I will look, it definitely needs to go into the release notes if it goes into 2.26
<mvo> pedronis: I will follow up in the forum, I think if nothing else we should create some hint for people looking at /var/log/syslog that they now need to use journalctl
<morphis> zyga: you already had time to look into the bind problem? this really prevents configure hook execution on !ubuntu for all !core snaps
<zyga> mvo: can you override merge https://github.com/snapcore/snapd/pull/3332 so that we don't waste resources on re-testing it
<mup> PR snapd#3332: interfaces/seccomp: document Backend.NewSpecification <Created by zyga> <https://github.com/snapcore/snapd/pull/3332>
<zyga> pstolowski: hey
<pstolowski> zyga, hey!
<zyga> pstolowski: question about https://github.com/snapcore/snapd/pull/3328 - how would you feel starting afresh; take that branch, squash the history so that it makes more sense
<mup> PR snapd#3328: many: snapctl outside hooks v2 <Created by stolowski> <https://github.com/snapcore/snapd/pull/3328>
<morphis> zyga: 87% pass rate, is what I have now
<zyga> pstolowski: I will work with you on the regexp code elimination today
<pstolowski> zyga, np, i can do that if it helps
<mvo> morphis: nice job
<zyga> pstolowski: as you think but I would recommend it, it's a "new" PR and the history is full of stuff that makes it harder to follow
<mup> PR snapd#3332 closed: interfaces/seccomp: document Backend.NewSpecification <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3332>
<morphis> mvo, zyga: however we need to fix the bind() problem for hooks this cycle, if you have any pointers for me what calls it in the go libs when snapctl is executed from your previous research that would be a great starting point
<zyga> morphis: sure
<mvo> morphis: who should I talk to about the dropping of rsyslog in the CE team? I would like to make sure none of our existing customers will suffer because of it
<pstolowski> zyga, ok, will do in a few
<zyga> morphis: it's easy, one sec
<morphis> mvo: I can raise this with Tony later today, it will mean that /var/log/syslog is not being filled anymore, right?
<morphis> joc: would that be a problem for you guys in any way?
<mvo> morphis: I think so, I'm looking at it right now
<zyga> morphis: look at /usr/share/go-1.6/src/net
<zyga> morphis: look at /usr/share/go-1.6/src/net/net.go line 99
<zyga> morphis: on startup the net package probes ipv4 and ipv6
<fgimenez> mvo: i can conform that adding the changes in snapd#3327 to the release/2.26 branch makes the full suite pass using core from beta (amd64 so far)
<mup> PR snapd#3327: tests: fix failing tests (snap core version, syslog changes) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3327>
<fgimenez> *confirm
<morphis> zyga: hm
<zyga> morphis: it creates two sockets and binds them to localhost address
<joc> morphis: pretty sure we have some tests that expect to be able to find events logged in syslog
<zyga> morphis: I don't know if seccomp can even express that
<zyga> morphis: and even if, I don't know if this is safe
<zyga> morphis: after all, you can bind on localhost and that's still IPC
<joc> morphis: off the top of my head, usb insertions
<zyga> morphis: apart from allowing any hook to do "socket+bind"
<zyga> morphis: or waiting for the bleeding edge kernel that can return EPERM
<zyga> morphis: (instead of killing)
<zyga> morphis: well, clarification, all kernels can EPERM, we want bleeding edge kernel that does EPERM + audit
<zyga> morphis: even if we just return EPERM today, I don't know if we can do that per syscall
<zyga> morphis: and even if we can I don't know how that combines with a rule that allows bind (say an actual hook that has the network-bind plug)
<zyga> morphis: all in all, it's pretty messy at this level
<zyga> morphis: for network filtering I'd feel much better if we wrapped things in a network namespace and used firewall rules
<zyga> morphis: but that's a huge chunk of work
<zyga> joc: interesting
<zyga> mvo: ^^
<morphis> zyga: hm
<zyga> mvo: how about postponing this till we can ship a working rsyslog snap?
<zyga> mvo: I know it's a tough problem because we have people that want both things _now_
<mvo> zyga: this was suggested by jamie as well, see the forum discussion
<zyga> mvo: alternatively allow customers to disable it
<zyga> mvo: but don't disable yet and don't remove yet
<icey> I'm trying to make a snap of a prigram that uses git internally, to clone and manage stuff, I'm having trouble getting all of git working from within the snap
<mvo> zyga: I personally think even the removal is risky, its a stable 16 core afterall and we enforce updates. if an update is percived to be breaking functionality that will weaken the trust in the system
<zyga> mvo: yes, I agree
<icey> looks like it's not finding the stuff that's normally in /usr/lib/git-core/
<zyga> icey: that's expected
<zyga> icey: snap execution environment is not like the regular environment
<icey> zyga: I'm aware
<icey> zyga: I've got git installed in the snap
<zyga> icey: all the content of your snap is in $SNAP which is something like /snap/yourfancysnapname/123
<icey> zyga: my program executes git fine, but git can't find any of its handlers
<zyga> icey: and the root filesystem is not the one you normally see
<zyga> icey: but the core snap itself (see /snap/core/current for some ideas)
<icey> zyga: warning: templates not found /usr/share/git-core/templates
<icey> fatal: Unable to find remote helper for 'http'
<zyga> icey: tip: run snap run --shell yoursnapname and look around
<icey> zyga: yes, I've been doing that
<icey> zyga: I'm wondering if anybody has figured out a way to let a program use git (inside the snap) as a dependency
<zyga> icey: some people that tried this also set a variable that redirects git to look elsewhere but I don't remember the details
<zyga> icey: yes they have, there was a discussion here a few months ago
<zyga> icey: but you will still struggle with ssh as ~/.ssh is not going to be available
<icey> zyga: I'm digging through git's manpages now to try to find environment variables
<zyga> icey: and $HOME will not retain its value
<zyga> icey: dig through git source code
<icey> zyga: I'm only expecting to use the http handlers
<zyga> icey: should be good then
<icey> zyga: and I'm not using $HOME
<zyga> morphis: what do you think about the bind issue?
<icey> zyga: practically, my program should be fine (and I can change its source ;-) )
<morphis> zyga: it's hard to say what we can do
<morphis> zyga: it would be good if you could generate a profile specific for snapctl
<morphis> as that is the real issue here and it gets executed under the umbrella of the hook profile
<icey> zyga: do you know if the environment variable is a runtime change or if it would need to be an install time thing?
<zyga> icey: I don't know
<zyga> icey: may be either, it was long ago, sorry :/
<pedronis> fgimenez: mvo: we need to upload some test-snapd-*Â snap with a configure hook (can be empty, accept anything)
<zyga> morphis: interesting
<zyga> morphis: that may be a nice way out
<morphis> zyga: yes
<zyga> morphis: we could have a profile just for snapctl and allow anyone to run snapctl in a way that changes profiles
<morphis> zyga: is that something we can do without a lot of refactoring?
<zyga> morphis: there's still risk ask overmount must now reject you from changing snapctl
<zyga> morphis: perhaps
<zyga> morphis: let me try
<mvo> pedronis: do we have the snap already? if so its trivial for me to upload
<zyga> morphis: thanks for the idea!
<morphis> zyga: np :-)
<pedronis> mvo: no
<morphis> zyga: if you have some initial code I can help more with that as we need to get this fixed real soon
<pedronis> mvo: can make a PR with one though
<mvo> pedronis: ok, I can create one - test-snapd-with-configure ?
<pedronis> yea
<mvo> pedronis: whatever is easier for you :)
<morphis> zyga: I can open a forum topic to get this more widely discussed
<mvo> pedronis: but I can do it too
<zyga> morphis: open one please
<zyga> morphis: I have no code at all but I can get started quickly
<zyga> morphis: it's actually trivial to test
<morphis> zyga: would be great!
<pedronis> mvo: I'll make a PR about that and ping you
<mvo> pedronis: thanks a bunch !
<mvo> pedronis: btw, 3211 (the repair assertion) is green and has two +1, anything else I can do there or can I merge?
<pedronis> mvo: I think it's fine personally, also after further thinking IÂ think it's a good property that if we want we can emit  a canonical signed     brand_model-# assertion if needed
<pedronis> (witho some coord with the brand)
<zyga> morphis: hmmmmmm
<zyga> morphis: I think there's a separate problem
<zyga> morphis: we can change the apparmor profile
<zyga> morphis: but not the seccomp profile
<zyga> morphis: let me read some man pages
<icey> zyga: any chance there's a way to see the snapcraft.yaml used to build a snap? looks like https://uappexplorer.com/app/git-repo.jhodapp may have figured it out
<mvo> pedronis: great, I merge it then, it got a +1 from gustavo as well, we can always iterate, its not being actively used yet anyway
<pedronis> mvo: yup
<zyga> icey: no
<zyga> icey: I know there's ongoing work for that but I don't think it is ready :/
<zyga> icey: you can just reach to the author of that snap
<pedronis> mvo: do we have a core that fixe create-user ?Â or is still building?
<icey> yeah zyga, stalking hiim on GH + Launchpad hasn't led me to useful results
<pedronis> Chipaca: maybe snapd#3335 is something you can review?
<mup> PR snapd#3335: daemon: teach the daemon to wait on active connections when shutting down <Created by pedronis> <https://github.com/snapcore/snapd/pull/3335>
<Chipaca> nah
<Chipaca> :-p
<zyga> oh, no battery
 * zyga looks for cable
<icey> zyga: looks like there's a $prefix available during build, I'm going to try building git in my snap ;-)
<mvo> fwiw https://codecov.io/gh/snapcore/snapd/pulls
<zyga> icey: tip: set prefix to /snap/your-snap-name/current/usr and then install it so that the snap's prime directory only contains the /usr part
<zyga> icey: (I think you can do this with organize)
<mup> PR snapd#3211 closed: assertions: add "repair" assertion  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3211>
<zyga> icey: ask kyrofa for hints, I'm not using snapcraft that much and my knowledge can be stale
<mvo> zyga: also sorry about the missing comment on 3308 - I added one last night but for some reason gh marked it as pending :/
<Chipaca> pedronis: 1.6 didn't have Shutdown, i guess
<pedronis> Chipaca: it doesn't
<pedronis> with 1.8
<pedronis> we wouldn't need this
<pedronis> but doing it similarly means we if/when we move to 1.8, the change is easier
<pstolowski> zyga, we already have sc_snap_name_validate, which is regexp-free
<pedronis> there was some idea to do something inside Command.ServeHTTP , but this seems less invasive
<zyga> pstolowski: I think we need a few more as well
<zyga> pstolowski: but yeah
<zyga> pstolowski: that's the way to go
<zyga> mvo: no worries, I just replied to your question
<zyga> mvo: thank you for responding :)
<pedronis> Chipaca: IÂ need to merge master and waiting for a fixed core to rerun tests, so I can add a comment about that
<Chipaca> pedronis: +1, anyway
<Chipaca> pedronis: my questions were merely because the godoc i have up right now points to 1.8
<Chipaca> if it had been pointing to 1.6 i woudln't've had to ask them at all
<Chipaca> code is super clear
<mup> PR snapd#3328 closed: many: snapctl outside hooks v2 <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/3328>
<pedronis> thx
<zyga> offtopic: wow, amd has released some insane chips!
<mup> PR snapd#3338 closed: tests/main/completion: source from /usr/share/bash-completion <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3338>
<morphis> mvo: thanks!
<pedronis> mvo: do you have a tentative date for 2.27 ?
<zyga> mvo: new core built
<mvo> pedronis: yes, 23.05 ideally, that would follow the two weeks cadance, I created a  milestone
<mvo> zyga: another new core? what changed?
<zyga> mvo: I was thinking that the release "shadow" issues say we should think about a pair of PPAs and snap recipes
<zyga> mvo: I think it was the one you built :)
<zyga> mvo: 2.26.2 with fixed --extrausers
<pedronis> mvo: thank you
<zyga> mvo: I'd like to see the new core, from master, with update-ns though
<mvo> zyga: that one finished some time ago, maybe the last stranglers or something
<zyga> mvo: without interrupting the release
<morphis> zyga: reading a bit through the snap-confine code for the seccomp setup ..
<zyga> mvo: perhaps, I'm on 1952 now
<zyga> morphis: seccomp can only be appended to, I think
<zyga> morphis: (constrained)
<mvo> zyga: I can't parse the "shadow" issue suggestion, sorry. could you elaborate please?
<zyga> mvo: sure, sorry, the conflict of which snapd package is build into the snap
<mvo> zyga: the update-ns from core? I think we need to merge the 2.26.2 change first
<morphis> zyga: so we can split out the current profile and extend just for snapctl?
<zyga> mvo: like when you made 2.26.2 you needed to dput to a ppa and quickly build the core snap
<zyga> mvo: so that another daily build doesn't clobber your state
<zyga> morphis: "split out the current profile?
<zyga> morphis: the problem is that as we can only constrain profiles
<zyga> morphis: if you are in a hook/app that doesn't have network-bind (hook)
<zyga> morphis: nothing you can do will add that
<zyga> morphis: if you allow network-bind in the first place then you'd have to constrain it for _everything_ else (apart from snapctl) but there's no way to do that
<mvo> zyga: thats how it works, except it does not need to be "quick" because as long as the version in the ppa is higher than the version in git master we are good, as soon as e.g. 3336 gets merged we get new core builds with the edge snapd. so the workflow is ok for now
<morphis> zyga: hm
<zyga> mvo: why didn't we get a single build in master that contains edge then?
<zyga> mvo: it's not okay because it doesn't work, releases interrupt master and vice versa IMO
<zyga> mvo: (I swapped the semantics of master and edge in the previous statement)
<mvo> zyga: yeah, that is true, during release the edge is the released version not the edge version, that is annoying
<zyga> mvo: not something i wan't to jump at fixing but I want to recongize the issue
<morphis> zyga: we can't even patch golang for this ..
<mvo> zyga: usually the interruption is short but this time its not because of the various issues (snapd, listing test breakage, rsyslog)
<zyga> morphis: nope
<mvo> zyga: yeah, agreed, I now understand your point and there is no disagreement
<zyga> mvo: I was thinking if we could clone the current setup so we have two of everything: snap recipes, deb recipes and PPA archives
<zyga> mvo: then edge just always contains master no matter what
<zyga> mvo: and beta is a hand-triggered thing
<zyga> mvo: though the list of packages in the ppa is scary :/
<zyga> mvo: I wish we didn't need those
<zyga> mvo: for the rarely changing packages we could just copy them from edge ppa once in a while
<zyga> mvo: but it'd be better if those didn't exist in the first place
<zyga> mvo: and our ppa just contained snapd and nothing else
<zyga> mvo: though maybe it can, with the image machinery
<zyga> mvo: we might move everything else to a 3rd ppa that is there as a base for all core channels
<mup> PR snapd#3336 closed: Reease snapd 2.26.2 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3336>
<mvo> zyga: yes, we can build more infrastructure and decouple the two. there is also the suggesiton from Gustavo about decoupling the snapd build and the base image which is probably the first step as we get a more predictable core with it
<zyga> mvo: yes, the way the core is assembled also has to change
<ogra_> zyga, i need to contact all the uploaders first, (i dont want to delete PPAs without consent), but i'll put dropping them on my TODO
<zyga> ogra_: hey, good mornign
<zyga> ogra_: I think mvo axed some PPAs
<ogra_> zyga, mvo, hmm, did you guys disable something already ?
<zyga> ogra_: I think so
<ogra_> seems edge is broken
<ogra_> (the edge PPA)
<zyga> ogra_: those looked very much dead anyway
<zyga> ogra_: in which way?
<ogra_> "This PPA depends on disabled archives. it may cause spurious build failures or binaries with unexpected contents."
<mvo> ogra_: I killed edge2, I can fix the fallout
<ogra_> this needs some planning i fear
<ogra_> ok
<mvo> ogra_: edge is fine again
<ogra_> we should end up with image anbd edge though, all the others should go ... but there might be people or other PPAs still using them somehow
 * ogra_ will start a forum thread 
<zyga> ogra_: have a look at the discussion just above ^ where I advocate for a beta PPA
<ogra_> zyga, well, we should finally follow the plan ...
<zyga> ogra_: as we (the snapd team) release just beta and edge snaps having a pair makes sense
<ogra_> it exists since nearly 2 years now and we're still buiolding from random PPAs
<ogra_> there should only be one PPA ... for edge ... the rest of the snap builds should come from different stages of the actual archive
 * ogra_ points to the QA teams https://wiki.ubuntu.com/QATeam/OSSnapPromotion
<zyga> ogra_: did you see my rationale for a beta ppa?
<zyga> ogra_: do you think it makes no sense to have it?
<ogra_> zyga, i think building beta from proposed is the way to go ... but that means a lot of PPA cleanup (packasges to go to the archive)
<ogra_> like the plan describes
<ogra_> else you have a PPA for beta builds and *still* need to do the deb release aside ... using proposed as beta stage archive saves that step
<zyga> ogra_: interesting, yes, I think that could work
<ogra_> the problem is that we need to get rid of the image PPA or at least clean up massively in there
<ogra_> we could start with it enabled, but then we need to make sure the package version for snapd is always higher in proposed before we build
<mup> PR snapd#3339 opened: tests/lib/snaps: add a test store snap with a passthrough configure hook <Created by pedronis> <https://github.com/snapcore/snapd/pull/3339>
<pedronis> mvo: ^
<mvo> pedronis: thanks, on it
<morphis> zyga: https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658
<zyga> morphis: I read it, thank you
<zyga> I'm checking what the kernel allows
<zyga> ogra_: who is doing the work on upstraming parts of our PPA?
<mvo> pedronis: thanks, uploaded and shared with you
<mup> PR snapd#3340 opened: Smany: snapctl outside hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/3340>
<pstolowski> zyga, ^ reopened; I've addressed some of your comments but not all, don't worry, i'll address them based on comments from previous PR
<zyga> pstolowski: great, thank you!
 * zyga looks
 * zyga needs some breakfast
<fgimenez> mvo: pi3 finished with just listing and interfaces-log-observe failing, no more crashes it seems, pi2 is good too so far (85/116), i'll trigger now the upgrade-from-stable scenario on pi3 (this one crahsed too on 2.26.1)
<morphis> zyga: happy thing, latest golang git master has changed from an initializer to lazy support detection
<morphis> so the func init() call is gone
<mvo> fgimenez: excellent, thank you. I'm working on 2.26.3 that fixes the listing and observer failures
<fgimenez> mvo: great tahnks
<pstolowski> friendly neighbour drilling again... I need a walk...
<fgimenez> mvo: pedronis should we upload test-snapd-with-configure to snappy-hub too and automate the upload to the store? it is not likely going to change too much, but to align it with the rest of test-snapd-*, i can prepare the lp branch and build
<zyga> morphis: nice :)
<morphis> zyga: however, doesn't really help us :-)
<zyga> morphis: but still meh :( we won't be using that anytime soon
<morphis> zyga: LD_PRELOAD would be another way but not sure if that would work
<morphis> I guess golang doesn't go through libc for that
<morphis> hm, they use syscall()
<mup> PR snapd#3331 closed: tests: remove unit tests task <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3331>
<zyga> morphis: how would LD_PRELOAD help?
<morphis> zyga: if it would use libc to call bind we could easily intercept the bind() call
<morphis> but we can't
<zyga> morphis: ah, right
<zyga> morphis: those are stright syscalls I'm afraid
<zyga> also sucks for strace
<zyga> (golang tooling sucks here)
<morphis> zyga: yes
<pedronis> mvo:  mmh, I haven't got the sharing email for that snap afaict
<mvo> pedronis: could you /msg me your primary sso email address please? there used to be a bug that it would only share it with this mail
 * zyga eats breakfast while reading seccomp sources
<ogra_> mvo, a review of https://github.com/snapcore/core/pull/43 would be appreciated ... (in that course ... i wonder if we should drop cron, the only remaining thing left for  it is logrotate which we could switch to a systemd timer instead)
<mup> PR core#43: remove generated logs, cleaner lsb-release removal <Created by ogra1> <https://github.com/snapcore/core/pull/43>
<mvo> ogra_: I don't want to make the cron removal call, I think its risky to do package removal on a stable core, I would prefer if we do this and the rsyslog change in 18 only. but thats just me
<morphis> zyga: hm, looks like we have a problem with rshared on Fedora
<zyga> morphis: tell me
<morphis> zyga: not sure yet, but the snap-on-non-shared-root spread tests fails, explicitly here https://github.com/snapcore/snapd/blob/master/tests/main/snap-on-non-shared-root/task.yaml#L18
<morphis> zyga: https://paste.ubuntu.com/24592098/
<zyga> morphis: can you capture that with SNAP_CONFINE_DEBUG=yes ?
<pedronis> pstolowski: IÂ think I'm a bit confused  about the relationship between Sanitize* and Validate* and default values for interface attributes (which is not a concept we use much, mind)
<morphis> zyga: yes, rebooting the machine right now and will do that
<Chipaca> pedronis, mvo: is there an obvious way of adding info (e.g. apps) to overlord/snapstate's mock snaps that i'm missing?
<pedronis> Chipaca: what kind of snaps ? snaptest.MockSNap ?
<Chipaca> pedronis: most tests just start with a SideInfo
<pedronis> well, there's snaptest.MockSnap
<pedronis> that we use when you want something on disk
<Chipaca> and it seems that changing that to something that has apps is a lot of repetitive typing
 * Chipaca looks
<pedronis> (remember to undo the mocking of ReadInfo though)
<pedronis> we use it sometimes in snapstate
<pedronis> this is more for stuff already installed though
<Chipaca> yep. sounds like the basic answer is 'no' :-/ but let me see how far i get
<ogra_> mvo, well, you should comment on the rsyslog thread at least ... i'll leave cron untouched for 16 then
<pedronis> if you want to start from a .snap, there's  something else
<Chipaca> pedronis: yep. I was just wanting to avoid having to rewrite all the tests
 * zyga errands
<Chipaca> well, 'all', 21 of them
<pedronis> Chipaca: there is also snaptest.MakeTestSnapWithFiles if you need a .snap
<abeato> zyga, hi, what do you mean by "atomic write helpers"?
<Chipaca> I'll probably remove the code that makes all the tests fail, and come back to it later
<mvo> ogra_: maybe, but it seems I'm just repeating something that has already been debated so I will not add much value to the discussion
<morphis> zyga: https://paste.ubuntu.com/24592122/
<Chipaca> (with the changes i made it's super easy to not add the {start,stop}-snap-services task if the snap has no services, so I thought I'd do that, but it breaks 21 tests :-) )
<ogra_> mvo, well, it will add value in that it shows you agree with jamie ... i would have preferred to just be able to disable it but didnt find it worth to have an argument about it
<Chipaca> (sorry, not the task, the backend call)
<morphis> zyga: will be out for lunch now
<pedronis> Chipaca: ah, my experience is that making task optional is a recipe for pain
<Chipaca> pedronis: i can imagine :-) but it's not the task, just the backend call, so it should be doable
<Chipaca> :-)
<Chipaca> pedronis: (and it'd avoid a lock/unlock of state, which is why i think it might be worth it)
<pedronis> Chipaca: anyway if you go that way what you want is remove those things from all tests and then just have a couple of tests about your case
<Chipaca> but, completely secondary to the work i'm doing
<pedronis> Chipaca: not re-add services everywhere
<Chipaca> pedronis: !
<Chipaca> good point
<Chipaca> in a later branch.
 * Chipaca tries to focus
<pedronis> fgimenez: mvo: still getting main/compleation create-key time outs fwiw :/
<Chipaca> basically in prep for 'snap start', i'm making wrappers.StartSnapServices -> wrappers.StartServices take a []*snap.AppInfo instead of a *snap.Info, and seeing how far into the beast this makes sense to let it bubble in
<Chipaca> i've reached the task level with no great changes, and i think this is good
<Chipaca> (not touching tasks)
<fgimenez> pedronis: that's bad, do you have a link to the build?
<pedronis> fgimenez: no, I resterarted it
<pedronis> but nothing interesting
<pedronis> just expect on create-key giving time out
<pedronis> in the prepare of main/completion
<fgimenez> pedronis: ok did you notice which system was failing? now we should be installing and configuring rng-tools for all the ubuntu-* systems
<fgimenez> maybe that's not enough though, i think Chipaca suggested to use something else
<pedronis> fgimenez: also here a prepare timed out: https://travis-ci.org/snapcore/snapd/builds/233161781
<pedronis> fgimenez: no, sorry, I will try to check that the next time :/
<Chipaca> look at the times on the prepares that succeeded
<pedronis> fgimenez: it seems we are quite back into flaky land overall
<pedronis> I see a green run everywhere I don't know many red ones
<pedronis> :/
<fgimenez> pedronis: nw, i'll try to keep an eye on it
<fgimenez> pedronis: yep, the flaky switch
<abeato> Chipaca, hey, how this thing about export_test.go works? don't really get it
<Chipaca> abeato: because it's called foo_test, it only is looked at during tests
<Chipaca> abeato: but you put it in the foo package, not the foo_test package
<Chipaca> abeato: so you have code in the main package that is only looked at during tests
<pedronis> abeato: you write most of your _tesst.go tests with "package pkg_test"Â  but you use "package pkg" in export_test.go
<pedronis> go test collects and compiles all _test.go  but export_test.go that way has access and can reexport give access to pkg internals
<Chipaca> abeato: so there you can do things like make private methods public, or mock out external calls, or etc
<Chipaca> abeato: hoping this makes sense in the context of that review :-)
<Chipaca> abeato: as I said there, it looks good; the changes i asked for are idiomatic
<Chipaca> looking forward to having that code :-)
<abeato> Chipaca, does that mean that I need to add somewhat all private methods that I use in the tests to export_test.go?
<fgimenez> pedronis: i've seen quite a few times the prepare timeout lately http://paste.ubuntu.com/24592153/, maybe we could remove the "quiet" call there now that we are folding the output in travis to see what's going on
<abeato> Chipaca, sure, you know, I am starting with golang, so it is still hard for me :)
<Chipaca> abeato: yep! we've all been there
<Chipaca> abeato: wrt "all private methods", are there really that many?
<Chipaca> it's usually just a few, if any
 * Chipaca looks
<abeato> Chipaca, well, just too, androidboot and newAndroidboot
<Chipaca> abeato: androidboot is a type, but you can add accessors in export_test
<zyga> re
<Chipaca> abeato: and yes, a constructor that lets you set more internal things makes sense
<Chipaca> in export_test i mean
<zyga> abeato: look at osutil/io.go
<zyga> morphis: thank you, reading
<abeato> Chipaca, will try that, thanks
<Chipaca> abeato: also it might help you write the tests more unit-y if you mock androidbootenv.NewEnv
<zyga> morphis: DEBUG: share snap directory here... this (somewhat ugly) output says that we rshared /snap
<zyga> morphis: let me triple check
<Chipaca> abeato: but i'm not fussed about that one
<abeato> Chipaca, ok
<Chipaca> abeato: (mocking would usually involve something like âvar newEnv = androidbootenv.NewEnvâ in the main code
<Chipaca> abeato: then you use newEnv
<zyga> morphis: but this also shows the code is different in master,
<zyga> morphis: which release was this?
<Chipaca> abeato: and in export_test you have a Mock function that lets you overwrite it
<zyga> morphis: and if you can, try master
 * zyga looks at email
<Chipaca> abeato: those Mock functions usually are func MockThing(newThing) func(), and they return a function that resets things to how they were
<Chipaca> abeato: so you can do e.g. restore := MockThing(newThing); defer restore()
<Chipaca> (or directly âdefer MockThing(newThing)()â but that's harder to read)
<Chipaca> abeato: anyway i'll let you work :-)
<abeato> Chipaca, thanks :)
 * zyga wonders what https://bugs.launchpad.net/snap-confine/+bug/1691405 is about
<mup> Bug #1691405: apt autoremove in removing snap-confine 2.24.1 cause mariadb galera crashes <galera> <mariadb> <snap-confine> <snap-confine:New> <https://launchpad.net/bugs/1691405>
<ogra_> zyga, smells like coincidence
<Chipaca> zyga: quoth the raven, WAT
<ogra_> (hard to tell with proper logs etc)
<zyga> Chipaca: my feeling exactly
<mup> PR snapd#3341 opened: Release 2.26.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3341>
<zyga> pstolowski: question about the validate methods: are they mandatory?
<zyga> pstolowski: if not, can we drop the no-op ones?
<pstolowski> zyga, my understanding is they are not mandatory, most interfaces will not need attributes collected at runtime. ok, I'll drop the no-op ones
<zyga> pstolowski: thanks!
<pstolowski> pedronis, re your earlier question.. we still need to discuss these aspects, i'm not sure if I know all I did matches what Gustavo had in mind last time we talked about it. the basic idea is that Sanitize* checks that attributes from yaml are fine and it can error out if a mandatory attribute is missing. It can also add missing attributes if it wants to. Whatever attributes are present after Sanitize* step, cannot be overwritten by snapctl at runtime.
<pstolowski> Validate* methods should validate all attributes collected from snapctl
<pedronis> pstolowski: the issue is whether, can Validate fill in defaults? because otherwise you cannot overwrite things with defaults left out form the yaml with those rules
<pstolowski> *i'm not sure if all I did matches*
<mup> PR snapd#3342 opened: this is a refactor branch, in preparation for 'snap start' etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342>
<pedronis> pstolowski: in other words, my question is,  should we fill defaults after the yaml, or do we need to support filling in defaults once we have seen both yaml attrs and dynamic attrs
<pedronis> I vaguely remember that we discussed the latter, but then IÂ don't understand the roles and when called of Sanitize* and Validate* anymore
<pstolowski> pedronis, Sanitize* is still called when plug or slot is added to the repo
<pedronis> I know
<pedronis> but that doesn't help with defaults if we need to fill after dynamic attrs
<pedronis> fgimenez: mvo: I'm seeing this kind of failures:  https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170517_111137_b1b51@/log.gz
<juanrubio> Hi guys, I'm trying to figure out how to include a configure hook so that my application gets its configuration file updated before the first use. Going through the docs, I've placed a 'configure' script under 'tizonia/snap/hooks'.. see https://github.com/tizonia/tizonia-openmax-il/tree/master/snap/hooks... but the hook is not getting included in the snap
<pedronis> it looks like we capture state.json when core is still being worked on somehow
 * zyga -> lunch
<pedronis> fgimenez: mvo: error: snap "core" has changes in progress
<fgimenez> pedronis: maybe because of the recent core publication? not sure
<pstolowski> pedronis, shouldn't this decision be left out to the interface implementation? if it wishes to support some attributes from runtime, it needs to implement Validate* and supply defaults at Validate* time, or error out there if missing, Otherwise if interface doesn't support runtime attributes, they all need to come from yaml and be handled in Sanitize*
<pedronis> pstolowski: that's a decision but now we have two places where to support attributes, or we just move things from Sanitize* to Validate*
<pedronis> pstolowski: anyway I'm also interested to keep this thing under control because of the passing nil for attrs and methods trying to write them
<pedronis> we need a hackish fix for content
<pedronis> for that
<fgimenez> pedronis: core with 2.26.3 has been just published to edge and beta, maybe the autorefresh detected it during the suite execution and started an update
<pstolowski> pedronis, yes.. that's a valid concern. thanks for bringing it up
<morphis> zyga: this is master between 2.25 and 2.26
<pedronis> s/we need/we did/
<mup> PR snapd#3335 closed: daemon: teach the daemon to wait on active connections when shutting down <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3335>
<pedronis> fgimenez: ah
<pedronis> pstolowski: what's the current idea? an interface supports dynamic attrs only if it has Validate* ?
<pedronis> otherwise we error?
<morphis> zyga: rebased now, let me see if that helps
<pedronis> pstolowski: no, I remember discussing that, and the idea was to just ignore them?
<sborovkov> hi, does service running inside the snap have access to /proc/$IT's_pid?
<pstolowski> pedronis, if an interface doesn't implement Validate*, but its implementation supports any extra attributes not present in yaml and after Sanitize*, then it would work if they were supplied by a hook.
<Chipaca> sborovkov: mostly, yes
<jamespage> Q: what does the syntax for consuming a snap for a specific track look like? Google is failing me and I'm trying to write some forward looking UX for the openstack snaps
<pstolowski> pedronis, in other words, if want to specifically block this scenario, that it needs an extra check
<pedronis> I don't think we want to block it
<Chipaca> jamespage: 'snap install --channel foo/bar thesnap'
<jamespage> foo being the track and bar being the channel?
<sborovkov> Chipaca: nice, I just want to know the number of threads my own process is using
<jamespage> so that might be ocata/stable for me I think
<pedronis> pstolowski: we call Validate* even if there are no dyamic attrs if it's defined?
<Chipaca> sborovkov: where does that info come from?
<sborovkov> Chipaca: well /proc/$pid/status should give that info I think. Not sure if there is better way
<Chipaca> jamespage: see the 'snap info' output, might help
<pstolowski> pedronis, yes. it receives plug or slot (same as Sanitize*), plus a dictionary with extra attributes (may be empty)
<pedronis> jamespage:   --channel=track[/risk]  where risk defaults to stable
<pstolowski> pedronis, btw, I feel that this discussion should happen in the forum
<jamespage> pedronis: thanks
<Chipaca> pedronis: the defaulting to stable only recently landed in master
<Chipaca> so you're right, but it might not be what jamespage is on yet :-)
<ogra_> sborovkov, to find out such stuff, install hello-world ... then you can use hello-world.sh to spawn a shell inside the snap and check what it can read/access
<jamespage> my forward looking UX is sufficiently far out it will be by the time we have things in tracks...
<pedronis> pstolowski: do we have a topic already, I can write something there later
<ogra_> sborovkov, "cat /proc/self/status" definitely works fine here
<pstolowski> pedronis, no, this branch is older than the forum ;)
<sborovkov> ogra_: alright, thanks
<ogra_> (self always points to your PID)
<sborovkov> wow nice I did not know that
<pedronis> pstolowski: maybe you can start a topic then ;)
<Chipaca> to be precise, jamespage: pedronis: making --channel=foo (for foo not in stable,candidate,beta,edge) mean foo/stable landed in master 5 days ago, in snapd#3290
<mup> PR snapd#3290: add support for `snap install foo --channel=3.4` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3290>
<jamespage> \o/
<Chipaca> jamespage: hurray for forward-looking UX
<Chipaca> jamespage: (also if you want to try it, use core from edge -- but it's called edge for a reason :-) )
<zyga> morphis: thank you, capture another trace with SNAP_CONFINE_DEBUG
<mup> PR snapd#3343 opened: WIP: Spread tests for fedora <Created by morphis> <https://github.com/snapcore/snapd/pull/3343>
<pstolowski> pedronis, sure, will do
<pedronis> thx
<diddledan> I just released corebird 1.5 to stable
<diddledan> (amd64 only atm, until the buildd works properly :-p - jhbuild doesn't like it)
<morphis> zyga: https://paste.ubuntu.com/24592352/
<morphis> zyga: the kernel and native arch values are wrong too
<morphis> zyga: or these are raw printed values
<morphis> looks like that is it
<Chipaca> diddledan: looks good! why does it download libopenh264 outside of the snap?
<diddledan> Chipaca: because it's legal
<zyga> morphis: the kernel / arch thing is just the way seccomp represents them, there's nothing better sadly
<zyga> morphis: interesting,
<Chipaca> diddledan: meaning you can't distribute libopenh264?
<zyga> morphis: can you cp snap-confine-debug to snap-confine
<morphis> we could atleast do some string conversion so we print something like x86-64 but would be just for the reader :-)
<zyga> morphis: and try again?
<diddledan> Chipaca: you're still liable for licensing costs if you distribute it yourself
<zyga> morphis: it's not that easy, it's not just a string
<Chipaca> diddledan: ew
<zyga> morphis: and it's opaque to us, internal seccomp thing
<morphis> zyga: right but there are defined values which you compare already
<diddledan> Chipaca: cisco are taking the hit for their compiled binary
<morphis> like SCMP_ARCH_X86
<diddledan> of course, I didn't think about that for arm.. must sort out whether it's possible to download an arm binary on those
<zyga> morphis: where?
<morphis> seccomp-support.c
<morphis> sc_add_seccomp_archs
<zyga> ah
<morphis> host_arch and native_arch
<zyga> the problem is that it not the whole view
<zyga> let me look at the internals of seccomp
<zyga> AFAIR there are bitfields and flags and other bianry garbage there
<morphis> zyga: let me build the -debug varaint of snap-confine and retry
<zyga> morphis: the debug variant is built too, just not intstalled
<zyga> morphis: you may have it in your tree
<zyga> morphis: but really
<morphis> zyga: you do a switch on host_arch against SCMP_ARCH_X86_64
<zyga> morphis: this is: mount --bind /snap /snap
<zyga> morphis: what is wrong is clearly the path
<morphis> so we can do something similar for a host_arch to string conversion
<zyga> morphis: anyway, irrelevant to the problem and let's look at seccomp to be sure
<jdstrand> morphis, zyga: trying to get through your backscroll conversaton-- it is spread out over several hours. but to confirm a few things: a) you can't seccomp arg filter bind because it can't derefernce userspace pointers (that is a hard limitation of seccomp) and b) there is no such thing as a profile transition with seccomp (that is a limitation of the kernel) c) you may change the current seccomp filter, but only by making it more restrictive (ie, you
<morphis> zyga: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L641 , should that use the configured SNAPMOUNTDIR?
<zyga> morphis: ah
<zyga> yes
<zyga> sorry, I should have caught that!
<jdstrand> morphis, zyga: tyhicks is working on kernel changes that would allow us to not KILL but EPERM, which would make this non-fatal
<morphis> jdstrand: hm, but a kernel change wouldn't really help in this case
<zyga> morphis: shall you make a patch or do you want me to
<morphis> zyga: let me do one
<zyga> jdstrand: we can already EPERM, what AFAIK is missing is the extra message that goes along with the currnet KILL
<zyga> morphis: thank you
<zyga> *current
<morphis> jdstrand: very interesting
<zyga> jdstrand: though I really wonder how we plan to work with that, given the various kernels out there, is this something we can detect from userspace before we create the profile?
<jdstrand> zyga: we absolutely do *not* want a network namespace. look at all the problems that the mount namespace has caused. we want fine-grained network filtering in the lsm. the netowkr namespace would tremendously complicate how the snap integrates into the system and how snaps interact
<zyga> jdstrand: maybe, maybe not, I'm not convinced
<zyga> jdstrand: I think vast majority of snaps would work inside a network namespace, you could opt-into a real-network-namespace interface to be free of that
<jdstrand> zyga: with that we can use seccmark. ie, we tag each packet with an per-snap seccmark, and then firewalling can be used with that
<zyga> jdstrand: a network namespace + firewall is a portable way to handle this
 * Chipaca ponders lunch
<jdstrand> zyga: remember, namespaces are for separation, not for integration into the system. selinux can do secmark too, so that shouldn't be an issue
<zyga> jdstrand: do you have any pointers to documentation about seccmark, I'm not faimilar with it
<zyga> jdstrand: oh and while you are here; a more relevant and pressing need
<zyga> jdstrand: is there _any_ way to replace the seccomp profile of a process?
<jdstrand> morphis, zyga: can you point me to the bug. I feel like I already discussed this and options but am having trouble finding that conversation
<zyga> jdstrand: (replace, not augment)
<zyga> jdstrand: ha, it is in fact the same problem
<zyga> sure
 * zyga gets the link
<morphis> jdstrand: https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658 , I didn't added the LP bugs yet, let me do that now
<zyga> https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658/2
<zyga> jdstrand: the instant idea was to give snapctl a dedicated apparmor profile (like snap-confine) but then we'd still be stuck on the seccomp profile
<jdstrand> zyga, morphis: re separate profile for snapctl-- that won't work in the way you might be thinking-- there is no such thing as a profile transition in seccomp. you can do that if you cross IPC though
<morphis> jdstrand: https://bugs.launchpad.net/snappy/+bug/1644573
<mup> Bug #1644573: snapctl causes hooks to attempt to open ip/ipv6 tcp connection <Snappy:Triaged by zyga> <https://launchpad.net/bugs/1644573>
<zyga> jdstrand: yep, that's what we realized earlier today :(
<zyga> jdstrand: I just hoped I was wrong and there's (some) way
<morphis> jdstrand, zyga: also added in https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658/3?u=morphis
<zyga> thanks!
<jdstrand> morphis: as for kernel changes not helping-- we are going to need to be a little more agile about that sort of thing I'm afraid (not that there isn't something else we can do here), but we used to have a long list of patches that a certified snappy kernel needed. anyway, that's a digression
<jdstrand> zyga: we can eperm, but it is either kill or EPERM now and if you EPERM you lose logging for everything
<zyga> jdstrand: the point is not that (that's all fine) but if we can detect such kernel in the first place so that we can make a compatible profile
<morphis> jdstrand: I agree, however I am not sure how fast we could get such a change into the official kernel for already released versions of Fedora, openSUSE, ...
<zyga> jdstrand: right, that's my understanding as well (eperm and logging)
<jdstrand> zyga: EPERM+audit will be detectable from userspace
<morphis> jdstrand: actually for Ubuntu this isn't a problem, this is one for all !Ubuntu systems where we have no apparmor but seccomp
<jdstrand> zyga: I can't say strongly enough that I think a network namespace is a mistake
<jdstrand> zyga: there is no way to replace a seccomp profile or to transition out of it
<niemeyer> Mornings!
<jdstrand> morphis: I read that forum post, but there is a bug and other conversation on it
<zyga> jdstrand: note that I'm not doing anything towards that, it was just (any) idea that I had left
 * jdstrand is still getting through your responses to my responses to backscroll (might've waited for me to come online :P)
<zyga> jdstrand: hehe
<morphis> jdstrand: :-)
<zyga> jdstrand: do you think we could _safely_ allow bind-on-localhost to in the default template?
<zyga> jdstrand: just bind, I don't think we need connect
<zyga> jdstrand: or even listen perhaps /me looks
<jdstrand> zyga: bind-on-localhost: that isn't a thing. it is bind or no bind. we can't derefence the struct to see it is for localhost
<jdstrand> ok
<jdstrand> I'm caught up
<zyga> jdstrand: not even listen!
<jdstrand> let me read everything and think a moment
<zyga> jdstrand: ah, then we've got no other options that I can think of
<zyga> it's a real shame seccomp cannot do this and apparmor cannot do this at the same time :/
<jdstrand> there is an option. just add the bind on systems without apparmor
 * Chipaca really lunch now
<zyga> Chipaca: ejoy
<zyga> niemeyer: hey! :)
<jdstrand> zyga: well, finegrained network mediation could come after the upstreaming-- you'd have to talk to ratliff and tyhicks about prioritizing that, but that doesn't solve anything here cause a) you said we can't patch kernels and b) this is for systems with only seccomp and not apparmor
<morphis> jdstrand: would be an option
<jdstrand> I guess morphis was the one who said we can't patch kernels
<jdstrand> ok, let me read
<morphis> jdstrand: we maybe can but I guess this will be a longer process to get such a patch into Fedora, openSUSE etc.
<zyga> jdstrand: we cannot patch kernels on existing systems, consistently and predictably so we need anything else as plan B
<jdstrand> morphis: note that an early implementation decision was that the lsm and seccomp would work together and that we wouldn't pick one or the other, since both are needed for proper confinement
<morphis> but given that we run snaps "unconfined" on these distros anyway we could just allow bind
<morphis> jdstrand: interesting, I was told we can use seccomp independently
<ogra_> just default to snap install canonical-livepatch alongside snapd ...
 * ogra_ grins
<jdstrand> zyga: I understand the problem but think about it-- we can only ever weaken the sandbox because we reach out farther and farther to systems that are running kernels that don't have features, may have bugs and at the same time reaching back in time to 3.4
<morphis> jdstrand: if that is true we should maybe make seccomp requiring apparmor being enabled inside snap-confine
<jdstrand> I mean, everything was designed with a particular set of requirements. how is one supposed to fix bugs if we are now trying to support unupdateable ancient kernels? why are we even upstreaming anything-- it won't but something everyone can use so no one can use it
<jdstrand> (that is not meant to be answered-- of course we need to upstream-- but it illustrates the point)
 * jdstrand really reads now
 * zyga agrees with jdstrand 
<zyga> perhaps just disabling seccomp if incompatible LSM is found is the way to go?
<morphis> zyga: I would say when --disable-apparmor disable seccomp too
<jdstrand> oh, and we can't patch go either :)
<zyga> morphis: we can just emit a no-op profile in snapd
<morphis> jdstrand: yeah, however latest go is a lot better and doesn't seem to have this problem anymore :-)
<morphis> zyga: why not disable it completely for snap-confine?
<jdstrand> morphis: iirc, my comments in bug #1674193 re the /run/snapd.socket are fixed now, right? ie, snapctl now chooses the correct socket
<mup> Bug #1674193: core snap's configuration hangs on debian | openSUSE | mainline kernel <Snappy:Fix Committed by morphis> <snapd (Debian):Fix Committed> <snapd (Fedora):Fix Committed by morphis> <snapd (openSUSE):Fix Released by morphis> <https://launchpad.net/bugs/1674193>
<morphis> jdstrand: AFAIK, yes
<jdstrand> but there is no lsm on these other distros, so they can just talk to that socket
<zyga> morphis: because it's a compile time decision
<morphis> jdstrand: right, but they are blocked by seccomp
<mvo> fgimenez, pedronis, nessita: I see a new error in our tests: "error: Please buy test-snapd-control-consumer before installing it." - did anything change to this snap recently?
 * jdstrand would have to remind himself of the code on those
<jdstrand> morphis: not if they plugs network-bind which is autoconnected
<pedronis> mvo: that the spurious error we would get on a 401
<mvo> pedronis: aha, that explains it
<pedronis> mvo: is this a classic test or a core test
<mvo> pedronis: this happend on classic
<zyga> morphis: ohhh, that thing you found earlier is a compile time choice :((((
<zyga> morphis: we need to change that too
<pedronis> mvo: bit unexpected
<Chipaca> mvo: are you running with SNAPD_DEBUG_HTTP?
<Chipaca> mvo: (do you get that every time?)
<mvo> Chipaca: I think it was just a one off
<mvo> Chipaca: sorry for the noise
<Chipaca> mvo: if you were running with http debug on, i'd like to see the store repsonse
<Chipaca> or its response
<Chipaca> either will do
 * mvo nods
<Chipaca> mvo: if this was in spread, it does have debug on :-)
<Chipaca> SNAPD_DEBUG_HTTP=7 even
<mvo> Chipaca: it did happen there, but in snap download which has no debug enabled apparently (c.f. https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170517_120423_15d84@/log.gz)
<Chipaca> :-(
<jdstrand> morphis, zyga: let's just accept for the moment that seccomp without lsm is ok for now and assume we can't patch anything but snapd/snap-confine. I see a few options: a) add bind unconditionally everyone, b) add bind conditionally on if apparmor isn't there and seccomp isn't using EPERM and c) adjust snapctl to not make these calls
<jdstrand> morphis, zyga: I don't like 'a' at all. let's strike that
<pedronis> it's go runtime that does these so c)Â is not an option
<pedronis> afaiu
<nessita> mvo, as pedronis said, is a misleading error, I thought pete worked on that before he left (maybe not?)
<pedronis> nessita: no, after discussion it was decided to wait for the store to return better errors
<jdstrand> pedronis: well, as its implemented. there would need to be investigating. perhaps reaching out to C and that wouldn't happen. out of process helper. fork a C program, etc
<jdstrand> however, 'c' is complicated
<jdstrand> so I suggest 'b'. zyga worked on code to conditionally add policy for snap try for ecryptfs, this is very similar to that
<jdstrand> zyga, morphis: ^
<Chipaca> + snap install --dangerous basic-hooks_1.0_all.snap
<Chipaca> error: cannot read snap file: info failed to parse: yaml: control characters
<Chipaca>        are not allowed
<Chipaca> from https://api.travis-ci.org/jobs/233194012/log.txt
<pedronis> Chipaca: weirdness++
<pedronis> and flakiness on top
<Chipaca> niemeyer: fgimenez: any chance we can fsck the images?
<mup> PR snapd#3341 closed: Release 2.26.3 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3341>
<jdstrand> zyga, morphis: that's totally doable this cycle. it's simple to understand and shouldn't be hard to implement. please request me as a reviewer
<nessita> pedronis, but an inmediate fix can be done which will help users considerably: on 401 from the download url, if the local metadata says there is no price set, just return a different error and do not mention buy or price
<pedronis> nessita: that was not my decision
<niemeyer> Chipaca: Do we have any issues there?
<Chipaca> niemeyer: ^^^
<pedronis> nessita: it's complicated because we don't the price information at that point
<Chipaca> niemeyer: what i pasted
<pedronis> in the code
<niemeyer> Chipaca: Sorry, a bit slow today.. I'm failing to make the correlation
<zyga> jdstrand: reading
<pedronis> Chipaca: we build the snaps, no?
<Chipaca> niemeyer: how did 'control characters' get to the yaml?
<pedronis> so it would flaky virtual disk not the image
<pedronis> that yaml comes from the checkout
<pedronis> same
<niemeyer> pedronis: Ah, but I think our snap builder doesn't read the files does it?
<niemeyer> Chipaca: That said, wouldn't that fail every single time?
<niemeyer> If it was the image
<zyga> jdstrand: I think b and c are possible and welcome; c is "free" on new golang stack but b feels more realistic quickly
<Chipaca> niemeyer: probably? I don't know
<fgimenez> Chipaca: you can always check an instance of the images with "spread -reuse -shell <system>"
<zyga> jdstrand: I agree on 'b'
<fgimenez> even without -reuse
<mup> PR snapcraft#1319 closed: kernel plugin: config check: remove DMIID option <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1319>
<niemeyer> Chipaca: If it was a broken image, how would it work sometimeS?
<ogra_> must be a moody image :)
<Chipaca> niemeyer: I don't have a hypothesis that could give this behaviour, so I was looking to eliminate things that could introduce failures
<Chipaca> s/give/explain/
<niemeyer> Ack
<zyga> ogra_: probability, image has a quantum state that when measured on full moon, crashes ;)
<ogra_> haha, yeah
<morphis> zyga: https://github.com/snapcore/snapd/pull/3344 doesn't work, as it happens before the call to sc_populate_mount_ns which mounts the /var/lib/snapd dir from the host into the core snap
<mup> PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344>
<mup> PR snapd#3344 opened: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344>
<morphis> so that doesn't seem to be the real problem as this only seems to remount /snap onto /snap again
<morphis> let me read through that code a bit more
<zyga> morphis: no
<zyga> morphis: 2nd line is wrong
<zyga> sc_do_mount(SNAP_MOUNT_DIR, "/snap", "none", MS_BIND | MS_REC,
<zyga> let that just do SNAP_MOUNT_DIR *again*
<zyga> it will work :)
 * zyga afk
<zyga> morphis: and please write a nicer commit message :D
<jdstrand> morphis, zyga: I'm commenting in the form
<jdstrand> forum
<morphis> zyga: ah I see, this is before the pivot_root call
<morphis> jdstrand: thanks!
<abeato> zyga, Chipaca https://github.com/snapcore/snapd/pull/3324 ready again, thanks for the thorough review!
<mup> PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324>
<Chipaca> abeato: yep! i'd be on it if i weren't in a meeting :-)
<abeato> Chipaca, :)
<Chipaca> mvo: in this case i think it was chrome and not pulseaudio funnily enough (or HO itself); pulseaudio was seeing my mics fine
<zyga> abeato: thanks, I'll have a look in a moment, just need to refill my drink, it's super hot in spain today
<Chipaca> abeato: the bit i got to look at so far looks much cleaner :-)
<morphis> abeato: is that PR still WIP?
<abeato> morphis, not really, I will remove that
<morphis> ok
<mup> PR snapd#3339 closed: tests/lib/snaps: add a test store snap with a passthrough configure hook <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3339>
<mvo> abeato: I added some feedback too, nice job I have to say :)
<zyga> abeato: done
<abeato> mvo, zyga thanks!
<morphis> zyga: ok, it seems to work now, but running into other problems on restore now
<ogra_> mvo, did you notice that the systemd in the image PPA is actually overridden by the archive now ? the one stuck in -proposed finally made it through ... do you think we can drop the systemd package from the PPA now ?
<ogra_> (seems we are building with the archive version since a while already ... with no bugs or complaints)
<mvo> ogra_: yeah, this looks pretty good now, this can go now. very happy that this is finally fixed
<ogra_> \o/
 * ogra_ removes the package
<ogra_> mvo, resolvconf too i suppose ?
<mvo> yes
<ogra_> done
<mvo> ta
<morphis> Pharaoh_Atem: can you include one minor fix in the 2.26.* package updates for fedora? just add --disable-seccomp for the snap-confine build
<mvo> morphis: \o/&
<morphis> Pharaoh_Atem: but wait a second, just reading jdstrand's reply
<Pharaoh_Atem> why is this broken again?
<morphis> jdstrand: didn't you say before that the seccomp confinement shouldn't be used without an LSM?
<morphis> Pharaoh_Atem: https://forum.snapcraft.io/t/hooks-calling-snapctl-are-broken-with-just-seccomp-enabled/658/
<morphis> Pharaoh_Atem: it was never really fixed, just for the core snap which now plugs network-bind
<morphis> jdstrand: " 'd' should not be used because it weakens the sandbox on systems where AppArmor is disabled (though the seccomp sandbox alone should not be considered strong confinement)" seems to contradict what you said before or do I miss something?
<Pharaoh_Atem> if it's fixed in Go 1.8, I can just conditionally disable it
<jdstrand> morphis: maybe its the double negative. I'm saying that on systems without apparmor, forcing disabling seccomp is undesirable since it would mean no seccomp filtering on those systems
<jdstrand> it's
<morphis> jdstrand: right, and I agree that is not really what we want but trying to see what this whole thing is actually meant to be
<jdstrand> morphis: in the irc scrollback, I did say that using them separately wasn't part of the original design, yes
<morphis> jdstrand: so with that said, !apparmor + seccomp is sth we want to support?
<jdstrand> morphis: but we are down that path now and it is easy enough to not disable seccomp by doing 'b'
<morphis> jdstrand: ok, got it
<jdstrand> morphis: well 'support'? I mean, we are already doing it. let's see how long we can continue with it. it isn't strong confinement, but it is something
<Pharaoh_Atem> which is precisely why I have it on
<Pharaoh_Atem> it's better than zero
<morphis> jdstrand: we could strongly say we don't want to support it
<Pharaoh_Atem> morphis: no
<morphis> Pharaoh_Atem: it's two sided, if it is unsupported you may run into problems upstream don't care about
<Pharaoh_Atem> but upstream is supposed to care about it
<morphis> if it doesn't fit into the confinement roadmap than we may better disable it
<morphis> Pharaoh_Atem: that is what I am trying to make clear
<Pharaoh_Atem> then by that logic, I should just remove fedora snapd because you guys can't support it properly :(
<Pharaoh_Atem> I'd really like for support to not be regressive in nature
<Pharaoh_Atem> and frankly, even openSUSE can't have apparmor+seccomp yet
<Pharaoh_Atem> we'll have it there this fall, but no earlier
<Pharaoh_Atem> I'm pinning my hopes on the patches being merged before Factory is branched for SLE 15
<morphis> Pharaoh_Atem: no you shouldn't because this doesn't mean nobody cares
<morphis> I am just trying to get a better understand of how things are supposed to work
<morphis> but I think option b as jdstrand described it is what we will do
<Chipaca> fgimenez: mvo: CPI is hitting multi-second response times 3x more than usual, 2x more than usual 5+ seconds responses. This might be impacting at least some of the flakiness we're seeing in tests.
<jdstrand> morphis: this corner case is the only thing that is like this that I'm aware of. that doesn't mean that others won't come up and distros always --disable-seccomp if they choose. I'd like to see how it goes for a while allowing seccomp without LSM before saying we can't support it
<jdstrand> always can*
<morphis> jdstrand: ok
<morphis> Pharaoh_Atem, jdstrand: https://github.com/morphis/snapd/commit/a604e6e94cca5251a1a1ae31907832e023b38fa7
<morphis> does that look ok for you guys? (untested yet)
<jdstrand> morphis: I like the comment (thanks) up until NOTE
<Pharaoh_Atem> looks okay to me...
<Pharaoh_Atem> though I'm not sure why you couldn't just apply it in general?
<jdstrand> morphis: how I see this is that you determine if apparmor is available, then if it isn't, tack this snippet on
<fgimenez> thanks Chipaca, good to know, i'm already seeing the effects in the core validation http://paste.ubuntu.com/24592937/
<jdstrand> morphis: ie, runtime, not compile time
<morphis> jdstrand: it does, it's just meant a distro-patch for the mean time
<jdstrand> morphis: ok, I only see that commit, not the full PR. ping me when you want the PR reviewed
<jdstrand> as that is written though, it clearly is just in the default template rather than appended to the default template based on a runtime check
<jdstrand> pseudo code:
<morphis> jdstrand: right, that is what I will work on next for 2.27
<jdstrand> template = what is there today
<jdstrand> if apparmor not available:
<jdstrand>   append bind and its comment
<morphis> jdstrand: just want to land this patch into fedora/suse now
<jdstrand> ok
<jdstrand> then yes, that is fine as a distro patch
<morphis> jdstrand: thanks
<morphis> Pharaoh_Atem: can you include that tiny patch in the next fedora pkg upload you're doing?
<Pharaoh_Atem> yes
<mvo> zyga: silly question, I'm looking at the dbus branch currently and there is this issue that we want to only allow a single slot with a given dbus path in the entire system, i.e. no two snaps should be able to provide com.example.MyDbus. whats the best way to do this from inside e.g. dbusInterface.SanitizeSlot?
<zyga> mvo: aha, interesting problem
<zyga> mvo: I think that you should allow each interface to contribute whatever it wants
<zyga> mvo: but the backend can detect conflicts
<zyga> mvo: the problem is that at that time it is too late
<zyga> mvo: so this seems to hint that we should allow backends to veto interface connections
<zyga> mvo: then a backend could trivially do the same check (where it matters, it could be a no-op)
<zyga> mvo: and given this the interface may produce a useful error message
<zyga> mvo: func (i *iface) ConnectionConsistency(repo *Repository, plug *Plug, slot *Slot) error
<zyga> mvo: (+ interface attributes perhaps)
<zyga> mvo: this should IMO happen before we even go ask hooks
<zyga> mvo: perhaps both before/after, that is less clear
<Pharaoh_Atem> morphis: this list of snapd paths, what is this relative to?
<morphis> Pharaoh_Atem: /var/lib/snapd
<zyga> mvo: the question still remains, how exactly we'd veto that; is it the backend that does the veto or is it in each interface's responsibility
<zyga> mvo: what do you think?
<zyga> mvo: btw, this is already present in the systemd backend
<zyga> mvo: but we never had to run into the issue
<zyga> mvo: there the backend can simply fail
<zyga> mvo: but nothing would handle that nicely later
<zyga> mvo: maybe try this:
<zyga> mvo: just start with a conflict in the backend
<zyga> mvo: and see what happens
<zyga> mvo: maybe it's "nice" enough
<Pharaoh_Atem> morphis: what is hostfs?
<zyga> Pharaoh_Atem: it's the place where classic distribution filesystem is visible
<zyga> Pharaoh_Atem: I'd call it "classicfs" but that'd be just mean on the word classic
<mvo> zyga: thanks, I check it out
<mup> PR snapcraft#1321 opened: tests: remove the reusable parts tour test <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1321>
<zyga> mvo: the hook problem is going to spin this around
<zyga> mvo: as it means we fail when we told apps that we didn't
<zyga> mvo: but before hooks it is okay
<zyga> mvo: to fail in the backend
<mvo> zyga: ok, looking at this next then
<abeato> mvo, zyga thanks for the quick reviews, https://github.com/snapcore/snapd/pull/3324 ready again for you ;)
<mup> PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324>
<Pharaoh_Atem> what does /var/lib/snapd/device do?
<zyga> Pharaoh_Atem: I think it is where device-specific things go
 * zyga looks
<zyga> Pharaoh_Atem: things like device key and such
 * zyga takes a break
<Pharaoh_Atem> morphis: is /var/lib/snapd/hostfs a directory or a symlink?
<morphis> Pharaoh_Atem: a directory
<morphis> the host / gets bind mounted there
<Pharaoh_Atem> morphis: does the bind mount go away when snapd is stopped?
<morphis> Pharaoh_Atem: its not in the root mount namespace, it will get bind mounted in the mount namespace every snap gets
<morphis> Pharaoh_Atem: so, if I am not wrong, the one one the hostfs gets never used
<morphis> only one from the core snap
<Pharaoh_Atem> okay then
<morphis> Pharaoh_Atem: I would guess we don't even have to create it if we don't use the rpm to include it in a core snap later on
<Pharaoh_Atem> morphis: https://paste.fedoraproject.org/paste/Nl-XU2nzkPUlVLHnnGFw515M1UNdIGYhyRLivL9gydE=
<Pharaoh_Atem> looks good?
<morphis> let me check
<morphis> Pharaoh_Atem: what is with the snap and snaps directories
<morphis> they will have content too
<morphis> I didn't saw them cleaned
<Pharaoh_Atem> those are getting erased already in snap-mgmt
<Pharaoh_Atem> hmm
<morphis> Pharaoh_Atem: can you give this a quick try?
<abeato> ogra_, where are the /boot/* created? Where should I do the change so we get /boot/androidboot ?
<Pharaoh_Atem> hmm, interesting
<abeato> (inside core snap)
<ogra_> abeato, one sec
<abeato> ok
<Pharaoh_Atem> this is a bit tricky because /var/lib/snapd/snap and /var/lib/snapd/snap/bin exist
<pedronis> fgimenez: niemeyer: anothere prepare timeout:  https://travis-ci.org/snapcore/snapd/builds/233253922
<Pharaoh_Atem> and I want to erase them independently :/
<niemeyer> fgimenez: Can we please bump the timing?
<ogra_> abeato, add it there https://github.com/snapcore/core/blob/master/live-build/hooks/16-ensure-bootloaders.chroot ... but you also want the initrd to learnto handle it ... that is here https://github.com/snapcore/core-build/blob/master/initramfs/scripts/ubuntu-core-rootfs#L313
<niemeyer> Lunch, back shortly
<fgimenez> niemeyer: sure i'll prepare a branch, given that we are folding the output in travis we could also remove the "quiet" call here https://travis-ci.org/snapcore/snapd/builds/233253922#L3999 to see where is it hanging
<abeato> ogra_, yes, yes, I know :) Thanks!
<ogra_> :)
<ogra_> sorry for pointing to it every time :)
<abeato> better that than not pointing at it at all :D
<Chipaca> abeato: dunno if you saw you've got failing static tests
<Chipaca> abeato: [...]/partition/androidbootenv/androidbootenv_test.go:42:2: ineffectual assignment to env
<abeato> Chipaca, hmm, I see, thanks for pointing out...
<zyga> mvo: can I trigger a PPA build to get master into edge (eventually?) or will that still interfere with the release?
<zyga> morphis: can you correct https://github.com/snapcore/snapd/pull/3344/files
<mup> PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344>
<morphis> zyga: I am testing that right now
<zyga> morphis: perfect!
<Pharaoh_Atem> morphis: https://paste.fedoraproject.org/paste/SaaKKnO-XBb-0cJvsnAc4V5M1UNdIGYhyRLivL9gydE=
<mup> PR core#44 opened: Add hook for androidboot bootloader <Created by alfonsosanchezbeato> <https://github.com/snapcore/core/pull/44>
<abeato> mvo, ogra_ ^^
<morphis> Pharaoh_Atem: looks good, does it work?
<Pharaoh_Atem> I'm about to find out
<mup> PR snapd#3345 opened: tests: bump kill-timeout and remove quiet call on build <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3345>
<ogra_> abeato, approved ... btw, can i remove the writable-path change ?
<ogra_> (since you now mount a writable partition that shouldnt be needed )
<abeato> ogra_, sure, let me close the PR
<ogra_> thx
<Pharaoh_Atem> morphis: running a scratch build now: https://koji.fedoraproject.org/koji/taskinfo?taskID=19597779
<fgimenez> niemeyer: pedronis snapd#3345 increases the project's kill-timeout to 20m, also removes "quiet" from the command that is actually timing out
<mup> PR snapd#3345: tests: bump kill-timeout and remove quiet call on build <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3345>
<mup> PR core-build#9 closed: Add writable boot for android-boot "bootloader" <Created by alfonsosanchezbeato> <Closed by alfonsosanchezbeato> <https://github.com/snapcore/core-build/pull/9>
<Pharaoh_Atem> morphis: is there a new version of the distrolibexecdir patch for 2.26.1?
<Pharaoh_Atem> it ftbfs with the current one
 * zyga works in an unusual place
<Pharaoh_Atem> zyga: eh?
<zyga> Pharaoh_Atem: I'm sitting on a beach
<zyga> ogra_: is this recipe used? https://code.launchpad.net/~snappy-dev/+recipe/snappy-daily-xenial
<zyga> ogra_: it's ancient and hasn't built since 2016
<zyga> ogra_: I want to rebuild snapd to the image ppa
<ogra_> zyga, ask the owner _P
<zyga> ogra_: but I guess it is built from the vendorized repo
<zyga> ogra_: we're the owners
<ogra_> it uses https://code.launchpad.net/~snappy-dev/snappy/trunk-github
<ogra_> and the owner seems to be sergio
<zyga> the url says the owner is snapp-dev
<ogra_> zyga, yes, but thats moot ... it was createrd by sergio, no idea for what etc ... ask him
<morphis> Pharaoh_Atem: there is, just take the current PR
<ogra_> zyga, the daily edge build of snapd is handled by elopio iirc
<morphis> Pharaoh_Atem: 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> elopio: ^^
<zyga> elopio: do you handle the daily snapd -> ppa build?
<zyga> the build process is so messy
<ogra_> zyga, whatever that thing builds is called "ubuntu-snappy" ... "dpkg-source -i -I --before-build ubuntu-snappy-1.7.2+20160204ubuntu1" ... (from the build log of that receipe)
<Pharaoh_Atem> morphis: new scratch build run: https://koji.fedoraproject.org/koji/taskinfo?taskID=19597955
<fgimenez> zyga: we have a spread-cron branch for that, after each merge + green build on master we update snapd-vendor on launchpad and trigger a build https://github.com/snapcore/spread-cron/blob/snapd-vendor-sync/target/tasks/snapd-vendor-sync/task.yaml
<zyga> fgimenez: can you trigger that manually now
<fgimenez> zyga: sure 1sec
<ogra_> zyga, also https://launchpad.net/~snappy-dev/+archive/ubuntu/edge?field.series_filter=xenial ... seems the last build was 2h ago
<ogra_> do you need anything newer ?
<fgimenez> ogra_: zyga yes, no longer daily
<ogra_> yep
<Pharaoh_Atem> morphis: patch does not apply
<ogra_> since quite a while already IIRC
<Pharaoh_Atem> morphis: https://kojipkgs.fedoraproject.org//work/tasks/7958/19597958/build.log
<zyga> ogra_: hmmm
<zyga> ogra_: I was under the impression that we only use one ppa during builds, the image ppa
<ogra_> zyga, ?
<zyga> ogra_: I think at this stage we should have a post that describes how this all works
<zyga> ogra_: I thought we use https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<ogra_> zyga, both PPAs are always enabled ... before doing a release a snapd with higher version gets uploaded to the image PPA ... that supersedes edge
<zyga> aha
<zyga> ogra_: thank you
<ogra_> (you did that plenty of times already ... why do you need it documented now)
<zyga> ogra_: I never realized this is how it works
<zyga> ogra_: or I forgot since
<ogra_> ah, k :)
<zyga> ogra_: I think cleaning the ppas will make it more obvious as there will be less moving pieces
<zyga> (or potentially moving)
<zyga> ogra_: thanks!
<zyga> ogra_: I want the core snap with master snapd to play with update-ns
<ogra_> ah, right, then the release got in your way i guess
<zyga> yes
<zyga> this is why I started the topic of how things are made in the first place
<mvo> zyga, ogra_: new edge deb is there and I triggered a build so you should have a new snapd edge in ~30min
<ogra_> thx!
<zyga> mvo: thank you sir :)
<ogra_> wow
<ogra_> if you mess up the oser creation in a kvm image bad things happen
<ogra_> *user
<mvo> but +1 for actually documenting it, its relatively straghtfoward *once* used to it
 * ogra_ shakes fist at shadow
<ogra_> (and higs mvo for fixing it)
<ogra_> *hugs even
<mvo> ogra_: heh, was wondering what about it, hopefully not another security upload
<ogra_> insecure crap ... always these CVEs!
<zyga> mvo: I was thinking about one thing
<Pharaoh_Atem> morphis: I'm disabling this patch and seeing if I can build without it
<Pharaoh_Atem> morphis: https://koji.fedoraproject.org/koji/taskinfo?taskID=19598084
<Pharaoh_Atem> we don't do unit testing yet anyway...
<zyga> mvo: about passing some compile time choices as variables from snapd to snap-confine
<zyga> mvo: this would allow us to enable reexec nearly everywhere where we can run unpatched master
<zyga> mvo: a single file in /var/lib/snapd/ say snap-confine.cfg
<zyga> mvo: key=value
<zyga> mvo: we'd pass a handful of things, mostly like force-devmode, snap-mount-dir and maybe something I'm not thinking about yet
<zyga> mvo: we could make it per security tag to also convey things like --classic without having snap-run care
<zyga> mvo: and we could finally fix the missing link between snap-run and snapd, snapd simply would write the new .cfg file
<zyga> mvo: (I recall that we had issues where snap run doesn't know something changed already and we kind of ignored it for now)
<zyga> mvo: so that snap-run doesn't have to wake anything up
<mup> PR core#44 closed: Add hook for androidboot bootloader <Created by alfonsosanchezbeato> <Merged by ogra1> <https://github.com/snapcore/core/pull/44>
<mvo> zyga: yeah, I think we want to close this gap, maybe a forum post to discuss things?
<mvo> zyga: I will leave for dinner soon
<zyga> mvo: yes, sounds good, I'll write something onw
<mvo> ta
<zyga> mvo: done https://forum.snapcraft.io/t/closing-the-gap-in-snap-confine-snapd-communication/665
<zyga> morphis, jdstrand ^
<zyga> me has another core snap, again with 2.26.3
<zyga> :-(
 * zyga doesn't understand how this work
<zyga> ks
<zyga> ogra_: what is snappy devices ppa? https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-devices
 * ogra_ highly dounbts zyga's sense for "better" 
<zyga> some things are 2017is
<zyga> ogra_: my sense for better is doing very good ;-)
<ogra_> zyga, thats for the signed customer kernels for secureboot
<zyga> ogra_: aah
<ogra_> ignore it :)
<zyga> ogra_: can I document it?
<mvo> zyga: meh, the edge ppa still has 2.26.2 not .3
<zyga> mvo: on the upside, my modem needs to download only deltas
<zyga> ogra_: I edited the description on https://launchpad.net/~snappy-dev/+archive/ubuntu/snappy-devices
<ogra_> zyga, looks fine
<mup> PR snapd#3345 closed: tests: bump kill-timeout and remove quiet call on build <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3345>
<fgimenez> mvo: we can trigger an execution of spread-cron's sync by pushing to snapcore/spread-cron in the snapd-vendor-sync branch (this is done automatically after detecting a new merge + green build on snapcore/snapd's master)
<fgimenez> probably the flakiness of the tests made that this wasn't executed for a while (the "+ green build" part wasn't happenning)
<ogra_> mvo, https://forum.snapcraft.io/t/bug-running-mir-kiosk-apps/657 might be a release blocker ...
<zyga> fgimenez: aha
<zyga> ogra_: yes, I was thinking about it
<zyga> it stopped working in beta because beta was updated
<ogra_> mvo, seems edge and beta are broken ...
<zyga> and it smells like netlink
<ogra_> we should really have a log message for the netlink stuff :(
<ogra_> not sure how to strace the kiosk apps to get valuable info
<zyga> I think we do
<zyga> it's a seccomp kill
<zyga> HUZZAH and SIGKILL
<ogra_> well, we dont get it in the logs
<zyga> then it's not occuring
<fgimenez> zyga: mvo if you need it i can push a commit to trigger the build, let me know
<ogra_> http://paste.ubuntu.com/24592960/
<ogra_> the issue starts at line 164
<zyga> fgimenez: if you can, please
<ogra_> which is a simple dlopen that fails for whastever reason
<zyga> and we really need to fix master == edge && beta == whatever mvo promoted distinction
 * zyga looks
<zyga> well
<zyga> no details why
<zyga> useless error :/
<robinhood2017> Hi, I'm just getting started with developing snap packages. I attempted to push my Hello World app (by entering 'snapcraft push hello-[username removed]_2.10_amd64.snap --release=candidate'), but I get the error message saying "The store was unable to accept this snap: You do not have access to modify this package."
<zyga> "I cannot do that Dave"
<ogra_> zyga, there are snapctl complaints above though
<jdstrand> snap.mir-kiosk-apps.mir-kiosk-app-daemon.service: Main process exited, code=exited, status=1/FAILURE
<jdstrand> that is not a KILL
<ogra_> zyga, ipv6 related it seems
<zyga> robinhood2017: did you snapcraft register that name?
 * jdstrand notes that mir interface was updated for netlink
<robinhood2017> Yes, I did "snapcraft register hello-robinhood2017" beforehand.
<zyga> ogra_: the denials are harmless
<zyga> (that's apparmor)
<ogra_> jdstrand, well, check the paste above ... line 148-153
<zyga> jdstrand: aha, still with no seccomp I think my netlink idea was wrong
<ogra_> zyga, harmless ? ... ok
<zyga> ogra_: that's snapctl, harmless
<ogra_> ok
<ogra_> well, then it boils down to dlopen again
<jdstrand> ogra_: the 148-153 is the normal snapctl denials and unrelated to this
 * zyga would love a call to dlerror
<ogra_> jdstrand, yeah, zyga said so
<ogra_> http://bazaar.launchpad.net/~phablet-team/platform-api/trunk/view/head:/src/ubuntu/application/base_module.h#L113
<ogra_> thats the code that loads the module
<jdstrand> it feels to my like something with the mount namespace
<zyga> yes, missing dleerr
<zyga> dlerror
<zyga> jdstrand: perhaps
<zyga> jdstrand: but what might it be...
<zyga> very little changes
<jdstrand> like, mir-libs isn't mounted
<zyga> jdstrand: mmmmm,
<zyga> maybe
<ogra_> the script has checks for that
<zyga> ogra_: do you have a reproducer?
<ogra_> see line 26 of http://paste.ubuntu.com/24593625/
<ogra_> zyga, install mir-libs, mir-kiosk and mir-kiosk-apps ... thats all i have
<zyga> ogra_: on x86-64?
<zyga> ogra_: I don't have a VM handy
<ogra_> zyga, mir-kiosk starts fine (you get a black screen with mouse cursor)
<ogra_> but the apps cant
<zyga> ogra_: ok, can you look at /var/lib/snapd/mount
<zyga> ogra_: and tell me what you see in any of the files there
<robinhood2017> So if I've registered the name, and it's still giving me that error, what's next?
<jdstrand> zyga: I'm not saying it is that. it just kinda feels like it
<zyga> jdstrand: yes
<jdstrand> oh
<ogra_> ogra@pi3:~$ ls /var/lib/snapd/mount
<ogra_> snap.mir-kiosk-apps.fstab                 snap.mir-kiosk-apps.mir-kiosk-app-daemon.fstab  snap.mir-kiosk.hook.configure.fstab
<ogra_> snap.mir-kiosk-apps.hook.configure.fstab  snap.mir-kiosk.fstab                            snap.mir-kiosk.mir-kiosk.fstab
<zyga> jdstrand: would certainly be easiest issue :)
<zyga> ogra_: look at the one that fails to start please
<zyga> jdstrand: well
<zyga> ogra_: well, at the snap that fails to start
<zyga> I need to stop writing per-app profiles
<zyga> those are not used anywhere
<ogra_> /snap/mir-libs/28/mirlibs0/usr/lib /snap/mir-kiosk-apps/16/mir-libs none bind,ro 0 0
<ogra_> thats the content
<jdstrand> there was one other thing. I remember when looking at kiosk I could get it to run once, then on subsequent runs I had to remove ~/snap/<snap name>
<zyga> ogra_: ok, can you now do this:
<jdstrand> that was unclear
<zyga> ogra_: sudo nsenter -m/run/snapd/ns/mir-kiosk-apps.mnt
<jdstrand> the app snap talking to mir, I could run it once, but then after I needed to clear out its user data
<ogra_> zyga, done
<fgimenez> zyga: the job is triggered https://travis-ci.org/snapcore/spread-cron/branches, snapd-vendor-sync branch, now with the latest edge core things are a bit busy :)
<zyga> ogra_: then look at /snap/mir-kiosk-apps/16/mir-libs
<ogra_> i'm groot!
<ogra_> err
<ogra_> root
<zyga> fgimenez: thank you! :)
<zyga> ogra_: groot :D
<zyga> ogra_: is there anything there?
<jdstrand> this was with webbrowser-app though, so I was thinking this was something weird in the qt stuff, but maybe it is something with mirlibs
<ogra_> zyga, yes, but not sure if it is actualyl the right stuff
<ogra_> gimem a bit
<zyga> ogra_: ls
<ogra_> *gimme
<ogra_> zyga, 12847523478 files :P
<zyga> ogra_: !!!!?!??!?!
<zyga> seriously?
<ogra_> root@pi3:/# find /snap/mir-kiosk-apps/16/ -name '*libubuntu_application_api_test*'
<ogra_> /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3
<ogra_> /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf/libubuntu_application_api_test.so.3.0.0
<ogra_> theer we go
<zyga> ogra_: ok, now do this
<ogra_>  oh
<ogra_> wait!
<zyga> ogra_: run cat /proc/self/mountinfo
<zyga> and tell me if there's a bind mount in that directory
<zyga> what's going on?
<ogra_> root@pi3:/# find /snap/mir-kiosk-apps/16/mir-libs/arm-linux-gnueabihf/ -name '*libubuntu_application_api_test*'
<ogra_> root@pi3:/#
<ogra_> it is not in the shared dir i think
<zyga> ogra_: so are snaps broken?
<zyga> ogra_: or is snapd broken?
<zyga> ogra_: which version of snapd is this?
<ogra_> .3
<zyga> aha
<ogra_> the most recent one
<zyga> so pre update-ns
<zyga> well, not maste R:)
<ogra_> but .2 had it too if i can judge by the "broken in edge since a few days"
<zyga> can you run /usr/lib/snapd/update-ns $SNAP_NAME (from outside the mount namespace) to confirm it says "Not implemented" or something ike that
<ogra_> zyga, theory:
 * zyga listens
<ogra_> mir-kiosk-apps ships the lib in  /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf ... but new snapd binmounts mir-libs one level above
<ogra_> *bind
<ogra_> so the shipped lib from the snap itself is gone
<ogra_> and mir-libs doesnt ship it
<ogra_> s/gone/hidden/
<zyga> ogra_: we just bind mount what the .fstab file says
<zyga> aha
<zyga> maybe the snap changed
<zyga> can you look at /snap/$SNAP_NAME/current/meta/snap.yaml
<ogra_> http://paste.ubuntu.com/24593671/
 * zyga looks
<ogra_> it seems to lose $SNAP/usr/lib/$ARCH from its library path somehow
<zyga> ogra_: maybe environment handling broke?
<ogra_> and uses $SNAP/mir-libs/$ARCH instead
<ogra_> which comes from the interface
<zyga> ogra_: the snap mount profile looks correct
<zyga> ogra_: cna you please: cat /proc/self/mountinfo | grep mir-libs
<zyga> ogra_: (from the mount namespace)
<zyga> ogra_: I just want to ensure that is mounted
<zyga> ogra_: and we're not chasing ghosts
<ogra_> http://paste.ubuntu.com/24593685/
<ogra_> the last line seems to be the one we use ...
<zyga> looks OK
<ogra_> yeah
<zyga> yes
<ogra_> does the mounting somehow mangle LD_LIBRARY_PATH ?
<zyga> no
<zyga> it's not related in any way
<zyga> ogra_: one more idea
<zyga> run: snap run --shell snapname.appname
<zyga> and inspect environment
<zyga> environment
<ogra_> hmm, does that work with daemons ?
<zyga> ogra_: it does, it runs shell instead
<zyga> ogra_: using the same confinement/environment
<ogra_> k, let me try
<zyga> ogra_: also look at the launcher wrappers from snapcraft, they used to touch environment
<ogra_> http://paste.ubuntu.com/24593692/
<morphis> zyga: thanks!
<ogra_> no LD_LIBRARY_PATH at all ...
 * ogra_ checks rteh wrapper
<zyga> ogra_: interesting
 * zyga checks if snapd sets it
<ogra_> http://paste.ubuntu.com/24593700/
<ogra_> wrapper
<ogra_> it sets a bunch
<zyga> ogra_: snapd doesn't set it, it's purely under snap/snapcraft contorl
<ogra_> right
<zyga> ok, that wrapper doesn't run in --shell
<zyga> no idea
 * zyga is underground
<ogra_> so how does an app get the one from the namespace mount onto LD_LIBRARY_PATH ?
<morphis> zyga: can you check https://github.com/snapcore/snapd/pull/3344/files again?
<mup> PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344>
<zyga> ogra_: I cannot parse that question
<ogra_> something needs to add it there when the mount occurs ... is that snap-confine ?
<zyga> ogra_: no, it's a hard-coded thing in the wrapper
<zyga> ogra_: snap-confine doesn't care what is being mounted
<ogra_> zyga, when you mount a shared lib space via a content interface nothing adds the new lib space dynamically ?
<ogra_> (to the env that is)
<ogra_> it somehow needs to end up in LD_LIBRARY_PATH
<zyga> yes
<zyga> it is impossible BTW
<zyga> it has to be predicted by the snap and just added unconditionally
<ogra_> well, it used to work ... now it doesnt :) ...
<morphis> zyga: thanks
<ogra_> so something changed
<ogra_> and that wasnt the snap
<ogra_> (last upload was in feb)
<morphis> zyga: but don't merge yet, still need to fix my spread tests with that
<zyga> morphis: it's still wrong :)
<ogra_> might be that the snap did it wrong before ... but it definitely used to work
<zyga> morphis: commented
<zyga> ogra_: hmm
<zyga> ogra_: I'll check
<morphis> zyga: only see "Just one trivial"
<zyga> morphis: yeah, my connection died, I just commented again
<morphis> zyga: ah that is what I wanted to ask
<morphis> zyga: pushed again
<zyga> done
<ogra_> i added an "env" call to the daemon script ... http://paste.ubuntu.com/24593758/
<zyga> ogra_: we never set LD_LIBRARY_PATH according to git grep
<ogra_> and i see /snap/mir-kiosk-apps/16/usr/lib/arm-linux-gnueabihf as well as /snap/mir-kiosk-apps/16/mir-libs/arm-linux-gnueabihf
<ogra_> in LD_LIBRARY_PATH
<zyga> so
<zyga> maybe dlopen works
<zyga> but without dlerror
<zyga> ...
<ogra_> no, doesnt start
<zyga> we're just guessing
<zyga> er, s/dlopen/mount/
<ogra_> zyga, well ask for it to be added :)
<zyga> ogra_: look at the forum
<ogra_> zyga, yeah, got the same as ping in #ubuntu-mir
<zyga> mvo: don't look
<ogra_> now ... why did that get removed
<zyga> mvo: I forsee 2.23.4
<ogra_> i dont
<zyga> mvo: er, 2.26.4
<zyga> more core builds (with same snapd)
<ogra_> right
<ogra_> unless libjson was a dep of snapd
<zyga> maybe
<zyga> still :/
<zyga> we cannot remove anything
<ogra_> zyga, we have no influencve on that ... if a package drops a dependency it is gone and we need to retroactively adjust
<zyga> ogra_: yes, we need better tooling
<zyga> ogra_: core ABI traces
<zyga> ogra_: and tests that ensure we don't break ABIs
<ogra_> we have manifest files
<zyga> ogra_: we are missing testss
<zyga> *tests
<zyga> we need a 2nd review for https://github.com/snapcore/snapd/pull/3344
<mup> PR snapd#3344: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <https://github.com/snapcore/snapd/pull/3344>
<zyga> perhaps Chipaca or jdstrand can have a look, just a few lines of diff
<ogra_> zyga, so libjson-c2 was pulled in by rsyslog before ...
<jdstrand> I reviewed it
<zyga> aha
<zyga> ogra_: nice find
<zyga> ogra_: can you add this to this thread?
<zyga> thanks jdstrand !
<ogra_> zyga, in the light that we do not guarantee anything bug /bin/sh and libc the fact that the snap depends on something inside core is wrong though ... i'll seed it for now but the snap is broken IMHO
<ogra_> s/bug/but/
<zyga> ogra_: in principle I agree but I think we need to be pragmatic
<zyga> Chipaca: I edited https://github.com/snapcore/snapd/pull/3342 - please keep nicer messages as those end up in changelogs and such
<mup> PR snapd#3342: many: refactor in preparation for 'snap start' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342>
<zyga> morphis: make fmt
<morphis> zyga: yeah, saw that
<morphis> these formattign rules are nasty :-)
<zyga> morphis: https://imgflip.com/i/1p7lz6
<zyga> morphis: I have something nicer brewing towards that end
<ogra_> mvo, zyga http://paste.ubuntu.com/24593840/ can i get an ACK for this ?
<zyga> ogra_: ''
<morphis> zyga: need a pre-commit hook for that :-)
<Saviq> hey all, if I've a part (app) that builds against another part (library) in that same snapcraft.yaml, what's a good way of pointing the app at the library? ../parts/library/install/...?
<nacc> Saviq: you mean you need build-time linkage?
<Saviq> nacc, yes
<ogra_> niemeyer, i assume an opinion of a director/architect might come in handy here https://forum.snapcraft.io/t/bug-running-mir-kiosk-apps/657
<ogra_> if you dont mind
<Saviq> nacc, something along the lines of PKG_CONFIG_PATH=$SNAPCRAFT_STAGE..., but I just notice PKG_CONFIG_PATH is already set up to include the stage...
<nacc> Saviq: i would think that would 'just work', put your library in a part, make your app be a part that is 'after' the library part
<Saviq> yeah I think my "after: " was wrong
<nacc> Saviq: or at least, it's explicitly mentioned as the uses case for after on https://snapcraft.io/docs/build-snaps/parts :)
<Saviq> nacc, yeah I think PEBKAC
<Chipaca> zyga: github uses the first line of the commit message as the title; my commit message was quite a bit longer
<nacc> Saviq: happens to me all the time :)
<zyga> Chipaca: well, commit messages have rules :)
<elfgoh> ogra_, any idea if there are updates on this thread? https://lists.ubuntu.com/archives/snapcraft/2017-April/003774.html
<zyga> Chipaca: first line is shorter (afair 60-something) then newline, then anything
<Chipaca> zyga: where are these rules? this is news to me
<elfgoh> Am trying to figure out where to get started on using GPIOs on a raspberry pi 3
<ogra_> elfgoh, you use the exposed gpio interfaces
<ogra_> look at snap interfaces
<ogra_> elfgoh, this didnt make it to the stable channel though since the pi3 gadgets can not be upgraded there and the interface comes from the gadget
<niemeyer> ogra_: Looking
<ogra_> thanks
<elfgoh> ogra_: so which channel is the change in now? I do have the flexibility to not use the stable channel for now
<ogra_> elfgoh, should be in all channels but stable
<elfgoh> And any rough non binding forecast on when the change will be in stable?
<ogra_> elfgoh, whenever upgradeable gadgets exist for the pi ... no idea
<zyga> Chipaca: one sec
<zyga> Chipaca: https://chris.beams.io/posts/git-commit/
<zyga> Chipaca: (quick google)
<zyga> Chipaca: http://stackoverflow.com/questions/2290016/git-commit-messages-50-72-formatting
<zyga> Chipaca: there are plenty of things like this
<ogra_> afaik it was discussed at the last planning sprint how to handle such upgrades, but i wasnt there and havent seen any docs with details for this issue
<elfgoh> ogra: who/what decides that? Canonical?
<zyga> Chipaca: frankly we as a team are utterly terrible at those
<ogra_> elfgoh, currently it is a technical limitation and needs to be implemented ... upgrading bootloaders is risky so its not an easy or small task ... it will happen but is a matter of time
<zyga> ogra_: I would love to know when someone will start working on this
<morphis> zyga: ok, that PR is good to go, there is a problem with my restore setup
<zyga> ogra_: are you planning to?
<zyga> morphis: OK
 * zyga looks again
<elfgoh> ogra: so means the upgrading of bootloaders is in all channels but no stable, due to the risk?
<ogra_> zyga, on what ? gadget upgrades ?
<Chipaca> zyga: most of the log messages i see are "merge pull request #yadda from foo/barbaz"
<zyga> Chipaca: yes, that too (because rebase policy)
<zyga> Chipaca: honestly looking at our history is next-to-useless but I really think it's a shame and we could do better
<zyga> ogra_: yes
<Chipaca> zyga: i suggest opening a topic and having a discussion about it, then
<zyga> ogra_: not sure if we have design on that
<Chipaca> zyga: as it stands I'm not clear what it is exactly that you're wanting us to improve
<zyga> Chipaca: well
<zyga> Chipaca: two things
<zyga> Chipaca: the lines cannot be this long
<ogra_> zyga, right, we dont ... i was expecting some design to have come out of the planning sprint
<zyga> Chipaca: they are way way too long usually
<zyga> Chipaca: and they are not scoped
<zyga> Chipaca: the rest is usually empty but I think it really should be different
<Chipaca> zyga: "too long" and "not scoped" seem to contradict each otehr
<zyga> Chipaca: (scope == many: ....)
<zyga> Chipaca: under 50 chars
<Chipaca> exactly, but scope can easily eat up more than that
<zyga> Chipaca: it should not, usually it is very short (just directory name of 1/2nd level)
<zyga> I think it's easy to use common sense
<Chipaca> zyga: I mean
<Chipaca> zyga: if the criteria is "--oneline needs to look good"
<Chipaca> zyga: that is very different from "you need to understand what the commit is about"
<Chipaca> I thought we wanted the latter
<zyga> Chipaca: you want both actually
<zyga> Chipaca: and it's not hard
<zyga> Chipaca: one line summary, scope and short facts, + newline + poem of any size
<jdstrand> ogra_: have you observed the behavior of /var/log/syslog in edge?
<jdstrand> ogra_: claims a size of 2M but reads just hang
<jdstrand> ogra_: stat /var/log/syslog too
<jdstrand> ogra_: cp...
<ogra_> jdstrand, i dont have that file on my current edge images anymore
<Chipaca> zyga: that's a nice article, the first one you linked
<Chipaca> anyway, i need to go make dinner
<Chipaca> o/
<jdstrand> ogra_: core          16-2.26.3    1962  canonical  -
<ogra_> jdstrand, where do yiou get it from ?
<jdstrand> ogra_: this is an upgrade
<ogra_> nothing should create it anymore
<jdstrand> snap refresh core --edge
<ogra_> so its an old file you have lying around
<ogra_> not much we can do about that i fear
<jdstrand> I don't know how it is there. I can't read it or do anything with it, yet, ls -l shows it
<jdstrand> $ ls -l /var/log/syslog
<jdstrand> -rw-r----- 1 syslog adm 1950368 May 17 09:53 /var/log/syslog
<ogra_> ogra@pi3:~$ ls /snap/core/current/var/log/|grep syslog
<ogra_> ogra@pi3:~$
<jdstrand> ogra_: that's a confusing bug that will trip up applications. they can't decide to read the journal or that file for example because the file exists
<jdstrand> if they try to read, it'll just hang
<ogra_> it definitely doesnt exist on fresh installs ... i'm not really sure what to do regarding upgrades where that file was created before but i wouldnt expect it to be any different than before we removed rsyslog
<ogra_> it just doesnt get filled up
<jdstrand> ogra_: why can't that file be removed on upgrade? or zeroed out, or something
<ogra_> do we have upgrade hooks that i dont know about ?
<jdstrand> ogra_: it is different, that is why I am talking to you. I expected it to either not be there, or be whatever it was before and unchanging
<jdstrand> :)
<ogra_> yes, me too
<ogra_> its just a text file after all
<ogra_> just that nothing writes to it anymore
<ogra_> permissions or anything didnt change
<jdstrand> ogra_: maybe it is journald
<ogra_> and it was never readable by anyone but root anyway
<ogra_> i dont think journalds cares about syslog
<jdstrand> that shouldn't be it...
<jdstrand> ogra_: oh, another issue:
<jdstrand> $ find /etc/systemd -name "*rsyslog*"
<jdstrand> /etc/systemd/system/multi-user.target.wants/rsyslog.service
<ogra_> ouch
<ogra_> juts dangling though
<jdstrand> that a dangling symlink
<ogra_> but ugly ...
<jdstrand> yeah
<ogra_> mind filing a bug for that ... i'm not sure what we can do there though without upgrade hooks
<ogra_> (apart from ugly hacks)
<jdstrand> there is something weird going on with this vm
<ogra_> anyway ... i need to stop now GF starts looking angry that i work so late today
<jdstrand> I can't remove that file
<ogra_> ogra@pi3:~$ sudo rm /etc/systemd/system/multi-user.target.wants/rsyslog.service
<ogra_> ogra@pi3:~$
<ogra_> works fine on my pi3
<ogra_> i wonder if your syslog issue is also caused by this
<jdstrand> that's what I'm wondering
<jdstrand> ogra_: ok, see you later
<jdstrand> ogra_: fyi, https://bugs.launchpad.net/snapd/+bug/1691525
<mup> Bug #1691525: dangling symlink /etc/systemd/system/multi-user.target.wants/rsyslog.service <snapd:New> <https://launchpad.net/bugs/1691525>
<pedronis> mvo: I now added a spread test to the default config PR
 * zyga calls it a day
<zyga> core is not ready as a snap
<ogra_> zyga, next build will be though
<zyga> ogra_: yes but 20:20 is the time for kids and books; :-)
<ogra_> +1
<ogra_> (or TV ... )
<zyga> I have a TV but I think it will stay in spain
<zyga> too big to move back
<zyga> not worth it (old)
<zyga> not CRT-old though
<zyga> and TV has only one use anyway, to plug to PS4 :)
<zyga> youtube/netflix/some games
<ogra_> you will need a good spy-glass if you want to watch TV then though ... spain is quite a bit from poland
<ogra_> :P
<zyga> ogra_: but we have big-brother TVs you know ;)
<ogra_> hehe
<zyga> maybe I should become a politician
<zyga> "I'm not nuts and far-right religious extremist!"
<zyga> but nobody votes for that
<ogra_> yeah, not where you are going at least
<zyga> yeah
<ogra_> compe to germany instead ;)
<ogra_> *come
<ogra_> (not the east part though ... there you also need to be fascist to be politican)
<zyga> i can live at the border, i can be both then ;)
<ogra_> hah
<jdstrand> ogra_: fyi, it seems that vm was messed up. I created a new one from stable and refreshed to edge and I can cat /var/log/syslog. it is unchanging
<kyrofa> Do we have any real documentation on tracks?
<Saviq> kalikiana, hey, any idea about http://pastebin.ubuntu.com/24594439/ when trying to use project containers?
 * Saviq on lxd+ZFS, I suppose that matters
<davidcalle> kyrofa: anything missing from https://snapcraft.io/docs/reference/channels on the topic?
<Saviq> I can launch via `lxc launch...` no problem
<kyrofa> davidcalle, ah ha! I was looking in Build snaps
<kyrofa> I should trust you more. You're always on top of things
<davidcalle> kyrofa: I wish! :D
<kyrofa> davidcalle, good docs. A question I'm left with, though, is: by default, it seems I have one track, `latest`. Once I start creating tracks, what is latest pointing to?
<kyrofa> Can I change it? And I assume people using latest change with it?
<kyrofa> Or is `latest` still its own thing, a track to which I must release separately?
<Facu> kyrofa, "latest" is always the default, the one used when you don't specify one
<Facu> right, you need to release to latest separately
<Facu> kyrofa, everybody start with "latest", so let's suppose you cut 5.10 of your project, at that point you'd have "5.10" track and latest (with latest stuff)
<kyrofa> Facu, and it 5.10 IS latest, I release into both?
<kyrofa> s/it/if/
<kyrofa> cjwatson, does launchpad support releasing into multiple tracks? (it seems not)
<Facu> kyrofa, if 5.10 is latest, you don't need to request a track for it, just use latest
<Facu> kyrofa, there's no need to use a track, if you're ok with latest
<mup> PR snapcraft#1321 closed: tests: remove the reusable parts tour test <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1321>
<kyrofa> Facu, then there's no way for my users to say "I only want to stay on 5.x"
<kyrofa> Right?
<noise][> kyrofa: you would at some point before moving beyond 5.x, cut a 5.x branch and message users to move to it if they want to stay on 5.x
<noise][> and give enough time before dropping a 6.x onto latest or whatever
<Facu> kyrofa, mmm... if you want users to say "I want to stay on 5.x" but currently 5.x is the ONLY thing you have... then you'd need to create a track, yes; you still would have "latest", but as 5.x is the only thing you have, no need for releases into latest
<kyrofa> Facu, but then there's no way for users to say "I'm happy to roll to 6.x when it's out" :P
<kyrofa> Facu, this is all academic anyway, I'm just giving you a hard time. Thanks for answering my questions!
<Facu> kyrofa, not sure if I understand that question or use case
<Facu> kyrofa, in any case there's no automatic switch between tracks
<kyrofa> Indeed: if one wanted such a thing, they would need to be tracking `latest`, right?
<Facu> kyrofa, right
<kyrofa> davidcalle, perhaps you should note that in your recommendation: "Eg. when you release the 2.0 version of your software in the latest track, open a track called 2.0 for users wanting to stay on 2.0 and subsequent 2.* releases."
<kyrofa> You'll need to release to both the 2.0 track _and_ latest
<mup> PR snapcraft#1317 closed: recording: save the details of the source pulled <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1317>
<kyrofa> And it seems that LP won't work with the workflow you're suggesting
<mup> Bug #1638334 changed: snap install not properly generating ConnectedSlot policy when auto-connecting via snap-declaration-allowed connection <personal> <snapd-interface> <Canonical System Image:Fix Released by kgunn72> <Snappy:Fix Released by albaguirre> <https://launchpad.net/bugs/1638334>
<cjwatson> kyrofa: not at the moment, though it ought to be possible to add if we can work out a reasonable UI (maybe just space-separated tracks in that input box I guess)
<cjwatson> kyrofa: it's just a UI issue though - you can set snap.store_channels over the API, in which case you could set it to ['2.0/edge', 'latest/edge'] or something
<kyrofa> cjwatson, good to know, thank you!
<cjwatson> kyrofa: (I don't recall what the UI will do when it tries to display that)
<CantaloupMelon> I think I have a quick question: Why would my snap not auto connect to plugs? I have them listed under each app, as plugs: [network, network-bind, etc]
<kyrofa> CantaloupMelon, some plugs don't auto-connect as they can be a bit dangerous
<kyrofa> CantaloupMelon, but network and network-bind should auto-connect fine
<CantaloupMelon> I also have home for a few as well
<kyrofa> That one should also be automatically connected these days
<CantaloupMelon> when I do a snap interfaces (after a snap try) they're not connected, and if I do it manually after the fact everything is great
<kyrofa> CantaloupMelon, none of them? Not even the network ones?
<CantaloupMelon> no, none.
<kyrofa> That doesn't seem right. Have you tried actually installing the snap? Does the same thing happen, or is it specific to tried snaps?
<CantaloupMelon> Also strangely one VM I could do a snap connect foo:network :network and it worked fine, but not in this other VM running ubuntu 16.10
<CantaloupMelon> kyrofa: happened on installed ones too
<kyrofa> CantaloupMelon, only in 16.10, though?
<CantaloupMelon> well, I did a fresh VM cause what I was doing wasn't compiling under my original VM Ubuntu 16.04. maybe I forgot to install something
<CantaloupMelon> or update?
<kyrofa> CantaloupMelon, jdstrand or zyga might have ideas for you... I'm not sure why interfaces wouldn't be auto-connecting on 16.10
<CantaloupMelon> at least I'm not going nuts, I figured it should work
<kyrofa> CantaloupMelon, agreed, I figure it should work as well
<mup> PR snapcraft#1322 opened: state: ignore the 'any' architecture in the build packages apt cache <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1322>
<mup> PR snapcraft#1323 opened:  state: search for the build package that provides a virtual package <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1323>
#snappy 2017-05-18
<mup> PR snapd#3344 closed: cmd/snap-confine: use SNAP_MOUNT_DIR to setup /snap inside the confinement env <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3344>
<morphis> mvo: thanks!
<mvo> morphis: thank you, that was a really useful fix!
<morphis> :-)
<mvo> morphis: want a hand with 3307? I can apply the simplifications if you want, otherwise the branch looks good so I'm keen to get it in soon(ish)
<morphis> mvo: ah you approved it, was waiting for another review to get this further before I rework this
<morphis> mvo: let me do that now
<mvo> ta
<morphis> mvo: pushed
<morphis> mvo: while we're on it, what are we doing now with https://github.com/snapcore/snapd/pull/3308
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<morphis> mvo: I will work on getting it through the tests today but would like to have a final agreement on how we implement this
<zyga> good morning
<mvo> morphis: looking again
<morphis> zyga: morning!
<morphis> zyga: I would like to get to an agreement for https://github.com/snapcore/snapd/pull/3308
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<morphis> zyga, mvo: maybe we can quickly discuss anything left here
<zyga> morphis: sounds good
<zyga> morphis: I think I made my statement, I will respect whatever mvo decides
<zyga> and if it doesn't work down the line (whatever we choose), it's just a commit away to change :)
<morphis> true :-)
<mup> PR snapd#3346 opened: [WIP] allow access to nm-dispatcher scripts <Created by felicianotech> <https://github.com/snapcore/snapd/pull/3346>
<mvo> zyga: I added another comment, but I agree, I think we just move forward we can always revisit the decision
<zyga> ok, let's merge it then
<morphis> mvo, zyga: thanks!
<morphis> anymore real code-review comments?
<zyga> morphis: I just had a look but I think that's all for now
<morphis> zyga: ok, then let me see that tests are passing
<morphis> mvo, zyga: https://github.com/snapcore/snapd/pull/3337 can have another review too
<mup> PR snapd#3337: errtracker: try multiple paths to read machine-id <Created by morphis> <https://github.com/snapcore/snapd/pull/3337>
<abeato> zyga, hi, what is this system-shutdown command for? when is it used?
<mvo> abeato: it used internally to ensure everything can be unmounted on shutdown
<zyga> abeato: it's used on shutdown of a core system, it exists because systemd cannot by itself untagle the mount situation
<mvo> zyga: snap :)
<zyga> :D
<abeato> zyga, hmm, so it is called by the shutdown/reboot command?
<zyga> abeato: not really, it is called by systemd from initrd on shutdown
<zyga> abeato: why?
<abeato> zyga, I need to do some changes to how we reboot on core/kernel updates. I need to add an argumento to the reboot syscall so nex reboot goes to the recovery partition
<abeato> so IÂ¡m trying to understand how the reboot process works
<zyga> abeato: aha
<abeato> zyga, for instance "reboot -f recovery" does the desired thing, but "shutdown +10 recovery" does not
<zyga> abeato: well, I think this is useful
<zyga> abeato: well the reboot command above is special as "recovery" is not a term normally parsed
<abeato> zyga, it is passed directly to the kernel: https://linux.die.net/man/2/reboot
<zyga> abeato: but the good thing is that you can patch system-shutdown to reboot the way you need
<abeato> zyga, yep, seems like a feasible hack
<zyga> abeato: I know the man page, 'recovery' is not there
<zyga> abeato: my point is that the command you quoted is custom
<abeato> zyga, that is why I say it goes straight to the kernek
<zyga> abeato: right
<abeato> yep
<zyga> abeato: so if you can express the desired reboot semantics via the system call you can do what you want
<zyga> abeato: but note that you cannot pass any argument to system-shutdown
<abeato> zyga, so how does it worl when I run "reboot"? first systemd, then initrd is mounted again and then system-shutdown is called? don't really know the details
<zyga> abeato: I don't know for certain (read systemd code to know); I believe what happens is that when a special systemd unit is present (we make one) systemd ensures that shutdown is terminated from initrd using this executable
<abeato> zyga, ok, I will pull the thread from there, thanks!
<zyga> quote of the day for me:
<zyga> from LWN
<zyga> "and thus Torvalds is not sure if it a mount point can be tested if it is a bind mount or not"
<zyga> jdstrand: ^^ :DD
 * zyga has +1000 karma
<abeato> zyga, the call to shutdown when there is a core/kernel update happens in daemon.go:Start(), is that right?
<pedronis> abeato: atm yes
<abeato> ok
<pedronis> I mean, the code is there, it doesn't happen there, that code is setting a callback
<abeato> pedronis, yes yes :)
<icey> how hard would it be to have snaps installable as a non-root user, ie: a I could install a snap (without sudo) for myself?
<zyga> icey: for yourself, not planned
<zyga> icey: without sudo, just "sudo snap login" once ;)
<zyga> icey: but the per-user install case is not anywhere on the roadmap
<icey> zyga: I mean that I wish I could fo per-user snaps :-P
<pedronis> it would be fairly involved
<icey> even into something like $HOME/snap
<icey> would be awesome :)
<icey> add additional user level restrictions on top of the snap security model
<zyga> icey: I agree with pedronis, it's not anything trivial
<zyga> icey: on many many levels
<pedronis> mvo: hi,  did you see my question in snapd#2592 ... do we need to skip creating /snap/foo links for those ?
<mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<icey> I get that it's not trivial, but it would be *awesome*
<icey> so, wishlist ;)
<pedronis> pstolowski: hi, you haven't created that topic in the forum yet about interface hooks , right?
<zyga> icey: well, it needs to fit design; right now it's not part of the design, even as a whislist item
<zyga> icey: I would recommend to open a forum thread to describe it
<zyga> icey: how you envision it might work, including services, confinement and what not
<pstolowski> pedronis, that's right but I didn't forget about it, I'll do today
<icey> zyga: I'll do some thinking about it and post something, I don't really think it'd work with services unless systemd supports per-user services
<icey> rather, services owned by a specific user
<zyga> icey: it does but it doesn't mean something can run as that user
<zyga> icey: e.g. an "apache" snap
<zyga> icey: it's a different beast entirely
<icey> zyga: right, services would be tough to model, which is why I want to think about it some more; I'm considering more from a tool perspective
<zyga> icey: and there's ongoing for for user services but only as a part for "regular" snaps
<zyga> icey: for tools it might be doable, just not sure why interesting
<icey> zyga: consider a user downloading something like nginx, and running it (on no priv port) as their own user
<icey> could be nice to use a snap instead of just running `nginx -{}`
<zyga> icey: it feels like a rat's nest of issues
<icey> zyga: there are a lot of wishlist snaps that are just tools, inkscape, picasa, etc
<zyga> icey: would all snaps work well this way?
<zyga> icey: do you want them to run as yoursel?
<icey> and it would be very interesting to be to be able to install those without root
<zyga> icey: you *can* install *anything* without root
<zyga> icey: if you sudo snap login first
<zyga> icey: that tells us you managed to be root once
<zyga> icey: is the no-root thing some special requirement?
<zyga> icey: e.g. on a machine you don't have root on otherwise?
<icey> there's a snap that managed to break apt a bit ago, no idea if it still does since I have removed it, but it would have been unable to if instaleld without root ;-)
<zyga> icey: that was classic-confinement snap
<icey> the `snap install $SNAPNAME` for that snap messed around with the global system in unfortunate ways
<zyga> icey: so it can do anything
<icey> zyga: now imagine if it didn't have root on install ;)
<zyga> icey: and that snap would not work at all then
<zyga> icey: "--classic"
<pedronis> well that snap managed to break because it needed lots of privileges in the first place
<zyga> icey: you want impossible things
<pedronis> it would not have worked anyway
<pedronis> and it was bad that it made a mess of apt
<icey> pedronis: I'm curious about that, I kind of want to isntall it into a virtualenv and see if it still works ;-)
<icey> pedronis: yeah, made me sad because I like that tool, haven't had it on my computer since then
<zyga> icey: virtualenv? what has that to do with anything?
<icey> fortunately, I haven't needed it
<icey> the tool is written in python
<zyga> icey: anything that installs with --classic is just like a typical deb/rpm, it has full access to everything on the system
<icey> so I want to actually try using it from source, to see what these functions it "needs" are :)
<icey> agree zyga
<zyga> icey: I really encourage you to think about how it should work, it might be possible to create a per-user install of certain kinds of snaps (pure apps, no services), but there are lots of quirks to figure out first
<zyga> icey: a forum thread is a way to explore that
<icey> zyga: certainly, I bet that classic snaps could work too, but services would be really hard (and probably not worth it?)
<zyga> icey: maybe with the session snapd deamon it might be doable but still many hard things there
<zyga> icey: (e.g. imagine encrypted $HOME)
<icey> zyga: yeah, it'd have to be something that was entirely after $USER was logged in fully, I think that services for a user level snap would be not worth it
<icey> but being able to `snap install inkscape` without having root would be cool :)
<mvo> pedronis: checking that question now
<mvo> pedronis: is the question if wrappers.IsService need to take into account if its a dbus activatable service?
<pedronis> mvo: yes, which means though that we would not create /snap/svc for those
<mvo> pedronis: no /snap/bin/svc ? not doing those is actually desirable
<pedronis> yes
<pedronis> sorry
<pedronis> no /snap/bin/svc
<mvo> pedronis: slightly interessting how to organize the code so that we know in wrappers.IsService() if it is a dbus activated service
<Chipaca> icey: well, you only need root once
<Chipaca> (good morning peeps!)
<Chipaca> icey: 'sudo snap login', and then you don't need sudo to snap install stuff
<icey> Chipaca: but snaps installed thereafter would have root access during install yeah?
<Chipaca> yep
<icey> Chipaca: my wish would be to have non-root snaps as well
<mvo> hey Chipaca, good morning
<Chipaca> icey: ah
<Chipaca> icey: to the forum! :-)
<icey> Chipaca: I'll thinkabout it and put something on the forum once I've thought it through a bit more :)
<Chipaca> mvo: how's things?
<Chipaca> icey: fair
<mvo> Chipaca: good, thank you. how are you?
<Chipaca> mvo: not bad
<Chipaca> i opened my big mouth and promised a patch for go, it seems :-) but that's not necessarily *bad*
<Chipaca> (in https://github.com/golang/go/issues/19546)
<mvo> Chipaca: \o/
<Chipaca> I hadn't noticed IsService
<Chipaca> why is it not a method of AppInfo?
<mvo> Chipaca: a good question. it is pretty recent
<mvo> Chipaca: so yeah, we should have a look at moving it
<Chipaca> I can do it as part of this service and wrappers shuffle i'm doing
<Chipaca> in fact I can piggy back it into snapd#3342; nobody's reviewed that yet :-)
<mup> PR snapd#3342: many: refactor in preparation for 'snap start' <Created by chipaca> <https://github.com/snapcore/snapd/pull/3342>
<pedronis> Chipaca: because it's not clear snap should have opinions on that, indeed with dbus service the logic gets quite complicated for being in snap
<Chipaca> pedronis: how so?
<pedronis> Chipaca: have you looked at the dbus activation branch?
<pedronis> anyway
<mvo> pedronis: yeah, I'm actually not super happy about the complexity we have there currently already
<Chipaca> pedronis: snapd#2592?
<mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<pedronis> Chipaca: also Services would need to be something else, because now we have services that are not dbus services
<pedronis> IÂ mean your new method
<mvo> pedronis: and I much agree about snaps opinion about dbus etc
 * mvo scratches head
<pedronis> Chipaca: you should probably look at it
<Chipaca> so, if we need to call them daemons instead of services, fine
<pedronis> because it has influence at on names of stuff and where wrappers.IsService should go
<pedronis> Chipaca: unrelatedly,  a 2nd review for snapd#3322 would be appreciated :)
<mup> PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
<Chipaca> but so far "services" are things that systemd starts
<pedronis> Chipaca: now we have dbus activated "services", like classic classic classic
<Chipaca> as you see from {Add,Remove,Start,Stop}SnapServices
<Chipaca> and start-snap-services
<Chipaca> etc
<pedronis> Chipaca: I'm happy not to care, and let you and mvo figure it out ;)
<mvo> Chipaca: what pedronis said is true, there is the potential to have dbus services (user session) now and systemd unit that are dbus activated (soon)
<mvo> pedronis: hehe
<mvo> Chipaca: but maybe for your branch yu can mostly ignore it, the only thing I will need is some way to figure out that its a dbus service so that I don't write a /snap/bin/foo-dbus-activated file that is useless to the user
<Chipaca> mvo: as things stand there's a lot of places where we use "service" to mean something that has a systemd unit
<mvo> Chipaca: indeed, so maybe a new term? dubsActivated or somesuch
<Chipaca> having a systemd unit that is dbus-activated instead of socket-activated or type=notify is just a variant, it's the same thing
<Chipaca> but having a service that does not have a unit associated would be strange
<mvo> Chipaca: right, the user session will not have a unit
<Chipaca> we *could* split it int SystemdService and DbusService
<Chipaca> OTOH... are you sure the user session will not have a unit?
<mvo> Chipaca: I mean, we could implement it via systemd but 16.04 has no systemd user session so things will fall apart there
<Chipaca> i mean, do we support user services on things that don't use systemd for the user session?
<mvo> Chipaca: dbus activation works fine without systemd user sessions, its an older concept
<Chipaca> i know
<Chipaca> upstart alos works fine
<Chipaca> the question is whether we want to support it :-)
<mvo> Chipaca: heh :) fair enough. if we don't we exclude 14.04 and 16.04 and possilbly 16.10 (have not checked this one)
<mvo> Chipaca: or maybe we need to spawn our own systemd user session with snapd
<mvo> Chipaca: no idea if that is feasible but if it is it might be nice way out
<Chipaca> mvo: anyway, backpedaling from the "do we want to do this" question, _if_ we do this, we should split service in two
 * mvo nods
<Chipaca> or call them daemons vs servcies
<Chipaca> or daemons and sprites, and confuse everybody
 * Chipaca grins evily
<mvo> Chipaca: sounds resonable, I will look into it in a little bit
<Chipaca> mvo: I haven't looked at your branch in detail; is there any place where you need to grab all services, both dbus and systemd?
<Chipaca> looks like you implement a separate isDbusService, and use that
<mvo> Chipaca: yeah, I think that will be sufficient for now
<Chipaca> mvo: also you don't do things from start-snap-service and related tasks
<Chipaca> afaict
<Chipaca> so, for now, i'm leaving Services in snap, and moving IsService in there
<Chipaca> and afaict (but tell me if i'm wrong), at most we'll be renaming them to SystemdServices/IsSystemdService, not making them more complex
<Chipaca> (or to Daemons/IsDaemon)
<Chipaca> (or Vegetable/IsVegetable)
<Chipaca> (or ..)
<pedronis> Chipaca: well, no, we need IsService to return true for the things mvo is working on, that's the matter
<Chipaca> pedronis: those things don't have daemon set
<pedronis> Chipaca: indeed
<Chipaca> pedronis: and dbus-activated systemd services are services in the current sense
<pedronis> but we don't want to create /snap/bin/foo for them
<pedronis> at the moment IsService decides whether the thing should have a /snap/bin entry
<Chipaca> pedronis: right, so the current code in binaries would change from IsService to IsService || IsDbusService (or whatever)
<pedronis> (and consequently whether to support aliases)
<Chipaca> pedronis: but what I'm wanting is to drop all the _other_ app.Daemon == ""
<pedronis> Chipaca: there are usages in snapstate too
<Chipaca> in aliasesv2
<Chipaca> yup
<pedronis> yes
<pedronis> it would be saner if they didn't all have to call two helpers
<pedronis> but that's my 2cts
<mvo> we could add wrappers.IsBinary maybe?
<Chipaca> pedronis: so maybe as part of the dbus branch we IsService -> IsSystemdService, have IsDbusService, and have IsService that ||s the two
<pedronis> mvo: yea, maybe that
<Chipaca> mvo: that would be confusing, at least to me, because I'd expect IsBinary to be !IsService, always
<Chipaca> bah
<Chipaca> hmm
<pedronis> Chipaca: it would be
<pedronis> if IÂ understand things
<Chipaca> pedronis: if IsService is the || above, yes
<Chipaca> mvo: why would it be wrappers.IsBinary and not snap.(*AppInfo).IsBinary?
<pedronis> because the logic for IsDbusService is complicated
<morphis> rharper: ping
<pedronis> and about policies that are 5 layers away from the basics of snaps
<pedronis> but you can read it both ways
<mvo> Chipaca: yeah, what pedronis said, probably in wrapper as its complex(ish)
<pedronis> I mean the issue is mostly not to have that logic in many places
<mvo> +1 on that
<Chipaca> agreed that that's #1
<pedronis> Chipaca: completion timeout that doesn't seem related to create-key: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170518_083559_ce30f@/log.gz
<Chipaca> OTOH that you can't tell whether an app is a dbus service from looking at the app, to me is a red flag
<Chipaca> or at least a bright yellow flag :-)
<Chipaca> pedronis: not only, no
<Chipaca> waaait
<Chipaca> that's a different completion
<mvo> Chipaca: we could make it more explicit. right now its entirely based on the dbus slot, however we could add something explicit to the app yaml part
<mvo> Chipaca: 2592 has an example of the current syntax, maybe we move the "service: true" part up to the app level (and rename it to something sensible or fold it into daemon:)
<Chipaca> pedronis: that timeout makes no sense :-(
<abeato> zyga, hey, I think you are the only one missing in https://github.com/snapcore/snapd/pull/3324 :)
<mup> PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324>
<Chipaca> mvo: what would one on the system dbus look like?
<Chipaca> mvo: does it running on the system dbus mean it runs as root?
<mvo> Chipaca: that is not decided yet, probably exactly the same excep tthat bus: session becomes bus: system
<mvo> Chipaca: correct
<Chipaca> mvo: how is a dbus-activated system dbus service different from a bus-activated systemd service
<Chipaca> the manpage points me to /usr/share/dbus-1/system-services/org.example.simple-dbus-service.service which doesn't exist. Hrmph.
<mvo> Chipaca: I have not looked into the details for the system dbus services, but I expect that we want to do the systemd unit route here
<mvo> Chipaca: i.e. there may be very little for us to do
<Chipaca> so they'd be quite different in that case?
<Chipaca> or would it still need a plug and etc?
<mvo> Chipaca: the user session was the most interessitng one to me as there are some gnome apps that use this mechanism and we can not support them ucrrently
<mvo> Chipaca: AIUI there is still a plug needed to ensure appamor allows all the dbus things that the dbus activated service wants to do
<mvo> (but take it with a grain of salt, I have not looked into the details for dbus in system services)
<ackk> hi, how do I remove a snap that's marked as broken,disabled?
<Chipaca> ackk: snap remove snapname?
<Chipaca> ackk: (how did it get into that state?)
<ackk> Chipaca, I had installed locally 2 versions of a snap, when I tried to sudo snap remove <snap> it hang for several minutes removing one of the versions
<ackk> Chipaca, I C-c'd it and after that it was broken
<ackk> Chipaca, fwiw it's a snap installed in an LXD container
<Chipaca> zyga: you want to look at this?
<ackk> Chipaca, uhm, it seems it eventually deleted itself, I don't see it anymore now :/
<Chipaca> ackk: 'snap changes
<Chipaca> agh
<Chipaca> ackk: 'snap changes' should be able to shed light on things
<ackk> Chipaca, I see a series of "install" and a "remove" at the end
<Chipaca> ackk: snap tasks <the number with the remove>
<ackk>  
<ackk> 2017-05-18T08:47:55Z ERROR cannot remove snap file "basic-auth-service", will retry in 3 mins: umount: /snap/basic-auth-service/x1: not mounted
<ackk> 2017-05-18T08:50:55Z ERROR cannot remove snap file "basic-auth-service", will retry in 3 mins: umount: /snap/basic-auth-service/x1: not mounted
<ackk> Chipaca, ^^
<Chipaca> ackk: where's that from? (and what did 'snap tasks' say?)
<mvo> pedronis: I updated the repair capability with a new "running repairs" proposal based on the ideas from gustavo. feedback welcome
<Chipaca> ackk: ('snap tasks' used to be 'snap change', if your snapd is slightly old try that instead)
<pstolowski> zyga, hey, any objections to expose rm_rf_tmp from ns-supoort-tests to utils-test or similiar? I need to cleanup tmp stuff in my new test
<pstolowski> s/expose/expose and move/
<pedronis> mvo: I'm not quite sure why we need --probe ?
<pedronis> that wasn't part of Gustavo proposals
<pedronis> mvo: also is not clear, but we still need the the latest good in snapd/gadget, otherwise we will download all assertions since forever
<mvo> pedronis: thats fine, I can change it. it felt slightly cleaner to make it explicit but I guess its an unneeded extra step
<pedronis> mvo: well it begs questions about the state after the real run
<mvo> pedronis: ok, let me update it
<pedronis> for when it's unknown
<pedronis> basically bigger state machine
<mvo> pedronis: updated it yet again
<pedronis> mvo: fixed the when repair section
<pedronis> mvo: I think with this approach the every 4h  seems reasonable, later we could have some approach that do it as well if snapd is down since a while
<mvo> pedronis: great
<zyga> pstolowski: no, go ahead
<zyga> Chipaca: yes, gladly
 * zyga is back, sorry, some unexpected stuff at home
<zyga> ackk: ah, LXD
<zyga> ok, I might as well explore LXD, this would fit nicely in my mount namespace layout tests
<zyga> abeato: looking
 * zyga refrains from reading the rest of the backlog
<ackk> Chipaca, it's from snap tasks
<Chipaca> ackk: could you pastebin the whole output of the relevant 'snap tasks'?
<ackk> Chipaca, http://paste.ubuntu.com/24597955/
<ackk> Chipaca, fwiw it was eventually removed correctly
<pstolowski> pedronis, https://forum.snapcraft.io/t/interface-hooks-attributes/673
<zyga> abeato: some things are still not documented (golint)
<zyga> a bit nitpick but I think it's relatively easy to do
<abeato> zyga, I tried golint, but I got no output
<zyga> abeato: in that directory?
<abeato> zyga, yes
<abeato> $ golint *.go
<abeato> androidbootenv_test.go is in package androidbootenv_test, not androidbootenv
<abeato> zyga, this is the only output I see *^^
<pstolowski> zyga, thanks
<zyga> abeato: commented again
<zyga> abeato: let me look, that's still wrong :) probably
<zyga> abeato: but check my feedback
<abeato> zyga, sure, thanls
<morphis> ogra_: is rsyslog already removed in edge?
<mvo> morphis: yes
<morphis> mvo: hm, so is the journal sync'ed to disk?
<pedronis> pstolowski: thanks, it seems to capture the discussion points, IÂ added a comment there
<pstolowski> pedronis, yes, saw it, thanks
<zyga> woohoo
<zyga> I see core edge :)
 * zyga sees the content interface changes work :D
<zyga> I'd say woot but that's be self serving
<zyga> still
<zyga> very happy :)
<mvo> morphis: aiui it is not
<mvo> morphis: it is only if the /var/log/journal dir exists or something
<morphis> hm
<mvo> zyga: what content interface chagne is that?
<abeato> zyga, answering your comment, I do not care about deterministic order
<abeato> zyga, were the test you proposing about that? If that is the case, it is not needed either
<zyga> abeato: yes, I think we want that
<zyga> abeato: it's almost always desirable IMO
<abeato> zyga, not in this case
<abeato> zyga, it is a hurdle we do not really care about
<NicolinoCuralli> Hi guys, is it now possibile revoke a gpg key on the Store?
<zyga> abeato: can you justify that?
<abeato> zyga, neither the bootloader or snapd cares about the orde in which env vars are stored
<abeato> so no reason to enorce that
<abeato> *enfroce
<abeato> enfroce
<zyga> heh
<zyga> make a file called '<' by accident
<zyga> then remove it
<zyga> fun :)
<Chipaca> zyga: ârm \<â ?
<zyga> Chipaca: yes but it took me a second to find that :)
<zyga> Chipaca: this is both you vs shell as well as you vs program parsing it :)
<Chipaca> zyga: the program shouldn't be doing parsing of the filename
<Chipaca> unless it were "-foo" or something
<ogra_> hmm
<Chipaca> (for which "--" exists)
<ogra_> building something for snapcore via build.snapcraft.io requires additional organization access :/
 * ogra_ wonders why ... given my GH account already has readonly access to the branches which should be enough to build it
<zyga> Chipaca: yep, I tried with -- but that was just my naive idea ;)
<mup> PR snapd#3347 opened: snap-confine: moved rm_rf_tmp to test-utils <Created by stolowski> <https://github.com/snapcore/snapd/pull/3347>
<pstolowski> zyga, ^ something for you ;)
<cjwatson> ogra_: BSI needs admin access to the repo in order to install a webhook
<cjwatson> I think we even explain that on the GH permission request page nowadays
 * zyga looks
<ogra_> cjwatson, well, the GH page itself is a bit confising ... telling me at the top that it has readonly access and requesting additional organization access at the bottom ... the snapcraft.io page is better designed but i get redirected first
<cjwatson> there's a limit to how much we can do about that; best we can do is explain it in the bits of text we get to control
<ogra_> yeah
<ogra_> we should just rent out mpt to GH for a redesign ;) (for most of the UI actually IMHO)
<pstolowski> thx zyga
<cjwatson> ogra_: it has its good points
<ogra_> some. yeah ...
<Chipaca> did somebody say lunch
<zyga> Chipaca: DEFCON-1 LUNCH!!!!
<Chipaca> actually a siesta might be what i need
<Chipaca> but no! onwards!
<Chipaca> zzmmmhyeah
<pedronis> mvo: wrote something in the forum about the last-refresh unset question/"issue"
<zyga> Chipaca: question, sir, how would you suggest to tweak this: http://pastebin.ubuntu.com/24598370/
<zyga> (apart from fixing s/slots/snaps/)
<Chipaca> zyga: âaccess the network as a clientâ reads wrong, and is fluffy and imprecise
<zyga> fluffy is what we had in a comment so far :)
<zyga> suggestions welcome
<zyga> I made it possible to expose meta-data about interfaces
<zyga> and shoved them through the pipeline to the CLI
<Chipaca> zyga: <this interface> lets apps do <exactly these things>?
<zyga> Chipaca: acccessing the network as a client is exactly what the doctor ordered though
<zyga> Chipaca: I know it's techy but not sure how to make it better
<zyga> but but
<zyga> this is not that thing I asked about
<Chipaca> my point is it's not techy enough :-)
<zyga> how would you display information about an interface
<zyga> aaah
<Chipaca> zyga: what did you ask me about :-)
<zyga> (not the particular wording)
<Chipaca> ah! that seems fine
<zyga> I just print the description if you ask via -i ifacename
<Chipaca> i assume you're using wrap() there?
<zyga> oh, no
<zyga> nice! let me look
<Chipaca> maybe use wrap then
<zyga> the patch is not long,  I'll post it in a moment
<Chipaca> wait was it wrap()
 * Chipaca digs
<Chipaca> zyga: fill()
<Chipaca> might need tweaking as it's only for errors right now (so it assumes an indent)
<mup> PR snapd#3348 opened: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<zyga> Chipaca: hmm, wonky
<Chipaca> oh?
<Chipaca> zyga: how so?
<zyga> http://pastebin.ubuntu.com/24598396/
<zyga> Chipaca: (offtopic) bash completion for http would be lovely ;)
<Chipaca> zyga: main problem there is the indent, which i warned you about :-)
<zyga> Chipaca: how do I make http talk to snapd again?
<Chipaca> http snapd:///v2/system-info
<zyga> snapd:// is a thing?!
<zyga> wow
<Chipaca> it is in the snap :-D
<zyga> I tried unix://
<zyga> Chipaca: ok, a bit better now
<Chipaca> zyga: http://pastebin.ubuntu.com/24598417/
<Chipaca> en nu, lunch
<zyga> Chipaca: I did something like that
<Chipaca> zyga: note you can kill filledError; it slipped in by accident (was going to use it, didn't in the end)
<zyga> Chipaca: yep, I killed it
 * Chipaca goes back to his leftovers
<mup> PR snapd#3235 closed: overlord/hooks: make sure only one hook for given snap is executed at a time <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3235>
<pstolowski> yay :)
<pstolowski> thanks pedronis!
<zyga> pstolowski: all red on the rm-rf test move
<ogra_> morphis, oops, sorry, missed your ping ... yes, rsyslog is gone for good in edge so we get potential feedback before next release
<morphis> ogra_: actually what I missed today was that I was booting an image in kvm which failed and I didn't got access, then stopped kvm, mounted the image and missed the syslog for inspection
<ogra_> morphis, if you want a persistent journal you can create /var/log/journal, journald will drop its blobs in there then and they persist across reboots
<ogra_> morphis, hmm, we should probably allow a cmdline option that creates that dir from the initrd for debug purposes
<ogra_> (not sure how else we could do it)
<morphis> ogra_: yes, that would be nice
<pstolowski> zyga, seems to be about formatting.. looking
<zyga> pstolowski: make fmt
<ogra_> would you comment on the forum thread ? i'd like to get gustavos input on it before starting to hack on anything
<zyga> pstolowski: feel free to force push this, I hate things like that breaking bisect
<zyga> Chipaca: how did you get around that terminal width issue in testing?
<Chipaca> zyga: regular expressions
<Chipaca> zyga:  MATCH -z "${expected// /[[:space:]]+}"
<zyga> Chipaca: ah, I used unit tests
<zyga> wanna see?
<Chipaca> zyga: even easier then :-)
<zyga> Chipaca: look at zyga/feature/iface-metadata please
<pstolowski> zyga, ok, pushed
 * zyga loves how this works 
<Chipaca> zyga: looks good; the level of nits i have are probably not worth it =)
<Chipaca> zyga: there's a bug there though
<zyga> yes?
<Chipaca> zyga: probably because it's doing something unGo-ly
<Chipaca> zyga: it does `ifaces, err := Client().Interfaces()`
<Chipaca> zyga: and then a super long block of `if err == nil`
<Chipaca> zyga: and then outside of that block, it uses ifaces
<zyga> Chipaca: aha, let me look
<zyga> ah, in cmd_interfaces.go
<zyga> thanks
<Chipaca> suggest switching that to a `err != nil`, exiting early, and so on
<zyga> Chipaca: diff would be longer
<zyga> I'll change that but separately
<Chipaca> zyga: code would be better
<zyga> Chipaca: fair enough
<zyga> I wrote it like that for 100% coverage (I was cheating)
<zyga> Chipaca: fetch again
<zyga> or maybe just look here: https://github.com/snapcore/snapd/pull/3349
<mup> PR snapd#3349: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
<mup> PR snapd#3349 opened: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
<Chipaca> tput reset; GOPATH=~/canonical/snappy goctest -coverprofile .coverage/profile.out -v github.com/snapcore/snapd/cmd/snap && GOPATH=~/canonical/snappy go tool cover -html=.coverage/profile.out
<Chipaca> oops, wrong paste :-)
<Chipaca> zyga: you didn't get 100% anyway :-D
<zyga> Chipaca: it used to be 100%
<zyga> I just reall why it was written this way before
<zyga> I think this will be a welcome feature
<zyga> I'd like to document interfaces on the forum
<zyga> and add a forum URL to meta-data :)
<Chipaca> zyga: i thought the github wiki was the place for docs
<Chipaca> zyga: 91.7% coverage as it stands now
<Chipaca> zyga: 93.6% before
<Chipaca> zyga: when you say 'add a forum URL to meta-data' you mean structuredly?
<Chipaca> also: http://imgur.com/a/IeRjS
<pedronis> Chipaca: I think docs now go to the forum doc category
<pedronis> Gustavo was planning to move over bits from the wiki and then close it
<niemeyer> Yeah, this is gradually happening already
<niemeyer> (good morning)
<niemeyer> A handful of documents have been moved
<Chipaca> zyga: I stand corrected :-)
<niemeyer> https://forum.snapcraft.io/c/doc
<Chipaca> well, 'stand' is a manner of speaking
<zyga> Chipaca: yes
<zyga> niemeyer: oh, nice
<niemeyer> We just need to be careful to not overload the forum with mechanical posts
<niemeyer> That's part of the reason why I'm not just taking things and moving over
<ogra_> woah ... popey ! 2.2k views for your wishlist post
<Chipaca> ogra_: it's been busy :-)
<ogra_> yeah
 * Chipaca 's finger hovers over [Spam]
<ogra_> heh
<Chipaca> but then i posted there, so shouldn't complain :-D
<zyga> Send-pings-after-midnight
<Chipaca> zyga: i think that PR will fail static check btw
 * zyga tries
<Chipaca> zyga: if you hurry you might beat travis :-D
<zyga> ah damn simplify rulels
<zyga> rules*
<zyga> I need to teach vim to do that
<Chipaca> or your eyes :-p
<zyga> Chipaca: yes, I wrote that after all :")
<Chipaca> zyga: here, try these: 8
<zyga> offtopic, today I installed a webcam in a T530 (not mine)
<zyga> I must say, damn, thinkpads are fantastic :)
<zyga> tooking the LCD bezel apart was trivial, I found official docs online, the panel had the connector cable installed already, all with proper tape to ensure it is held in place
<zyga> the connector was keyed so it was easy to get it right
<zyga> and the whole procedure took 10 minutes including the part where the machine was turned off and disconnected from battery
<zyga> I thought we'd 1) fail 2) take long time 3) buy more parts 4) succeed next time, maybe
<zyga> super happy with the result :)
<Chipaca> i guess i've been spoiled by my e-series latitude
<zyga> is that a dell?
<Chipaca> yeap
<zyga> on the other hand the camera-less laptop is pretty rare for me
<Chipaca> single-screw access to all the guts
<zyga> (feels like government stuff)
<Chipaca> (well, not all, but the most common)
<zyga> nice :) I took many laptops apart but I never touched the screen bezel or internals
<zyga> and now I'm thinking of swapping a panel (on that same laptop) to a highere res one
<Chipaca> anyway. i'm going to go get some tea, let's see if it wakes me up
<Chipaca> otherwise some of us might be asleep at the standup
<zyga> enjoy :)
<Chipaca> can't have that
<morphis> mvo, zyga: can you have a look at https://github.com/snapcore/snapd/pull/3337 again?
<mup> PR snapd#3337: errtracker: try multiple paths to read machine-id <Created by morphis> <https://github.com/snapcore/snapd/pull/3337>
<morphis> niemeyer: you had time to look at https://github.com/snapcore/snapd/pull/3222 already?
<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: sure
<morphis> zyga: thanks
<zyga> morphis: cannot find?
<zyga> morphis: cannot read
<morphis> ?
<zyga>  +logger.Noticef("cannot find %s: %s", id, err)
<morphis> fine for me
<zyga> morphis: fix that and LGTM
<morphis> zyga: done
<niemeyer> Would anyone have a plausible explanation for this:
<niemeyer> root@worker-c:/root# ls -l /bin/mount
<niemeyer> -rwsr-xr-x 1 root root 40152 Dec 16 15:40 /bin/mount
<niemeyer> root@worker-c:/root# /bin/mount -h
<niemeyer> bash: /bin/mount: Permission denied
<zyga> morphis: thanks!
<niemeyer> This is inside a devmode snap
<zyga> niemeyer: one sec
<zyga> niemeyer: I think I know why
<zyga> niemeyer: do you have any denials?
<niemeyer> Well, I must do
<niemeyer> Checking
<Chipaca> zyga: if [[ "$USER" =~ niemeyer ]]; then exit EPERM; fi
<zyga> niemeyer: hmm, no my idea is not there
<niemeyer> [  421.101403] audit: type=1400 audit(1495111946.792:42): apparmor="DENIED" operation="open" profile="snap.discourse.shell" name="/bin/mount" pid=1630 comm="bash" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> niemeyer: we used to have an explicitly deny for mount
<zyga> aha
<zyga> iiinteresting
 * zyga looks
<niemeyer> Yeah, I assumed that was the case
<niemeyer> What I don't understand is why
<zyga> niemeyer: cna you look at the profile, is it really a complain-mode profile?
<zyga> niemeyer: there's nothing that explains this for me so far
<niemeyer> Nope
<niemeyer> I think we have a bug in the profile generation
<zyga> niemeyer: can you pastebin the head of the profile? (or the whole thing)
<niemeyer> I've already enabled and disabled the snap, which removes the case of something being left over
<niemeyer> https://www.irccloud.com/pastebin/R0nWdOwZ/
<niemeyer> zyga: ^
<niemeyer> snap list confirms it's devmode, FWIW
<pedronis> pstolowski: do you still have a todo about CheckChangeConflict and connect/disconnect ?
<popey> ogra_: yeah, bit sad cafe isn't surfaced on the front page
<niemeyer> zyga: I had observed this problem yesterday, but I thought it was related to reverts.. but now I managed to reproduce it without a revert
<zyga> niemeyer: interesting, this is *not* devmode
<niemeyer> Right
<zyga> niemeyer: hop into the standup
<zyga> niemeyer: we can chat
<niemeyer> omw
<ogra_> popey, well, probably niemeyer can change that
<zyga> niemeyer: snap list says it is devmode?
<pstolowski> pedronis, I need to refresh my memory. last time I checked I couldn't really see what was wrong with it
<pedronis> pstolowski: oh, IÂ though you understood the problem
<pedronis> pstolowski: Connect/Disconnect check  but CheckChangeConflict don't consider disconnect/connect tasks
<pedronis> pstolowski: so you can run install why you are trying to Connect/Disconnect
 * Chipaca crosses âhear mvo describe something as Â«gnarlyÂ»â from his bucket list
<pstolowski> pedronis, yes, but the I looked at this method and as far as I remember it doesn't care about task type, it just looks for another task affecting same snap
<pstolowski> s/the/then/
<pedronis> pstolowski: ?
<pedronis> pstolowski: there's a full map of task types
<pedronis> the issue is that the connect/disconnect carry two snaps
<pedronis> so there's a bit more to do
<pstolowski> pedronis, you're right, i see
<Saviq> ogra_, hey, I'm trying to update https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ a bit - it mentions rpi3 gpu support "not in stable yet" - I suppose this note should go away now?
<jdstrand> zyga (cc niemeyer): fyi, we don't have any explicit denies for mount in any of the policy (we avoid explicit denies as much as possible)
<zyga> jdstrand: it's a different bug
<zyga> jdstrand: the profile is for strict
<zyga> some state is mixed up
<ogra_> Saviq, nope, it is a gadget thing and we can not update gadgets yet
<Saviq> ogra_, ack, leaving it be, then
<ogra_> Saviq, so we only have it in !stable channels
<jdstrand> zyga: I know, but I didn't want the idea to propagate that we have explicit denies for mount
<zyga> jdstrand: aha
<zyga> jdstrand: I have a branch I'm sure you will like
<zyga> https://github.com/snapcore/snapd/pull/3349
<mup> PR snapd#3349: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
<niemeyer> popey: The point of cafe was for things that are usually pretty offtopic ("look at that sun set!"), which is not what people expect when they go to forum.snapcraft.io..
<niemeyer> popey: If you have an entry that you wish was presented in the front page, that's likely not something to be discussed on the cafeteria :)
<zyga> mvo: could we support C coverage via codecov as well?
<mvo> zyga: I think so, I have not looked into it
<zyga> mvo: I'll look at that
<jdstrand> zyga: oh that's nice. note that 'The core snap provides the slot that is shared by all the snaps' is handy, but that is defined elsewhere (implicit.go and the base declaration). this makes a third spot to keep in sync. I'm not sure how to fix that, but wanted to mention it
<zyga> jdstrand: yes, that will go away too :)
<zyga> jdstrand: I'll make implicit.go just ask for meta-data :)
<zyga> jdstrand: but I didn't want to clobber it here
<zyga> jdstrand: initially I also folded Name into meta-data but I think not doing so is just easier
<zyga> jdstrand: I could also fold base declaration but I think you were against that
<popey> niemeyer: I didnt expect that thread to blow up like that tbh. Thought it might be a casual conversation with 2 or 3 comments
<niemeyer> popey: Ah, on that thread, it really doesn't feel so coffeey.. I moved it to the snap category earlier today already, so it is now in the front page
<popey> Sweet, thanks!
<jdstrand> zyga: I'm ok with folding the base declaration into it cause that makes a good bit of sense, but it would be handy to be able to dump the entire base declaration with a command
<zyga> jdstrand: aha
<zyga> jdstrand: that's doable via snap debug interface, I'll look at that as well then
<Saviq> zyga, hey, is there a GH issue or PR we can reference about https://bugs.launchpad.net/snappy/+bug/1646333 ?
<mup> Bug #1646333: bind mounts related to content interface plugs remain stale on snap disconnect/connect or snap updates <Snappy:New> <https://launchpad.net/bugs/1646333>
<zyga> jdstrand: so with this interfacecs would become 100% self-contained
<zyga> Saviq: ha
<zyga> Saviq: use edge
<zyga> Saviq: that's fixed now :)
<jdstrand> zyga: really, I think defining everything within the interface file is good, since you can see everything in one place
<zyga> jdstrand: yes, I agree, I think this will be nicer for everyone
<Saviq> zyga, is cjson back in edge yet? ;)
<ogra_> Saviq, yes
<zyga> Saviq: I didn't check but I think ogra_ pushed it
<jdstrand> zyga: what I was against is the policy being spread out over multiple file and thus making it hard to see. this is making things easy to see :)
 * zyga nods 
<Saviq> ogra_, zyga thanks, that's helpful
<Son_Goku> zyga, morphis: snapd 2.26.3 and snapd-glib 1.12 are building
<zyga> Saviq: this will be in 2.27 (mount changes)
<ogra_> Saviq, i was actually greeted with a running kisok-app when entering my office this morning ;) thanks to auto-update
<morphis> Son_Goku: nice!
<Son_Goku> morphis: I had to drop the libexecdir test fixes patch because it wouldn't build
<zyga> hey Son_Goku, sounds great :-)
<Son_Goku> and the changes were too drastic
<Saviq> ogra_, :)
<morphis> Son_Goku: a simple rebase didn't work?
<Son_Goku> Nope
<Son_Goku> there were way too many changes
<Son_Goku> anyway, tests are still not enabled in the Fedora packages anyway
<morphis> right
<Son_Goku> that thing needs to be merged for 2.27
<morphis> need to follow up with the various bugs I filed to get packages updated and AFAIK you still need to review one :-)
<zyga> fgimenez: can you tell me more about that test that you just mentioned?
<fgimenez> zyga: of course thanks, let me push the last changes https://github.com/snapcore/snapd/pull/3348
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<zyga> fgimenez: thank you
<fgimenez> zyga: last changes pushed
<zyga> fgimenez: looking
<fgimenez> thank you zyga
<fgimenez> zyga: you can execute it with "spread -v qemu:ubuntu-16.04-64:tests/nested/core-revert"
<mup> PR snapcraft#1322 closed: state: ignore the 'any' architecture in the build packages apt cache <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1322>
<fgimenez> zyga: anyway i'm not sure if just installing network-manager is enough for surfacing the problem, maybe it should be configured somehow?
<Son_Goku> zyga, morphis: https://bodhi.fedoraproject.org/updates/FEDORA-2017-74f7c7df46 (F26), https://bodhi.fedoraproject.org/updates/FEDORA-2017-2e4459fa03 (F25), https://bodhi.fedoraproject.org/updates/FEDORA-2017-866e9643a8 (F24)
<morphis> Son_Goku: can you add those to the forum thread?
<Son_Goku> I don't know which one to add it to, and I have to go to work
<rharper> morphis: here
<zyga> fgimenez: let me show you what CE did
<pedronis> zyga: jdstrand: notice that there was still the open idea to let the base declaration be updateable from the store
<pedronis> splitting it might make understanding that flow harder, don't know
<zyga> Chipaca: we found the issue
<zyga> pedronis: aha
<Chipaca> zyga: is it potatoes
<zyga> pedronis: I thought that was ony about the snap declaration, not the base declaration
<zyga> Chipaca: it's snap list,
<zyga> Chipaca: snap is not in devmode in state
<zyga> Chipaca: but notesFromLocal has some logic that is probably stale
<Chipaca> that's a relief (in that at least that bug i got)
<zyga> Chipaca: I'm going to look at that now
<Chipaca> ok
 * zyga actually should eat lunch first
<zyga> niemeyer: the kernel change is one thing, the snapd change is another thing
<zyga> niemeyer: when we change core, that core's snapd needs to do the setup
<zyga> niemeyer: (like 2-phase setup really)
<zyga> niemeyer: maybe we should re-exec into new core snapd even on core systems
<zyga> niemeyer: then shutdown will need to care after the kernel part of the problem only
<pedronis> zyga: we wait for reboot on core systems before doing the 2nd phase
<zyga> pedronis: reboot yes but I mean we should restart and reexec snapd on core as well
<zyga> pedronis: I don't think we do that
<pedronis> zyga:Â ?
<pedronis> we don't finish the install
<zyga> pedronis: (so that the incoming snapd gets to finish profile generation before boot)
<pedronis> until we are after reboot
<zyga> pedronis: yes, and that is also part of the problem
<pedronis> one of the thing we planned to change is not too wait for the reboot long
<zyga> pedronis: don't get me wrong, just one of many options
<zyga> pedronis: the bug is that on boot the profiles are stale
<zyga> pedronis: and they can be stale because kernel or core changed (or maybe gadget too, I didn't think about it)
<zyga> pedronis: gustavo suggested to update profiles on shutdown, this would allow us to do kernel changes correctly
<zyga> pedronis: but core changes cannot be handled this way
<zyga> I also wonder what this means for attribute hooks
<pedronis> well we cannot restart snapd
<pedronis> because core is the full root
<pedronis> isn't unclear things would work in all casses
<zyga> pedronis: aha
<zyga> pedronis: well, we could make it work
<zyga> but I think the general case needs to be investigated more
<Chipaca> ok, i'm off to a parents' evening (a.k.a. teachers' nightmare). Bbl...
<zyga> Chipaca: will there be tapas?
<zyga> Chipaca: enjoy :)
<Chipaca> I don't think there'll be anything to eat
<Chipaca> but i could be wrong
<Chipaca> but i won't eat it anyway
<Chipaca> because, waste time
<pedronis> zyga: anyway moving starting snapd as early as possible on the core would also solve the problem, no?
<pedronis> IÂ early in the boot sequence
<zyga> pedronis: yes
<zyga> pedronis: though it is unclear what happens if, say, snapd fails and things go south
<zyga> pedronis: or how long will that slow down the boot sequence
<pedronis> well on a core device
<pedronis> all interesting things will be snap
<pedronis> so they need those profiles
<zyga> pedronis: also we probably want to say "hey snapd, start but hold it there for most activities as, you know, we're still booting"
<zyga> pedronis: then say "ok, GO" later
<zyga> could be pretty nice actually
<zyga> snapd could hold a mode (in memory only)
<zyga> booting, running, shutting-down (or something)
<zyga> and could react to requests
<zyga> and alter ensure as appropriate
<pedronis> maybe, we don't a lot at all
<pedronis> there
<pedronis> under normal circumstances
<pedronis> profile rewriting is probably the biggest bit
<pedronis> but also the one we want
<zyga> I'd like to avoid things like bootup, super early, just out of initrd and we run refresh or what not
<zyga> yes, I agree
<pedronis> well refresh is scheduled
<zyga> yes, but it will run if we're unlucky
<pedronis> we can do things about that
<zyga> yes
<zyga> that's my point about the mode variable
<zyga> not do things that are not appropriate
<pedronis> anyway sounds a forum topic
<zyga> very much so
<mup> PR snapd#3350 opened: interfaces,overlord/ifacestate: make sure installing slots after plugs works similarly to plugs after slots <Created by pedronis> <https://github.com/snapcore/snapd/pull/3350>
<morphis> zyga, mvo: https://github.com/snapcore/snapd/pull/3308 is ready for merging if you don't see anything else
<mup> PR snapd#3308: tests/lib: introduce pkgdb helper library <Created by morphis> <https://github.com/snapcore/snapd/pull/3308>
<mvo> morphis: commented, there is another micro opitmization you could do, but I can also merge and propose this later
<mvo> morphis: tests are green so
<mvo> morphis: I will just merge and push my diff later
<niemeyer> Lunch
<mup> PR snapd#3337 closed: errtracker: try multiple paths to read machine-id <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3337>
<davhou> Can someone offer a solution to this error I get when trying to run an installed snap? https://paste.ubuntu.com/24599229/plain/
<mup> PR snapd#3351 opened: errtracker: small simplification around readMachineID() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3351>
<davhou> receiving: "cannot create lock directory /run/snapd/lock: Permission denied" running as root or via sudo
 * zyga goes to handle some errands
<davhou> running Ubuntu 16.04.2 LTS
<ogra_> davhou, stop doing that as root, and dont use sudo
<morphis> mvo: sounds good! thanks
<mup> PR snapd#3308 closed: tests/lib: introduce pkgdb helper library <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3308>
<mup> PR snapd#3352 opened: interfaces/log-observe: allow using journalctl from hostfs for classic distro <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3352>
<mup> PR snapd#3347 closed: snap-confine: move rm_rf_tmp to test-utils <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3347>
<morphis> niemeyer: do you saw https://github.com/snapcore/snapd/pull/3274 already?
<mup> PR snapd#3274: cmd/snap,tests/main: add force-devmode switch instead of spread system blacklisting <Created by morphis> <https://github.com/snapcore/snapd/pull/3274>
<Saviq> can I change privacy of a snap after I've registered a name, but before I've uploaded anything? does it matter before I publish anything?
<niemeyer> morphis: If there are no comments there from me probably not
<zyga> we should really fix the openvswitch test
<zyga> I'll check out why it keeps timing out :/
<morphis> niemeyer: references to you are there, asking for your comments :-)
<niemeyer> morphis: So you'll get them..
 * zyga moved to the pier to observe uncommon event of two cruise ships departing
<zyga> I can obviously do code reviews at the same itme
<zyga> jdstrand: I posted a question on https://github.com/snapcore/snapd/pull/3352#pullrequestreview-38977547
<mup> PR snapd#3352: interfaces/log-observe: allow using journalctl from hostfs for classic distro <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3352>
<zyga> jdstrand: and replied to myself :)
<zyga> sorry for the noise
<kyrofa> Saviq, I don't even think you get a snapd ID before you upload anything
<kyrofa> Err, snap ID
<kyrofa> Saviq, for example, you can't add collaborators until you've uploaded at least one revision
<kyrofa> (at least, last I checked)
 * Chipaca returns from the void
<kyrofa> Chipaca, lost in time and space? (arkham horror reference /me hopes someone gets)
 * Chipaca hugs kyrofa 
<Chipaca> kyrofa: nobody gets it, but we like you anyway
<Chipaca> :-p
<kyrofa> :(
<Chipaca> :-D
 * kyrofa hugs Chipaca back anyway
<Chipaca> kyrofa: in my defence, I've just been through 11 interviews with as many teachers in an hour and a bit, so I'm feeling slightly evil
<ogra_> and ? are your kids hired
<ogra_> ?
<Chipaca> it's a bit of a record I've only had to censor myself with one of them
<kyrofa> Chipaca, oh brutal
<Chipaca> ogra_: I think they go to the next phase because of audience votes
<ogra_> lol
<Chipaca> ogra_: the jury definitely voted them out
 * Chipaca wonders if he should bling up his PR so it gets reviews
<pedronis> Chipaca: is the service refactor reviewable? or does it need changes because of this morning discussions?
<Chipaca> pedronis: it's reviewable
<Chipaca> pedronis: it includes what I think is the outcome of this morning's discussions, already
<pedronis> ok
<pedronis> Chipaca: snapd#3322 needs a 2nd review
<mup> PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
<kyrofa> Chipaca, I hear ALL CAPS and containing "you won't believe what happens" helps
<Chipaca> kyrofa: http://www.commitstrip.com/en/2014/08/07/our-cto-has-discovered-an-incredible-way-of-making-developers-read-his-commit-messages-you-wont-even-believe-how-he-did-it/?
<ogra_> pedronis, boo ... now you made us all miss the opportunity to see how a blinged up Chipaca PR looks like
<Chipaca> ogra_: so. much. unicode
<ogra_> haha hands and all ?
<kyrofa> Chipaca, hahahahaha, EXACTLY what I was talking about
<Chipaca> ogra_: the only limit is the version of unicode people have
<kyrofa> "This was the most stupid bug in the world, fixed in the smartest way ever" <- how I feel about much of my work, but no one realizes it was my bug in the first place
<Chipaca> ogra_: like, if i want to use an avocado, i'd better hope people are on yakkety
<Chipaca> kyrofa: :-D
<ogra_> dang ... no avocados for me then
<Chipaca> ogra_: ð¥
<ogra_> :(
<Chipaca> ogra_: ð¤?
<ogra_> trapped in 16.04 .... only square avocados
<ogra_> that one works !
<Chipaca> see? that one's in unicode 8 :-)
<pedronis> Chipaca: we never have services so far in snapstate tests ?
<Chipaca> pedronis: correct
<Chipaca> pedronis: ARE YOU SCARED
<pedronis> no, but IÂ need to say something in the review
<Chipaca> ok :-)
<pedronis> Chipaca: reviewed
<Chipaca> woo
<Chipaca> psh! tests
<pedronis> Chipaca: I think now I understood your question from the ther day, and IÂ answered it, the alias tests have a similar problem
<pedronis> they needed actual apps
<pedronis> at Info-level actual apps
<Chipaca> yeah
<pedronis> s/at/at least/
<Chipaca> ah well, I'll dig into that tomorrow
<pedronis> sorry
<Chipaca> was going to have to do it at some point anyway
<Chipaca> no problem! you're probably right :-)
<Chipaca> (otherwise i'd argue back -- you know i do)
<pedronis> but you need to change all the tests anyway
<pedronis> so :/
<Chipaca> Â¯\_(ã)_/Â¯
<pedronis> I mean is not like you managed not to touch them there
<Chipaca> I did say I had 21 failing tests :-)
<Chipaca> pedronis: thank you for the review!
<sdrobertw> [Ubuntu core question] Does Ubuntu core supports any library to deploy the built-in GPS in DB410c, just as android has?
<sdrobertw> [Ubuntu core question] Is there a way to "convert" existing SW applications installed via RPM or apt-get, to snappy packages so I can install them on DB410c?
<Chipaca> ogra_: is that the dragonboard we support?
 * Chipaca never remembers
<kyrofa> Chipaca, indeed
<ogra_> Chipaca, yes, but we dont have any userspace snaps for GPS or anything
<Chipaca> ogra_: what interface is it?
<ogra_> (i'm not even sure we have a snap interface for GPS yet)
<ogra_> no idea ... never used it
<Chipaca> i mean, usb? i2c? potato-over-carrier-pidgeon?
<Chipaca> ah
<ogra_> (i rarely carry moy board outside, to even get a sattelite fix)
<ogra_> *my
<kyrofa> sdrobertw, I'll let these guys debate over your first question, but your second question: you can tell snapcraft to unpack debs into a snap using `stage-packages`
<kyrofa> sdrobertw, but that needs to be done on a machine with those debs available via their sources.list configuration. If this is just a deb you have, you can supply it directly via the `source` keyword
<ogra_> sdrobertw, https://github.com/ogra1/laidout is a very ugly but working way ... (pretty old snap i guess there are better ways to get rid of the wrapper.sh nowadays)
<ogra_> indeed, if you want to just use a deb from the ubuntu archive, just stage-packages shoudl eb enough
<ogra_> *should be
<kyrofa> sdrobertw, the one complication you can run into by essentially packaging a deb as a snap is that a snap is mounted in a particular directory: where the deb might be configured to reach out to /usr/share, it now need to to use $SNAP/usr/share
<kyrofa> Just depends on the application
<sdrobertw> will you join OpenHours real quick?
<kyrofa> Sure!
 * ogra_ sadly can't ... on my way out the door, only Chipaca's ping stopped me
<sdrobertw> http://link.linaro.org/openhoursjoin
 * Chipaca hugs ogra_ 
<sdrobertw> Thanks!
<Chipaca> ogra_: have a good one
 * ogra_ hugs Chipaca 
<ogra_> you too
<kyrofa> Those germans, always leaving at the beginning of the day
<ogra_> kyrofa, but we also dont sleep til afternoon
<ogra_> !
<kyrofa> Hahaha
<sdrobertw> 943216362
 * ogra_ looks around in case there are any asian earlybirds still up :P
 * Chipaca fades into the bushes
<kyrofa> sdrobertw, you know where to find us if you have questions when making those tutorials-- always happy to help!
<sdrobertw> Thanks for all of your help ogra_ and kyrofa
<kyrofa> sdrobertw, any time
<morphis> mvo: https://github.com/snapcore/snapd/pull/3307 is ready for merging too :-)
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<mup> PR snapd#3351 closed: errtracker: small simplification around readMachineID() <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3351>
<niemeyer> morphis: ping
<morphis> niemeyer: pong
<niemeyer> morphis: Heya
<morphis> hey!
<niemeyer> morphis: Quite note on PR process: we avoid rebasing while changes are in review, otherwise we lose track of what was reviewed
<niemeyer> s/Quite/Quick
<niemeyer> morphis: snapd#3222 as one example
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<morphis> niemeyer: fine for me, trying to keep my git log clean but if that is preferred I will follow that
<niemeyer> morphis: Without the rebase, I could click on "View changes" since my last review and get an idea of where we are
<niemeyer> morphis: Feel free to keep it anyway you want before pushing for review.. after that, it's more important that people can track what is being done, otherwise it's a full review every time
<morphis> aye
<morphis> niemeyer: what are you referring to with "I would actually prefer the original approach. "?
<morphis> niemeyer: what I implemened or what mvo suggests?
<niemeyer> morphis: Neither.. the original one, in the tree
<niemeyer> morphis: systems: -debian* feels pretty good to me
<morphis> niemeyer: the thing is that we want to run portions of these tests
<morphis> as we have a bundled situation with seccomp enabled but AppArmor not
<morphis> so we want at least verify the connected part of the interfaces tests works fine
<morphis> but leave out the parts which verify the interface denies things
<morphis> (the disconnected case)
<niemeyer> morphis: Ah, I see
<niemeyer> Okay, let me provide a new review then
<morphis> niemeyer: thanks!
<niemeyer> morphis: np, review updated
<mup> PR snapcraft#1323 closed:  state: search for the build package that provides a virtual package <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1323>
<mup> PR snapcraft#1315 closed: lxd: mock platform in the FakeLXD fixture <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1315>
 * ahoneybun wonders when the filesystem bug would be fixed
<ahoneybun> elopio: ^
<kyrofa> ahoneybun, which filesystem bug?
<ahoneybun> well all the snaps show as loop devices in file managers
<ahoneybun> dolphin and nautilus
<davhou> @ogra, OK, so back to my id, can you tell me what the folder ownership should be for /run/snapd?
<nothal> davhou: No such command!
<davhou> ogra_,  OK, so back to my id, can you tell me what the folder ownership should be for /run/snapd?
<davhou> ogra_, it was root:david although I am getting the same error message as id david when i try to run the snap
<kyrofa> davhou, mine is the same
<davhou> kyrofa, the ownership on folder?
<kyrofa> davhou, yeah
<kyrofa> (but no errors here)
<kyrofa> Though that surprises me a bit... what happens with multiple users?
<kyrofa> noise][, is transferring snap IDs to other publishers easy these days? Or still a yucky manual process? i.e. should I still be giving the "register <snap>-<nick>" advice?
<noise][> kyrofa: easy
<kyrofa> noise][, excellent!
<noise][> we still want reasonable commitment / justification to take a reserved name, but we've been a lot more free with them since transfers got easy
<kyrofa> Of course, makes sense
<kyrofa> noise][, okay, a harder question: if I was starting today, I'd request the upstream name. However, I'm not, and I have thousands of users (well, downloads anyway) of my snap. Do we have a process for renaming snaps?
<kyrofa> noise][1, looks like your internet flaked there, not sure if you saw my question
<noise][1> nope, sorry
<nacc> kyrofa: fwiw, i recently renamed a snap by adding a wrapper to my old snap's yaml that replaced teh comamnds with 'please don't run this, use this snap isntead'
<kyrofa> nacc, yeah... I don't want to do that to my users though
<nacc> kyrofa: i wish there was some sort of rename op at the store level, but it would force the store to carry historical state (forever?)
<nacc> and i'm not sure if it's organized in that way (i have no idea, i mean)
<kyrofa> nacc, not really: nothing in snapd cares about the name, it uses a snap ID
<kyrofa> That's not quite true, the name is used to form file paths
<kyrofa> So that sounds hard
<kyrofa> So the store would probably be fine with it, but snapd will probably barf
<kyrofa> I'll just live with my namespaced snap name
<nacc> kyrofa: oh i didn't realize it was all via IDs
<nacc> so it could in theory have a lookup table for IDs
<nacc> (the store)
<nacc> but yeah, snapd would need to dtrt
<kyrofa> Indeed
#snappy 2017-05-19
<niemeyer> Forum update coming...
<niemeyer> It's back up
<elfgoh> ogra_: any idea if the i2c interface is enabled on the Raspberry Pi?
<zyga> good morning
<abeato> zyga, hey, regarding https://github.com/snapcore/snapd/pull/3324 , if you strongly think that the file vars should be ordered, I can do that... tbh not that I agree, but I do not want to block on that. There is another PR that I need to push on top of this one.
<mup> PR snapd#3324: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3324>
<zyga> abeato: hey
<abeato> zyga, o/
<zyga> abeato: it's just my preference for deterministic behavior but I can merge it right away
 * zyga looks
<abeato> zyga, yes, I understand that but also I think that some times not being completely deterministic is good, so programs that read the file are not tempted to rely on deterministic content, which would be bad if, say, a new var is added
<abeato> zyga, and if that comes at the price of a (slightly) more complex code, then it is something I would usually not do
<abeato> zyga, but anyway, not that I mind changing it, just different POVs imo :)
<zyga> abeato: done
<mup> PR snapd#3324 closed: partition,snap: add support for android boot <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3324>
<abeato> zyga, thanks!
<zyga> abeato: I agree
<zyga> abeato: so what's the next step?
<abeato> zyga, gimme a minute and you'll see it :)
<mup> PR snapd#3352 closed: interfaces/log-observe: allow using journalctl from hostfs for classic distro <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3352>
 * zyga looks at https://github.com/snapcore/snapd/pull/3349
<mup> PR snapd#3349: many: model and expose interface meta-data <Created by zyga> <https://github.com/snapcore/snapd/pull/3349>
<zyga> hmm
<zyga> actually, not at that one
<zyga> 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>
<abeato> zyga, hmm, I see compile errors in current master: http://paste.ubuntu.com/24603514/
<pedronis> abeato: you need to update deps
<abeato> pedronis, ah, thanks
<pedronis> get-deps.sh
<abeato> zyga, this: https://github.com/snapcore/snapd/pull/3353
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<mup> PR snapd#3353 opened: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<zyga> abeato: thanks!
<abeato> np
<abeato> Does anybody know why run-checks could be producing these errors: http://paste.ubuntu.com/24603574/ ?
<abeato> in a clean master checkout, I mean
<zyga> abeato: maybe more recent shellcheck
<zyga> Chipaca: ^^
<zyga> abeato: what kind of reboot parameters are we going to see typically?
<zyga> abeato: I'm not too fond of the C parts, I may choose to rewrite that a little
<zyga> Chipaca: good morning :)
<Chipaca> abeato: that's shellcheck from zesty
<abeato> zyga, "recovery". It could be "bootloader" too. they are typical android partitions/modes
<elfgoh> Does anyone know if the i2c interface works in Ubuntu core on the Raspberry Pi3?
<zyga> abeato: I'd much rather see an enum to be honest
<zyga> elfgoh: hey
<zyga> elfgoh: I know for a fact that it may work :)
<Chipaca> abeato: if it's blocking you i can fix
<zyga> elfgoh: but I didn't update my snap in a while
<zyga> elfgoh: I made a snap that used i2c to talk to some LED controller
<elfgoh> Great. Do you have your snap on github?
<abeato> zyga, note that the way the parameter is passed is the one used by systemd, not something I worked out
<zyga> elfgoh: and tested it on pi2 and pi3
<abeato> Chipaca, nw, just found it surprising
<zyga> abeato: can you document that please?
<zyga> elfgoh: yes
<elfgoh> I would like to refer to the snapcraft.yml
<abeato> zyga, sure
<zyga> elfgoh: https://github.com/zyga/snappy-pi2-piglow
<zyga> elfgoh: note that this is very old (it talks about skills, not interfaces)
<abeato> zyga, it is coded so systemd command "reboot recovery" works as expected too
<zyga> elfgoh: you can update it and I'll happily take pull requests
<elfgoh> Oops. I have never heard about skills :o
<zyga> elfgoh: those are "interfaces" now
<zyga> elfgoh: just when snappy was very young :)
<elfgoh> Actually, I am trying to get a humidity sensor working via i2c
<zyga> elfgoh: do you have the datasheet for that?
<elfgoh> Hang on a min
<elfgoh> But I do know for a fact that the program works outside of a snap
<elfgoh> zyga: this is the datasheet http://www.silabs.com/documents/public/data-sheets/Si7021-A20.pdf
<elfgoh> But one thing for sure, when we booted Ubuntu Core, i2c is in the list when running "$ snap interfaces"
<zyga> elfgoh: nice,
<elfgoh> Is that expected?
<zyga> elfgoh: yes, i2c is supported now
<zyga> elfgoh: on a given device, it's not universal
<elfgoh> sorry correction. i2c isnt in the list
<zyga> elfgoh: can you pastebin "snap interfaces" on your device?
<zyga> elfgoh: and snap version
<elfgoh> So i2c is supported, but not necessarily on the rpi?
<elfgoh> Ok hang on
<zyga> elfgoh: it depends on gadget
<zyga> elfgoh: ppisati and ogra_ can fix that if needed
<ogra_> i think we dont have tegh interface in the gadget ...
<zyga> ogra_: can we add one quickly?
<ogra_> elfgoh, can you access i2c from the cmdline without having the app in a snap ?
<ogra_> (i.e. install the classic env to get apt support and access it from there)
<elfgoh> zyga: this is the output of interfaces
<ogra_> zyga, if we know the kernel has all bits we can indeed enable it quickly in edge
<elfgoh> snap version
<elfgoh> snap    2.26.3+201705181256.git.035e139~ubuntu16.04.1
<elfgoh> snapd   2.26.3+201705181256.git.035e139~ubuntu16.04.1
<elfgoh> series  16
<elfgoh> kernel  4.4.0-1051-raspi2
<zyga> ogra_: well, that's a question for you and ppisati :)
<zyga> ogra_: but I think it does
<ogra_> zyga, well, thats a question i was just asking elfgoh :)
<zyga> elfgoh: ok, you are on the latest edge
<ogra_> if the kernel provides all he needs we can just turn it on
<zyga> ogra_: we should test and enable it, it's a ref platform and the snapd part is in place
<ogra_> zyga, yes
<elfgoh> ogra: yes we can access i2c from cmdline in classical snap
<zyga> ogra_: sounds like a yes :)
<ogra_> zyga, obviouslly elfgoh has a usecase to test :)
<elfgoh> Yup most certainly!
<ogra_> great
<elfgoh> Actual hardware here
<elfgoh> Working outside of snap, giving humidity and temperature readings
<Chipaca> abeato: so in androidboot reboot is always equivalent to 'systemctl reboot recovery'?
<abeato> Chipaca, correct. But unfortunately "shutdown +time recovery" does not work the same, the parameter is ignored
<elfgoh> ogra_: quick question I have a colleague who created a snap that execs a command and is able to run ps command
<elfgoh> Is this expected?
<abeato> Chipaca, systemd bug I'd say
<abeato> Chipaca, https://github.com/systemd/systemd/blob/master/src/systemctl/systemctl.c#L8262
<Chipaca> shutdown isn't documented as taking 'recovery' as an arg
<elfgoh> ogra_: fwiw this colleague is using docker as a reference point
<abeato> Chipaca, it is not "recovery", it is a generic argument that the syscall accepts
<Chipaca> shutdown isn't documented as taking any argument beyond time or 'now'
<abeato> well, yes, but "reboot" command takes it
<ogra_> zyga, https://github.com/snapcore/pi3-gadget/pull/7
<mup> PR pi3-gadget#7: add i2c interfaces <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/7>
<Chipaca> abeato: "systemctl reboot" does
<Chipaca> abeato: reboot on its own does as well?
<ogra_> elfgoh, yes, but ps will only show the processes realted to the snap AFAIK
<zyga> ogra_: approved :)
<Chipaca> abeato: anyway, my quesiton is, in androidboot, all reboots are reboots into recovery?
<Chipaca> that seems wrong to me, which is why i ask
<abeato> Chipaca, yep, it is just a symlink to systemctl
<zyga> Chipaca: it's the design
<zyga> abeato: I think it should be documented there
<zyga> abeato: it's not obvious
<abeato> Chipaca, no, only when we are updating kernel/core
<zyga> abeato: I only know this because I paid attention to some internal traffic
<Chipaca> abeato: the PR you have up always does recovery reboot in androidboot
<Chipaca> in fact, it always does 'reboot recovery' no matter how you tell systemd to shut down
<abeato> Chipaca, so maybe the code is wrong there :) How can I know when I want to reboot because of a kernel/core update? I thought that was the only case in daemon.go call
<Chipaca> ah!
<Chipaca> might be getting confused because of that
<Chipaca> heh
<abeato> zyga, sure will add that to the PR
<abeato> Chipaca, maybe I couls change the name from Reboot() to RebootAndUpdate() or something like that
<elfgoh> zyga: ogra_ woot! Thanks! when will the pi3 gadget snap be update with the merge?
<Chipaca> abeato: or RebootForCoreUpdate or whatever
<elfgoh> ogra_: let me get additional details about the implementation
<Chipaca> i'm bad at names, but yes, Reboot misguided me there
<ogra_> elfgoh, https://code.launchpad.net/%7Ecanonical-foundations/+snap/pi3 should start building in a minute
<abeato> Chipaca, ok, will change it :)
<zyga> elfgoh: yes, soon
<elfgoh> \o/
<morphis> zyga, mvo: can we get https://github.com/snapcore/snapd/pull/3307 merged?
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<morphis> ogra_: would the i2c slots make sense for the pi2 gadget too?
<ogra_> morphis, as soon as i know everything works for elfgoh i'll add them there too
<morphis> ogra_: great!
<ogra_> the dragonboard will really need that stuff too ... its rather lacking ...
 * zyga needs to go to the bank
<ogra_> Chipaca, abeato yes, in androidboot all reboots should be recovery reboots ... (recovery will hold the rollback and upgrade mechanisms, all reboots shoudl go through that)
<ogra_> abeato, i was about to ask, why you not just hardcode it :)
<abeato> ogra_, well, if the systemd mechanism is already there, better to use it, so we additionally have "reboot bootloader" working too, for instance ;)
<ogra_> there is no need too make a difference ... recovery serves the same purpose as the uboot shell (scripting and recovery mode)
<ogra_> so any reboot should be a recovery reboot ...
<Chipaca> ogra_: hold on
<Chipaca> ogra_: there's two parts to it
<ogra_> i wonder if we cant do that on a systemd level instead and leave out snapd completely
<Chipaca> ogra_: one is the part in snapd that triggers a reboot because of core/kernel/gadget change
<ogra_> Chipaca, right, there is no need to make any difference here
<Chipaca> ogra_: the other is shutdown-helper, which is called unconditionally by systemd on any shutdown/reboot/halt/kexec
<ogra_> it could be a hardcoded thinng on systemd level instead
<abeato> ogra_, we need to modify system-shutdown command for sure
<Chipaca> ogra_: shutdown-helper cannot be hardcoded in the way you describe
<Chipaca> ogra_: but snapd can (and is)
<ogra_> Chipaca, doesnt it just call reboot
<ogra_> ?
<ogra_> and hand off to systemd
<Chipaca> ogra_: no, systemd execve's into it
<Chipaca> ogra_: it runs as pid 1
<Chipaca> ogra_: there is no systemd
<ogra_> ah
<abeato> ogra_, writes "recovery" to "/run/systemd/reboot-param", then calls sysnted reboot
<ogra_> yes, i see the code
<ogra_> my point is ... there is no need to make a difference
<ogra_> every reboot should go through recovery
<Chipaca> ogra_: on androidboot
<ogra_> Chipaca, yes
<Chipaca> ogra_: but not on uboot
<abeato> wel, I think we are better modifying snapd instead of systemd, which would mean a patch
<Chipaca> ogra_: (system-shutdown doesn't know what bootloader you're on; snapd does)
<ogra_> Chipaca, right ... but our gadget knows that ... so it could ship a systemd config that always makes it "reboot recovery"
<abeato> also, I would prefer reboot command to work in a normal way too
<ogra_> uh
<ogra_> but that means you will be able to reboot without the safety new
<ogra_> *net
<Chipaca> ogra_: is it really just a systemd config?
<ogra_> Chipaca, in my imagination it is :P i dont know ... but it should
<Chipaca> :-)
<Chipaca> it's possible it is, but i don't know
<Chipaca> (there is a unit for reboot)
<ogra_> right
<abeato> ogra_, not sure what you mean... if we are upgrading, then yes, go to recovery. But we want plain reboot or "reboot booloader" commands to work
<abeato> from command line
<ogra_> abeato, why ?
<ogra_> and what cmdline
<abeato> well, for developers
<abeato> shell
<fgimenez> good morning zyga, i've just updated the revert test in snapd#3348, if you could have a look when you have some time that would be great, there are some refactors in there, the test itself is https://github.com/snapcore/snapd/pull/3348/files#diff-4825fd024a235e7895b109ad37072e68
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<ogra_> the shell is the recovery env
<ogra_> like you have a uboot chell on uboot installs or a grub shell in grub installs
<ogra_> the only moment you boot without recovery is a cold boot
<abeato> disagreed, I would like to reboot to bootloader to flash a new kernel image using fastboot as a developer
<abeato> for instance
<ogra_> the only moment you need the bootloader is when you flash
<ogra_> i.e. the initial flashing
<ogra_> abeato, if you want to manually replace the kernel you dd it from the recovery shell
<morphis> ogra_, abeato: btw do we have the full process documented somewhere?
<elfgoh> Got the edge pi3 snap. Giving it a go
<ogra_> i donmt really want fastboot to work on production devices by default so that random people passing by could replace your image
<ogra_> morphis, we have that forum thread
<morphis> ..
<morphis> I mean a structured document which covers the latest agreed process
<morphis> could easily go on docs.ubuntu.com
<abeato> ogra_, honestly I do not think we should ardcor reboot to recovery in systemd
<ogra_> thats all we have atm ...
<abeato> *hardcore
<abeato> *hardcode
<ogra_> abeato, well, how else do we want to make sure that every boot goes through the rollback mechanism ?
<ogra_> we want the same behaviour as in any other snap install ...
<pstolowski> zyga, hey, commented on the upgrade-all-dependencies PR
<pstolowski> zyga, also, +1 on iface metadata, so it has two reviews and can land; not sure if you want Gustavo to review this change
<ogra_> pedronis, i just refreshed my gadget snap on the pi3 ... shouldnt i get an auto-reboot ?
<pedronis> ogra_: no
<abeato> ogra_, when there is a panic, we go to recovery, that is hard-coded in the kernel
<pedronis> ogra_: we don't reboot on gadget changes so far
<pedronis> we will need to do if we change assets I suppose
<ogra_> abeato, and when we upgrade ... and when someone tinkers for development ... and ... and ...
<pedronis> ogra_: so far only core and kernel trigger restart/reboots
<ogra_> pedronis, oh, i see ... interface changes get applied without reboot!
<ogra_> thats sweet!
<pedronis> if it works it is :)
<ogra_> ogra@pi3:~$ snap interfaces|grep i2c
<ogra_> pi3:i2c-0                 -
<ogra_> pi3:i2c-1                 -
<ogra_> pi3:i2c-2                 -
<ogra_> pi3:i2c-2                 -.d
<ogra_> oops
<ogra_> :D
<elfgoh> @ogra_ zyga : glad to report that the new pi3 gadget works well with i2c :D
<nothal> elfgoh: No such command!
<ogra_> elfgoh, \0/
<elfgoh> ogra_ zyga : glad to report that the new pi3 gadget works well with i2c :D
<ogra_> awesome
 * ogra_ prepares the same change for pi2
<elfgoh> Quick question: my humidity snap currently needs sudo in order to get my snap reading humidity via i2c. What is the way to remedy that?
<abeato> ogra_, you cannot forsee all cases, one of the things that was clear in the thread is that this solution would not be 100% safe until we had devices with 2 boot partitions. What about the case of somebody powering off the device after something bad happened instead of rebooting? In next boot, things would go wrong
<ogra_> abeato, well, how would you overcome that case ?
<ogra_> (without access to the bootloader)
<ogra_> even two boot partitions wont help there
<abeato> ogra_, you can't, the point is that anyway this solution is limited
<abeato> ogra_, 2 partitions would help as you would actually boot using the old one, as you would not hae switched yet the main partition if something went wrong... but you cannot do that if there is only one
<ogra_> zyga, https://github.com/snapcore/pi2-gadget/pull/7
<mup> PR pi2-gadget#7: add i2c interfaces <Created by ogra1> <https://github.com/snapcore/pi2-gadget/pull/7>
<ogra_> abeato, i dont get that ... how would you switch without having support for that in the bootloader ?
<abeato> ogra_, I understand that if you get 2 boot partitions you also get that sort of support from the bootloader, would not make much sense otherwise (maybe ondra knows about this?)
<ogra_> well, if the bootloader is designed for such a setup
 * ogra_ hasnt seen that before ... 
<ogra_> typically you can only toggle between recoovery and normal boot
<elfgoh> ogra_: I believe it may be a similar issue for serial port interface, since it didnt come out on the list of interfaces
<ogra_> and there you want to go through recovery if any possible in our setup ... rercovery replaces the bootloader shell and scriptery in this case
<abeato> ogra_, yes, but one thing that ondra mention is that newer devices with android 7 have two boot partitions for safer upgrades, and in that case you need a way to tell the bootloader to use one or another when powering on the device
<abeato> (can have)
<ogra_> abeato, so we dont support anything with a base older than android 7 ?
<abeato> ogra_, we do, but we assume that the solution is not 100% sage
<abeato> *safe
<ogra_> (also ... how would we integrate that bootloader behaviour with our setup)
<ogra_> (this seems very bootloader internal, how wuld we manage the rollback and such ?)
<abeato> we will tackle that when we get to it, usual bussiness ;)
<ogra_> right, and until then i'D like to have the safest mechanism through recovery ...
<ogra_> which holds exactly that part of the logic
<elfgoh> With regards to process isolation, this is what my colleague tried and it seems like one snap can view another snap's processes https://gist.github.com/choonkeat/a398244e3ce406ad1ee27448f383c7aa
<ogra_> elfgoh, i think you can view them but not get any additional data about them
<ogra_> elfgoh, hmm, also ... sudo ?
<ondra> ogra_ I assume there is some higher level api which will unify all bootloader implementations
<ogra_> ondra, yes, in a not yet existing version :)
<ondra> ogra_ as this should be inherited feature of android 7 onwards and it's controlled by OS
<ogra_> ondra, we need to deal with the existing one ;)
<ondra> ogra_ in already existing
<ogra_> well you knwo what i mean
<ondra> ogra_ there are already phones with this setup
<ogra_> fine for these phones ... are there customers with boards that use it ?
<ondra> ogra_ that's different topic :)
<ogra_> and are you sure there will only be boards with 7 onwards ?
<ogra_> ondra, well, the current topic is the current setup ... what android based boards do we have right now ?
<ogra_> (what version)
<ondra> ogra_ I just mentioned this feature, to make sure we do not choose solution which we will need to re-engineer once we start seeing those boards :)
<ogra_> ondra, well, we need to see how we can blen in our setup with that bootloader then ... if at all ...
<ogra_> *blend
<ogra_> but for now we dont have that and need an implementation that deals with the existing situation
<elfgoh> ogra_: is it possible to evaluate if being able to view other processes is really necessary? This "feature" causes discomfort
<ogra_> wasnt there actually a way to set the boot reason on cmdline ?
<Chipaca> abeato: âIt is defined by snapd:â <- i think you meant systemd
<abeato> Chipaca, yep, lust corrected :)
<ondra> ogra_ there is way
<abeato> *just
<ondra> ogra_ but it's not persistent
<Chipaca> :-) ok
<ondra> ogra_ so does not do for cold boot
<ogra_> elfgoh, thats a jdstrand question i fear ... you might need to wait til he gets up (US timezone)
<ondra> ogra_ therefore I suggested to use recovery as test path
<ogra_> ondra, why not ? if it is in boot.img does it get re-written there ?
<elfgoh> ogra_: Ok got it will nudge jdstrand when he is awake
<ondra> ogra_ you prepare update files, reboot to recovery with cmd line boot reason, and if it boots, you move that image to boot partition
<ondra> ogra_ no it's just in memory
<ogra_> ondra, after modifying it
<ondra> ogra_ it sets flag which bootloader can read
<ogra_> ondra, recovery will modify the cmdline befiore flashing boot,img
<ogra_> ondra, right and we could just have that in every boot.img
<ogra_> that would make sure we always go through recovery
<ogra_> ondra, if we update core the cmdline needs to carry the new snap_core ... if we need to modify it anyway we can also always  add the bootreason
<ogra_> that is why i want it to go through recovery with any reboot ...
<ondra> ogra_ but boot reason is not in cmdline
<ondra> ogra_ that is too late
<ogra_> that was my initial question ;)
<ogra_> thanks :)
<ondra> ogra_ boot reason is read by bootloader, to determine from which partition to load next boot step
<ogra_> right
<ondra> ogra_ boot/ recovery
<elfgoh> ogra_ zyga: sorry to nudge you again. Was wondering if the serial-port interface is ready to be supported on the pi3?
<elfgoh> I have a use case for it too :)
<ondra> ogra_ therefore I suggested, using boot reason for test boot, will always put us back to working (boot partition) case by nature of it, as for next/cold/crash reboot we have no boot reason -> boot partition
<ogra_> elfgoh, what kind of serial ... on the pi3 ttyAMA0 is already taken by the BT interface
<ogra_> elfgoh, would that be any additional serial device =
<ogra_> ?
<ogra_> ondra, what if the boot partition holds a broken version
<ogra_> ondra, i want to always go to recovery first
<elfgoh> ogra_: it would be under /dev/serial
<ogra_> elfgoh, thats taken by the console by default
<elfgoh> https://www.irccloud.com/pastebin/qXSDL82F/
<ogra_> (or will soon be, ondra suggested some cvhanges there that i didnt add yet)
<ogra_> elfgoh, i fear that wouldnt work ... since we have console=ttyS,... (or later console=serial,...) on the kernel cmdline ... so that device is occupied in our default setup ...
<ogra_> elfgoh, you would need your own gadget that drops console=(serial,ttyS0) and add your own serial interface to snapcraft.yaml
<ogra_> we cant really drop that console in our developer images
<ogra_> oh, i should have looked at your paste first ...
<ogra_> so you use a USB dongle there
<elfgoh> yup yup :)
<elfgoh> Oh sorry. didnt know how irccloud snippet is showing up in other clients
<ondra> ogra_ no that is the point, boot will hold verified version, you test in recovery partition new update, only if recovery version boots fine, it will be moved to boot partition
<ogra_> well, thats also something you will need your own gadget for ... iirc the USB serial interface wants vendor ID and product ID
<ondra> ogra_ so version in boot partition is always good verified one
<ogra_> ondra, but we only verify by having a successfully finished boot
<ogra_> ondra, to boot the new img you first need to flash it into the boot partition and then reboot without recovery ... and only if the boot succeeds the boot img is deemed good
<elfgoh> ogra_: pardon if i have any wrong assumptions, but would it be sensible to have the pi3 gadget have an interface that opens up /dev/serial?
<ogra_> ondra, now ... if you have a broken reboot and dont finish because core was broken or your kernel paniced you neerd to go back to recovery and re-flash the former version
<ogra_> ondra, there will be a point where the boot partition holds a broken boot.img and the only way to auto-fix that is to go through recovery and re-flash
<ogra_> elfgoh, yes, for tewh internal serial device *if* that isnt used as console
<ondra> ogra_ no, not this way. you get new image, you flash it to recovery, and do test boot, you do not touch boot partition, only of you have sucessfull boot through recovery then you move it to boot partition
<ondra> ogra_ so at any time boot partition is always verified boot option
<ogra_> ondra, thats notr what we discusssed
<ogra_> ondra, something needs to have the scriptery for rollback of core and kernel
<ogra_> thwe only way to have that is recovery
<pedronis> Chipaca: hi, how it's going with your PR ?
<ondra> ogra_ if you invent some different way to do it, then do not ask me, why it's not working :)
<ogra_> and if you assume that the only thing that can actually boot otherwiose is the boot partition, it is the oone that always holds the running kernel
<ogra_> ondra, we have a long thread on the forum where that was discussed
<ogra_> ondra, recovery needs to always hold our logic ...
<Chipaca> pedronis: need moar coffee
<ondra> ogra_ I thought logic is in snapd
<ogra_> if you just dump a boot.img into the recovery partition, where would you put the rollback logic (that needs to run *before boot*
<ogra_> ondra, half of it
<ogra_> ondra, the oother half is "before booting"
<ondra> ogra_ boot/recovery is just kernel + initrd
<ondra> ogra_ so you gonna add logic to initrd?
<ondra> ogra_ and bootloader will load kernel from that partition, no logic there
<ogra_> ondra, righ, buit recovery has the original kernel the board was initially flashed with and additional scripts (translated from the grubn/uboot ones)
<ogra_> ondra, exactly ... the recovery initrd has the script logic we usually have in uboot/grub
<ondra> ogra_ where do you have those additional scripts? in initrd?
<ogra_> ondra, and will never be touched so we have a guarantee you can always boot into that mode ... like you can always intercept autoboot in uboot or grub
<ondra> ogra_ ok then we if we are adding logic to initrd, I'd suggest to unify and use that inird logic for all platforms
<ogra_> ondra, we do ... in the uboot hush shell or in the grub shell scripts
<ondra> ogra_ something I mentioned before I don't see reason why u-boot should be handling versions for core snap
<ogra_> ondra, because it needs to be able to roll back when a boot failed
<ogra_> *before* booting
<ondra> ogra_ and initrd would not be able to do roollback?
<ondra> ogra_ or you are assuming update of core + kernel in one go?
<ogra_> it would but you would have to re-design the whole process from the groound up
<elfgoh> ogra_: we are a bit confused. Are we talking about the same console? The one at /dev/ttyS0? Are you saying that there will be plans to change it to use /dev/serial?
<ogra_> and have twop different implementations for kernel vs core
<ondra> ogra_ that's only case I can think of when you don't reach even to initrd
<ogra_> ondra, there are a muillion cases where you cant reach initrd ... your kernel panics ... your initrd is messed up etc etc
<ondra> ogra_ yes some rework, but then you have one implementation for all u-boot/grub/android, core revisions will be always handled in one place
<ogra_> ondra, also dont forget that one day our initrd comes from core
<ogra_> (if i ever find the time for the split initrd)
<ondra> ogra_ and you leave kernel revision handling to bootloader
<ondra> ogra_ ha?
<ondra> ogra_ initrd from core?
<ogra_> ondra, seriously ... that isnt really relevant for the stuff here
<ogra_> you can propose to move the core handling to initrd ... but that wont change the kernel initrd side
<ogra_> it will just add additional code and logic in the end ...
<ondra> ogra_ ogra again, if you made up your mind how to implement it, there is no way somebody will convince you otherwise, but then don't ask me why it's not working :D
<ogra_> but wont fix the probelm we are currently trying to solve
<pedronis> Chipaca: :)  ( still need a review for snapd#3322  :) )
<mup> PR snapd#3322: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <https://github.com/snapcore/snapd/pull/3322>
<elfgoh> ogra_: let me try again. the "serial-port" interface is supported, but not enabled on pi3 gadget. Correct?
<ogra_> elfgoh, right
<Chipaca> pedronis: on it!
<pedronis> Chipaca: it's big but mostly the tests
<ogra_> elfgoh, and console= occupies the device on a booted system
<elfgoh> ogra_: doesnt console=/dev/ttyS0 on pi3 on Ubuntu Core?
<ogra_> elfgoh, yes
<ogra_> elfgoh, so the internal serial is taken ... for your usb serial you need to add anothert interface to snapcraft.yaml
<ogra_> ondra, i dont get how the initrd is relevant here ... it wouldnt fix the problem
<elfgoh> ogra_: i am assuming that you are referring to the snapcraft.yml of a gadget snap?
<ogra_> elfgoh, exactly
<ogra_> to enable the interface you need your own gadget snap
<ondra> ogra_ it would not fix it, it will make various bootloader support easier, as we will only worry about kernel revision, but as you said initrd will be coming from core, so I guess this is off the table anyway
<ogra_> ondra, well, half of the initrd :)
<ogra_> (the relevant half though)
<elfgoh> ogra_: based on our understanding devices populated /dev/serial/, eg eg $ ls /dev/serial/*
<elfgoh> /dev/serial/by-id: usb-FTDI_FT230X_Basic_UART_DM007FNY-if00-port0  usb-FTDI_FT230X_Basic_UART_DM007X1O-if00-port0, can change their device names unpredictably. Therefore it seems unfeasible to hardcode the interface path in snapcraft.yml. Or is there another way to handle such dynamic interfaces?
<ogra_> elfgoh, well ... dio you have a /dev/ttyUSB* ?
<ogra_> assuming you only ever have one USB dongle attached you should be able to use a rather simple interface definition
<ogra_> (same as bt-serial in https://github.com/snapcore/pi3-gadget/blob/master/snapcraft.yaml but with your own name and pointing to /dev/ttyUSB0 (or whatever number your sevide gets))
<elfgoh> ogra_: we have multiple usb serial devices. The device enumeration gets randomised unfortunately. So that's why we used /dev/serial/by-id it
<ogra_> elfgoh, ok, that gets more tricky then ...
<elfgoh> Yup. We dont have a scalable interface definition
<ogra_> elfgoh, line 157ff has the other way ... using udev vendor and product id's https://github.com/snapcore/snapd/blob/master/interfaces/builtin/serial_port_test.go#L162
<ogra_> with that you should also be able to use by-id i think
<elfgoh> ogra_: have clarity we have multiple of the same USB serial devices, ie having the same vendor and product id :( We are not kidding
<ogra_> elfgoh, well, i fear thats a limitation of the serial interface ... mind starting a forum thread about it ? i guess we could extend the path /dev/serial/by-id/<identifier>
<ogra_> but thats not in my hands :)
<ogra_> *extend the path to
<elfgoh> ogra_: fair enough. Will do that
<ogra_> thx
<ogra_> lets see what gustavo and the security guys say :)
<Saviq> should I (and collaborators) be able to install a private snap from the store?
<elfgoh> ogra_: but nevertheless, thank you for hearing our complicated use case out :D
<ogra_> elfgoh, heh, no problem :)
<mup> PR snapd#3322 closed: overlord: make config defaults from gadget work also at first boot <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3322>
<pedronis> Chipaca: thanks
<mup> PR snapd#3355 opened: tests/main/snap-info: don't use named parameter for print statement <Created by morphis> <https://github.com/snapcore/snapd/pull/3355>
<mup> PR snapd#3356 opened: tests/lib: allow SRU validation only on ubuntu type systems <Created by morphis> <https://github.com/snapcore/snapd/pull/3356>
<elfgoh> ogra_: started the conversation here https://forum.snapcraft.io/t/usb-serial-port-access-for-snap-apps/693
<ogra_> elfgoh, perfect,. thanks
<mup> PR snapd#3357 opened: tests/lib: abstract build dependency installation a bit more <Created by morphis> <https://github.com/snapcore/snapd/pull/3357>
<mup> PR snapd#3358 opened: tests/main/snap-info: use proper pkgdb functions to install distro packages <Created by morphis> <https://github.com/snapcore/snapd/pull/3358>
<morphis> fgimenez, zyga: submitted many tiny PRs for our test setup, would be nice if you can have a look
<fgimenez> morphis: sure thanks, already reviewed one of them
<morphis> nice!
<mup> PR snapd#3359 opened: tests/lib: use mktemp instead of tempfile to work cross-distro <Created by morphis> <https://github.com/snapcore/snapd/pull/3359>
<mup> PR snapd#3360 opened: tests/libs: add distro_auto_remove_packages function <Created by morphis> <https://github.com/snapcore/snapd/pull/3360>
<pedronis> oh, no, more than 25 PRs , :)
<mup> PR core#45 opened: allow rsyslog disabling <Created by ogra1> <https://github.com/snapcore/core/pull/45>
<zyga> re
<zyga> ogra_: approved pi2 i2c interfaces
 * ogra_ hugs zyga 
<ogra_> merged
 * zyga hates doing tax paperwork but ... well
<zyga> pstolowski: thank you!
<mup> PR snapd#3349 closed: many: model and expose interface meta-data <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3349>
<zyga> pstolowski: I was thinking about the problem of security setup for core/kernel revision change
<zyga> pstolowski: are you familiar with that discussion
<zyga> pstolowski: I wanted to know your view, especially since we're about to have hook attributes that, I think, complicate the prblem
<pstolowski> zyga, i wasn't following that discussion, do you have a link?
<zyga> pstolowski: yes I was actually looking for it :)
<zyga> pstolowski: so part of it is in https://forum.snapcraft.io/t/providing-system-settings-to-snap-confine/665/13
<zyga> pstolowski: but the real problem is separate, there's no thread yet
<zyga> pstolowski: I want to open one but I wanted to chat with you to get the full picture
<zyga> pstolowski: the problem is that on kernel/core change, just after reboot, the services start with security profiles written by old snapd based on old kernel
<zyga> pstolowski: CE hit this problem, I can share a link to a private bug
<ogra_> pedronis, do we have any docs for that gadget config option ? (is it the old way we used to have in 15.04 ?) i'd actually like to default our images to have rsyslog off
<pedronis> ogra_:  is still in the wiki:Â  https://github.com/snapcore/snapd/wiki/Gadget-snap#gadgetyaml   notice the key is the snap-id , not the name
<ogra_> pedronis, i.e. http://paste.ubuntu.com/24604351/
<ogra_> ah
<ogra_> so close ... but different to 15.04 :)
<pedronis> ogra_: I plan to do a quick branch soon to show that in snap info
<pedronis> (that == snap-id)
<pedronis> because of this among other reasons
<ogra_> does the prepare-device hook accept snap names btw ?
<pedronis> ?
<pedronis> IÂ don't understand the question
<pedronis> accept where/how ?
<ogra_> loking at the bottom of https://github.com/snapcore/snapd/wiki/Gadget-snap#gadgetyaml at the example ...
<ogra_> could that call "snapctl set foo bar.baz=true"  ... for the preinstalled foo snap ?
<pedronis> ah
<ogra_> or is it only applying to some generic defaults
<pedronis> no
<ogra_> k
<pedronis> something to discuss if needed
<pedronis> snapctl set/get are about the snap of the hooks
<pedronis> in general
<pedronis> you need snapd-control to set other snaps config
<ogra_> well, it just struck me as a way to get around the snap-id if it had worked :)
<ogra_> <- cheating ;)
<pedronis> ogra_: there is some argument to be made that we should support names at least for things listed in the model assertion, otoh there were vague discussion about allowing snap-ids in the model as well
<pedronis> anyway nothing that will happen soon, high prio
<ogra_> well, as long as the id is predictable and known ...
<ogra_> (and doesnt change randomly)
<ogra_> it makes it a bit harder for devs ... but nothing that would block the feature
<ogra_> (we should publish the id's for the core snaps though ... until the snap info bit is there)
<ogra_> (an external developer wont easily get the id unless he builds a test image and looks at the snap-declarations first)
<zyga> gee, some code reviews are tedious
 * Chipaca slinks off
<abeato> zyga, are you suggesting to add "sc_" prefix to all function declarations in system-shutdown-utils.h?
<abeato> zyga, also, why "sc_"?
<ogra_> abeato, stands for supercool ... makes the functions more special ;)
<abeato> ogra_, that is definetely a +1 to adding it :p
<ogra_> :D
<morphis> zyga: so, LXD works on suse
<morphis> zyga: however you have to run $ lxc config set next-snipe raw.lxc "lxc.aa_allow_incomplete = 1" for every container
<morphis> zyga: need to file a bug on lxd for that
<zyga> morphis: what is next-snipe?
<morphis> zyga: the container name
<zyga> abeato: it's just a prefix from all the snap-confine function but I sometimes think of it as 'snapd-c-code'
<niemeyer> Moin moin
<morphis> niemeyer: moin!
<abeato> zyga, I guess we can apply the second :p
<zyga> morphis: I commented on https://github.com/snapcore/snapd/pull/3222 - I'm inclined to LGTM but my head is dizzy from all the indirection
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<abeato> zyga, in all funtxions in the header?
<morphis> zyga: :-)
<zyga> abeato: just the new ones,
<zyga> abeato: we can do the rest separately, no need to cloud what is going on in this PR
<Son_Goku> morphis, you packaged lxd for suse?
<abeato> zyga, ok, fine for me
<morphis> Son_Goku: no, its the snap :-)
<Son_Goku> bah
<morphis> Son_Goku: ?
<Son_Goku> I thought you had done something cool :)
<morphis> Son_Goku: :-D
<zyga> morphis: what are the three iota constants in content.go?
<Son_Goku> zyga: that distrolibexecdir PR makes my brain hurt
<morphis> zyga: ?
<zyga> https://github.com/snapcore/snapd/pull/3222/files/9b771dd09d80ef950160a1fffcd1d4b8a7ce7c80#r117467086
<mup> PR snapd#3222: many: fix test cases to work with different DistroLibExecDir <Created by morphis> <https://github.com/snapcore/snapd/pull/3222>
<Son_Goku> I'm not used to Go as it is, and it's really complicated to follow for me :(
<zyga> Son_Goku: yes, I feel the same; it's not morphis fault in any way, it's just the variables do make it hard to guess what is going on sometimes
<Son_Goku> I don't like saying this, but all the tests pass, can we please just merge it
<morphis> Son_Goku: +1
<morphis> zyga: let me drop these
<lazyPower> Is there a reason i'm nothinking of as to why the root user doesn't have /snap/bin added to $PATH by default on ubuntu-server/desktop distributions? Because to me it just seems like a papercut.
<Croepha> i know i have asked this before, but i cant find my notes, and its not readily available via google, how can I know what version of a package was used to make the core snap?  i remember that there was some kind of manifest on launchpad but i cant find it?
<lazyPower> Croepha: https://launchpadlibrarian.net/283317939/buildlog_snap_ubuntu_xenial_arm64_ubuntu-core_BUILDING.txt.gz - does something like that help?
<Croepha> lazyPower, yes thanks, i can make that work
<lazyPower> not the most straight forward way but you should be able to grep that build log for what went into it.
<lazyPower> *note, thats for the arm64 core snap. you may need to swap projects respectively
<Croepha> so, where is the link to that link?
<Croepha> like, how can I find more links like that?
<lazyPower> aha Croepha https://launchpadlibrarian.net/316771673/core_16-2_amd64.manifest
<lazyPower> there IS a manifest file
<lazyPower> cited: https://forum.snapcraft.io/t/inspecting-package-differences-across-core-base-snaps/378
<cjwatson> Start from https://code.launchpad.net/~snappy-dev/+snap/core - each build has a link to the manifest
<cjwatson> Unfortunately it's hard to find older builds there, but it can be done through the LP API
<Croepha> thanks cjwatson
<ogra_> lazyPower, http://people.canonical.com/~ogra/core-builds/ is an overview but only logs the automatically built daily snaps ... not the manual triggered builds
<Croepha> any ideas on how to translate revision number (like 1689) into build id?
<Croepha> oh!
<lazyPower> :) sorry jsut trying to be helpful. I actually have very little insight into how the core snaps are built so i was grepping around google searches/forums.
<Croepha> that ogra link is gold
<ogra_> (i need to update the code to handle the new version strings ... but you cn just click on the "Launchpad (...)" thing to get to the menifest)
<lazyPower> haha typical day for ogra_ ;)
<cjwatson> the store revision is available over the LP API so it would be possible to correlate that way
<cjwatson> store_upload_revision
<cjwatson> would involve walking back over the full list though
<cjwatson> ogra's link is easier :)
<morphis> zyga: ok, updated the PR
<ogra_> but also incomplete ...
<ogra_> (it parses the clogfile for auto-builds ... pretty hackish)
<ogra_> *logfile
<cjwatson> lp-shell production devel
<cjwatson> In [1]: for build in lp.load('/~snappy-dev/+snap/core').builds:
<cjwatson>    ...:     if build.store_upload_revision == 1689:
<cjwatson>    ...:         print(build.web_link)
<cjwatson>    ...:         break
<cjwatson>    ...:
<cjwatson> https://launchpad.net/~snappy-dev/+snap/core/+build/32410
<ogra_> yeah ... one day i'll find the time to make it based on proper lp-lib
<cjwatson> leads to https://launchpadlibrarian.net/315255992/core_16-2_amd64.manifest
<Croepha> cjwatson++ thanks!
<Croepha> build.getFileUrls() will give the manifest
<cjwatson> yep
<zyga> Chipaca: https://forum.snapcraft.io/t/anomalous-snap-list-devmode-flag/699
<morphis> zyga: there we go, docker works now too
<morphis> zyga: time to give the packages from https://build.opensuse.org/package/show/home:mrmorph:branches:system:snappy/snapd a try?
<abeato> zyga, pedronis,  Chipaca, morphis https://github.com/snapcore/snapd/pull/3353 ready again
<mup> PR snapd#3353: Add support for reboot parameter <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/3353>
<morphis> zyga: otherwise: https://build.opensuse.org/request/show/496769
<morphis> Son_Goku: btw. you may want to add https://build.opensuse.org/package/view_file/home:mrmorph:branches:system:snappy/snapd/0003-cmd-snap-confine-do-not-share-etc-ssl-with-the-host.patch?expand=1 to the snapd packages on Fedora until 2.27 is out
<morphis> Son_Goku: also I will look onto the bodhi requests on monday
<Son_Goku> why would I do that?
<Son_Goku> the Ubuntu Core snap expects /etc/ssl/certs, right?
<Son_Goku> well, in Fedora, /etc/ssl/certs is a valid location
<Son_Goku> it's a symlink to /etc/pki/tls/certs
<Son_Goku> oh, lemme guess
 * zyga hugs morphis :-)
<Son_Goku> you don't pull in /etc/pki, right?
<zyga> morphis: I'll definitely try today
 * Son_Goku grumbles
<morphis> Son_Goku: this is a tricky and not easy to solve situation we're in
<morphis> the best we can do today is to rely on the core snap
<Son_Goku> :(
<morphis> in a next step we will merge this somehow with what the host provides
<morphis> Son_Goku: why does that make you sad?
<Son_Goku> because for example, I can't access things that I have imported my certs into
<morphis> right but that is a problem we will solve
<Son_Goku> I have a number of private CA certs imported into my computer, so this would break
<Son_Goku> then again, it wasn't working before, was it?
<Son_Goku> thankfully Fedora infra no longer requires it
<Son_Goku> it used to be one of those I needed
<Son_Goku> they moved to Krb auth
<morphis> Son_Goku: it was horrible broken until we did this small fix
<morphis> there will be work to make /etc sharing better
<morphis> including CA stuff
<morphis> in one or another way
<zyga> Chipaca: given that devmode is now just a flag (not confinement type) can we just do this: http://paste.ubuntu.com/24604770/
<morphis> Son_Goku: btw. I will need you on Monday to have a look at a PR which introduces the rpm build stuff for our spread setup
<Son_Goku> okay
<Chipaca> zyga: yes. And there's code for determining jailMode based on devmode that also needs to go
<zyga> Chipaca: right
<Chipaca> zyga: as our metadata gets richer our black magic can be more relaxed
<zyga> yes, I was thinking that the transformations in snap list are unfortunate and it'd be nicer if we could just give simple facts from the daemon
<zyga> (perhaps even the notes)
<morphis> zyga: can you merge https://github.com/snapcore/snapd/pull/3307 ?
<mup> PR snapd#3307: tests: abstract common dirs which differ on distributions <Created by morphis> <https://github.com/snapcore/snapd/pull/3307>
<zyga> morphis: in a sec
<morphis> aye
<mup> PR snapd#3361 opened: cmd/snap: correct devmode note for anomalous state <Created by zyga> <https://github.com/snapcore/snapd/pull/3361>
<zyga> Chipaca: check out https://github.com/snapcore/snapd/pull/3361 please
<mup> PR snapd#3361: cmd/snap: correct devmode note for anomalous state <Created by zyga> <https://github.com/snapcore/snapd/pull/3361>
<Chipaca> zyga: yep, was already reviewing
<Chipaca> +1
<Chipaca> and now, friday school run
<Chipaca> ttyl!
<fgimenez> zyga, if you could have a look at snapd#3348 when you have some time that would be great, there are some refactors in there, the test itself is https://github.com/snapcore/snapd/pull/3348/files#diff-4825fd024a235e7895b109ad37072e68 probably i'm missing something but it seems to work fine (ie, the network connection is up after reverting)
<mup> PR snapd#3348: tests: add core revert test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3348>
<zyga> fgimenez: sure, gladly
<elopio> ahoneybun: do you know if that bug is already reported?
<fgimenez> zyga: thanks!
<zyga> morphis: done
<mup> PR snapd#3307 closed: tests: abstract common dirs which differ on distributions <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3307>
<morphis> zyga: thanks
<morphis> zyga: can you look at https://github.com/snapcore/snapd/pull/3358 too?
<mup> PR snapd#3358: tests/main/snap-info: use proper pkgdb functions to install distro packages <Created by morphis> <https://github.com/snapcore/snapd/pull/3358>
<morphis> zyga: and https://github.com/snapcore/snapd/pull/3359
<mup> PR snapd#3359: tests/lib: use mktemp instead of tempfile to work cross-distro <Created by morphis> <https://github.com/snapcore/snapd/pull/3359>
<zyga> morphis: yes
<mup> PR snapd#3359 closed: tests/lib: use mktemp instead of tempfile to work cross-distro <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3359>
<zyga> morphis: done
<mup> PR snapd#3358 closed: tests/main/snap-info: use proper pkgdb functions to install distro packages <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3358>
<morphis> great!
<morphis> zyga: https://github.com/snapcore/snapd/pull/3360 too?
<mup> PR snapd#3360: tests/libs: add distro_auto_remove_packages function <Created by morphis> <https://github.com/snapcore/snapd/pull/3360>
<morphis> and https://github.com/snapcore/snapd/pull/3357 would be nice too
<mup> PR snapd#3357: tests/lib: abstract build dependency installation a bit more <Created by morphis> <https://github.com/snapcore/snapd/pull/3357>
<morphis> on the last one just a review
<mup> PR snapcraft#1307 closed: cli: new UI and internal refactor <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1307>
<ahoneybun> elopio: I don't know tbh
<elopio> ahoneybun: I can't find it. This sounds like a good topic for the forum, would you mind making a post in forum.snapcraft.io?
<ahoneybun> elopio: I'll see if this wifi lets me
<ahoneybun> https://forum.snapcraft.io/t/snaps-list-as-loop-devices-in-file-manager/701
<ahoneybun> elopio: ^
<elopio> ahoneybun: thanks!
<Croepha> i made a little toy script, to grab all debug symbols for a core snap: https://gist.github.com/croepha/0185fa264a1fb3b454469cd3c7419a09
<Croepha> it still chokes on ones that have been updated since core came out
<Croepha> not sure how to fix that
<niemeyer> Lunch, back in a bit..
<Croepha> also, for some reason there are man pages and doc stuff in the debug files
<ogra_> Croepha, note that the manifest doesnt reflect what was removed du4ring the core snap build ... there is a lot less in it than the manifest lists after all
<ogra_> (we can only generate the manifest file before we remove things like apt and dpkg)
<Croepha> well, with everything (well at least with the packages I can get the right versions for) its all only 323MB so if I have too much then its not that big of a deal
<Croepha> my main concern is that I can guarantee  that i can read backtraces for cores after deployment
<Croepha> because it hard to find the debug symbols later
<ogra_> Croepha, if you want to debug on a device, i'd rather recommend using the classic snap and then install the symbols there ... the classic snap re-creates the env with apt, dpkg and all other bits that have been removed
<ogra_> snap install classic --devmode --edge; sudo classic
<elfgoh> jdstrand: ogra_ : I have raised the issue with regards to the visibility of processes in external snaps here https://forum.snapcraft.io/t/visibility-of-processes-originating-from-other-snaps/703
<ogra_> (obn any core device)
<ogra_> elfgoh, yes, and i pinged niemeyer and jdstrand in the thread ... they will answer eventually :)
<ogra_> elfgoh, oops, sorry ... that was the other thread
<Croepha> ogra_, well im thinking about the longterm, being able to get support info for the older binaries... like im thinking that I'll just tar up all the debug info for a specific release, so i can have it for later if i need to figure out what happened from core dump pulled from a customer down the road....  For my normal day to day development cycle im just using ubuntu desktop, and I can test and debug the snap there
<ogra_> Croepha, right, just dont be surprised if half the libs and binaries you expect ate actually not really there
<ogra_> the manifest is only a snapshot mid-build
<Croepha> ogra_ ahh ok
<ogra_> we only use debs for the initial rootfs but then mangle it a lot
<ogra_> (to cut down size ...)
 * ogra_ shakes fist towards people that base new product u-boot on upstream branches from 2013
<ogra_> *new products
<ogra_> such a pain
<mup> PR snapd#3361 closed: cmd/snap: correct devmode note for anomalous state <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3361>
<fgimenez> niemeyer: i've verified the scenario i mentioned in the standup and it seems that it can refresh after the revert to the previous version, so after reverting it seems that when autorefresh kicks in you would be back to the previous state
<fgimenez> niemeyer: to give you more context, start from stable, "snap refresh --candidate core", "snap revert", now "snap list" shows the revision at stable but snap info shows "tracking: candidate" and, indeed, "snap refresh core" installs the latest revision in candidate
<pedronis> fgimenez: manual refresh and auto refresh don't work the same in that scenario
<pedronis> fgimenez: with auto-refresh we send blocked revisions, we a manual refresh we don't
<pedronis> fgimenez: this is the relevant code:  https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate.go#L491
<zyga> morphis: hey, can you tell me more about why you are making this change https://github.com/snapcore/snapd/pull/3355/files
<mup> PR snapd#3355: tests/main/snap-info: don't use named parameter for print statement <Created by morphis> <https://github.com/snapcore/snapd/pull/3355>
<zyga> morphis: is this a 2-vs-3 thing?
<zyga> morphis: note that print adds implicit newline so this actually changes semantics soo
<zyga> too
<morphis> zyga: AFAIK fedory python3 couldn't deal with the file= argument
<fgimenez> pedronis: aha, thanks a lot, looking
<zyga> morphis: that is very unlikely, can you give me a backtrace?
<pedronis> fgimenez: to be precise what is different is auto-refresh and "snap refresh"Â   VS   "snap refresh NAMES"
<morphis> zyga: yes, let me check that again once my fedora system is free
<zyga> morphis: thank you
<fgimenez> pedronis: autorefresh doesn't use names, right?
<pedronis> right
 * zyga does last round of reviews
<elfgoh> Perhaps not the right place to ask, but relative to Docker, I am guessing that there have been less people trying to break snap security. So where is Snap with regards to security compared to Docker? (perhaps not most elegantly articulated, but it is my best effort)
<nacc> elfgoh: iirc, there is a white paper on the website
<zyga> elfgoh: hey
<nacc> https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ ?
<zyga> elfgoh: we have a security whitepaper
<zyga> nacc: thanks!
<nacc> zyga: np :)
<zyga> elfgoh: it's a complex questions as it is an apples-to-oranges comparison in many ways
<zyga> elfgoh: there are many things that have nice properties but I'm about to join a hangout on air so I cannot tell you about them
<zyga> elfgoh: I can tell you keywords to look up or discuss later
<zyga> elfgoh: assertions, core snap shared by everything, separate updates, automatic confinement
<morphis> zyga: if I have an reported oops id from snapd, where can I see that reported error?
<ogra_> pfft ... apples ... oranges ....
<ogra_> take pears !!!
<pedronis> morphis: an error tracker one?Â or a store oops?
<morphis> pedronis: error trackker
<zyga> morphis: I'm in a call
<pedronis> morphis: https://errors.ubuntu.com/oops/ID if you have access
<morphis> pedronis: doesn't look like
<niemeyer> fgimenez: Yeah, that looks sane
<fgimenez> niemeyer: pedronis yep, i've just tried "snap refresh" and it gives first an error about network-manager's aliases http://paste.ubuntu.com/24605592/ (not sure if it's related to network-manager itself) after, removing network-manager returns "All snaps up to date" (core is not updated to the tip of candidate)
<pedronis> fgimenez: what version is this?
<pedronis> of snapd
<pedronis> (me has lost rack)
<pedronis> fgimenez: ah, you reverted core ?
<fgimenez> pedronis: yes, now it is at the current stable, 2.24
<pedronis> yea, aliases and reverting core will not be happy
<mup> PR snapcraft#1324 opened: Revert "tests: remove the reusable parts tour test (#1321)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1324>
<fgimenez> ok thanks pedronis
<pedronis> IÂ mean that errors comes fromr 2.24
<pedronis> IÂ think
<mup> PR snapcraft#1325 opened: cli: proper error for failed snap command <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1325>
<Chipaca> signs I should probably take a break: in two lines of code, type a variable name three different ways
<davhou> ogra_ Hi, a followup question related to "snap run hello" error I was getting yesterday
<davhou> ogra_, https://paste.ubuntu.com/24605885/
<davhou> ogra_, Any suggestions?
<davhou> ogra_, or debugging techniques to help solve the problem...
<ogra_> davhou, "snap version" ?
<ogra_> (just paste it here ... only 4 lines)
<ogra_> (or 5)
<davhou> david@david-VirtualBox:~â« snap --version
<davhou> snap    2.25
<davhou> snapd   2.25
<davhou> series  16
<davhou> ubuntu  16.04
<davhou> kernel  4.4.0-75-generic
<ogra_> looks all fine
<davhou> odd thing is, I am pretty certain I was once able to run that snap w/out an error
<davhou> at least once
<davhou> when I initially tried it out
<ogra_> if you just type "hello" and hit enter ... does it behave the same  ?
<davhou> i installed simplenote to try it and that's when I saw it the first time
<davhou> that works!
<Chipaca> pedronis: any idea why PlaceInfo has e.g. DataHomeDir but not UserDataDir?
<davhou> david@david-VirtualBox:~â« hello
<davhou>  hello, world
<ogra_> yeah, looks fine
<davhou> what's that mean?
<davhou> is that how i should run all the snaps?
<nacc> davhou: you don't use `snap run` to run a snap, normally
<pedronis> Chipaca: it's not used a lot, so new things might have not be added to it
<ogra_> both should work
<davhou> ok
<Chipaca> pedronis: ah ok
<ogra_> (they do here)
<davhou> was just following the docs from online
<nacc> davhou: /snap/bin is in your PATH and then the app provided by the snap is available
<ogra_> normally ... like nacc said ... you run the binary directly ... snap apps get added to your path
<nacc> davhou: (on ubuntu, iirc)
<ogra_> but the snap run command should still work nontheless
<pedronis> Chipaca: anything that can be derived just by name and revision should be ok for it, if you need it
<ogra_> it indicates that theer is some issue with that specific code path
<nacc> fwiw, on 17.04, i don't have a /run/snapd :) and those permissions look weird
<Chipaca> pedronis: i don't need it, but was looking at adding tests while i'm in the neighborhood
<davhou> you mean the root:david permissions on /run/snapd look weird?
<nacc> davhou: yeah, it's a strange combination -- i'd have to spin up a 16.04 to compare though
<davhou> i'll try installing another snap and run it directly
<nacc> davhou: well, the ownership in combination with the actual permissions
<davhou> oh, ok
<pedronis> Chipaca: it's mostly  undo and remove stuff that uses it, to be sure they don't depend too much on having a fully sane snap
<nacc> davhou: i'm not sure why /run/snapd would be owned by a user's group
<pedronis> (because they migh well not)
<nacc> davhou: as it's a system directory (it seems like)
<ogra_> nacc, it is here as well ...
<nacc> ogra_: interesting
<ogra_> so i guess thats fine ...
<nacc> ogra_: same permissions?
<davhou> Hmm, simplenote does not work as well as hello does....
<davhou> david@david-VirtualBox:~â« sudo snap install simplenote
<davhou> simplenote 1.0.8 from 'flexiondotorg' installed
<davhou> david@david-VirtualBox:~â« simplenote
<davhou> cannot create lock directory /run/snapd/lock: Permission denied
<Chipaca> sigh. our user home layout is so simplistic i'm surprised it isn't biting people more
<Chipaca> (i guess everybody has homes in the same place :-) )
<nacc> ogra_: it seems like /run/snapd/lock would be created by snapd, not by `snap`?
<ogra_> nacc, yeah, sorry, the permissions of the lock files are root:ogra
<ogra_> not the dirs
<nacc> ogra_: ah ok
<zyga> davhou: hey
<zyga> nacc: that directory is made by snap-confine and snapd alike
<davhou> ogra_, so what is are your owners x:X on /run/snapd ?
<zyga> davhou: can you tell me more about your environment
<nacc> zyga: ah i see, but i assume files in it are created by snapd?
<zyga> davhou: when this error happens
<zyga> nacc: nope, unless you are using edge
<davhou> zyga, what would you like to know?
<ogra_> davhou, better go with zyga than me ... he is deeper into snapd stuff
<zyga> davhou: also, can you share 'dmesg | grep DENIED'
<nacc> zyga: ok, just funny to see a directory called /run/snapd not contain files ... from snapd? :)
<zyga> nacc: snapd and snap-confine are both from the same project, different programs though
<nacc> zyga: ah i see
<Chipaca> zyga: can I kill NoneSecurityTag? nothing uses it
<zyga> nacc: (there are more)
<zyga> Chipaca: are you sure? I bet it is used by udev)
<davhou> last two lines...
<davhou> [105316.495420] audit: type=1400 audit(1495213933.488:79): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/lock/" pid=76593 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<davhou> [106747.330295] audit: type=1400 audit(1495215368.207:84): apparmor="DENIED" operation="mkdir" profile="/usr/lib/snapd/snap-confine" name="/run/snapd/lock/" pid=96954 comm="snap-confine" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<zyga> Chipaca: it was made for udev
<ogra_> nacc, and you have any snaps installed ??
<zyga> davhou: ok, can you tell me which distribution are you using
<zyga> davhou: or better
<zyga> davhou: share "snap version" please
<Chipaca> zyga: grep says no
<Chipaca> $ grep -r NoneSecurityTag
<Chipaca> snap/info.go:// NoneSecurityTag returns the security tag for interfaces that
<Chipaca> snap/info.go:func NoneSecurityTag(snapName, uniqueName string) string {
<nacc> ogra_: hrm, `snap list` says core is installed but not sure that counts
<zyga> Chipaca: very odd, please keep it, we had uses for it (real uses)
<ogra_> nacc, core should have a lock file i guess
<Chipaca> zyga: it's untested >:-(
<ogra_> it does here
<Chipaca> zyga: :-)
<davhou> zyga, Check above at 13:29:17 for 'snap --version'
<zyga> davhou: can you also check what does ls /etc/apparmor.d/usr.lib.snapd.snap-confine.real*  return?
<nacc> ogra_: yeah, it seems oddly inconsistent. Not a big deal to debug right now, as I think davhou's issue is presumably more pressing :)
<zyga> davhou: thanks, looking
<zyga> aha, I see
<ogra_> everything pretty recent and sane there
<zyga> davhou: give me a sec, checking something
<davhou> david@david-VirtualBox:~â« ls /etc/apparmor.d/usr.lib.snapd.snap-confine.real*
<davhou> sorry, trying again
<davhou> david@david-VirtualBox:~â« ls /etc/apparmor.d/usr.lib.snapd.snap-confine.real*
<davhou>  /etc/apparmor.d/usr.lib.snapd.snap-confine.real  /etc/apparmor.d/usr.lib.snapd.snap-confine.real.dpkg-new
<zyga> aha!!!
<zyga> davhou: can you diff -u those two files
<zyga> davhou: and pastebin this
<zyga> davhou: this is the reason it failed
<zyga> davhou: but I must ask, did you edit the file before?
<davhou> which file?
<zyga> davhou: or perhaps, did you run an upgrade that failed/did not complete?
<zyga> davhou: /etc/apparmor.d/usr.lib.snapd.snap-confine.real
<zyga> davhou: if you run: sudo dpkg --configure -a
<davhou> i did an upgrade recently to 16.0.2
<zyga> davhou: what does that do?
<davhou> 16.04.2
<zyga> davhou: that file looks like a partial update occured
<davhou> ok, so you want a diff of those 2 files you asked me to ls ?
<zyga> yes, please!
<davhou> ok
<zyga> and then do the dpkg --configure -a
<davhou> coming up in pastebin, one sec
<zyga> I suspect it will finish configuring snap-confine
<davhou> ok
<zyga> and the issue will go away
<zyga> or you had a prompt during upgrade
<zyga> and it asked you what to do
<zyga> (which is terrible)
<nacc> zyga: nice catch
<zyga> then you got a default reply 'keep the locally installed file'
<davhou> I suspect you are right
<zyga> which is equal to "break snapd"
<davhou> nice
<davhou> those are not easy ?s to answer...
<zyga> yep
<zyga> we should move this file out out etc
<zyga> it's a constant pain
<zyga> jdstrand: ^^ FYI
<davhou> https://paste.ubuntu.com/24606043/
<zyga> looking
<zyga> ha
<zyga> :)
<zyga> so
<zyga> to fix your immediate issue
<zyga> sudo dpkg --configure -a
<zyga> and see if that does anything
<davhou> it's setting up and processing a bunch of things...
<zyga> your upgrade was interrupted somewhere
<davhou> ok
<zyga> davhou: it can cause your system not to boot in extreme cases
<zyga> davhou: once that is done
<zyga> davhou: follow up with "sudo apt-get dist-upgrade"
<zyga> davhou: as more packages are bound to be updated
<zyga> davhou: this is just finishing what was started, updated partially, and not finished
<davhou> i was experiencing some odd video scaling that i could not explain
<davhou> hopefully this will help that also
<zyga> I bet it will
<davhou> ok, will follow up as asked when this is done
<zyga> davhou: good luck :)
<davhou> thanks for all your help zyga and ogra_
<zyga> o/ :-)
<adfad666> pardon the interruption, can someone point me towards a device repo that also builds u-boot, i'm used to bringing up android devices but ubuntu snappy is a whole new world for me, looking for something to study
<zyga> adfad666: I think you want to talk to ogra_ ::)
<zyga> adfad666: look at github.com/snapcore/pi2-gadget
<zyga> adfad666: but that is not building it from source _I think_
<zyga> anyway, ogra is the man to talk to
<adfad666> thanks, i'll take a look at that
<davhou> noticed this during --configure -a
<davhou> Installing new version of config file /etc/apparmor.d/usr.lib.snapd.snap-confine.real ...
<zyga> davhou: see :")
<zyga> davhou: that will fix your snapd
<davhou> awesome
<zyga> davhou: this is essentially telling you that the file that was unpacked is now moved to the place where it was supposed to be
<davhou> ok
<zyga> davhou: but because the binaries were done earlier it was all broken
<davhou> makes sense
<zyga> davhou: dpkg cannot handle that better unfortunately
<davhou> not sure why I didn't realize the upgrade was interrupted somehow
<davhou> guess the hammer was too small : - )
 * zyga needs to help with the kids, ttyl
<davhou> if there was one
<davhou> k
<davhou> zyga, I had success with running 'snap run simplenote' after 'dpkg --configure -a' & 'sudo apt-get dist-upgrade' !
<davhou> zyga, Again, thanks for all your help in helping me to resolve the issue
<mcphail> Is there a plugin for a repo with a "debian" directory to automatically resolve dependencies etc in snapcraft, or does it always have to be done by hand?
<Chipaca> davhou: FWIW if you can train yourself to use "apt" instead of "apt-get", things are much better (plus it's nicer in a lot of other ways)
<Chipaca> kyrofa: ^ mcphail's is for you :-D (I think?)
<Chipaca> as for me, I'm EOW'ing
<mcphail> Chipaca: have a good weekend
<Chipaca> mcphail: you too!
<Chipaca> I've got a new guitar to play with, so the weekend is looking good
<Chipaca> :-D
<mcphail> What did you get?
<Chipaca> my first electric!
<mcphail> Ha! You'll find it so much more fun than acoustic, and much easier to play. Enjoy!
<Chipaca> an ibaÃ±ez S521
<Chipaca> went in looking at a fender telcaster thinline, but ended liking this one better
<mcphail> One of my mates used to swear by ibanez. He could make it make ridiculous sounds. Have a lot of fun and turn it up to 11
<kyrofa> mcphail, Chipaca sorry I missed your ping! Busy day!
<kyrofa> mcphail, you mean if the snapcraft.yaml is in the same tree as the debian dir?
<mcphail> kyrofa: yes. is it possible to cheat and use the debian dir?
<kyrofa> mcphail, not by default, but you can probably write something really simple that uses python-debian to do it
<mcphail> kyrofa: ok. Cheers
<mcphail> kyrofa: i'm really just being lazy ;)
<kyrofa> mcphail, snapcraft depends on python3-debian, so it should always be there
<kyrofa> mcphail, well, who wants to maintain that list in two places? I hear ya
<mcphail> I thought there was chat about a tool to automagically snappify debian packages, but I may be misremembering
<kyrofa> mcphail, I think that was taking an already-built deb, which is easy
<mcphail> aah. ok.
<niemeyer> Need to step out for an errand and school run.. will be back later today
<mup> PR snapcraft#1325 closed: cli: proper error for failed snap command <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1325>
<mup> PR snapcraft#1324 closed: Revert "tests: remove the reusable parts tour test (#1321)" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1324>
<mup> PR snapcraft#1326 opened: Release changelog for 2.30 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1326>
<mup> PR snapd#3362 opened: Timedatectl <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3362>
<mup> PR snapd#3363 opened: cmd: test everything (100% coverage \o/) <Created by chipaca> <https://github.com/snapcore/snapd/pull/3363>
<mup> PR snapd#3362 closed: Allow snaps to use the timedatectl utility <Created by tyhicks> <Closed by tyhicks> <https://github.com/snapcore/snapd/pull/3362>
<mup> PR snapd#3364 opened:  Allow snaps to use the timedatectl utility <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3364>
#snappy 2017-05-21
<mup> PR snapcraft#1326 closed: Release changelog for 2.30 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1326>
<mup> PR snapd#3343 closed: WIP: Spread tests for fedora <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3343>
<mup> PR snapd#3365 opened: Add package build support for Fedora for our spread setup <Created by morphis> <https://github.com/snapcore/snapd/pull/3365>
<mup> PR snapd#3366 opened: packaging: Add Fedora packaging files <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3366>
<mup> PR snapd#3367 opened: many: cleanup MockCommands and don't leave a process around after hookstate tests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3367>
#snappy 2018-05-14
<mborzecki> morning
<zyga> good morning
<mborzecki> zyga: hey
<zyga> how was your weekend?
<mborzecki> zyga: good, spent no more than an hour in front of the computer throughout the whole weekend
<mborzecki> oh and i bought a bike, finally replacing my old one :)
<zyga> mborzecki: I spent a few hours yesterday trying to put some life into and old netbook my mom gave me
<zyga> ooh, nice
<zyga> we managed to clean the garage to make room for the bikes
<zyga> did a "garage sale" and let go some stuff
<zyga> the bigger things (old kiddy beds) will likely be picked up this week so we will have all the room available
<mborzecki> nice
<mborzecki> btw. let me show you something
<mborzecki> zyga: https://i.imgur.com/YM0lCsE.jpg
<zyga> is that the one with folded keyboard?
<zyga> ah
<zyga> no
<zyga> :)
<mborzecki> no, unfortunately not
<zyga> I saw one recently
<zyga> what's inside?
<mborzecki> asking price was ~30eur
<zyga> pretty low, the cosmetics are nice
<zyga> did you buy it?
<mborzecki> nope, bought a road bike instead
<zyga> :-)
<zyga> I'm using sports tracker for my biking fun
<zyga> e.g. this https://www.sports-tracker.com/workout/zygmuntkrynicki/5af879cec3d63959d624fc56
<mborzecki> got a used bike for ~540eur, with my frugal spending habits, another 30 felt like too much
<mborzecki> zyga: looks like direct competition to endomondo
<zyga> yeah, plenty of those apps
<zyga> I've been using it for some time
<zyga> it was working on my blackberry first :D
<zyga> and it integrates with apple health now so I like it (it tracks my biking in the apple health app)
<zyga> my wife uses endomodo as well but this one seems like what you get if you pay for endomodo
<mborzecki> zyga: wonder if you can see this https://www.endomondo.com/users/20483467/workouts/1119982468
<zyga> yes
<zyga> nice route :-)
<mborzecki> that's the medium loop ;) got a couple of variants between 25-35km, the larger ones are 35-50, but those i can only do on weekends
<zyga> do you go alone or with family?
<zyga> for us the main limiting factor is how far the kids are willing to go
<mborzecki> alone mostly
<mborzecki> usually have like 1.5-2h of free time, so i can squeeze 25-35km loop
<zyga> nice :)
<zyga> we usually go on 20km loops at most, also going around Warsaw is not as fluid as there are many street lights and other choke points
<zyga> I started going south from where we live, where there's fewer people and buildings but I haven't found a good route yet
<zyga> my plan is to do a longer route along the river and then go back through "lasek kabacki" (a bit off to the west) so that the full loop would be close to 40km but we haven't done that y et
<zyga> oh btw, I'm going to be off on Thursday, Friday, (this week) Monday, Tuesday and Wednesday (next week)
<zyga> I need to file that
 * zyga -> walk the dog
<mborzecki> zyga: you entirely sure that the arrow does not go in the opposite direction? :)
<zyga> haha
<zyga> the truth has come out :)
<mup> Bug #1484898 opened: device tarball needs to allow setting sysctl defaults <Snappy:Triaged> <https://launchpad.net/bugs/1484898>
<mborzecki> zyga: another look at https://github.com/snapcore/snapd/pull/4504 when you're back?
<mup> PR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<zyga> Ack
<zyga> Still walking but close to home now
<zyga> Or I can just try now
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> zyga: https://paste.ubuntu.com/p/XTPx5xJFVY/
<zyga> mborzecki: nice :)
<zyga> is that the volume broken by your script?
<mborzecki> yes
<mborzecki> need to read more about the name checksums
<mborzecki> github slow today?
<zyga> mborzecki: I haven't noticed
<zyga> mborzecki: I'm puzzled by something
<zyga> I bet it is silly
<zyga>     if !(strings.HasPrefix(notifySocket, "/") || strings.HasPrefix(notifySocket, "@")) || strings.ContainsAny(notifySocket, `?*[]{}^"`) {
<mborzecki> hm?
<zyga> so a string must start with either / or @
<zyga> and must not have ? and other guys
<zyga> right?
<mborzecki> zyga: right
<zyga> so
<zyga> if s is the string
<zyga> and s is "/?"
<zyga> the first condition will be true, right?
<zyga> so || will short-circuit and won't evaluate the rest
<zyga> which is wrong
<zyga> am I missing something?
<zyga> if you add the test for special chars separately
<mborzecki> zyga: the first condition will be false
<zyga> wh?
<zyga> why?
<zyga> strings.HasPrefix(s, "/")
<mborzecki> !(..)
<zyga> that's separate
<zyga> the condition inside the ( ) will be true
<zyga> then the ! will negate
<zyga> but that's separately evaluated
<mborzecki> zyga: not sure what you're aiming at, you have !(true) || true for /?
<zyga> oh boy
<zyga> I'm blind
<zyga> I didn't notice the () around the first two
<mborzecki> zyga: or in more detail !(true || false) || true
<zyga> I though it was around all three
<zyga> I tweaked the code slighttly
<mborzecki> maybe i should separate the cheks to make it more legible?
<zyga> http://paste.ubuntu.com/p/zYzt3mW46f/
<zyga> is this okk?
<zyga> I can push it
<mborzecki> zyga: maybe s/AARE/illegal characters/ ?
<mborzecki> (in the error message)
<zyga> meta-characters?
<zyga> invalid doesn't say much
<zyga> yeaah, wrong but why?
<mborzecki> hm
<mborzecki> zyga: "cannot use %q as notify socket path: contains meta-characters" vs "...: contains illegal characters"
<zyga> contains apparmor meta-characters
<zyga> or contains one of "..."
<zyga> that would be explicic
<mborzecki> oh, the last one
<mborzecki> zyga: `cannot use %q as notify socket path: contains one of ?*[]{}^"`
<zyga> doing that
<mborzecki> zyga: thanks!
<Chipaca> moin moin
<pstolowski> o/
<zyga> hey Chipaca, pstolowski
<zyga> mborzecki: question about watchdog
<zyga> does systemd enfroce any minimum values
<zyga> mborzecki: what's the resolution there? seconds
<zyga> ah, I see yes
<zyga> is 1 second valid?
<mborzecki> yeah, i think so
<mborzecki> i mean, why wouldn't it?
<zyga> I'm wondering if putting unreasonable value would be harmful to the system
<mborzecki> if you feel like pinging every second and risking being restarted due to a missed ping, then so be it ;)
<zyga> I just realized we should limit the number of apps in a snap
<zyga> if we create a snap with 100M services
<zyga> it would harm the system eqaisly
<mborzecki> zyga: i think it's self regulating, if you put a value too low and miss it and malfunction you'll have the need to regulate it
<mborzecki> zyga: the same with apps, i'd guess you'd bring down systemd if a snap has ridiculously large number of apps
<mborzecki> s/apps/services
<mup> PR snapd#5154 closed: releases: merge 2.32.8 back into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5154>
<mwhudson> hmm
<mwhudson> when selecting server snaps to install in subiquity, should the snaps actually be installed?
<mwhudson> or should subiquity build a seed.yaml for the installed system?
<mwhudson> pedronis: hi, this seems like something you would know? :) ^
<Chipaca> mwhudson: pedronis might not be with us yet
<mwhudson> oh right
<mwhudson> timezones how do they even
<Chipaca> mwhudson: well, it's 10:30 in his tz
<mwhudson> oh
<mwhudson> heh
<Chipaca> mwhudson: but it's a national holiday in the helvetic confederacy
<mwhudson> ah
<mwhudson> i guess i should email really
<mwhudson> Chipaca: 'interdenominational-counterintelligences' lol
<popey> Trips off the tongue.
<Chipaca> mwhudson: popey: and that's just unrepresentative-herpetology.~1~, the next version is going to be even better, i hear
<Chipaca> I'd tell you what channel to get it from, but it won't fit in this margin
<mwhudson> i wonder how badly this would break the snap list view i'm making for subiquity
<Chipaca> mwhudson: answering that question is why I made it :-)
<Chipaca> mwhudson: to be clear, package name, version, and summary are max length. Revision in particular is not, because I got lazy.
<mwhudson> heh
<mwhudson> what is the max revision length?
<Chipaca> mwhudson: undocumented
<mwhudson> len(str(sys.maxint))?
<mwhudson> i don't know that the store team would be super happy with you uploading billions of reviions
<Chipaca> mwhudson: probably log2((1<<31)-2) or something silly like that
<Chipaca> mwhudson: exactly, too lazy to change country again because of being on the run from the store people
<mwhudson> hahaha
<mwhudson> ok now to make this stuff actually talk to snapd
<Chipaca> mwhudson: what're you writing in?
<mwhudson> Chipaca: python
<mborzecki> anyone seen https://paste.ubuntu.com/p/wRXzv8vJQK/ ?
<Chipaca> mwhudson: if you have requests, the http snap uses that + requests-unixsocket
<mwhudson> Chipaca: that was what i had found with google
<Chipaca> mwhudson: I'm sorry I'm only on par with, and not better than, a multi-billion corporation
<mwhudson> Chipaca: i trust your recommendation a lot more!
 * Chipaca wonders at the wisdom of that
<pedronis> Chipaca: I'm around now, is not a holiday for me (next Monday is)
<ryan____> hi!
<ryan____> need help understanding prime and stage
<Chipaca> pedronis: ah! my bad :-)
<Chipaca> pedronis: mwhudson had a question for you about becoming a farmer or something about seeds
<Chipaca> ryan____: that's a bit vague :-) what do you need help with?
<pedronis> mwhudson: either is fine, depends what you can actually do, to install things the system needs to have been booted from the installed fs
<mwhudson> pedronis: i have managed to 'boot' the installed system in a container
<mwhudson> and then install snaps, even
<ryan____> understanding whats the difference in purpose between prime and stage.
<Chipaca> ryan____: 'prime' is what the snap ends up as
<pedronis> mwhudson: so  that boot seeds the real system I suppose, the issue there is at also starts the holding period for refreshes which we might want or not
<Chipaca> ryan____: you can even install it using 'snap try'
<om26er> What could cause snap build process to change the signature of a repackaged binary ?
<om26er> case: https://github.com/snapcrafters/sublime-text/issues/16
<Chipaca> ryan____: it gets populated from 'stage', which is where parts install to
<mwhudson> pedronis: hmm yes
<pedronis> mwhudson: I think both approaches are workable, it's a bit of a matter of what's the speed of one or the other and details like that one
<pedronis> also the speed of the first boot after install
<Chipaca> om26er: differ from what?
<ryan____> it sounds like a small step from build to prime
<om26er> Chipaca: from the tarball downloaded from the official release channel
<mborzecki> zyga: any idea what's the status of https://github.com/snapcore/snapd/pull/4369 ? do you still plan to introduce the attribute? (i can look into that if needed)
<mup> PR #4369: add write permission to optical-drive interface <Decaying> <Created by diddledan> <https://github.com/snapcore/snapd/pull/4369>
<om26er> the binary sublime_text under this tar https://download.sublimetext.com/sublime_text_3_build_3176_x64.tar.bz2 is different from what we have in the snap, even though the source is the same. The upstream is concerned chipaca
<Chipaca> om26er: snapcraft is probably patching the binary using patchelf
<Chipaca> om26er: is this a classic snap?
<om26er> Chipaca: yes, that's true
<Chipaca> om26er: which is true
<om26er> hmm, would need to add https://github.com/snapcrafters/android-studio/blob/master/snap/snapcraft.yaml#L31 ?
<om26er> Chipaca: we need some kind of articulated response to the upstream on that one.
<Chipaca> om26er: who is creating the snap?
<om26er> Chipaca: we (snapcrafters)
<Chipaca> om26er: so, you need to figure out what you're doing to the binary, and explain it to them
<om26er> Wimpress: ^
<popey> Wassup?
<om26er> I kind of was not expecting the signature to change, so someone with more knowledge of why and how that is happening could produce a better response :)
<om26er> popey: https://github.com/snapcrafters/sublime-text/issues/16
<Chipaca> om26er: if it's running patchelf, it's changing the binary; if it's changing the binary, its signature will change
<Chipaca> and if patchelf is causing crashes on linux, it's doing it wrong
<popey> you can disable patchelf
<zyga> mborzecki: that is blocked on a decision by gustavo
<popey> om26er: use the build-attributes -no-patchelf
<zyga> sorry, I was afk for a moment, we're giving away baby gear and a friend came over for a summer kiddy bed
<popey> om26er: see android-studio
<om26er> popey: sure, we did that for Android Studio a bit ago, it was not starting at all.
<om26er> yeah
<om26er> I will do a PR but would be better if you could write on that issue popey
<mup> PR snapd#5134 closed: Shrink image generated with snap prepare <Created by kubiko> <Closed by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<popey> om26er: ok leave it with me
<Chipaca> popey: resurrecting #1739097 if you could give it a read
<mup> Bug #1739097: "This leaves <snap> tracking edge." <snapd:In Progress> <https://launchpad.net/bugs/1739097>
<om26er> I do have a PR though https://github.com/snapcrafters/sublime-text/pull/17 but I still am not able to build it because snapcraft eats 100 cpu during build and never gets further.
<mup> PR snapcrafters/sublime-text#17: Dont use patchelf <Created by om26er> <https://github.com/snapcrafters/sublime-text/pull/17>
<Chipaca> om26er: I'd suggest checksumming that before declaring it fixed
<Chipaca> om26er: also, dude, if you don't explain _why_ you're doing a change, how do you remember why you did things a year from now?
<popey> om26er: hang fire for now. I'm building and testing locally
<popey> I'll respond to upstream
<om26er> popey: yep, that would make sense.
<om26er> Chipaca: I added some description now, thanks for the reminder.
<mup> PR snapd#5134 opened: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<mborzecki> pstolowski: is https://github.com/snapcore/snapd/pull/4968 still blocked?
<mup> PR #4968: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<pstolowski> mborzecki: nope, let me merge master back
<mborzecki> ok
<mborzecki> looks like google:ubuntu-16.04-32:project is failing, is the image broken? i'm suspecting the apt lock file was left behind
<mborzecki> heh, when starting manually project prepare on ubuntu-16.04-32 works just fine
<zyga> mborzecki: maybe unattended updates?
 * zyga needs more coffee 
<Son_Goku> zyga, did cachio finally get the f28 google images up?
<zyga> I haven't touched that, I will ask cachio when he shows up
<Son_Goku> I had to spin new packages yesterday due to failing scriptlet: https://copr.fedorainfracloud.org/coprs/ngompa/gce-oslogin/build/753629/
<zyga> thank you again for preparing that package
<zyga> my main focus this week is to go through the reviews
<Son_Goku> gce-oslogin was a crappy package
<Son_Goku> but I fixed it: https://copr-be.cloud.fedoraproject.org/results/ngompa/gce-oslogin/fedora-rawhide-x86_64/00753629-google-compute-engine-oslogin/google-compute-engine-oslogin.spec
<zyga> Son_Goku: I'm not sure how google handles that, can you send your improvements back?
<Son_Goku> they require a CLA
<Son_Goku> and I hate signing those
<Son_Goku> I actually more or less rewrote the spec
<Son_Goku> so I should have dropped the ASL license header in the file
<Son_Goku> I probably will drop it actually
<Son_Goku> since my spec file shares ~2-4 lines with the original
<Son_Goku> and that's it
<kjackal> Hi snappy people, I have a deb that I should plave in a snap. Normaly that would go into the staged-packages but that specific deb is from a non-bleshed repository, what can I do?
<kjackal> *place
<popey> kjackal: you could add it as a part, plugin type dump, source, url to the deb.
<kjackal> thanks popey, do you happen to have an example yaml for that?
<kjackal> popey: something like this: https://github.com/snapcrafters/mattermost-desktop/blob/master/snap/snapcraft.yaml I guess
<popey> not off the top of my head, no.
<zyga> hmm
 * zyga is stuck with a test failure on code he is hacking 
 * cachio afk
 * Chipaca lunch
<pedronis> pstolowski: I asked a question about #4767 in your latest forum topic
<mup> PR #4767: interfaces: disconnect hooks <Critical> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<pstolowski> pedronis: i saw it, thanks
<mborzecki> zyga: https://paste.ubuntu.com/p/ydn2KZBTHV/
<zyga> nice
<zyga> so that's exactly what we tarballed
<zyga> but created programmatically, right?
<mborzecki> -rwxr-xr-x 1 root root 8 2018-05-14  ï»¿uboot.env
<mborzecki> -rwxr-xr-x 1 root root 8 2018-05-14  uboot.env
<mborzecki> yes
<mborzecki> zyga: i think that core fssck is to blame
<zyga> I afgree
<zyga> it looks like a bug, clearly, there
<mborzecki> when i use fsck.vfat from host the entries are looking good
<zyga> hmm
<zyga> hold on, and which fsck are we using?
<mborzecki> dang, hsot fsck does the same too
<mborzecki> zyga: well, the one from core right?
<Chipaca> mborzecki: zyga: that's what mvo's patch to dosfstools fixes
<Chipaca> https://github.com/dosfstools/dosfstools/pull/83
<mup> PR dosfstools/dosfstools#83: [RFS] check.c: do lfn_remove  on auto_rename() <Created by mvo5> <https://github.com/dosfstools/dosfstools/pull/83>
<mborzecki> anyways, fsck 4.1 and 3.0.28 (from core snap) appear to do the same, i end up with 2 entries, one has only shortname (uboot.env) and the other shortname (fsck0000.000) and lfn (uboot.env)
<mborzecki> Chipaca: right
<Chipaca> if upstream had at least ACKed the issue we could distropatch it
<Chipaca> if they don't, we'd have to be a lot more sure about it fixing the core issue
<mborzecki> once mounted this appears as 2 files with identical names ;)
<mborzecki> (should kernel at least display it differently?)
<Chipaca> mborzecki: there are options to mount to control that
<Chipaca> mborzecki: i think the one mvo suggested was win95
<Chipaca> (if you look for win95 in man mount you'll see the options)
<mborzecki> aah, it was in mvo's change, let me try that, i'm using check=s right now
<zyga> try dosbox
<mborzecki> -rwxr-xr-x 1 root root 8 2018-05-14  ï»¿uboot.env
<mborzecki> -rwxr-xr-x 1 root root 8 2018-05-14  UBOOT.ENV
<mborzecki> all ups is the one without lfn
<Chipaca> this way at least we can point to one or t'other :-)
<mup> PR snapd#5155 opened: interfaces/apparmor: use strict template on openSUSE tumbleweed <Created by zyga> <https://github.com/snapcore/snapd/pull/5155>
<zyga> mborzecki: so on dosbox things work better?
<mborzecki> zyga: you can tell which file is which
<zyga> hmm
<zyga> can we mount things like that in linux?
<zyga> mborzecki, Chipaca: can we land https://github.com/snapcore/snapd/pull/5142 ?
<mup> PR #5142: many: add "snap debug sandbox-features" and needed bits <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5142>
<Chipaca> zyga: why squash-merge?
<zyga> junk in history
<Chipaca> zyga: that usually means you want to backport it
<Chipaca> and that concerns me :-)
<Chipaca> s/backport/cherrypick/
<zyga> no, I don't need that :")
<zyga> my main motivation is to use that branch
<zyga> to filter tests better once we do the opensuse experiment
<zyga> cachio: would it be hard to add opensuse tumbleweed to CI?
<zyga> cachio: even as a manually used image
<zyga> I could definitely use it
<mborzecki> yup TW makes sense
<mborzecki> sort of early upgrade of the image is there for arch already, tw could do the same
<mborzecki> although iirc opensuse can do more than 1 kernel installed
<niemeyer> Chipaca, cachio: Coming?
<Chipaca> niemeyer: trying to
<niemeyer> :)
<Son_Goku> mborzecki, Fedora and openSUSE support multiversioned kernel packages
<mborzecki> Son_Goku: thanks, fedora i know about, but i didn't remember how suse does it
<Son_Goku> same exact way
<mborzecki> well, at least some drstros as sane ;)
<Son_Goku> pretty much all RPM-based distributions use multiversion/slotted kernel packages
<zyga> pstolowski: feedback con 5032
<pstolowski> zyga: thanks, looking
<pstolowski> zyga: ouch, thanks, mistake in conflict resolution
<zyga> W: Target Translations (main/i18n/Translation-en_US) is configured multiple times in /etc/apt/sources.list.d/google-cloud-sdk.list:1 and /etc/apt/sources.list.d/google-cloud-sdk.list:2
<zyga> apart from apt lock being held
 * zyga -> lunch 
<zyga> https://www.youtube.com/watch?time_continue=1&v=F8nrpe0XWRg <- interesting, so far watched about 1/3rd though
<mborzecki> off to pick up the kids
<pedronis> pstolowski: I did a first pass on #4767 , have also some questions there
<mup> PR #4767: interfaces: disconnect hooks <Critical> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/4767>
<pstolowski> pedronis: ty, checking
<pedronis> zyga: #4889 needs a j-dstrand review ?
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> pedronis: not sure, I think it doesn't but we can add one
<zyga> pedronis: jamie is a bit busy lately so I think I will wait for a +1 from gustavo first
<cachio> zyga, pedronis FYI issue on xenial 32bits fixed
<zyga> cachio: what was the issue?
<cachio> zyga, sometimes when the execution was done from a fast machine
<cachio> zyga, the system tried to do a release upgrade because it is a new lts
<cachio> zyga, and it was locking
<cachio> I updated the file /etc/update-manager/release-upgrades
<cachio> and the problem is gone
<zyga> thanks!
<zyga>  that is great
<cachio> I could reproduce it from canonistack
<cachio> zyga, imposible from here
<kenvandine> is there a way to unrelease a revision from a specific track using the command line?
<kenvandine> we can't use the web UI because the track in question doesn't appear in the web UI
<noise][> kenvandine: you can either release a different revision to the channel or close it
<kenvandine> noise][, ah, then they can release a revision to that track again later?
<kenvandine> this is for the esr channel from mozilla, they want to test releasing the snap to esr60/stable then unpublish it until they are sure
<kenvandine> noise][, although i'm not sure why :)
<noise][> kenvandine: yes, they can release to that track/risk and then close it again
<kenvandine> noise][, thx
 * cachio afk
<Chipaca> ttfn peeps
<zyga> rain!
<ogra_> butter!
<mup> PR snapcraft#2119 closed: repo: automatically prune unneeded stage-packages <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2119>
<thresh> me dances
<thresh> or rather
 * thresh dances
<popey> :)
<zyga> mborzecki: there?
<mborzecki> mborzecki: yeah
<mborzecki> pfff 5080 failed because master changed :(
<zyga> ah
<zyga> I re-ran tests on nearly all failing branches
<zyga> and we have very very green set of PRs
<mborzecki> 'merge material'
<zyga> mborzecki: but I wanted to ask about https://github.com/snapcore/snapd/pull/5142
<mup> PR #5142: many: add "snap debug sandbox-features" and needed bits <Squash-merge> <Created by zyga> <https://github.com/snapcore/snapd/pull/5142>
<zyga> it's got one +1 and is green
<mborzecki> ah, forgot to +1 it
<mborzecki> btw. updated #5080
<mup> PR #5080: many: support 'system' nickname in interfaces <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5080>
<zyga> thanks, looking
<zyga> thanks!
<mup> PR snapd#5142 closed: many: add "snap debug sandbox-features" and needed bits <Squash-merge> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5142>
<zyga> it's raining again
<zyga> no bike today
<zyga> it's raining again
<zyga> ah, I'm online now :)
<sveinse> I'm having problems using docker under snap. When trying to run docker build, I get "unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /var/lib/snapd/void/Dockerfile: no such file or directory"
<zyga> sveinse: ha, that's pretty interesting
<zyga> notice the path
<sveinse> it is
<zyga> the "void" directory is used when the path you were in cannot be represented in snap context
<zyga_> sveinse: note the path of the Dockerfile, the "void" directory is used when your original path cannot be represented inside the snap
<zyga> ping pong
<zyga_> (my network is flaky on my laptop)
<sveinse> Still here :D
<zyga_> what was your working directory when you ran the command?
<sveinse> zyga_: My directory containing the Dockerfile. I ran "docker build -t ubuntu:myimage ."
<sveinse> Just the way I'd use "normal" docker
<zyga_> right... but was it?
<zyga_> *what was it
<thresh> is there a prebuilt snapcraft package built from git?
<zyga_> snapcraft in the edge channel?
<thresh> ...except from snapped version :)
<thresh> I meant ubuntu/debian .deb packages, sorry.
<zyga_> ah, I see
<zyga_> well, soon it would work
<zyga_> (the new snapcraft with virtualization)
<zyga_> but that's WIP
<thresh> the reason is I build my snap in a docker container, and this one does not come with systemd as init, etc, which makes snapd unpossible to run
<zyga_> ah, I see
<zyga_> sergiusens: ^ is there a ppa with snapcraft deb?
<sergiusens> zyga: no, we don't do PPAs
<sergiusens> thresh: you could use snapcore/snapcraft:edge (or look at the docker file for it and adapt yours)
<thresh> righto
<sveinse> zyga_: this is the Dockerfile: https://bpaste.net/show/cd8aed8faf03
<thresh> thanks!
<zyga_> sveinse rather than the contents of the docker file I was asking about its location
<zyga_> sveinse the "void" directory shows up whenever you are in a directory that doesn't exists from the point of view of the snap's filesystem
<zyga_> sveinse for example
<zyga_> sveinse mkdir /foo
<zyga_> sveinse cd /foo
<zyga_> sveinse snap run --shell hello-world
<sveinse> zyga_: /home/sveinse/sp/build/ubuntu/ubuntu-14.04-docker/tmp.docker/
<zyga_> hmm
<zyga_> that directory should exist just fine
<zyga_> can you export SNAP_CONFINE_DEBUG=yes and run the command again?
<sveinse> I even run "cd $(realpath "$PWD")" prior to calling docker to ensure I'm in a symlink-free path
<sveinse> zyga_: https://bpaste.net/show/d6e3b95f6276
<zyga_> ha
<zyga_> DEBUG: cannot remain in /srv/home/common/sp/build/ubuntu/ubuntu-14.04-docker/tmp.docker, moving to the void directory
<zyga_> your home directory is not /home, it's really /srv/home/common
<zyga_> is this a NFS mount?
<sveinse> no, its another partition. I dualbooted between 18.04 pre-release and 17.10, so I had a common partition for all non-distro related home files
<zyga_> please use a bind mount, this will resolve the issue
<zyga_> that is, make your home directory really appear in /home, using a bind mount
<zyga_> that's mount --bind /old /new
<zyga_> or mount --rbind /old /new if you need recursive
<zyga_> you can also put this into /etc/fstab
<sveinse> is *is* a bindmount. I just don't want it at /home or /home/user
<zyga_> brb
<zyga_> sveinse it must be in your $HOME
<sveinse> ok, then, sorry, I won't change that now. So I'll revert to the apt based docker then.
<zyga_> sveinse may I ask why you don't want that to appear as /home/$LOGNAME?
<zyga_> it's not easy to support arbitrary locations for us
<zyga_> so I want to know the motivation better
<sveinse> zyga_: sure, here's my use-case: As said, I have multiple distros running. And my experience with sharing /home between these have failed miserably in the past, so each distro has its own individual /home. So all I have which is worked on from both distros is put in /home/common, which is a bind-mount to a third partition. Everything is then simply symlinked from my to the common dir, which takes 3
<sveinse> minutes to setup.
<zyga_> sveinse so if you use /home/$LOGNAME as your home (separate home for each distribution) and use /home/common as a bind mount from /srv/whatever it would work again
<zyga_> do you see what I mean?
<sveinse> Actually the real mount for the /home/common bind mount is actually /srv, so testing that wouldn't be too hard
<zyga_> you can just bind mount now (without touching your fstab)
<sveinse> zyga_: wait, I was wrong. I have it oposite. /home/ is bind mount to /srv/home-18.04 and then /home/common being a symlink to /srv/home/common
 * zyga_ has IRL interrupt
<sveinse> zyga_: I gotta go, my time box for this is up, so I have to revert to the other docker. Thanks for your help.
<zyga_> sveinse o/
<popeycore> gnnnnnnn
<popeycore> installing a snap made my x session explode. *again*
<jhobbs> How do I set a proxy for snapd, and only snapd, to use? I don't want to set a system wide proxy
<jhobbs> do I use "snap set core proxy.https=http://my.proxy" ?
<Pharaoh_Atem> jhobbs: you can't in Ubuntu
<Pharaoh_Atem> since it uses /etc/environment for environment variables
<jhobbs> Pharaoh_Atem: that doesn't preclude applications from having their own proxy settings
<mwhudson> jhobbs: i think the snap set thing yes, although i haven't tried to use it, only read the code :)
<jhobbs> mwhudson: ok, it didn't seem to work for me, and i don't know enough to get any feedback from snapd about whether it's using it or not, so I found a way to do it via environment variables instead - thanks for looking into it
<jhobbs> reading the code is the one thing i didn't do
<mwhudson> heh
<mwhudson> i hope to use it soon so well
<mwhudson> there's always a systemd drop-in i guess
<jhobbs> yes, that's what i used
<jhobbs> http://paste.ubuntu.com/p/K8VncJv4vp/
<mwhudson> uh by looking at this code calling snap set core proxy.http=... *writes* to /etc/environment
<mwhudson> but i suspect it does not actually update the proxies used by snapd
<mwhudson> ?
<mwhudson> so you need to snap set ... and then restart it to get snapd to notice...
<mwhudson> jhobbs: oh heh the snap set core proxy.* is only supported on core systems it seems
#snappy 2018-05-15
<mup> PR snapcraft#2132 closed: errors: generic exception for common.run[_output] <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2132>
<ryan___> hi
<ryan___> How might I be able to deploy snaps without going to the snap store?
<ryan___> Like I have built snaps, but I'd like to distribute it only to specific users whom should be able to download it
<mborzecki> morning
<mborzecki> much fun when the gnome session dies out of the blue
<zyga> Hey
<mborzecki> zyga: hey
<mborzecki> zyga: so today we merge everything that's green right?
<mborzecki> omg, today must be some gnome shell love day
<mvo> hey mborzecki
<mvo> mborzecki: just saw your helper to corrupt an image, nice!
<mborzecki> mvo: hey, yeah took some time, fat is super annoying to parse
<mborzecki> all that legacy cruft :/
<mvo> mborzecki: I'm totally with you here :)
<mvo> mborzecki: I just verified that https://github.com/dosfstools/dosfstools/pull/83 works with the corrupted image created from your script. this is really nice
<mup> PR dosfstools/dosfstools#83: [RFS] check.c: do lfn_remove  on auto_rename() <Created by mvo5> <https://github.com/dosfstools/dosfstools/pull/83>
<mborzecki> yay
<mborzecki> mvo: any word from maintainers of dosfstools?
<mvo> mborzecki: unfortunatly not, I will try a debian bugreport next, maybe he reads those
<zyga> mborzecki: Yes, that is the plan
<mvo> zyga: good morning!
<mvo> zyga, mborzecki what did I miss fri/mon ? where are we standing?
<zyga> Man, it is so cold today
<zyga> Mvo, nothing major. Just lots of catch up with PRs
<mvo> zyga: cool
<zyga> I have a question about
<zyga> Your fixes for 8
<zyga> There is a new service there
<mvo> zyga: sure
<zyga> But there are no changes to packaging
<mvo> zyga: you mean core-fixup?
<zyga> Yes
<mvo> zyga: its an existing service
<mvo> zyga: I just extended it
<zyga> Ahh
<zyga> Ok
<zyga> I must have mistress
<zyga> Misread
<mvo> zyga: conveniently we had an issue before
<mvo> zyga: lol@mistress
<zyga> I did a compare against 6
<zyga> Because 7 didnât have a tarball
<zyga> Yeah, phone is fun ;-)
<mvo> zyga: yeah .7 was very short lived, sorry for that
<zyga> Taking the dog out
<mvo> zyga: I should have waited a bit longer
<mvo> zyga: heh, enjoy!
<zyga> No worries, just wanted to double check
<mvo> zyga: thank you for this
<mvo> zyga: I will go over the PRs now and see what comments need addressing, iirc I left some small ones so that I don't have to wait for tests. now is a good time to address them
<zyga> I need to work from downtown today
<zyga> Need to go to a government office for some paperwork
<mborzecki> uhh
<mborzecki> zyga: good luck
<mborzecki> reminds me i need to replace the my car registration
<mborzecki> btw. i'll have a longer break ~1030, my daughter has an athletic tournament at her school, going there to cheer for her
<zyga> Woot, nice :-)
<zyga> I will be home soon, grab my gear and commute
<mup> PR snapd#5156 opened: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> #5156 travis job timed out, restarted it
<mup> PR #5156: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
 * zyga is on a bus, commuting feels weird now
<zyga> Weird and inefficient
<mborzecki> zyga: no tram lines going near your destination?
<zyga> No, not even close
<zyga> Closest tram is the subway
<zyga> re
<zyga> I specifically took the slower bus to be able to sit and work on the way :)
<zyga> at this time the rush hour is over and bus is rather empty
<zyga> oh drat
<zyga> no 2fa :(
<zyga> well
<pedronis> mvo: hi
<pedronis> mvo: seems autopkgtest tests sometimes fail over a flaky snapstate test
<mvo> pedronis: good morning! do you have a link with the particular failure?
<pedronis> mvo:  https://launchpadlibrarian.net/370203382/buildlog_ubuntu-xenial-armhf.snapd_2.32.8+git720.9dc7b89~ubuntu16.04.1_BUILDING.txt.gz
<pedronis> it's one of the prereq tests
<mvo> pedronis: aha, looks like the autopkgtest vms are very slow
<mvo> pedronis: I have a look and will improve
<mborzecki> any PRs that need attention?
<pedronis> mborzecki: #4844 is now green
<mup> PR #4844: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<mborzecki> pedronis: merge or do you want to have one last look?
<pedronis> IÂ approved it
<mborzecki> very well, merging then :)
<mup> PR snapd#4844 closed: overlord/snapstate: allow core defaults configuration via 'system' key <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4844>
<mborzecki> pedronis: would you like to take a look at https://github.com/snapcore/snapd/pull/5091 too? you were the last to modify the auto refresh code and know ins and outs of this
<mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<pedronis> will do in a little bit
<mborzecki> pedronis: thanks!
<diddledan> does anyone know where the gnome-system-monitor snap source is? I want to investigate to see if anything special is done for localisations
<mborzecki> zyga: https://paste.ubuntu.com/p/wSN7fZCn6Q/ nice!
<zyga> mborzecki: yeah, now just convince people to enable apparmor
<mborzecki> hahaha
<mborzecki> zyga: fwiw there's both apparmor and selinux enabled kernel packages in aur, plus a bunch of userland packages in respective flavors, still bugs me why would one want to rebuild that much of the base system and not just use some other distro
<mup> PR snapd#5157 opened: many: improve `snap wait` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/5157>
<mborzecki> afk for 1-2h
 * zyga arrived close to the office
<mup> Bug #1771299 opened: snap is a total failure, drop it <Snappy:New> <https://launchpad.net/bugs/1771299>
<zyga> need to check where to deliver the papers
<zyga> but I can enjoy a cup of coffee and work some more from a restaurant now
<diddledan> this is a delightful morning message: https://github.com/snapcrafters/gimp/issues/27
<Chipaca> diddledan: https://giphy.com/embed/nPTXD4lJmDSTe
<diddledan> haha
<diddledan> gotta love crab ideas
<zyga> yeah
<zyga> crab is good cooked
<zyga> ;-)
<Chipaca> diddledan: also, https://giphy.com/embed/26mfgW5tgmbV7wkUg
<zyga> I love that I've seen this guy on various forums
<zyga> spewing toxic waste from his mouth
<Chipaca> zyga: s/his/their/
<mup> PR snapd#5158 opened: boot,partition: improve tests/docs around SetNextBoot() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5158>
<zyga> also the LP issue about crabs
<mup> Bug #1771299 changed: snap is a total failure, drop it <Snappy:Won't Fix> <https://launchpad.net/bugs/1771299>
<mvo> sorry for all those PRs, its leftovers from the madness last week, hopefully super trivial to review
<Chipaca> zyga: if you go to the github's user's homepage, it's illuminating
<zyga> oh?
 * zyga looks
<Chipaca> also, they're german. So it's mvo's fault.
<zyga> Chipaca: what's illuminating?
<mvo> hm, yeah, some crabs are german
<zyga> the crab picture :D
<zyga> mvo: crabs are an international exterretorial nation ;)
<Chipaca> zyga: to my prejudiced eyes, that's a website created by an agry 13-year-old
<Chipaca> angry, also
<zyga> https://translate.google.com/translate?sl=de&tl=en&js=y&prev=_t&hl=pl&ie=UTF-8&u=http%3A%2F%2Fschwender-beyer.de%2F&edit-text=&act=url
<diddledan> I love the icons all crossed-out
<zyga> well
 * zyga gets back to work
<zyga> <insert no crab emoji>
<Chipaca> zyga: ð¦Ì¸
<mvo> Chipaca: what website is this?
<zyga> where is no-space combining strike-through glyph
<mvo> Chipaca: I just saw the bugreport?
<Chipaca> mvo: starting from this *other* bug report by the same crabby person: https://github.com/snapcrafters/gimp/issues/27
<Chipaca> zyga: U+0338
<Chipaca> zyga: all combinings are zero-width, fwiw
<zyga> Chipaca: this bug report is zero-value, all crab
<Chipaca> zyga: https://www.youtube.com/watch?v=PhM4VQFkw04
 * zyga looked at twitter and ...
<zyga> https://twitter.com/nixcraft/status/996283804527378432
<Chipaca> zyga: fwiw i'd've set it to 'opinion' more than 'won't fix'
<zyga> Chipaca: thanks, though I doubt we will fix this guy
<Chipaca> zyga: "won't fix" means you think they have a point :-)
<zyga> I think they lost the point a long time ago :)
<zyga> mvo: ^ that's the vfat issue
<mvo> zyga: "opinion" might be best, otoh its fine, one open bug is enough
<Chipaca> mvo: rationale*
<Chipaca> :-)
<mvo> zyga: this is briliant
<mvo> Chipaca: *cough* thank you
<mvo> Chipaca: I should have written that in GH, then I could edit it ;)
<Chipaca> mvo: ikr
<zyga>  github is doubleplusgood
<mvo> zyga: thanks for your comments in the PRs \o/
<zyga> mvo: I'm going through it
<zyga> I was thinking if it would be better to use present tesnse
<zyga> rather than snapd will do this and that
<zyga> I can propose one on top once this lands
<mvo> cachio: hey, good morning! how is the QA for .8 looking? I heard there might be issues ?
<mvo> zyga: sure
 * diddledan spies popey is awake
<zyga> mvo: https://github.com/snapcore/snapd/pull/5158/files#r188209242
<mup> PR #5158: boot,partition: improve tests/docs around SetNextBoot() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5158>
<zyga> https://github.com/anordal/shellharden/blob/master/how_to_do_things_safely_in_bash.md
<zyga> ^ ^ ^ interesting read
<kjackal> hey zyga, just read you did some cuda tinkering with snaps, is any of your work public somewhere?
<zyga> kjackal: hey
<zyga> kjackal: I didn't get anything operational
<zyga> kjackal: unfortunately I no longer have nvidia hardware
<kjackal> thats fine, I am looking for some guidance
<zyga> (or one that works with current cuda)
<kjackal> How would cuda integration work?
<zyga> kjackal: cuda is just some userspace stuff really
<zyga> kjackal: the opengl interface today should give you access to nvidia character devices
<kjackal> How did you manage the cuda-drivers installation?
<zyga> kjackal: make a cuda hello world
<zyga> kjackal: that was long ago, I don't recall that anymore
<zyga> kjackal: my advice is as follows:
<zyga> kjackal: 1) build the simplest cuda program you can
<zyga> kjackal: 2) ldd it, print that out
<zyga> kjackal: 3) snap it manually, use the opengl interface
<zyga> kjackal: 4) run it and see what happens
<zyga> kjackal: put that on a forum and CC mborzeck1
<zyga> he has the recent hardware and should be able to help you out
<Chipaca> mvo: when you have a moment, can we talk about #1739097?
<mup> Bug #1739097: "This leaves <snap> tracking edge." <snapd:In Progress> <https://launchpad.net/bugs/1739097>
<zyga> we correctly put all the things inside the sandbox now
<zyga> so the only possibly missing thin is a userspace library bit
<zyga> we should copy all of those but nobody tested that
<kjackal> zyga: I am not sure I can follow that path, I need to make the nvidia-docker working :(
<zyga> kjackal: nvidia-docker?
<zyga> how is that related
<zyga> E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource temporarily unavailable)
<zyga> E: Unable to lock directory /var/lib/apt/lists/
<zyga> wasn't this fixed yesterday ^ ?
<zyga> mvo: please fetch origin and rebase your latest PRs
<zyga> kjackal: I don't know anything about nvidia-docker
<kjackal> zyga: nvidia-docker needs the cuda drivers installed on the host machine
<zyga> kjackal: I can help you with snaps, not docker
<kjackal> sure, forget anything I said about docker
<kjackal> the question is how do I deploy the cuda-drivers deb package ?
<zyga> I don't know
<zyga> do you mean install?
<zyga> I assumed you just install that and that's it
<kjackal> apt-get install cuda-drivers
<kjackal> zyga, I hope the missing link is the cuda-drivers, the rest of the stack seems to be working, but I will know if i get cuda working
<kjackal> zyga: I get this error: /snap/microk8s/x1/usr/bin/nvidia-container-cli --load-kmods configure --ldconfig=@/sbin/ldconfig.real --device=all
<kjackal> --utility
<kjackal> --pid=3426 /var/snap/microk8s/x1/lib/docker/overlay2/8e97d76a3e4a0b2d05f11d4744b805ab91bad8caa62c39a942d2f110f9fc7d68/merged]\\\\nnvidia-container-cli:
<kjackal> initialization error: load library failed: libnvidia-fatbinaryloader.so.390.30
<zyga> I don't know what this is or what you are doing
<zyga> are you running inside docker inside a snap?
<zyga> can you rewind to just plain system with nvidia and cuda working and move from there
<kjackal> lets forget about docker, I have a binary inside my snap that needs to load libnvidia-fatbinaryloader.so.390.30 that comes with cuda-drivers
<zyga> do you get any denials?
<zyga> where is the library relative to the root of the snap
<kjackal> I am in classic confinement
<zyga> oh
<zyga> that's even more messy then
<kjackal> :) it is
<mvo> Chipaca: sure, didn't we fix the message a while ago?
<Chipaca> mvo: that's why we're having this conversation :-)
<mvo> zyga: I can rebase/repush, I thought my master was up-to-date, let me double check
<Chipaca> mvo: it was fixed to be unambiguous, yes
<Chipaca> mvo: unambiguously wrong :-D
<zyga> mvo: then the fix for apt unattended upgrades is wrong
<kjackal> I was thinking that during the install hook I could apt-install cuda-drivers and then update the LD_LIBRARY_PATH of my wrapper. But this does not sound right. zyga?
<Chipaca> mvo: sorry i missed this, to be fair you did tag me and i missed it
<zyga> kjackal: that's all crazy IMO
<zyga> kjackal: if your snap's hook uses apt it is not a good snap IMO
<mvo> Chipaca: oh, so this means "Snap %q is *now* tracking %v"?
<mvo> Chipaca: or in what way is it wrong?
<zyga> kjackal: can you please go back
<Chipaca> mvo: the message is printed when the snap is tracking channel X, but the revision is from channel Y
<zyga> kjackal: run a hello-world cuda app outside all magic
<zyga> kjackal: share that
<zyga> kjackal: and let's iterate
<mvo> zyga: what fix was that? did it happen in one of the recent PRs?
<zyga> kjackal: can you get that part to work?
<zyga> mvo: I don't know, cachio fixed it
<mvo> zyga: ok
<kjackal> what would that giveme zyga? What would be the next steps?
<mvo> Chipaca: what will happen in this case? the snap keeps tracking channel X ?
<zyga> kjackal: that would give you a binary
<Chipaca> mvo: the snap is tracking channel X, yes
<zyga> kjackal: you can inspect that binary, strace it
<zyga> see what it loads
<zyga> kjackal: see what it needs to operate
<zyga> kjackal: then you can put that binary (built binary) into a snap you made
<zyga> kjackal: run it there
<zyga> see what braks
<Chipaca> mvo: if a revision is released to channel X it'll grab that, it's only getting things from Y because X is closed
<zyga> *breaks
<zyga> see why, iterate
<zyga> eventually you will be able to run that built binary inside your snap
<zyga> kjackal: I suspect you will do more things after that but before this is achieved I don't know what we are doing
<mvo> Chipaca: ok, I see. sorry for this
<Chipaca> mvo: it's not a very clear corner case
<Chipaca> mvo: in the bug report i suggest "this revision is from channel %s; we'll continue to check channel %s for updates"
<Chipaca> mvo: but i don't know if that is clear
<Chipaca> also the royal we is probably not what we want
<mup> PR snapd#5159 opened: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<mvo> Chipaca: yeah, the message looks like the right direction though
<zyga> https://github.com/snapcore/snapd/pull/5159 is simple, will let me build the tests  that jdstrand requested
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> anyone wants to look quickly?
<Chipaca> popey: you're good with words, sometimes, can you think of a better way of saying this?
 * Chipaca only used "sometimes" to not trigger the "aw shucks" response
 * zyga goes to the goverment office to do paperwork, ttyl
<zyga> kjackal: I'll be connected but I won't reply for a while, let's keep chatting, I find this topic interesting (if only I had correct HW)
<Chipaca> zyga: kjackal: for extra fun, you can run cuda stuff on PRIME hardware when the intel card has the con
<kjackal> :)
<Chipaca> zyga: and that might royally mess up the detection stuff
<Chipaca> dunno
<popey> Chipaca: hello. what words in particular, and where?
<Chipaca> popey: when you 'snap install --edge foo' but edge is closed right now
<Chipaca> popey: so you get it from, say, beta instead
<Chipaca> popey: right now we print something that's incorrect, so looking at fixing that
<Chipaca> popey: so far best attempt is "this revision is from channel %s; we'll continue to check channel %s for updates"
<Chipaca> popey: but we don't use the 'we' elsewhere :-)
<popey> "$channel for $snap is closed, forwarding to $channel+1"
<Chipaca> popey: that does not convey the 'as soon as something is pushed to edge you'll get it instead of this beta crud'
<popey> you will?
<popey> I thought you get bumped to the next channel down and stay there
<Chipaca> that's what tracking means
<Chipaca> nope
<popey> like, if you were on beta, and I close it, you're now in stable
<popey> if I re-open beta, you flip back to beta?
<Chipaca> yes
<popey> wow
<diddledan> who understands why gimp isn't picking up localisations? because I sure as chocolate don't understand it
<popey> this is not well known
<Chipaca> popey: not even the whole snapd team was aware of it :-)
<popey> loooolz
<diddledan> I found this post https://forum.snapcraft.io/t/lack-of-compiled-locales-breaks-gettext-based-localisation/3758/14 but that claims it's fixed
<Chipaca> diddledan: doesn't everybody speak esperanto already?
<diddledan> if they speak esperanto they'll not get the UI in their language, instead it'll be en_US
<Chipaca> diddledan: i thought en_US was esperanto 2.0
<kjackal> zyga: what will we do with the strace of the cuda program?
<Chipaca> popey: "$trackingChannel for $snap is closed, temporarily forwarding to $snapChannel"?
<popey> better
<Chipaca> k
<kjackal> We will be able to identify libraries needed for a cuda program to function, right? Then what?
<mup> PR snapd#5160 opened: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <https://github.com/snapcore/snapd/pull/5160>
<zyga> kjackal: look at the ser of files being accessed
<zyga> kjackal: then we check if current nvidia integration handles all of them
<niemeyer> Moins
<zyga> Hey
 * zyga waits in line to file paperwork, 60 people in front, ouch
<kjackal> "current nvidia integration" ?
<Riddell> 'support all snap apps, including "classic" apps'  what are classic apps?
<mvo> pedronis: the above pr is to make the issue in the handlers_prereq_test.go:247: more robust
<zyga> kjackal: we have special code that bridges nvidia driver to snap space
<zyga> kjackal: but it doesnât apply to classic confinement
<zyga> Riddell: classic confinement is the way we describe snaps that run without a special mount namespace and with little to no confinement
<zyga> Like typical classic packages
<zyga> Hence the name
<Chipaca> Riddell: i don't know what classic apps are in that context; classic snaps are what zyga just said
<Riddell> I'm writing the KDE Plasma 5.13 and this is what I have for Plasma Discover changes  'Snap support now follows Snap application permissions and it's possible to use classic Snap formats.'
<Chipaca> Riddell: I literally can't even :-)
<Chipaca> Riddell: you're going to have to ask the author for clarification i'm afraid
<Chipaca> i don't know what "classic Snap formats" are, and I can only guess at what "Snap application permissions" are
<zyga> Those are probably worded incorrectly
<Chipaca> yes
<zyga> They should be âsnaps using classic confinementâ and âsnap interfacesâ
<zyga> Not permissions
<Chipaca> zyga: _if_ that's what they meant
<Chipaca> I guess I fall back to "refusing to guess" too easily (but it's saved me in the pasts)
<Chipaca> past*
<zyga> Well, if they meant something else Iâd like to see those patches b cause we donât have such features
<Chipaca> man, i wish you could toggle a spread run to debug
<mup> PR snapd#5161 opened: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <https://github.com/snapcore/snapd/pull/5161>
<zyga> Chipaca reviewed
<pedronis> Chipaca: could you look at #5077 ?
<mup> PR #5077: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/5077>
<Chipaca> zyga: the truncated bit is because the fake store replies with "" for tracking channel
<Chipaca> zyga: (there's an ad hoc comment on the test)
<zyga> Ah
<Chipaca> zyga: but you're right about the i18n thing, will fix
<zyga> Thanks
<Chipaca> zyga: also, will reply there
<Chipaca> why am i doing it here
<zyga> Ack :-)
<Chipaca> just to make your life harder
<Chipaca> pedronis: nice PR
<zyga> Yeah, reading too
<Riddell> zyga: thanks changed to 'Snap support now follows Snap interfaces and it's possible to use the Snaps using classic confinement.'
<zyga> What does âfollowsâ here mean?
<zyga> Otherwise it reads ok
<Riddell> good question
<Riddell> 'uses Snap interfaces'?  'allows Snap interfaces'?
<Chipaca> Riddell: is this talking about a GUI?
<Riddell> Chipaca: yes
<Chipaca> does it mean that it now exposes toggles to connect interfaces?
<Riddell> Chipaca: that sounds likely
<Riddell> toggle is a real term? I love that
<Chipaca> if so, then maybe saying that ("now allows toggling interface connections") might be preferably, although i might be too deep in the argot
<Chipaca> Riddell: it's a verb and a noun :-)
<Chipaca> you just need a place name and you can go all 'buffalo buffalo buffalo' on it
<Chipaca> preferable*
<Chipaca> my language is shot (toady?) :-/
<Riddell> thanks, I've used that in https://www.kde.org/announcements/plasma-5.12.90.php#discover
<Chipaca> Riddell: nice
<zyga> Thanks Riddell
<popey> that's awesome
<popey> Riddell: is the snap plugin for kde discover installed by default - my kde neon is some months old and I manually installed it iirc
<Riddell> popey: no I don't think so, probably because last time i tried it I couldn't get it to work because it needs some newer snap library.  plasma-discover-snap-backend is the package.  but I'm mostly waiting on us moving to 18.04 before looking at snaps again
<thresh> what can I subscribe to to receive snapcraft/snapd changelogs/release notes etc?  I'm mostly interested in theming advancements, though.
<popey> Riddell: great, should work fine in 18.04. Happy to help with testing etc. :)
<Wimpress> Riddell: I need to schedule the next KDE catchup with Aleix and Harald, would you like an invite?
<Riddell> Wimpress: sure
<Wimpress> OK. Expect an invite soon :-)
<mborzeck1> re
<zyga> thresh: there should be a topic on the forum that you can subscribe to
<zyga> Iâm relocating now so I cannot easily share
<zyga> thresh: so looking for themes I can see several topics
<zyga> thresh: but the one to follow, IMO, is this one https://forum.snapcraft.io/t/supporting-desktop-themes-via-the-content-interface/4122
<zyga> thresh: as the person posting is also working on the feature
<zyga> thresh: you can bookmark the topic to easily return to it (a forum bookmark, not browser one)
 * zyga reads https://blog.ubuntu.com/2018/05/15/trust-and-security-in-the-snap-store
<zyga> well written :)
<thresh> many thanks
<pedronis> mborzeck1: hi,  #5091 looks good,  mostly some suggestions to fold some things more into helpers
<mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<Chipaca> mborzeck1: how did you fix the 'could not get lock' problem you were having yesterday?
<zyga> Chipaca: AFAIK chacio changed something in the image
<Chipaca> zyga: i just got the same thing again
<zyga> Chipaca: it is the bionic update kicking in that is doing that from what he told me
<Chipaca> https://api.travis-ci.org/v3/job/379141529/log.txt
<zyga> Chipaca: yeah, me too
<zyga> I'd like to see what the fix did
<mborzeck1> pedronis: thanks for the review
<zyga> I didn't see any PRs, perhaps the image was edited
<mborzeck1> Chipaca: it's gone now, all i need to know ;)
<Chipaca> mborzeck1: 's not :-)
<Chipaca> bah, maybe i need to merge master
<Chipaca> (but i did before starting...?)
<mborzecki> i thought this was 'image' related
<mborzecki> saw a commit with related message pushed to spread-images
<mborzecki> Chipaca: https://github.com/snapcore/spread-images/pull/10/commits/a84f101cd538da1a63da4da513aca436dce5b15f
<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>
<zyga> cachio: we are still seeing the issue
<zyga> cachio: perhaps we should drop unattended-upgrades from the image?
 * zyga resumes reviews
<pstolowski> pedronis: i've addressed your comments to #4510 (and the test failure is unrelated, it's what zyga just mentioned i think)
<mup> PR #4510: asserts: use Attrer in policy checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
<zyga> gaah
<zyga> is there a tool that fixes this automatically
<zyga> testutil/lowlevel_test.go:663: github.com/snapcore/snapd/testutil.CallResult composite literal uses unkeyed fields
<pedronis> pstolowski: thx, I saw the mails passing by, I will look in a little bit
<mborzecki> hm isn't apt smart enough to not block on prompt when stdin is not a tty? https://github.com/snapcore/spread-images/pull/10/commits/a84f101cd538da1a63da4da513aca436dce5b15f#diff-91d7306570fb598492422cd22f1aebfdR43
<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> iirc dpkg-reconfigure does it already
<zyga> mborzecki: I bet it is using a tty
<zyga> mborzecki: the whole session runs in a ptty
<zyga> mborzecki: and the issue is not prompting, is it?
<zyga> it's running "apt-get update"
<mborzecki> no clue, that's what the commit message is fixing
<mborzecki> s/message//
<mborzecki> #5156 timeouted again
<mup> PR #5156: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
<zyga> hmm hmm
<zyga> Chipaca: do you know of a tool that automatically adds struct field names to literals?
<Chipaca> zyga: I do not
 * zyga does *not* fancy adding 100s of those by hand
<Chipaca> zyga: what PR is that?
<zyga> https://github.com/snapcore/snapd/pull/5159
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> hmm
<zyga> I could make it a [2]interface{}
<zyga> it would work, no?
<zyga> (the type)
<zyga> then the literal would be OK
 * zyga tries
<Chipaca> zyga: plz no :-)
<zyga> http://paste.ubuntu.com/p/hSgWFpPby2/
<zyga> that's the whole diff and it passes go vet
<zyga> I think typing those Call/Result field headers will drive people mad
<Chipaca> zyga: so, RCalls() is nice because you get to see the whole thing
<Chipaca> zyga: and you have Calls()  that returns jut the names
<zyga> yeah, for backwards compat
<Chipaca> zyga: why not have CallResults() that returns just the values?
<zyga> I plan to drop (at least) the usage of Calls
<mborzecki> zyga: func callResult(call string, result interface{}) CallResult { return CallResult{Call: call, Result: result} } ?
<zyga> Chipaca: beause it's not easy to use then
<zyga> Chipaca: if a test has 50 syscalls that's not readable
<Chipaca> zyga: and mborzecki's option? ^
<zyga> mborzecki: that's still passing that in every single line of tests that checks this, vs not passing anything new
<zyga> the real application will be for code like ...
<Chipaca> []CallResult{{...}, {...}, ...}
<zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/secure_bindmount_test.go#L80
<mborzecki> hmm
<zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/secure_bindmount_test.go#L176 is even better (fits my whole screen)
<zyga> I have that already patched to use Rcall
<zyga> I just didn't run vet before :/
<Chipaca> zyga: FWIW I think the long things are more readable with the named fields
<zyga> https://github.com/snapcore/snapd/blob/master/cmd/snap-update-ns/change_test.go#L1194 <- imagine if this was filled with Call Result
<zyga> how is that helping?
<Chipaca> zyga: do you have it with the results already?
<Chipaca> zyga: just the names alone is a quagmire to read
<zyga> yeah, one sec
<Chipaca> zyga: with the values it's probably worse
<Chipaca> but, show me
<zyga> http://paste.ubuntu.com/p/dZYBgDMfVs/
<zyga> a fragment, I have it split into some branches because it was written slightly ahead of master
<zyga> FYI: the code has both calls/rcalls
<zyga> I plan to drop calls, this is just to prove that it works
<zyga> I will keep calls in testutil/lowlevel_test.go only
<zyga> oh
<zyga> one thing I could do is to make the return value optional to reduce the number of nil's
<zyga> not sure if worth doing
<zyga> Chipaca: also interesting to see how we mount things if you didn't know that before
<zyga> Chipaca: shall I push http://paste.ubuntu.com/p/zTXJnJjsqh/
<zyga>  
<Chipaca> zyga: my 5Â¢ is that it is not less readable with the labels, and in some cases might be more, and you get to drop th enils
<zyga> Chipaca: ok, let me think how to rewrite that
<Chipaca> but, you spend a lot more time looking at this than I do
<Chipaca> zyga: I can do it for you after lunch if you'd rather not
<Chipaca> sounds like a fun bit of perl :-)
<zyga> Chipaca: fun and perl is only true if perl is EOLd and debian tools are rewritten in rust
<zyga> ;)
<zyga> Chipaca: as a compromise
<zyga> C and R
<Chipaca> maybe it's just that i need lunch
<zyga> instead of Call Result?
<zyga> then it's shorter but still explicit
<Chipaca> sure
<zyga> jdstrand: offtopic, are you back today?
<zyga> Chipaca: thanks, I'll do this
<zyga> Chipaca: drop your feedback there so that others know we discussed this
<zyga> Chipaca: FYI, I just used sublime's multi-line cursor to edit that qucikly
<zyga> Chipaca: should I split R: into R: E:
<zyga> result/error
<Chipaca> zyga: is it ever not an error or nil?
<Chipaca> i guess when it's a fd and stuff
<Chipaca> eh
<zyga> it's either an error or it is whatever the syscall returns
<Chipaca> zyga: probably yes
<zyga> this would allow me to improve one other thing
<zyga> I have a checker for syscall lists
<zyga> because the DeepEquals one is garbage
<zyga> it could use ErrorMatches on error implicitly
<zyga> so error traces would be less repetetive
<pedronis> zyga: is #5159 motivated by some open PRÂ ?
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> yes, jamie asked me to write tests that show the file descriptor values clearlyt
<zyga> as many of the branches related to layout fixes had tests like that
<pedronis> ok, thx
<zyga> *clearly
<zyga> Chipaca: pushed now
<zyga> and I should move
<zyga> I will resume reviews soon
<zyga> mvo: interesting failure
<zyga> + echo 'ERROR: test-snapd-requires-base should not be installable without test-snapd-base'
<zyga> ERROR: test-snapd-requires-base should not be installable without test-snapd-base
<zyga> this is on https://github.com/snapcore/snapd/pull/5160
<mup> PR #5160: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <https://github.com/snapcore/snapd/pull/5160>
<zyga> maybe a real bug?
 * zyga walks
<zyga> The agenda for the Fedora server SIG is interesting this week
<zyga> We have one topic requiring discussion this week: whether we will ship a Fedora base snap under the Fedora Server umbrella. Please see the earlier email to this list for further details.
<Chipaca> :-D
<mborzecki> tests/main/base-snaps failing in Chipaca's and mvo's PRs
<zyga> Yes, I commented on one of the PRs
<mborzecki> zyga: yeah, it was in mvo's pr which was semi-related, but Chipaca's PR is unrelated
<zyga> I think it is either a racy test or racy bug
<mborzecki> #5160 and #5161
<mup> PR #5160: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <https://github.com/snapcore/snapd/pull/5160>
<mup> PR #5161: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <https://github.com/snapcore/snapd/pull/5161>
<jdstrand> kjackal: hey, responding now since I was on holiday. I'll try to answer all your questions I see in backscroll
<jdstrand> kjackal: there is not a way to edit the apparmor profiles and reload them from a hook as the security policy would disallow that. for a classic snap, it may be possible, but not sure which hook could be used (this isn't something that is typically done)
<jdstrand> kjackal: there is actually a way to provide your own profile though. you use --security-opt apparmor=some-profile. see https://docs.docker.com/engine/security/apparmor/
<mvo> mborzecki, zyga ups, I know why its failing, let me fix it
<Chipaca> mvo: tell me more! (mine's also failing)
<jdstrand> kjackal: however, you can't create your own profiles (see previous answer), but you could specify one from your snap
<mvo> Chipaca: I relesed test-snapd-base to stable which breaks exiting tests
<jdstrand> kjackal: you'd really want to copy docker-default then add the signal rule to allow your snap to send signals to it
<mvo> Chipaca: I undid that now
<Chipaca> mvo: lel
<Chipaca> mvo: as punishment now you must review #5161
<mup> PR #5161: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <https://github.com/snapcore/snapd/pull/5161>
<mvo> Chipaca, zyga, mborzecki should be good again, sorry for that. I will tweak my other PR to work somehow
<Chipaca> mvo: :-D
<jdstrand> kjackal: for a docker from a deb, this would be your best option and a manual step. modifying docker-default is going to be tricky as dockerd will regenerate it on daemon start
<jdstrand> kjackal: an option is to ship your own dockerd and plugs 'docker-support'. another option is for you to have the docker snap (rather than deb) installed and then make snapd add the peer rules ala https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/2
<jdstrand> cprov: hi! still seeing the 504s with the public store so I filed https://bugs.launchpad.net/snapstore/+bug/1771333
<mup> Bug #1771333: frequent 504s when accessing (at least) public store reviews page <Snap Store:New> <https://launchpad.net/bugs/1771333>
<cachio> Son_Goku, hey
<cprov> jdstrand: I've commented on your public bug, the fix is coming, slightly more involving that we thought.
<Son_Goku> cachio, yo
<cachio> Son_Goku, for fedora 28 we need google_compute_engine and google_compute_engine_init too
<Son_Goku> cachio, gah, okay
<cachio> Son_Goku, and oslogin which is already done
<cachio> thanks for that
 * Son_Goku grumbles about how much he hates monorepos
<Son_Goku> cachio, I'll tackle those later today
<Son_Goku> hopefully have them ready for you during my lunch time
<cachio> Son_Goku, awesome, thanks
<kjackal> thank you jdstrand
<zyga> Iâm on the subway now. Will likely miss standup
<mborzecki> kjackal: regarding cuda, libnvidia-fatbinaryloader is what you're missing?
<kjackal> that was the first missing lib reported mborzecki
<mborzecki> kjackal: it should be picked up by our glob code in snap-confine, is libnvidia-gl also installed on the machine?
<mborzecki> kjackal: oh, and what distro is it?
<zyga> My update today is simple: catchup on reviews and gardening my PRs
<zyga> Heads up: I will be gone on Thursday , Friday and till Wednesday next week
<zyga> I will send details on the forum
<kjackal> mborzecki: I am on 16.04 and the snap is in classic confinement
<kjackal> mborzecki: why are you asking about libnvidia-gl? how would this affect you?
<mborzecki> kjackal: hm if it's classic then there should be nothing stopping it from using host libs
<mborzecki> kjackal: the detection code in snap-confine checks if nvidia lib (libnvidia-glcore.so.<driver-version>) is in arch directory, but you are on 16.04 (libs were under /usr/lib/nvidia-..) and have a classic snap, so none of this should matter
<kjackal> mborzecki: yes, I was thinking I could deploy cuda-drivers on the host, but that would not work towards a strict confinement
<jdstrand> cprov: thanks! :)
<mborzecki> kjackal: can you ldd the binary that does cuda?
<jdstrand> kjackal (cc mborzecki): to be super clear, are you classic confined or devmode confined?
<kjackal> jdstrand: classic confined. We also updated the forum request to go through a review
<jdstrand> (I ask cause I thought we discussed devmode at the sprint, but classic is being discussed here)
<kjackal> jdstrand: with devmode we had the problem that pods do not get killed. So we moved to classic confinement for now
<jdstrand> kjackal: I've not caught up on forum email yet, but will
<jdstrand> kjackal: I see
<jdstrand> kjackal: I'm still suprised that you are sending signals directly to the containers rather than using 'docker ...'
<jdstrand> kjackal: but I guess if that is how it works...
<kjackal> mborzecki: Here is the ldd: https://pastebin.ubuntu.com/p/M3QxnZ6vhj/
<mvo> mborzecki: how do I run shellcheck on my spread tests
<mborzecki> mvo: ./spread-shellcheck <path-to-task.yaml>
<mborzecki> mvo: pip install --user yq
<mborzecki> kjackal: that's just nvidia-container-cli, does not seem that it's missing any lib though
<mvo> mborzecki: have you tried ./spread-shellcheck with the yq snap? I get some strange errors here with that
<mborzecki> mvo: that's not the same yq
<mvo> mborzecki: uh, that explains it :)
<mborzecki> same name, different 'modus operandi'
<mvo> mborzecki: :(
<mvo> mborzecki: you are using the github kislyuk/yq?
<mborzecki> i was thinking about dropping yq and using pyaml directly
<mborzecki> mvo: https://pypi.org/project/yq/
<mvo> mborzecki: might not be a bad idea. I would rather like to have a snap or a deb of the yq we use. I can create a snap I think
<mborzecki> mvo: i think that moving this to spread-shellcheck will be easier/faster, it's just pyaml that we really need
<mvo> mborzecki: ok, I think you are right, it looks straightforward, will you look into it or shall I?
<mborzecki> mvo: i can do it
<mvo> mborzecki: thanks! how far are we from running this by default ? i.e. how many unfixed things are still left in the tree?
<mborzecki> mvo: all of the tests are fixed in my branch, but i'm pushing this to master in batches of 20 tests, so far we've merged 1 batch, 2nd is waiting for review sprint to finish
<mvo> mborzecki: aha, cool
<mborzecki> mvo: fwiw the check is running by default now, the tests are whitelisted by adding them to tests/unit/spread-shellcheck/must
<mborzecki> xenial apt locking thing also observable on master branch jobs
<mup> PR snapd#5162 opened: overlord/hookstate: support undo for hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/5162>
<cachio_> Chipaca, the apt-daily.service is locking now
<Chipaca> cachio_: disable it in the image
<Chipaca> cachio_: sudo systemctl disable --now apt-daily{,-upgrade}.{timer,service}
<Chipaca> cachio_: or systemctl disable --now apt-<alt+asterisk>
<Chipaca> probably
<cachio_> Chipaca, yes, I created a new image
<cachio_> I am testing it
<cachio_> Chipaca, try rexecuting your branches
<Chipaca> cachio_: i should try right now?
<cachio_> Chipaca, yes
<Chipaca> ok
<cachio_> Chipaca, I made few runs and seems to be gone the problem
<Chipaca> cachio_: tests are running, will let you know
<cachio_> Chipaca, tx
<pstolowski> zyga: can you take another look at #4510
<mup> PR #4510: asserts: use Attrer in policy checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
<pstolowski> ?
<zyga> Yes, in a sieÄ
<zyga> Just got home now
<Chipaca> jdstrand: if you're back from your holidays, what's your take on the mandb/libpipeline work? If you're not back, go away.
<mup> PR snapcraft#2042 closed: many: implement vendoring support <do-not-merge-yet> <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2042>
<zyga> re :-)
<zyga> back home, after lunch
<mup> PR snapcraft#2138 opened: ci: resurrect codecov <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2138>
 * zyga reads 4510
<Chipaca> cachio_: all good
<cachio_> Chipaca, yes
<mup> PR snapd#5161 closed: cmd/snap: fix the message when snap.channel != snap.tracking <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5161>
<Chipaca> mvo: wrt #4600, is it ready for a re-review?
<mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
<cachio_> zyga, about using jq to query the cursor_id
<zyga> yes
<cachio_> the problem there is that we don't have jq on ubuntu core
<cachio_> so, I should install/remove jq just for querying that
<cachio_> that's why I did a mix
<cachio_> between jq and the --export
<cachio_> any ideas?
<cachio_> mborzecki, ideas?
<mborzecki> cachio_: iirc there's jq in a snap
<mborzecki> meaning, packaged as snap
<mborzecki> i saw some tests installing it
<cachio_> mborzecki, yes, but all the snaps are removed during the reset
<cachio_> so I should install it for each test
<cachio_> something that I can do is to skip removing jq
<cachio_> as we do with the core, kernel, etc
<mborzecki> aah right, it's in the helpers now
<zyga> cachio_: can we use the export version everywhere?
<zyga> cachio_: or the jq version everywhere?
<zyga> I only opposed using two similar code paths
<zyga> if we can get jq let's use it
<cachio_> jq  yes
<zyga> if we cannot then the shell variant looked very good
<cachio_> but I have to add a small change to avoid removing jq during the reset
<cachio_> zyga, does it make sense?
<zyga> cachio_: use the shell version
<zyga> it's a one liner
<zyga> no complexity
<mvo> Chipaca: I'm just working on this one, the "changes()" code is incomplete and needs some tweaks
<cachio_> zyga, sorry, which shell version?
<zyga> cachio_: you had two code paths
<zyga> right?
<zyga> one if you had jq
<zyga> and another if you didn
<zyga> is that correct?
<cachio_> yes
<mborzecki> cachio_: this one https://github.com/snapcore/snapd/pull/5151/files#diff-c900b6adcccb98df1880eff34e415f2cR9
<mup> PR #5151: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
<cachio_> the --export fails in bionic
<cachio_> zyga, mborzecki this is failing on bionic
<mborzecki> cachio_: w8, what? --output=export does not work?
<cachio_> the --export is generating a binary output
<zyga> cachio_: so why do you need two variants? just use the simpler one without jq
<cachio_> zyga, the shell one was not working for bionic
<zyga> ah
<zyga> I didn't see that
<zyga> what was the issue with it on bionic?
<cachio_> because on bionic it is --export generates a binary output
<mborzecki> cachio_: --output-fields=__CURSOR --output=export ?
<cachio_> mborzecki, let me try that
<cachio_> I tried similat things
<Chipaca> zyga: is there any case where you _can't_ install something with --devmode?
<zyga> cachio_: I don't think so
<Chipaca> zyga: was that to me
<zyga> er, yes
<mborzecki> cachio_: if that fails you can try grep --binary-files=text perhaps
<zyga> sorry, distracted
<cachio_> mborzecki, ok, let me try those alternatives
<cachio_> mborzecki, journalctl: unrecognized option '--output-fields'
<mborzecki> cachio_: ok, so we're left with grep --binary-files=text then
<cachio_> journalctl: unrecognized option '--binary-files'
<cachio_> mborzecki, this is on xenial
<cachio_> mborzecki, main problem that I see is the compatibility of the different versions
<cachio_> otherwise I can install jq snap durint the prepare and then skip the uninstall
<mborzecki> cachio_: that's for grep
<mborzecki> cachio_: --binary-files=text
<cachio_> ah, sorry
<mborzecki> cachio_: journalctl --output=export -n1 |grep --binary-files=text -o '__CURSOR=.*' | sed -e 's/^__CURSOR=//'
<cachio_> mborzecki, testing on trusty and bionic
<cachio_> mborzecki, works
<cachio_> I'll update the PR with that
<cachio_> thanks!!
<mvo> Chipaca: 4600 is ready now I think
<Chipaca> mvo: +1
 * mvo hugs Chipaca 
<mborzecki> pedronis: i've updated #5091
<mup> PR #5091: many: hold refresh when on metered connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5091>
<jdstrand> Chipaca: I am back but I would have to come back up to speed on it. is the most up to date discussion in the forum?
<Chipaca> jdstrand: I don't think so, I'm not aware of a trail beyond https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877199
<jdstrand> cprov (cc ratliff): fyi, I've been trying to access the public store review url for hours and only getting 504s today. not sure when the fix will be rolled out, but at this point, manual reviews are blocked
<sparkiegeek> Chipaca, jdstrand: https://forum.snapcraft.io/t/support-for-man-pages/2299 has some more discussion
<pedronis> mborzecki: looks good, don't know if you discussed the option name with Gustavo
<Chipaca> sparkiegeek: you are correct, but that's AFAIK prior to the last entry in the bug report where it says it's Done
<Chipaca> but i might be wrong on the sequencing
<sparkiegeek> Chipaca: well, both things are threads. The Debian bug was last touched Feb 4th, and was summarised to the forum in https://forum.snapcraft.io/t/support-for-man-pages/2299/5
<sparkiegeek> there's further discussion beyond that
<sparkiegeek> i.e. does snapd NIH it and make 'snap man' or do we try and push MANPATH fixes
<zyga> sparkiegeek: as a data point I was thinking about implementing a concept of "exports"
<zyga> sparkiegeek: where a snap exports data to classic world
<zyga> sparkiegeek: like we exports apps and services today
<zyga> sparkiegeek: we could export man pages, images (wallpapers) themes and what not
<sparkiegeek> zyga: right, sounds promising
<Chipaca> sparkiegeek: jdstrand: re-reading the forum topic, maybe it's all on us at the JFDI end, i.e. it's in integrator's hands
<Chipaca> i dunno why i thought it was otherwise, given i proposed a plan of action and gustavo +1'ed it and jdstrand +1[security]'ed it
<zyga> sparkiegeek: I think we should do special support for man pages (however agreed) and eventually migrate it into the exports mechanism
<Chipaca> zyga: read the forum topic :-)
<zyga> we're on slashdot :) https://news.slashdot.org/story/18/05/15/157259/canonical-addresses-ubuntu-linux-snap-stores-security-failure
 * zyga reads 
<Chipaca> zyga: i think all the bits are in place, at least for bionic
<mup> PR snapd#5163 opened: tests: build spread in the autopkgtests with a more recent go <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5163>
<mvo> pedronis: ^- the above PR fixes autopkgtests with spread 1.6. we talked about it last week iirc that we need to do something about it
<mvo> pedronis: (just fyi)
<cachio_> zyga, #5151 ready
<mup> PR #5151: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
<zyga> cachio_: thank you
<zyga> looking
<cachio_> tx
<mup> PR snapd#4970 closed: Add SocketUser and SocketGroup options <Blocked> <Created by guilhem> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4970>
<zyga> cachio_: reviewed
<Chipaca> zyga: you requested changes on #4562, i think they're done, could you check?
<mup> PR #4562: debian: add a zenity|kdialog suggests <Reviewed> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4562>
<Chipaca> zyga: no, wait, i got that wrong, they're not done
<zyga> ack
<Chipaca> at all
<Chipaca> heh
<zyga> heh
<zyga> ok :)
<zyga> the packaging changes, right?
<Chipaca> zyga: yeah, i jumped to conclusions way too fast htere
<Chipaca> zyga: OTOH we could totally do it in separate PRs
<zyga> yes
<Chipaca> no reason to block the deb work just because the rpm work isn't done
<Chipaca> also this is _just_ for ubuntu, not even debian
<cachio_> zyga, tx
<Chipaca> otoÂ²h i'm not sure debian packaging uses this
<Chipaca> mwhudson tried to do work in this area but we kinda crapped out on him
<mup> PR snapd#4873 closed: many: delay classic registration until first store interaction <Blocked> <Squash-merge> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/4873>
<Chipaca> pedronis: ?
<jdstrand> niemeyer: hi! two things: 1) perhaps I should simply submit an exporatory PR for https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222 implementing what I think is best? this would help kjackal/tvansteenburgh with microk8s too
<jdstrand> niemeyer: 2) would you mind quickly looking at https://forum.snapcraft.io/t/classic-confinement-request-communitheme-set-default/5146/7 ?
<niemeyer> jdstrand: Looking at both
<pedronis> Chipaca: ?
<thresh> is there a way to tell snapd not to update snaps when using certain wireless nets?
<thresh> and/or when the connectivity is via wwan device
<niemeyer> jdstrand: Second one sounds like the anbox installer again
<diddledan> popey: is there a signal-desktop snap, and if there is who publishes it? there's an advisory about it so I wanted to make sure it's fixed... seclists.org/fulldisclosure/2018/May/39
<popey> me
<popey> i pushed a new version this morning
<diddledan> yey
<popey> :)
<popey> Thanks! :D
<diddledan> I thought it was but I'm on Windows right now so couldn't check
<jdstrand> niemeyer: yes but with very limited scope per didrocks
<cachio_> mvo, this is the issue I see in the pi3 https://paste.ubuntu.com/p/VCfTJVPNVr/
<jdstrand> niemeyer: so that make it harder (for me)
<niemeyer> jdstrand: I can't quite trace that line.. it's just a tool doing system manipulation on behalf of a third snap.. it's the sort of stuff we should be thinking about interfaces for
<cachio_> always trying to remofe test-snapd-servoce
<cachio_> mvo, it removes the snap but fails with timeout
<niemeyer> jdstrand: I've asked for some further info in the topic.. let's see if we can pinpoint what the need is and whether we might offer the real snap a proper interface to do that job
<cachio_> mvo, it failed in rgular and refresh scenarios for the pi3
<popey> diddledan: https://snapcraft.io/signal-desktop - click "Show versions" button :)
<jdstrand> niemeyer: it sounds like he wants to be able to modify the update-alternatives mechanism. This is a Debianism and I'm not sure what an interface for that would look like. I mean, I guess we could probe the system and expose the interface dynamically, similar to hotplug...
<jdstrand> niemeyer: asking in the forum sounds great
<jdstrand> niemeyer: thanks!
<niemeyer> jdstrand: Cool, let's follow up there so the discussion isn't lost
 * jdstrand nods
<diddledan> yikes, popey , you're right about gimp being popular!
<popey> ikr
<popey> :)
<diddledan> the adoption rate of 2.10 is impressive, too
<thresh> are there open stats on packages popularity?
<popey> no, but as diddledan is the uploader for gimp, he sees some stats
<popey> same as you see for vlc
<diddledan> is "active"
<diddledan> err, try again
<thresh> popey, sure that's why I asked :)
<popey> yeah, gimp has some way to catch up with vlc :D
<diddledan> is "active devices" the number that are actually launching the app, or just reporting metrics?
<popey> install base, we have no idea if people run it
<diddledan> gotcha
<niemeyer> jdstrand: Responded to the other issue
<zyga> jdstrand: hey
<zyga> jdstrand: do you have a moment
<jdstrand> zyga: if it is about the abd udev rules, I already commented
<mborzecki> thresh: https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001 is this what's you're looking for?
<zyga> jdstrand: it's about something else: https://github.com/snapcore/snapd/pull/5159
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> jdstrand: also an ack here https://github.com/snapcore/snapd/pull/5090
<jdstrand> zyga: what about it?
<mup> PR #5090: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/5090>
<zyga> I think this is doing what you asked for now
<jdstrand> I have both of these on my todo
<zyga> super
<zyga> I'll resume hacking then
<zyga> niemeyer: can you please look at https://github.com/snapcore/snapd/pull/4889 again
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> it should be ready now and needs your re-review
<niemeyer> zyga: Thanks for the fixed.. looking again
<niemeyer> fixes
<niemeyer> zyga: Can you clarify this point:
<niemeyer>  +	// Note that we allow /var/snap instead of /var/snap/$SNAP_NAME because
<niemeyer> zyga: What can write on /var/snap more specifically?
<zyga> the point is that if snaps foo and bar want to content share via $SNAP_COMMON (for example)
<zyga> then because we don't know the name of the "far side" of the connection here we cannot scope the permission to just /var/snap/foo and /var/snap/bar
<zyga> so we allow /var/snap
<zyga> so that content interface can create both /var/snap/foo/common/shared and /var/snap/bar/common/incoming (for example)
<mup> PR snapd#5164 opened: tests: increase timeouts to make tests reliable on slow boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5164>
<niemeyer> zyga: Where would those permissions end more specifically?
<zyga> niemeyer: can you rephrase, are you asking about how is this used by Secure.MkDir and all kinds of other helpers?
<zyga> those are telling snap-update-ns when to go ahead and write to the real filesystem and when to create a writable mimic and write to tmpfs instead
<niemeyer> zyga: Is that allowance just for the inner workings of snap-update-ns?
<zyga> yes
<niemeyer> zyga: Where do we block the remote snap from actually putting the layout on those places?  snpad?
<zyga> yes
<zyga> in snap/validate.go
<niemeyer> Ack, thanks
<mvo> cachio_: hm, hm, it looks like the timeout is a bit too tight, could you please set the kill-timeout to 6m and re-run the test?
<mvo> cachio_: and thanks for digging into this!
<cachio_> mvo, I created a pr to move it to 5
<cachio_> it is working fine with 5m
<cachio_> mvo, #5164
<mup> PR #5164: tests: increase timeouts to make tests reliable on slow boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5164>
<mvo> cachio_: \o/
<mvo> a second review for 5163 would be awesome
<mvo> this is important because our current SRU is blocked on failing autopkgtests
<cachio_> mvo, sure
<mup> PR snapd#5163 closed: tests: build spread in the autopkgtests with a more recent go <Critical> <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5163>
<niemeyer> zyga: Reviewed, asked some more questions
<zyga> ack, looking
<mvo> cachio_: do you think .8 is ready for candidate?
<mvo> cachio_: thanks for merging 5163
<cachio_> I am reviewing another teest and we need confirmation from cwayne
<cachio_> mvo, our part is ok
<mvo> cachio_: great, thank you
<cachio_> but still waiting to see if there is an issue on caracalla
<cwayne> cachio_: mvo said earlier he let you know we were ok to push
<mvo> ok
<mvo> cwayne: indeed, sorry I think I pasted wrong
<cachio_> cwayne, ah, ok, in this case I'll promote in few minutes
<cachio_> re-running a test in pi2
<cwayne> ah np sorry then, thought it was taken care of :)
<cprov> jdstrand: review pages should not timeout now, still slow, but at least you are not blocked.
<mup> PR snapd#4805 closed: daemon: add confinement-options to /v2/system-info <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4805>
<jdstrand> cprov: nice! that makes the full fix way less urgent (to me anyway)
<jdstrand> ratliff: fyi ^
<ratliff> jdstrand: great news, thanks cprov!
<cprov> jdstrand, ratliff: np, sorry for the trouble the queue has grown a bit :-/
 * cachio_ afk
<jdstrand> cprov: yeah-- we're trying to get people to look at the gadgets and kernels too
<Chipaca> ok, EOD for me
<Chipaca> o/
<mup> PR snapcraft#2138 closed: ci: resurrect codecov <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2138>
<mup> PR snapcraft#2139 opened: ci: remove unused cron tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2139>
<mup> PR snapd#5151 closed: tests: use journalctl cursors instead rotating logs <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5151>
<mup> PR snapd#5146 closed: tests: fix user mounts test for external systems <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5146>
<mup> PR snapd#5165 opened: tests: fix user mounts test for external systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5165>
<thresh> is there a way to fetch all possible version of a snap? e.g. revisions?
<noise][> thresh: as a publisher, you can get download links for all revisions from the snap revision pages on dashboard.snapcraft.io
<thresh> right.  what about other snaps?
<thresh> I'm mostly interested in trying out older core snaps
<noise][> generally not, you can access the revisions currently in the various channels
<thresh> I mean since some time ago I've started having issues with VLC on KDE, which I thought is due to my changes
<thresh> but apparently (trying out the stable which didnt have issues at the time) it's not me
<thresh> but something changed in snap/apparmor or something
<thresh> so I wanted to bisect a bit
<noise][> interesting, i'd suggest opening a topic on the forum - since it's the core snap you are after it shouldn't be a problem to help you get older revs
<noise][> the restriction is in place mainly to respect publisher wishes of "what should be available" for their snaps
<thresh> ah, undestandable
<noise][> thresh: i'm at end of day, but post a topic and we can get someone to help out with that
<noise][> you can @ me (noise on the forum)
<Pharaoh_Atem> niemeyer, it's happening: https://meetbot.fedoraproject.org/fedora-meeting-1/2018-05-15/serversig.2018-05-15-19.59.html
<niemeyer> \o/
<niemeyer> Pharaoh_Atem: Congratulations, and thank you!
<Pharaoh_Atem> niemeyer: this means we _gotta_ put some focus on getting things in place
<Pharaoh_Atem> the goal is to have all this ready by Fedora 29
<Pharaoh_Atem> zyga and I will probably submit an official self-contained change (https://fedoraproject.org/wiki/Changes/Policy) for this once we've determined the work needed
<niemeyer> Pharaoh_Atem: Sounds great, and that aligns well with the focus of snapcraft work that we are going to have this cycle
 * zyga mentioned that during the meeting
<niemeyer> By the end of the cycle we want to have a very smooth  multi-base experience
<mwhudson> a little bird tells me that snap info will start reporting the last update of a track/risk soon, is there some place i can track this?
#snappy 2018-05-16
<eraserpencil> I'm reading some articles on snappy, and read that it's not possible to update snaps that are not hosting on the snap store..
<eraserpencil> Is it a functionality I might be able to replicate if I hosted my own distribution network? currently, I'm manually copying snaps onto different machines and installing them but just thinking of how I might be able to update them
<mborzecki> morning
<mvo> hey mborzecki ! good morning
<mborzecki> hm 15 reviews/week, i have a feeling we'll not bring bring down the PR count to say 20 in a reasonable time :)
<mup> PR snapd#5166 opened: tests: go must be installed as a classic snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/5166>
<mvo> mborzecki: *cough* yeah, but hopefully we do better over the coming days
<mborzecki> mvo: #5156 can be merged now?
<mup> PR #5156: core-fixup: address review feedback from #5147 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5156>
<mvo> mborzecki: yes, done. thank you!
<mup> PR snapd#5156 closed: core-fixup: address review feedback from #5147 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5156>
<mup> PR snapd#5167 opened: tests: cherry-pick more GCE commits <Created by mvo5> <https://github.com/snapcore/snapd/pull/5167>
<mup> PR snapd#5166 closed: tests: go must be installed as a classic snap <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5166>
<mup> PR snapd#5160 closed: snapstate: make TestDoPrereqRetryWhenBaseInFlight less brittle <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5160>
<zyga> good morning
<mup> PR snapd#5061 closed: tests: ensure interfaces-network-bind daemon is stopped early <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5061>
<zyga> mvo: I will be off for 5 work days, starting tomorrow
<mup> PR snapd#4562 closed: debian: add a zenity|kdialog suggests <Reviewed> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4562>
<mvo> zyga: nice! will you go on vac?
<zyga> mvo: ish, yes, we need to go and wrap up some stuff in Catalonia
<zyga> mvo: but also some vac hopefully, a surprise birthday party for our close friend there
<zyga> (she doesn't know we're coming yet :)
<mvo> zyga: ha! nice
<zyga> I will take my laptop (obviously) so I can still help land stuff while nothing better to do around
<zyga> this reminds me, I need to find my Vodafone SIM and install it
 * zyga installed an air filter yesterday 
<zyga> and ... shockingly, it worsk
<mborzecki> air filter where?
<zyga> my desk was covered in dust every morning, driving me insane
<zyga> it's a pretty big box standing right next to me
<zyga> I moved my hand across the desk and keyboard this morning and it was clean as if wiped a moment ago
<mborzecki> ah, that dust, isn't that some pollen or the mythical sands from sahara dragged over europe?
<zyga> before it was always full of fine powdery dust
<zyga> well, whatever it is, the machine works :)
<mborzecki> make sure to clean the filter regularly, otherwise you may have a close encounter with fungi spores dispersed in the air
<zyga> mborzecki: yeah, I need to learn proper maintenance
<zyga> it has a nice phone app to measure stuff though, it will surely remind me of everything :)
<mborzecki> zyga: xiaomi?
<zyga> yes
<zyga> model 2
<zyga> it was 200zÅ off the normal price to celebrate a new store that opened in warsaw
<mup> PR snapd#5167 closed: tests: cherry-pick more GCE commits <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5167>
<mborzecki> aah yes, 'big event' :), well whatever people say, they have a better track updating their firmware than most vendors
<zyga> hehe, yes, it had a firmware update out of the box
<zyga> so far I'm happy, it is quiet on auto and seems to solve my biggest annoyance with home office,
<mborzecki> so morphis found some issues with egl support, i'm looking into that
<zyga> I saw
<zyga> it's interesting
<zyga> maybe run a strace -e open
<zyga> and see what else is opened by sample app
<zyga> then sort -u the paths
<zyga> there should be a handful of things really
<mborzecki> it should be easy to fix
<mborzecki> at least it's saner than what vulkan setup did
<mborzecki> (though the mechanism is similar)
<mborzecki> mvo: shall we do `xmessage -buttons Yes:0,No:1 -default Yes -nearmouse "shall we do xmessage?" -timeout 10` ?
<mvo> mborzecki: as a fallback if zenity or kdialog are not around? probably a good idea but its pretty hardcore
<mvo> mborzecki: I mean, Xaw
<mborzecki> haha yes
 * zyga requests a review for https://github.com/snapcore/snapd/pull/5159
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> it went through an iteration with chipaca already
<pstolowski> morning
<mborzecki> we seem to be globbing the right egl libraries already, so what's missing is the vedor files only
<mborzecki> i've built https://github.com/dv1/eglinfo and running some tests with it now
<zyga> mvo: do you plan any more 2.32.x?
<zyga> mborzecki: if so that would feel like an update to backport
<mborzecki> or .33 material
<zyga> 2.33 is not branched yet so it's full master
<mborzecki> zyga: have you made any attempts at building nvidia snap?
<zyga> mborzecki: no but after doing some research I would say we should split the responsibility of the snap
<zyga> mborzecki: it should be a snap that only handles non-kmod aspect
<zyga> so just userspace
<mborzecki> zyga: yes, that's what i understand as nvidia snap
<mborzecki> one for each driver version
<mborzecki> actually that might be a track
<zyga> mborzecki: yes, it should be a track
<zyga> well
<zyga> actually
<zyga> no
<zyga> what if you have >1 card?
<zyga> old and a new one
<zyga> is that even supported by the driver today/
<mup> PR snapd#5115 closed: interfaces: add xdg-document-portal support to desktop interface <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5115>
<zyga> mvo: #5032 looks like a low hanging fruit
<mup> PR #5032: repo: pass and return ConnRef via pointers <Simple> <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5032>
<mborzecki> zyga: each with different driver?
<mborzecki> zyga: i think both cards have to be supported by the same driver, i.e. 9600gt and gt1030 setup is a no go
<zyga> mborzecki: well, it depends on the actual support with the existing drivers
<zyga> if it's not supported at all then yeah, tracks are natural
<mborzecki> but gt730 and gt1030 is probably ok
<zyga> snapd could have a hardware manager that looks at your cards and refreshes the right snap/track
<mborzecki> yup
<mborzecki> we could pull in those snaps as dependencies (like with do with content now)
<zyga> yes
<zyga> the OpenGL interface could be extended to do that
<zyga> it would behave as a content interface to the special-cased nvidia snap
<zyga> all without any app changes that is :)
<pedronis> mvo: hi, this was the original  comment that prompted the expansion, no:Â  https://github.com/snapcore/snapd/pull/5124#discussion_r187167856
<mup> PR #5124: many: add wait command and seeded target <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5124>
<mborzecki> coffee and rhubarb pie :)
<zyga> pstolowski: some feedback on 4510
<newbee> In snapcraft how we clear the ppa:repository cache?
<pstolowski> zyga: thanks
 * zyga -> breakfast
<pedronis> zyga: pstolowski: I counter feedbacked
<pstolowski> yep, reading, thanks
<pedronis> pstolowski: I really don't see a reason to bring in the Mock* functions here
<mvo> pedronis: yeah, thats correct
<mvo> pedronis: sorry for the delay - I looked at the json package, the amount of  types is pretty small we need to support if we limit to it
<mvo> just FYI - I will do a 2.23.9 which *just* contains the spread fixes so that we get working autopkgtests agian on 16.04
<pedronis> mvo: I think we have 3 options:   the json types, the yaml types (to be a bit more future proof and consistent with other similar code), everything but then it belong to some util package as mborzecki said and we need to consider some other cases
<pstolowski> pedronis, zyga fair point about Mocks and just using Attrer interface, I'll change it, thanks!
<pedronis> mvo: btw  client uses   jsonutil.DecodeWithNumber
<mvo> pstolowski: is 5032 good to go?
<mvo> pedronis: yeah, I agree. I have not looked at the types that yaml uses yet, if we go with the option (2) I need to do that
<pedronis> mvo: so really only Number  can appear and  it's not documented in client  which probably should
<mvo> pedronis: what cases are missed for option(3) ? I know "nil" is missing right now, what else?
<pstolowski> pedronis: yes
<mvo> pedronis: yeah, I noticed we use json.Number, so I can remove "int" support too, right?
<pedronis> mvo: yes, but you should go over client and see where it's relevant,   it's likely only conf and debug stuff ?
<pedronis> and put in the docs
<mvo> pedronis: yeah, only conf even at this point (not even debug)
<pedronis> I actually expect that to bite us at some point, IÂ think the change was done indeed for conf stuff
<eraserpencil> hi
<mvo> pedronis: what in particular will bite us?
<pedronis> that we write some code that forgets about it
<pedronis> it's the only place we do that
<pedronis> afair
<mvo> pedronis: sorry, I'm a bit slow this morning: "forgets about it" - whats the "it" here?
<eraserpencil> hi
<pedronis> mvo: that decoding in client is using Number
<mvo> pedronis: aha, right. let me check the client, I know we do it in the daemon everywhere(ish?)
<pedronis> mvo: ?
<pedronis> I see only one call in non-test code to UseNumber
<pedronis> sorry
<mvo> pedronis: oh, let me check, sorry, then I must mis-remember
<pedronis> it's only all config code
<pedronis> that uses it
<pedronis> but in client is everything
<mvo> pedronis: do you think it would be a good time to change this in the client?
<pedronis> in which sense?
<mvo> pedronis: change the client code to not use numbers so that it won't bite us in the future
<pedronis> well,  we do it for good reasons for config
<pedronis> stuff
<mvo> pedronis: its for the float vs int which we normally won't have, right?
<pedronis> yes
<mvo> pedronis: ok, I'm inclined to go with removing the extra code and just deal with the types that json produces (in the spirit of YAGNI)
<pedronis> mvo: the only problematic place for Number is Attrs in interfaces.go
<pedronis> atm
<pedronis> having float64 for everything there is not good either though
<mvo> pedronis: indeed
<pedronis> but IÂ think at least doSync  document should mention the fact that it uses Number
<mvo> pedronis: I can add this
<pedronis> and the same in the documentation for Conf
<pedronis> mvo: ^
<mvo> pedronis: ta, I will push something new shortly
<pedronis> mvo: also I agree > 0  vs != 0  is a bit strange
<pedronis> that was zyga comment
<mup> PR snapd#5032 closed: repo: pass and return ConnRef via pointers <Simple> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5032>
<mvo> pedronis: PR updated
<mvo> yay, less than 40 PRs
<Chipaca> yay
<Chipaca> mvo: good morning
<mvo> Chipaca: good morning
<mup> PR snapd#5164 closed: tests: increase timeouts to make tests reliable on slow boards <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5164>
<mvo> pedronis: pr is updated (and addressed zyga comments as well, sorry for the confusing behavior there)
<zyga> thanks
<mvo> zyga: thank you, that was a nice catch
<zyga> mvo: one more nitpick
<mvo> zyga: sure, keep them coming
<pedronis> mvo: given the complexity you probably want a couple of end to end tests  about  1.1  0.0 0 and 1
<mvo> pedronis: yeah, that makes sense
<mborzecki> well egl is a bag of snakes apparently, i'm reading some presentation on egl external platform, afaict in the context of nvidia drivers it's only relevant for wayland now
<pedronis> I mean RedirectClientToTestServer tests
<mvo> pedronis: thanks, yes, that is what I understood :)
<mvo> pedronis: +1 for this, will do that in a wee bit (doing the 2.32.9 SRU to unblock autopkgtests again)
<mvo> pedronis: but once that is done I will add the tests and zyga nitpicks
<pedronis> mvo: indeed  snap interface  --attrs  (which I didn't know about) is probably broken because of Number
<zyga> oh?
<zyga> Number?
<zyga> there are tests for --attr so whatever it is, should be easy to check
<pedronis> they don't test the number case
<pedronis> just strings
<pedronis> anyway the impl is a bit naive anyway
<pedronis> but Number isn't helping it
<mup> PR snapd#5168 opened: release: 2.32.9 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5168>
<zyga> woah
<zyga> woah
<zyga> 9?
<pedronis> because of autopkgtests
<pedronis> mvo mentioned before here
<zyga> ah, a test-only release
<zyga> uff :)
<mvo> zyga: yeah, just tests, no further change
<pedronis> so the kind of bug I expected in future, is already in the present/past
<mvo> xnox: I get errors on s390x in cosmic in the snapd autopkgtests when trying to read /dev/kmsg - is that something new? afaict this test used to work. should we just blacklist it on s390x ?
<mvo> pedronis: I can have a look in a wee bit
<pedronis> not super important I suspect
<pedronis> less important than progressing with the review sprint
<pedronis> atm
<pedronis> the bug has been there since a long while
<mborzecki> zyga: it feels like we should have the opengl interface produce mount entries for vulkan and egl
<zyga> mborzecki, yes, can you expand on that idea, I'd like to do that and ditch the nvidia code in snap-confine
<zyga> we're now very much equipped to do that
<mborzecki> zyga: why exactly the nvidia setup is done in snap-confine now? or is it just historical?
<zyga> just historical
<zyga> snap-confine is far older than snap-update-ns and mount profiles
<zyga> it dates back to 15.04 and before
<mvo> the dawn of time!
<mborzecki> i was afraid of some pivot_root play or whatever but if it's historical then maybe we could dump/trim it now
<zyga> mborzecki: now that we have full access to hostfs all nvidia setup can easily be done after pivot_root in a mount profile
<mborzecki> yes, that's what i'm looking into now
<zyga> mborzecki: my suggestion: how to update existing namespaces (we cannot easily)
<mborzecki> we could pick out the libraries from the host, glob it nicely in go code
<zyga> mborzecki: write a function for what you just said above, that computes the mount profile for various use-cases of nvidia
<zyga> mborzecki: and add a mode in snap-confine where nvidia is managed by snapd
<zyga> mborzecki: (maybe via --managed-nvidia or something)
<mborzecki> if system-key changes, the mount profile will be regenerated too?
<zyga> mborzecki: so that we can opt in/out
<zyga> mborzecki: yes but existing mount namespaces cannot be updated
<zyga> mborzecki: on a system that does snapd update with running apps it would pose a problem
<mborzecki> ok, so PRIME (maybe) or old optimus then
<zyga> mborzecki: so what I'm saying, keep the old code for now for transition purpose
<zyga> mborzecki: but also keep in mind that we don't want to break apps on snapd update and that updating pre-pivot-root mount namespace is tricky
<zyga> mborzecki: so maybe don't try that, just wait for reboot or namespace invalidation
<zyga> mborzecki: it's an edge case that is better left as-is
<mborzecki> zyga: the upside is that if you install/enable the driver, you have to reboot/stop all apps anyway
<xnox> mvo, it should work.... the kernel between bionic & cosmic should be the same, and i better hope that /dev/kmsg works....
<xnox> mvo, if you don't have it blacklisted on other releases, there is nothign special about cosmic...
 * zyga asks for a review of #5159
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<mvo> xnox: ok, I will dig into it then
<mvo> xnox: thank you!
<sparkiegeek> hmm, after pulling in 2.32.8+18.04 on my bionic machine I'm left without a running snapd service
<sparkiegeek> https://paste.ubuntu.com/p/Vx8SK2xmDW/ <- socket was stopped and not restarted?
<sparkiegeek> dpkg.log https://paste.ubuntu.com/p/ZcwcH2pbtb/
<mvo> sparkiegeek: weeeh, but no install error or anything?
<sparkiegeek> mvo: nope
<mvo> sparkiegeek: from what version did you upgrade? /var/log/apt/history.log should tell you
<sparkiegeek> mvo: snapd:amd64 (2.32.5+18.04, 2.32.8+18.04)
<sparkiegeek> ahh Error: Sub-process /usr/bin/dpkg returned an error code (2)
<mvo> sparkiegeek: I just tested this on a spare bionic box and went from 2.32.6->.8 without this but that is quite scary
<mvo> sparkiegeek: puhh, at least an error - well, an error still sucks but the alternative would be worse
<sparkiegeek> mvo: so, I just `dpkg --configure -a`
<sparkiegeek> that seems to have unblocked it
<mvo> sparkiegeek: can you paste me the details of the error please? either from /var/log/apt/term.log or history.log (former probably has more info)
<mvo> sparkiegeek: was the dpkg error related to snapd? or an unrelated package?
<sparkiegeek> mvo: looks like dpkg lock issues, pasting
<mvo> sparkiegeek: if unrelated package thats "expected" (and one reason we like snaps), apt will just stop dpkg in this case and the daemons are usually stopped early
<mvo> sparkiegeek: thank you
<sparkiegeek> mvo: https://paste.ubuntu.com/p/GMshWgdrSh/
<sparkiegeek> note that this wasn't interactive
<mvo> sparkiegeek: this was unattended-upgrades?
<mvo> sparkiegeek: was there anything else running at the same time? packagekit or gnome-software or anything like this? or was this on a server
<mvo> sparkiegeek: its not (strictly speaking) my turf but I don't like this :/
<sparkiegeek> mvo: yeah, I think it might have been landscape...
<mvo> sparkiegeek: so any extra info about the system is appreciated
<mvo> sparkiegeek: aha, interessting
<sparkiegeek> (now snapd is running, using my browser becomes easier!)
<pstolowski> zyga: pedronis addressed your feedback re 4510
<zyga> ack
<mvo> pedronis: I added the integration test you asked about in 5157
<eraserpencil> is making a gadget snap the only way to apply udev rules to a device?
<Lin-Buo-Ren> https://github.com/ubuntu/snapcraft-desktop-helpers/issues/117
<zyga> Lin-Buo-Ren: what changed in the before/after?
<zyga> eraserpencil: one more way is to add an interface
<eraserpencil> zyga: like exposing a serial port or usb port
<zyga> eraserpencil: usb port?
<zyga> those don't need to be exposed, what is the rule you are after?
<mup> PR snapd#5169 opened: snap: fix `snap interface --attrs` output when numbers are used <Created by mvo5> <https://github.com/snapcore/snapd/pull/5169>
<eraserpencil> assigning usb ports to usb devices if/when plugged in
<mup> PR snapd#5168 closed: release: 2.32.9 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5168>
<eraserpencil> zyga: actually, I'm more interested in exposing the serial port, which i read needs a gadget port
<zyga> eraserpencil: yes, that's correct
<zyga> you need a gadget for that
<Chipaca> mvo: want to link the "boot modes" doc from https://forum.snapcraft.io/t/documentation-outline/3781 ?
<Chipaca> mvo: building the case for a 'devices' heading in there soon :-)
<pedronis> that was what was about to say, there is no core specific content there yet
<Chipaca> pedronis: âEnabling swap on core devicesâ is on there
<pedronis> in the wrong section
<Chipaca> pedronis: how do you figure
<Chipaca> pedronis: it's not "developing", and it's not "publishing"
<zyga> I think device makers need a dedicated section
<Chipaca> pedronis: of the sections there are, it's under the right one
<zyga> that's neither developing nor publishing
<pedronis> Chipaca: I don't know
<Chipaca> I agree, but it's not going to happen unless we write  things for devices
<Chipaca> thus, my prompting mvo to link to the thing he wrote
<Chipaca> with two device-specific entries, we could think of a section for them
<Chipaca> although "Devicing" is not a word
<Chipaca> :-)
<mvo> Chipaca: hm, yes. linking makes sense
<mvo> Chipaca: I added it under "Using" for now but I think we need niemeyer to discuss where to put ubuntu core specific bits, the current naming makes it a bit hard and I don't want to add somehting that is totally out of line
<pstolowski> there was a failure in master on snap-confine-from-core test: https://api.travis-ci.org/v3/job/379596518/log.txt ; it seems we didn't match on "restarting into" in the journal
<zyga> -- Logs begin at Wed 2018-05-16 08:21:06 UTC, end at Wed 2018-05-16 08:29:15 UTC. --
<zyga> May 16 08:29:04 may160809-192333 kernel: audit: type=1400 audit(1526459344.395:475): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="snap.test-snapd-tools.head" pid=21848 comm="apparmor_parser"
<zyga> this is the head of the log
<zyga> it feels to me like it is too late
<zyga> the cursor logic may be inaccurate?
<pstolowski> I think the cursor changes landed quite some time ago? or is it a recent change?
<zyga> recent
<pstolowski> ok
<newbee> please guide us how to add external jar in snapcraft.ymal file. for example to access postgres database i need postgres.jar in my project lib path, i want to add like that in my snap
<pstolowski> newbee: you need to add it as a part in your parts: section to have it bundled somewhere in the snap; then you will most likely want a wrapper shell script for your app that sets CLASSPATH properly
<newbee> @pstolowski, ok, and just clarify us, in which part have to that, any example for this plese
<sparkiegeek> mvo: just for completeness, my issue seems to have been a bad interaction between unattended upgrades and landscape, which I'm pursuing with the Landscape team
<mvo> sparkiegeek: I suspect the underlying issue is that apt needs a more global lock. right now it is using the dpkg lock but there is a race because apt needs to release that in order to let dpkg do the work. so a higher level /var/lib/apt/lock would be in order that everything libapt respects. this can then be kept being locked even when the lower-level dpkg lock is released
<zyga> mvo: thank you for the review on #5159, replied
<mvo> zyga: ta
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> mvo: as for Call and RCall, maybe we should call the function RECall
<zyga>  as or just Recall
<zyga> it would play nice on the Result, Error and Call
<zyga> and it is also a word
<zyga> recall what happened
<zyga> hmm?
<mvo> zyga: no strong opinion about this
<mvo> zyga: I was mostly curious if its something I should know
<sparkiegeek> mvo: ack, waveform has found some /interesting/ lock behaviour in unattended-upgrades too
<pstolowski> newbee: see the advanced examples here https://docs.snapcraft.io/build-snaps/parts
<waveform> mvo, I'm probably making a mistake but looking through unattended-upgrades, the Unlocked context manager looks ... unusual
<mvo> sparkiegeek: it will unlock the dpkg lock quite often as it runs many dpkg operations (it defaults to minimal upgrade mode nowdays)
<waveform> it's called apt_pkg.pkgsystem_unlock on both __enter__ *and* __exit__
<mvo> waveform: oh? let me see
<waveform> (and it wraps both calls in bare try..except so a double-unlock will go unnoticed)
<pstolowski> newbee: one of your parts will be the jar file, and you will probably want to use dump plugin to have it copied into a specific place in the resulting snap; see https://docs.snapcraft.io/reference/plugins/dump
<mup> PR snapd#5170 opened: interfaces/builtin: add adb-support interface <Created by zyga> <https://github.com/snapcore/snapd/pull/5170>
<mvo> waveform: yeah, that looks very broken
<waveform> as far as I can tell Unlocked is only used by cache_commit, which is only used by do_install and do_auto_remove
<waveform> so I don't *think* this would get called by a default config (which might explain why it's not been seen yet?)
<waveform> still, it looked rather weird to me!
<mvo> waveform: very sure this is a bug
<waveform> ok, thanks - glad I'm not missing something!
<mvo> waveform: I will propose a fix and followup with foundations about it
<waveform> ta
<mvo> waveform: thank *you*
<waveform> mvo, incidentally ... I couldn't figure out where the pkgsystem lock gets removed; main sets it (with pkgsystem_lock) but the only place pkgsystem_unlock is called (I think?) is in Unlocked which isn't *necessarily* called by main ...
<waveform> ... so I'm not sure if something higher level is dealing with that lock later, or if there's some logic for breaking stale locks somewhere ... either way, that was another bit that felt rather odd to me
<mvo> waveform: when u-u exists the lock is automatically freeed but it holds it for its entire lifetime
<waveform> ah, that explains it
<pstolowski> zyga: replied to your comments on 4510
<mborzecki> zyga: land #5159 ?
<mup> PR #5159: testutil: record system call errors / return values <Created by zyga> <https://github.com/snapcore/snapd/pull/5159>
<zyga> pstolowski: +1
<zyga> mborzecki: yes please
<zyga> mborzecki: I will do follow ups that adjust things to move to RCall
<pstolowski> zyga: ty!
<mup> PR snapd#4510 closed: asserts: use Attrer in policy checks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4510>
<mup> PR snapd#5159 closed: testutil: record system call errors / return values <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5159>
<pstolowski> yay, more PRs landing today
<mvo> waveform, sparkiegeek thanks again for the report!
<waveform> np
<zyga> mborzecki: about our earlier discussion
<zyga> https://github.com/snapcore/snapd/pull/4889#discussion_r188582792
<mup> PR #4889: cmd/snap-update-ns: don't trespass on host filesystem <Created by zyga> <https://github.com/snapcore/snapd/pull/4889>
<zyga> this made my day :-(
<zyga> :-)
<mborzecki> hm you mean x-snapd.role? is it always stored?
<zyga> mborzecki: we can tag our mounts
<zyga> read the man page
<zyga> look for X. and x.
<mborzecki> yeah, it's hairy, libmount tools etc
<zyga> libmount is not the key, the key is that the kernel stores this
<mborzecki> zyga: are you sure? just tried something, mount shows the options, /proc/$$/mount{s,info} does not
<pedronis> the man page lists places is not stored, not where it is
<pedronis> a bit unclear
<pedronis> is says it doesn't go to mount(2) though
<mborzecki> wonder where it keeps it though
<zyga> hmmm
<zyga> yes, I agree
<mborzecki> wouldn't be surprised if there's some shm just to store this
<zyga> it is /run/mount/utab
<pedronis> searching for that gives references to this:  https://mirrors.edge.kernel.org/pub/linux/utils/util-linux/v2.23/libmount-docs/libmount-Tables-update.html
<zyga> this is certainly something to consider
<pedronis> we can always list the mimic paths in some /run file of our  own?
<zyga> yes, that's another option
<zyga> though I think using the same file would have some advantages, e.g. mount would print that
 * zyga dog walk & lunch
<pedronis> zyga: does it?  IÂ don't see it listing in xenial
<zyga> I checked artful
<pedronis> in xenial that command line (in the PR) doesn't file but mount doesn't list anything
<pedronis> and utab is there but empty
<pedronis> s/file/fail/
<pedronis> unless I'm missing something
<mborzecki> too old util-linux?
<Lin-Buo-Ren> zyga: The default font used to render the characters
<zyga> So the snap has changed?
<zyga> Was the application snap the same or was it rebuilt?
<pedronis> mvo: what is stopping #5095 from being merged?
<mup> PR #5095: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <https://github.com/snapcore/snapd/pull/5095>
<ads20000> https://forum.snapcraft.io/t/support-for-appstream-id/2327/19 there's been nothing posted in here since February and is apparently a blocker for deduplicating Software listings, I don't normally like asking for progress but it's unclear to a non-technical user how finished this is? :)
 * cachio_ afk
<pedronis> mborzecki: don't know, but we need something that works also in xenial and trusty(?)
 * zyga waits for police to get a drunken guy off school yard
<zyga> Also, it started raining now
<pstolowski> zyga: land #4968?
<mup> PR #4968: ifacemgr: remove stale connections on startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<zyga> In the rain, returning home
<zyga> But yes
<zyga> Please
<pstolowski> thx
<mup> PR snapd#4968 closed: ifacemgr: remove stale connections on startup <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4968>
<zyga> re, food and back to PRs
<mup> PR snapd#5095 closed: snapstate: support getting new bases/default-providers on refresh <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5095>
<Lin-Buo-Ren> zyga: The snap is rebuilt with snapcraft.yaml constantly changing, so I can't tell
<Lin-Buo-Ren> I'm trying to rebuild the snap with old revision of desktop-helpers to see the issue can still be reproduced
<zyga> can you install the old revision? are you the developer of that snap?
<Lin-Buo-Ren> @zyga I don't keep the old builds but can rebuild them if needed; I'm working with upstream with the snap packaging
<zyga> Lin-Buo-Ren: if you are the developer of that snap (you can publish releases) then you can also install any old revision
<zyga> just snap install -r
<zyga> see if current snapd makes old revisions work correctly
<zyga> if this is an issue with snapd or with the desktop helpers
<niemeyer> ads20000: There's just one piece missing which is the integration on snapd proper.. that's scheduled for this cycle
<Lin-Buo-Ren> zyga: I just successfully pushed a few releases on the store, I'll check it out
<niemeyer> ads20000: Updated the topic
<ads20000> thank you niemeyer for the update! <3
<niemeyer> ads20000: np
<mborzecki> hmm gnome session got killed again
<zyga> mborzecki: what happens?
<mborzecki> again when snaps were being installed
<popey> mborzecki: is that when installing a snap? I find it happens when the opengl interface is connecting
<popey> you on nvidia?
<thresh> meh, fonts are invisible again
<mborzecki> zyga: http://paste.ubuntu.com/p/w42w3SW4RG/
<pstolowski> snapc-confine-core failed again in master; there is also test-snapd-python-webserver.test-snapd-python-webserver[21122]: ImportError: No module named 'contextlib' there
<thresh> snap-ns-disccard thingie worked though, but I didnt use nvidia bumblebee/prime or whatever that is
<mborzecki> it's like Xorg was gone
<mborzecki> popey: yes, on nvidia
<popey> same as me, xorg goes bang
<niemeyer> That sounds pretty bad.. :/
<niemeyer> mborzecki: Please let us know what you find there
<niemeyer> I won't be in the standup today as we have a conflicting meeting, and also have one right after it so we can't even reschedule
<mvo> zyga, pstolowski I have a conflicting
<mvo> meeting
<zyga> ack
<popey> niemeyer: mborzecki https://bugs.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/1760104
<pstolowski> k
<niemeyer> popey: Can't see it
<mborzecki> popey: me neither
<mvo> and niemeyer also has the same conflicting meeting now
<popey> made it public
<popey> I have had this about 4 or 5 times now
<popey> kinda annoying to have your entire session blown away when doing "snap install"
<zyga> popey: we are discussing this in the standup now
<popey> thanks
<Son_Goku> popey, with nvidia and ogl, snaps cause the system to flicker every minute :/
<Son_Goku> that happens on Fedora
<popey> ooer, not seen that
<Son_Goku> it doesn't cause gnome session to crash, but I almost would have preferred that
<popey> hah!
<Son_Goku> though I suspect it _would_ crash if I was using xorg
<mborzecki> Son_Goku: system to flicker, can you elaborate?
<popey> maybe get a video with a cell phone?
<Son_Goku> mborzecki, display session looks like it's constantly refreshing slowly
<Son_Goku> this is with free drivers, since my card is old enough
<Son_Goku> I suspect it'd crash on f28 + nvidia + proprietary
<Son_Goku> snapd 2.32.4
<zyga> .4 oh gosh
<zyga> we are at .8
<zyga> ;-)
<Son_Goku> dude, I haven't had any time
<mvo> we are at .9 ;)
<Son_Goku> oh god
<Son_Goku> zyga, mvo: the next time I update snapd will be the last one for Fedora 26
<mborzecki> zyga: yeah, it seems that udev rules are reloaded
<mborzecki> udevadm monitor is showing a change for each device
<zyga> Son_Goku: that's fine
<zyga> we are looking at F29 :)
<Son_Goku> zyga, you got the list from me on the stuff we need to touch, right?
<zyga> yes
<zyga> I was wondering how to start
<zyga> shall we merge your code somewhere?
<mborzecki> hahaha now my sound is gone
<mborzecki> pcspkr works though
<Son_Goku> zyga, well, my code is pretty much PoC
<Son_Goku> to integrate into oz, koji, and pungi will require different code
<zyga> Son_Goku: which tool shall we start with? koji?
<Son_Goku> oz
<Son_Goku> it's the thing that actually makes the stuff
<zyga> ah
<zyga> ok
<zyga> is it easy to run?
 * Son_Goku shrugs
<Son_Goku> looks like it
<Son_Goku> https://github.com/redhat-imaging/imagefactory
<b_b> hi
<b_b> can anyone point me on a basic snap question ?
<b_b> i'm trying to snap a python app
<b_b> http://thetimelineproj.sourceforge.net/about.html this one
<b_b> for now i've got this yaml file
<b_b> http://pastebin.fr/53663
<b_b> and the app need python-wxgtk2.8 ubuntu package
<b_b> i'm not sure how to write this dependencie
<b_b> with a stage-packages ?
<popey> yes
<popey> stage-packages:
<popey>   - python-wxgtk2.8
<b_b> http://pastebin.fr/53664 like this ?
<b_b> thx popey :)
<b_b> so, i can try to prime it now
<popey> yeah, like that
<b_b> i was missing a space
<b_b> hmm prime wants to install libpython3-dev libpython3.5-dev python3-dev etc.
<b_b> ever if i add python-version: python2
<popey> did you add that to both parts?
<b_b> 'k, got to add it to the two parts ^^
<b_b> nice
<b_b> Failed to stage: Parts 'timeline' and 'humblewx' have the following files, but with different contents:
<b_b> usr/lib/python2.7/UserString.py
<b_b> etc.
<b_b> http://pastebin.fr/53665
<b_b> for info, the provided zip for timeline doesn't need a build
<b_b> cf http://thetimelineproj.sourceforge.net/installing.html#installing-from-source
<b_b> 'k, it seems i have to stage all thath files
<b_b> hmmm timeline seems to be a "prebuilt app", so dump plugin will do the trick
<b_b> same error with this yaml  http://pastebin.fr/53666
<b_b> anyone know a working snap of this type of app that can provide me an exemple ?
<popey> might have more success on the forum
<b_b> 'k
<mup> PR snapd#5171 opened: ifacestate: unify reconnect and autoconnect methods <Simple> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5171>
<b_b> got it with http://pastebin.fr/53667
<pstolowski> cachio_: you asked about faillog for journalctl issue? https://api.travis-ci.org/v3/job/379684074/log.txt
<mup> PR snapcraft#2139 closed: ci: remove unused cron tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2139>
<mup> PR snapd#5090 closed: cmd/snap-update-ns: poke holes when creating source paths for layouts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5090>
<cachio_> pstolowski|afk, tx
<chzbacon> hey guys, i'm having a time trying to get logged into a fresh install of core on a raspberry pi 3. might anyone be able to lend a hand?
<chzbacon> can i not connect locally? ie chzbacon@192.168.1.xx ?
<popey> once it's setup, you can.
<popey> to do the setup you need to either connect a serial cable or keyboard/display
<chzbacon> i'm trying to login from another local machine on the network (which i've uploaded the public key for). I still get prompted for a password though.
<popey> have you been through the first run setup?
<chzbacon> yeah i set it up last night using a kb and monitor
<chzbacon> yup
<popey> are you specifying the right username as well as the ip?
<chzbacon> i didn't see any prompt for a password though. i think so. chzbacon@gmail.com
<popey> no, it uses ssh key not password
<chzbacon> that's what i thought. i've tried both a key with a passphrase and without.
<chzbacon> i'll just go back through the steps once i get home. maybe i messed something up.
<b_b> so my latester attempt works fine with prime
<b_b> http://pastebin.fr/53667
<b_b> now i need to copye the content of the zip somewhere in order to get this working
<b_b> since there is no setup.py in the zip
<b_b> anyone have a clue to do that ?
<b_b> https://docs.snapcraft.io/build-snaps/syntax#stage is maybe what i'm searching for ?
<b_b> or maybe https://docs.snapcraft.io/build-snaps/syntax#prime
<jdstrand> niemeyer: fyi, I didn't mention you in the response so you may not have seen it, but I responded in https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/8
<niemeyer> jdstrand: Thanks, replied there
 * cachio_ afk
<b_b> my last attempt work fine until i try to lauch timeline command
<b_b> http://pastebin.fr/53670
<skomorokh> Is a "classic" confinement snap just classic in the sense that it runs unconfined as the user when they load the app or does it also let the package maintainer run scripts as root like a .deb or similar?
<b_b> enough for this day :p
<b_b> ++
<cachio_> e
<jdstrand> kjackal: hey, fyi, https://forum.snapcraft.io/t/htop-snap-unable-to-signal-aa-enforced-processes/5222/9
<jdstrand> kjackal: it doesn't completely solve the microk8s problem, but does mean that the docker snap could be modified to have a 'signal (receive) peer=snap.*,' rule in its default container policy. with that, microk8s could 'plugs: [ process-control ]' and send signals to the docker snap's containers
<jdstrand> kjackal: there are other options once you've decided what docker to use
<jdstrand> kjackal: honestly, I still think that shipping your own docker is going to be the most robust snap implementation (since you don't have to worry about docker changing incompatibly from under you, and you can adjust its policies, etc)
<jdstrand> kjackal: we can chat later at your convenience
#snappy 2018-05-17
<mborzecki> morning
<newbee> Any one tell us, why the "snapcraft pull" command always create "default-jdk and java-open-Jdk" in the "parts/local/install" directory, and also guide us to use oracle-jdk.
<newbee> I have a maven project which has source and target versions as JDK 1.8. And I wanted to build a snap app for the same project. As per the doc it looks like snapcraft "will pull a relocatable OpenJDK via the default-jdk Ubuntu package" and since, my project relies on 1.8 building the app fails. Is there a provision through which I can build the project?
<mborzecki> mvo: morning
<mborzecki> mvo: i was experimenting with udev a bit yesterday, just to simulate us dropping new rules file to /etc/udev/rules.d
<mborzecki> when udev reloads the rules and tirggers events, there's a chance bad things will happen
<zyga> Good morning
<zyga> mborzecki: chance as in randomly?
<mborzecki> zyga: yeah, looks like so
<zyga> I wonder if we could run just a fragment of udev rules somehow
<mborzecki> loosing sound, pulseuadio killed, libinput going crazy, disks spinning up
<mborzecki> libinput thing is most annyoing, all the key repeat settings are gone now and cannot restore them, would probably have to restart the session
<mborzecki> (xorg shutting down is probably more annyoing, but so far it didn't happen again)
<mvo> hey mborzecki! good morning
<mvo> mborzecki: uh, that sounds nasty
<mvo> mborzecki: any idea what we can do about it?
<mborzecki> not yet, need to do some digging still
<mvo> ta
<pstolowski> heyas!
<mvo> hey pstolowski
<gohan> I have a maven project which has source and target versions as JDK 1.8. And I wanted to build a snap app for the same project. As per the doc it looks like snapcraft "will pull a relocatable OpenJDK via the default-jdk Ubuntu package" and since, my project relies on 1.8 building the app fails. Is there a provision through which I can build the project?
<mup> PR snapd#5172 opened: cmd/snap-confine, interfaces/opengl: allow access to glvnd EGL vendor files <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5172>
<kjackal> jdstrand: thank you for th update. Yes lets have a quick chat about this. I also think we will have to ship our own docker build (as we will do for etcd if we want to support other architectures).
<b_b> hi
<pstolowski> mvo commnted on your json.Number PR
<mvo> pstolowski: thank you!
<mvo> pstolowski: yeah, this is what I remembered as well. probably a good idea to talk during the standup about the concerns from samuele (aiui we don't use it consistently enough?)
<pstolowski> mvo: it's possible i missed something as your PR shows...
<pstolowski> mvo: just mentioning all this in case we want to re-consider the approach; we need to remember of the original bug that triggered the introducion of json.Number, although hopefully the tests should be good enough to prevent a regression
<mvo> pstolowski: yeah, I don't want to go back, just wanted to explore options
<mvo> pstolowski: i.e. if there is a strong opinion that we should do something else my PR would be a bit pointless :)
<mvo> (but I think there is no such consensus yet)
<pedronis> mvo: pstolowski: as I said we don't have a strong case to do something else atm, otoh IÂ think we discovered there are some people using client as a library, they might be surprised by Number but who knows,  ... it seems something to reconsider if somebody files a bug or when we introduce config schemas
<pedronis> mvo: btw, IÂ will not be at standup today,  I have another meeting  (not a recurring one though)
<mvo> pedronis: +1 - its a good point that it will be surprising for some people
<mvo> pedronis: meeting> thanks, no worries
<pstolowski> i see
<mvo> niemeyer: could you please add sil2100 to the standup for the time being? not sure if he should attend every day but he will work with us on core18
<pedronis> mvo: pstolowski: at least in mvo's PR  the use is documented for Conf
<pedronis> now
<pedronis> the only other issue is Attrs in interfaces but not sure is super used
<pedronis> mvo: IÂ marked #4497 as something you should look at,  it also need a 2nd Gustavo's review
<mup> PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<pedronis> pstolowski: btw if you did a review of #5169 we could land it
<mup> PR #5169: snap: fix `snap interface --attrs` output when numbers are used <Created by mvo5> <https://github.com/snapcore/snapd/pull/5169>
<pedronis> our little hill of PRs seems hard to flatten
<pstolowski> yes, merged
<mup> PR snapd#5169 closed: snap: fix `snap interface --attrs` output when numbers are used <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/5169>
<Chipaca> o/
<pedronis> pstolowski: thx
<pedronis> Chipaca: hi
<Chipaca> pedronis: how's things?
<pedronis> good-ish
<mborzecki> need to go out for a while, bb in 1-2h
<Chipaca> pedronis: am I right in reading that we drop changes after just 1 day?
<Chipaca> i thought it was longer than that
<pedronis> Chipaca: ready changes, yes
<Chipaca> pedronis: context of my question was https://askubuntu.com/a/1037304/711
<pedronis> mvo: I think 5157 and 5158 just needs to get green?   there's a couple of PRs marked for you to review
<pedronis> zyga: are you working on  #5081 ?
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<pedronis> is there somebody with a PR that needs a review from me? most seems to need Gustavo's input or j-dstrand or rework or are close to merging
<zyga> pedronis: Yes though a bit on the back of the queue
<zyga> And on holidays today
<pedronis> ah
<zyga> I will apply feedback in the evening
<pedronis> sorry
<zyga> No worries :-)
<kjackal> hi all, when building with snapcraft cleanbuild the lxc ubuntu image is a xenial one? or is it whatever the host system is?
<popey> xenial
<kjackal> thanks popey
<popey> np
<mborzecki> mvo: shall we land #5158?
<mup> PR #5158: boot,partition: improve tests/docs around SetNextBoot() <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5158>
<pedronis> mborzecki: it looked ok tome
<pedronis> *to me
<mup> PR snapd#5157 closed: many: improve `snap wait` command <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5157>
<mup> PR snapd#5158 closed: boot,partition: improve tests/docs around SetNextBoot() <Simple> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5158>
<mvo> pedronis: thanks, I get to the reviews now
<mup> PR snapd#5077 closed: overlord/snapstate,overlord/auth,store: coalesce no auth user refresh requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5077>
<b_b> 'k finally got a working snap of timeline
<b_b> https://gist.github.com/brunob/1155589f66171992c8661dd8a51d8555
<b_b> have to use this trick https://forum.snapcraft.io/t/add-external-resources-into-final-snap/990/2
<b_b> since the zip of the app doesn't provide a setup.py file
<b_b> i was hoping to get it working with a dump of the zip downloaded, but no luck
<b_b> cf https://gist.github.com/brunob/1155589f66171992c8661dd8a51d8555/ad3e38dd591969211daf59404c6b3e60495d069e
<b_b> if anybody have advices or recommandations on this i'll be glad
<Chipaca> b_b: my advice would be to ask in forum.snapcraft.io
<b_b> 'k, thx Chipaca
<mup> PR snapd#5165 closed: tests: fix user mounts test for external systems <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5165>
<mvo> mwhudson: hey, do you build the go snap for ppc64el ? and if not, would it be possible to enable it there? we use it now as part of our autopkgtest suite
<mwhudson> mvo: i do
<mvo> mwhudson: hm, I get a "funny" error there https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/ppc64el/s/snapd/20180516_134211_9b965@/log.gz
<mvo> mwhudson: "/snap/go/1877/gowrapper: line 3: /snap/go/1877/bin/go: No such file or directory"
<popey> diddledan: have you seen "IsADirectoryError" on corebird before?
<popey> diddledan: https://launchpadlibrarian.net/370632559/buildlog_snap_ubuntu_xenial_amd64_c0aad5cf3f1a1163b9cfe834a79080dc-xenial_BUILDING.txt.gz
<popey> "IsADirectoryError: [Errno 21] Is a directory: '/build/corebird/stage/usr/share/locale'"
<b_b> "sorry, new users can posts 2 links only"
<b_b> nice...
<thresh> yeah the forum is a weird thing
<popey> it's anti-spam protection
<b_b> https://forum.snapcraft.io/t/snapcraft-a-prebuilt-python-app-no-setup-py-file/5482
<thresh> is it needed if all the links are nofollow? (are they?)
<popey> just break the url, and post to the forum, give me the link and I'll fix it
<b_b> done
<popey> hah, it thinks setup.py is a url :)
<mvo> mwhudson: I think I know what is going on /lib64/ldso is not a relative link
<mvo> mwhudson: I can fix that in core
<mwhudson> mvo: uhh there were snapcraft bugs in this area but they got fixed i thought...
 * mwhudson is not really here btw
<mvo> mwhudson: thank you and sorry for the noise, I think I know what to do do fix this
<mwhudson> mvo: ok :)
<mup> Bug #1771793 opened: Interface for hardware temperature monitoring <Snappy:New> <https://launchpad.net/bugs/1771793>
<mborzecki> re
<mup> PR core#88 opened: hooks: make /lib64/ld64.so.2 relative to unbreak classic snaps on ppc64el <Created by mvo5> <https://github.com/snapcore/core/pull/88>
<b_b> the problem was with the 3rd url popey : https://forum.snapcraft.io/t/add-external-resources-into-final-snap/990
<b_b> so i broke it
<Chipaca> popey: b_b: backtick-quote things that it thinks are urls, fwiw
<sitter> there is something seriously wrong with Qt 5.10 compatibility due to the newer/different syscalls it uses compared to earlier versions. e.g. `snap install --candidate kde-frameworks-5 && snap install okular && snap run okular` lots of write errors by snapd apparently denying linkat syscalls which are used inside qtemporaryfile which in turn is used for just about config file writing business (e.g. https://github.com/qt/qtbase/blob/
<sitter> fe5edcee602f0ab2912bbdd1a21f4309ed7dbfd6/src/corelib/io/qtemporaryfile.cpp#L466 ) I think this ultimately is also the problem here https://forum.snapcraft.io/t/qt5-kde-integration-in-vlc-snap-is-broken/5465
<sitter> seems fairly major, but I really don't know what to do with this :S
<sitter> well, when I say fairly I actually mean: this is preventing any and all KDE snap builds moving forward
<Chipaca> sitter: raising the issue in a forum topic, with a sampling of the denies, would be a good step towards fixing it
<Chipaca> sitter: we've historically been rather good at fixing these
<eraserpencil> is it possible to have run snapcraft across several cores?
<Chipaca> I'll tag jdstrand on that vlc+qt5 one
<Chipaca> eraserpencil: by cores, you mean cpus?
<Chipaca> eraserpencil: (cores is a rather loaded term...)
<mborzecki> same as 'classic' for that matter
<eraserpencil> Chipaca: I guess cores, or threads. Not sure of the accurate term.
<mborzecki> eraserpencil: are you doing container builds?
<eraserpencil> I thought CPU was the actual physical processor
<eraserpencil> nope
<Chipaca> eraserpencil: snapcraft itself shouldn't be cpu-bound, and you should be able to pass any arguments the things inside it need to run in parallel
<mborzecki> eraserpencil: make -j and so on
<Chipaca> yeah
<eraserpencil> ahh kk
<eraserpencil> i'll give it a try
<eraserpencil> sorry, I might need a more detailed hot-to
<eraserpencil> how-to*
<sitter> https://forum.snapcraft.io/t/qt-5-10-linkat-denials-broken-kde-snaps/5484 about the qt 5.10 issue
<Chipaca> sitter: thanks
<b_b> trying to get a minimal gtk theme for my app now
<b_b> should i use https://github.com/snapcrafters/gtk-common-themes ?
<b_b> or use stage-packages like here https://gitlab.gnome.org/Community/Ubuntu/gnome-software/blob/35d29d0b6188c6b1d60644af30d18f91e773eda2/snap/snapcraft.yaml#L163
<jdstrand> Chipaca: I was already planning on looking at that
<pedronis> jdstrand: hi
<mvo> a review for https://github.com/snapcore/core/pull/88 (trivial) would be great
<mup> PR core#88: hooks: make /lib64/ld64.so.2 relative to unbreak classic snaps on ppc64el <Created by mvo5> <https://github.com/snapcore/core/pull/88>
<mborzecki> mvo: why does it break with an aboslute path in the symlink?
<mvo> mborzecki: the go snap sets the elf interpreter to /snap/core/current/lib/ld64.so.2
<mvo> mborzecki: but that links to a libc6 that is not necessarily available on the system
<mvo> mborzecki: eh, to an ld.so
<ogra_> jdstrand, geez ... stop fixin security holes ... i only updated my packageproxy snap on the weekend for new curl :P
<mup> PR core#88 closed: hooks: make /lib64/ld64.so.2 relative to unbreak classic snaps on ppc64el <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/88>
<mup> PR snapd#5171 closed: ifacestate: unify reconnect and autoconnect methods <Simple> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5171>
<jdstrand> ogra_: it isn't me, it our awesome security team :)
<jdstrand> cc ratliff ^ :)
<ogra_> :D
<jdstrand> it is pretty cool seeing those go out :)
<jdstrand> pedronis: hey :)
<ogra_> yeah, totally !
<jdstrand> I set up all my little snaps with LP builds so I could get those :)
<mborzecki> heh udev reload && trigger makes x session cry
<ogra_> mborzecki, yeah, dont do that ... you can limit trigger to certain subsystems
<ogra_> (forgot what the option ws called ...)
<mborzecki> ogra_: snapd does it currently when a snap is installed and it comes with some udev rules, it's control -R && trigger, i suspect it's when the x session may occasionally die as it happened on me a coulpe of times already
<pedronis> there's a zoo of filtering options to trigger but we aren't using them
<mborzecki> hm maybe interface should specify a subsystem at least
<mvo> Chipaca: do you have an opinion on #5134?
<mup> PR #5134: Shrink image generated with snap prepare <Created by kubiko> <https://github.com/snapcore/snapd/pull/5134>
<Chipaca> mvo: let me look
<Chipaca> ah. it's green now? i'll look properly then :-)
<ogra_> mborzecki, well, snapd should inspect what subsystem the rules are for and only re-trigger that one ... blindly re-running all rules and uevents (which is what trigger does) can dremove and re-add devices ... xorg might simply not expect that
<ogra_> -d
<ogra_> mborzecki, it can get really nasty if udev decides to re-init your HDDs
<ogra_> (because you didnt exclude the block devices)
<mvo> Chipaca: not sure if it is, I merged master and addressed the review from zyga
<mvo> Chipaca: but it does lok interessting
<mborzecki> ogra_: hehe, it does trigger the disks to spin up, also yday my sound card went away, pulseaudio died and pcspkr started working instead
<ogra_> yeah
<mborzecki> well, at least there's something to investigate now
<zyga> IMO the question about udev is that it fails -sometimes-
<zyga> Why is that?
<niemeyer> zyga: Are you holiday? :)
<niemeyer> on
<zyga> Yes
<niemeyer> zyga: Doesn't look like it!
<niemeyer> :P
<zyga> Heheh
<zyga> Taking a break
<zyga> We arrived at 2am
<zyga> And woke up early
<mup> PR snapcraft#2140 opened: lp 1768233 workaround for plainbox_provider plugin <Created by jocave> <https://github.com/snapcore/snapcraft/pull/2140>
<skomorokh> Is a "classic" confinement snap just classic in the sense that it runs unconfined as the user when they load the app or does it also let the package maintainer run scripts as root like a .deb or similar?
<b_b> it seems override-build is what i'm looking for
<b_b> maybe i should put after: [desktop-gtk2] in a specific part
<b_b> cause everytime i clean my snap the build of gtk take so long
<mborzecki> my snap graphics-debug-tools-bboozzoo has been flagged for manual review because i'm not shipping *.desktop files, can someone approve it?
<mvo> mborzecki: sure
<mborzecki> heh installing & removing this snap, pcspkr is back :)
<mborzecki> mvo: thanks!
<mvo> mborzecki: there you go
<mborzecki> mvo: ta
<mborzecki> Chipaca: do you still have that nvidia laptop?
<mup> PR snapd#5172 closed: cmd/snap-confine, interfaces/opengl: allow access to glvnd EGL vendor files <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5172>
<mup> PR snapd#5173 opened: snap: some doc comments fixes and additions <Created by pedronis> <https://github.com/snapcore/snapd/pull/5173>
<Chipaca> mborzecki: i do
<mborzecki> Chipaca: is it on 18.04?
<pedronis> Chipaca: your input on #5173 would be appreciated  (it's small but interesting, apparently)
<b_b> ++
<mup> PR #5173: snap: some doc comments fixes and additions <Simple> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5173>
<diddledan> niemeyer: and jdstrand: I've updated the optical-drive write support PR I filed - take a look when you get a break from other things: https://github.com/snapcore/snapd/pull/4369
<mup> PR #4369: add write permission to optical-drive interface <Decaying> <Created by diddledan> <https://github.com/snapcore/snapd/pull/4369>
<jdstrand> yes, I'm looking at it now
<diddledan> \o/
<diddledan> the tests pass locally (unrelated tests elsewhere are broken but the tests on the optical-drive interface pass)
<diddledan> I can't decide whether I really love golang or whether it is too different for me to understand properly :-p
<roadmr> jdstrand: heads up! I added a task for click-reviewers-tools for bug 1771840
<mup> Bug #1771840: snap upload rejected with "refresh-timer" interface attribute <Canonical Click Reviewers tools:New> <Snap Store:New> <https://launchpad.net/bugs/1771840>
<roadmr> kyleN: ^^ relevant to you as well
<kyleN> ack
<jdstrand> roadmr: I'll have something for you a bit later
<roadmr> yay jdstrand \o/ thanks
 * cachio_ lunch
<Chipaca> pedronis: all the +1's
<Chipaca> pedronis: if you see a message about a '.' at the end, i deleted it; i can't read diff :-)
<diddledan> jdstrand: looks like I might be dereferencing a pointer somehow - my golang probably sucks :-p `if err := plug.Attr("write", &write); err == nil && write == true {` <-- I think `write` is a nil pointer here
<diddledan> I can change the `write == true` test to put it inside the block as a nested `if`. That should fix it?
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<Chipaca> diddledan: if write were a pointer, it wouldn't compile
<diddledan> it's ok, jdstrand pointed out a way to eliminate the whole block in the github comments :-)
<Chipaca> heh
<mup> PR snapcraft#2141 opened: jhbuild plugin: allow running as 'root' <Created by diddledan> <https://github.com/snapcore/snapcraft/pull/2141>
<diddledan> damn that guy, diddledan, he's a nutter
<diddledan> too many commas
 * diddledan tries again
<diddledan> damn that guy diddledan, he's a nutter!
<sergiusens> diddledan: thanks for that jhbuild fix!
<mup> PR snapd#5174 opened: interfaces/default,process-control: miscellaneous signal policy fixes <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5174>
<mup> PR snapd#5175 opened: systemd: mock useFuse() so testsuite passes in container via lxd snap <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5175>
#snappy 2018-05-18
<eraserpencil> When i run "snapcraft", it runs on one processor. How do I let it run on multiple processes?
<mup> PR snapcraft#2140 closed: lp 1768233 workaround for plainbox_provider plugin <Created by jocave> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2140>
<mup> PR snapcraft#2142 opened: Release changelog for 2.42.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2142>
<eraserpencil> is there a list of accepted architectures snapcraft build?s
<eraserpencil> What are the differences between a snap revision and a snap version?
<mborzecki> morning
<mup> PR snapd#5173 closed: snap: some doc comments fixes and additions <Simple> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5173>
<mborzecki> mvo: #5075 is simple an can be landed now, niemeyer requested changes before, but those have been addressed, can you do a review?
<mup> PR #5075: snap/env: fix env duplication logic <Simple> <Created by didrocks> <https://github.com/snapcore/snapd/pull/5075>
<mvo> mborzecki: yes, will do in a little bit
<Lin-Buo-Ren> https://github.com/ubuntu/snapcraft-desktop-helpers/issues/117 I have found the commit that causes the regression
<Lin-Buo-Ren> dunno how to fix though...
<gohan> How can I build a snap package that runs executable jar?
<Lin-Buo-Ren> gohan: Packs an Java runtime into it?
<gohan> @Lin-Buo-Ren how to do it can you please guide us to do that?
<gohan> @lLin-Buo-Ren if there is any example for that please share us.
<Lin-Buo-Ren> gohan: I don't know any Java snaps as of now
<gohan> @Lin-Buo-Ren : ok, thanks...
<mup> PR snapd#5075 closed: snap/env: fix env duplication logic <Simple> <Created by didrocks> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5075>
<Lin-Buo-Ren> gohan: Check out https://forum.snapcraft.io/t/snapcraft-plugin-jdk-java-runtime-app-error/1403/3
<mborzecki> mvo: a bunch of PRs is stuck waiting for re-review after changes were requested
<Lin-Buo-Ren> gohan: Here's an example that claimed working: https://github.com/ogra1/jtiledownloader
<mvo> mborzecki: yeah, I will do a re-run this morning
<Lin-Buo-Ren> I would like to request reviewing two trivial PRs on ubuntu/snapcraft-desktop-helpers: #119, #121
<mup> PR #119: Do not export dirs.snappyDir <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/119>
<mup> PR #121: Add built-in capabilities to the daemon <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/121>
<mborzecki> i can look info fixing #5081 while zyga is on vacation
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<niemeyer> Mornings
<gohan> @Lin-Buo-Ren : ok..
<mborzecki> niemeyer: adjusting to new timezone already?
<Lin-Buo-Ren> https://github.com/ubuntu/snapcraft-desktop-helpers/pull/119 ; https://github.com/ubuntu/snapcraft-desktop-helpers/pull/121
<mup> PR ubuntu/snapcraft-desktop-helpers#119: Makefile: Honour CC, CFLAGS <Created by Lin-Buo-Ren> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/119>
<mup> PR ubuntu/snapcraft-desktop-helpers#121: Prepend $SNAP/share to XDG_DATA_DIRS <Created by Lin-Buo-Ren> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/121>
<niemeyer> mborzecki: A bit early for that :-)
<niemeyer> Just catching up.. yesterday was a bit hard to focus, so gave up and decided to do it early today
<zyga> mborzecki: sure but please check if the expression from Jamie actually works
<niemeyer> zyga: Heya
<zyga> I was somewhat surprised on 2nd read
<zyga> Hey
<niemeyer> zyga: Before I forget, remind me to ask you about the parallel install feature
<zyga> Holidays are fun but not when kids become ill
<zyga> Ack, will do
<newbee> How to make a snap from a .jar files, and how to make the snapcraft.yaml for that ?..
<zyga> niemeyer: why are you up so early? Are you in Europe?
<niemeyer> zyga: No, just shifted today to catch up with reviews a bit
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> damn, spilled coffee :/
<pstolowski> mborzecki: ouch
<eraserpencil> What is the filepath to see where plugs and slots connects. I'm unsure where to point "target" of my content plug interface
<Chipaca> moin moin
<mvo> hey Chipaca
<Chipaca> mvo: 'sup
<mvo> Chipaca: reviews mostly and a bit of core18 work. I'm also looking for a volunteer who wants to work on the snapd snap :)
<mvo> Chipaca: 'sup on your side?
<Chipaca> mvo: the snapd snap sounds fun :-) but not sure i'll have the space today to learn where it fits in the dance
<Chipaca> mvo: if you're still looking on Monday, hit me up
<mvo> Chipaca: sounds great. monday is a public holiday here but I can still hit you :)
<Chipaca> today, physio (unless things are on fire), then into London for lunch, otherwise snapshots (if i get a review) or warnings (if not)
<Chipaca> mvo: tuesday is also good
<Chipaca> maybe i should take monday off to discourage you from working it
<Chipaca> that sounds quite nice actually
<niemeyer> pedronis: you got a review on #4497.. LGTM once that's considered
<mup> PR #4497: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<niemeyer> mvo: You have a review request there too ^
<niemeyer> Chipaca: Moin
<Chipaca> niemeyer: getting used to gmt?
<niemeyer> Chipaca: No, just catching up on reviews.. feeling bad for my lag there
<niemeyer> Still a couple of months away from the shift
<Chipaca> niemeyer: don't run yourself into the ground
<Chipaca> niemeyer: we call 'em sprints, but they're marathons
<niemeyer> Chipaca: Thanks, and yeah.. the more it grows the heavier the burn is to get it down
<gohan> how to access extenal jar file in snap?
<niemeyer> gohan: Heya
<niemeyer> gohan: The forum is usually a better place for that sort of question as you'll get more eyes there, and the ability for them to answer on their appropriate time without your question getting lost to the logs
<niemeyer> gohan: The general answer is that the jar needs to ship with the snap
<niemeyer> gohan: But your question probably has more context than this
<mup> PR snapd#5176 opened: many: add `snap connectivity-check` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/5176>
<mvo> Chipaca: the above PR is a bit of an RFC - if you could have a look and check that the approach makes sense that would be cool, then I can clean it up properly
<pedronis> niemeyer: thanks
<mvo> 5175 is an easy win
<niemeyer> #5175
<mup> PR #5175: systemd: mock useFuse() so testsuite passes in container via lxd snap <Simple> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5175>
<mborzecki> zyga: https://paste.ubuntu.com/p/THFBWKbZzD/
<mup> PR snapd#5175 closed: systemd: mock useFuse() so testsuite passes in container via lxd snap <Simple> <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/5175>
<niemeyer> mborzecki: #4504 unblocked
<mup> PR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<mborzecki> niemeyer: thanks!
<niemeyer> np
<pstolowski> niemeyer: can you take a look if the approach in #4551 is now ok? it was re-worked after your initial review and after I had a discussion with zyga
<mup> PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<mup> PR snapd#4538 closed: interfaces/builtin: Add new steam-support interface <Created by ikeydoherty> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4538>
<niemeyer> mvo: #4600 re-reviewed
<mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
<mvo> niemeyer: thank you!
<niemeyer> mvo: np, and thanks! nice feature!
<niemeyer> pstolowski: Yeah, the tab for that one was even open already :)
<pstolowski> niemeyer: that's already a good start :) thanks
<pedronis> mvo: thanks for the review, I'll work through the comments after lunch
<mvo> pedronis: thank you, nice PR, this will make it much more usable
<mvo> 5174 is also probably an easy win
<Chipaca> mvo: i'm looking at #5176 now, but will be offline for a little bit
<mup> PR #5176: many: add `snap connectivity-check` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/5176>
<Chipaca> ttfn
<mborzecki> leaving #5081 for now, did the change but it feels a bit fishy around edge cases, probably best if zyga takes a look at it
<mup> PR #5081: interfaces/apparmor: add chopTree <Created by zyga> <https://github.com/snapcore/snapd/pull/5081>
<pstolowski> zyga: conflicts on #4996
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<niemeyer> pstolowski: #4551 reviewed, thanks!
<mup> PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<pstolowski> niemeyer: ty!
<tatramaco> hi
<tatramaco> anyone know how I can configure the apparmor policy for chromium to allow it to talk to u2f security key ?
<eraserpencil> :q
<tatramaco> or is there an interface for a u2f key ?
<ogra_> tatramaco, thats probably better suited as question to the forum (see channel topic)
<tatramaco> I had already tried there and nada
<niemeyer> tatramaco: Please ping me there and I'll go after it
<niemeyer> Taking a break now to rest a bit before the standup
<cachio_> mvo, hey, about the comment you did on the #4416
<mup> PR #4416: tests: performance measurements for basic snapd commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4416>
<cachio_> with the question this way we avoid mixing stdout with the performance results?
<cachio_> I don't get what you are proposing
<fusion809> Hi folks, why is 2.32.9 tagged in the snapd repo but there's no release notes to it and no vendor tarball? I was expecting it to be merely a matter of time, like a few hours a day at most, but it's been two days and there's still no release notes. Did someone just accidentally tag it, or something?
<mborzecki> mvo: ^^
<mborzecki> pedronis: can you take a look at #4996 ? i've pushed some changes
<mup> PR #4996: overlord/ifacestate: store and use revision with security profiles set <Created by zyga> <https://github.com/snapcore/snapd/pull/4996>
<mborzecki> i'm off to pick up the kids, coming back for the standup
<jdstrand> mborzecki: hey, is 'daemon-notify' ready for re-review now?
<mup> PR snapd#4551 closed: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<mvo> fusion809: hey, sorry for this. .9 is only autopkgtest fixes which are very ubuntu specific, however I see that this is confusing and will add a page on GH
<fusion809> mvo: thank you for clarifying.
<Chipaca> re
<Chipaca> just a quick pop in to let y'awl know I'm going to miss the standup, as I'll be on the underground going back home then
<mvo> fusion809: updated, thanks for letting us know!
<Chipaca> mvo: happy to bikeshed the location, but not bothered by what's there (beyond this command not being debug -- the problem is we've always said debug commands were guaranteed not stable)
<Chipaca> mvo: for ex: i'd say this is slower/more expensive but still system info-ish, so as such we could have a select= on sysinfo do it
<mvo> Chipaca: yeah, that sounds reasonable. sysinfo works for me
<mvo> Chipaca: I won't be in the meeting today but please relay that I want to branch 2.33 early next week (Monday hopefully)
<mvo> Chipaca: we are a bit behind with this one already
<Chipaca> mvo: neither will i
<mvo> Chipaca: aha, ok
<mvo> niemeyer:  I won't be in the meeting today but please relay that I want to branch 2.33 early next week (Tuesday hopefully, monday is a public holiday here). we are already a little bit behind with 2.33
<Chipaca> pedronis: is there anything we could do to hit the right cdn with something cheap, say a HEAD request, that'd get redirected appropriately?
<mvo> Chipaca: you ask the right questions :)
<pedronis> Chipaca: we could do details on something well known and do HEAD on the download url
<Chipaca> pedronis: yes we could, but i'd be happier if we weren't making the db do extra work for a connectivity check :-)
<pedronis> the cdn might vary
<pedronis> and the download urls are not documented
<pedronis> in theory if we had a canary snap  with just one revision its download url before redirects would be fixed (until thing change and ignoring the enterprise proxy)
<pedronis> so not sure how not to ask the store for a download url
<pedronis> if we care
<mborzecki> jdstrand: yes
<Chipaca> pedronis: maybe we should chat with our store buddies :-D
 * Chipaca disappears into the tubes
<niemeyer> Heya
<niemeyer> Running late but omw
<niemeyer> mvo: Ack, thanks
<noise][1> pedronis: what was that download URL thing in reference to, or the use-case i mean?
<pedronis> noise][1: mvo is implementing a connectivity check for snapd, to see if it can access the main api domain,  but there's a question how to check that download are accessible
<pedronis> noise][1: wip PR is here: https://github.com/snapcore/snapd/pull/5176
<mup> PR #5176: many: add `snap connectivity-check` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/5176>
<pedronis> s/domain/domains/
<mborzecki> jdstrand: thanks for the review
<noise][1> pedronis: makes sense, thx
<pedronis> noise][1: so we wonder if  we care about having something better that  doing /details on a snap and HEAD on the download url (following redirects)
<Chipanaut> ullo ullo
<noise][1> pedronis: that should be a reasonable start
<Chipanaut> ooh, ooh
<pedronis> yea, think so
<Chipanaut> pedronis: noise][1: are you talking about the connectivity check
<noise][1> make sure we pass the headers
<noise][1> in case of cloud images
 * Chipanaut on the move, hoping the webchat works better than actual irc on iffy networks
<Chipanaut> noise][1: a question I have is whether HEAD will always redirect, or if we should do a plain GET and then drop it
<Chipanaut> of course the boss check would be to download and check the hash, but that's taking it a bit far
 * Chipanaut is suspicious of the silence in the channel
<pedronis> Chipanaut: yes we were talking about that
<noise][1> the HEAD should get your the redirect, but best to double check it :)
<Chipanaut> noise][1: it does today
<Chipanaut> noise][1: my question is whether we can  rely on it, as CDNs come and go :-)
<pedronis> the redirect comes from the API
<Chipanaut> d'oh
<pedronis> we control it
<Chipanaut> i'll go get a dunce hat, brb
<pedronis> we can add spread test
<pedronis> and also one in the store itself if needed to keep that working if we start relying on it
<Chipanaut> pedronis: same headers, but narrowing fields would be a'ight, yes?
<pedronis> Chipanaut: yes, but my point is that we need to send headers also for the download, not just the details
<Chipanaut> mvo: mind if I push a commit to #5176 ?
<mup> PR #5176: many: add `snap connectivity-check` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/5176>
<Chipanaut> pedronis: gotcha
<pedronis> the actual relevant headers are consumed at that  point
<Chipanaut> pedronis: hardcoding the download url is tempting
<Chipanaut> but i'll be brave and resist
<pedronis> Chipanaut: that is not a good idea because of the enterprise proxy
<Chipanaut> pedronis: well, I had reasons for it not being a good idea before :-) but yeah
<pedronis> the current code does the right thing wrt that afaict
<Lin-Buo-Ren> https://bugs.launchpad.net/snapcraft/+bug/1772027
<mup> Bug #1772027: Pull stage of a unspecified part is unexpectedly cleaned by snapcraft <Snapcraft:New> <https://launchpad.net/bugs/1772027>
<Chipanaut> pedronis: wrt headers and HEAD?
<pedronis> Chipanaut: no, IÂ meand wrt to using the right helper to use if the eproxy url if it's set
<Chipanaut> ah, k
<pedronis> Chipanaut: also my other comment silly, we can just use the GET details instead of the current endpoint GET
<pedronis> not doing the former only if the latter work
<Chipanaut> yeap
<Chipanaut> pedronis: I'm about to go offline again for a bit, but I'll work on this
<Chipanaut> 's fun
<pedronis> ok, thx
<pedronis> :)
 * Chipanaut steals the fun work out from under mvo's feet
<jdstrand> mborzecki: thanks for sticking with that PR. it was a loooong time coming :)
<jdstrand> Chipanaut: fyi, I responded in the PR regarding classic and signals
<thresh> jdstrand, we can debug the issue here, since it's going to be faster (re: qt/vlc/debian)
<thresh> I think I also reproduced the same behaviour on newest ubuntu though
<thresh> but we can focus on debian for now
<mup> PR snapd#4504 closed: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<jdstrand> thresh: for the moment I think it makes sense to discuss in the forum since we may handoff
<xnox> jdstrand, mvo, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858 does this sound reasonable to you? and will you be able to ship effectively a one line shell script?
<mup> Bug #1771858: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH <snapd (Ubuntu):New> <systemd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <systemd (Ubuntu Xenial):Confirmed> <snapd (Ubuntu Bionic):New> <systemd (Ubuntu
<mup> Bionic):Won't Fix> <snapd (Ubuntu Cosmic):New> <systemd (Ubuntu Cosmic):Won't Fix> <https://launchpad.net/bugs/1771858>
<thresh> jdstrand, gotcha
<jdstrand> xnox: I have no objections since it is appended to PATH
<jdstrand> cc mvo ^
<xnox> jdstrand, mvo - btw this is an actual bug for foundations, we can't integrate preseeded snaps on classic in clouds =)
<jdstrand> thresh: what is the output of 'snap info vlc'
<jdstrand> thresh: on Ubuntu, what kernel were you using?
<thresh> jdstrand, snap info vlc: https://gist.github.com/thresheek/28e1e1fea148f32648a2022bc8400ee3
<thresh> jdstrand, re ubuntu:  my 18.04 does not boot for some reason, but the same happens on 16.04, using 4.13.0-36-generic, `XDG_CURRENT_DESKTOP=KDE snap run vlc -vvv`. snap/snapd 2.32.6.  same vlc (337).
<jdstrand> thresh: to be clear, that snap info was done on the debian system?
<thresh> jdstrand, correct. coal is my debian machine.
<jdstrand> thresh: I'm going to try to reproduce this. in your Debian testing machine, what do you install to get a typical KDE environment?
<jdstrand> thresh: apt-get install ...?
<thresh> ugh, tough question
<thresh> on regular 16.04 ubuntu it's enough to reproduce that issue with XDG_CURRENT_DESKTOP=KDE snap run vlc -vvv
<jdstrand> thresh: I didn't know if there was some meta package there
<thresh> without any kde stuff installed afaict
<jdstrand> thresh: the difference on 16.04 will be strict mode though...
<jdstrand> I mean, it could be the same underlying issue, just trying to distill this down a bit
<thresh> I mean you don't really need to run under KDE, setting that env var should be enough to tell Qt5 you're on KDE.
<jdstrand> I understand. but Debian vs Ubuntu will change the system confinement
<thresh> kde-plasma-desktop I guess
<jdstrand> anyway, I'll figure it out
<thresh> is the name of the package
<jdstrand> thanks
<Chipaca> pedronis: mvo: should the connectivity check retry?
<Chipaca> eg should it do client.Get, or httputil.RetryRequest
<pedronis> Chipaca: should probably retry but a bit less agressively, less max time than normal?
<Chipaca> bah, there's two axes: client.Get vs store.doRequest (which could refresh a macaroon etc), and direct vs httputil.RetryRequest
<pedronis> the refresh macaroon bit is annoying
<pedronis> it's less an issue with SnapAction though
<pedronis> Chipaca: I think more than /details we probably want the new not existing action for download
<Chipaca> pedronis: it's more of an issue for details than for snap action?
<pedronis> Chipaca: if the macaroon is expired  /details will 401 on you
<pedronis> SnapAction will still return a result
<pedronis> but tell btw
<pedronis> so you can ignore the refresh macaroon bit
<pedronis> (which is a bit odd to do in here)
<Chipaca> pedronis: the problem is the device macaroon, right?
<Chipaca> device session?
<pedronis> yes
<Chipaca> ye
<pedronis> basically if we use /details for now
<pedronis> we need all the dance
<pedronis> later we can do what we will do for download/prepare-image
<pedronis> and cut some of the code
<Chipaca> ah, for the days of yore, when men were men and everything was plaintext
<Chipaca> pedronis: so I'll use retry with a doRequest, and add a TODO to move it to the new thing explaining why
<pedronis> Chipaca: basically later we should be able to use some variant of Store.snapAction (the internal helper that doesn't refresh on itself)
<Chipaca> hmmm
<pedronis> maybe
<pedronis> it's trade offs
<Chipaca> what's https://dashboard.snapcraft.io/dev/api/
<Chipaca> ?
<Chipaca> in particular, what's that license list
<pedronis> I don't know
<pedronis> it doesn't seem ideal to hit though
<pedronis> Chipaca: it's api metadata
<pedronis> and the license bit seems buggy
<Chipaca> pedronis: yes
<pedronis> it hits the db (lightly)
<pedronis> channel and release come from the db afaict
<pedronis> anyway not completely ideal
<pedronis> it's cached though afaict
<Chipaca> eeep
<Chipaca> rabbitholes
<mvo> Chipaca: haha, yeah, steal the fun, thats fine. more fun Tuesday when you work on the snapd snap :)
<mvo> xnox: thanks, I saw the bug I will have a look Tues (Mon is a holiday here)
<cachio__> __    62221
<cachio__> .
 * cachio__ afk
<mup> PR snapd#5177 opened: interfaces/builtin: allow access to libGLESv* too for opengl interface <Created by morphis> <https://github.com/snapcore/snapd/pull/5177>
<mup> PR snapd#5178 opened: interfaces/builtin: initial version of the anbox-support interface <Created by morphis> <https://github.com/snapcore/snapd/pull/5178>
<om26er> popey: where does vim' snap packaging live ? (is uploaded by snapcrafters)
<om26er> and the current version apparently does not work
<popey> om26er: no idea! dunno who uploaded that
<popey> om26er: sergio
#snappy 2018-05-19
<Lin-Buo-Ren> https://github.com/ubuntu/snapcraft-desktop-helpers/pull/123
<mup> PR ubuntu/snapcraft-desktop-helpers#123: Fixup REALPATH expansions <Created by Lin-Buo-Ren> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/123>
<Lin-Buo-Ren> I would like to say the scripts in snapcraft-desktop-helpers have quite a few bugs, will patch it in the near future
<Lin-Buo-Ren> I wonder if you accept patches that enables script checking in c-i?
<zyga> Lin-Buo-Ren: for sure :)
<zyga> pstolowski|afk: we have a bug :)
<zyga> my snapd is using 100% of CPU since i left poland apparently
<zyga> trying to reconnect interfaces
<zyga> snapd using lots of CPU, doing reconnects https://www.irccloud.com/pastebin/1flru8oN/
<zyga> snap changes takes _very_ long to respond
<jack> I am new to snap, now i want to make a snap for . jarfile. please guide us to create a snap.
<zyga> it takes almost 30 seconds to run "time snap changes 355"
<zyga> jack: there are documents that show how to do this, please research snapcraft and jar
<zyga> jack: qucik google search gave me this, does it help? https://forum.snapcraft.io/t/how-can-i-snap-a-jar/3306
<jack> @zyga yes, but i when i run this it shows, "missing files in your snap"
<zyga> have a look at this: https://github.com/snapcore/snapcraft/tree/master/demos/java-hello-world
<zyga> it should be a working example
<zyga> the error you gave usually means that the command you want to execute as a part of application command: section is missing
<zyga> remember that it is relative to the snap itself
<zyga> (to $SNAP)
<jack> @ zyga  thanks.. i do this in my snap..
<zyga> good luck
<zyga> pstolowski|afk: the high cpu usage condition persists across snapd restart
<zyga> pstolowski|afk: this is bionic with edge
<zyga> though an older one as my snapd tried to refresh core and failed in this weird state
<zyga> in the end I aborted that change: maj 19 09:24:22 t470 snapd[12097]: 2018/05/19 09:24:22.102917 handlers.go:374: Reported install problem for "core" as a636dfbe-5b35-11e8-a231-fa163ebeb28a OOPSID
<zyga> pstolowski|afk: now I'm equally stuck reconnecting interfaces
<zyga> using lots of CPU
<zyga> something is very wrong with the revision I'm on
<zyga> snap    2.32.9+git733.7f74160~ubuntu16.04.1
<zyga> it seems to be compiling subsequent apparmor profiles
<zyga> last once I got is vlc.vlc
<zyga> but this doesn't explain why snapd uses the cpu
<zyga> (not apparmor_parser)
<zyga> I've stopped snapd not to drain by battery now
<Lin-Buo-Ren> I would like to ask if the default shell in snap apps is dash
<Lin-Buo-Ren> Because there's LOTS of bashisms in the desktop-launcher scripts
<Son_Goku> Lin-Buo-Ren, I sure hope not
<Son_Goku> mainly because most distributions aren't insane enough to use dash by default
<zyga> Lin-Buo-Ren: No, AFAIK It is basy
<zyga> Bash
<Lin-Buo-Ren> zyga: Got it, that'll be much easier IMO
<cjwatson> $ ls -l /snap/core/current/bin/sh
<cjwatson> lrwxrwxrwx 1 root root 4 Feb 17  2016 /snap/core/current/bin/sh -> dash
<cjwatson> same if I do "snap run --shell <random snap>" and "ls -l /bin/sh" there
<Lin-Buo-Ren> cjwatson: I'm quite sure bash is installed in core as well?
<cjwatson> That is not the same as what the default is ...
<Lin-Buo-Ren> Sure...
<cjwatson> But sure, it is
<Lin-Buo-Ren> I noticed that they actually inserted a bash shebang at the head of the desktop-launch script, oh well
<zyga> Bash is used by snapcraft generated scripts AFAIR
<anarcat> hello
<anarcat> i'm wondering why my firefox snap is stuck in the past.. "sudo snap refresh" says "All snaps up to date."
<popey_> what does "snap info firefox" say?
<anarcat> pasting... :)
<anarcat> http://paste.debian.net/1025424/
<popey> you installed with --devmode. That's why
<anarcat> popey: did i?
<anarcat> okay, how do i unstick that? :)
<popey> if you `snap refresh firefox --stable` does it do it?
<anarcat> "snap refresh firefox" seems to download the new version, but i wanted to fix the auto-upgrades
<anarcat> i'll try snap refresh firefox --stable
<juliank> hmm, does it stay in devmode then?
<anarcat> that says "snap "firefox" has no updates available"
<popey> Not sure how you can refresh from devmode to non-devmode.
<anarcat> and so does "snap "firefox" has no updates available"
<anarcat> gah
<popey> might need to uninstall and reinstall
<popey> (which will lose your profile, so back that up)
<anarcat> and so does "sudo snap refresh firefox"
<anarcat> sudo snap refresh firefox --classic also fails
<popey> dont do that
<popey> thats worse :)
<juliank> it's not a clasic snap ...
<popey> random commands won't help here :)
<popey> I would backup ~/snap/firefox
 * anarcat tries to bruteforce snap ;)
<popey> then snap remove firefox, snap isnatll firefox
<popey> but spelled correctly
<anarcat> hehe
<anarcat> okay, will try
<popey> and then put ~/snap/firefox back
<juliank> popey: just trying to get anarcat to understand different snap types :)
<anarcat> thanks juliank :)
<anarcat> okay, so  tar cfz ~/backups/ff.tgz ~/snap/firefox && rm -rf ~/snap/firefox
<anarcat> done
<ads20000> errr
<ads20000> the rm -rf was unnecessary xD
<anarcat> ah
 * anarcat restores
<anarcat> Download snap "firefox" (85) from channel "stable"
<anarcat> low bandwidth here - this is going to take 30 minutes (!)
<ads20000> ah yes, better when installed since you'll likely have update deltas etc...
<ads20000> and yes you will get auto-refreshes
<juliank> anarcat: maybe check any other installed snaps if they are in devmode too (if you have more)
<ads20000> basically you kinda have to let it happen and when you notice it's slowing stuff down use `snap changes` then `snap abort number` where number is the number of the update
<ads20000> *number of the refresh task
<anarcat> ads20000: i'm not following... what are you describing?
<anarcat> juliank: i'll check
<ads20000> anarcat: how to manage the automatic updating on low bandwidth connections
<anarcat> i see
<anarcat> well i don't mind it taking it's time
<anarcat> i'm just saying it will take a while before i can report back :)
<anarcat> it seems no other snap is stuck
<anarcat> or at least, not in devmode
<anarcat> downloading like it's 1999:  13% 93.9kB/s 31.9m
<anarcat> ads20000: does abort allow for resumes or i'd have to start over from cratch?
<anarcat> 26%  104kB/s 24.6m
<ads20000> anarcat: not sure
<anarcat> sigh
<anarcat> rain and wifi, fun times
<ads20000> anarcat: patience!
<ads20000> yeah I know the feels
<anarcat> fun fact: suspending `sudo snap install` does not suspend the download :p
<popey> no because its not snap that is doing the download, it's a background process
<anarcat> weird - i get much better bandwidth with youtube...
<popey> the snap command is an interface to that background process
 * anarcat shrugs
<popey> be interested to know which cdn you're on
<anarcat> right, figures
<anarcat> ah?
<popey> we have a couple of cdns in use
<anarcat> ah
<popey> if you run something like nettop or iftop or something, you can see where the traffic is coming from
<popey> and figure out which cnd in it, not that it will help you speed it up unfortunately
<popey> be nice to capture the data in a bug report for the store team
<anarcat> looks like fastly
<anarcat> 151.101.138.217
<popey> sounds about right, its them or internap i believe
<anarcat> captiure which data?
<popey> I'm not actually sure what helps the store team, and being the weekend they're likely not about
<popey> we should have a thread on the forum to document it
<anarcat> well considering the difficult network conditions here, i wouldn't make a fuss about it
<anarcat> youtube-dl said: [download] 100% of 39.56MiB in 04:18
<anarcat> that's about 160KB/s
<anarcat> firefox 60.0-2 from 'mozilla' installed
<anarcat> whoohoo!
<anarcat> devmode gone
<anarcat> thanks for the help folks
<juliank> anarcat: have fun browsing the web :)
<anarcat> juliank: thanks!
<anarcat> i feel like i'm on the information superhighway! it's great!
#snappy 2018-05-20
<trvbueno> Hi, having issues with the UBUNTU_STORE_ID env. variable on Fedora. Trying to switch to Limenet's but seems like the variable is simply ignored by snap. Am I missing something?
<trvbueno> I feel like it is related to PR 3382 in a way I don't fully understand just yet
<mup> PR #3382: daemon,overlord/auth: store from model assertion wins <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3382>
<pedronis> trvbueno: what does  "snap known model"Â shows?   are you setting in /etc/enviroment, have your restarted snapd?
<trvbueno> pedronis: type: model, model: generic-classic, series: 16, brand-id: generic, authority-id: generic, classic: true then some key
<trvbueno> pedronis: cat /etc/environment returns UBUNTU_STORE_ID=LimeSDR
<trvbueno> And yes, tried to restart snapd, and also reboot.
<pedronis> trvbueno: afaik that combination should work, you can set SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=1 as well and restart, and look at journactl -u snapd  to see if the right header with the store id is sent
<trvbueno> pedronis: Thanks. I'll try and see what's wrong.
<trvbueno> Well, turns out when systemd is launching snapd apparently it's not under the same environment variables than running it manually as described in the HACKING document of the repository.
<trvbueno> So: when running manually, I have access to the LimeSDR store, but not when it's systemd. Also, debug flags not working either when ran by systemd.
<trvbueno> Solved, environment variables for snapd need to go in /etc/sysconfig/snapd on Fedora.
<Son_Goku> trvbueno, yes, Fedora packaging (and all derivatives of it) use /etc/sysconfig/snapd
#snappy 2019-05-13
<mborzecki> morning
<zyga> Good morning mborzecki
<mborzecki> zyga: hey
<zyga> Ries and shine,
<zyga> s/ries/rise/i
<mup> PR snapcraft#2563 closed: Release changelog for 3.5 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2563>
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mborzecki> hmm mirrors.fedoraproject.org does not resolve
<mborzecki> pstolowski: can you try nslookup fedoraproject.org ?
<Chipaca> bongiorno, principesse e principi
<pstolowski> Chipaca: hey!
<mborzecki_> Chipaca: hey, thought you're swapping today
<Chipaca> I was talked into not doing so :-)
<Chipaca> as in, not needing to swap
<Chipaca> not as in not swapping
<Chipaca> :)
<Chipaca> had a very lazy weekend (where 'lazy' includes 'personal best 10k woo' but w/e)
<mborzecki_> Chipaca: congrats
<Chipaca> pstolowski: on Friday you said maybe we should add a flag to Done() to say whether the script had run or not, and I said maybe instead just don't run things (and we add the flag if/when we need the "run Done even with no script" feature instead), but I didn't understand your answer -- and didn't want to slow down the standup further
<mborzecki> Chipaca: don't tell mvo though :)
<Chipaca> mborzecki: about which part? =)
<mborzecki> Chipaca: 10k personal best
<Chipaca> mborzecki: :-) I'm more competitive than he is, but we both go to great efforts not to be competitive with each other
<Chipaca> just don't play board games with me and you'll be fine
 * Chipaca does not want to show that side of himself ever
<Chipaca> pstolowski: could you tell me why the "don't run it" option is worse?
<Chipaca> to me it seems like a win, there's a lot of stuff we'd avoid doing in the common case of 'no script'
<Chipaca> (everything from the xxx on)
<pstolowski> Chipaca: yes, sorry, I think I didn't understand your suggestion either. I think as long as we keep an option to run Done() even if there is no script, it's fine, that was my main point. Probably your idea is better to save some cycles indeed
<Chipaca> pstolowski: I'll push a pr to add this, then
<Chipaca> with a flag on the hook setup
<Chipaca> just in case (tm)
<pstolowski> Chipaca: thanks
<mup> PR snapd#6862 opened: overlord/hookstate: don't run handler unless hooksup.Always <Created by chipaca> <https://github.com/snapcore/snapd/pull/6862>
<Chipaca> pstolowski: ^^^
<ackk> hi, I'm seeing a weird behavior with python deps building a snap non non-intel machines
<ackk> https://launchpadlibrarian.net/423189074/buildlog_snap_ubuntu_bionic_arm64_maas_BUILDING.txt.gz is failing because cffi pulled from pipy differs from the one in bionic, but https://launchpadlibrarian.net/423191401/buildlog_snap_ubuntu_bionic_amd64_maas_BUILDING.txt.gz doesn't
<ackk> and they have the same versions
<Chipaca> ackk: ports.u.c. differing from the main archive?
<Chipaca> or is that what you mean about the same versions
<ackk> Chipaca, well it seems the python3-cffi-backend deb that get installed is the same version in both cases
<ackk> 1.11.5, whereas the one from pypi is 1.12.3
<ackk> so I'm not sure why it's failing in one case and not in the other
<ackk> actually it fails on arm64 and ppc64 arches, works in i386 and amd64
<Chipaca> ackk: so the deb is the same version, but the one in pipy is different, for those arches?
<ackk> Chipaca, no, deb is 1.11.5 for all and pypi is 1.12.3 for all
<ackk> but it only complains that the versions are different on non-intel
<Chipaca> ackk: could it be because pipy does not have non-intel linux binaries of cffi?
<ackk> Chipaca, ah. that's a good point
<ackk> indeed it seems so
<Chipaca> ackk: so maybe on non-intel it's trying to build it from source, and needs more stuff for that?
 * Chipaca does not know
<ackk> Chipaca, well I guess I can try to force cffi in requrements to match the ubuntu one
<zyga> Hello
<Chipaca> zyga: 'sup
<pstolowski> zyga: hey!
<pstolowski> zyga: how was the travel? how is the sprint going?
<zyga> pstolowski: the travel was very good, the sprint is going on slowly, nothing eventful yet
 * Chipaca lunches
<zyga> pstolowski: some meetings about core20 but early early discussions
<Saviq> zyga: https://git.launchpad.net/~saviq/+git/miral-framework?h=master is my test - didn't work with edge FWIW
<mborzecki> cmatsuoka: pstolowski: please take another look at #6849, i've pushed an implementation that matches what libblkid does
<mup> PR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<mborzecki> (or systemd/udev for that matter)
<mborzecki> off to pick up the kids
<cmatsuoka> mborzecki: ack
<pstolowski> mborzecki: k, will do after lunch
<mborzecki> cmatsuoka: pstolowski: thx!
<Chipaca> degville: what would be better: "Talk to apt via an apt hook", "Run as an apt hook", "Run in 'apt hook' mode", or "Be an apt hook" ?
<zyga> mborzecki: quick one https://github.com/snapcore/snapd/pull/6863
<mup> PR #6863: testutil: support sharing-related mount flags <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6863>
<mup> PR snapd#6863 opened: testutil: support sharing-related mount flags <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6863>
<degville> Chipaca: I think the second, or - 'via an apt hook'? (difficult without context). if we can link to something apt hook related, that would be good too.
<Chipaca> degville: this is for 'snap advise-snap --from-apt', which is a bit backwards but also currently is wrong and also *also* currently upsets localisers because trying to fix it breaks our static lowercase-description rule
<Chipaca> degville: it's a command that's hidden (so nobody ever sees this string! until we fix go-flags) and the option is only used from integration scripts
<mup> PR snapd#6861 closed:  packaging/fedora: Merge changes from Fedora Dist-Git and drop EOL Fedora releases <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6861>
<Chipaca> but, we smacked an i18n.G on it to be conscientious about it or sth
<Chipaca> degville: apt runs this as a hook for suggestions, basically
<Chipaca> "Run under apt" could also work, not mention hooks at all
<Girtablulu> Save data of snap "retroarch" in automatic snapshot set #27 (cannot create archive: runuser: failed to user credentials: <-- someone knows what's the issue is?
<degville> Chipaca: I'm just in our standup if you wanted to chat about it.
<Chipaca> omw
<Chipaca> was just about to ask about the standup :)
<zyga> mborzecki: another one please https://github.com/snapcore/snapd/pull/6864
<mup> PR #6864: cmd/snap-update-ns: fix golint complaints about variable names <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6864>
<mup> PR snapd#6864 opened: cmd/snap-update-ns: fix golint complaints about variable names <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6864>
<Chipaca> Girtablulu: ouch
<Chipaca> Girtablulu: is there anything interesting about our user setup?
<Girtablulu> define interesting? :), installment works fine just doesn't let me remove stuff :D
<Chipaca> Girtablulu: anything other than the default /etc/passwd user
<Girtablulu> nope, not that I'm aware of, using Solus
<Chipaca> Girtablulu: on remove snapd now tries to archive the user data before deleting it, and for some reason your system doesn't support that
<Chipaca> Girtablulu: you'll probably get the same error from 'snap save'
<Girtablulu> yep correct
<Chipaca> Girtablulu: you can disable these snapshots, to unblock you; pstolowski will know how to do that (it's in the forum otherwise)
<Chipaca> Girtablulu: but something's funny with your system fwiw
<Girtablulu> k thanks for the info
<degville> Chipaca: if the way apt is probed doesn't matter to whoever is asking for help on advise-snap (would it help to know, for eg., when troubleshooting an integration script), I'd go with "Run under apt."
<Chipaca> degville: the super-verbose one would be "This flag tells snap-advise that it is being run under apt, as a hook", or something like that
<degville> Chipaca: +1 - sounds good to me!
<Chipaca> degville: but that's too long :-D
<Chipaca> bah,not really, but we usually get away with it being shorter
<Chipaca> the "this flag tells <the command> that" is usually implied
<Chipaca> but it's a bit weird, this one
<Chipaca> dunno
<degville> Chipaca: right, sorry. Thought there was going to be both a short and verbose version.l
<Chipaca> omg no :)
 * Chipaca suddenly imagined having to come up with short _and_ verbose versions of every flag help text
<degville> Chipaca: ahaha! "Run  under apt using a hook", "Run via an apt hook."?
<Girtablulu> Chipaca: thanks found the command
<Chipaca> Girtablulu: snap set system somethingsomethingsomething?
<Chipaca> degville: this is a flag apt uses to tell 'snap advise-snap' it is running under apt
<Girtablulu> snap set core snapshots.automatic.retention=no
<Chipaca> Girtablulu: that's what i said :-p (j/k, but note core and system are synonymous there)
<Girtablulu> ah k :)
<Chipaca> Girtablulu: out of curiosity if you could explore why runuser doesn't work for you I'd be grateful
<Chipaca> Girtablulu: if you can't you can't :)
<Girtablulu> I gonna poke the solus cores devs regarding this, for me is this a bit confusing :)
<Chipaca> Girtablulu: it's a new feature so it's entirely possible we're needing to do something extra -- but it might be some wonky integration on solus's side. I really don't know.
<Chipaca> Girtablulu: you can quote me on that (especially the last sentence is always true)
<Girtablulu> yea
<Girtablulu> that's why first poking solus devs :D
<Girtablulu> quite possible that ikey build the snap package not correctly for solus and now it shows
<Chipaca> degville: everything is terrible. I'm going with "Run as an apt hook" and hoping for the best.
 * Chipaca misses ikey
<degville> Chipaca: ok. :)
<Chipaca> mborzecki: fedora 30 not having snap/bin on path was fixed somewhere, right?
<mborzecki> Chipaca: is it about the warning in snap install?
<Chipaca> mborzecki: ye s
<Chipaca> mborzecki: see https://forum.snapcraft.io/t/how-to-fix-snap-binaries-not-found/9469
<Chipaca> lots of federees
<Chipaca> fedorees
<Chipaca> fedorians
<mborzecki> Chipaca: iirc, plain sudo would not load the whole profile, so no PATH entry
<Chipaca> fedoralians
<Chipaca> aliens
<mborzecki> Chipaca: sudo -i worked though
<mup> PR snapd#6865 opened: cmd/snap: allow option descriptions to start with the command <Created by chipaca> <https://github.com/snapcore/snapd/pull/6865>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6866
<mup> PR #6866: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>
<zyga> I'll review with jdstrand locally
<mup> PR snapd#6863 closed: testutil: support sharing-related mount flags <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6863>
<mup> PR snapd#6866 opened: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>
<zyga> mborzecki: I force pushed because git add -p typo :P
<mup> PR snapd#6858 closed: cmd/snap: unit tests for debug timings <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6858>
<Chipaca> lol of course the only test that failed is the connectivity check
<Chipaca> ogra: nethack 3.6.2 has been out for _ages_ and there's been no snap update! what is this! rabble rabble rabble
<ogra> Chipaca, oh, geez ... thanks for the ping, will update it
<Chipaca> ogra: :-) i wasn't looking for it, i just noticed the news
<ogra> what is it that all of a sudden they make regular releases ? ...
<ogra> one revision per dacade should be enough for everyone !
<Chipaca> ogra: next up: nethack LTS
<ogra> *decade
<Chipaca> pstolowski: is there anything that sets hooksetup.revision? I somehow got it in there at _some_ point which led me to believe it worked, but i can't reproduce that now
<pstolowski> Chipaca: it seems to be only used in tests if looking for all references doesn't lie
<Chipaca> sigh
<mup> PR snapd#6864 closed: cmd/snap-update-ns: fix golint complaints about variable names <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6864>
 * cachio lunch
#snappy 2019-05-14
<mborzecki> morning
<cmatsuoka> mborzecki: integration tests failed for PR #6849
<mup> PR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<mborzecki> cmatsuoka: hey, yes, just restarted the jobs
<cmatsuoka> ah ok
<mborzecki> wish we recorded timestamps before the test, and displayed only the relevant part of the journal log, otherwise it's hard to find out what is the issue when you have to scroll through screens of log output
<mborzecki> cmatsuoka: hm mkfs.ext* seems to truncate the label on input
<cmatsuoka> and this truncation is not on codepoint boundaries, right? or is it codepoint-aware?
<cmatsuoka> my guess was that it would just clip on 16 narrow chars
<zyga> Good morning
<mborzecki> cmatsuoka: heh, so it's bit misleading, dumpe2fs and e2label seem to hide the truncated codepoint
<zyga> Hey mborzecki, cmatsuoka :-)
<mborzecki> cmatsuoka: but udev properties show the whole sequence: ID_FS_LABEL_ENC=abcdabcdabcdabc\xc4
<mborzecki> zyga: hey
<cmatsuoka> good morning zyga
<cmatsuoka> mborzecki: and how does snapd read the label? could it panic on the string conversion or something like that?
<mborzecki> cmatsuoka: so, our problem is reverse, the input is the value that came from gadget yaml, which is valid utf8, then we try to find something under /dev/disk/by-{part}label matching that value, we don't read the labels ourselves
<mborzecki> cmatsuoka: in which case, there would be no match
<zyga> cmatsuoka: I'm in the plenary room in case you're post breakfast
<cmatsuoka> mborzecki: oh ok, we're safe then
<mborzecki> cmatsuoka: yup, i'll ask pstolowski|afk to do antoher pass on the PR too
<cmatsuoka> zyga: ack
<zyga> IT WORKS!
<zyga> mborzecki: remember ausearch
<zyga> mborzecki: so, found another bug there
<mborzecki> zyga: oh?
<zyga> mborzecki: it doesn't show *anything* when apparmor denial is for propagation change
<zyga> mborzecki: mount --make-shared -- nope, _nothing_ in dmesg, nothing in audit log
<mborzecki> zyga: try ausearch -m AVC --debug
<mborzecki> it'll show entries that could not be parsed too
<zyga> mborzecki: nothing
<mborzecki> zyga: unless, there's nothing logged :P
<zyga> maybe deeper LSM bug
<zyga> but man, that drove me crazy yesterday
<zyga> mborzecki: patches coming soon, I need to adjust tests and then shove some of the patches to the earlier branch
<mborzecki> btw, are you certain that's caused by apparmor?
<zyga> mborzecki: yes
<zyga> mborzecki: 100%
<zyga> mborzecki: I'm only editing the apparmor profile
<mborzecki> mhm
<zyga> and now it works, found one last place that lacked the permission
<zyga> mborzecki: haha
<zyga> ausearch uses 100% cpu
<zyga> I think it  failed to parse
<zyga> anyway
<zyga> happy this is solved now
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: can you take another look at https://github.com/snapcore/snapd/pull/6849 ? it changed a bit
<mup> PR #6849: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<pstolowski> k
<mborzecki> pstolowski: thanks for the review
<pstolowski> yw
<mup> PR snapd#6867 opened: gadget: offset-write: fix validation, calculate absolute position <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6867>
<Chipaca> could I get reviews for #6862? the check-health pr is ready to go, but it includes this and is rather big so keeping it lean would be nice
<mup> PR #6862: overlord/hookstate: don't run handler unless hooksup.Always <Created by chipaca> <https://github.com/snapcore/snapd/pull/6862>
<mup> PR snapd#6868 opened: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>
<Chipaca> mborzecki: nice
<mborzecki> Chipaca: it'd be nicer if we didn't have to do that :)
<Chipaca> totes
<mborzecki> Chipaca: noticed we don't really have a spread test for snap services output, so the problem was not caught earlier
<Chipaca> mborzecki: noticed
<Chipaca> Stepping out for a walk and lunch. I'd call it a wunch, but that's the collective noun of 'banker'.
<mborzecki> meh, gofmt 1.10 vs gofmt 1.11 is super annoying
 * pstolowski lunch
<cachio> degville, hey
<degville> cachio: hello!
<mup> PR snapd#6849 closed: many: introduce a gadget helper for locating device matching given structure <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6849>
<mborzecki> off to school, back before standup
<diddledan> @jdstrand I appreciate I took forever and a day to try your suggestions, but we have a successfully working makemkv with some fiddling with the apparmor and udev rules: https://forum.snapcraft.io/t/openat-returning-eperm-for-dev-sg0/10069/15
<zyga> Hey hey
<zyga> mborzecki: found one more bug in the same area
<zyga> The synthetic mount change retention logic is incorrect
<mborzecki> cachio: Fedora-Cloud-Base-30-1.2.x86_64.qcow2 seems to behave just fine, just updated the kernel, was at 5.0.9-301.fc30.x86_64, rebooted and 5.0.13-300.fc30.x86_64 is running now
<cachio> mborzecki, weird
<cachio> I am using http://fedora.c3sl.ufpr.br/linux/releases/30/Cloud/x86_64/images/Fedora-Cloud-Base-30-1.2.x86_64.raw.xz
<cachio> it is the same
<mborzecki> cachio: shuld be the same
<cachio> yes
<mborzecki> cachio: all i'm doing is sudo dnf upgrade -y && sudo reboot
<cachio> I'll need to review if something installed during the image creation is causing this
<mborzecki> pstolowski: idk if you noticed, but tests/main/auto-refresh-retry is failing more often now, usually the last line is:
<mborzecki> May 14 11:30:49 arch nsenter[2289]: retry.go:113: DEBUG: Retrying because of temporary net error (DNS): &net.DNSError{Err:"Temporary failure in name resolution", Name:"api.snapcraft.io", Server:"", IsTimeout:false, IsTemporary:false}
<pstolowski> mborzecki: hmm i saw it once
<mborzecki> cachio: i'm looking at fedora, it's using some bootloader specification now, https://systemd.io/BOOT_LOADER_SPECIFICATION
<cachio> mborzecki, I updated the scripts to create the image
<cachio> mborzecki, I am running now
<Chipaca> mborzecki: nice mess, the volumes thing
<mborzecki> Chipaca: heh ;) maybe the spec is user friendly at least
<mborzecki> for sure it's not parser friendly
<Chipaca> mborzecki: the yaml is very easy to follow
<Chipaca> mborzecki: but even the names of the things in there seem to be designed to conflict with other homonymous things
<Chipaca> anyhoo
 * Chipaca makes tea
<jdstrand> diddledan: ack, thanks! :) I'm sprinting this week and will give it some thought. I've added it to my list for profile additions for 2.40. I too am not sure if it should be a separate interface or not
<diddledan> cool, many thanks :-)
<jdstrand> thank you :)
<Chipaca> brb rebooting
<cachio> mborzecki, it is fixed the issue with the kernel
<cachio> on fedora
<mborzecki> cachio: what was the fix?
<cachio> Initially I was installing kernel-modules with the base image
<cachio> now I am installing kernel modules and kernel core during the update
<cachio> then reboot
<cachio> basically
<cachio> I was installing kernel-modules then doing upgrade then instlaling kernel-core then during upgrade
<cachio> in 2 scripts
<mborzecki> ah
<mborzecki> cachio: so once you push the new image, we can restart the PR with fedora 30
<cachio> now I upgrade, then install the kernel-modules and kernel core and then reboot
<cachio> mborzecki, done
<cachio> thanks for the support
 * cachio lunch
<mup> PR snapd#6865 closed: cmd/snap: allow option descriptions to start with the command <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6865>
#snappy 2019-05-15
<mborzecki> morning
<zyga> good  morning mborzecki
<mborzecki> zyga: hey
<zyga> mborzecki: trying the new atom feature
<mborzecki> zyga: what is it?
<zyga> https://blog.atom.io/2019/05/12/atom-1-37.html
<zyga> it's pretty neat :)
<mborzecki> zyga: interesting
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6856/files
<mup> PR #6856: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>
<zyga> specifically this part https://github.com/snapcore/snapd/pull/6856/files#diff-6e1312a8e6236111d0199b57d496b986R87
<mborzecki> zyga: do we have any helpers in the code to find a mount point given a device/source name?
<mborzecki> oh, well, i'll use LoadMountInfo() then
<mborzecki> off to drop some papers at my accountant's
<pstolowski> mornings
<pstolowski> zyga: hey, you there?
<mborzecki> re
<pstolowski> mborzecki: hey, 6868 can land
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: Chipaca: thanks for the reviews
<mup> PR snapd#6868 closed: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>
<mborzecki> #6860 has some new selinux denials, need to look at those
<mup> PR #6860: tests: running tests on fedora 30 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6860>
<mborzecki> Chipaca: morning, thanks for the reviews!
<Chipaca> mborzecki: niets te danken, or something
<mborzecki> Chipaca: nice :) still remembering some dutch?
<Chipaca> mborzecki: i think 'niets te danken' and 'natuurlijk' are the only bits i remember at this point
<Chipaca> mborzecki: dunno if you saw but i tagged #6868 for 2.39
<mup> PR #6868: systemd: workaround systemctl show quirks on older systemd versions <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6868>
<Chipaca> because it seems to me to be the right combination of safe and important
<mborzecki> Chipaca: great, thanks
<mborzecki> we'll be doing .1 anyway to include zyga's fixes
<Chipaca> yep
<zyga> hey hey
<zyga> my fixes are almost ready, just need to add an instance test
<zyga> I was trying to get to it between sessions
<Chipaca> zyga: is that going to be in a separate pr?
 * mborzecki feels sorry for whoever will review the raw image writer bits 
<Chipaca> mborzecki: could you wrap up your review of #6721 at some point?
<mup> PR #6721: tests: new profiler snap used to track cpu and memory for snapd and snap commands <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6721>
<mborzecki> Chipaca: sure
<mborzecki> Chipaca: all that was missing was +1 :)
<Chipaca> mborzecki: :)
<Chipaca> i'm using my gh.go thing to find low-hanging fruit
<mborzecki> i've restarted travis jobs, last it built was 13 days ago
<Chipaca> might need a re-merge, we'll see
<Chipaca> anyway cazzo has a few housekeeping things to do with his PRs
<Chipaca> cmatsuoka: you around?
<cmatsuoka> Chipaca: hello
<Chipaca> cmatsuoka: hiya! good morning
<cmatsuoka> good morning!
<Chipaca> cmatsuoka: the "RootOnly" flag is now merged, and I don't know what to do with #6679: if that work continues, is it going to start there, or are you going to do it again from scratch?
<mup> PR #6679: many: implement user removal <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/6679>
<Chipaca> cmatsuoka: IOW should I close the PR :)
<Chipaca> RootOnly was only one of the parts of the puzzle that needed solving first
<Chipaca> the other was about classic
<cmatsuoka> Chipaca: I think it will be cleaner to restart from scratch, we can just drop the old PR
<Chipaca> cmatsuoka: ok. I'll close it, unless you want to do so
<cmatsuoka> close it, please
<cmatsuoka> oh, the link is right here, I can close it as well
 * cmatsuoka still sleepy, jet lag
<mup> PR snapd#6679 closed: many: implement user removal <Created by cmatsuoka> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/6679>
<Chipaca> mborzecki: in #6680, when you say 'root only', do you mean _actual_ root only, or is logged-in ok also?
<mup> PR #6680: [RFC] daemon: expose pprof endpoints <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6680>
<mborzecki> Chipaca: hm it's trace & profiling, not sure if anthing sensitive is accessible through the api, it's probably just stacktraces & addresses
<mborzecki> maybe addresses are sensitive ?
<mborzecki> Chipaca: limiting access to uid 0 probably the safest approach
<Chipaca> mborzecki: ok, i included how to do that in my review
<Chipaca> ('s trivial)
<mborzecki> Chipaca: see that now, thanks
<Chipaca> cmatsuoka: I'll be working on the next bit of user thing refactoring, namely making the user thing not be there on classic by default
<Chipaca> cmatsuoka: after that you should be able to work on the removal without issue
<mup> PR snapcraft#2564 opened: remote_build: handle git push in detached head state <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2564>
<mborzecki> going back home
<zyga> Chipaca: that bug? no, all one PR
<zyga> Chipaca: all the propagation fixes are in one PR (still pending because conference)
<Chipaca> zyga: not related to #6866 then?
<mup> PR #6866: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <https://github.com/snapcore/snapd/pull/6866>
<popey_> when is 2.39 out?
<mup> PR snapd#6869 opened: daemon: only allow `users`/`create-users` when not on classic* <Created by chipaca> <https://github.com/snapcore/snapd/pull/6869>
<Chipaca> hmm, that PR looks a little daunting
<Chipaca> popey_: cachio was coordinating with mvo and store people, dunno how that went
<Chipaca> popey_: "asap"
<popey_> ok
<mborzecki> re
<zigford> Anyone familiar with the recent change where snap-seccomp now requires a buildid? Version bumping my Gentoo snapd package and hung up on this.
<Chipaca> zigford: yes
<Chipaca> zigford: we landed a fix for that in master 15 days ago though
<Chipaca> zigford: not sure what you're building
<Chipaca> in particular: #6782
<mup> PR #6782: osutil: use go build-id when no gnu build-id is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6782>
<zigford> Did that make it into 2.39?
 * Chipaca asks git
<Chipaca> zigford: no
<Chipaca> at least, git says no
<zigford> okay, no worries. I'll see if I can just patch in that commit
<Chipaca> k
<Chipaca> zigford: I'll flag mvo to see if we add it to 2.39.1
<zigford> Confirmed by looking in the release .tar.gz that it is not in 2.39
<zigford> I don't know what it takes to use gnu buildid's which is probably why it is not working without that commit on my Gentoo ebuild.
<Chipaca> zigford: I think it's because we got rid of CGO dependencies that would previously allow gnu buildid to be involved
<mborzecki> hm that PR should not be required for snap-seccomp
<mborzecki> zigford: does your snap-seccomp have no buildid?
<zigford> correct. The output when running snap-seccomp: error: cannot get build-id of snap-seccomp: executable does not contain a build ID
<zigford> I mean snap-seccomp version-info
<zigford> It could be the way I'm compiling it too. I'm a bit of a n00b when it comes to golang
<mborzecki> zigford: can you run `file <path-to-snap-seccomp>` ?
<zigford> Certainly appears to have a buildid according to file: snap-seccomp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, Go BuildID=a8kMN841Luo-M1zG6V_w/k1vJUu3M_98NWHHNQyDR/4QcWrWhdOMwMS78nFYhQ/pb96YzBzA9BKT4Mc4AMS, stripped
<mborzecki> interesting, that's only the buildid added by go toolchain
<mborzecki> zigford: when you build the package, can you add -x -v to go build and upload the output somewhere
<mup> PR snapd#6870 opened: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
<zigford> http://zigford.org/build.log
<zigford> might have to search, as that log builds all the bits
<mborzecki> zigford: thanks, so it's using gcc to drive the linking, but somehoow there's no GNU buildid added
<mborzecki> zigford: can you try this `echo 'int main() { return 0; }' | gcc -xc  - && file ./a.out` ?
<zigford> ./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, not stripped
<mborzecki> zigford: right, but it adds gnu buildid automatically on my system
<zigford> Could BuildID's be a compile time option of GCC, ie, On Gentoo, GCC is compiled by my system, and the feature to create buildid's might be disabled
<mborzecki> zigford: maybe some defaults are different, i doubt it would be disabled
<mborzecki> zigford: can you try this: `echo 'int main() { return 0; }' | gcc -xc -Wl,--build-id=sha1 - && file ./a.out` ?
<zigford> ./a.out: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=9fe501acda2e1d8562da2548c42b9361344804f5, not stripped
<mborzecki> zigford: just for the record, what's the version of binutils and gcc?
<zigford> gcc = 8.3.0, binutils = 2.31.1
<thomascm> Hey everyone, is there a way to know if a bug if good for newcomers?
<mborzecki> zigford: can you check if there's --enable-linker-build-id in gcc -v output?
<zigford> alas, it is not
<mborzecki> zigford: right, so the PR that Chipaca linked makes snapd side of things support both GNU build id and Go build id (in case the first one is missing), but that won't be available in 2.39 until 39.1 (?)
<mborzecki> zigford: meanwhile, maybe there's a use flag to enable build-id by default? this is enabled in configure of gcc
<zigford> Yeah, I quickly checked that, but I think I might be able to find another ebuild package the enables it and just plagerize their work :)
<zigford> So, there does not appear to be a use flag for GCC to enable it by default
<Chipaca> thomascm: what do you mean?
<zigford> Many thanks for your assistence in tracking down the issue, mborzecki
<mborzecki> zigford: np, perhaps you could tweak CC/CFLAGS/LDFLAGS to add -Wl,--build-id=sha1
<thomascm> chipaca: well there many bugs in launchpad, and I am not sure where to start, this is the first opensource project that I contribute to...usually someone is assigning me issues :P
<zigford> Great idea. I'll post back here if I get it working
<Chipaca> thomascm: I don't think we've been good at tracking "bitesize" bugs
<Chipaca> we tried to start doing that but it didn't get momentum
<Chipaca> thomascm: are you wanting to contribute to snapd, or to snapcraft?
<Chipaca> pstolowski: what's the "dangerous" thing in the purge pr?
 * Chipaca hugs pstolowski 
<Chipaca> pstolowski: 's good, just one mistake i think
<pstolowski> Chipaca: thanks for catching!
<thomascm> Chipaca: snapd
<Chipaca> thomascm: what do you know? what can you do?
<pstolowski> Chipaca: hmm. i think i will simply pass bool there in the client (+options which will still be expected to be nil as before). don't see any nice way to check if anything-but-purge was passed
<thomascm> chipaca: sorry getting ready to leave for work. I can program in python, php, javascript, and new to golang ... I can handle most task, it just I don't have a lot of time, a few hours a week, so I rather start with smaller issues
<mup> PR snapcraft#2565 opened: requirements: update to requests-toolbelt 0.8.0 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2565>
<cachio> mborzecki, hey
<cachio> mborzecki, there is a problem on fedora 30
<zigford> mborzecki: fixed by adding a parm to go like so: go install --ldflags '-extldflags "-Wl,--build-id=sha1"'
<cachio> I run the suite in a vm and after some tests it is out of space on disk
<cachio> mborzecki, it is weird because du -h says we use 4.5 of 9 GB
<cachio> mborzecki, I created a debug machine if you want to take  a look
<mborzecki> zigford: yup, that should work too
<cachio> I am debugging this as well
<mborzecki> cachio: can you point me to the log?
<cachio> mborzecki, https://paste.ubuntu.com/p/ckqhnFxvFC/
<cachio> mborzecki, this is one from my machine
<dot-tobias> jdstrand / diddledan: Ping re: /dev/shm if you have the time ð  â https://forum.snapcraft.io/t/proposal-add-dev-shm-namespace-to-all-snaps-by-default/5416/5?u=tobias
<diddledan> dot-tobias: have you tried the `browser-support` interface for the dev/shm access?
<dot-tobias> diddledan: Not yet, since I thought using this interfaces prevents publishing on the store without exceptions
<diddledan> you'll need to get approval for automatic connection of the interface if you need it
<diddledan> you can request the store admins to verify and approve/deny the automatic connection by posting in the store-requests category on the forum
<ijohnson> dot-tobias: fwiw the snap you mention in your forum post seems like a browser so it doesn't seem unreasonable to provide browser-support to that snap
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<dot-tobias>  ijohnson: Yep, its a browser ð
<dot-tobias> diddledan: Ok, will try out locally with browser-support instead of preload + desktop launch first. I'm including this snap in a gadget and ran into issues with auto-installing chromium-mir-kiosk with browser-support interface before, but maybe that's resolved
<ijohnson> yeah so requesting browser-support should be fine
<ijohnson> since you're using a kiosk, you may have your snap flagged since it would be a daemon and also use browser-support, which is not automatically allowed but that should be approved eventually
<dot-tobias> diddledan / ijohnson: Just tested if browser-support resolves the shared memory error, but does not seem like it: Still getting âFailed to create shared memory file /WK2SharedMemory.3964029874: Permission deniedâ with browser-support interface connected for my snap.
<ijohnson> dot-tobias: what is the apparmor denial for your snap when you try this?
<dot-tobias> ijohnson: For whatever reason there's no syslog on my Core test machine â¦ Core 18 on PC gadget+kernel
<ijohnson> can you get logs from `journalctl -e --no-pager | grep apparmor | grep DENIED
<dot-tobias> ijohnson: Yup: May 15 12:36:24 localhost kernel: audit: type=1400 audit(1557923784.977:691): apparmor="DENIED" operation="mknod" profile="snap.wpe-webkit-mir-kiosk.browser" name="/dev/shm/WK2SharedMemory.1479971001" pid=29142 comm="cog" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<ijohnson> dot-tobias: hmm that should be allowed: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/browser_support.go#L228
<ijohnson> I assume your snap is a daemon because it's a kiosk, but just to clarify the wpe-webkit-mir-kiosk.browser app is a deamon right/
<ijohnson> ?
<dot-tobias> ijohnson: Correct
<diddledan> that's with sandbox
<diddledan> you either need to specify the sandbox on the interface or disable the webkit sandbox
<ijohnson> ahh yes listen to diddledan
 * ijohnson will be back in a bit
<dot-tobias> diddledan: I'm testing locally with allow-sandbox: true and running into a very stupid problem â¦ how do I specify a list of plugs for an app where one is not a simple list entry but a dict (i.e. browser-support: \n allow-sandbox: true)
<diddledan> specifying interface options is a separate block to the `plugs` on an app:
<diddledan> https://www.irccloud.com/pastebin/LFF8yqR4/
<Chipaca> cachio: standup?
<diddledan> Chipaca: sit down!
<Chipaca> diddledan: dance!
<cachio> Chipaca, OMW
<diddledan> boogy!
<Chipaca> cachio: k
<diddledan> /o/
<diddledan> \o\
<diddledan> \o/
<diddledan> /o\
 * Chipaca assigns bugs to diddledan 
<diddledan> oh damn
<dot-tobias> diddledan: Thanks, works â the /dev/shm error is gone, but for whatever reason WPE can't find libraries that are definitely in the snap (and work fine when using snapcraft-preload + desktop-launch). Need to investigate this more .
<zyga> re
 * dot-tobias waves at zyga
<Chipaca> cachio: there should be a few lines wrt that cycle, listing all the things in the cycle
<Chipaca> cachio: can you pastebin the whole thing?
<Chipaca> systemd will be always killing one of the units in the cycle to break it, but it picks one at random
<cachio> Chipaca, https://paste.ubuntu.com/p/8p3xhCRZTH/
<cachio> Chipaca, random :s
<cachio> that explains why it is happening randomly
<Chipaca> cachio: so it's one of those four things
<Chipaca> three, really, because one is a target
<Chipaca> and two of them are google
<Chipaca> so i guess it's just the one :-)
<cachio> hehehe
<Chipaca> suspect you need to talk with the cloud-init devs
<Chipaca> cachio: this is only on fedora?
<cachio> Chipaca, it is only on fedora 30
<Chipaca> maybe they have a "different" version of something
<Chipaca> cachio: can you compare the unit files for those four things in fedora 30 vs 29, say?
<cachio> Chipaca, yes
<Chipaca> cachio: digo 30 vs 29 so they might be closer than 30 vs 19.04
<cachio> I'll check that
<cachio> ok}
<Chipaca> cachio: OTOH if you're seeing bug reports with this issue for ubuntus, maybe it's known and fixed in cloud-init and just needs updating on fedora
<cachio> Chipaca, the issues reported are with the same error message but different root cause
<Chipaca> cachio: aw
<cachio> systemctl cat cloud-init
<cachio> Chipaca, I'll review the open issues first and compare configuration with f29 and u19.04
<cachio> to see I can find the diff
<Chipaca> k
<Chipaca> pstolowski: OTOH wrt checking whether only Purge is set, go can compare "flat" structs directly, so just checking whether the struct was equal to the empty one or the empty one with just purge set would work
<Chipaca> (and client.SnapOptions is "flat" in this sense)
<pstolowski> hmm indeed
<pstolowski> Chipaca: nah, doesn't work because of Users []string
<Chipaca> o dang
<Chipaca> well
<Chipaca> you could embed the bools and compare that
<Chipaca> but it gets silly
<Chipaca> every other option is not allowed in multi
<Chipaca> so just, go with that
<Chipaca> we'll add support for multi sometime, and it'll be fine
<Chipaca> but there's not a lot of demand so Â¯\_(ã)_/Â¯
<pstolowski> ok
<Chipaca> pstolowski: maybe remove it from multiActionData also :)
<pstolowski> oh yes!
<pstolowski> ty
<mup> PR snapd#6871 opened: gadget: raw/bare strcuture writer and updater <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6871>
<mborzecki> only excuse i have is that tests make up ~70% of the whole thing
<Chipaca> cachio: note #6618 is >this< close to a second +1, there's a suggestion from mvo that's hard to ignore
<mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
<cachio> Chipaca, yes, I'll update that PR today
<cachio> thanks for the heads up
<Chipaca> cachio: ping me when you do (and it's green) so we can land that
<cachio> Chipaca, sure
 * cachio lunch
<Chipaca> ondra: ping
<ondra> Chipaca hey
<ondra> Chipaca what's up?
<Chipaca> ondra: hey
<Chipaca> ondra: looking at your PRs
<Chipaca> ondra: in particular #6691
<mup> PR #6691: boot: move ExtractKernelAssets <Created by kubiko> <https://github.com/snapcore/snapd/pull/6691>
<Chipaca> ondra: it looks abandoned
<ondra> Chipaca no, I just need update test based on mvo's comment
<ondra> Chipaca just did not find time yet :(
<Chipaca> ondra: ah, ok, so i'll review it then
<ondra> Chipaca actually review avahi one pls
<ondra> Chipaca https://github.com/snapcore/snapd/pull/6325
<mup> PR #6325: Allowing avahi-observer/control slots from app snap also on classic <Created by kubiko> <https://github.com/snapcore/snapd/pull/6325>
<Chipaca> ondra: it's got a needs-changes from jdstrand and conflicts
<ondra> Chipaca yeah I did those
<Chipaca> ondra: that means "stay away" in reviewese
<ondra> Chipaca but it based on those changes it was bigger change, so it'd be good to have extra pair of eyes on it
<ondra> Chipaca lol
<Chipaca> ondra: i tried to look at your lk pr, and that looks interesting but it includs 6691 and is rather big to review in a single go
<Chipaca> ondra: what's the status of #6327?
<mup> PR #6327: Allowing sockets under /run/user/0/$SNAP_NAME <Created by kubiko> <https://github.com/snapcore/snapd/pull/6327>
<ondra> Chipaca also more looking for time to rewrite it based on jdstrand comments, but that's last one on my priority list now
<Chipaca> ondra: if it's a rewrite, would it be ok to close it? or is it not a rewrite in that sense
<ondra> Chipaca not in that sense, still same idea, just a bit more clever implementation
<Chipaca> ah well
 * Chipaca goes on down the list
<Chipaca> zyga: for per-user mounts is there something reviewable?
<Chipaca> mborzecki: what should we do with #6708 ?
<mup> PR #6708: packaging/ubuntu: enable PIE hardening flags <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<Chipaca> #6734 could use a second review
<mup> PR #6734: advise-snap: add --dump-db which dumps the command database <Created by shawnl> <https://github.com/snapcore/snapd/pull/6734>
<zyga> Chipaca: Iâm sorry for responding late
<zyga> Not yet
<zyga> Need to sit down tonight
<Chipaca> zyga: no worries, asking only because i was going down the list
#snappy 2019-05-16
<mborzecki> morning
<zyga> Good morning
<mborzecki> brb, new kernel
<mborzecki> and back
<mborzecki> zyga: hey
<zyga> mborzecki: :)
<mup> PR snapd#6866 closed: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6866>
<zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/6856
<mup> PR #6856: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>
<zyga> mborzecki: (thank you for the first one)
<mborzecki> zyga: added a 2.39 label to #6866, or maybe mvo prefers cherry picks
<mup> PR #6866: cmd/snap-update-ns: allow changing mount propagation <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6866>
 * zyga goes through reviews
<zyga> mborzecki: oh, good thinkink, thank you
<zyga> thinking*
<mborzecki> zyga: if you discuss that with mvo, there's 3 PRs that landed and are tagged for 39.1
<zyga> mborzecki: I'll bring it up, he just went to fetch Samuele
<mborzecki> didn't we use to have cloud init in ubuntu core images?
<pstolowski> morning
<mborzecki> pstolowski: hey
<mup> PR snapd#6872 opened: many: backport fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6872>
<zyga> mborzecki: woot, thank you for the backport
<zyga> mborzecki: I will push the fix as soon as we're out of the plenary review cycle
<zyga> mborzecki: we have cloud init in core and core18
<mborzecki> zyga: idk, somehow it does not set up the system on boot
<mup> PR snapcraft#2565 closed: requirements: update to requests-toolbelt 0.8.0 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2565>
<mborzecki> zyga: regular cloud images have a bunch of cloud-init services, i don't see anything in core18 image though
<zyga> mborzecki: hmmmm, that's odd
<zyga> not sure about services but there *should* be some cloud-init for setting up core images in cloud
<mborzecki> zyga: there are units in /lib/systemd/system but they have not been loaded by systemd for some reason
<zyga> mborzecki: presets?
<zyga> maybe something changed?
<mborzecki> zyga: omg, is the virtio support in the kernel, i added cloud init data disk with if=virtio even though had the main image with if=ide :/
<mborzecki> zyga: so it never got 'found' by systemd and cloud init did not start
<zyga> I have a feeling we found this before
<zyga> missing virtio module in core?
<zyga> (kernel)
<mborzecki> zyga: still a mystery why sytemctl list-units --all did not show cloud init services
<pstolowski> degville: hey, wdyt about changing the help message per zyga's suggestion to https://github.com/snapcore/snapd/pull/6870 ?
<mup> PR #6870: cmd/snap, api, snapstate: implement "snap remove --purge" <Created by stolowski> <https://github.com/snapcore/snapd/pull/6870>
<zyga> mborzecki: does systemctl cat show anything?
<Chipaca> pstolowski: Refrain from creating the automatic snapshot?
<Chipaca> pstolowski: i thought that might be less clear, but then i see zyga himself suggested it
<degville> pstolowski: I agree with zyga actually. 'Don't' seems a little informal and maybe not as immediately clear.
<pstolowski> degville: great, ty
<Chipaca> zyga: hey
<Chipaca> zyga: https://forum.snapcraft.io/t/different-seccomp-behaviors-on-amd64-and-pi2-armhf/11370 might be of interest to you
<zyga> Chipaca: hey, thank you, looking now
<Chipaca> zyga: a libseccomp bug? surely you jest
<zyga> Chipaca: not sure but perhaps, perhaps an outcome of the old vs new seccomp stack
<zyga> but I'm just hand-waving, I need to look for real with hw to test
<cwayne> zyga: if only there were a way to reserve a pi2.. :)
<zyga> cwayne: yeah, sadly there's no way ;-)
<zyga> (my vpn creds are back home)
<zyga> but hardware is not the problem, trying to avoid spending too much time during plenary on non-plenary work
<mup> PR snapcraft#2566 opened: kernel plugin: correctly download the os.snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2566>
<dot-tobias> greyback / alan_g: I opened this GH issue re: mir-kiosk startup splash a while ago, short feedback highly appreciated :) https://github.com/MirServer/mir-kiosk/issues/15
<greyback> dot-tobias: gosh sorry, I never noticed that. I'm not sure the splash animation can be disabled by a config, alan_g will know more
<alan_g> In a meeting. I'll respond on the issue asap.
<Chipaca> mborzecki: could you include #6851 in #6872 ?
<mup> PR #6851: cmd/snap: mangle descriptions that have indent > terminal width <Simple ð> <â  Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6851>
<mup> PR #6872: many: backport fixes to 2.39 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6872>
<mborzecki> Chipaca: sure, let me pick that
<Chipaca> mborzecki: and #6853 might also be worthy ( pstolowski ?)
<mup> PR #6853: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helperâ¦ <Simple ð> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6853>
<Chipaca> or is that #6844
<mup> PR #6844: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helpers <Simple ð> <Squash-merge> <â  Critical> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6844>
<Chipaca> anyway, one of those two should probably be in :)
<Chipaca> pstolowski knows more
<pstolowski> Chipaca: https://github.com/snapcore/snapd/pull/6853 was merged to 2.39 branch already
<mup> PR #6853: interfaces: special-case "snapd" in sanitizeSlotReservedForOS* helperâ¦ <Simple ð> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6853>
<pstolowski> if that was the question
<Chipaca> ð
 * zyga needs more tests
<zyga> (we require more spread tests)
<mup> PR snapd#6873 opened: gadget: improve device lookup, add helper for mount point lookup <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6873>
<mborzecki> Chipaca: #6851 is already included, it probably landed sometime between pre and final
<mup> PR #6851: cmd/snap: mangle descriptions that have indent > terminal width <Simple ð> <â  Critical> <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6851>
<Chipaca> mborzecki: thank you
<mborzecki> gadget/device_test.go:325:35: undefined: strings.ReplaceAll waaat?
<Chipaca> mborzecki: strings.Replace(old, new, -1) is ReplaceAll
<Chipaca> mborzecki: too much python over the weekend
<Chipaca> or something
<Chipaca> strings.Replace(s, old, new, -1) actually
<mborzecki> Chipaca: https://godoc.org/strings#ReplaceAll really wish they had a tag with a version this was added in
<Chipaca> mborzecki: or maybe you're getting confused with regexp, which does have a ReplaceAll
<Chipaca> mborzecki: they do
<Chipaca> mborzecki: they've just not used it on that :-|
<mborzecki> Chipaca: i must be hitting those that don't have the tag then :P
<Chipaca> mborzecki: https://golang.org/pkg/strings/#ReplaceAll
<Chipaca> mborzecki: note the right hand side
<mborzecki> Chipaca: aaa
<Chipaca> mborzecki: bbbb
 * Chipaca wins
<mborzecki> Chipaca: still, 1.12 :(
<Chipaca> the -1 thing isn't that terrible :)
<Chipaca> i mean, replaceall is literally
<Chipaca> func ReplaceAll(s, old, new string) string {
<Chipaca> 	return Replace(s, old, new, -1)
<Chipaca> }
<Chipaca> anyhoo, coffee break time
<mborzecki> coffee sounds about right
<Chipaca> ikr
<pstolowski> grr this must be the worst May for years, the weather has been terrible so far
<pstolowski> no signs of summer whatsoever
<zyga> I'm still working on the bugfix for propagation, tests pass as root, fail as  user,  need to investigate more
 * pstolowski lunch
<Chipaca> pstolowski: https://imgur.com/a/8mufe7k
<mup> PR snapd#6862 closed: overlord/hookstate: don't run handler unless hooksup.Always <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6862>
<Chipaca> #6848 ready for reviews
<mup> PR #6848: introduce healthstate, run check-health post-(install/refresh/try/revert) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6848>
<Chipaca> at 800 lines, not for the faint of heart
<Chipaca> (but a lot of those lines are mechanical test changes)
<Chipaca> in that, https://github.com/snapcore/snapd/pull/6848/files#diff-81e36f58e21bdcdeb85d468298d9b17eR93 is for roadmr
<mup> PR #6848: introduce healthstate, run check-health post-(install/refresh/try/revert) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6848>
<roadmr> thanks :)
<roadmr> that is awesome, Chipaca hehe thanks
<pstolowski> re
<pstolowski> Chipaca: i'm envy
<mborzecki> off to pick up the kids
<cachio> mborzecki, hey
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<zyga> re
<zyga> mborzecki: funny thing, my fix makes the root user ok but there's still a bug if you run as test user
<zyga> mborzecki: I'm debugging why, updated the test suite to check it (that's how I found it)
<zyga> Chipaca: can you do 2nd review on https://github.com/snapcore/snapd/pull/6856
<zyga> it's just more tests
<mup> PR #6856: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <https://github.com/snapcore/snapd/pull/6856>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#38
<pstolowski> cachio: hey, how can i run the test from #6859 ?
<mup> PR #6859: tests: new hotplug test executed on ubuntu core  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6859>
<mup> PR snapd#6856 closed: cmd/snap-update-ns: add tests for executeMountProfileUpdate <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6856>
<zyga> mborzecki: thanks!
<zyga> woot, I have very little after that, let me see
<cachio> pstolowski, no yet, I'll try now to register again my key and see if it works
<mborzecki> zyga: nsswitch.conf is a symlink to /etc/authselect/nsswitch.conf now
<zyga> fun
<zyga> I really really know we need to start over with empty /etc
<zyga> this is not something we can fix easily
<zyga> mborzecki: can you report the bug with a good explanation
<zyga> I will discuss locally and we can plan for actions next week
<zyga> it sucks that F30 is just broken :/
<mborzecki> zyga: w8, it was like that in 29 too
<zyga> whaaat?
<mborzecki> zyga: f30: https://paste.ubuntu.com/p/drHz7js6Q5/ running hello-world snap
<zyga> fuuuuuk
<zyga> can you report that as critical please
<zyga> we can discuss options
<zyga> fun week
<mborzecki> let me check if that's new in 2.39 though
<zyga> mborzecki: I think I understand the  bug (older bug) better now
<zyga> if you have some time today I can show you in a call
<zyga> for some brainstorming
<mborzecki> zyga: standup?
<zyga> mborzecki: and if you can, please  send one patch
<zyga> mborzecki: don't mount over /etc symlinks
<zyga> not a security defennse
<zyga> just as OMG BROKEN
<zyga> mborzecki: joining
<cachio> zyga, https://paste.ubuntu.com/p/5fx9fbKMbH/
<cachio> this is the output for findmnt -o+PROPAGATION
<cachio> perhaps it helps
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<cachio> mborzecki, this is the error on the selinux-clean test on fedora 30 https://paste.ubuntu.com/p/PGG4JyXWgN/
<cachio> is it the same you saw
<cachio> ?
<mup> PR snapcraft#2566 closed: kernel plugin: correctly download the os.snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2566>
<mborzecki> cachio: yes
<mborzecki> cachio: unsquashfs is somethign we can fix, nsswitch.conf requires a fix elsewhere
<cachio> so, should we skip that test while the fix is in progress?
<cachio> or it is better to fix it before starting the test for fedora 30
<cachio> sergiusens, hey, which is the best way to delete my default key using snapcraft
<cachio> ?
<zyga> mborzecki: intermediate path is symlink
<zyga> Not the final name
<zyga> We have better mount code in go
<mborzecki> zyga: i was checking the wrong end :/
<zyga> mborzecki: both ends matter
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/6874
<mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
<mborzecki> cachio: this should fix part of the problem ^^
<zyga> looking
<mup> PR snapd#6874 opened: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
<zyga> mborzecki: can you do a small tweak
<cachio> mborzecki, great news!!
<zyga> if anything fails -> die  (unless ENOENT)
<zyga> if lstat works -> remember mode
<zyga> then mode must match (REG or DIR)
<zyga> then mount
<zyga> on unexpected failure die
<zyga> on expected mismatch log
<zyga> mborzecki: does that make sense?
<Chipaca> mborzecki: https://play.golang.org/p/qwiysalqvq1
 * zyga explores and explores...
<cachio> sergiusens, kyrofa, hey, any idea of this https://paste.ubuntu.com/p/PmBdZ7QzkH/
<cachio> pstolowski|afk, hey, still trying to fix the issue I have with my keys, I'll try to push the last fix for tomorrow, sorry for the delay
<cachio> Chipaca, hey, sorry for the delay, I updated the PR 6618
<mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
<Chipaca> cachio: ack. I'll take a look later tonight
<Chipaca> going to have dinner and walk the dog, now
<cachio> Chipaca, thanks
<cachio> hehe, I forget it is so late in uk
<cachio> Chipaca, do you know how to do snap sign with a key which is not hte default?
<cachio> Chipaca, found that
#snappy 2019-05-17
<mborzecki> morning
<zyga> good morning
<zyga> mborzecki: will you be reworking https://github.com/snapcore/snapd/pull/6874/files?
<mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
<mborzecki> zyga: hey, yes
<zyga> cool, thanks!
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6873/reviews
<mup> PR #6873: gadget: improve device lookup, add helper for mount point lookup <Gadget update> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6873>
<mborzecki> zyga: thanks
<zyga> mborzecki: I just pushed https://github.com/zyga/snapd/tree/wip/lp-1828354 (diff https://github.com/snapcore/snapd/compare/master...zyga:wip/lp-1828354?expand=1 )
<zyga> it doesn't nearly pass tests
<zyga> I'm trying to understand which of the fragments of mimic construction breaks sharing
<mborzecki> zyga: updated #6874
<mup> PR #6874: cmd/snap-confine: do not mount over non files/directories <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6874>
<mborzecki> zyga: tagged it for .39.1 too
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: https://news.ycombinator.com/item?id=19929986
<jamesh> zyga: hi.  Do you know if anything came of the "desktop session agent" idea we brainstormed at the last engineering sprint?
<jamesh> zyga: and if the answer is nothing, would it be something worth while for me to work on?
<pstolowski> mborzecki: uhmmm
<pstolowski> mborzecki: they even mention xplane, wow
<mborzecki> pstolowski: so you know, when you put that antenna on your balcony ;)
<Chipaca> interesting read, if you're into that sort of thing: https://songlh.github.io/paper/go-study.pdf
<Chipaca> zyga: i know you probably are ^
<mup> PR snapd#6873 closed: gadget: improve device lookup, add helper for mount point lookup <Gadget update> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6873>
<zyga> jamesh: hey, not 100% sure if that's the topic but I think we agreed to use snap userd a lot more; having said that we're not doing anything towards  that
<zyga> Chipaca: thank you, queued
<jamesh> zyga: this was the idea of having a unix socket activated service in the user session that snapd could talk to
<jamesh> zyga: this could either be userd, but wouldn't necessarily be the same thing.
<zyga> jamesh: note, I'm at a sprint now, partial focus
<jamesh> zyga: ah.
<zyga> jamesh: I think that's the agreement
<zyga> jamesh: I don't think we've ageed on anything byeond the general idea that there's a two way communication between system-wide snapd and per-user "aid"
<jamesh> zyga: okay.  Would it be useful to start adding the infrastructure for the user agent?  From my memory, we discussed socket activated user session service speaking an HTTP API similar to snapd
<zyga> mborzecki: so because that wip  branch I  posted  is arguably huge  and the test there is hard to follow, I'm making a standalone shell script that illustrates the issue so  that we can discuss this properly next week
<zyga> jamesh: I think you need to get an ack from pedronis before you do that
<mborzecki> zyga: ack
<zyga> jamesh: explain that this is going towards bi-directional communication and this is the protocol idea and if you get an ack, work on  it
<zyga> jamesh: I would refrain from proposing thnigs that need design review before there's written agreement on what it is
<jamesh> zyga: okay.  Would the forum be the best place to do  that?
<zyga> jamesh: yes, and a call as  well
<Girtablulu> Chipaca: are you around?
<Chipaca> Girtablulu: yes
<Girtablulu> remember my issue on solus with snapd 2.39 and creating the snapshot by removal?
<Chipaca> Girtablulu: yes
<Chipaca> well, no, but yes
<Chipaca> i didn't remember it was you :-)
<Chipaca> but i remember the issue
<Chipaca> mborzecki: is --prune in 2.39.1?
<cachio> Chipaca, hey, if you want to enjoy  a bit you can take alook to https://github.com/snapcore/spread/pull/77
<mup> PR spread#77: Add testflinger backend <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/77>
<Chipaca> cachio: sure!
<Chipaca> cachio: and i get the impression you asked me to do something last night and i never did :-/
<Girtablulu> well talked to JoshStrobl and he had a look and made this patch https://dev.getsol.us/source/snapd/browse/master/files/0001-Force-usage-of-sudo-over-runuser-on-Solus.patch, and he said we have to look into the util-linux if it's setup wrong on Solus
<cachio> Chipaca, hehehe, it is ok
<cachio> no hurry
<mborzecki> Chipaca: isn't that wip still? pstolowski will know
<Chipaca> mborzecki: i meant purge, and it's not even in master, so yeah
<cachio> Chipaca, I need a final review for #6618
<mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
<Chipaca> Girtablulu: wow
<pstolowski> mborzecki, Chipaca: yes, not even in master, needs Samuele's review
<Chipaca> Girtablulu: thanks for the update! that's very interesting
<Chipaca> pstolowski: yep yep
<Girtablulu> Chipaca: np you said I should come back if a solution is found :)
<Chipaca> Girtablulu: it does sound like something's awry in solus's plumbing, but glad that's getting sorted one way or another
<cachio> pstolowski, hey, yesterday I could make work the user my keys to sing the models
<cachio> but then testing I realized I need to make some changes for core18
<cachio> because the vms are not starting with the user1
<cachio> I'll try to have it working before standup
<Chipaca> cachio: do systems start with numbers in testflinger?
<cachio> Chipaca, no
<cachio> names are alphanumeric
<Chipaca> cachio: the change to validSystem seems bogus then
<cachio> Chipaca, yes, you are right
<cachio> should be something like [a-z]+[0-9]+
<Chipaca> cachio: the * seems intentional also
<Chipaca> which you removed
<Chipaca> but dunno
<cachio> Chipaca, no, because the name enforced has a - between
<Chipaca> ?
<Chipaca> ah
<Chipaca> you mean in testflinger systems can't have -s?
<cachio> I need [a-z]+[0-9]+-[a-z0-9*]
<Chipaca> no you don't :-)
<cachio> Chipaca, the name enforced by default is like
<Chipaca> cachio: what do you actually need? give me examples please
<cachio> rpi-3-64
<cachio> and we need rpi3-64
<cachio> because then we use the rpi3 as name for testflinger
<Chipaca> ah
<cachio> Chipaca, rpi3 is the device name on tf
<Chipaca> cachio: and do you know what systems have an '*' in them?
<Chipaca> wondering what that was there for
<cachio> Chipaca, no idea, I never seen one with *
<Chipaca> let's ask gustavo :)
<cachio> Chipaca, yes :)
<Chipaca> niemeyer: in spread, why does the validSystem regexp allow explicit asterisks in the system name? "^[a-z*]+-[a-z0-9*]+(?:[-.][a-z0-9*]+)*$"
<Chipaca> niemeyer: what's the use case for this? (examples? tests?)
<Chipaca> cachio: in any case what you want is probably "^[a-z][a-z0-9]*-[a-z0-9]+(?:[-.][a-z0-9]+)*$"
<Chipaca> cachio: modulo *s inside the []s pending gustavo's reply
<Chipaca> cachio: that is, changing the [a-z]+ to a [a-z][a-z0-9]*
<Chipaca> meaning there can be numbers in the first chunk as long as it doesn't start with numbers
<cachio> perfect
<Chipaca> cachio: simplest way forwards is to assume the *s are there for a reason, and replacing the [a-z*]+ with [a-z*][a-z0-9*]*
<cachio> change done :)
<niemeyer> Chipaca: Might be a bug depending on where this is used, but systems filtering allows wildcards
<Chipaca> ah! +ubuntu-* etc?
<Chipaca> cachio: there you go :)
<cachio> Chipaca, niemeyer nice
<Chipaca> cachio: so
<cachio> I never tried it :)
<Chipaca> cachio: ^[a-z*][a-z0-9]* instead of ^[a-z*]* and the rest stays the same
<niemeyer> cachio: I'm pretty sure snapd tests depends on this
<Chipaca> of course that means you couldn't say rpi*
<Chipaca> e.g. tests/main/xdg-open/task.yaml:systems: [-ubuntu-core-*]
<Chipaca> cachio: ^
<cachio> niemeyer, we run snapd tests like doing google: that should use the * as wildcard right?
<Chipaca> cachio: it's for the filtering in tasks
<niemeyer> cachio: No, that uses ... because wildcards are special for shells
<Chipaca> cachio: I suspect you forgot to push to snapd#6618
<mup> PR #6618: tests: validates snapd from ppa <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6618>
<cachio> niemeyer, ok, thanks for the explanation
<Chipaca> niemeyer: ditto, thanks
<niemeyer> nps!
<cachio> Chipaca, right, pushing
<cachio> Chipaca, pushed
<pstolowski> cachio: ack, thanks for update!
<cachio> pstolowski, I just pushed the new models I am trygin to make that work
<cachio> pstolowski, to run the test you need to set the variable SPREAD_NEW_CORE_CHANNEL to edge
<pstolowski> cachio: ack, ty, i'll try that
<mborzecki> off to pick up the kids
 * Chipaca lunches
<popey_> how long should a refresh from of core from stable to candidate (2.39) take? It's taking forever here.
<popey_> "snap changes" hasn't returned anything at all.
<popey_> Consider re-refresh of "core"   is all it says in the terminal where I am refreshing core
<popey_> perhaps it's regenerating all apparmor profiles or something?
<popey_> (yes, looks like that's what it's doing, incredibly slowly)
<pstolowski> popey_: possible, ps aux and check for apparmor parser? i just checked and it was almost instant, but i have very few snaps
<popey_> pstolowski: yes, i see a lot of apparmor parser in syslog. i have 260 snaps and this is taking an age and I'm not getting any feedback from the "snap refresh core --candidate" about what's happening
<popey_> if I was a normal person, I would likely have turned my computer off right now
<popey_> (not that a normal person has 260 snaps ofc) :D
<popey_> \o/ finished
<popey_> that was about 20 mins. not bad for 260 snaps :D
<pstolowski> popey_: i agree, no feedback is problematic
<pstolowski> something worth exploring/imrpoving
<pstolowski> bbiab
<jdstrand> popey_: this gets precisely to the snapd team's roadmap item to make this faster (cc zyga). snapd is calling apparmor_parser for *every* interface connect in every snap command rather than once per snap command
<jdstrand> popey_: which makes it particularly terrible for you and as snaps get more popular
<jdstrand> popey_: but, it's known and understood and now marked as a deliverable for the next cycle (last I saw)
<popey_> \o/
<popey_> https://www.youtube.com/watch?v=ZtAzeoA0UgE
<popey_> </spam>
<Chipaca> pstolowski: mborzecki: cachio: standup?
<kenvandine> zyga: is bug 1825883 fixed in 2.39 or is there still some work to do?
<mup> Bug #1825883: stale copy of plug and slot attributes is kept in connection state <snapd:In Progress by zyga> <https://launchpad.net/bugs/1825883>
<Chipaca> mborzecki: i thought for mkfs.extN you could avoid the root/non-root weirdness via root_user
<mup> PR snapcraft#2537 closed: dotnet plugin: fix parsing of newer sdk releases <Created by ianmetcalf> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2537>
<mborzecki> Chipaca: is that an option for mkfs?
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: under extended options
<mborzecki> Chipaca: isn't that the owner of / only?
<Chipaca> mborzecki: what else does it do that needs fakeroot?
<mborzecki> Chipaca: ownership of all entries dropped into the fs, it's basically doing `mkfs.ext.4 <magic-options> -d <rootfs>`
<mborzecki> s/ext.4/ext4/
 * cachio lunch
<mup> Bug #1829558 opened: Unable to install fwupd <Snappy:New> <https://launchpad.net/bugs/1829558>
<zyga> kenvandine: pstolowski|afk did the fix in reduced capacity for 2.29 but I donât remember if that is .0 or .1
<Chipaca> zyga: 29, or 39?
<kenvandine> i'm sure it had to be 39
<Chipaca> kenvandine: I _think_ it's e4c706fb7bf9f19279d54f1ce610ef2bbfaae8b1/b2c48938155f8e05f53843fe718e6f326c0362ec but I can't see that in any tag
<Chipaca> kenvandine: mvo will know for sure
<Chipaca> if i'm right, then not in any tag â not in 2.39; hopefully 2.39.1
<Chipaca> but if you need certainty (heh) ask mvo
<kenvandine> i'll talk to him on monday
<Chipaca> EOW, ttfn
<cachio> pstolowski|afk, I pushed the change in the model to make the nested vms start correctly
<cachio> and other changes
<cachio> the problem is that the qemu is not appearing when doing snap connections system
<cachio> pstolowski|afk, it is easy to reproduce by running: SPREAD_NEW_CORE_CHANNEL=edge spread -debug google-nested:ubuntu-18.04-64:tests/nested/core/hotplug
<cachio> still missing the change to reuse the test script
<cachio> pstolowski|afk, but first I want to make it pass :)
<pstolowski|afk> cachio: thanks, Iâll check it, the symptoms are as if my fix isnât present or was not sufficient
<cachio> pstolowski|afk, when was it merged?
<cachio> it should be on edge
 * cachio afk
#snappy 2019-05-18
<mup> PR snapcraft#2567 opened: remote build: add warning before sending data <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2567>
<monkeystance> ok I downloaded snapd on my systemd distro
<monkeystance> where do I go from here?
#snappy 2020-05-11
<mborzecki> morning
<mup> PR snapd#8636 closed: tests: add dependency needed for next upgrade of bionic <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8636>
<mup> PR snapd#8634 closed: usersession/agent,wrappers: fix races between Shutdown and Serve <Test Robustness> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8634>
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mup> PR snapd#8630 closed: tests: inject snapd from edge into seeds of the image in manual preseed test <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8630>
<mup> PR snapd#8617 closed: tests: new directory used to store the cloud images on gce <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8617>
<mup> PR snapd#8611 closed: tests: not fail when boot dir cannot be determined <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8611>
<pstolowski> morning
<mvo> good morning pstolowski
<mup> PR snapd#8577 closed: secboot,cmd/snap-bootstrap: move initramfs-mounts tpm access to secboot <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8577>
<mvo> mborzecki: there is one comment from ian in 8628, is that still relevant to address? this looks like a fine 2.45 piece
<zyga> o/
<mborzecki> mvo: yes, i'll be pushing a patch there, filepath.Glob() sorts internally but it isn't mentioned in the doc so it's fair to call it an implementation detail and just sort eplxiciltly outside
<zyga> hey guys
<mborzecki> zyga: hey
<mvo> mborzecki: thanks, I want to cherry pick this to 2.45 so I will wait for this update first :9
<mvo> hey zyga
<mborzecki> mvo: updated #8628
<mup> PR #8628: cmd/snap: coldplug auto-import assertions from all removable devices <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8628>
<mvo> mborzecki: thank you
<mborzecki> zyga: something random? https://paste.ubuntu.com/p/V7PhBg73zj/
<zyga> 1;1
<mborzecki> btw. 14.04 deb does not build anymore?
<mborzecki> https://paste.ubuntu.com/p/f4CdkXsVwm/ getting 2020-05-11T07:32:20.0517313Z E: Unable to locate package dbus-user-session on 14.04
<mborzecki> mvo: the ci job in #8628 has finished, please take a look and merge, there's a couple of unrelated failures in the tests
<mup> PR #8628: cmd/snap: coldplug auto-import assertions from all removable devices <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8628>
<mvo> mborzecki: thanks, in a meeting
<zyga> mborzecki: maybe new image?
<zyga> I think it's the new image with a new package preinstalled
<zyga> re
<mborzecki> zyga: we try to install dbus-user-session in prepare, but there's no such package on 14.04 apparently
<zyga> mborzecki: is it on master now
<mborzecki> zyga: yeah, it's on master
<zyga> mborzecki: is that on 14.04?
<zyga> mborzecki: IIRC it only was a factor on 16.04
<zyga> ubuntu-16.04-64
<zyga> the log says 16.04
<zyga> sergio preinstalled that package
<zyga> it landed this morning
<zyga> so we just need a matching test correction
<zyga> the test measures what's the state of our image
<zyga> so that we understand what to do in tests and what to expect
<mborzecki> zyga: i'm confused, which log?
<zyga> ah
<zyga> you said: "something random? ..."
<mborzecki> zyga: that's separate issue :)
<zyga> right
<zyga> yeah, this package does not exist in 14.04
<zyga> we should not try to install it there
<zyga> hmm, didn't this land after a spread run?
<zyga> anyway, both need to be fixed
<mvo> zyga: 8633 is the one that fails in core with the strange ownership, right?
<zyga> mvo: yes
<mvo> zyga: so if I run this in core16 I should see the same failure?
<zyga> mvo: checkout that PR and run core16 spread tests
<zyga> yeah
<mvo> zyga: I wonder if it also fails on qemu, maybe it's really something cloud specific
<zyga> mvo: aaah
<zyga> brilliant idea
<zyga> I'm sure it will be a decisive test for the cloud-init theory
<mvo> zyga: running it now locally here
<zyga> ok, I'll grab one thing from upstairs and look at the thing maciek reported
<zyga> ok
<zyga> let's get to it
<pedronis> #8613 needs a 2nd review and is fairly straightforward
<mup> PR #8613: o/configcore: pass extra options to FileSystemOnlyApply <Created by stolowski> <https://github.com/snapcore/snapd/pull/8613>
<zyga> mborzecki: testing a fix, should be available shortly
<mborzecki> zyga: thanks
<mborzecki> pedronis: mvo: should i start looking into snap repair for uc20 perhaps or the cli bits for recovery systems?
<mup> PR snapd#8637 opened: tests: test adjustments and fixes for recently published images <Created by zyga> <https://github.com/snapcore/snapd/pull/8637>
<zyga> mborzecki: ^
<pedronis> mborzecki: probably reviews
<pedronis> mborzecki: also I think Ian PR can panic in some cases: https://github.com/snapcore/snapd/pull/8635#discussion_r422906005
<mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
<mborzecki> pedronis: ok, let me check that, i can push a fix if needed
<mup> PR snapd#8628 closed: cmd/snap: coldplug auto-import assertions from all removable devices <Squash-merge> <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8628>
<mborzecki> yay
<mvo> mborzecki: thank *you* - and cherry-picked to 2.45
<mborzecki> mvo: anything else we need to do for auto import right now? (aside from little tweaks)
<mvo> mborzecki: I think that's it, this should work now
<mvo> mborzecki: once it's on beta/edge I will ask taipei to test it
<mborzecki> mvo: great, thanks!
<pedronis> we broke 14.04 testing ?
<zyga> pedronis: yes
<zyga> pedronis: fix is up
<pedronis> :/
<zyga> 8637
<zyga> pedronis: I updated https://github.com/snapcore/snapd/pull/8566
<mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<zyga> pedronis: it was merged earlier today https://github.com/snapcore/snapd/pull/8636
<mup> PR #8636: tests: add dependency needed for next upgrade of bionic <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8636>
<pedronis> zyga: again a pulseaudio failure as well: https://pipelines.actions.githubusercontent.com/xS8oSnypZkPEQZqiZgDaRp2kdvQJKbOY08TesHp7E8vn7g4hYR/_apis/pipelines/1/runs/4124/signedlogcontent/31?urlExpires=2020-05-11T09%3A53%3A40.8345409Z&urlSigningMethod=HMACV1&urlSignature=CGXZSIWuB1%2B%2FEaA9iyF9qXEMhUFFa5d0nk8fHPh%2BXic%3D
<zyga> that's interesting, it looks like a real issue, look that within the same test we did interact with pulse already
<pedronis> and also issues with session agent on core16
<zyga> I have an idea about that failure
<zyga> pedronis: is that a random or have you seen this more than once?
<pedronis> is the one when we cannot talk to the socket
<pedronis> but this time is the a different socket not root
<pedronis> read unix @->/run/user/12345/snapd-session-agent.socket: read: connection reset by peer
<zyga> do you think that the agent is crashing or just shutting down at the wrong moment?
<zyga> pedronis: perhaps a debug line would help, something like
<zyga> session-tool -u test journalctl --user
<zyga> brb,
<mborzecki> pedronis: hm perhaps we should error out when trying to request a system action and the system is not yet fully seeded
<mborzecki> pedronis: looking at current code, the 'current' system would also be incorrectly detected in such case
<mborzecki> so any systemLabel == current.Label checks make no sense at all
<pedronis> mborzecki: well, it's complicated
<pedronis> you don't get any run or recover
<pedronis> action
<pedronis> if there's no current I think
<mborzecki> pedronis: yes, that also
<pedronis> it's install that is strange
<pedronis> honestly I think we should just error if you try to install while installing
<pedronis> even if it's the same system
<pedronis> is just a strange request
<mborzecki> maybe just error out early if in install mode
<mborzecki> yeah
<zyga> re
<zyga> pedronis: we could do two things that would have better perception of working
<zyga> 1) if we are already performing an operation that is being requested (.e.g. refresh while refreshing) we could just display the progress instead of failing
<zyga> this sometimes fails when you open gnome software and it tries to refresh snaps but we're already doing that
<zyga> 2) we could perhaps queue a install command if we are in a special state (not seeded, but perhaps other states as well)
<zyga> https://github.com/snapcore/snapd/pull/8637 fixes master and needs a 2nd review
<mup> PR #8637: tests: test adjustments and fixes for recently published images <Created by zyga> <https://github.com/snapcore/snapd/pull/8637>
<pedronis> zyga: this is about mode, not normal snap operations
<zyga> I see
<zyga> so run vs other?
<pedronis> mborzecki: actually, I was confused, we set things into seeded-systems even for the ephemeral ones?
<pedronis> mborzecki: it sounds slightly wrong (in terms of defining what is current)
<zyga> mvo: did your qemu experiment turn up passing or failing?
<mborzecki> pedronis: yes, it's set in mark seeded, which ephemeral does too for itself
<mvo> zyga: it failed but in a different test :( in snap-user-service-socket-activation on uc16
<pedronis> mborzecki: it sounds kind of wrong
<mvo> zyga: sounds like I need to run it again
<zyga> mvo: that's a known warning
<pedronis> mborzecki: we need to think a bit
<zyga> mvo: dit it fail on just that? roughly how many tests did you get throguh?
<zyga> mvo: in GCE I see the failure really quickly
<pedronis> mvo: all kind of snap-user-service tests fail sometimes on UC16
<mborzecki> pedronis: upated #8635
<mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
<pedronis> mborzecki: thx
<mvo> zyga: around ~100, I can run it again on gce
<zyga> mvo: I'm running int on GCE now with some more ideas
<zyga> mvo: but I think this shows it's cloud-init and, presumably, around tests that reboot
<zyga> mvo: the naive workaround I added just fixes one reboot case (the initial reboot)
<zyga> need to think where to put a fix for something that can happen at any time
<zyga> I wonder if we could turn off cloud-init somehow as well, not sure if it should do stuff on core during CI
<pedronis> in which sense? some our CI flows use cloud-init
<zyga> pedronis: it seems that cloud init data in GCE causes creation of an "ubuntu" user with broken home directory
<zyga> but only on core16/18
<zyga> (though only *broken* there, it may be that we create it everywhere0
<pedronis> well, it's easy to know
<pedronis> look what's the user data there
<zyga> at cloud-init data? I'm not deeply familiar with it but I looked that some on Friday and
<zyga> 1) cloud-init.service sets up the password for ubuntu user, so it's likely it is creating it as well (this is evident in the log file)
<zyga> 2) user data contains gustavo's account but I was not able to find the string "ubuntu" there - perhaps I looked at the wrong files as I'm not familiar with cloud-init that much
<pedronis> ok, but I doubt turning it off completely is an option
<zyga> I see
<pedronis> anywway I have no time to help with this atm
<pedronis> zyga: is this breaking some tests directly? or it's breaking some sanity checks?
<zyga> just a sanity check
<zyga> I was wondering where it came from
<pedronis> given all the things we have to fix it, seems it should go in the ignore for now bucket
<zyga> indeed,
<mvo> zyga: running it again in qemu/google on core18, maybe that is more robust
<zyga> ok, the 14.04 issue is gone
<mup> PR snapd#8637 closed: tests: test adjustments and fixes for recently published images <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8637>
<mup> PR snapcraft#3112 opened: spread: remove dead code for lxd setup and add debug prints <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3112>
<mup> PR snapd#8638 opened: tests: do not add pkg dbus-user-session on ubuntu-14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8638>
<mup> PR snapd#8334 closed: many: add core.resiliance.vitality-hint config setting <Needs Samuele review> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8334>
<zyga> mvo: I added a workaround as samuele suggested, I'll rebase on top of the master fixes and pushed
<zyga> mvo: we can return there if we are really bored one day ;-)
<mvo> zyga: heh, maybe what is running already contains this workaround, no failure so far on gce
<mvo> zyga: anyway, I have lunch now
<zyga> oh?!
<zyga> weird
<zyga> I saw this very quickly
<zyga> (before the workaround)
<zyga> on core16 or core18?
<zyga> I kept running core16
<mup> PR snapd#8639 opened: o/cmdstate: handle ignore flag on exec-command tasks (1/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8639>
<zyga> re
<zyga> in the times of home schooling, fixing the printer is a rather important duty :/
<zyga> mvo: we can close https://github.com/snapcore/snapd/pull/8638
<mup> PR #8638: tests: do not add pkg dbus-user-session on ubuntu-14.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8638>
<mup> PR snapd#8572 closed: packaging: add the inhibit directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8572>
<zyga> pedronis: is there a particular name we can settle on in https://github.com/snapcore/snapd/pull/8578
<mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> pedronis: I'd like to do a small pass, update the name, adjust the test as pawel suggested, and be done with it
<pedronis> zyga: so  :   session-tool -u test journalctl --user  gets a permission error about test not being systemd-journal,  and I haven't found an easy way to see the same logs when driving things as root
<zyga> curious, let me look
<zyga> I mean, the whole point of journalctl --user is to look at your own logs
<zyga> was this on core 16?
<pedronis> yes
<zyga> can you paste the entire message if you have it handy
<zyga> I'm looking now
<pedronis> session-tool -u test journalctl --user
<pedronis> Hint: You are currently not seeing messages from other users and the system.
<pedronis>       Users in the 'systemd-journal' group can see all messages. Pass -q to
<pedronis>       turn off this notice.
<pedronis> No journal files were opened due to insufficient permissions.
<zyga> huh, that's very confusing
<zyga> checking what happens under the cover
<zyga> interesting, it could be a permission error on core
<zyga> user logs are in /var/log/journal/*/user-UID@*
<zyga> so presumably part of that path is not available to the test user
<zyga> it could be that we are lacking some basic group ownership
<zyga> oddly all logs are owned by root and systemd-journal group (on classic)
<zyga> I'll check if we can simply create the test user with systemd-journal group to solve it
<pedronis> it's core so groups is readonly, maybe there's a way around that
<zyga> we work around that alreay
<zyga> core has extra setup for it
<zyga> pedronis: trying something like this now
<zyga> https://www.irccloud.com/pastebin/DL4hLdWP/
<mup> PR snapd#8640 opened: wrappers: pass 'disable' flag to StopServices wrapper <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8640>
<mup> PR snapcraft#3108 closed: tools: install wheel in snapcraft-dev <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3108>
<zyga> almost but not quite ;)
<mup> PR snapcraft#3103 closed: python v2 plugin: set path to the interpreter <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3103>
<zyga> pedronis: re, can we settle on the final name for the host-docs proposal? I'd love to have that branch behind us :)
<pedronis> zyga: I made some proposals, nobody gave feedback on them
<zyga> pedronis: I think the word "misc" is probably bet to be avoided
<zyga> so perhaps just system-doc?
<pedronis> no
<pedronis> they are eally not the system docs
<zyga> though I personally perfer the plural because there's more than one document there
<zyga> what do you mean?
<pedronis> they are not the main system doc
<pedronis> the manpages and mayb share/info are
<zyga> I see what you mean
<pedronis> as I said,  the FHS call them miscelleanous documentation, I didn't make that up
<zyga> arguably we could explore providing both info and man pages but I would not expect those to be much use
<zyga> I think FHS naming is not really that great, it's only misc from a mainframe era point of view
<zyga> on my system there are nearly 200MB in /usr/share/doc and only about 50 in both info and man pages
<zyga> pedronis: I was wondering about "system" as well, because it's a dual-purpose word in snap world - it can mean the "system" as as a whole, including the core part of it, or the "host system" when thinking about classic systems with snapd also installed
<pedronis> I made a 2nd proposal as well: system-packages-doc
<zyga> I'm happy with that one, because packages are plural and the "doc" refers to the directory name, not to "documentation" or "documents"
<zyga> if you are okay I can apply that quickly
<mup> PR snapcraft#3105 closed: build provider: clean incompatible build-environments <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3105>
<mup> PR snapcraft#3111 closed: elf: fix parsing of notes after patchelf mangling <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3111>
<mborzecki> cmatsuoka: if you can access the shell after booting in recovery mode and chooser failed to trigger, can you try to obtain the log from snapd.recovery-chooser-trigger.service ?
<cmatsuoka> mborzecki: will do
<mborzecki> cmatsuoka: thanks!
<cmatsuoka> mborzecki: I'll re-image ian's PR because sudo doesn't work in this image
<mup> PR snapd#8638 closed: tests: do not add pkg dbus-user-session on ubuntu-14.04 <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8638>
<mup> PR core-build#59 closed: initramfs: add new handle_writable_defaults() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/59>
<pedronis> mborzecki: this how Pool is going to be used in the end: https://github.com/snapcore/snapd/pull/8569/files#diff-763375e1fe8805703f81dfb94060286f
<mup> PR #8569: o/assertstate,asserts: use bulk refresh to refresh snap-declarations <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8569>
<mup> PR snapd#8641 opened: tests: improve debugging of user session agent tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8641>
<mborzecki> cmatsuoka: chooser seems to start correctly with core20_634.snap, pc_100.snap, pc-kernel_495.snap in recover mode here
<cmatsuoka> mborzecki: did you remaster the kernel?
<mborzecki> cmatsuoka: no, i did not try to repack it
<cmatsuoka> mborzecki: in my tests this situation works too
<cmatsuoka> mborzecki: once you repack the kernel it starts to fail
<cmatsuoka> you don't really need to inject anything or even change the efi
<mup> PR snapd#8642 opened: tests: add dbus-user-session to bionic and reorder package names <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8642>
<cachio> zyga, hey, when you have 5 minutes, could you please take a look to #8642
<mup> PR #8642: tests: add dbus-user-session to bionic and reorder package names <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8642>
<zyga> I'm looking
<zyga> does it affect anything? I mean session-tool already shows 18.04 has this, or is that just because the current image has recommended packages?
<cachio> zyga, I was testing and the images dont have it
<zyga> do you mean the upcoming images?
<cachio> zyga, yes, upcomming https://paste.ubuntu.com/p/PRTDY963dY/
<zyga> ok
<zyga> yeah, looks good
<zyga> pedronis: this should help https://github.com/snapcore/snapd/pull/8641
<mup> PR #8641: tests: improve debugging of user session agent tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8641>
<cachio> zyga, once we have that, I can push the image which will fail with the mount-ns test
<zyga> cachio: sounds good
<cachio> zyga, nice, thanks
 * zyga goes for lunch
<cmatsuoka> mborzecki: https://pastebin.ubuntu.com/p/67KsBSvCP4/
<mborzecki> cmatsuoka: does it reboot?
<mborzecki> hmm
<cmatsuoka> sorry, I didn't wait again
<cmatsuoka> I just rebooted it by hand to get the other log
<cmatsuoka> mborzecki: the other log: https://pastebin.ubuntu.com/p/Gkz77ksFK3/
<mborzecki> cmatsuoka: from what i've seen you need to hold it super long to trigger the chooser in recovery
<cmatsuoka> I press it then the tianocore logo is still on screen, and release it only when the key fingerprints appear
<cmatsuoka> and I got a lot of 1111111111 during the boot messages
<mborzecki> hmm ok i think i know what's going on
<cmatsuoka> ah excellent
<mvo> pstolowski: fwiw I uploaded https://github.com/snapcore/core-build/pull/59 to bionic,xenial so the next kernel rebuild should have support for _writable_defaults
<mup> PR core-build#59: initramfs: add new handle_writable_defaults() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core-build/pull/59>
<pstolowski> mvo: great! thanks!
<mborzecki> cmatsuoka: mvo: looking at the logs here, when system is booting in recovery mode, the trigger watch is started in initramfs (your only chance to trigger the chooser is now!), then once we switch root snapd won't start the trigger monitor since it has `# X-Snapd-Snap: do-not-start`, so there's no chance to trigger it during first boot
<cmatsuoka> mborzecki: but why does it work when you don't repack the kernel snap?
<pedronis> mborzecki: it's a bit unclear why snapd shouldn't start if it's not started already
<pedronis> *start it
<mborzecki> cmatsuoka: idk, if the log can be trusted, the key triggered in < 10s? weird
<cachio> zyga, does it makes sense to have a script which created the github actions workflows based on a cofiguration file?
<zyga> cachio: if we end up editing them a lot, maybe, otherwise I would not bother
<zyga> cachio: depending on how actions evolve I would expect to see unification, not further shattering of the workflow files
<cachio> so it is easy to have a workflow by system
<cachio> and it is easy to restart just 1 system
<zyga> cachio: it's not quite easy becaues the script doesn't matter to github
<zyga> once still has to edit and run the script and commit the result
<zyga> *because
<zyga> I mean, if we find editing those files a burden, sure
<cachio> the idea is to have an script which will create the workflows, the we push that
<cachio> so then we just need to edit the template
<mup> PR snapcraft#3113 opened: colcon: use packages.ros.org/ros2 repository <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3113>
<zyga> cachio: I do understand but did you read what I said above?
<zyga> since it's an additional step it doesn't buy us anything over just editing the script once in a while (you need to commit both the script changes and the actual workflow files)
<cachio> yes, we don't need to edit/update those
<zyga> and I'm not opposed to it in principle but I don't see the need for it either
<cachio> zyga, the idea is to avoid this
<cachio>       matrix:
<cachio>         system:
<cachio>         - ubuntu-14.04-64
<cachio>         - ubuntu-18.04-64
<cachio>         - ubuntu-core-18-64
<cachio>         - debian-9-64
<cachio>         - arch-linux-64
<cachio>         - amazon-linux-2-64
<cachio>         - centos-7-64
<cachio> 1 workflow 1 system
<cachio> does it makes sense?
<cachio> until we are able to restart sytems independently
<zyga> so that's not quite what you described earlier
<zyga> that's a different cahnge
<zyga> the problem here is that now you run unit tests way many more times
<zyga> this will perform differently
<cachio> zyga, we could run unit tests just on some systems
<zyga> then we would run spread if unit tests failed
<zyga> because you cannot have cross-workflow relationships
<cachio> we could use tags for that
<zyga> what kind of tags?
<cachio> in a gce bucket
<zyga> can we do that without doing the script?
<zyga> IIRC mvo has implemented this already, it's under review
<cachio> zyga, I'l take a look
<cachio> that that change, I didn't see that
<mup> PR snapd#8643 opened: wrappers: add RestartServices function and ReloadOrRestart to systemd (3/N) <Services âï¸> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8643>
<mborzecki> cmatsuoka: repacked ekrnel, added some timestamps to the trigger monitor and can't trigger chooser anymore
<zyga> pedronis, jdstrand: updated https://github.com/snapcore/snapd/pull/8578
<mup> PR #8578: interfaces: add host-docs interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> mainly renamed to system-packages-doc
<zyga> pedronis: ha, we have logs from the faliure now
<zyga> *failure
<pedronis> there's no there there
<pedronis> fascinating
<zyga> snap is gone
<zyga> what :D
<zyga> right?
<pedronis> we are probably leaving a mess in the maint script I suppose
<pedronis> and things get confused
<pedronis> wondering why it doesn't affect other systems though
<zyga> I'll get to the bottom of this
<zyga> but I need to do an errand now
<zyga> but it's paying off
<pedronis> ah, no
<pedronis> this is core16
<pedronis> but is saying /snapd
<pedronis> ??
<zyga> ha
<zyga> I have a hunch :D
<zyga> let's see if the log has this
<pedronis> we do have a core16->core18 test
<pedronis> maybe
<pedronis> and leaving stuff around?
<zyga> I bet it's something like that
<pedronis> anyway I suspect we don't quite the right thing with the user services
<pedronis> and cleanup / restore
<zyga> google:ubuntu-core-16-64:tests/core/reboot google:ubuntu-core-16-64:tests/core/remodel google:ubuntu-core-16-64:tests/core/os-release google:ubuntu-core-16-64:tests/core/apt google:ubuntu-core-16-64:tests/core/network-config:system google:ubuntu-core-16-64:tests/core/snap-auto-import-asserts google:ubuntu-core-16-64:tests/core/swapfiles google:ubuntu-core-16-64:tests/core/writablepaths
<zyga> google:ubuntu-core-16-64:tests/core/device-reg google:ubuntu-core-16-64:tests/core/snap-core-fixup google:ubuntu-core-16-64:tests/core/grub-no-unpacked-assets:vmlinuz google:ubuntu-core-16-64:tests/core/snap-set-core-config google:ubuntu-core-16-64:tests/core/grub-no-unpacked-assets:initrdimg google:ubuntu-core-16-64:tests/core/create-user-2 google:ubuntu-core-16-64:tests/core/services
<zyga> google:ubuntu-core-16-64:tests/core/gadget-config-defaults:ssh_oneline google:ubuntu-core-16-64:tests/core/classic-snap16 google:ubuntu-core-16-64:tests/core/gadget-config-defaults:rsyslog google:ubuntu-core-16-64:tests/core/snapd-failover google:ubuntu-core-16-64:tests/core/gadget-update-pc google:ubuntu-core-16-64:tests/regression/lp-1599891 google:ubuntu-core-16-64:tests/main/snap-services
<zyga> google:ubuntu-core-16-64:tests/main/system-usernames-illegal google:ubuntu-core-16-64:tests/main/interfaces-personal-files google:ubuntu-core-16-64:tests/main/services-snapctl google:ubuntu-core-16-64:tests/main/security-dev-input-event-denied google:ubuntu-core-16-64:tests/main/install-remove-multi google:ubuntu-core-16-64:tests/main/auto-aliases google:ubuntu-core-16-64:tests/main/interfaces-content-mkdir-writable:common
<zyga> google:ubuntu-core-16-64:tests/main/snap-user-service-start-on-install + echo '# free space'
<zyga> there's the snapd failover test
<zyga> prime candidate :)
<zyga> pedronis: looking at the failover  test I don't see what removes snapd actually, perhaps it assumes some global cleanup
<zyga> I'll look
<zyga> but _after_ an errand, I'll be late soon
<mborzecki> cmatsuoka: this is so weird, https://paste.ubuntu.com/p/kB7QyDMmrx/ can't trigger this when i remove the firmware from the kernel snap, same when i pass dangerous systemd.debug-shell=1
<pedronis> well, we assume globabl cleanups but probably they don't do the right thin about this services
<pedronis> *these
<zyga> I'm not entirely sure this is really that, it's just a command that fails to find an executable,
<zyga> but we'll find out once we look closer
<pedronis> well it's wrong service file content
<pedronis> for UC16
<cachio> pedronis, do you know is there is a publis user assertion for uc20 beta images?
<zyga> pedronis: but the service file is fixed
<zyga> pedronis: it's just /usr/bin/snap userd --agent
<pedronis> zyga: that's not what the log says
<pedronis> or the .in
<zyga> can you explain?
<zyga> what does the .in file say?
<pedronis> ExecStart=/snap/snapd/x1/usr/bin/snap userd --agent
<pedronis> @bindir@/snap userd --agent
<zyga> that's from the log, I wonder if that's actually true (the first line)
<zyga> I don't recall us rewriting those units
<zyga> but maybe I'm mistaken
<pedronis> we rewrite them for 18
<pedronis> that's why as I said I suspect an interaction between testing snapd on UC16 vs cleanup
<pedronis> logic
<pedronis> but I might be off
<zyga> mmm, I see, I grepped for the snapd.session-agent but I didn't find anything in snapd proper, looking at the test code
<zyga> anyway, it's much more closer to the light now :)
<pedronis> it's the code in wrappers/core18.go
<pedronis> it's very indirect so it's not easy to grep
<pedronis> I think
<zyga> ah, I see it now
<zyga> writeSnapdUserServicesOnCore
<pedronis> yes
<zyga> yeah, it's cleary this
<zyga> this makes me wonder why it got stale, perhap the code is just naive and is happy with any file it finds
<pedronis> I'm not sure we undo
<pedronis> except via the general cleanup
<pedronis> restore
<pedronis> but as I said I'm not sure that code
<pedronis> does things with this files
<mup> PR snapd#8641 closed: tests: improve debugging of user session agent tests <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8641>
<pedronis> the snap-mgmt tests or something need to grow I suppose
<zyga> oh I see
<zyga> when we install snapd this happens
<zyga> we don't have an equivalent call path for "but I want back to core"
<zyga> the core in wrappers is actually pretty smart already
<mup> PR snapd#8559 closed: boot, bootloader: adjust comments, expand tests <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8559>
<zyga> we could fix this with an explicit test changes
<zyga> but I suspect it's also a real bug
<zyga> that would show up in practice
<pedronis> yes, but I'm not sure apt purge snapd
<pedronis> does the right thing
<pedronis> was user services
<pedronis> atm
<pedronis> there's probably a real bug there
<pedronis> *fo ruser services
<zyga> yes, we don't consider user services
<zyga> oh well, so many things
<zyga> I'll run now because I'm already late
<cachio> mvo, you said I should test pending images on cdimage for beta channel
<cachio> mvo, I tried amd64 and didn't work
<cachio> mvo, I should use pending images just for rpi?
<mvo> cachio: thanks! in a meeting right now, please hop into #uc20
 * cachio lunch
<zyga> condensed debug data in case someone wants to figure out how we ought to fix the bug pedronis identified:
<zyga> user session services debug data https://www.irccloud.com/pastebin/Cbp1aJFm/
<zyga> the failover test does indeed corrupt the system
<zyga> it's also possible that many other tests that have similar interactions behave the same way
<zyga> rm /etc/systemd/user/snapd.session-agent.service && systemctl --user cat snapd.session-agent.service is sufficient to work around it
<zyga> but it highlights a deeper bug
 * zyga -> AFK
<mup> PR snapcraft#3101 closed: package repositories: avoid setting up on host when not the target <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3101>
<cachio> zyga, hey
<mup> PR snapd#8642 closed: tests: add dbus-user-session to bionic and reorder package names <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8642>
<cachio> zyga, once you have the fix for the mount ns test I'll promote the failing image
<cachio> zyga, I mean I'll promote the bionic image which fails running mount-ns test
<mup> PR snapd#8613 closed: o/configcore: pass extra options to FileSystemOnlyApply <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8613>
<mup> PR snapcraft#3113 closed: colcon: use packages.ros.org/ros2 repository <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3113>
<mpontillo> hi friends; I noticed today that some of my snaps are out out of date. I thought I was maybe hitting bug #1754345, but logging out and logging in again didn't fix things. any ideas? https://paste.ubuntu.com/p/prCzJTGjnZ/
<mup> Bug #1754345: Returns "invalid credentials" error while trying to refresh an invalid macaroon <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1754345>
<mup> PR snapd#8644 opened: cmd/snap-bootstrap/initramfs-mounts: append uuid to ubuntu-data when decrypting <UC20> <â  Critical> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8644>
<mup> PR snapd#8645 opened: secboot: append uuid to ubuntu-data when decrypting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8645>
<mup> PR snapcraft#3114 opened: npm v2 plugin: update doc string <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3114>
<mup> PR snapcraft#3112 closed: spread: remove dead code for lxd setup and add debug prints <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3112>
<mup> PR snapcraft#3115 opened: build providers: ignore missing LXD instance when cleaning project <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3115>
#snappy 2020-05-12
<mup> PR snapcraft#3115 closed: build providers: ignore missing LXD instance when cleaning project <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3115>
<mpontillo> (I ended up just purging `snapd` and reinstalling it as suggested here - https://forum.snapcraft.io/t/download-snap-core-invalid-credentials/15253/17 - that worked.)
<mup> PR snapd#8645 closed: secboot: append uuid to ubuntu-data when decrypting <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8645>
<mup> PR snapcraft#3116 opened: cli: fix following hints in channel status <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3116>
<mup> Bug #1878131 opened: snapd caused problems in WSL <Snappy:New> <https://launchpad.net/bugs/1878131>
<mup> PR # closed: 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, snapd#8247,
<mup> snapd#8271, snapd#8301, snapd#8317, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8551, snapd#8558, snapd#8564, snapd#8566, snapd#8567, snapd#8568, snapd#8569,
<mup> snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608, snapd#8609, snapd#8612, snapd#8620, snapd#8631, snapd#8632, snapd#8633, snapd#8635, snapd#8639, snapd#8640, snapd#8643, snapd#8644
<mborzecki> morning
<mup> PR # opened: 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, snapd#8247,
<mup> snapd#8271, snapd#8301, snapd#8317, snapd#8340, snapd#8351, snapd#8352, snapd#8366, snapd#8395, snapd#8398, snapd#8400, snapd#8455, snapd#8499, snapd#8508, snapd#8519, snapd#8520, snapd#8521, snapd#8532, snapd#8533, snapd#8551, snapd#8558, snapd#8564, snapd#8566, snapd#8567, snapd#8568, snapd#8569,
<mup> snapd#8570, snapd#8573, snapd#8576, snapd#8578, snapd#8591, snapd#8592, snapd#8604, snapd#8608, snapd#8609, snapd#8612, snapd#8620, snapd#8631, snapd#8632, snapd#8633, snapd#8635, snapd#8639, snapd#8640, snapd#8643, snapd#8644
<mborzecki> mvo: hey
<mvo> mborzecki: good morning!
<mup> PR snapd#8644 closed: cmd/snap-bootstrap/initramfs-mounts: append uuid to ubuntu-data when decrypting <UC20> <â  Critical> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8644>
<mborzecki> mvo: heh, i was wondering yesterday evening how that that problem fixed by ian's PR came up
<mup> PR snapd#8646 opened:  tests: not fail when boot dir cannot be determined (2.45) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8646>
<mvo> mborzecki: could you please check 8632 ? should be trivial :)
<mborzecki> so weird, i can trigger the chooser trigger in recovery initrd, but not in other initrd modes for some reason
<mborzecki> somehow it triggers after 2s instead of 10
<mborzecki> uh, i'm stupid :/
<zyga> Hey
<zyga> Winter is back!
<pstolowski> morning
<mborzecki> zyga: hopefully a couple of days only
<mborzecki> zyga: pstolowski: hey ;)
<zyga> Yeah :-)
<zyga> Hey PaweÅ, any snow?
<mup> PR snapd#8647 opened: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
<mup> PR snapd#8632 closed: configcore: only reload journald if systemd is new enough (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8632>
<mup> PR snapd#8646 closed:  tests: not fail when boot dir cannot be determined (2.45) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8646>
<pstolowski> zyga: snow??
<pstolowski> zyga: no, it's nice and sunny, albeit only 8 C
<pedronis> hello, can somebody double check my commits from yesterday here: https://github.com/snapcore/snapd/pull/7129
<mup> PR #7129: userd: allow setting default-url-scheme-handler <Needs Samuele review> <Created by jwheare> <https://github.com/snapcore/snapd/pull/7129>
<zyga> pedronis: looking
<zyga> pedronis: only one question, but this is not something you changed, just stood out in the new test code
<pedronis> I found slightly odd, but then it's preexisting, always this messages are anyway completely different from the xdg-settings ones
<pedronis> hehe
<pedronis> I also found it slightly odd, but then it's preexisting, also these message are anyway completely different from the xdg-settings ones
<zyga> yeah, let's land it
<zyga> I'll fix the session agent service cleanup problem and carry on with usual stuf
<pedronis> anyway I plan to do a follow up because of the slightly confusing join/split
<pedronis> zyga: mborzecki: fwiw xdg-settings prints its entire help if you give it an invalid setting
<mborzecki> that too
<mborzecki> desktop weirdness
<mborzecki> iirc it's a shell script anyway :P
<zyga> at least it's not inventing a new IPC along the way (see new things now usnig varlink insteadof dbus or other stuff)
<mborzecki> if anyone wants to read up more: https://varlink.org/
<mborzecki> i'm sure we'll go full circle back to corba & orbit at some point
<zyga> mborzecki: hahahah
<zyga> my first non-uni job was corba
<zyga> C++ corba DRM server for a VOD service
<mborzecki> pedronis: wdyt about including the mode in systems response for the current system?
<mborzecki> pedronis: we also have system-info endpoint, where the mode could live too probably
<pedronis> mborzecki: what's the use case?
<mborzecki> pedronis: find out the current mode (specifically adding a spread test that goes through run -> recovery -> run)
<pedronis> ah
<mborzecki> pedronis: btw. can you take a look at https://github.com/snapcore/snapd/pull/8635 ?
<mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
<pedronis> mborzecki: system-info seems the right place
<mborzecki> pedronis: cool, i'll add it there then
<pedronis> mborzecki: system-mode probably
<mborzecki> pedronis: ok
<mborzecki> zyga: google:ubuntu-core-16-64:tests/main/snap-user-service-socket-activation is something you were debugging yesterday?
<mup> PR snapd#7129 closed: userd: allow setting default-url-scheme-handler <Needs Samuele review> <Created by jwheare> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7129>
<zyga> yes, it's debugged, just feeling some back pain so paused working
<zyga> I'll fix it in a few hours
<mborzecki> we should ask Chipaca to update the http snap to core18
<pedronis> mborzecki: yes, I will look at that asap, I was in meeting and have some more
<pedronis> pstolowski: thanks for updating/merging master in the early config PRs, I will look at them as well
<mborzecki> hmm we don't have grub-editenv in core18/core20
<pstolowski> pedronis: sure, ty. i'm  looking at adding a spread test for core20 defaults (now that mvo's initramfs changes landed)
<pstolowski> pedronis: but will likely make a separate PR
<pstolowski> pedronis: nb core18 PR is bound to fail atm, new pc-kernel snap is not yet available and I've just removed my hack from the test
<zyga> it's snowing here
<pedronis> mborzecki: no, that's related to why we added snap debug boot-vars
<pedronis> I think
<mborzecki> errand, back in 1h or so
<pstolowski> i still have no luck with tests/nested/core20/basic, does anyone know if it is expected to work? fails on ssh after mutiple retries
<pstolowski> afair Sergio was working on it and fixedit,  and an initrd change that was causing an issue with nested tests for core20 landed as well
<mborzecki> re
<mup> PR snapd#8648 opened: vendor: update to latest secboot <Created by mvo5> <https://github.com/snapcore/snapd/pull/8648>
<ogra> mvo, is there an ETA for https://github.com/snapcore/snapd/pull/8329 ? (i guess 2.45 ? )
<mup> PR #8329: interfaces: allow raw access to USB printers <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8329>
<mvo> ogra: correct, roughtly 2 weeks away
<mvo> ogra: to hit stable, available in beta already
<ogra> great, thanks !
<mvo> pedronis: are the changes in 8635 good now?
<pedronis> mvo: I haven't looked again, I will in a little bit (finishing lunch)
<mvo> pedronis: no rush, more stuff is pending still :)
<mvo> (but not that much!)
 * mvo also considers lunch
<mborzecki> it'd be so cool to learn spread about making qemu snapshots and be able to save/restore snapshot at a relevant test stage
<mborzecki> s/learn/teach/
<mborzecki> iterating on uc20 tests is so annoying
<pedronis> mborzecki: mvo: done
<mborzecki> pedronis: thanks
<pedronis> mborzecki: reviewed #8647
<mup> PR #8647: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
<ogra> hrm ... my core18 VM just rebooted in the middle of me running through console-conf ... do we do upgrades in the background even though console-conf is up ?
<ogra> GRRRR !
<ogra> and again ... shutdown while creating user (a proper shutdown, not a crash)
<ogra> tird time works now but this is a super annoying user experience
<pedronis> pstolowski: I reviewed #8533
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<cmatsuoka> mborzecki: is it expected/by design that we can't run the chooser if unseal fails?
<mborzecki> cmatsuoka: imo it's not designed to that extent yet, when unsealing fails nothing really happens atm right?
<mborzecki> cmatsuoka: i would expect to reboot to recovery mode and take actions from there
<cmatsuoka> mborzecki: I would expect to be able to drop to a shell in recover mode without host/ubuntu-data mounted
<cmatsuoka> mborzecki: yes, today you stop at the recovery key prompt
<mborzecki> cmatsuoka: yes, so we need changes in initrd and the recovery chooser in recover mode
<mborzecki> none of which is there atm :)
<cmatsuoka> ok, just checking :)
<pedronis> we need to move more responsability to snap-bootstrap to control that
<pedronis> Ian is working on that, but is all post best stuff
<pedronis> s/best/beta/
<cmatsuoka> also the latest beta image is a bit confused about which certificates to use
<pedronis> cmatsuoka: is #8591 ready for review?
<mup> PR #8591: secboot,cmd/snap-bootstrap: add tpm sealing support to secboot <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8591>
<cmatsuoka> pedronis: there's a conflict there, I still didn't merge Ian's uuid change
<cmatsuoka> pedronis: will do that now
<mborzecki> cmatsuoka: about the trigger, i'm stupid really ;) totally forgot that the time you need to hold the key is 2s only (we previously had concerns about even hitting taht long wait in iniramfs)
<cmatsuoka> mborzecki: so the log is reporting what's expected?
<cmatsuoka> mborzecki: and everything is consistent
<mborzecki> cmatsuoka: yes, i think the cause is how long it takes to mount the snaps, and in recover mode your only chance of triggering it is in initramfs, because later when we seed snapd, we never start the trigger monitor service
<cmatsuoka> hmmm
<mborzecki> cmatsuoka: also for recovery mode, there sould be either a respective chooser with a bunch of actions, or something from the command line
<mborzecki> i mean a dedicated thing that does not need to be triggered, because it's already a recovery mode
<cmatsuoka> pedronis: merged and pushed
<pstolowski> pedronis: thank you
<pstolowski> cachio: hey, is tests/nested/core20/basic expected to work or are you working on it?
<pedronis> cmatsuoka: I have a question about the input
<pedronis> commented in the PR
<cmatsuoka> pedronis: thanks, I'll check
<pedronis> sorry, I just updated it, was missing a not
<cachio> pstolowski, hi, let me check
<cmatsuoka> pedronis: yes, I think remodeling is still not ingrained in my mind -- we'll need a different approach there
<cachio> pstolowski, It wotks in my branch, I think it fails in master because the change pushed to fix random generation issues
<cachio> pstolowski, if you could take a quick loook should be great https://github.com/snapcore/snapd/pull/8558
<pedronis> cmatsuoka: can't we fix it now?
<mup> PR #8558: tests: make the nested library usable independently of spread <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8558>
<cmatsuoka> pedronis: working on that
<pedronis> cmatsuoka: it probably need a more complicated input struct
<pedronis> also Chris will need to review this (hopefully more closely)
<cmatsuoka> pedronis: I'm considering having model params containing model, load chains and cmdlines, and having a slice of those inside the seal params
<pedronis> sounds reasonable
<mup> PR snapd#8648 closed: vendor: update to latest secboot <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8648>
<mvo> ijohnson: can I squash merge 8635?
<pstolowski> cachio: wasn't random generator fix supposed to fix this problem?
<pstolowski> cachio: i'll look at your PR
<cachio> pstolowski, no
<cachio> pstolowski, it broke the nested run
<pstolowski> cachio: ah
<cachio> pstolowski, In my branch I fixed all the issues
<mborzecki> shall we land https://github.com/snapcore/snapd/pull/8635 ?
<mup> PR #8635: o/devicestate: support doing system action reboots from recover mode <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8635>
<mvo> mborzecki: yeah, I want to squash it though
<mvo> mborzecki: but yeah, lets do it, it's the last 2.45 PR :)
<mvo> mborzecki: so yeah, let me land it
<mborzecki> mvo: mghm, needs your superpowers
<mborzecki> mvo: failed tests are unrelated
<mvo> mborzecki: thanks, will merge
<mvo> done and cherry-picked
<mvo> yay
<mup> PR snapd#8635 closed: o/devicestate: support doing system action reboots from recover mode <Squash-merge> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8635>
<mup> PR snapcraft#3116 closed: cli: fix following hints in channel status <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3116>
<mborzecki> cachio: can you take a look at the console of machine may121345-800144 for me?
<cachio> mb sure
<cachio> mborzecki, ~
<cachio> mborzecki, https://paste.ubuntu.com/p/PsxkPmwcvy/
<mborzecki> cachio: thx, looks like it's in recover mode now
<cachio> yes
<cachio> it finished
<cachio> mborzecki, you can't connect after that?
<mborzecki> cachio: it rebooted again?
<cachio> mborzecki, no
<mborzecki> cachio: mvo: somehow in the spread test i cannot log into the gcp node with root/password used by spread :/
<mborzecki> (when in recovery0
<mborzecki> tbh spread should probably be better at reporting such errors
<ackk> hi, is there a way to get the "prime/" dir on the host when building with --use-lxd?
<ijohnson> ackk: use `snapcraft try`
<zyga> re
 * zyga is back with coffee 
<ijohnson> mborzecki: I bet it's because the hacks we apply to the image to get install mode to add the right user login bits to work don't get applied in such a way they work for install mode
<zyga> standing desk helps but I had a bad back day :|
 * ijohnson goes to look at that code
<ackk> ijohnson, so, build with --use-lxd, then snapcraft try? or just the latter to build and try?
<ijohnson> ackk: `snapcraft try --use-lxd` or `snapcraft --use-lxd try` I can't remember the correct order of options
<ackk> ijohnson, ah I see, thanks
<ijohnson> (and snapcraft is especially picky about such options for some reason)
<cachio> mborzecki, let me try connecting through serial
<ijohnson> mborzecki: cachio: see https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L378-L380
<mborzecki> ehh
<cachio> ijohnson, ahhhh
<mborzecki> ijohnson: let's see if i can tweak it :P
<ijohnson> I'm wondering if actually an easier way to do this is just to hack the core20 snap instead
<ijohnson> just stick our spread user/pw into the /etc/passwd that's in the core20 snap, then we can get rid of all this nonsense
<cachio> ijohnson, nice find
<ijohnson> or actually perhaps more realistically stick the spread user/pw into the var/lib/extrausers/passwd
<ijohnson> (in the core20 snap)
<ijohnson> though note that if you go the route of just sticking the user into the core20 snap, you still need a way to block spread from connecting via ssh during install mode
<ijohnson> perhaps another hack script which runs during install mode and turns off ssh until run mode
<mvo> mborzecki: in a meeting, let's talk about this in a wee bit, I have an idea
<mvo> mborzecki: I think the problem is that in ephemeral mode we don't have https://github.com/snapcore/snapd/blob/master/tests/lib/prepare.sh#L342 i.e. snapd.spread-tests-run-mode-tweaks.service which overlays the root user
<mborzecki> mvo: yeah, ijohnson suggested the same, i've tweaked it a little to see what will happen now
<mup> PR snapd#8649 opened: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <https://github.com/snapcore/snapd/pull/8649>
<pedronis> that's not urgent but small ^
<pedronis> mvo: it's not easy to place a service in the ephemeral modes though, I suppose we can via hacking the initrd somehow
<mvo> pedronis: yeah
<pedronis> but it seems we have code trying to do this but failing ?
<pedronis> or maybe being confused about how things work?
<mborzecki> and it works, yay
<mup> PR snapcraft#3117 opened: ci: setup release-drafter <project-health> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3117>
<pedronis> pstolowski: related to your naming comments, is this clearer https://github.com/pedronis/snappy/commit/959f89056cb2c5b6903fbdf30ef2159efa56a504 or worse?
<pstolowski> looking
<pstolowski> pedronis: yeah, it's great
<pstolowski> thank you
<pedronis> pstolowski: ok, I'll propose an actual PR then
<pedronis> thx
<pedronis> once the prereq is merged
 * cachio lunch
<pstolowski> ok
<mup> PR snapd#8650 opened: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650>
<mborzecki> ijohnson: mvo: ^^
<ijohnson> nice
<mborzecki> cachio: ^^ also includes a tweak for restoring the seed in uc20 if that's what you had a problem with
<mvo> mborzecki: nice
<mvo> mborzecki: how did you fix the issue of the root login?
<mup> PR snapd#8651 opened: release: 2.45 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8651>
<mborzecki> mvo: the special sauce is applied in run and recovery modes
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/8650/commits/a52172b01bfa470cc10b2687baa6aa8408ba3cc2
<mup> PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650>
<mborzecki> ijohnson: haha, thanks for spotting
<ijohnson> grr typo, meant systems: [ubuntu-core-20-*]
<mvo> mborzecki: oh, nice!
<ijohnson> hopefully I edited it in time
<ijohnson> mborzecki: also what was the problem you found with the http snap ?
<ijohnson> it was sending a POST when it shouldn't have been?
<mborzecki> ijohnson: idk, switched to curl, i could see this in the logs:
<mborzecki> May 12 10:00:26 ubuntu snapd[3346]: daemon.go:313: DEBUG: pid=3407;uid=0;socket=/run/snapd.socket; GET /v2/snaps?snaps=http%2Cjq 901.548Âµs 200
<mborzecki> May 12 10:00:28 ubuntu snapd[3346]: daemon.go:313: DEBUG: pid=3645;uid=0;socket=/run/snapd.socket; POST /v2/systems 93.149Âµs 405
<mborzecki> then the actual response was 405 method not allow and some error from our api
<ijohnson> mborzecki: what `http` command?
<mborzecki> ijohnson: `http snapd:///v2/systems`
<mborzecki> same when i used `snap run http ..`
<ijohnson> hmm
<zyga> sigh
<zyga> our restore is insufficient
<mborzecki> afk for now
<mup> PR snapcraft#3118 opened: plugins: add support for local v2 plugins (core20) <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3118>
<mup> PR snapd#8651 closed: release: 2.45 <Simple ð> <Skip spread> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8651>
<zyga> mvo: the fix for the leaking units is coming along but I need to run some tests to ensure no other tasks are causing this
<mvo> zyga: sure
<zyga> I fixed the management script, packaging and some restore logic
<zyga> but it's easy to trigger and we have many tests that use snapd as a snap
<mup> PR snapcraft#3114 closed: npm v2 plugin: update doc string <documentation> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3114>
<mup> PR snapcraft#3117 closed: ci: setup release-drafter <project-health> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3117>
<cmatsuoka> pedronis: changed the structure of seal key data to allow different sets of cmdline and load chains for different models
<benfrancis> Has anyone else experienced Ubuntu Core suddenly prompting for a password after previously authenticating with SSH using keys?
<mup> PR snapd#8564 closed: asserts: introduce Pool <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8564>
<ogra> benfrancis, disk full or some such ?
<benfrancis> orga: I don't think so, it is otherwise operating normally
<ogra> well, if the key is in place it should never ask for a password
<ogra> especially since we never set one by default in core (on purpose)
<ijohnson> benfrancis: are you sure you didn't type the username wrong? I've done that before and gotten quite confused
<ogra> typoing "ian" ? :)
<mup> PR snapd#8652 opened: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8652>
<benfrancis> ijohnson: Hah! Genius. I forgot this box has a different username to all the others. Thanks for saving my sanity.
<benfrancis> ogra: lol
<ijohnson> hey it's a lot of letters
<ijohnson> 3 > 0 hence there's a non-zero change I type it wrong
<ijohnson> that and my sso username isn't as short as ian :-)
<ogra> :)
<mup> PR snapd#8653 opened: asserts: make clearer that with label we mean a serialized label <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8653>
 * zyga commits some more fixes
<mup> PR snapd#8654 opened: tests: test registration with serial-authority: [generic] <Created by pedronis> <https://github.com/snapcore/snapd/pull/8654>
<zyga> pedronis: quick review https://github.com/snapcore/snapd/pull/8654#pullrequestreview-410339434
<mup> PR #8654: tests: test registration with serial-authority: [generic] <Created by pedronis> <https://github.com/snapcore/snapd/pull/8654>
<pedronis> zyga: it's derived from similar preexisting tests, maybe we should modernize them all
<zyga> yeah, we used this style quite a lot
<zyga> if you suggest good values for --wait and -n I can do a pss
<zyga> *pass
<pedronis> we --maxmins nowadays
<pedronis> as well
<pedronis> anyway probably something for the next days
<mup> PR snapd#8655 opened: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
<zyga> --maxmins?
<zyga> pedronis: https://github.com/snapcore/snapd/pull/8655 those are all the tests that needed fixing for the session agent bug
<mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
<zyga> I have follow ups to improve the packaging
<zyga> and I have some more for test restore but I won't propose is as it needs some more work
<zyga> this is the other part of it
<zyga> https://github.com/snapcore/snapd/pull/8656
<mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<zyga> the rest needs more work and some discussion
<zyga> https://github.com/snapcore/snapd/pull/8655/files is rather mechanical and mundane but will get us a lot fewer failing tests
<mup> PR snapd#8656 opened: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
<zyga> cachio: hey, about that mount-ns test
<zyga> cachio: I don't know if you noticed my comment during the standup
<zyga> cachio: but it would be best if you push a change to use the new image and disables the mount-ns test on ubuntu 18.04
<zyga> cachio: and I can follow-up with a change that re-enables the test
<cachio> zyga, sure
<zyga> cachio: thanks, if you push that I can follow up tomorrow
<cachio> I'll create the pr to disable mount-ns right now
<cachio> zyga, #8657
<zyga> thanks!
<mup> PR #8657: tests: disable mount-ns test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
<mup> PR snapd#8657 opened: tests: disable mount-ns test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
<cachio> I'll merge it once tests pass and then I will promote the new bionic image
<cachio> zyga, thanks f
<zyga> ok
<zyga> ijohnson: could you spare a moment to look at pawel's comment on https://github.com/snapcore/snapd/pull/8633 -- specifically this one: https://github.com/snapcore/snapd/pull/8633#discussion_r423134486
<mup> PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
<ijohnson> zyga: sure let me quick look
<zyga> I'd love to get this merged so that detecting issues (of more than just this kind) os easier
<ijohnson> zyga: the separate PR comment you mean?
<zyga> but perhaps I picked the unlucky first problem :)
<zyga> yes
<ijohnson> mmm
<zyga> I mean, I wonder what to do with /home/ubuntu - I'd be happy to park that for now and focus on more pressing problems
<zyga> but perhaps pawel is right and we should explicitly discuss this
<ijohnson> I guess I'm kinda leaning towards doing this in a separate PR, but that's only if you are not about to immediately work on debugging what is creating those things
<ijohnson> if you are going to work on debugging that very soon, then I'd say let's just merge it and you can debug in a followup
<zyga> I spent some time on it and my best theory is that it's cloud init as it happens in GCE but not in qemu
<ijohnson> ah
<ijohnson> interresting
<zyga> I think the real bug is that /home/ubuntu is root-owned
<zyga> it's late so I'll EOD anyway but I want to attack this early tomorrow and make progress
<pedronis> I'm a bit confused, why I said ignore ubuntu I meant ignore it, not override it
<zyga> pedronis: ignore as in exclude?
<pedronis> well, I asked whether it matters, you said no
<pedronis> so yes, excelude
<pedronis> unless it matters
<pedronis> for actual tests
<ijohnson> actually I agree with pedronis just excluding that dir from the check I think is best for now
<zyga> not for actual tests (at least not yet)
<zyga> ok, I'll do that then
<zyga> I think it only matters to the extent that we should understand our stack and what's going on
<pedronis> also at some point we should really rename some of the *-tool because I really don't expect a thing called invariant-tool to anything but check them
<zyga> happy to sit down and discuss names when you have a moment
<mup> PR snapd#8658 opened: cmd/snap-bootstrap/initramfs-mounts: cosmetic changes in prep for future work <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8658>
<mup> PR snapd#8659 opened: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8659>
<mup> PR snapcraft#3119 opened: elf: fix string format for debug log <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3119>
<teward> any way to disable snap autoupdates for a specific snap?
<TheCowboy> Is there any straightforward workaround to giving a snap app access to a NFS mount? I've tried mounting under /home/$USER without any luck
<oerheks> teward, i find no such option, for a single snap
<teward> any way to do it globally then for all snaps on a given snapd instance?
<oerheks> TheCowboy, see softwarecenter > installed > snapname > settings ?
<oerheks> else reinstall the snap with the --classic option, to escape confinement
<TheCowboy> --classic didn't work, --classic --edge didn't work
<TheCowboy> i don't see it installed in the software center but i installed it via commandline
<TheCowboy> Might this work? https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662552
<mup> Bug #1662552: snaps don't work with NFS home <snapd:Fix Released by zyga> <snapd (Ubuntu):Fix Released> <https://launchpad.net/bugs/1662552>
<oerheks> interesting; " If a user logs in and snapd is restart, NFS support is then enabled." https://forum.snapcraft.io/t/snaps-and-nfs-home/438/23
<oerheks> marq 19
<ijohnson> oerheks: that does not work, you cannot install a strictly confined snap in classic mode
<ijohnson> oerheks: the --classic option is just ignored for strict snaps, it does not let you escape confinement
<oerheks> correct, confinement is not the right word, i meant access to the /home folder
<oerheks> and not knowing which snap.
#snappy 2020-05-13
<mup> Bug #1878307 opened: Consider replacing math/rand with crypto/rand in snapd <crypto> <go> <snapd> <Snappy:New> <https://launchpad.net/bugs/1878307>
<mup> PR snapcraft#3119 closed: elf: fix string format for debug log <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3119>
<mup> PR snapcraft#3120 opened: spread: only run in LXD with the google/multipass provider for repo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3120>
<mborzecki> morning
<pedronis> mborzecki: hi, I have a question in https://github.com/snapcore/snapd/pull/8647
<mup> PR #8647: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
<mborzecki> pedronis: hi, let me see
<mborzecki> pedronis: those are log messages
<pedronis> mborzecki: ok, because Ian suggestion sounded instruction like, I suppose it works for a log too but got me confused
<mup> PR snapd#8647 closed: cmd/snap-bootstrap: tweak recovery trigger log messages <Simple ð> <Skip spread> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8647>
<pedronis> #8649 needs review (it's relatively short)
<mup> PR #8649: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <https://github.com/snapcore/snapd/pull/8649>
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<mup> PR snapd#7728 closed: cmd: implement snap run --explain <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7728>
<pedronis> mvo: hi
<mvo> hey pedronis ! good morning
<mvo> 8652 needs a second review, pretty simple fwiw
<pedronis> mvo: could you land #8653 (it's a follow up to a previous review), it failed on user services issues. You can look at it/tests, it's all renames really.
<mup> PR #8653: asserts: make clearer that with label we mean a serialized label <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8653>
<mvo> pedronis: sure
<mup> PR snapd#8653 closed: asserts: make clearer that with label we mean a serialized label <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8653>
<mvo> pedronis: yeah, just looked at it, this could have been done with skip-skpead even
<mvo> pedronis: anyway, merged :)
<pedronis> mvo: thanks
<zyga> good morning
<mborzecki> zyga: hey
<mvo> good morning zyga
<pstolowski> morning
<mborzecki> and good morning pstolowski
<mvo> hey pstolowski
<pedronis> zyga: hi, #8655 failed differently, it seems the fix as is, is too blunt
<mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
<zyga> I noticed, I think I know why
<zyga> My fix was tailored for core 16 and not generic enough
<zyga> I will have to check
<pedronis> mborzecki: thanks for the reviews, fwiw I pushed this: https://github.com/snapcore/snapd/pull/8649/commits/a98339435069517eb7a2997d4802bf926bc322b7
<mup> PR #8649: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <https://github.com/snapcore/snapd/pull/8649>
<mborzecki> pedronis: thanks!
<zyga> I send a follow up
<pedronis> pstolowski: hi, did you see Dimitri email?  afaict we check for /dev/mem as landmark, do you remember why we need /dev in general ?
<zyga> the problem was that snapd-failover test runs on all systems but only core16 needs the workaround
<zyga> classic systems gain the extra services via snapd.{deb,rpm}
<zyga> core systems, apart from core16, have snapd snap used in general and the services do not need to be removed
<zyga> only core16 is special here
<zyga> let's see if it passes
<zyga> pedronis: I also noticed I need to update the permissions for core20 - the test user does not have journal access there
<zyga> that is a different path so needs special treatment (test user setup on core20)
<pstolowski> pedronis: hi, i've read it just now
<pstolowski> pedronis: right, i'm checking dev/mem among few other things in snap-preseed. i don't remember why anymore, need to run without it to see. i suppose something was failing somewhere, i think there was a reason i added it. will check in a moment
<pedronis> pstolowski: thank you
 * zyga found the missing core20 test user setup 
<mup> PR snapd#8660 opened: tests: test user belongs to systemd-journald, on core20 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8660>
<mborzecki> zyga: some comments under https://github.com/snapcore/snapd/pull/8656
<mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<zyga> thanks!
<zyga> good ideas indeed
 * zyga eagerly checks if https://github.com/snapcore/snapd/pull/8655 is green now
<mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
<zyga> mborzecki: we don't support user-level timers, do we?
<mborzecki> zyga: hm looking at the code, seems like we do
<mborzecki> zyga: and not sure we have a spread test for it either
<zyga> Ah, I understand now
<zyga> Timers bind to apps
<zyga> And apps have scope
<mup> PR snapd#8658 closed: cmd/snap-bootstrap/initramfs-mounts: cosmetic changes in prep for future work <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8658>
<jamesh> zyga: could I trouble you to do another merge for one of the snappy-hub test-snapd-* branches? https://code.launchpad.net/~jamesh/snappy-hub/test-snapd-dbus-service/+merge/383854
<zyga> jamesh: hey
<jamesh> hi
<zyga> sure, in a moment
<zyga> jamesh: done
<jamesh> zyga: thanks!
<clmsy> hi everyone
<clmsy> im in need of some help
<clmsy> im trying to build an image using the ubuntu-image tool, i get this error ubuntu_image.parser.GadgetSpecificationError: `role: system-data` structure must have an implicit label, or 'writable': flasher
<clmsy> ill show you the part related in gadget.yaml
<clmsy> https://pastebin.com/ee2zXpjC
<clmsy> are we not allowed to try rename the writable partition ?
<ogra> clmsy, nope, while this might be different in core20 images, until core18 the existence of a "writable" labeled partition is essential
<ogra> you can add additional ones as you like but there must be one called "writable" that carries the writable bits of the OS
<ogra> oh, and looking at your paste you seem to define two targets for the same thing ... i dount that can work
<ogra> ... and your target: entry is also not properly indented
<clmsy> it was i think pastebin related
<clmsy> the original file is properly indented
<clmsy> hmm
<ogra> is it ?
<ogra> (tabs vs spaces ?)
<ogra> the paste show the other indents just fine
<ogra> *shows
<clmsy> yes it broke when i pasted there and i just hand changed it quickly to look ok :)
<clmsy> yeah i understand the issue, so im not allowed to do what im trying to do
<clmsy> which is trouble
<ogra> what exactly *are* you trying to do ? :)
<ogra> there are probably ways, just not the one you're walking ;)
<clmsy> i would love to know if thats possible because it looks like i just couldnt find a way
<clmsy> can you check pm for a second pretty please
<mup> PR snapd#8247 closed: .travis.yml: enable arm64 again as unstable <Skip spread> <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8247>
<mup> PR snapd#8400 closed: osutil: make the TestWriter() test less racy <Simple ð> <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8400>
<mup> PR snapd#8612 closed: sysconfig: use new _writable_defaults dir to create cloud config <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8612>
<zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/files based on your suggestion
<mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<zyga> I'll add some test code now
<zyga> https://github.com/snapcore/snapd/pull/8655 passed but I think there's still something fishy going on there
<mup> PR #8655: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8655>
<zyga> I wonder if I should merge and see broader results
<zyga> or run some more and try to get it to break
<zyga> mvo: ^ how do you feel about this?
<mborzecki> zyga: thanks, will take a look in a bit
<mvo> zyga: yeah, it seems ok to land this
<zyga> ok
<pedronis> zyga: well, the issue is regularly breaking master so if it's even a partial improvement it would be useful, unless you know it breaks on core != 16
<pedronis> still
<zyga> pedronis: I fixed the thing you noticed, my fault for testing on core-16 only
<pstolowski> pedronis: hey, so /dev/mem is not needed, it was a silly check that /dev under mounted image is not empty, so i'm getting rid of that. what is really needed is loop devices for mounting squashfs. however i just learned after discussing with zyga that lxd needs fuse, but snap-preseed assumes squashfs when mounting snapd/core snap, so that needs fixing. and we clearly need a spread test under lxd, so i'm going to work on one too
<zyga> pedronis: it passed now (but perhaps due to luck)
<pedronis> pstolowski: we still need to emit units for squashfs but use fuse ourselves to be clear. yes sounds we need a spread test indeed
<zyga> I'll merge it and let's see what this brings
<pstolowski> pedronis: yes (about units)
<mup> PR snapd#8655 closed: tests: remove generated session-agent units <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8655>
<pedronis> pstolowski: unless we are making images for lxd itself, at which point we need to think
<pedronis> but it's its own tasks
<pstolowski> pedronis: i see
<pedronis> mvo: sorry about #8400, I did make a proposal, I can try to look at it again when I have a moment
<mup> PR #8400: osutil: make the TestWriter() test less racy <Simple ð> <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8400>
<pedronis> pstolowski: mborzecki: not urgent but when you have a moment #8568 is ready for review, rebased it but I also addressed your initial comment
<mup> PR #8568: asserts: rest of the Pool API <Bulk assert refresh :scroll::scroll::scroll:> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8568>
<zyga> mborzecki: expanded snap-mgmt test and checking what that shows
<zyga> it now covers user services, sockets and timers
<zyga> I need a 2nd review on https://github.com/snapcore/snapd/pull/8566 to make progress on refresh app awareness
<mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<bdx> Hello
<bdx> I am trying to get our slurm snap live
<zyga> hello bdx
<bdx> Z
<bdx> zyga, hello!
<bdx> can you aid me in getting this snap live ? I feel like Iâm spinning my wheels trying to Communicate about this through discourse
<bdx> i need auto connect granted for physical-memory-control and network-control for slurm
<bdx> as well as the capability to push to the snap store
<bdx> Zyga , is there anyway we can take care of this now?
<zyga> bdx: hey, I cannot grant such permissions
<zyga> you can make your snap live without them at any time, it's entirely up to you
<bdx> dah, ok
<zyga> as for the auto connect, you must follow the process on the forum
<bdx> I canât though ... the store wonât let me publish it ... telling me that I need approval
<zyga> there's usually a small queue but I cannot speak about that as I'm not directly involved in the process
<bdx> I see
<zyga> bdx: what's the store message?
<zyga> perhaps your snap is stuck in manual review
<bdx> I think it may be
<zyga> physcical memory control is a privileged interface
<zyga> so probably that's why
<bdx> I see
<zyga> do you really need it? Just checking
<zyga> it's rarely required
<bdx> I mean ... is this usually what it takes? Lol
<zyga> ?
<zyga> I'm not familiar with your snap, can you explain?
<bdx> yeah we do , slurmrestd tryâs to allocate memory for its endpoints ... it fails with cannot allocate errors without the physical-memory-control
<zyga> you don't need physical-memory-control to allocate memory
<zyga> do you explicitly need to write to /dev/mem?
<bdx> Yes
<zyga> (forgive me if I misunderstand what slur is doing, I never heard about it before)
<zyga> *slurm
<bdx> slurm is a workload manager for HPC
<bdx> https://slurm.schedmd.com/
 * pstolowski lunch
<bdx> slurm is the software that many enterprise organizations use to run their hpc workloads
<bdx> we are trying to deliver this software to one of the enterprises
<bdx> and many more in the furure
<zyga> bdx: are you following the forum process for permission access?
<bdx> by requesting it via discourse? yea
<bdx> is there something else I should be doing?
<zyga> I think only clarifying how the interface permissions are required for the application and then waiting
<bdx> got it
<zyga> and using the right forum category
<bdx> awesome
<mborzecki> bdx: and also the right people should be coming online in a couple of hours i believe
<zyga> bdx: btw, can you feed my curiosity please, how is /dev/mem used by your application?
<mup> PR snapcraft#3120 closed: spread: only run in LXD with the google/multipass provider for repo <tooling> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3120>
<zyga> mborzecki: I found a funny/weird bug
<zyga> mborzecki: well, probably a feature actually :)
<bdx> zyga, are you saying I should repost my original post ?
<zyga> snap names matter more than file names :D
<zyga> bdx: if you have a link I'll gladly read it
<zyga> bdx: I'm just curious,
<zyga> never had to use /dev/mem in my work before
<bdx> https://forum.snapcraft.io/t/slurm-snap/15595/6
<mborzecki> bdx: also, /dev/mem access can be limited by other factors that aren't snap related, such as kernel config, iirc core for instance has strict devmem enabled
<pedronis> pstolowski: sounds we might not need to work on supporting fuse immediately, we should unblock the other thing so they can try further
<zyga> bdx: that thread does not explain why specific permissions are required, it might help to explain to the reviewers what the use case is
<bdx> got it
<mup> PR snapd#8661 opened: configcore: add "system.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<mup> PR snapd#8662 opened: tests: run core/snap-set-core-config on uc20 too <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8662>
<zyga> bdx: I responded on the forum
<pedronis> mvo: what's the status of #8531 ?
<mup> PR #8531: secboot,cmd/snap-bootstrap: add model to pcr protection profile <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8531>
<pedronis> oops, not that one
<pedronis> mvo: I meand #8351
<mup> PR #8351: config: apply vitality-hint immediately when the config changes <Created by mvo5> <https://github.com/snapcore/snapd/pull/8351>
<bdx> zyga, thanks
<bdx> I catching the errors produced by not having the physical-memory-control plug created
<bdx> https://paste.ubuntu.com/p/D2BVBkwyyj/
<bdx> ^ the big one
<zyga> bdx: can you please provide apparmor denials instead, or a line number in that file where I should look specifically if that's easier
<mvo> pedronis: should be ok to review, it has one known wart about the reload/restart iirc but maybe okay, it's not terrible
<pedronis> mvo: ok, I'll try to look at it when I have a moment
<mvo> pedronis: thank you
<pedronis> mvo: it's probably a good idea to do a master merge as well
<mvo> pedronis: I can double check after lunch if you prefer
<mvo> pedronis: good point
<pedronis> it doesn't have conflict but things might have changed in that area
<mvo> pedronis: yeah, actually let me write one or two more unit tests, I see that the "merging" of old and new is in parts only covered by spread so I think it makes sense to add something more unit-testish first
 * mvo lunches first though
<zyga> hmm
<zyga> something weird is going on
 * zyga investigates
<pedronis> zyga: I reviewed #8578
<mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> pedronis: thanks, looking
<bdx> zyga, yeah that is the strange thing, nothing is showing up in dmesg
<bdx> that link was the incorrect traceback - my apologies
<bdx> I'm working on regenerating the error now
<bdx> I'll post it discourse here shortly when I figure it out, thanks
<zyga> thanks bdx
<mborzecki> meh, running uc20 spread tests is so sloooow
 * zyga ran into a shell trap
<zyga> shell never ceases to surprise
<mborzecki> zyga: surprise in the worst sense i guess ;)
<zyga> smurf gift box surprise
<ijohnson> morning folks
<mborzecki> ijohnson: good morning
<ijohnson> hey mborzecki
<zyga> hey Ian, how are you?
<ijohnson> doing fine mostly, how bout yourself?
 * ijohnson -> coffee
<zyga> ijohnson: yeah, feeling better, my back is not so bad today
<mup> PR snapcraft#3121 opened: spread tests: improvements for python-hello-with-stage-package-dep <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3121>
<mup> PR snapd#8662 closed: tests: run core/snap-set-core-config on uc20 too <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8662>
<zyga> cachio: the label was set later, after the PR was opened, perhaps that is relevant
<cachio> zyga, but I restarted all the jobs
<cachio> and it is running again the tests
<zyga> yes, but perhaps that's not how it works
<zyga> we definitely used this label with workflows
<cachio> zyga, ok
<cachio> it is ok in that case
<cachio> I'll wait until tests finish to merge it and publish the new bionic image
<cachio> zyga, I'll ping you once it is ready
<zyga> sure
<Psil0Cybin> morning yall, question since this is kind of just opinionated > what or why does certain software only have to be downloaded from snap.d?
<Psil0Cybin> and why does snap.d have a daemon? actually wait let me see if they have a channel
<zyga> Psil0Cybin: hello, we call it "snapd", there's a daemon because it has an API layer that various things talk to
<Psil0Cybin> gotchya so this daemon has to always be on?
<Psil0Cybin> I am just confused becuase only 1 piece of software I use is offered only via snapd,. but not from tar.gz and im just trying to understand what snappy really is
<Psil0Cybin> or snapd..is it a new aged marketplace for all linux distro?
<zyga> it's a packaging manager that's quite different from classic packaging systems
<Psil0Cybin> as I am just interested why i need to get snapd, before my application and what benefit would this have for me in the future?
<Psil0Cybin> okay, is it safe to use at the moment?
<Psil0Cybin> could it cause flaws in my system by installing and having the daemon always run?
<Psil0Cybin> since its "constantly" communicating?
<zyga> it's not what you say as it's not constantly but we try to be very careful and we have a good security track record
<zyga> pstolowski: can you do a 2nd review for a trivial test change: https://github.com/snapcore/snapd/pull/8660
<mup> PR #8660: tests: test user belongs to systemd-journald, on core20 <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8660>
<zyga> Psil0Cybin: software developers who make applications decide how they are distributed, please ask the makers of whatever the application you were interested in for their particular motivations - snapd is much easier to package software for, compared to traditional packages, and it also allows the same package to work in many environments
<zyga> good luck :)
<zyga> degville: could you please look at a one-sentence change that needs some improvement here https://github.com/snapcore/snapd/pull/8578#discussion_r424371602
<mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> once I have a suggestion I'll adjust it and that branch will be good to go
<degville> zyga: will do!
<zyga> thank you :)
<mborzecki> cachio: about spread tag in https://github.com/snapcore/snapd/pull/8657 the tag was added later, from what i've seen, with gh actions, you need to add the tag when creating the PR
<mup> PR #8657: tests: disable mount-ns test <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
<mborzecki> cachio: otherwise the tag info is not present in the gh even that gets evaluated as action context
<mborzecki> maybe we should restore the old way, the current setup is bit inflexible
<cachio> mborzecki, ah, nice, thanks for the explanation
<zyga> mborzecki: hehe, found a bug
<zyga> - Make snap "test-snapd-user-service" (unset) available to the system ([--user --global --root / enable snap.test-snapd-user-service.test-snapd-user-service.service] failed with exit status 1: Operation failed: Invalid argument
<zyga> 2980
<zyga> mborzecki: user services do not operate on 14.04 at all
<zyga> and installing snaps fails
<zyga> mvo, pedronis: ^ advice on what we should do, refuse to install early on?
<mborzecki> we have a systemd version check now too
<zyga> mborzecki: what do you men about "restore the old way?"
<Psil0Cybin> zyga, thanks just wanted some input
<Psil0Cybin> was i am intersted in snapd, and this is the first time i heard of it
<zyga> Psil0Cybin: sure
<Psil0Cybin> from the software.
<Psil0Cybin> so thank you for your oppnions. :)
<zyga> Psil0Cybin: you can read the source code for snapd, it's up on github.com/snapcore/snapd
<mborzecki> zyga: do the check in the job code by poking the PR url instead of getting gh actions engine evaluate the conditions itself
<zyga> ah, I see
<zyga> maybe it's a bug, worth asking about it
<zyga> I kind of like this way more than the old version
<mborzecki> zyga: i suppose the context that the job gets is what was set/present at the time the PR got created, so not a bug per se
<Psil0Cybin> thank you zyga.
<Psil0Cybin> you have more peaked my interest.
<zyga> mborzecki: it depends on perception, I'm sure that's how it is implemented though
 * zyga breaks for lunch and bike ride 
<zyga> I'll adjust the postrm test not to install snaps that require 16.04+ systemd
<zyga> but we should probably fix this so that it fails at installation stage
<zyga> I'll send some code towards that later tonight
<mup> PR snapd#8660 closed: tests: test user belongs to systemd-journald, on core20 <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8660>
<pedronis> zyga: that's known (14.04 not working), we just need to have a reasonable and if possible early message
<pedronis> we'll talk with jamesh tomorrow
<zyga> +1
<pedronis> mborzecki: mvo: I asked a question in #8661, bit confused
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<mborzecki> pedronis: yeah, double checking this now
<mborzecki> pedronis: so i can invoke the chooser after completing console conf & rebooting, but after a reboot /var/lib/console-conf/complete does not exist (even though i get the right prompt)
<pedronis> it's all a bit confusing :)
<pedronis> did we change the wrapper? what writes /complete
<mborzecki> pedronis: iow, when there's /var/lib/console-conf/complete it actually indicates that console conf should not run and getty@ starts instead
<mborzecki> pedronis: but without the file consoel conf starts, but presents the login details here: https://github.com/CanonicalLtd/subiquity/blob/master/bin/console-conf-wrapper#L33-L68 and block getty from starting
<mborzecki> and wow it's a hack :)
<mborzecki> pedronis: yeah, i've created /var/lib/console-conf/complete and we directly get getty instead
<mup> PR snapd#8657 closed: tests: disable mount-ns test <Skip spread> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8657>
<mborzecki> pedronis: mvo: we should that condition from the unit file and instead handle it directly in the code after we had a chance to invoke the chooser
<mborzecki> afk for a bit
<pedronis> mborzecki: yes, sounds we need to do something like that
<ijohnson> stgraber: hey how well is lxd's cross-distro support? would you expect it to be able to launch containers on all supported snapd arches on the following distros: debian 9, debian sid, fedora 30, 31, arch linux, centos 7 and centos 8 and maybe even amazon linux ?
<mvo> mborzecki: thanks, commented in #8661
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<zyga> ijohnson: don't forget fedora 32
<ijohnson> oh do we support that now too?
<ijohnson> I was just going off what we have spread.yaml for systems
<zyga> ijohnson: we ought to
<zyga> we should stop supporting f30 as f32 is the current one and f31 will be out of support soon
<ijohnson> thanks zyga, so stgraber same question, just minus fedora 30 and add fedora 32
<zyga> :)
<zyga> yeah, that's a great question ijohnson
<zyga> it's about what a product, shipped as a snap, officially supports
<zyga> products vs services
<ijohnson> I'm sure it's probably documented somewhere I just didn't find it in about 60 seconds of googling so I figured I'd ask instead
<zyga> ijohnson: I would not be surprised if it was a mental transition that we've yet have to do
<zyga> as snaps can be consumed on !ubuntu just as easily
<mup> Bug #1878374 opened: UC20 stuck at installing system on some Intel NUC systems with nvme <bot-comment> <core20> <snapd:New> <Snappy:Incomplete> <https://launchpad.net/bugs/1878374>
<stgraber> ijohnson: yes
<ijohnson> perfect thank you stgraber
<stgraber> We test on most of those too
<mup> PR snapd#8663 opened: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8663>
<mup> PR snapd#8664 opened: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.45 <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8664>
<mup> PR snapd#8665 opened: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.44 <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8665>
<jdstrand> mvo: fyi, I noticed with snapd 2.44.5 a lot of log noise due to ^
<jdstrand> mvo: I don't know if you are cutting another 2.44 (I see 2.44.5 is in candidate, not release), but you might want to pick that up
<cachio> zyga, the new bionic image is already promoted
<mvo> jdstrand: will fix
<mvo> jdstrand: thank you!
<mvo> jdstrand: thanks for this
<zyga> cachio: excellent
<zyga> cachio: looking now
<cachio> zyga, thanks
<mup> PR snapd#8649 closed: usersession,tests: clean ups for userd/settings.go and move xdgopenproxy under usersession <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8649>
<jdstrand> mvo: np
<jdstrand> mvo, zyga: fyi, still executing the "What's Jamie up to..." plan. I should move to step 4 this tomorrow/friday (PR reviews)
<zyga> jdstrand: ok, I don't have much for you now, perhaps just the new interface PR
<zyga> jdstrand: more will come next week
<zyga> jdstrand: (the one with /usr/share/doc)
<jdstrand> mvo: step 5 (2.45 policy updates) isn't until after that, but I thought this denial was important to do fast
 * jdstrand nods
<mvo> jdstrand: I hope we don't need another 2.44, especially since libseccomp is not quite ready so we may as well fix it as part of 2.45
<jdstrand> mvo: I'll leave that up to you. I'm seeing this with 2.44.5 and can say there is a lot of noise that will only get worse as people start to install snaps that use icon sets
<jdstrand> mvo: but how that weighs against the existing testing for 2.44.5 in candidate, I can't really say
<jdstrand> but, you have the info :)
<mvo> jdstrand: 2.44.5 is build against the libseccomp with the regression so that is a nono, it will at least need a rebuild. but aiui there is no fixed libseccomp yet so I'm leaning towards skipping it and moving to 2.45, the "only" reason it exists is the libseccomp fix on armhf
<jdstrand> mvo: I sponsored an update from amurray to groovy for libseccomp that can be cherrypicked while the SRU is in progress. the ~uc1 libseccomp in the image ppa has 2.4.3 with the fix and should not have the regression
<jdstrand> mvo: again, as fyi for any decisions you might make
<jdstrand> mvo: (dimitri uploaded that ~8 hours ago to the image ppa)
<jdstrand> mvo: anyway, I'm not trying to convince you of anything. having it in 2.45 is great. just want you to have all the info
<mborzecki> pedronis: mvo: perhaps we should use /quit
<mborzecki> pedronis: sorry for the nice, had unfinished line in the buffer :)
<mvo> jdstrand: yep, much appreciated :)
<mup> PR snapd#8666 opened: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <https://github.com/snapcore/snapd/pull/8666>
<zyga> cachio: ^
<cachio> zyga, nice thanks!!
<zyga> errand 1h now, I'll send more fixes to my branches later
<zyga> o/
 * cachio afk -> doc app
<mup> Bug #1878307 changed: Consider replacing math/rand with crypto/rand in snapd <crypto> <go> <snapd> <Snappy:Opinion> <https://launchpad.net/bugs/1878307>
<zyga> re
<zyga> so cold but pretty outside
<zyga> ijohnson: if you have a moment, needs 2nd review, test update for UEFI boot https://github.com/snapcore/snapd/pull/8666
<mup> PR #8666: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <https://github.com/snapcore/snapd/pull/8666>
<ijohnson> zyga: sure will look now
<zyga> thanks, just merge it if you are okay with it
<ijohnson> sure, it is all green amazingly
<zyga> right? :D
<mup> PR snapd#8666 closed: tests/mount-ns: update to reflect new UEFI boot mode <Created by zyga> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8666>
<mup> PR snapcraft#3121 closed: spread tests: improvements for python-hello-with-stage-package-dep <bug> <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3121>
<mup> PR snapcraft#3122 opened: pluginhandler: make the build environment available to all steps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3122>
#snappy 2020-05-14
<mborzecki> morninb
<mborzecki> morning
<mborzecki> mvo: good morning
<mvo> mborzecki: good morning
<mborzecki> mvo: do we need https://github.com/CanonicalLtd/subiquity/pull/770 and https://github.com/snapcore/snapd/pull/8661 for beta?
<mup> PR CanonicalLtd/subiquity#770: console-conf: always run when triggered for the chooser <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/770>
<mup> PR #8661: configcore: add "service.console-conf.disable" config option <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8661>
<mvo> mborzecki: it's not beta critical
<mvo> mborzecki: I will not even backport it :)
<mborzecki> mvo: ah ok
<zyga> Good morning
<mborzecki> zyga: hey
<mvo> hey zyga
<pstolowski> morning
<ackk> good morning, I'm seeing a weird behavior with a core20-based snap. If I call the snapraft-runner script in a configure hook, it segfaults
<ackk> it worked fine with core18
<mborzecki> pstolowski: hey
<ackk> oh, actually I might know what's the issue
<ackk> have snap hook always been duplicated in snap/hooks and meta/hooks ?
<mborzecki> hmm google:ubuntu-18.04-64:tests/main/mount-ns:reboot failing?
<zyga> mborzecki: how?
<mborzecki> zyga: https://paste.ubuntu.com/p/NSHS5rHk34/
<mborzecki> look slike / is moutned with different options and efivars is present
<zyga> Are you up to date in relation to master?
<zyga> This changed yesterday to match the new image
<mborzecki> ah ok, i need to update tht branch then
<zyga> ackk: hooks must be in meta/hooks
<zyga> Perhaps snapcraft is copying them?
<ackk> zyga, yeah I mean you put them in snap/hooks for snpcraft to find them right?
<zyga> I donât really know, 90% of my snaps are hand made
<ackk> heh
<ackk> ah yeah, it seems they've always been in both places.
<ackk> maybe snapcraft could not populate snap/hooks?
<zyga> That does seem weird
<mup> PR snapd#8667 opened: interfaces/fwupd: allow bind mount to /boot related on core <Created by woodrow-shen> <https://github.com/snapcore/snapd/pull/8667>
<ackk> zyga, IIUC snapcraft copies snap/ as-is, with the exception of snap/local
<mup> PR snapd#8663 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8663>
<mup> PR snapd#8664 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.45 <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8664>
<mup> PR snapd#8665 closed: interfaces/desktop: silence more /var/lib/snapd/desktop/icons denials - 2.44 <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8665>
<pstolowski> xnox: hey
<ackk> mvo, hi, to confirm, there's currently no way via sudo/su to drop from root the snap_daemon user, right?
<mvo> ackk: hey, not sure I understand the question, can you please give me a little bit more context? what do you want to archive exactly. you are root and drop to the snap daemon-user inside the snap?
<ackk> mvo, yes, I want to run a process as daemon user, ideally from a bash script. afaict sudo/su don't work in the snap
<ackk> mvo, I thought we did that in maas, but actually we have a python script that does that
<mvo> ackk: I'm out of my depth here unfortunately, I think we need jdstrand to help if you can use su/sudo inside a snap to drop from root to the snap-daemon user
<ackk> mvo, ok, np, thanks
<pstolowski> zyga: what was the PR you wanted reviewed to unblock you (mentioned yesterday in the standup)?
<zyga> pstolowski: let me find it
<zyga> https://github.com/snapcore/snapd/pull/8566
<mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<pstolowski> k
<mborzecki> wow, https://github.com/snapcore/snapd/pull/8650 is green
<mup> PR #8650: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8650>
<ijohnson> ackk: if you want to drop privs to snap_daemon from a shell script you need to use one of the tricks mentioned in "Usage considerations" on https://snapcraft.io/docs/system-usernames
<ackk> ijohnson, ah, thanks
<zyga> re
<zyga> sorry, helped wife with lucy for a moment
<zyga> mborzecki: makes all the test fixing worth it :)
<zyga> pstolowski: I removed the hacks around /home/ubuntu from https://github.com/snapcore/snapd/pull/8633 it now simply ignores it
<mup> PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
<zyga> pstolowski: also extended tests to show this
<pstolowski> thanks
<zyga> pstolowski: and extended help to show the invariants
<zyga> pstolowski: I think it's good now
<zyga> and rebased on master to get all the fixes
<zyga> I didn't do the extra test suite as that's somewhat more work
<pstolowski> zyga: naive question to the lock PR
<zyga> looking
<zyga> pstolowski: as in when the lock file exists but is empty?
<zyga> pstolowski: if you look at unlock() that's exactly an unlocked lock :)
<zyga> pstolowski: we truncate to unlock
<pstolowski> zyga: exists & not-empty
<zyga> if it exists and is non-empty then it is locked
<pstolowski> zyga: yes and if reboot happens it remains non-empty, is it going to ihibit snap run?
<zyga> perhaps the confusing aspect is that there are two locks in one: the contents of the file and the flock protecting reading/writing the contents
<zyga> yes
<zyga> pstolowski: that's the fature
<zyga> *feature
<zyga> it can very much happen that you reboot to uninhibit
<pstolowski> zyga: is there a guarantee it gets released?
<pstolowski> (i'm missing bigger picute)
<pstolowski> *picture
<zyga> pstolowski: it's not a part of this branch
<zyga> pstolowski: it's the same question as link/unlink snap
<zyga> pstolowski: those are just the primitives
<zyga> pstolowski: and the primitives do allow having a lock for indefinite amount of time
<pstolowski> ok. my only concern is that this interrupts a snapd op in flight and we leave snap run unusable for given snap
<pstolowski> but yes, i can see it belongs elsewhere to handle this
<zyga> pstolowski: if you look at the usage of this in another PR
<zyga> I currently inihibit before unlinking
<zyga> and uninhibit after linking
<zyga> though my preference is to expand that period so we inhibit when we decide to refresh
<zyga> and uninhibit when refresh is either done or aborted
<ijohnson> mborzecki: have you seen https://bugs.launchpad.net/snapd/+bug/1878505 ?
<mup> Bug #1878505: recovery chooser doesn't trigger on rpi with core20 <snapd:New> <https://launchpad.net/bugs/1878505>
<mborzecki> ijohnson: hm not surprised really, it's probably a usb keyboard, so it may come up whenever during the boot
<ijohnson> mborzecki: yes he mentioned it was a usb keyboard, in fact he has multiple attached
<mborzecki> ijohnson: probably after loadign the modules, and udev has to settle and create input devices by the time the trigger detection runs
<ijohnson> mborzecki: so perhaps the chooser should gain a systemd depends on systemd-modules-load and systemd-udev-settle (or whatever it's called) ?
<mborzecki> ijohnson: the post-pivot one runs after snapd seeding is done iirc
<ijohnson> ah I see
<mborzecki> ijohnson: what i would expect to work pretty well is using gpio-keys in dtb, setting up one gpio to emit KEY_1
<pstolowski> quick errand, bbiab
<mup> PR snapd#8650 closed: daemon, tests: indicate system mode, test switching to recovery and back to run <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8650>
<mborzecki> ijohnson: added a note, not sure udev settle would fix that reliably tho
<mborzecki> it's a usb stack after all :/
<zyga> brb
<ijohnson> mborzecki: ack thanks for looking at it
<mup> PR snapd#8668 opened: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<ijohnson> pedronis: mvo: I opened https://github.com/snapcore/snapd/pull/8668 which is the first step to cross-check, complete with some tests, not sure if y'all will want more tests or not, it's already at ~1k lines
<mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<pedronis> ijohnson: thanks I will look, we would also like to move partition somewhere else before 1.0, so need also to think whether this bits belong here or not
<ijohnson> ok
<pedronis> *these bits
<mvo> ijohnson: thanks
<zyga> re
<zyga> TIL, well, not T but recently, gparted cannot resize FAT16
<zyga> those small boot partitions, you need some hand holding and remaking from scratch to grow them
<ijohnson> mvo: also could you do a sudo git merge on https://github.com/snapcore/snapd/pull/8659 ?
<ijohnson> the test failures are unrelated
<mup> PR #8659: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8659>
<abeato> o/ is it possible to do 'snap run --gdb' on UC? It complains about gdb command not found
<zyga> abeato: IIRC not at present
<zyga> abeato: we discussed some work required for that but it's not scheduled
<abeato> ok, thanks
<mborzecki> an errand, back in 2-3h
<mup> PR snapd#8659 closed: cmd/snap-bootstrap/initramfs-mounts: use booted kernel partition uuid if available <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8659>
<pstolowski> re
<mvo> pstolowski: thanks your view in 8531! great comments
<zyga> hmm
<zyga> that binfmt misc change is annoying
<zyga> let me take it out of the equation
<pstolowski> mvo: yw, glad you found it useful
<mvo> pedronis: fwiw, I updated the vitality score pr, need to address the comemnts from pawel still though, feel free to have a look still
<mup> PR snapd#8669 opened: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8669>
<zyga> https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test
<mup> PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8669>
<zyga> mvo: ^
<pstolowski> cachio: hi, i commented on your nested.sh PR
<cachio> pstolowski, thanks
<xnox> pstolowski:  hi
<pstolowski> xnox: hey! i've sent you an email
<zyga> mborzecki: I updated https://github.com/snapcore/snapd/pull/8656/
<mup> PR #8656: snap-mgmt: perform cleanup of user services <Created by zyga> <https://github.com/snapcore/snapd/pull/8656>
<zyga> I think it's okay now
<zyga> mvo: I have one tiny fix for you https://github.com/snapcore/snapd/pull/8670 -- debian packaging
<mup> PR #8670: packaging: update sid packaging to match 16.04+ <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670>
<zyga> ijohnson: do you want to review https://github.com/snapcore/snapd/pull/8566 -- it has +2 and I'd like to merge it to make progress
<mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<zyga> you marked yourself as a reviewer
<mup> PR snapd#8670 opened: packaging: update sid packaging to match 16.04+ <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670>
<zyga> but that was two weeks ago
<ijohnson> zyga: go ahead without me, I started a review but didn't finish
<zyga> ok
<zyga> thanks :)
<pedronis> ijohnson: I reviewed #8668, it probably could help if it go split at least in two, I comment as much. I need to go take of an errand, but happy to chat about it later if you have questions. I also think it should live under osutil/disks or something like that.
<mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<pedronis> *take care of an errand
<pedronis> mvo: notice that I commented on one of pstolowski considerations and your answer
 * pedronis errands
 * zyga found a curious failure in session agent test, looking
<zyga> a daily reminder that spread -seed is your friend
<mvo> zyga: thank you
 * zyga breaks for a moment, for the next meeting
<cachio> zyga, please tell be what you mentioned about the spread user
<ijohnson> pedronis: yes let me finish going through your comments, splitting out is probably a good idea and fine to do, I had forgotten I still had the exported mocking methods in the file, those are used in a followup
<cachio> zyga, couldn't hear
<mborzecki> re
<zyga> cachio: in a moment, in another call
<mvo> pedronis: what was the second comment you had about 8351? I will work on the seeding spread test now but forgot what comment 2 was
<pedronis> mvo: we should block people from putting snapd itself in the list
<pedronis> because we are not going to support making it less important than other things
<mvo> pedronis: nice, will do
<pedronis> ijohnson: I asked a question, and answered/made a suggestion to something else in that PR
<pedronis> pstolowski: mvo's PR has landed (and maybe we got new enough kernels), #8533 needs  master merge
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<pstolowski> pedronis: ok, thanks
<zyga> 20 minutes until next call
<zyga> mvo: I feel your pain :D
<zyga> jdstrand: before the next call, do you have time to look at https://github.com/snapcore/snapd/pull/8578
<mup> PR #8578: interfaces: add system-packages-doc interface <Created by zyga> <https://github.com/snapcore/snapd/pull/8578>
<zyga> jdstrand: it's doing the same thing, just some naming changes
<ijohnson> thanks pedronis sounds good
<pedronis> ijohnson: made a suggestion based on your answer
<mborzecki> pedronis: do you have a minute to talk abou the tweaks to keeping track of the current system? i implemented the changes we discussed and have some concerns that we may be overcomplicating it
<ijohnson> thanks yes a Dev() method is fine too
<ijohnson> also a quick review on https://github.com/snapcore/snapd/pull/8652 by anybody would be great  :-)
<mup> PR #8652: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8652>
<pedronis> mvo: should I come to the next meeting? mborzecki wants to chat about something with me
<jdstrand> zyga: before the next call? no. as mentioned yesterday when talking about the coordination email I sent, I will be getting to PR reviews today/tomorrow. I have a bunch of meetings so likely tomorrow
<zyga> jdstrand: sure, no worries
<jdstrand> ackk, mvo: you may not use sudo/su in a snap to drop to the snap_daemon user. those go through the pam stack. I outlined in https://forum.snapcraft.io/t/system-usernames/13386 with a link to code on how to do it. I believe there is something in the snapcraft realm that (cc cjp256) to make it even easier
<jdstrand> one of the reasons why is that sudo and su use the pam stack. but you don't need pam for this
<mup> PR snapd#8669 closed: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669>
<ijohnson> thanks zyga for the review!
<zyga> :)
<zyga> I need to look at the snap routine portal info test
<zyga> but
<zyga> more meetings
<mup> PR snapd#8652 closed: cmd/snap-bootstrap/initramfs-mounts: copy auth.json and macaroon-key in recover <Simple ð> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8652>
<mborzecki> pedronis: no worries, we can talk after your meeting
<cachio> pstolowski, hey
<cachio> nested is working again
<cachio> cmatsuoka, told me the problem
<pstolowski> cachio: yay, that's great
<cachio> pstolowski, I'll push in a bit
<pstolowski> thx
<zyga> woot
<pedronis> mborzecki: I'm available now, standup?
<mborzecki> pedronis: ok
<pedronis> zyga: yes, I looked at your PR, we indeed should talk, also because if I understand that's not the final place you want to put those in, right?
<pedronis> I mean the inhibit locks
<zyga> pedronis: that's right, I'd like to grab the lock earlier, when we do the soft check and it succeeds
<zyga> pedronis: I will look at it in detail tomorrow
<zyga> my main question was where should this live
<zyga> as there will be more code for a non-demo version (undo, all exit paths covered, tests)
<cachio> pstolowski, I pushed the change
<cachio> I already tested that
<zyga> cachio: my question was about the external user
<zyga> cachio: what's the reason for using a non-root user to log into the test device in spread, when using the ad-hoc backend
<zyga> cachio: and a follow-up, if we could use regular root instead
<cachio> zyga, I suppose that in core device we need a user
<cachio> different than root
<zyga> cachio: do you know why?
<pstolowski> cachio: could you push this fix as a separate PR? i think this could land quickly if independent of your nested lib PR
<cachio> I mean, if you can setup the password for root you can use root
<cachio> zyga, but you need to specify the passwotd in the spread.yaml
<zyga> cachio: and how is that different from the external user? we specify a password for it
<zyga> cachio: I want to avoid the difference between ad-hoc and all the other backends
<cachio> zyga, I mean, it is the same
<zyga> cachio: because we get more and more session level things
<zyga> and now we will get a new session that only occurs in a rarely-exercised test interaction
<cachio> zyga, we could use root
<cachio> zyga, I dindt'
<cachio> didn't try with root in a core device but I dont see any restriction
<cachio> zyga, let me make a try
<zyga> cachio: cool, if we can do it that is preferable
<zyga> cachio: if we cannot do it I will try to accommodate the external user instead
<cachio> pstolowski, yes I can, but I'll need a bitr of time because there are few other thinks needed as well
<cachio> zyga, ok
<pstolowski> cachio: ah, if it is more than this 2 line change to apply it on master than maybe it's not worth it
<cachio> pstolowski, I'll make a try after lunch
<cachio> I need to review what is needed
<zyga> ijohnson: hey, if you have a moment, I'd love to get a 2nd review for https://github.com/snapcore/snapd/pull/8633 -- I have some extra checks piled after that, which might help with flaky tests
<mup> PR #8633: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8633>
<zyga> I merged master to get some more fixes but it should otherwise pass (unless network issues show up)
<zyga> mvo: I guess I could look at proposing prompting in to master
<zyga> mvo: it needs considerable setup so it would be a distinct suite / backend perhaps
<cachio> mvo, is it possible to add a password to root in ubuntu core?
<cachio> zyga, ~
<zyga> home :)
<ijohnson> zyga: sure I will take a look at it
<zyga> ahhh
<zyga> I just understood why we still see some failures
<zyga> the failover fixes
<zyga> they don't reload root's session systemd --user
<zyga> I'll send a follow up shortly
<zyga> the things we learn :)
<pedronis> zyga: btw not urgent, but I also spent some time thinking about how to name the *-tool things. we should think a good time to talk about that
<zyga> pedronis: I'm off tomorrow but we can try early next week
<pedronis> ok
<zyga> pedronis: or by email if it's low bandwidth
<zyga> pedronis: I see the problem but I also love the -tool suffix is recognizable as our internal thing and it's short
<pedronis> yes, I agree, we need recognizable or at last standing out names
<pedronis> but the problem with -tool is that is not easy to know what to actually expect from them
<pedronis> zyga: anyway this is a bit an area were it's easy to bikeshed, I might have to simply make a call about where to got at some point
<zyga> pedronis: SURE
<zyga> sure
<zyga> :)
<zyga> sorry, tabbed out of vm with the wrong key
<pedronis> also we have snap-tool that being consistent should be called snapd-tool-tool
<pedronis> :)
<pedronis> anyway
<zyga> pedronis: snapd-metatool
<zyga> https://github.com/snapcore/snapd/pull/8671 should fix the cases that fail with errors like
<mup> PR #8671: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8671>
<zyga> - Make snap "test-snapd-user-service-sockets" (unset) available to the system (Post http://0/v1/service-control: read unix @->/run/user/0/snapd-session-agent.socket: read: connection reset by peer)
<mup> PR snapd#8671 opened: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8671>
<zyga> and with that I'd like to do some paperwork and EOD
<zyga> cachio: ^
<zyga> ijohnson: I should probably move the defer.sh + tac trick into a helper
<zyga> ijohnson: cleanup-tool (accepting any rename after we agree on new names)
<mup> PR snapd#8654 closed: tests: test registration with serial-authority: [generic] <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8654>
<zyga> this is so nice
<zyga> I wanted to do my own model a few times
<zyga> and now with the generic authority I can just really do that
<zyga> and not feel like it's half baked
 * cachio lunch
 * zyga EOWs
<zyga> see you on Monday everyone
<pedronis> pstolowski: there seem to be some selinux failures showing up in #8533
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<pstolowski> looking
<mup> PR snapd#8672 opened: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8672>
<pstolowski> hmm that's weird, seems unrelated
<mvo> cachio: adding a password to the root user is pretty hard, it's /etc/passwd,shadow are readonly so we would need to play bind-mount tricks
<ackk> is it possible to share unix sockets via a content interface between snaps?
<zyga> ackk: yes
<zyga> ackk: it's also tested
<zyga> ackk: and really works :)
<ackk> zyga, lol. yeah I think I have misconfiguration on my side
<ackk> thanks
<zyga> :)
<zyga> I'm EOD but can respond to questions with small alg
<zyga> *lag
<pstolowski> pedronis: ok, it's not obvious with selinux and the test alone against master didn't fail, i'll investigate tomorrow
<zyga> pstolowski: looking
<pstolowski> zyga: it's about #8533
<mup> PR #8533: image, tests: core18 early config <Created by stolowski> <https://github.com/snapcore/snapd/pull/8533>
<pstolowski> afk
<zyga> ok, next week
<pedronis> ijohnson: questions: https://github.com/snapcore/snapd/pull/8668#discussion_r425309127
<mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<mup> PR snapd#8671 closed: tests: reload root's systemd --user after snapd tests <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8671>
<mup> PR snapd#8633 closed: tests: detect and report root-owned files in /home <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8633>
<ijohnson> pedronis: well iiuc from xnox is that what we are trying to do re: cross checking may be racy in that we are walking through entries in sysfs and udev, and "the-tool" currently doesn't wait for udev, it just waits for systemd-modules-load
<ijohnson> I think maybe making the-tool run after udev would eliminate some of the raciness, in which case maybe it's okay to say it's deterministic, but I just don't honestly know
<ijohnson> I have not seen it fail at any point mid way through the function with incomplete output fwiw, but that also isn't a good representation
<pedronis> ijohnson: sorry, so we write a lot of code to avoid the raciness of lsblk but actually we have raciness anyway?
<ijohnson> pedronis: well I don't know how much / what is racy
<ijohnson> pedronis: so to combat not knowing I am just assuming it's racy and doing a best effort in the function
<ijohnson> pedronis: if you'd rather I can just turn all of the "continue"s into return nil, err` but then there will be very many checks there and it feels all a bit fragile to me
<pedronis> ijohnson: we should step back a bit I think
<ijohnson> also fun fact the "unsafe encoding" actually comes from blkid, and the format is already deprecated yet udev continues to use it:-/
<ijohnson> or rather the "safe encoding" format comes from blkid
<ijohnson> pedronis: ok, sure how should we proceed
<ogra> snap changes
<ogra> error: no changes found
<ogra> is there any particular reason why we consider this an "error" ?
<xnox> ijohnson:  "currently doesn't wait for udev" => we did discuss this before, to order it after udev trigger is done....
<ijohnson> xnox: true but we didn't do this yet
<ijohnson> xnox: so if we ordered the-tool to run after udev, would you expect things in /sys/dev/block/<maj:min>/uevent to change ?
<xnox> ijohnson:  what do you mean to change?
<xnox> uevent is a kernel api file there.
<xnox> it's dynamic write/read response api
<ogra> is "udevadm settle" not existing anymore ?
<ogra> (that used to block until udev is done)
<xnox> ogra:  why would you run that under systemd?
<xnox> when there is a  unit to order one after?
<ijohnson> i.e. in order to implement mounting of a consistent set of partitions, we need to look at all of the devices with uevent files like that that match some filter, in this case the same major number
<ogra> xnox, dunno ... probably because i'm from last century ;)
<ijohnson> and I'm wondering if in the course of finding the set of devices that match the same major device number, would anything read from say the first uevent we look at change by the time we are done and look at the last uevent?
<ijohnson> xnox: from the sounds of it you are saying it wouldn't change
<xnox> ijohnson:  i'm not sure, why you key onto the uevent file. but the /sys/dev/block/<maj:min> numbers are stable from device inception as seen in userspace from kernel.
<zyga> https://github.com/snapcore/snapd/pull/8669 fixes random occurance of mounted of binfmt_misc brekaing mount-ns test
<mup> PR #8669: tests/mount-ns: stop binfmt_misc mount unit <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8669>
<ijohnson> sorry we're not keying on the uevent file, we just need to read that file
<zyga> sorry, paste frommdauaf\t\
<zyga> keyBa
<zyga> fghhh
<zyga> lol
<zyga> she loves backlit keys
<ijohnson> really we glob /sys/dev/block/NUM:*/uevent and read all those files basically
<zyga> (that was Lucy smashing keys)
<xnox> ijohnson:  yeah, reading it is fine.
<ijohnson> xnox: ok, next question for each device that matches the filter above, we also run `udevadm --name <devname> --query property`, would you expect the output from that to change at all from the first device we query to the last one?
<xnox> ijohnson:  note, that will only have kerenl uevent details, not the udev uevent details. Normally one subscribes to the kernel netlink uevents and just listens the stream of them.
<ijohnson> xnox: again, if we ordered after udev
<xnox> or like subscribe to udevd's events, which have more information.
<ijohnson> xnox: perhaps this would be easier if you just reviewed my PR and tell me if what I'm doing looks racy/non-racy
<xnox> ijohnson:  you are asking very low level questions, without the overall goal known.
<ijohnson> xnox: see disks.go in https://github.com/snapcore/snapd/pull/8668/files#diff-6c8f8423221c269ce0465372c62a9751
<xnox> ijohnson:  yeah. Normally, one uses udev apis and talks against it's database which is cached / consistent.
<mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<ijohnson> xnox: the overall algorithm is, we have a mountpoint, how do we get 1) the mapper partition from that mountpoint, 2) the underlying encrypted partition from that mapper partition, 3) the disk that the encrypted partition comes from
<xnox> sounds fun
<xnox> ijohnson:  and you don't want to use libudev bindings to query all of those things? cause it has like apis to query all the things, including "who is parent of this device", and again, and again, etc.
<xnox> ijohnson:  https://pkg.go.dev/github.com/farjump/go-libudev?tab=doc ? you rather have your own code, instead of using libudev1, right?
 * xnox is kind of surprised that snapd doesn't already use libudev bindings => it's the fastest thing to query drives
<xnox> and is the ultimate source of truth.
<ijohnson> xnox: last I heard is that we don't want cgo
<ijohnson> if there are pure go bindings to libudev then probably that would help, but would it help by much?
<xnox> there are pures ones too, but executing udevadm imho is safer than any custom native bindings.
<xnox> ijohnson:  you seem to do a lot of work walking all the things in /dev/ when you have all of that information in the udev database already.
<ijohnson> xnox: is there a way that we can get udev params from device major minor directly ?
<xnox> yes
<ijohnson> how?
<ijohnson> using udevadm directly I mean
<ijohnson> not the libudev library
<xnox> i normally, just do `udevadm info --export-db` which exports a consistent snapshot of _everything_
<xnox> and in there you have all the major:minor, all the DM_UUID, all the parents already pre-declared.
<ijohnson> xnox is there a way you can get that in the --query output format though?
<xnox> xnox:  and you can ask udevadm to tell you which major:minor a given device is on
<ijohnson> the format that udevadm outputs by default is slightly more complicated to parse than I would like
<xnox> ijohnson:  there is also this:
<xnox> $ udevadm info --device-id-of-file /boot/
<xnox> 259:5
<xnox> which prints major:minor of the device a given file is on
<xnox> such that if something is mounted, you can just query give me the device of the things.
<ogra> geezs ... allthehiddenknobs !
<jdstrand> ackk: fyi, I updated "Dropping privileges" in https://forum.snapcraft.io/t/system-usernames/13386 to discuss the 'setpriv' command with an example snap: https://git.launchpad.net/~jdstrand/+git/test-setpriv/tree/snapcraft.yaml
<jdstrand> ackk: with snapd 2.45 you can just use setpriv without LD_PRELOAD
<jdstrand> ackk: hope that helps
<ackk> jdstrand, oh, great, thanks! that will make things easier
<jdstrand> cool :)
<jdstrand> fyi emitorino ^
<ijohnson> jdstrand: why does setpriv in snapd 2.45+ work without LD_PRELOAD?
<jdstrand> ijohnson: https://github.com/snapcore/snapd/pull/8220
<mup> PR #8220: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8220>
<ijohnson> jdstrand: so does that mean that setpriv is doing the same thing as dnsmasq and is arguably a coding error?
<jdstrand> ijohnson: yes
<emitorino> jdstrand, ack
<ijohnson> hmm jdstrand but couldn't upstream setpriv change to not do this and effectively break snaps that are relying on this behavior ?
<mup> PR snapd#8673 opened: tests: enable degraded test on uc20 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8673>
<jdstrand> ijohnson: sure, but that is true of anything that you stage when you change bases
<jdstrand> ijohnson: fyi, this is the code: https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/sys-utils/setpriv.c#n1035
<jdstrand> ijohnson: but actually, the only way they could break it would be to call setgroups(<something not 0>,)
<jdstrand> ijohnson: ie, it doesn't matter what they do with the second argument (use the document NULL or something else), cause our filter no longer cares
<jdstrand> documented*
<jdstrand> (and it is safe that we don't care as per the PR discussion)
<pedronis> ijohnson: so I'm looking at #8668, and even ignoring the raciness I think there's too much going on, given in the end we are going to call udevadm info, we don't need to use /sys/ that much, we can pass /sys paths to udevadm
<mup> PR #8668: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<pedronis> directly
<ackk> jdstrand, does that mean that apps using initgroups/setgroups will also work without preload in 2.45?
<jdstrand> ackk: no. this is about using setgroups(0, <something>) only
<jdstrand> ackk: before we required setgroups(0, 0). dnsmasq didn't do that so we investigated and got comfortable with setgroups(0, <something>)
<jdstrand> ackk: as it happens, that makes setpriv with --clear-groups also work
<jdstrand> ackk: setgroups with a size of > 0 is not mediatable by the sandbox, since we can look at what is in the second argument
<jdstrand> ackk: so, we can't differentiate between setgroups(1, 584788) and setgroups(1, 0)
<jdstrand> meh
<jdstrand> setgroups(1, [584788]) and setgroups(1, [0,1,1000,...])
<jdstrand> (we can't dereference a user space point at the time of mediation as a limitation of seccomp's design and implementation)
<jdstrand> it should be possible to mediate setgroups when apparmor grows its syscall filtering, but that is not on a near term roadmap
<mup> PR snapcraft#3122 closed: pluginhandler: make the build environment available to all steps <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3122>
 * cachio afk
<jdstrand> ackk: (and initgroups() is a glibc wrapper around the setgroups system call, so it has all the same issues)
<jdstrand> ackk: erf
<jdstrand> s/since we can look at.../since we can*not* look at.../
<jdstrand> ackk: hopefully I answered your question (sorry for the typos)
<mup> PR snapcraft#3123 opened: cmake v2 plugin: configure with $SNAPCRAFT_PART_SRC <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3123>
<zyga> heh
<zyga> are we again waiting on travis?
<zyga> https://github.com/snapcore/snapd/pull/8566 is stuck on travis
<mup> PR #8566: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <https://github.com/snapcore/snapd/pull/8566>
<zyga> close/reopen to fix it, as usual
<ijohnson> pedronis: part of the issue with the code tho is that udevadm just doesn't give us enough info for various bits
<ijohnson> We still need to go to sysfs for various things unless there's more magical flags to udevadm that tell us what we need
<pedronis> ijohnson: what doesn't it tell us?
<ijohnson> (sorry internet cutting out here)
<ijohnson> pedronis it doesn't have heirarchical info and doesn't know much about the dm devices
<pedronis> ijohnson: well the hierarchical issues are kind of the same
<pedronis> ijohnson: afaict it has the same info about dm devices that /sys has
<ijohnson> pedronis how do you mean
<ijohnson> I run udevadm on the dev mapper and it gives me very little info
<ijohnson> But regardless I see your suggestion now, if you would rather me iterate with udevadm calling on the minor incremented I can do that, I don't see the advantage of that vs inspecting sysfs
<pedronis> ijohnson: there is a lot of back and forth between reading /sys and udevadm, each of that needs an error check
<pedronis> it's all very roundabout
<pedronis> ijohnson: afaict dm name and dm uuid here are present as DM_UUID and DM_NAME
<ijohnson> Well I mean yes all of this is extremely roundabout since there's not a complete set of info from udev or sysfs
<pedronis> ijohnson: i still don't understand the complete info bit, they kind of have the same information
<pedronis> in slightly different ways
<ijohnson> pedronis those were defined for udev env vars for me before we started mounting as /dev/mapper, but now that we use that I don't get that info
<ijohnson> Pedronis can you share what you see running udevadm where you get that info
<ijohnson> Perhaps my uc20 install is buggy somehow
<ijohnson> pedronis: this is what I see now with udevadm
<ijohnson> https://www.irccloud.com/pastebin/xy1iR8UT/
<ijohnson> (my internet seems to be back so back at my computer now)
<ijohnson> I get the same output if I try to access it by /dev/disk/by-label/ubuntu-data or by the major device number as well
<pedronis> ijohnson: I was playing with a focal system, not uc20, I get a ton more info for dm devices
<pedronis> strange
<pedronis> I wonder what is different
<ijohnson> pedronis: yes on my focal classic system I have more info too, but not in uc20
<ijohnson> could be in the options we use in creating the luks device, etc.
<pedronis> I doubt that
<pedronis> this is about the mapper info
<ijohnson> well I mean I really don't know, what I know is that the code I have works with the info we currently have on uc20 and that there is probably about 1000 other ways we could do the same thing
<pedronis> ijohnson: that code is full of continue, that is the part that worries me, I would really like to have as little things returning errors as possible
<pedronis> to have to deal with
<pedronis> and also even with less info is still seems a bit too roundabout
<ijohnson> pedronis: I can try to refactor it to use udevadm calls with incremented minor numbers perhaps that will make it easier/have less `continue`/`return nil, err` but I think at the end of the day unless we have some kind of magical udevadm flag or config option or something that I don't know about we're going to have to get our hands dirty with this code
<pedronis> ijohnson: like I don't think we need to do all the find DEVNAME then use the DEVNAME
<pedronis> udevadm will happily take things under /sys/
<ijohnson> sure let me try to refactor that and see how much goes away
<pedronis> ijohnson: do your partion all have ID_PART_ENTRY_DISK at least ?
<ijohnson> pedronis: you mean physical partitions or dm partitions
<ijohnson> dm partition does not have
<pedronis> I mean the physical partitions
<ijohnson> dm partition does not have ID_PART_ENTRY_DISK
<ijohnson> the physical partitions all seem to have that prop though yes
<pedronis> well, it's not a partition
<pedronis> it has DEVTYPE=disk
<pedronis> but it here it has a little bit more info
<pedronis> but we can deal with that
<ijohnson> ok, but yes all of the vda* have that defined
<pedronis> anyway as I also remarked it doesn't make sense to find all the partition, especially when we just want to find if the mount points come from the same disk
<pedronis> it seems we need two primitives  diskFromMountPoint(path) -> major:minor
<pedronis> diskIter(major:minor, func(udev props) (done bool)) or something like that
<ijohnson> by diskIter you just mean a function which finds all the partitions for the specific disk?
<pedronis> yes, and calls a function passing the result udevadm for each partition until the function is happy
<pedronis> this are the internal primitives
<pedronis> not what we expose as api to be clear
<ijohnson> seems overly complicated to me, why do that over a for loop ?
<mup> PR snapcraft#3124 opened: storeapi: update api and error messages from push to upload <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3124>
<ijohnson> do we need different kinds of searches ?
<pedronis> ijohnson: we need to mock both of those in this world
<ijohnson> so I think what the impl will look like is diskfrommountpoint returns a wrapper object around the major/minor and doesn't do any searching yet and then the MountPointIsFromDisk and FindMatchingPartitionUUID functions actually do the searching, in the case of mount point from disk we may not actually need to do any searching
<pedronis> ijohnson: yes, something like that
<ijohnson> because MountPointIsFromDisk really just gets the dev maj:min for the mount point and compares
<ijohnson> so we only have to do one search, which is for FindMatchingPartitionUUID
<ijohnson> see originally I had different function names where you called one function and not two like this and it seems the refactor carried a bit too much implementation much the before the factor
<pedronis> ijohnson: yes, I still think that the helper would make clearer what's constraints and responssibility, and also make mocking a bit more limited
<ijohnson> right
<ijohnson> alright well I will re-work this a little bit later today, need to go run an errand, perhaps we can sync on this shortly tomorrow after/before SU to see if I'm in a better direction then
<pedronis> anyway looking at a focal system it seems the extra DM_ info comes from /lib/rules.d/55-dm.rules
<pedronis> I wonder if they are not in core 20 or something they need is not there
<pedronis> anyway this is the initramfs
<pedronis> so maybe it has less rules anyway
<ijohnson> pedronis: I have that file in /usr/lib/udev/rules.d/55-dm.rules from the core20 snap
<ijohnson> let me quickly check the initramfs
<ijohnson> hmm actually that same file is also in the initramfs
<pedronis> interesting
<pedronis> anyway as you said we are not waiting for udev, whatever that means
<ijohnson> yes there's a systemd udev service that runs in the initramfws
<ijohnson> we should make the-tool depend on it
<ijohnson> but also I've been looking at userspace where it should also have run
<pedronis> reading that rule files it sounds that we probably have only what we got from the initrd
<pedronis> given that we carry the mount device through from it
<pedronis> so userspace doesn't matter
<pedronis> the question is just why that doesn't work in the initrd
<pedronis> not our biggest concern anyway atm, but interesting/confusing
<pedronis> ijohnson: actualy does _FLAG you have sounds like they have been turned off (maybe)
<pedronis> *those _FLAG
<ijohnson> pedronis what _FLAG ?
<pedronis> ijohnson: you have things like: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
<pedronis> in your udevadm output
<pedronis> it sounds like things are turned off
<mup> PR snapd#8566 closed: c/snaplock/runinhibit: add run inhibition operations <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8566>
<mup> PR snapcraft#3123 closed: cmake v2 plugin: configure with $SNAPCRAFT_PART_SRC <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3123>
<mup> PR snapcraft#3124 closed: storeapi: update api and error messages from push to upload <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3124>
#snappy 2020-05-15
<mup> Issue core20#57 opened: "man" command should not suggest running unminimize <Created by anonymouse64> <https://github.com/snapcore/core20/issue/57>
<mup> PR snapd#8674 opened: tests: fix nested tests  <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8674>
<mup> PR snapd#8668 closed: cmd/snap-bootstrap/partition: add Disk, methods to cross-check mountpounts <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8668>
<mup> PR snapd#8675 opened: osutil: add disks pkg for associating mountpoints with disks/partitions <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8675>
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: guten morgen
<mborzecki> mvo: dzieÅ dobry :P
<mvo> mborzecki: heh :)
<zyga> Hola
<mborzecki> we should practice hellos in every language we have in our team
<mvo> mborzecki: totally!
 * zyga is on a morning walk
<mborzecki> zyga: Â¡hola!
<zyga> Please donât restart test on my PR
<zyga> I want to reproduce the failure and grab the seed
<zyga> More session agent surprises there
<mvo> zyga: oh no
<zyga> Otherwise please merge master into your branches.
<mup> PR snapd#8673 closed: tests: enable degraded test on uc20 <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8673>
<mup> PR core20#58 opened: hooks: enable check that we do not use "synced" dirs <Created by mvo5> <https://github.com/snapcore/core20/pull/58>
<pstolowski> morning
<mborzecki> looks like we have a strange interaction with netns: https://forum.snapcraft.io/t/cannot-run-snaps-apps-inside-a-custom-netns-or-a-tmux-session/17501
<mborzecki> pstolowski: hey
<mup> PR core20#59 opened: static: provide friendly message when "man" is used <Created by mvo5> <https://github.com/snapcore/core20/pull/59>
<zyga> mvo: is https://github.com/snapcore/core20/pull/59/commits/6d6143a566d727d14bd4d70cd7a5fdce55d52c77 +x ? I cannot see that on gh
<mup> PR core20#59: static: provide friendly message when "man" is used <Created by mvo5> <https://github.com/snapcore/core20/pull/59>
<zyga> mborzecki: replied on https://forum.snapcraft.io/t/cannot-run-snaps-apps-inside-a-custom-netns-or-a-tmux-session/17501/3
<zyga> I'm running enlightement and while snaps work our icons cause GFX corrpution (constant glitching every other frame)
<mvo> zyga: yeah, should be at least +x - let me quickly double check
<zyga> mvo: perhaps merge https://github.com/snapcore/snapd/pull/8670 -- travis got stuck
<mup> PR #8670: packaging: update sid packaging to match 16.04+ <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8670>
<pstolowski> zyga: hi, not off today?
<zyga> off
<pstolowski> right :)
<mborzecki> zyga: heh, intersting why ip uses CLONE_NEWNS
<mup> PR snapd#8670 closed: packaging: update sid packaging to match 16.04+ <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8670>
<zyga> mborzecki: I think I know why it fails
<zyga> mborzecki: it doesn't have /run/snapd/ns
<zyga> (the special one)
<zyga> pstolowski: I'm here because a test failure is like a good mystery
<zyga> and I came here to find the killer :)
<pstolowski> :)
<zyga> GAAAAAH
<zyga> mvo: how did we grow all those helpers
<zyga> dbus.sh is another "let's start a session bus" thing
<zyga> used by five tests in total
<zyga> ok, now that I know what it is, let me burn it with fire
<zyga> I re-wrote the tests, I'll send them later today
<mborzecki> silly quesion, where should i file a bug for snap-store snap?
<mborzecki> nvm found it
<lool-> do we have notes on factory mode for UC20? I need to refresh my memory on what it's about   :-)
<mborzecki> lool-: there should be some notes in the snapd roadmap sprint document that was linked in the meeting
<lool-> thanks
<lool-> side question: do we have a doc/site explaining differences between dangerous, signed and secured, and the different UC20 states/modes - install, factory, run
<zyga> hey guys
<zyga> this is a good day :)
<zyga> I'm afk now but I've sent one patch for test robustness https://github.com/snapcore/snapd/pull/8676
<mup> PR snapd#8676 opened: tests: port interfaces-dbus to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8676>
<mup> PR #8676: tests: port interfaces-dbus to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8676>
<mborzecki> didn't we have a fix that when a default content provider snap is being fetched, the install/refresh status bar would update to show that download progress?
<mborzecki> instead of showing the autoconnect label
<mup> PR snapd#8677 opened: cmd/snap, daemon: detect and bail purge on multi-snap <Created by chipaca> <https://github.com/snapcore/snapd/pull/8677>
<pedronis> mborzecki: no, fix afaik, it was only discussed
<pedronis> mborzecki: I reviewed #8672, some questions
<mup> PR #8672: o/devicestate: change how current system is reported for different modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8672>
<mborzecki> pedronis: thanks
<pedronis> mmh, comma too much, I mean "no fix afaik"
<ogra> zyga, can i layout /etc/os-release ??
<ogra> (or is that one of the forbideen files)
<zyga> ogra: no, because /etc/os-release may be a symlink and is actually annoyingly critical for snapd to operate
 * zyga is not here
<ogra> heh, sorry
<ogra> i forgot that half of europe is off
<zyga> I just took a day off
<ogra> ah
<zyga> I'm in the office drinking coffee #
<ogra> i thought poland was in that group
<zyga> I guess one day after the apocalypse I would sit here, with torn cloths and burned face and still drink coffee
<ogra> my zoom users want screen sharing on wayland ... and silly ness of the week, zoom checks os-release for supported distros
<ogra> (and indeed Core18 isnt in that list>)
<mborzecki> ogra: what's the occasion?
<ogra> mborzecki, zoom does video conferencing and screen sharing ... just like google meet ... but on wayland it doesnt work (obviously) ... seems the deb version of zoom uses pipewire after it checked os-release
<mborzecki> ogra: i meant what's the occasion for half of europe to be off today? :) thought v day was a week ago
<ogra> oh, lol
<ogra> not sure ... something catholic ... ?
<ogra> zyga, for not working you are spamming my merges inbox quite a lot :P
<zyga> ogra: lies and insinuations ;)
<ogra> haha
<zyga> in other news, enlightement is fun
<zyga> I really like their terminal
<Chipaca> zyga: they've released a new E?
<zyga> Chipaca: I think I used E16 last time
<Chipaca> ah :)
<zyga> this seems to be e17 0.23.1
<ogra> that came out around the time we started the phone i think
<Chipaca> yep
<mborzecki> i recall intel ivi supporting e17 in the early days, probably in the days of tizen
<zyga> mborzecki: IIRC tizen stil runs on EFL
<mborzecki> zyga: heh, there was this famous error message reported by efl
<zyga> yes?
<zyga> mborzecki: low hanging fruit https://github.com/snapcore/snapd/pull/8676
<mborzecki> zyga: `SPANK! SPANK! SPANK! Naughty programmer!`, even mentioned in this rant https://what.thedailywtf.com/topic/15001/enlightened
<mup> PR #8676: tests: port interfaces-dbus to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8676>
<zyga> lol!
<zyga> so juvenile :)
<mborzecki> fwiw https://github.com/Enlightenment seems pretty active overall
<mborzecki> pedronis: i'll move the system helpers to separate file in the conflicts pr if you don't mind
<pedronis> mborzecki: that's ok
<mup> PR snapd#8678 opened: tests: port interfaces-contacts-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8678>
<Chipaca> hah! we're actually using multi-snap purge in spread itself :-D  snap remove --purge jq jq-core18 jq-core20
<mup> PR snapcraft#3125 opened: cli: cleanup error handling <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3125>
<mborzecki> pstolowski: can you run snap run under strace and see which socket it opens up?
<pstolowski> mborzecki: hmm it's lxd snap. let me try selinux-clean test
<pstolowski> mborzecki: i don't think it's snap related, scontext is snappy_cli_t
<mup> PR snapd#8679 opened: tests: port interfaces-location-control to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8679>
<ackk> hi, is there a way to use variables other than $SNAPCRAFT_PROJECT_VERSION in a "source" url?
<zyga> re
<zyga> ackk: hey, no idea
<zyga> how are tests today?
<zyga> anything failing repeatedly?
<zyga> Chipaca: hey :)
<zyga> Chipaca: thank you for the PR, do you plan to iterate or shall we pick up?
<Chipaca> zyga: ð :)
<Chipaca> zyga: depends :-) what's missing?
<zyga> Chipaca: "go test" doesn't pass
<zyga> Chipaca: :D
<Chipaca> zyga: oh?
<zyga> unless you did something more, I looked earlier briefly
<Chipaca> zyga: I don't know when you looked, but I did push test fixes, tests, and fixes for spread tests that were broken as a result of it
<zyga> Chipaca: ah, brilliant
<zyga> thanks :)
<Chipaca> zyga: 19 passing, 6 failing
<zyga> I must have looked before you did that
<mup> PR snapd#8680 opened: tests: port interfaces-autopilot-introspection to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8680>
<niemeyer> cmatsuoka: You said 164?
<niemeyer> cmatsuoka: Can't find that in spread
<cmatsuoka> niemeyer: 104
<niemeyer> Ah, thanks
<cmatsuoka> it just enables the shielded instance configuration in gce
<niemeyer> cmatsuoka: Merged and updated
<cmatsuoka> niemeyer: \o/
<cmatsuoka> thanks!
<niemeyer> cmatsuoka: Option is "secure-boot", not "secureboot", following related options
<niemeyer> cmatsuoka: Don't celebrate just yet. Please let me know if it works :)
<cmatsuoka> right. I'll update the related PRs accordingly
<cmatsuoka> I already tested the branch and it worked, but I'll run another round of tests now that it's properly merged
<niemeyer> cmatsuoka: Note that this is pilublished already.. PRs are using that code already, so that might be easier to test
<cmatsuoka> niemeyer: I'm re-running tests for the encrypted partitions PR, we'll see the results soon
<mup> PR snapd#8681 opened: tests: port interfaces-accounts-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8681>
<mup> PR snapd#8682 opened: tests: port interfaces-password-manager-service to session-tool <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8682>
<mup> PR snapd#8683 opened: osutil/disks: support IsDecryptedDevice for mountpoints which are dm devices <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8683>
<zyga> I know why the portal routine test can sometimes hang
<zyga> but let's do that next week :)
<ijohnson> Have a good weekend zyga!
<zyga> o/
<zyga> likewise Ian
<mup> PR snapd#8684 opened: tests: add a note about broken test sequence <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8684>
<egeeirl> Is it possible for a strict Snap to access /sys/class even for reads?
<zyga> egeeirl: you need to be more precise
<zyga> egeeirl: what specifically in /sys/class
<egeeirl> in particular - /sys/class/infiniband_mad/abi_version
<zyga> egeeirl: a quick grep through the interface code seems to suggest the answer is "no"
<egeeirl> Unfortunate but understandable
<zyga> egeeirl: but adding an interface is not really hard, we'd just have to discuss the use case and either decide to add it to one of the existing network interfaces
<zyga> or add a new one
<zyga> maybe network-observe could provide that
<zyga> what does that sysfs path say?
<egeeirl> Its a file that returns a number; the version number
<egeeirl> nhc checks that file when doing healthchecks
<zyga> version of something related to infiniband?
<egeeirl> yeah its the userland mad lib verions
<zyga> egeeirl: please bring this up on the forum _or_ file a bug and grab jdstrand or pedronis next week
<egeeirl> Will do - thanks!
<zyga> thanks!
<mup> PR snapcraft#3125 closed: cli: cleanup error handling <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3125>
<mup> PR snapd#8685 opened: opensuse: zypper --replacefiles <Created by zyga> <https://github.com/snapcore/snapd/pull/8685>
<mup> PR snapcraft#3126 opened: pluginhandler: allow cleaning the build step <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3126>
#snappy 2020-05-16
<mup> PR snapcraft#3126 closed: pluginhandler: allow cleaning the build step <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3126>
#snappy 2020-05-17
<mup> PR snapcraft#3127 opened: gnome extensions: i386 bindtextdomain.so support on amd64 systens <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/3127>
<mup> PR snapcraft#3128 opened: extensions: pre/append_dir: support rpath tokens by not using eval <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/3128>
