#snappy 2016-01-18
<imnichol> I'm playing around with creating a znc snap, and I'm running into an issue where "snapcraft stage" fails, but running "./configure" succeeds.  Is there any way to see what snapcraft is doing differently?
<imnichol> Is there a way to configure a post-install script to run after a snap is installed?  I need to kick off the generation of a configuration script
<imnichol> Oh wait, I could probably use the copy section of snapcraft.yaml and copy over a template config
<imnichol> But if I do that, will the user be able to modify it with their own configuration?
<imnichol> Is there something like a home directory for snaps?  znc looks for it's config file in ~/.znc/config/znc.conf so if I can't place the config file there, then I need to hack on znc itself, which is more work :/
 * tsimonq2 is gone: 
<zyga> good morning
<fgimenez> good morning
<LefterisJP> Hey guys I have a question for framework/app filesystem structure. I have some data that keeps growing and need them to persist over upgrades and it would be nice if they are not duplicated at all upgrades. Where can I place such data?
<JamesTait> Good morning all! Happy Monday, and happy Martin Luther King Jr. Day! ð
<blah1> I'm working through the snapcraft tutorial, and it doesn't have a step for editing package.yaml.  What step should I do that in?
<sergiusens> blah1, I don't follow
<blah1> sergiusens: I'm playing around with building a snap from znc just to get an idea of how snaps are built
<blah1> I can get it staged just fine
<sergiusens> blah1, I don't follow the specific question you asked ;-)
<blah1> ah
<sergiusens> blah1, oh, but I misread
<sergiusens> package.yaml, you are not supposed to edit
<blah1> uh, how about this: "is package.yaml automatically generated or do I have to create it?
<sergiusens> it is automatically generated from snapcraft.yaml
<blah1> Ok, is there a way to call the program with specific flags then?
<sergiusens> blah1, are you using 1.x or 2x?
<blah1> sergiusens: of what software?  snappy?
<sergiusens> the version of snapcraft is what I ask for
<blah1> 1.0
<sergiusens> blah1, so in snapcraft.yaml you must have a binaries or services entry; if your command is a binary, add an exec, if it is a service add it to start
<sergiusens> blah1, here's an example https://github.com/ubuntu-core/snapcraft/blob/1.x/examples/ros/snapcraft.yaml
<blah1> sergiusens: oh ok that makes sense
<sergiusens> there are two binaries, named listener and talker, each exec'ed with what is in exec
<blah1> sergiusens: so I could do something like "binaries: server: exec: znc --whatever flags here"?
<blah1> I'm assuming that the "talker" and "listener" entries tehre are arbitrary
<sergiusens> blah1, there is one minor problem in params here, envvars are not allowed do to security problems; we've solved that in 2.x though with some magic wrappings (might backport it or not)
<sergiusens> blah1, those are the names you want your binaries exposed as
<blah1> sergiusens: ok makes sense
<blah1> what do you mean by problem with params?
<sergiusens> blah1, once installed on Ubuntu Core, they will be accessed as 'ros-example.listener' and 'ros-example.talker'
<sergiusens> blah1, the one you gave as an example should work fine
<blah1> ok awesome
<sergiusens> blah1, this won't work though 'exec: znc --tmpdir $TMP' ... as '$' is a non valid char
<sergiusens> it would work in 2.x though
<blah1> sergiusens: ok yeah, that shouldn't be an issue
<blah1> Is there a way for me to put a config file somewhere where the user could modify it?
<blah1> I'm working with znc and obviously everyone's going to need to put unique data in the conf file
<blah1> Otherwise everyone would be connecting to the same IRC channel ;)
<ogra_> blah1, i have a bip package with a "snappy config" hook ... perhaps you want to look at that one ... though that does only use global configs
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files
<blah1> ogra_: that should do what I need
<blah1> thanks
<ogra_> mind you, most people wouldnt consider shell good for parsing yaml though ... yxou might want to look inot a python or GO way or some such
<ogra_> (talking about config.sh here)
<blah1> ogra_: actually, I think I can do it even more simply since I can point znc to an arbitrary conf file
<ogra_> well, but then you need to edit the config by hand
<blah1> I just need to know where to put it so that someone can edit the .conf once they install the snap
<blah1> ogra_: true
<ogra_> instead of using snappy config
<blah1> Oh yeah I see what you mean
<blah1> ogra_: that looks really cool but kind of a "running before I walk" kind of deal.
<Chipaca> blah1: https://github.com/ubuntu-core/snappy-testdata/blob/master/config-example/meta/hooks/config
<sergiusens> blah1, doing it the snapcraft way, look at the config stuff in the webcam-webui example (one level above the link I gave you)
<blah1> sergiusens: thx
<kyrofa> sergiusens, saw your PR. How is this not a problem on amd64?
<kyrofa> elopio, travis doesn't offer any way to run tests on arm, I assume?
<sergiusens> kyrofa, I am not sure; no denials there
<sergiusens> kyrofa, well we don't run the tests on arm or x86 using travis
<elopio> kyrofa: you are right.
<sergiusens> kyrofa, are you back in action?
<sergiusens> or just lurking?
<kyrofa> sergiusens, bizarre. But you can confirm it continues to work on amd64?
<kyrofa> sergiusens, no I need to bring my brother back to DC here pretty quick, but I will be after that
<sergiusens> kyrofa, it should; right after that line of code, there's a CMAKE_PREFIX_PATH.insert(os.path.abspath(__file__), 0)
<sergiusens> well you get the gist of it, __file__ being _setup_util.py which coincides with rosdir (dirname)
<kyrofa> sergiusens, gotcha
<kyrofa> sergiusens, does the face detector work on the rpi, then? Or more problems?
<sergiusens> kyrofa, same problems
<sergiusens> kyrofa, might be good to setup a hangout
<kyrofa> sergiusens, hmm... and no denials? Maybe I'll flash regular-old Ubuntu on my rpi and see if it's a snappy thing or an rpi thing or what
<kyrofa> sergiusens, sure, I'll ping you when I'm back :)
<sergiusens> kyrofa, great, I found more logs btw http://paste.ubuntu.com/14567191/
<sergiusens> kyrofa, and http://answers.ros.org/question/212847/how-to-get-usb-camera-frame/
 * ogra_ would rather want the picture, not the frame :P
<sergiusens> kyrofa, so in summary I think I need to learn how to change the capture pixel fmt from mjpeg to yuyv with roslaunch files (as I can't change that could, well, hmmm
<fgimenez> elopio, jenkins master is building after pushing your changes to my fork https://hub.docker.com/r/fgimenez/snappy-jenkins/builds/
<elopio> fgimenez: thank you!
<noise][1> for 16.04 I assume snappy will be periodically checking all installed packages for updates, is that implemented yet?
<renat> Hi guys! Are you planning to include support of snaps running in chroot?
<noise][1> Chipaca: do you happen to know about my updates question ^^^ ?
<ogra_> renat, for desktops, yes .... iirc that is what the libertine project does
<renat> orga_, thanks! Let me investigate it.
<Chipaca> noise][1: yes, but 16.04 is that which we break all the time
<Chipaca> noise][1: that is your answer about your question about updates, not your answer to you question about your updates question
<Chipaca> noise][1: in particular, if the 16.04 you're talking about is pre-all-snaps, I don't think it'll continue updating
 * noise][1 shakes head in confusion :)
<noise][1> Chipaca: 2 followups: how often is that check going to be, and I don't think we have a bulk query api for CPI so that'll be one CPI hit per installed package right?
<Chipaca> noise][1: we have a bulk query api for cpi
<Chipaca> noise][1: I think we settled on checking a few times throughout the day, downloading when available, and installing once a day
<noise][1> ah, (checks CPI APIs again - click-metadata endpoint), that's good.
<noise][1> Chipaca: excellent, thx for the details
<Chipaca> noise][1: right now it'll just run update once an hour though
<Chipaca> give or take 15 minutes
<Chipaca> OnCalendar=hourly
<Chipaca> AccuracySec=15min
<noise][1> Chipaca: we'll probably want that to be less often by launch
<Chipaca> noise][1: that's in a snappy system, fwiw
<Chipaca> noise][1: I have no idea how often (nor how) snappy mode would do it
<blah1> I've managed to build and sideload a snap, but when I try to start the service it fails with the error here: https://paste.ubuntu.com/14567702/
<renat> orga_, seems it's not what we want. We need ultra light approach, for example with systemd-nspawn?
<blah1> I thought that running "snapcraft stage" was meant to add the libraries in the right location and take care of that, or did I misunderstand?
<ogra_> renat, well, there are lxd and docker frameworks
<renat> ogra_, thanks!
<blah1> To solve my own problem, I've probably got to use a stage package, huh?
<Chipaca> blah1: you're building against the wrong libcxx
<Chipaca> blah1: libstdc++ i mean
<sergiusens> blah1, most likely, is znc from source?
<blah1> sergiusens: yes
<blah1> if it matters: I'm building it on a 15.10 box, but snappy core is running on a 15.04 box
<sergiusens> blah1, maybe create a container or vm on 15.04 to get that out of the way
<sergiusens> blah1, the quick solution though is to add a stage-package stanza and add libstdc++ in there
<sergiusens> iirc that is the package name
<blah1> Alright, thanks!
<sergiusens> elopio, any idea what's wrong with https://github.com/ubuntu-core/snapcraft/pull/240 ?
<elopio> sergiusens: it seems coveralls is not parsing the coverage file.
<elopio> nothing wrong on our side.
<sergiusens> elopio, ok then; once that's in I think we are good for a 2.0
<sergiusens> elopio, did you update the changelog btw?
<elopio> sergiusens: I'm just looking now at all your comments regarding missing bugs.
<elopio> I'll start searching for them.
<kyrofa> sergiusens, elopio okay I'm actually here now
<sergiusens> kyrofa, great, I'm leaving for lunch :-P
<kyrofa> sergiusens, hahaha
<sergiusens> kyrofa, but I have been succesful!
<kyrofa> sergiusens, no way! Awesome!
<sergiusens> kyrofa, well, almost; no more camera errors
<kyrofa> sergiusens, but no image?
<sergiusens> kyrofa, now I need to figure out rosrun imgviewer
<kyrofa> sergiusens, ah, that I can help with :)
<kyrofa> sergiusens, go eat, ping me
<sergiusens> kyrofa, ok; will be back in a bit :-)
<sergiusens> kyrofa, ok, hangout?
<kyrofa> sergiusens, give me 2 mins
<kyrofa> sergiusens, alright, standup url
<sergiusens> kyrofa, sure
<elopio> sergiusens: I don't understand what you meant with the 1.0 changelog.
<kyrofa> sergiusens, for your reference: http://wiki.ros.org/ROS/NetworkSetup
<sergiusens> kyrofa, ok, got it working
<sergiusens> kyrofa, the hz thing
<kyrofa> sergiusens, excellent! The next step you pretty much have: `rosrun image_view image_view image:=<topic you want to view>`
<kyrofa> sergiusens, use /camera/image_raw to get the raw feed, and the faces one to get faces
<kyrofa> sergiusens, image_view does require X
<kyrofa> sergiusens, so make sure you have that reversed or something
<sergiusens> kyrofa, \o/
<kyrofa> sergiusens, yeah? Fantastic!!
<kyrofa> sergiusens, how is the performance of the face detection on that thing?
<kyrofa> sergiusens, is it useable?
<sergiusens> kyrofa, with patience :-)
<kyrofa> sergiusens, hahaha
<kyrofa> sergiusens, I could write a much more performant one, it would just take more time
<sergiusens> kyrofa, this is fine
<sergiusens> kyrofa, http://imgur.com/2EtrDqB
<kyrofa> sergiusens, awesome :)
<kyrofa> sergiusens, I'm sorry that was such a painful experience
<sergiusens> kyrofa, so, network latency even though it is all wired comes into effect, I am also doing two streams
<sergiusens> and the webcam is low res
<sergiusens> kyrofa, and it is an rpi2 :-P
<kyrofa> sergiusens, yeah, definitely
<sergiusens> kyrofa, this was a good excersice that got rid of plenty of bugs
<kyrofa> sergiusens, so did you end up needing an apparmor/seccomp workaround in the yaml?
<sergiusens> kyrofa, only due to lazyness
<sergiusens> kyrofa, http://paste.ubuntu.com/14569194/
<kyrofa> sergiusens, so it definitely needed more permissions than it could get from snappy? If you weren't in a hurry, would we just be waiting for capabilities?
<sergiusens> kyrofa, yeah, we are basically waiting on zyga; and the udev thing is probably fixable; the mounts is totally ignorable
<kyrofa> sergiusens, okay so none of those things are things we'll never be able to access?
<sergiusens> kyrofa, mounts is probably a never allowed lightly
<kyrofa> sergiusens, but non-fatal
<sergiusens> kyrofa, I don't know what we may encounter with other packages, but this one is pretty sane
<kyrofa> sergiusens, okay, good deal
<sergiusens> I'll experiment more and polish now
<kyrofa> sergiusens, thanks for doing that man
<sergiusens> kyrofa, heh, well I'll probably spend some family time as I travel in 12 hours (5:30 AM flight)
<sergiusens> kyrofa, and polish on the way :-)
<kyrofa> sergiusens, yeah do that!
<sergiusens> elopio, btw with 1.0 I mean, grab the changelog corresponding to 1.0 from the 1.x branch, copy and paste in between 0.6 and 2.0 :-)
<elopio> sergiusens: I thought about that but it didn't seem correct. Many of the 1.0 entries are from backports from the master branch.
<elopio> they would be duplicated, and they refer to stuff that never happened in this branch.
<sergiusens> elopio, yeah, but it seems to be the way it is done
<sergiusens> elopio, this is what dholbach did before
<elopio> sergiusens: if you say so, it's coming...
<camako> Where does snappy redirect an app's stdout?
<camako> i.e. where do printfs go?
<bellyfeel> I understand that snappy uses a read-only filesystem, but why am I able to write to certain files within the hierarchy? What's the distinction?
<kyrofa> bellyfeel, each app has its own read/write space which must be on writable partitions
<kyrofa> bellyfeel, check out /etc/fstab on the snappy system-- the labels should clue you in
<kyrofa> bellyfeel, err, paths
<kyrofa> camako, nothing special is done with the stdout. For binaries you should see it on the terminal, for services the syslog
<bellyfeel> kyrofa, ok so it's the user vs os space distinction
<camako> kyrofa, thanks
<kyrofa> bellyfeel, yeah more or less
<bellyfeel> so what determines if a directory or file is writable within the ~/ directory?
<beuno> bellyfeel, apps can only write to their own space, they are confined from the rest
<bellyfeel> for example i can modify /etc/sysctl but not /etc/modules
<beuno> you shouldn't be able to modify anything outside of your own writable space when confined
<beuno> not even the app's own files
<beuno> is this on 15.04 or rolling?
<bellyfeel> rolling
<beuno> so there are 2 levels of confinement
<beuno> some parts of the system are hardcode read-only
<beuno> and some of them you will be confined when building a proper snap
<beuno> at least snaps that can be uploaded to the general store for others to install
<bellyfeel> so the latter is when a snap is trying to access some part of the os/kernel
<beuno> correct
<beuno> or a file outside of its own realm
<beuno> like a file from another app
<beuno> the general idea is that people can generally safely install apps and trust they won't be stealing data or otherwise being malicious outside of themselves
<enoch85> kyrofa, hey! just got home
<kyrofa> enoch85, hey there!
<enoch85> so ownCloud is in now=
<enoch85> ?
<enoch85> (haven't checked)
<kyrofa> enoch85, it's in progress. I got the answer to my mysql extension question by looking at the owncloud src, and it's PDO
<kyrofa> enoch85, so I'm working on that now. Looks like I need a few more PHP extensions enabled as well
<enoch85> kyrofa, ok cool
<kyrofa> enoch85, but I have the owncloud error page working telling me what I'm missing, so I feel quite close
<enoch85> kyrofa, I have the full list in my code
<enoch85> kyrofa, have you checked?
<kyrofa> enoch85, no-- some of these are probably included in the .deb, so I'm letting owncloud tell me
<enoch85> kyrofa, https://github.com/enoch85/ownCloud-VM/blob/master/beta/owncloud_install.sh#L88-L106
<enoch85> kyrofa, okok
<enoch85> kyrofa, need any help?
<kyrofa> enoch85, nah, this shouldn't take too long
<LefterisJP> when I have architecture set to armhf in snapcraft and use node.js in a part like this: parts:
<LefterisJP>    test-webserver:
<LefterisJP>      plugin: nodejs
<LefterisJP>      node-packages:
<LefterisJP>        - web3
<LefterisJP> Can't the staged node binary have the armhf architecture somehow?
<LefterisJP> (right now it does not)
<kyrofa> LefterisJP, snapcraft doesn't support cross-compilation right now
<kyrofa> elopio, you around?
<elopio> kyrofa: yes
<kyrofa> elopio, can you think of any reason why an app in my .snap would be linking to /usr/lib/arch/libkrb5.so.3 when there's a perfectly good one in $SNAP_APP_PATH/usr/lib/arch/libkrb5.so.3 ?
<kyrofa> elopio, I see $SNAP_APP_PATH/usr/lib/x86_64-linux-gnu in the .wrapper LD_LIBRARY_PATH, which to me means it should have precedence over the one in /usr/lib
<elopio> kyrofa: yes. The only related change I can think of was renaming the $SNAP_APP_PATH var, but afaik the old was has not been removed.
<elopio> kyrofa: sorry, I don't know.
<kyrofa> elopio, that's alright, I wanted to whine more than anything
<kyrofa> elopio, glad to know you're still here
<elopio> kyrofa: ok, then keep going :)
<kyrofa> elopio, :P
<elopio> kyrofa: I was about to leave for the gym, and bbl. Do you need me here?
<kyrofa> elopio, haha, no but thanks for the offer
<elopio> just double checking...
<xnox> looks like snappy doesn't know about s390x architecture.
<LefterisJP> kyrofa: The solution right now was to simply include an armhf-node binary and copy it inside the staging aread by using the copy plugin in snapcraft. Not elegant but working. Guess this can be later improved in snapcraft itself.
<kyrofa> LefterisJP, you you have the right idea. That way you can create a .snap that can be run on multiple architectures
<LefterisJP> kyrofa :)
<LefterisJP> kyrofa: one other question that you or someone else may be able to answer.
<kyrofa> LefterisJP, sure
<LefterisJP> kyrofa: What would be a directory for a framework to write data to that should be persistent across updates? I am making a framework for ethereum, which runs a client and downloads the blockchain. Re-syncing the blockchain with each upgrade would be a no-go.
#snappy 2016-01-19
<kyrofa> LefterisJP, any data directory is persistent across updates
<kyrofa> LefterisJP, here's how updates occur on Snappy:
<kyrofa> 1. Version A is installed and has data.
<kyrofa> 2. Version B is downloaded
<kyrofa> 3. Requested to install version B
<kyrofa> 4. Copy version A data into version B space
<kyrofa>  5. Install version B
<kyrofa> LefterisJP, now if version B sucks, you can rollback to version A and its data is still there in the state it was when it was copied
<kyrofa> LefterisJP, this applies to both $SNAP_APP_DATA_PATH and $SNAP_USER_DATA_PATH
<LefterisJP> hmm so data are first copied? It was suggested to me to use $SNAP_APP_DATA_PATH for the framework to sync the blockchain. This is a database that will practically always grow.
<kyrofa> LefterisJP, indeed. Yeah, that sounds like a good spot
<kyrofa> LefterisJP, any database will always grow :)
<LefterisJP> That's nice then, and do users get some form of cleanup management? So that they can delete old data lying around? Cause at least for sideloading I got lots of directories lying around. I can delete manually but that feels dirty :)
<kyrofa> LefterisJP, right now there's `snappy purge`, but that will clear ALL data. We're working on making that a bit better
<kyrofa> LefterisJP, `snappy purge <appname>` specifically
<LefterisJP> I see. All right thanks that will do for now I guess. In the future having some granularity in the choice of versions to purge would be awesome.
<kyrofa> LefterisJP, agreed
<adsad> Why doesn't Snappy Ubuntu use apt-get given that apt-get is so friendly to use?
<xnox> adsad, well, snappy uses a different model of atomic updates. it's kind of what rpm-ostree is to yum/rpm. But so much more as well, given frameworks, atomic updates, and snaps (aka apps)
<xnox> instead of package-per-package update, it's an atomic whole image, a/b updates. or so i understand it.
<adsad> What is the advantage of atomic updates? what is so good about it that the proven apt-get is abandoned?
<xnox> adsad, the base things are still compiled with apt-get/deb based things. So e.g. all the source packages for ubuntu are still build with dpkg-src.
<adsad> if update whole image instead of individual package, wouldn't it take long long time to update?
<adsad> am i right to say the right place to use snappy is on IoT gateways?
<xnox> adsad, it's actually faster =) because there is no maintainer scripts to run, nor individual packages to update. It's down to byte-wise delta. With apt, one has to download and unpack all the unchanged files. And thanks to reproducible builds, security update of a .deb is actually just a tiny delta =)
<adsad> xnox: wow. good to know. impressive. Why not Ubuntu mainstream move to snappy atomic update instead? :)
<xnox> adsad, currently snappy is targeted on IoT gateways, but there are plans to use same technology on e.g. ubuntu for phones, and eventually clients/desktops/servers but UX is still to sort out. Cause e.g. people currently used to e.g. removing apps.
<xnox> adsad, and not everybody who is using e.g. ubuntu unity desktop experience, wants all the default apps that we provide.
<adsad> what are some embedded system boards today that support snappy as iot gateway? I don't think it is suitable for use on desktop and servers, right?
<xnox> adsad, eventually, one day, maybe we will have efficient, atomic, delta, snappy based updates for all for factors. But right now, we are looking at embedded space - cause that's kind of how it has always operated. (ie. "flash" firmware whole disk image)
<xnox> adsad, there aren't enough frameworks/base-images generated to be a better experience on the desktop/server than the current apt-get offering, that's true.
<xnox> adsad, i'm not sure of the current target boards, somebody from snappy team might be able to help you more. I think one can run it in an x86_64 qemu kvm VM to try things out.
<adsad> why is snappy suitable for use as iot gateway? I believe mainstream Ubuntu can also work as IoT gateway as long as the gateway has enough RAM. Embedded systems are almost like mini  PCs today
<xnox> adsad, because of snaps - there are things being packaged for snappy, to make it more open to the end user. Frequent updates, vendor supported, and customizable. E.g. one can add/remove snaps to configure "gateway" advance functionality. Or so I understand. E.g. a snap to get filesharing configured, securely, updated, supported. snap to get firewall. snap to get QoS. Etc. instead of sub-par experience with existing point-and-click firmware on gateways.
<xnox> adsad, look at partners at http://www.ubuntu.com/internet-of-things
<xnox> note, i'm just a community member, i don't develop snappy at all. just a user.
<adsad> xnox: thanks. u sound highly knowledgeable anyway
<adsad> sounds like the main reason for using snappy on Iot is security
<xnox> adsad, a while back, i was like "what is this ubuntu core and snappy thing anyway" so did my research.
<xnox> adsad, yeah, in a user friendly and actually open way =)
<adsad> xnox: yes, that's important with high security stuff. normally, security means developer-unfriendly
<adsad> xnox: if u have tried Intel WIndRiver, u will understand what developer-unfriendly means
<xnox> true. snappy is all around friendly: manufacturers/partners, developers/deployers, end-users, end-developer (consumer developers)
<xnox> adsad, i cannot comment on Intel Windriver at all =) as I used to work for Intel, albeit not at all on windriver products.
<adsad> xnox: snappy is lacking with embedded system security compared to other industrial gateways
<xnox> not sure, didn't study that deep. On the surface it did appear to utalise priviledge separation a lot, and apparmor.
<adsad> xnox: oops.. not to say Intel products are bad. Only WindRiver gave me a terrible experience. Anyway, Intel supports Snappy too. It is a great vote of confidence
<xnox> but i'm not a security expert.
<adsad> xnox: embedded system security is a hardware thing. There's no way snappy can deal with that because snappy is a software
<adsad> xnox: when someone tempers with the hardware, the system can detect that with good embedded system security. I really don't think it is worth paying for this feature anyway
<xnox> snappy is software, ubuntu core is a product. And given the list of hardware partners on the website, it's not unreasonable to expect for hardware to be integrated eventually.
<xnox> that's the point of hardware partners, no?
<adsad> xnox: yes.
<adsad> xnox: i'm  a hobbyist. So far, the only hardware for snappy for hobbyist is raspberry pi. poor man's development board
<adsad> Some hardware partners charge an arm and a leg. Like WindRiver.
<zyga> good morning
<JamesTait> Good morning all!  Happy Tuesday, and happy Popcorn Day! ð
<LefterisJP> When doing `sudo snappy-debug.security scanlog` is there anyway to clear the logs? Asking because right now they are kind of spammed by previous denials I have fixed and I would like to make them go away.
<mvo> ogra_: hi, is your gadget snap for arm64 available in bzr?
<mvo> ogra_: nevermind, I used your dragonboard_0.1_all.snap now and put that into the lp:~snappy-dev/snappy-hub/snappy-systems  tree
<mvo> ogra_: btw, I wonder if we should make partition label a property of the gadget snap maybe?
<LefterisJP> Hey guys is there any way to regenerate apparmor policies for snapps that use a framework's policy if I change said framework's policy group apparmor profile in place? I want to find faster ways to debug/test things in the framework I am developing.
<LefterisJP> I tried sudo snappy-debug.security regenerate SNAPPNAME but that did not do it. (I have edited the framework's policygroup in place, and the snapp uses it so that may introduce extra complexity)
<mvo> ogra_: also if you could check https://github.com/ubuntu-core/snappy/pull/337 if that is actually trueâ¦
<fgimenez> hi mvo :), quick question about https://trello.com/c/tfC2TNsE/291-all-snaps-check-that-boot-grub-does-not-contain-a-kernel-initrd
<fgimenez> mvo, do we need to check only /boot/grub or also /boot/grub/a-b for the absence of the initrd.img and vmlinuz files?
<mvo_> ogra_: I have created an all-snap dragonboard image, do you have the HW to test it?
<mvo_> fgimenez: maybe we can just do a "find /boot/grub -name "vmlinuz" to get it all?
<fgimenez> mvo_, ok thx, i hope to have it finished soon
<mvo_> fgimenez: \o/
<mvo_> ogra_: anyway, please ping me once you are around so that we can talkabout the image
 * zyga pused https://github.com/ubuntu-core/snappy/pull/338
 * zyga pushed https://github.com/ubuntu-core/snappy/pull/340
<pindonga> hi elopio , sorry to be such a nuisance... just wanted to set expectations for this week... do you think it's possible the snappy tests in travis can be run in xenial this week?
<kyrofa> Good morning
<kyrofa> LefterisJP, if you're still around, the snappy-debug logs come from syslog-- truncate that and you'll be good to go
<kyrofa> jdstrand, ping
<liuxg> Chipaca, ping
<liuxg> what could be the error "required description field not specified snappy-systemd_package_yaml_description_present (piglow)" after I uploaded my snap to the ubuntu core store. I have description field in the snapcraft.yaml file there.
<liuxg> kyrofa, ping
<kyrofa> liuxg, pastebin your snapcraft.yaml
<kyrofa> liuxg, and hi :)
<liuxg> kyrofa, this is the snapcraft.yaml http://paste.ubuntu.com/14575220/, and the error is like http://paste.ubuntu.com/14575221/
<kyrofa> liuxg, your service requires a description
<liuxg> kyrofa, oh, really? I did not notice that. In fact, the snapcraft never complains it when building it.
<kyrofa> liuxg, yeah it's just required by the review tools
<liuxg> kyrofa, may I think this is a bug for the tool?
<kyrofa> liuxg, later versions of snapcraft specify one for you
<kyrofa> liuxg, not really-- if you install the review tools locally snapcraft will run them for you
<kyrofa> liuxg, but snapcraft isn't really meant to be a review tool
<kyrofa> liuxg, make sense?
<liuxg> kyrofa, ok. thank you for your help. I will correct it :) by the way, would you please help to review my training slides. thanks a lot for your help.
<liuxg> kyrofa, how to use the review tool for snap?
<liuxg> kyrofa, I really need it to check it before I upload my snaps to the store.
<liuxg> kyrofa, yes, it makes sense, of course :)
<kyrofa> liuxg, ah, I forgot, I'm so sorry! Thank you for the reminder-- looking now
<liuxg> kyrofa, it is alright. I think you are pretty busy.ãJust do it when you are free. Again, thanks for your help!
<kyrofa> liuxg, regarding the review tools, I'm not certain. I think it's click-review
<kyrofa> liuxg, click-reviewers-tools
<kyrofa> liuxg, then run click-review <my snap>
<liuxg> kyrofa, ok. thanks a lot. I will take it down, and blog it for the developers :)
<elopio> pindonga: let me re-run to see what's the status today.
<sergiusens> kyrofa, elopio are you standing up?
<kyrofa> sergiusens, yeah, wanna join?
<sergiusens> I'll try
<elopio> sergiusens: nah, just talking about you.
<bladibla> how to get started with snappy
<elopio> fgimenez: I'd like to attend pitti's proposed migration call. If you have something to discuss, can we do it here?
<liuxg> I just published my snappy apps to the store, then I started to install it. However, it showed me the error like "webcam failed to install: snappy package not found"
<sergiusens> elopio, I forgot to ask, do the adt tests work fine for master?
<elopio> sergiusens: do you mean integration tests in snappy master? Last time I looked they did.
<elopio> I'm about to check again.
<fgimenez> elopio, sure np
<sergiusens> elopio, snapcraft I mean
<sergiusens> elopio, as in atd run snapcraft (or however it was run)
<elopio> sergiusens: ah, I know what you mean. I don't know, let me check.
<elopio> sergiusens: it fails with snapcraft/tests/test_plugin_catkin.py:334:20: E713 test for membership should be 'not in'
<elopio> which means it's taking an old version.
<kyrofa> liuxg, slides reviewed. Good presentation!
<kyrofa> liuxg, I made a number of comments
<liuxg> kyrofa, thanks for your help on this.
<kyrofa> liuxg, of course, I'm sorry for taking so long
<liuxg> kyrofa, it is so kind of you to help me!
<pitti> elopio: FTR, still waiting for my co-sprinters to join
<elopio> pitti: are you in an IRC channel?
<pitti> elopio: #u-devel and #ubuntu-vsprint
<pitti> elopio: or the hangout :)
<elopio> pitti: ok, let's wait for them :)
<sergiusens> elopio, how does it use an old version?
<sergiusens> elopio, or are you looking at update excuses?
<elopio> sergiusens: yes, looking here: http://autopkgtest.ubuntu.com/packages/s/snapcraft/xenial/amd64/
<sergiusens> elopio, yeah, that's the 1.x branch that wasn't supposed to go to xenial :-P
<liuxg> Chipaca, ping
<liuxg> elopio, ping
<elopio> liuxg: pong.
<liuxg> elopio, I have just published 3 snaps into the snappy ubuntu core store. They were successfully published. However, when I tried to install it from my raspberry pi device, it showed me sth like http://paste.ubuntu.com/14575641/. what could be the problem for it?
<elopio> liuxg: rolling?
<liuxg> elopio, what do you mean?
<elopio> liuxg: are you using the rolling release?
<liuxg> elopio, do you mean that I need to select "rolling" when publishing?
<liuxg> elopio, I am not so sure. How can I check it? I can install the "hello-world" snap without any problems.
<elopio> liuxg: I'm just asking if you are in rolling, because things are really different between the two releases.
<elopio> liuxg: snappy info
<liuxg> elopio, sorry, I do not know much about it. would you please explain it?
<liuxg> elopio, http://paste.ubuntu.com/14575656/
<liuxg> elopio, I have just publishedãan app like "piglow-snappy", it is visible in the store, but I cannot install it.
<elopio> liuxg: it says that you are using the 15.04 release, stable channel. I haven't tried uploading snaps recently, you can talk to the store team to see if there's something happening in there.
<liuxg> elopio, who is the person there in the store team?
<elopio> liuxg: join #u1-internal in the canonical IRC.
<liuxg> elopio, when I publish the snap, I select "15.04-core". is this right?
<beuno> elopio, as you know, we've switched to all snaps
<beuno> which are squashfs based
<beuno> so you can't use the same snap for both 15.04 *and* rolling/16.04
<beuno> you have to use an up to date snapcraft
<beuno> and target one or the other
<elopio> actually, snapcraft 1.0 for 15.04, and snapcraft 2.0 for rolling.
<zyga> jdstrand: quick question, for bool-file, do we need any extra syscalls (seccomp)?
<elopio> liuxg: if you are using 2.0 and trying to upload for 15.04, that's likely your problem.
<liuxg> beuno, I did not use snapcraft 2.0 in fact.
<liuxg> elopio, beuno, i have checked that the snapcraft version is still 1.0.
<liuxg> elopio, beuno I can see the snappy app in the store, however, I cannot install it. the app link is https://myapps.developer.ubuntu.com/dev/click-apps/4332/rev/1/
<beuno> liuxg, I understand
<beuno> as I said, snapcraft built a snap that isn't compatible with rolling
<beuno> you need a newer snapcraft
<liuxg> beuno, so, do you mean I need to use snapcraft 2.0 for it?
<liuxg> beuno, my current snappy system is http://paste.ubuntu.com/14575656/
<beuno> liuxg, yes
<liuxg> beuno, I can install it using sideload, and it works well for me.
<beuno> oh, you're on 15.04
<liuxg> beuno, yes, I am on 15.04
<beuno> oh, so ignore everything I said
<liuxg> beuno, I just want to know what could be problem for it. the apps were successfully published. but they cannot be installed from the store.
<jdstrand> zyga: iirc, bool-file is simply a rw rule, so no
<matiasb> liuxg, beuno, I guess you need to install piglow-snappy.xiaoguo (you need to use the full name, afaict)
<jdstrand> (the default seccomp policy allows you to open/read/write/close files
<jdstrand> )
<liuxg> matiasb, then I come to another problem http://paste.ubuntu.com/14575725/. it happens the same when I try to install from the store.
<matiasb> beuno, fyi, ^ that's because we are not enabling anonymous download there
<liuxg> matiasb, it is very strange that for some of the snaps, I do not need to have the domain name. for example, for the case of hello-world http://paste.ubuntu.com/14575730/
<beuno> matiasb, but I thought 15.04 still targets the framework?
<zyga> jdstrand: right, thanks for confirming this
<matiasb> beuno, hmm... in this case, the release is 15.04-core, but no framework was set; we have the auto-enable anonymous for -core frameworks, though
<liuxg> beuno, would you please help me on it? I do not know how to get it working. this is another app I published. is there any problem for it? https://myapps.developer.ubuntu.com/dev/click-apps/4342/
<fgimenez> elopio, there's a bunch of PRs for you to review https://github.com/ubuntu-core/snappy-jenkins/pulls
<beuno> matiasb, ack. Can you enable that for him?
<matiasb> beuno, I can, give me a sec
<elopio> fgimenez: ok, added to the queue. Will look soon.
<matiasb> beuno, done; liuxg, can you try now? (with piglow-snappy.xiaoguo)
<fgimenez> elopio, thx, with all of them applied i've redeployed successfully, pls take a look to check if the snapcraft part is in place http://10.55.32.158:8080/, and if you have the time try to redeploy too
<liuxg> matiasb, beuno, thanks. However, I still face the same issue http://paste.ubuntu.com/14575769/
<elopio> fgimenez: \o/ I'll trigger a test run to see if I missed something.
<liuxg> matiasb, beuno, I do need some access for uploading snaps?
<fgimenez> elopio, ok, i've added to travis tests for checking the images build and basic connection between them, when you are a owner we need to enable travis on ubuntu-core/snappy-jenkins
<liuxg> matiasb, I just rebooted my raspberry pi device, and did it again. it is the same problem here..
<matiasb> liuxg, give it a min until update is propagated, it should work if you try in a couple minutes
<liuxg> matiasb, may I know what change you made just now? it is good to know it.
<liuxg> matiasb, doãI need to let you do some configuration whenever I need to publish an app? will this happen to the rest of the developers? thanks
<matiasb> liuxg, this is an internal detail which we should be working around (on our side) soon, related to authentication and downloads from snappy devices; it should be transparent for devs
<liuxg> matiasb, so, your team will work this out, right? from developers' point of view, we do not need to do anything?
<matiasb> liuxg, from the developer point of view, no, nothing extra will be required
<elopio> pindonga: we are closer again: https://travis-ci.org/ubuntu-core/snapcraft/jobs/103364898
<liuxg> matiasb, so, for now, it is a bug, right? I just re-tried, it did not work yet. how long should I wait?
<matiasb> liuxg, hmm... it should be working now... what are you trying? still 401?
<liuxg> matiasb, still the same http://paste.ubuntu.com/14575845/
<matiasb> liuxg, but that's another package!
<matiasb> :)
<liuxg> matiasb, yes, I have 3 apps: grovepi-server, Webcam, piglow-snappy
<liuxg> matiasb, so, you need to configure for each of the apps?
<matiasb> liuxg, I fixed the status for the piglow-snappy one, I should check the others if needed
<liuxg> matiasb, my snappy is being updated "another snappy is running, try again later" :) I need to wait for a while. the other ones are https://myapps.developer.ubuntu.com/dev/click-apps/4341/ https://myapps.developer.ubuntu.com/dev/click-apps/4332/
<matiasb> ack, will take a look in a bit
<elopio> beuno: mvo mentioned that the store doesn't allow us to name the os snap ubuntu-core for amd64 and armhf, but that's the plan.
<elopio> is that happening soon, like this week? The workaround in the tests is not just a couple of lines, so I would like to know if it's worth it.
<matiasb> elopio, working on that, trying to get there asap; hopefully before end of next week
<liuxg> matiasb, yes, the piglow-snappy works now.
<matiasb> liuxg, great
<liuxg> matiasb, so, next time when I publish a new one, I still need to look for you to help?
<elopio> matiasb: ok, so I will work around. Do you have a bug I can subscribe to?
<bellyfeel> Is there a way to add two factor auth to snappy? I see that the files in pam.d are read only...
<matiasb> liuxg, maybe, hopefully not, the update to handle this is in progress, afaict
<matiasb> elopio, hmm... I think there isn't, but I have a trello card with a hard deadline for Feb 1s
<liuxg> matiasb, that sounds good. By the way, when I install the "hello-world", I do not need to have "canonical" there. I just need to sudo snappy install hello-world. But for may case, I need always to have ".xiaoguo"
<liuxg> matiasb, for the other two apps, are they ready to check? thanks
<matiasb> liuxg, right, there are short names available for some packages (frameworks and canonical pkgs)
<matiasb> liuxg, give me a few, I'll let you know when ready
<liuxg> matiasb, ok. thanks! I just want to make sure they are in good shape. By the way, if I upgrade them to new versions, do I need to bug you again?
<matiasb> liuxg, no, updates should work without any issues
<liuxg> matiasb, ok. thanks. it is good to know :)
<matiasb> liuxg, ... and updated; try again in a few mins, and the other packages should get installed too
<liuxg> matiasb, one more thing, when I publish a snap, if the link is https://vimeo.com/152249451, it is now allowed. However, if the link is http://vimeo.com/152249451. it works fine. is this a bug?
<liuxg> matiasb, sorry, the one with "s" is not allowed :)
<matiasb> liuxg, sounds like it could be (although the help text example is http), feel free to file a bug for it, if it isn't already there, and it will be eventually triaged
<liuxg> matiasb, could you please give me the project name for it?
<matiasb> liuxg, software-center-agent
<liuxg> matiasb, thanks!
<matiasb> np
<rickspencer3> jdstrand, can I write a service that shells out "echo 14 > /sys/class/gpio/export", etc...?
<rickspencer3> so far, it seems like my service can't really see into /sys/class, but I am not getting back clear error messages from my Go code
<liuxg> matiasb, I have filed a bug at https://bugs.launchpad.net/software-center-agent/+bug/1535808
<ubottu> Launchpad bug 1535808 in Software Center Agent "Cannot successfully submit an app if the video link contains "https"" [Undecided,New]
<jdstrand> rickspencer3: the /sys/class/gpio/export file can be used with hw-assign
<rickspencer3> jdstrand, hmmm
<rickspencer3> jdstrand, let me try some more, but I have not made it work
<jdstrand> you should be able to hw-assign anything in /sys/class/gpio/
<liuxg> matiasb, thanks. the other two apps are fine now. have a nice day!
<rickspencer3> also, I noticed that when I am on the cli, just "sudo echo 15 > /sys/class/gpio/export" does not work
<rickspencer3> for some reason I have to to do $sudo su
<rickspencer3> and then I can do it from #
<jdstrand> rickspencer3: try: sudo sh -c 'echo 15 > /sys/class/gpio/export'
<rickspencer3> I was wondering if that could be related
<jdstrand> rickspencer3: the '>' redirection write is happening under your uid, not root
<rickspencer3> interesting
<matiasb> liuxg, great! ack, thx for the bug report
 * jdstrand needs to step into a meeting but will keep an eye on backscroll
<liuxg> matiasb, have a good day. thanks a lot for your help!
<rickspencer3> jdstrand, any reason I shouldn't be able to use Go's library for reading files to read /sys/class/gpio/gpio14/value ?
<jdstrand> rickspencer3: not otoh if the security perms are granted... maybe mwhudson might have an idea?
 * rickspencer3 futzes a bit
<rickspencer3> jdstrand, so, when I try to read from the file, I get this?
<rickspencer3> Jan 19 18:48:33 localhost kernel: [ 7624.772671] audit: type=1400 audit(1453229313.026:73): apparmor="DENIED" operation="open" profile="rest-button.sideload_rest-cam_IKXIKPPCYFMQ" name="/sys/devices/platform/soc/3f200000.gpio/gpio/gpio14/value" pid=3006 comm="rest-button" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<jdstrand> rickspencer3: ah, you might have tried to read a symlink down in there
<rickspencer3> comes from this line of code, I guess
<rickspencer3>  /sys/devices/platform/soc/3f200000.gpio/gpio/gpio14/value
<rickspencer3> oops
<jdstrand> rickspencer3: you can use hw-assign for that
<rickspencer3> ioutil.ReadFile("/sys/class/gpio/gpio14/value")
<rickspencer3> jdstrand, yeah, I did that
<rickspencer3> but, it seems quite idiosyncratic
<jdstrand> you did hw-assign for /sys/devices/... too?
<rickspencer3> jdstrand, no
<rickspencer3> I did not know that would work
<jdstrand> right, you need both (or more)
<rickspencer3> so, I can hw-assign rest-button /sys/devices/* ?
<jdstrand> this is what capabilities will fix
<jdstrand> rickspencer3: sure. you can do multiple hw-assign(ments)
<rickspencer3> I did hw-assign to the specific file, and that made my code work
<rickspencer3> sure, I just didn't know at what level that was requireed
<jdstrand> rickspencer3: it seems that the first rule created a situation where you needed a second rule
<jdstrand> iiuc, when you gpio export something, new files are created in /sys
<jdstrand> rickspencer3: use these with hw-assign: /sys/class/gpio/** and /sys/devices/**/gpio/**
<rickspencer3> ok
<jdstrand> eg, sudo snappy hw-assign foo /sys/class/gpio/**
<rickspencer3> I'll try that next
<jdstrand> sudo snappy hw-assign foo /sys/devices/**/gpio/**
<mwhudson> jdstrand, rickspencer3: no idea
<rickspencer3> fair enough :)
<rickspencer3> it seems to be working, actually
<rickspencer3> now I am just figuring out how to caste the []byte in the right way
<jdstrand> mwhudson: it turned out to be a permission issue
<mwhudson> jdstrand: nothing like it being the obvious answer
<kyrofa> dholbach, what is this app developer manual you speak of?
<dholbach> kyrofa: the "Snappy Ubuntu Core - Application Developer Manual 15.04" doc
<dholbach> kyrofa: both PRs updated
<dholbach> all of this should probably be in HACKING.md
<dholbach> ... or the tools more forgiving
<dholbach> and maybe  to make things even more enjoyable we should use bzr on LP, but that's probably just my very own pipe dream
<kyrofa> dholbach, when you make a PR, you should see a "read the contribution guidelines" link, no? It links to https://github.com/ubuntu-core/snapcraft/blob/master/CONTRIBUTING.md. See step 3 :)
<dholbach> ah sorry - I was just looking at HACKING.md
<dholbach> thanks
<kyrofa> dholbach, yeah, HACKING will tell you how to actually develop changes, run tests, etc. CONTRIBUTING is how to get changes back IN
<dholbach> ok cool
<dholbach> kyrofa: I'm not sure what still needs to be done for https://github.com/ubuntu-core/snapcraft/pull/241
<kyrofa> dholbach, "Snapcraft can be extended by adding plugins new part plugins" needs to be reworded, and a blank line needs to follow the class definition
<dholbach> oops yes, I just saw it
<dholbach> sorry
<kyrofa> dholbach, no problem :)
<dholbach> that's what you get when you try to edit documentation when jetlagged :)
<kyrofa> dholbach, what is the time difference for you? And are you already in california?
<dholbach> yes
<dholbach> 9h
<kyrofa> dholbach, blech, you have my pity
<dholbach> luckily I came here a few days ago already and visited (and stayed with) the family of my girlfriend's sister, so I'm doing much better already :)
<kyrofa> dholbach, oh fun!
<kyrofa> dholbach, coffee drinker?
<dholbach> I was off of caffeine for quite a while, but that wasn't sustainable here ;-)
<kyrofa> dholbach, hahaha
<kyrofa> dholbach, I see you updated it. But the extra line I believe elopio is referring to needs to be between the `class` and `def build()` for pep8. Right elopio ?
<dholbach> I ran pep8 over that bit
<dholbach> but maybe I was doing something wrong
<kyrofa> dholbach, you may be fine-- let's just get elopio's OK
<dholbach> sure sure
<kyrofa> dholbach, he's the python guy
<kyrofa> dholbach, I'm definitely not. But I'm trying!
<dholbach> kyrofa: how was the ride so far? :-)
<kyrofa> dholbach, python? I have mixed feelings about it :P
<dholbach> sounds like my feelings about using git :-P
<kyrofa> dholbach, :D
<kyrofa> dholbach, the include path methodology is nonsense. I still don't understand it
<dholbach> I'm sure there's a PEP for that :)
<kyrofa> dholbach, also I'll never get used to a whitespace-scoped language. It hurts me a little inside
<jerryG> Chipaca: are u there
<jerryG> kgunn: are u online?
<dholbach> kyrofa: for some reason it was easy enough for me to just accept that - I can't even remember the times before :)
<kyrofa> dholbach, yeah I have to tilt my head sideways
<jerryG> mterry: can u answer a quick question about xmir?
<dholbach> kyrofa: it sounds like a conversation we should have in a hotel bar after hours at some stage :-P
<kyrofa> dholbach, sounds like a plan ;)
<dholbach> awesome :)
<kgunn> jerryG: i happen to be yes
<jerryG> kgunn: is any1 at canonical using SDL on snappy?
<kgunn> jerryG: not that i'm aware of
<kgunn> jerryG: but there's no reason you couldn't
<kgunn> snappy is just different way to package
<jerryG> kgunn: it should be alright if i just include the .so files for SDL right?
<kgunn> yes
<jerryG> kgunn: k thx
<kyrofa> elopio, you still around?
#snappy 2016-01-20
<kyrofa> liuxg, did you ever get those packaging problems resolved?
<kyrofa> liuxg, I seem to be running into a 401 when trying to install my just-published .snap
<liuxg> kyrofa, it is very late for you, right? so far, it is fine for me.
<kyrofa> liuxg, heh, yeah we switched places :)
<kyrofa> liuxg, and you didn't need to do anything?
<liuxg> kyrofa, yeah, I talked to the online service team, and they helped me to configure sth at the backend. The the problem disappeared.
<kyrofa> liuxg, bueno etc.? Nothing you could walk me through, I suppose?
<liuxg> kyrofa, for now, for each snap app, I need to talk to matiasb to help to configure. they are trying to solve the problem.
<liuxg> kyrofa, yeah, bueno's team is responsible for it.
<kyrofa> liuxg, that's too bad-- it seems pretty broken
<liuxg> kyrofa, yes, I just got my 3 snaps published. he manually fine-tuned something for me.
<kyrofa> liuxg, alright I'll ping matiasb in the morning, then
<kyrofa> liuxg, thanks for the advice :)
<liuxg> kyrofa, late on, he said that it would be automatic. it is really annoying
<kyrofa> liuxg, yeah. Growing pains I guess :)
<liuxg> kyrofa, yes, it seems that is the only way. I think you probably need to go to bed. it is really too late for you.
<kyrofa> liuxg, great minds think alike ;)
<kyrofa> liuxg, have a great day!
<liuxg> kyrofa, by the way, thanks for your help to review my slides. I really learned a lot from you!
<liuxg> kyrofa, have a good night :)
<kyrofa> liuxg, my pleasure :)
<kyrofa> liuxg, night!
<miken> kyrofa: I can push the right button if you need it...
<miken> But right, if it's that late, sleep and have it done in the morning :)
<fgimenez> good morning
<LefterisJP> hey guys, how can one clean the output of `sudo snappy-debug.security scanlog`? It has irrelevant warnings that i fixed days ago and takes quite some time to reach the end :P
<robert_ancell> mvo, what is the correct way to search for snappy packages? The REST API for snapd doesn't seem to have any search functionality, but the command line tool does (I think it goes directly to search.apps.ubuntu.com)
<JamesTait> Good morning all!  Happy Wednesday, and happy Penguin Awareness Day! ð
<blr> JamesTait: sadly, our yellow eyed penguins in Dunedin are not doing particulary well :(
<JamesTait> blr, how so?
<kyrofa> Good morning
<kyrofa> LefterisJP, truncate your syslog
<kyrofa> mvo, I'd like to get an all snaps image on my rpi2 (that's where I can use classic, right?). How do I go about that?
<mvo> kyrofa: its here http://people.canonical.com/~mvo/all-snaps/
<kyrofa> Thanks mvo :) . Booting now
<kyrofa> mvo, another question: I know that ubuntu-core itself is automatically updated, but does is _ever_ .snap automatically updated by default?
<kyrofa> s/ever/every/
<kyrofa> mvo, I think the answer is "yes" but I want to make sure. Other .snaps aren't updated enough for me to know from experience, heh
<vir17> hi, i am new here. I am interested to learn more about snappy for things. Any good tutorials out there?
<kyrofa> vir17, welcome! Start here: https://developer.ubuntu.com/en/snappy/ :)
<vir17> thank you kyrofa , I have already read the information of this link,thank you, I want more of a guide/article explaining a real concept so I can follow the steps and learn in the process
<vir17> if anyone is aware of something like this
<kyrofa> vir17, have you visited https://developer.ubuntu.com/en/snappy/build-apps/ then?
<LefterisJP> kyrofa: how can I truncate syslog in snappy? Doing `sudo cat /dev/null > /var/log/syslog` gives me a permission denied error. Also tried to use the systemd journal way with `journalctl --vacuum-time=1m" but that had no effect.
<vir17> thanks kyrofa i will try that
<kyrofa> LefterisJP, try `sudo dd if=/dev/null of=/var/log/syslog`
<kyrofa> vir17, note that link was linked from the original page I shared, near the top (named "Build apps")
<mvo> kyrofa: yes :) every snap auto-udpates
<kyrofa> mvo, excellent, thank you for the verification
<LefterisJP> kyrofa: thanks! it worked. Curious why cat did not work.
<kyrofa> LefterisJP, redirects don't get your privileges
<kyrofa> LefterisJP, so you could also have sudo su - and THEN done the redirect
<kyrofa> LefterisJP, so the cat was happening with sudo, but the redirection was happening as you. Make sense?
<LefterisJP> kyrofa: yeah it does, thank you - should have thought about that :)
<kyrofa> LefterisJP, any time :)
<jdstrand> LefterisJP: hey, fyi it is pulling from /var/log/syslog. the tool itself could definitely be smarter, but a log rotation would also do the trick
<kyrofa> jdstrand, question for you
<jdstrand> kyrofa: hey
<kyrofa> jdstrand, there are some applications that host a vast amount of data (e.g. owncloud)
<jdstrand> mvo: not sure if you saw it, but you should have gotten an email regarding mksquashfs/unsquashfs hashes. I don't need an answer now, just want to make sure you saw it
<kyrofa> jdstrand, such collections of data really shouldn't be copied upon upgrade, etc.
 * jdstrand is waiting for the question
<kyrofa> jdstrand, that also leads to another point: say you're running on the rpi2, but want to host owncloud's data on an external hard drive instead of in SNAP_APP_DATA_PATH or something. Is that a problem you're considering as far as hw-assign goes?
<kyrofa> jdstrand, or capabilities, I guess
<LefterisJP> kyrofa: jdstrand: I have to go right now, be back in 1 hour or so, but I have the exact same problem with the framework I am developing. The data (the blockchain) is stored in $SNAP_APP_DATA_PATH and is copied with each upgrade, which is not a good solution (it starts to become too big). Wonder how it could be done better.
<jdstrand> on Touch the data dirs are not versioned. I initially suggested we do the same for snappy, but it was decided that snappy should have versioned data dirs to support rollbacks (which isn't supported on Touch)
<kyrofa> jdstrand, indeed, and that's actually awesome for the database i'm hosting there
<kyrofa> jdstrand, but I feel like we're missing that other capability
<jdstrand> which other capability-- the hard drive or having some sort of optional "share data between versions" or something?
<kyrofa> jdstrand, the share data bit, but in my head they're the same problem-- store data outside of the typical snappy paths
<jdstrand> I think the sharing data between versions is a conversation point for the snappy architects. It could perhaps start as a bug
<jdstrand> the hard drive point actually isn't a hard drive device-- it is just an alternate directory. I don't see why that couldn't be handled by capabilities
 * jdstrand jots that down on the list of things to bring up with zyga
<kyrofa> Alright, thanks jdstrand!
<jdstrand> kyrofa: I can say that the thing with rollbacks is, aiui, you don't have infinite number of them. you get one. that isn't exactly what you'd like I know, but at least there is an upper limit
<kyrofa> jdstrand, oh interesting, actually I didn't know that. Are versions older than "the previous one" cleaned up, then?
<jdstrand> maybe there is an opt in behavior there. do the copy, and if you don't rollback, get rid of the old data dir
<jdstrand> kyrofa: I'm not sure what the implementation does now, but aiui, that is the plan. perhaps mvo can shed more light on that
<kyrofa> elopio, you may still be in the QA call, eh?
<mvo> kyrofa: sorry, in a meeting right now, I can reply in a bit but I can't read backlog currently
<kyrofa> mvo, no problem
<kyrofa> elopio, ping me if you want to standup :)
<kyrofa> mvo when you get a minute, any idea why `make` would be segfaulting in the classic dimension?
<mvo> kyrofa: its doing what - segfaulting? huuuu
<kyrofa> mvo yeah even just make clean
<mvo> kyrofa: that sounds more like a bad sd card or something, do you have a backtrace?
<elopio> kyrofa: sorry, my other meeting ran long.
<elopio> kyrofa: I don't want to stand up, my throat hurts. I think I've already said today all the words I usually say in a week.
<kyrofa> mvo, http://pastebin.ubuntu.com/14582510/ with strace
<elopio> kyrofa: do you need something from me for today?
<kyrofa> elopio, no problem :)
<kyrofa> elopio, and no, you're good!
<elopio> :)
<mvo> kyrofa: thats on the rpi2 I assume?
<kyrofa> mvo, indeed
<kyrofa> mvo, never seen this before
<mvo> kyrofa: I suspect some HW issue, but I will try to reproduce, just need to fiddle with the serial cable of my rpi2 to get it going again
<kyrofa> mvo, thanks for the help! Yeah the only thing I can get out of make is --help. Even -v segfaults. But I was able to setup classic and install snapcraft and everything without issue
<mvo> interessting
<mvo> kyrofa: http://paste.ubuntu.com/14582659/ - works here :/
<kyrofa> mvo, what on earth
<mvo> kyrofa: let me try to upgrade everything so that I'm really on the latest everything
<kyrofa> mvo I don't see any real problem in the strace either-- it lists the entries in /dev a few times and then closes the /dev fd right before it segfaults
<mvo> kyrofa: does gdb show anything meaningful? but before that, can you try "sudo apt install --reinstall make" ?
<mvo> kyrofa: and maybe its dependencies, I still suspect some sd card issue
<kyrofa> mvo, no gdb is useless: http://pastebin.ubuntu.com/14582689/
<kyrofa> mvo, reinstalling make doesn't help
<kyrofa> mvo I might have another card here I can try
<kyrofa> mvo I hate hardware sometimes :P
<mvo> kyrofa: worth a shot to try with a different sd card I would say, we had a bunch of sd card issues when testing with the bbb, quite a few issues were faulty HW
<opmodoro> Hello, I'm building my first snap using go as in the tutorial. When I install it apparmor deny it asking for capability net_admin, if I add it in the yaml it won't install with an error. Any tought?
<kyrofa> opmodoro, what is your snap doing?
<opmodoro> actually a simple http server at 127.0.0.1:8080
<kyrofa> opmodoro, what version of Ubuntu Core are you running?
<opmodoro> uhm, I'm on vagrant box ubuntu-core-edge-15
<kyrofa> opmodoro, to double check, `cat /etc/lsb-release`. It's 15.04?
<opmodoro> kyrofa, yes 15.04 vivid
<kyrofa> opmodoro, can you please pastebin the apparmor denial you're seeing, as well as your snapcraft YAML (assuming you're using snapcraft)?
<opmodoro> ok, just a moment
<jdstrand> opmodoro, kyrofa: that is a harmless denial
<jdstrand> if you use snappy-debug.security scanlog, it will tell you that
<jdstrand> https://launchpad.net/bugs/1465724
<ubottu> Launchpad bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed]
<opmodoro> jdstrand, kyofa, I found something similar on launchpad. However logs are not helping and netstat -nat doesn't show it
<kyrofa> jdstrand, oh, nice. What's being denied there? What does net-admin give you?
<kyrofa> opmodoro, he's saying you should be able to safely ignore it-- it shouldn't be affecting your .snap
<jdstrand> kyrofa: it is a kernel bug. its logic is wrong when trying to see if something has access to some proc file iirc
<opmodoro> jdstrand, I do not have such command
<jdstrand> opmodoro: sudo snappy install snappy-debug
<kyrofa> opmodoro, `sudo snappy install snappy-debug`. Very handy tool
<opmodoro> great thanks!
<kyrofa> Thanks for jumping in there jdstrand :)
<jdstrand> np :)
<tzununbekov_> asac, jdstrand hi, have you received our message on mail?
<jdstrand> tzununbekov_: it went through, yes. I didn't respond since we chatted on irc and was waiting for the conversation to pickup
<opmodoro> kyrofa, jdstrand thank you! It is working now. I've added the correct caps now. Best
<kyrofa> opmodoro, excellent!
<kyrofa> mvo, alright, trying with a second SD card
 * kyrofa crosses his fingers
<Guest35435> quick question, there's no way to add repositories like Deluge or anything right now yeah?
<ogra_> Guest35435, you can use an lxc container, a docker container or the classic mode to use debs .... in plain snappy there is no deb support though
<ogra_> you would rather use snapcraft with the copy plugin to create a snap of your project instead
<Guest35435> okkkk thanks! I'll look into all that
<kyrofa> mvo, segfault again
<kyrofa> sergiusens, did you try the classic dimension on the rpi2?
<elopio> mvo: are you still working? I wanted to ask you about this https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/update_os_test.go#L45
<elopio> but if it's too late for you, I can do it earlier tomorrow.
<mvo> elopio: sure, still here
<kyrofa> elopio, can you take another quick look at https://github.com/ubuntu-core/snapcraft/pull/241 when you're able?
<mvo> elopio: just addressed your pull request comments (thanks for those!)
<elopio> mvo: so, when I run snappy update, where are the bootloader files that will be used after the reboot?
<mvo> elopio: what do you want to know in particular? the new syle boot dir is simple on grub: its empty (except for the UEFI stuff that is mandatory)
<mvo> elopio: in uboot its /boot/uboot/snap-blob-name/{vmlinuz,initrd.img}
<elopio> mvo: yes, uboot case.
<elopio> mvo: so, after the new snaps are installed, they overwrite the system boot. That's all I needed to know.
<mvo> elopio: http://paste.ubuntu.com/14583211/
<elopio> I'll make the test pass on rpi.
<elopio> kyrofa: ack
<kyrofa> elopio, make sure the code style is what you were going for
<mvo> elopio: here are the vars used: http://paste.ubuntu.com/14583223/
<mvo> elopio: \o/
<mvo> elopio: let me know if there is anything else you need to know
<elopio> mvo: I got that workaround with the env vars covered on my pull request from monday.
<elopio> mvo: maybe you can look at it tomorrow. It's simple, and m-o is happy: https://github.com/ubuntu-core/snappy/pull/343
<LefterisJP> guys is there any way to add another editor instead of VI inside snappy? For debugging purposes I need to be editing different files and then rerun snap services, but my VI editing skills are a bit ... well ..
<LefterisJP> (I am an emacs user)
<ogra_> just create an emacs snap then ?
<ogra_> (or use the classic mode)
<elopio> LefterisJP: +1 to the emacs snap. I would like your snap very much.
<elopio> I'm wondering how do we allow a snap to read all files, and write all the writable files, like an emacs snap would need.
<ogra_> (we might end up to even drop vi from the core OS at some point)
<ogra_> elopio, probably simply via sideloading :)
 * ogra_ has a htop snap, a debootstrap and a wget snap he uses like that
<mvo> elopio: sure
<ogra_> i.e. http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/files ...
<mvo> ogra_: aha, did you see all my messages about all-snaps & arm64 from the other day ?
<ogra_> mvo, hmm, perhaps not ... IRC ? mail ?
<mvo> ogra_: irc
<elopio> ogra_: why do you need the wget snap sideloaded? It seems it could be a good citizen touching only its dirs.
<mvo> ogra_: I created an arm64 alls-snap image but can't test it because i have no board
<ogra_> elopio, because it is annoying to fish your files out of SNAP_APP_USER_DATA_PATH
<ogra_> mvo, damn and i didnt bring mine to the UbuCon
<mvo> ogra_: if you have the HW maybe we can talk about this tomorrow?
<mvo> ogra_: oh, you are at ubucon, ok
<mvo> ogra_: no worries then, its not urgent
<elopio> ogra_: maybe a link to ~/Downloads.
<ogra_> yeah, sorry .... i was pondering to bring it with me but found it to risky to lose it
<mvo> ogra_: I guess all my irc message will show up on your other client when you are back home ;)
<ogra_> hmm, let me kill that
<ogra_> (and yes, you might be right)
<fgimenez> elopio, about https://travis-ci.org/ubuntu-core/snapcraft/jobs/103540103, it seems that it's trying to send the info stored under /home/ubuntu, the path where the tests were executed inside the container
<fgimenez> elopio, but outside the container that route doesn't seem to exist, maybe you should execute coveralls inside the container? or change the path in the report?
<elopio> fgimenez: I mount the path, so it's the same dir in the container and in the host.
<elopio> *should be. At some point it worked.
<elopio> I tried executing coveralls inside the container, and it complained about many things. I can retry that.
<elopio> ahh, maybe there's something new here. It didn't seem to link the coverage with the absolute path before.
<fgimenez> elopio, now when it sends the report it looks for paths like /home/ubuntu/snapcraft/__init__.py, as in "No source for /home/ubuntu/snapcraft/__init__.py"
<elopio> yeah, that's a good clue.
<fgimenez> leaving, have a nice day o/
<kyrofa> mvo, FYI, installing regular old Ubuntu on the rpi2, make works fine
<sergiusens> kyrofa, yes, I did try the classic dimension, it is how I built the face stuff
<sergiusens>  ogra_, mvo I think that olli is bringing one for me here, I can lend it while here
<Lefteris`> elopio: ogra_: yeah an emacs sideloaded snapp would be perfect for debuging and dev purposes. Should not be that hard to make.
<kyrofa> sergiusens, yeah that's what I thought. It's odd-- I tried it twice, on two different SD cards, and make was segfaulting
<kyrofa> sergiusens, I finally just installed Ubuntu on one of the SD cards and now it works fine
<kyrofa> sergiusens, no clue what's happening
<kyrofa> sergiusens, it works for both you and mvo
<elopio> Lefteris`: it would be fun to explore the integration with elpa.
<elopio> how a snap can install "plugins".
<Lefteris`> :)
<sergiusens> kyrofa, is your clock bonkers?
<kyrofa> sergiusens, currently it's UTC. I didn't check in ubuntu core though-- you think that would cause `make -v` to segfault?
<sergiusens> kyrofa, no, not really
<kyrofa> sergiusens, yeah... a head scratcher for sure. I didn't see anything odd here-- you? http://pastebin.ubuntu.com/14582510/
<sergiusens> kyrofa, try make on something simpler. Why does it stat all the dev nodes?
<kyrofa> sergiusens, that was only a make clean-- a single rm -rf call
<kyrofa> sergiusens, I got the same thing from `make -v`
<kyrofa> sergiusens, which obviously does _nothing_
<kyrofa> sergiusens, great question regarding the stat. No clue
<sergiusens> ah, weird; do you have anything strange hooked up to your device which would cause the stat call to die?
<kyrofa> sergiusens, no, and they aren't dying-- they're returning 0 (no error)
<kyrofa> sergiusens, hmm... actually I wonder now if the piglow might have something to do with it
<kyrofa> sergiusens, that's the only thing hooked up. Do you have one hooked up?
<sergiusens> kyrofa, classic is a container iirc, so accessing things that are denied might cause unexpected behavior on old software
<sergiusens> kyrofa, no, I have  a barebones pi2; from before the merch was avail
<kyrofa> Hmmmmm.... mvo how about you?
<kyrofa> sergiusens, after I finish building here I'll try taking it off and trying again
<sergiusens> kyrofa, he has a regular one as well iirc
<kyrofa> sergiusens, but yeah... make does more than I thought, apparently :P
<sergiusens> ogra_, can you sponsor an upload for me?
<kyrofa> elopio, can you verify that I can set bug #1534802 to Fix Committed?
<ubottu> bug 1534802 in Snapcraft "gopaste example fails because sqlite tries to chown" [Undecided,New] https://launchpad.net/bugs/1534802
<enoch85> kyrofa, hey, now I'm online
<kyrofa> Hey enoch85 :)
<elopio> kyrofa: nop, the bug is still there. What I made was a workaround to get the example running.
<kyrofa> elopio, ah, okay
<elopio> maybe a better name for the bug would be good.
<blr> JamesTait: they're endangered, and their numbers are declining... predation from introduced species (stoats) and apparently climate change is affecting fish stocks.
<JamesTait> blr :(
<vir17> can I use python to create snaps?
<kyrofa> vir17, you mean can python be used within a .snap?
<vir17> yes
<kyrofa> vir17, certainly
<kyrofa> There are py2 and py3 examples here: https://github.com/ubuntu-core/snapcraft/tree/1.x/examples
<vir17> thanks kyrofa very useful :)
<fazer> can someone look at this please: https://github.com/ubuntu-core/snapcraft/pull/245
<kyrofa> fazer, I've gotcha
<kyrofa> Sorry for the delay
<fazer> thanks
<fazer> no problem
<kyrofa> fazer, looks like you got the squash, though?
<fazer> kyrofa, yup, it was pretty painful the first time. But the second was better. I understood what exactly I was doing, better.
<kyrofa> fazer, excellent! Yeah this looks great
<fazer> kyrofa thanks. much appreciated
<kyrofa> fazer, no problem, you're getting pretty good at jumping through the hoops!
<kyrofa> elopio, I learned the downside of specifying multiple build threads all the time
<kyrofa> Gaaah.... come on rpi2... you can do it...
<kyrofa> elopio, I need a cluster of rpis just to build stuff
<elopio> kyrofa: hah, but with a single thread isn't it just as slow?
<kyrofa> elopio, well I'd bump it back up, duh :P
<kyrofa> elopio, this has been running since this morning
<elopio> I have a cluster of two rpis here :)
<kyrofa> Hahaha
<kyrofa> elopio, got a sec for a python question?
<elopio> kyrofa: sure.
<kyrofa> elopio, if your code is built using setuptools, is easy-install.pth required to run it?
<elopio> ja, no idea. Maybe barry is around.
<barry> heyho
<kyrofa> Ah, barry was my backup plan
<kyrofa> Hey barry!
<barry> kyrofa: hi!
<kyrofa> barry, I don't know anything about setuptools
<barry> kyrofa: ok
<kyrofa> barry, but I'm curious if easy-install.pth plays a role at runtime, or if it's more of a version manager. What happens if it's not there?
<barry> kyrofa: where do you see easy-install.pth?  pth files are kind of an abomination ;)
<barry> they hack the path in non-evident ways
<kyrofa> barry, bug #1531570
<ubottu> bug 1531570 in Snapcraft "Can't have two python3 parts using setuptools" [Undecided,New] https://launchpad.net/bugs/1531570
<barry> looking
<kyrofa> barry, yeah, and I'm wondering if it buys you anything in a .snap
<barry> kyrofa: can you pastebin what's in that .pth file?  you should be able to delete it since it shouldn't be doing anything that isn't already set up (e.g. modifying sys.path, but .pth files can do other evil things).
<kyrofa> barry, here's one of them: http://pastebin.ubuntu.com/14585410/
<kyrofa> barry, and the other: http://pastebin.ubuntu.com/14585415/
<barry> kyrofa: okay, i think i see what these are doing.  i don't think you strictly need the .pth files if you have control over the command line and can e.g. export PYTHONPATH=foo.egg:bar.egg
<kyrofa> barry, alright, I'm experimenting now
<kyrofa> barry, thank you for your help!
<barry> essentially i think that's what this .pth file is doing-  putting some eggs on sys.path.  eggs essentially fancy zips that python can import from
<barry> kyrofa: k, good luck!
<kyrofa> So as long as they're in the path, it should work regardless
<barry> right
<elopio> I'm going to finish earlier today to attend a workshop about mqtt.
<elopio> bbl
#snappy 2016-01-21
<noizer> Hi
<noizer> im looking into snappy these days but i want to install the boost library on snappy but how can I do that
<noizer> anyone that can help me
<elopio> noizer: you can use snapcraft to generate a snap that will consume the library
<elopio> or you can use the classic mode while you are developiong something.
<noizer> will boost then can be used of anny snap that i will deploy on it?
<sergiusens> kyrofa, still around? I hope :-)
<kyrofa> sergiusens, yeah hey :)
<kyrofa> sergiusens, got your email
<sergiusens> kyrofa, I just hacked ROS_MASTER to made up hostname and configured that in /etc/hosts
<kyrofa> sergiusens, well, you just saved me some typing
<sergiusens> kyrofa, just because I just read this " Great care should be taken when using localhost, as that can lead to unintended behaviors with remotely launched nodes. "
<sergiusens> kyrofa, we should make our plugin do export VAR=http://$(hostname):####
<sergiusens> kyrofa, lets see how it goes :-)
<sergiusens> kyrofa, how's everything with you, all good today?
<kyrofa> sergiusens, I'm not convinced that will change things, but if it doesn't, I bet it's still hostname-related. I have more ideas for you
<sergiusens> kyrofa, maybe start shooting them out :-)
<kyrofa> sergiusens, today was a bit frustrating. rpi problems. But I worked through them, things are building
<sergiusens> kyrofa, 16.04? Did unplugging the piglow thing work btw?
<kyrofa> sergiusens, right so, when nodes communicate they provide contact info: "here's how to reach me"
<kyrofa> sergiusens, thing is, by default they use their hostnames
<kyrofa> So when setting up a ROS cluster, we always make sure each computer has the others in /etc/hosts
<kyrofa> But an alternative is to use the ROS_IP variable
<sergiusens> kyrofa, I have /etc/hosts setup now, more so because setting up ROS_IP on the snap would be painful
<kyrofa> Which allows you to skip using hostnames all together
<sergiusens> kyrofa, I tried ROS_IP on the plain ubuntu box, didn't work out that well
<kyrofa> Yeah, but snappy doesn't have a real hostname right? It's "localhost"?
<kyrofa> So you may want to set ROS_HOSTNAME on the device as well
<sergiusens> kyrofa, I can set one
<sergiusens> kyrofa, using snappy config
<kyrofa> Oh interesting. It's odd that I didn't run into this, but yeah: the surefire way to make this work is to use hostnames all the way through. dev computer has a hostname that snappy can resolve, snappy has a hostname that dev can resolve, set the ROS_MASTER_URI to localhost on snappy, set it to snappy's IP on dev
<kyrofa> sergiusens, I'm going to have to sit down and make sure we have a config that actually works for this use-case
<sergiusens> kyrofa, right, so when you say "ROS_MASTER_URI to localhost on snappy" I think we want it to be the hostname and not localhost
<sergiusens> from what I saw in the wiki
<kyrofa> sergiusens, that should be fine. I've never done it, but I can't imagine it'll hurt anything
<kyrofa> sergiusens, how was this working for you previously? Did you change your network setup somehow?
<sergiusens> export ROS_MASTER_URI=http://rpi2:11311
<sergiusens> export ROS_HOSTNAME=rpi2
<sergiusens> kyrofa, that's my setting now on the rpi2
<kyrofa> sergiusens, if rpi2 is actually its hostname, I don't think you need ROS_HOSTNAME
<sergiusens> ping rpi2 and ros-trusty (my hostnames) works from either side
<sergiusens> kyrofa, I'm setting it up just in case
<kyrofa> sergiusens, alright
<kyrofa> sergiusens, yeah your setup sounds good. Settings on the dev machine?
<sergiusens> kyrofa, export ROS_MASTER_URI=http://rpi2:11311
<sergiusens> ubuntu@ros-trusty:~$ vi /etc/host
<sergiusens> oops
<sergiusens> just the export :-)
<kyrofa> sergiusens, yeah fire away
<sergiusens> rostopic and rosnode still work with that setting
<sergiusens> kyrofa, waiting for the squash now ;-)
<kyrofa> sergiusens, nice. And no-- I'm still waiting for the owncloud build. Now you know why this has taken me so darn long
<sergiusens> kyrofa, hah
<kyrofa> sergiusens, compiling mysql died several times for lack of RAM. I started using swapfiles... 1G... 2G... screw it, plugged in a flash drive, 16G swapfile
<sergiusens> kyrofa, I've been considering scalingstack
<kyrofa> sergiusens, do they have ARM?
<kyrofa> sergiusens, I just learned about the alpha launchpad .snap builds, too
<kyrofa> sergiusens, I asked to get in on that
<sergiusens> kyrofa, I probably got the name wrong though
<sergiusens> it is arm exclusive
<kyrofa> Oh... hmm yeah that doesn't seem arm exclusive
<kyrofa> 96%...
<sergiusens> kyrofa, working!
<kyrofa> sergiusens, yes!
<sergiusens> kyrofa, going downstairs for a bit
<kyrofa> sergiusens, okay :)
<sergiusens> kyrofa, I've documented the recipe, so I'll share later ;-)
<kyrofa> sergiusens, sounds good
<kyrofa> sergiusens, my cell# is in the directory if you need me and I'm not around
<kyrofa> 100%!
<snappy-user> kyrofa hello I am just testing :-)
<fgimenez> good morning
<opmodoro> good morning, in the webchat snapcraft example I see an `apps` directive usage, but in the source there is no mention about it. Where is the magic? :)  Thanks
<elopio> pindonga: beuno: I'm dangerously close to get the xenial tests back to green. static, unit, integration and coveralls are working.
<elopio> Just need to figure out why the examples started to fail yesterday. So ETA, one more day.
<LefterisJP> guys for a user providing some extra configuration to a framework is there any standard way? What I can imagine is having a config file in the framework's writable location and then have the wrapper script of the service read that config file to see what args to use when launching the service.
<LefterisJP> Then an extra binary to query/edit the config for the framework
<JamesTait> Good morning all; happy Thursday, and happy Hugging Day! ð
<joeblew99> basic question. All applications in ubuntu core snappy run inside LXD. So can it run gui apps like Google chrome ?
<kyrofa> Good morning
<kyrofa> LefterisJP, might be a use for snappy config
<kyrofa> LefterisJP, https://developer.ubuntu.com/en/snappy/guides/config-command/
<kyrofa> joeblew99, that's not correct-- they don't run inside an LXD
<kyrofa> joeblew99, however, supporting things like .desktop files is work that ongoing
<kyrofa> joeblew99, so yes, eventually, but only in betas right now
<kyrofa> joeblew99, https://rainveiltech.com/posts/prototype-a-gui-friendly-snappy
<LefterisJP> kyrofa: looks interesting. So there should be a binary inside the app that can read and output yaml syntax. But seems there is no way to set specific config option from the CLI, just provide a new yaml file to replace the old one.
<kyrofa> LefterisJP, yeah kinda. ogra_ may be your best resource here-- I know for certain he's used this. I'm not sure of its capabilities
<LefterisJP> all right will wait for his input then
<LefterisJP> one more question. I have been trying to turn a snappified directory project to a snapcraft project. How can I make a snapcraft, part of recipe for: 1) Clone repository 2)run specific commands on the repo to produce binaries 3) copy these binaries to the staging area.
<LefterisJP> Also the various profiles and other data that go in the meta/ directory for a snappified directory app, how can they be included when creating a snap from snapcraft?
<kyrofa> LefterisJP, alright let me make sure I understand
<kyrofa> LefterisJP, you have a project with some sort of build system (even if it's just scripts). You want snapcraft to clone that project, run the build system, and include the binaries in the .snap?
<kyrofa> LefterisJP, that sounds exactly like what snapcraft does. Am I missing something?
<kyrofa> LefterisJP, but your build scripts also produce the meta/ stuff?
<kyrofa> LefterisJP, sorry... I'm feeling a little dense this morning :P
 * kyrofa pours his coffee
<LefterisJP> hehe so let's see
<LefterisJP> I currently have 1 project which is bassically a readymade directory on which I snappy build
<LefterisJP> But I already have the binaries built and ready under bin/
<kyrofa> Okay, with you so far. And you don't use snapcraft because... cross compiling?
<LefterisJP> yes
<kyrofa> Okay, continue
<LefterisJP> But if the user has the appropriate libraries, I can actually make it cross-compilable, since this is a go-project and the developers have made a very handy makefile (which resorts to go build eventually)
<LefterisJP> so I just want to clone the repo and run make with 2 different arguments
<LefterisJP> and then take the 2 produced binaries
<LefterisJP> and from then an on continue as I would with a normal snappy build
<kyrofa> Hmm, and are these "appropriate libraries" available in the ubuntu repos for a given arch? Say amd64 or whatever you're running on
<kyrofa> LefterisJP, or are they other things you need to clone and build?
<LefterisJP> no they are there
<LefterisJP> only need to clone this one repo
<kyrofa> LefterisJP, ahh.... you just might be able to get this to work
<kyrofa> LefterisJP, okay. Are these libs build-time dependencies then, not run-time?
<LefterisJP> yes, since it's go everything is statically linked. I already do this manually, and have it working on a Raspberry Pi. Just wanted to automate it with snapcraft
<kyrofa> LefterisJP, excellent. Automation is good
<kyrofa> LefterisJP, can you add a target to the repo's makefile to run both make commands that you need?
<kyrofa> LefterisJP, or is this a third-part repo you're cloning?
<LefterisJP> I don't think this is an option
<kyrofa> LefterisJP, alright, you need to do a bit more work then
<LefterisJP> I saw there is a make plugin, but that seems to run only make
<LefterisJP> (no args)
<kyrofa> LefterisJP, with my limited understanding of what you're doing, I'd use `build-packages` to pull in those libs, and use the `make` plugin with `source: src` and in the src folder create a Makefile to clone your source and run the necessary commands
<kyrofa> LefterisJP, essentially use the Makefile as a script
<kyrofa> LefterisJP, keep in mind that the only targets the `make` plugin uses is `all` and `install`
<kyrofa> And the `install` target is called with DESTDIR
<LefterisJP> hmm is there a way to use a "script" plugin? Just write a script and call it as part of the preparation of building the snap?
<kyrofa> LefterisJP, not included with snapcraft. But did you know you can actually include your own plugin in-tree?
<kyrofa> And use it in the snapcraft.yaml?
<LefterisJP> nope. That's funny though. There are so many plugins, I would expect one for a simple script to exist.
<kyrofa> LefterisJP, I just use the `make` plugin when I want a simple script. How would you expect snapcraft to tell the script where to put stuff?
<kyrofa> LefterisJP, all the other plugins have established ways to do that (make, autotools, cmake, go)
<LefterisJP> call it with an argument which would be interpreted as a path I suppose
<kyrofa> LefterisJP, yeah, that might be a useful addition. Feel like logging a bug?
<kyrofa> LefterisJP, regarding custom plugins: https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md
<LefterisJP> Sure, is it https://github.com/ubuntu-core/snapcraft?
<kyrofa> LefterisJP, that's the src, but bugs are tracked here: https://bugs.launchpad.net/snapcraft/
<LefterisJP> thanks for the link, will check it out right now.
<kyrofa> LefterisJP, if you come up with a generic script plugin that you like feel free to propose it to snapcraft
<LefterisJP> Would love to. So that would be as a Github PR?
<kyrofa> LefterisJP, indeed. Bugs are tracked at LP, everything else on github
<kyrofa> LefterisJP, check out the HACKING.md as well as the CONTRIBUTION.md
<kyrofa> LefterisJP, it'll need some test coverage as well (see the other plugins for examples)
<LefterisJP> noted, thank you. If I come up with something good in time I will send it back upstream.
<elopio> kyrofa: there seems to be a problem in hangouts. Could you get in the call?
<kyrofa> elopio, google has been annoying lately
<kyrofa> elopio, want to try again later?
<elopio> kyrofa: what if we try https://meet.jit.si/snapcraft ?
<elopio> seems to work here.
<kyrofa> Agh, elopio sorry got distracted. I'll be right there
<kyrofa> elopio, that doesn't seem to be working for me either...
<elopio> kyrofa: :) want to stand up here?
<kyrofa> elopio, works for me!
<kyrofa> elopio, your turn first
<elopio> DONE: update integration tests working on snappy rpi2, coveralls reporting working again from travis lxd, attended the mqtt class and got the mosquito server and client working on rpi2 classic.
<elopio> TODO: understand the examples errors in jenkins (when I put prints they stop raising an exception :@), make a snapcraft for mosquitto, more work on the jenkins snapcraft jobs.
<elopio> kyrofa: your turn.
<kyrofa> Awesome
<kyrofa> DONE: Built owncloud package for amd64 and uploaded to store.
<kyrofa> DONE build owncloud package for armhf but then realized I couldn't upload to the store
<kyrofa> TODO: Removing amd64 version from the store, uploading new armhf version to replace it
<kyrofa> TODO: Got emailed several papercut bugs last night. Turning them into real bugs and fixing the low-hanging fruit
<kyrofa> elopio, ^^
<elopio> thanks.
<elopio> @fgimenez I think I need to go and pick up the car of a friend that's traveling, soon. So I might miss our standup.
<nothal> elopio: No such command!
<elopio> anything you would like to discuss today?
<elopio> ahh, telegram is affecting me.
<fgimenez> elopio, ok :) i have a couple of PRs and another one is coming, no rush at all anyway
<elopio> fgimenez: I'll get to them soon.
<fgimenez> elopio, thx also there was an error in the integration tests yesterday caused by with https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/autoupdate-msg_test.go#L53, could you take a look? if we can't rewrite it maybe it should be dropped, let me know what do you think
<elopio> fgimenez: from my side, I had to trick travis using the same path in the container and in the host. Now the coveralls works again.
<elopio> I tried everything I could think about to send the report from the container, and got every possible error.
<fgimenez> elopio, great, it's working so \o/
<elopio> fgimenez: well, now the problem are the examples tests. They raise and exception, but when I try to print the stderr, it's not raised.
<elopio> damn it with travis.
<fgimenez> elopio, let me know if i can be of any help
<elopio> fgimenez: about that test, I would prefer to discuss with mvo about possible solutions. It was one of the first tests added after a UI change, so I wouldn't like to remove it.
<elopio> I'm fond of it :)
<elopio> fgimenez: is it failing often, or was it just one time weirness?
<elopio> I can put it in a loop.
<fgimenez> elopio, only once in a lot of executions
<elopio> this is a great use for jenkins.
<elopio> just loop running one test to get more info. I'll try to make the job soon, but I still owe a couple of things from yesterday.
<elopio> like the dockers in the hub. I'll finish that first.
<mvo> elopio: we make it a long operation by creating a fake os update first
<mvo> elopio: well, longer - and also throttle the download of the fakestore
<elopio> ahh, that's right. Now the update takes a lot less.
<elopio> ok, going for the car. bbs.
<elopio> that was a lot faster than what I thought.
<elopio> and now I have a car for the rest of the week. No idea what to do with it, though.
<kyrofa> elopio, hahaha
<elopio> kyrofa: can you give me a hand debugging this? https://paste.ubuntu.com/14590836/
<elopio> how can I see what causes make to exit != 0? is there a verbose flag or something?
<kyrofa> elopio, that's the most unhelpful error message I've ever seen :P
<mvo> jdstrand: thanks for your work on the squashfs-tools \o/
<kyrofa> elopio, with cmake you can to VERBOSE=1
<kyrofa> elopio, but the actual error should be above what you pasted...
<jdstrand> mvo: sure. Now I need to see about different archs. I see some code about little endian vs big
<mvo> jdstrand: iirc its nowdays (v4) all one endianess, that might be from the old v2 or v3 squashfs format. but mind you, I'm not an expert :)
<jdstrand> mvo: oh, btw, kgunn needed a new os snap for the latest ubuntu-core-security when you have a chance. I don't hink he is blocked on it per se (perhaps he can comment)
<jdstrand> mvo: we'll see! :)
<mvo> jdstrand: sure, happy to update. amd64?
<jdstrand> I think so
<jdstrand> kgunn: ^ ?
<mvo> ta
<kyrofa> elopio, can I see more of that log?
<kyrofa> elopio, is that in travis somewhere?
<elopio> kyrofa: I tought python was swallowing the stderr, but it seems it just doesn't print anything.
<elopio> ubuntu@xenial:/home/elopio/build/snapcraft/examples/ros/parts/catkin-tutorials/build/build_isolated/beginner_tutorials$ VERBOSE=1 make -j2 -l2 || echo $?
<elopio> 139
<elopio> kyrofa: yes, one second.
<elopio> kyrofa: https://travis-ci.org/ubuntu-core/snapcraft/jobs/103794957
<elopio> search for Failed to process package 'beginner_tutorials'
<kyrofa> elopio, wow, that really is all it gave you
<kyrofa> elopio, I have no idea what happened there. Yeah, try the verbose
<elopio> kyrofa: but did you see my line with verbose above? It exits with 139, but prints nothing.
<kyrofa> elopio, ...
<kyrofa> elopio, I'm honestly clueless. I've never seen that
<kyrofa> elopio, what are you testing here?
<kyrofa> elopio, the only time I've seen anything similar was yesterday, when make was segfaulting for me
<elopio> that's what I hate about this. I'm sure I saw it before, at some time. But I've seen so many travis errors this days that I'm confused.
<elopio> kyrofa: I'm trying ot build from a xenial lxd.
<elopio> at least now I can reproduce it on my local xenial lxd, so I don't have to wait for travis' output.
<kyrofa> elopio, I'm so tired of ROS barfing on xenial
<elopio> kyrofa: oh, but there are 7 tests failing with the same.
<elopio> sorry, I picked you on ros because I thought you would magically tell me the solution :)
<kgunn> mvo: jdstrand yep, amd64
<kyrofa> elopio, hmm. You can reproduce on xenial though? Are they all `make` failures?
<elopio> kyrofa: I'm trying that, but the costa rican archive is out of sync. So trying another mirror and goes even slower...
<elopio> will know soon.
<kyrofa> elopio, AH! mvo
<kyrofa> elopio, mvo just installed make on my xenial lxc. IT SEGFAULTS!
<kyrofa> elopio, I bet you $100 that's your problem
<kyrofa> elopio, oh I'm so happy I'm not insane
<mvo> kyrofa: ohhhh! so a real upstream make bug!
<kyrofa> mvo, yeah!
<kyrofa> mvo, dang. That's so upstream I don't even know where I'd log such a bug
<elopio> oh come on, now also the main archive gives a hash mismatch.
<elopio> kyrofa: what command are you running to get the segfault?
<kyrofa> elopio, make -v :P
<kyrofa> elopio, everything seems to segfault except make -h
<elopio> oh, wow.
<kyrofa> Yeah, terrible
<elopio> it segfaults when I run it as root, but when I run it as user it doesn't say anything.
<elopio> pindonga: I give up. Even make is failing on me.
<kyrofa> elopio, yeah I went back to good-old trusty
<kyrofa> trusty trusty
<pindonga> elopio, :(
<elopio> kyrofa: so, this happens only on xenial lxc, right? on your real xenial machine it works?
<kyrofa> elopio, I fist experienced in on my rpi2 in classic, so no
<kyrofa> Well wait
<kyrofa> That's actually lxc too
<kyrofa> right?
<kyrofa> mvo, ^^
<kyrofa> elopio, I don't actually have a xenial machine
<mvo> kyrofa: not lxc, more like a chroot, it using unshare lightly but mostly a chroot
<elopio> kyrofa: same version in real machine and in container. 4.1-2. It only fails in the container.
<kyrofa> elopio, very interesting!
<mvo> kgunn: I put an updated ubuntu-core snap into the edge channel, once I tested it I will promote to the other channels (I guess you will still get it because all images default to edge iirc currently)
<kgunn> mvo: ta
<mvo> yw
<elopio> it works from gdb.
<elopio> mvo: any idea who to ping about this make segfault?
<elopio> https://paste.ubuntu.com/14591130/
<kyrofa> elopio, easy review when you have a minute: https://github.com/ubuntu-core/snapcraft/pull/246
<elopio> kyrofa: was the change in the indentation on purpose?
<kyrofa> elopio, yeah, it's not valid markdown
<kyrofa> elopio, and we have another PR that wants it done but it hasn't been updated in a while
<kyrofa> elopio, so I figured I'd just tackle it here
<elopio> so it was a trap!
<elopio> simple, but I have to read it all :)
<kyrofa> elopio, yeah, stupid git
<elopio> don't worry, I'm on it.
<kyrofa> elopio, if you trust me, I promise all I added was the build-packages
<elopio> kyrofa: ok, I will trust you but just because I'm hungry ;)
<kyrofa> elopio, mmm
<mvo> elopio: did you got an anser already? do you have some more info? so it happens on amd64 in a lxc xenial env, right?
<Lefteris`> kyrofa: I managed to automate it as I had planned with a nice local plugin for snapcraft.
<Lefteris`> kyrofa: What does not work now is the framework's policy
<Lefteris`> kyrofa: Before I had the framework policy in meta/
<kyrofa> Lefteris`, you'll need to specify it in the snapcraft.yaml. Did you?
<Lefteris`> same level as package.yaml, but now with snapcraft how do I do it?
<Lefteris`> (no I did not write anything in snapcraft)
<Lefteris`> in short everything I had in meta/ when I snapify a directory ... where should it be if I use snapcraft?
<enoch85> kyrofa, here?
<kyrofa> enoch85, yessir!
<Lefteris`> hmm there is an integration test having `framework-policy: dir` inside a snapcraft yaml
<Lefteris`> will go with that :)
<elopio> mvo: sorry, late reply. I reported this: https://bugs.launchpad.net/ubuntu/+source/make-dfsg/+bug/1536727
<ubottu> Launchpad bug 1536727 in make-dfsg (Ubuntu) "make crashes in xenial lxc" [Undecided,New]
<kyrofa> elopio, even easier than the last one: https://github.com/ubuntu-core/snapcraft/pull/248/files
<kgunn> mvo: hmm, just pulled an image using core rolling --oem=generic-amd64/stable --channel edge...and system-image-cli -i shows it's from jan 12, expected?
<kgunn> thot it might be updating soon..
<mvo> kgunn: yes, we stopped updating using system image, please use http://people.canonical.com/~mvo/all-snaps/ for now, unfortuantely the ubuntu-device-flash in xenial is not updated there is a branch review pending still
<kgunn> np, thanks mvo
<mvo> kgunn: here is a bit of the background https://lists.ubuntu.com/archives/snappy-devel/2016-January/001400.html
<circ-user-edG3L> hi
<circ-user-edG3L> how do i download xenial version of snappy?
<circ-user-edG3L> or is that not available currently?
<kyrofa> circ-user-edG3L, use http://people.canonical.com/~mvo/all-snaps/
<circ-user-edG3L> kyrofa: k thx
<circ-user-edG3L> kyrofa: are you at the ubucon?
<kyrofa> circ-user-edG3L, note that it's under heavily development, though
<kyrofa> circ-user-edG3L, unfortunately no. Too close to having a baby to leave!
<circ-user-edG3L> kyrofa: oh.  congratulations!.
<kyrofa> circ-user-edG3L, haha, thanks
<circ-user-edG3L> kyrofa:  is mir spec for xenial ready yet? or still being modified?... is there a timeline for mir/xmir ?
<kyrofa> circ-user-edG3L, kgunn is your man there
<circ-user-edG3L> kyrofa: k thx
<dbuellough> hello
<circ-user-edG3L> kgunn: is mir spec for xenial ready yet? or still being modified?... is there a timeline for mir/xmir ?
<circ-user-edG3L> dbuellough: hi
<kyrofa> circ-user-edG3L, did you just see sergio and manik's talk?
<ogra_> still running :)
<circ-user-edG3L> kyrofa: im watching it now
<kyrofa> circ-user-edG3L, the live stream is broken :(
<circ-user-edG3L> kyrofa: https://www.youtube.com/watch?v=1C8T4Mp9aSM
<circ-user-edG3L> kyrofa: it works
<kyrofa> circ-user-edG3L, terrible audio here
<circ-user-edG3L> kyrofa: :{
<enoch85> I can confirm that audio is bad
<camako> Trying to publish a snap on the store. It fails with "ERROR: manifest malformed: hooks/mir-server is empty...". How do I fix this?
<camako> My snap -->  https://myapps.developer.ubuntu.com/dev/click-apps/share/4255e10a7324e99961bb6a15b0c4368692e318870c3e527339100387379a08c96802720a73162eabafce/
<kgunn> circ-user-edG3L: i assume you're asking here so specific to snappy?
<kgunn> we have it working, just worked thru sec profiles for mir recently with the sec team...so waiting for those to flow thru
<circ-user-edG3L> kgunn: yes.
<circ-user-edG3L> kgunn: ok.  so spec is finalized?
<circ-user-edG3L> kgunn: or still tbd?
<circ-user-edG3L> kyrofa: I recorded the demonstration if you want to see it
<kyrofa> circ-user-edG3L, yes please
<circ-user-edG3L> kyrofa: can i have your email address to send?
<circ-user-edG3L> kyrofa: im uploading to youtube
<kyrofa> circ-user-edG3L, just paste the url here if you don't mind, I'm sure other people would like to watch as well
<aatchison> hello!
<sergiusens> aatchison, http://people.canonical.com/~mvo/all-snaps/
<sergiusens> utlemming, hey, I'm getting reports from aatchison that the vagrant images don't work. Are you still maintaining those?
<utlemming> sergiusens: interesting...
<utlemming> sergiusens: yup, looking
<sergiusens> utlemming, also, out of the blue, do we have rolling/all snaps images for vagrant?
<utlemming> sergiusens: I haven't checked since last week, but if that is the default for u-d-f, then yes
<aatchison> I'll paste bin the results
<sergiusens> utlemming, oh, it's not; it needs a non backwards compatible u-d-f
<utlemming> sergiusens: then we do not
<aatchison> http://paste.ubuntu.com/14593617/
<sergiusens> utlemming, can we use a different u-d-f to set that up? Calling a different image creator?
<utlemming> aatchison: windows/mac?
<utlemming> sergiusens: can you send me the instructions on that? Better yet, file me a bug with the instructions and I can try to get to it.
<aatchison> utlemming, Ubuntu 15.10
<aatchison> ok
<utlemming> aatchison: where did you procure your version of vagrant....this looks like a bug in Vagrant/Ruby, not in the image itself.
<utlemming> aatchison: double checking
#snappy 2016-01-22
<utlemming> aatchison: yup, confirmed....I just pulled it and it worked as expected.
<aatchison> utlemming, I just installed it today, but I'll check. I'm going to another talk at Scale, but I'll get back to this;)
<JamesTait> Good morning all!  Happy Friday, and happy Answer Your Cats' Questions Day! ð  ð
<jstephan> He guys, I am playing around with Ubuntu Core (snappy) on Raspberry, My project is in Python, any idea how I can get pip and compile some modules I need?
<asac> ppisati: i am playing with making a snapcraft plugin that builds kernel snaps from source without having to do a deb etc. as intermediate step and noticed that make install behaves odd in the sense that it does not just install the zImage etc. in INSTALL_PATH, buut it rather also tries to create a .deb etc.... any idea how i can do make install without that part?
<asac> jstephan: check out snapcraft ... it has python2/python3 plugins that should support pip
<ppisati> asac: not really, the deb packaging of the kernel is a bit convoluted
<ppisati> asac: try to ping apw, he might know better than me what to do
<ppisati> asac: but if i was you
<asac> apw: :)
<ppisati> asac: i would just create our config from our src tree
<asac> ppisati: so make install just magically assumes that i want to produce a .deb? wow :)
<ppisati> asac: e.g. fdrc && fdr-prepare-generic
<asac> ok.... and then?
<ppisati> asac: copy the config to a git tree and compile it there
<ppisati> oh wait
<asac> sure the compile is fine... i have features in myh plugin for providing a config file or using defconfig or use defconfig and overload a few CONFIGS etc.
<apw> asac, in the packaging we use like make boot/Zimage or whatever to get just the kernel bits of the right form and we make install_modules to make that
<asac> install is causing the trouble for me... it starts off doing the right thing (e.g. copy stuff to INSTALL_PATH)
<asac> but then it also goes and creates a deb
<apw> asac, but i would not expect make install to make a deb
<asac> right, but it does for me :(
<asac> latest torvalds trunk that is... but let me see
<tzununbekov__> asac, hey, have you seen our email to you?
<jstephan> asac: I will have a look
<asac> tzununbekov__: not sure... who are you :)?
<asac> tzununbekov__: jst /msg me the mail subjhect and i will look for it :)
<asac> apw: ok found that kernel make install runs /sbin/installkernel if that exists on system, which i would guess (as that is on my system from a package called debianutils) seems to be the one spoiling the raw make install show :)\
<asac> a bit sad that there is no switch to ignore an installkernel helper ... hmm.
 * asac gives up and makes custom code to fiddle the right bits out of tree instead of make install
<LefterisJP> kyrofa: As you suggested yesterday I made a PR for the suggested generic script snapcraft plugin: https://github.com/ubuntu-core/snapcraft/pull/252
<LefterisJP> ops, there is an error in another test. Fixing it now.
<apw> asac, would you not be making the bits for this in a chroot of your own making, so you can control if that is in there, ie supply like a snappy-build package which diverts the existing and replaces it with one yout want
<asac> apw: yeah, think i could do it, but then few lines o python that copies the *image is also goodie
<asac> thanks
<kyrofa> Good morning
<LefterisJP> kyrofa: Morning :)
<kyrofa> LefterisJP, thanks for the PR! I'll take a look :)
<renat> Hi all! It's Renat from Screenly.
<renat> I have a question again=)
<renat> How can I "sign" a snap, so I won't need to use --allow-unauthenticated flag to install a snap, or build an image?
<LefterisJP> kyrofa: addressed the remarks of your review
<kyrofa> renat, that's done in the store
<kyrofa> renat, though in 16.04 you'll be able to do it yourself with assertions
<renat> kyrofa, thanks!
<kyrofa> renat, it's a debsig. So while you could sign it, Ubuntu Core 15.04 is only setup to verify against a single key: the store's
<renat> kyrofa, didn't know. Thanks!
<kyrofa> renat, sure thing :)
<kyrofa> renat check out /etc/debsig/policies
<renat> kyrofa, one more question. About "follow symlinks"
<kyrofa> renat, ah, yes?
<renat> It was named "symlinks" before, and copied symlinks as symlinks only if it's value is true. But after I renamed it to follow symlinks - logic should change now. So follow-symlinks means "copy file instead of symlink", right?
<kyrofa> Ah, interesting point. Indeed, I agree. And I do agree that follow-symlinks is a more clear config name
<kyrofa> renat, what did you think of my dangling link comment, by the way?
<renat> We can add "ignore-dangling" option to control that behavior.
<kyrofa> renat, but read the docs for copytree-- I don't think that'll work
<renat> 1 min.
<kyrofa> renat, it only seems to apply when you're FOLLOWING the symlinks. If you're copying the symlinks it doesn't seem to care
<kyrofa> renat, here: "Changed in version 3.2: Added the copy_function argument to be able to provide a custom copy function. Added the ignore_dangling_symlinks argument to silent dangling symlinks errors when symlinks is false."
<renat> It only silences the error message.
<renat> You won't get error message if you copy symlinks as symlinks.
<kyrofa> renat, right, which means we can _create_ dangling symlinks
<kyrofa> renat, in this case, what I mean by dangling is symlinks that point outside the snap
<kyrofa> renat, they might be valid at the time of .snap creation
<kyrofa> renat, but not install/runtime
<kyrofa> renat, make sense?
<renat> Yes.
<renat> Understood.
<kyrofa> renat, as-is, copying everything following the symlinks, that's not a problem. So the only way I see to avoid introducing that problem is with a custom copy function that symlinks what it can and copies the rest
<kyrofa> renat, kind of annoying, granted
<kyrofa> renat, sorry :P
<renat> kyrofa, this approach is not very intuitive. You will need to add "smart-copy" and document its behavior then.
<renat> sorry, smart-copy option.
<kyrofa> renat, so perhaps you would argue that, if they turned the symlink following off, (I guess it should be on by default), they deserve the dangling symlinks since they should have known about them?
<kyrofa> renat, and it is indeed a corner case
<renat> kyrofa, yes. At least - they will know about it during testing.
<kyrofa> renat, maybe. It could be more insidious. I'll have to get my colleagues thoughts there
<renat> kyrofa, thanks.
<kyrofa> renat, sorry for the trouble, thanks for bearing with us :)
<renat> kyrofa, no problem. Let me return to work and generate more questions=)
<kyrofa> elopio, sergiusens and I have a meeting which may flow over standup
<pindonga> elopio, I've reworked my PR so it doesn't depend on xenial anymore... if you, kyrofa or someone else could please review it? https://github.com/ubuntu-core/snapcraft/pull/197
<pindonga> if you like the approach, I'll squash the commits and fix the coveralls errors
<kyrofa> pindonga, excellent use of discretion regarding the squashes. For future reference, checkout git commit --fixup. Makes the squash insanely easy
<pindonga> ack
<kyrofa> pindonga, https://robots.thoughtbot.com/autosquashing-git-commits
<pindonga> kyrofa, while ssoclient is already packaged in xenial, I proposed vendoring it in to avoid the blockage on getting tests running in xenial
<pindonga> this also enables snapcraft to include this feature in previous versions
<pindonga> eg, trusty
<kyrofa> pindonga, I've never vendored in python before. I guess elopio or sergiusens might need to speak on that
<kyrofa> pindonga, do you have experience with that?
<pindonga> kyrofa, not really, I've essentially looked what other people do
<pindonga> ideally I'd like not have to modify the vendored pkg import paths
<pindonga> so if someone more experienced in this area can suggest a way, +1
<kyrofa> pindonga, agreed
<elopio> good morning.
<kyrofa> elopio, good morning!
<elopio> pindonga: working around xenial seems the way to go. As the only thing that fails on travis are the examples, it's ok because the idea has been always to move that to jenkins. But yesterday the disk of the jenkins slaves got full. What a week to be QA...
<elopio> fgimenez: ^ did you see the slaves? I wasn't sure what I could delete.
<elopio> kyrofa: np about the standup. If you want to do it, ping me when ready.
<mvip> mectors: We have a blocking issue for Screenly on MWC. The bug is filed here (https://bugs.launchpad.net/snappy/+bug/1500755). Any chance you or someone could bump up the priority for that one?
<ubottu> Launchpad bug 1500755 in Snappy "bootloader firmware needs update to get vchiq working with 4.2" [High,Confirmed]
<pindonga> elopio, right, I also think vendoring in this case makes sense to prevent snapcraft requiring xenial from now on
<pindonga> not sure what's the best way to vendor stuff in cases like this though
<elopio> I'll check.
<elopio> pindonga: first thing I see is that your branch drops coverage 7%.
<pindonga> yes, am looking at that
<pindonga> but I was mostly concerned whether you're ok with the vendoring of ssoclient
<pindonga> elopio, and tbh, that coverage drop is only there bc I've modified main.py and it didn't have enough coverage to begin with
<pindonga> :)
<elopio> right, I'm not saying you have to get it back to 90%. Just looking :)
<elopio> pindonga: so, how do we run the tests of that vendor package?
<pindonga> elopio, I didn't include the tests for the vendored packages as those should be tested upstream
<pindonga> and considered here just as an external library
<pindonga> vendored in for convenience only
<pindonga> ie, we don't test them
<elopio> pindonga: um, I get the idea. And why don't we just put it in a different repository, package them and import them here?
<pindonga> package as in deb packaging?
<pindonga> that's what we're trying to avoid here
<pindonga> new packages should go via xenial
<pindonga> also, it's quite an overhead
<pindonga> and this code might evolve in ways incompatible with deb pkg lifecycles
<elopio> ah right right. I don't like this, copying code into the repository without running its tests. What about a git submodule?
<elopio> pindonga: lets say we want to make a release suddenly. How can we be sure that the new code works with this vendored library?
<sergiusens> elopio, want to do the standup now?
<elopio> sergiusens: yes.
<pindonga> elopio, there are tests for the commands that use the vendored lib
<pindonga> elopio, I could include the upstream tests here as well if you like, but I see little to no benefit
<pindonga> as long as the upstream lib doesn't change it's api this should work ok
<pindonga> and since we control those upstream apis we should make sure to update snapcraft when/if they change
<elopio> pindonga: ok. Let me read it fully after the call.
<pindonga> ack
<Chipaca> JamesTait: question, is there a way in cpi to search only on the package name?
<JamesTait> /api/v1/search?q=name:%22package_name%22 should work I think?
<JamesTait> e.g. https://search.apps.ubuntu.com/api/v1/search?q=name%3A%22com.ubuntu.music%22&page=1
<elopio> ping jdstrand: do you have some time to help me here? https://github.com/elopio/snapcraft/commit/43d6ed402f98fa39046d455ffdcbbde0a244c943#commitcomment-15606270
<JamesTait> Chipaca, yay?
<fgimenez> elopio, sorry didn't notice it, it's the same problem we had with devicemapper http://paste.ubuntu.com/14597997/, hopefully we'll have a new server deployed in a few minutes
<jdstrand> elopio: I planned on giving you a hand but wasn't ready just yet. I will ask-- what is this on 15.04 or 16.04?
<mvip> mectors: Cool. Thanks.
<elopio> jdstrand: 16.04, all snaps.
<elopio> jdstrand: but don't hurry, whenever you have time. I was just wondering if you got the ping.
<jdstrand> I did
<pindonga> elopio, btw, pushed a new test that improves coverage
<elopio> pindonga: saw it. Thanks!
<jdstrand> I responded in the request. the fix is actually on its way. I am curious though, can I see your snapcraft.yaml, /snaps/mosquitto.../current/meta/package.yaml and /var/lib/snappy/apparmor/profiles/mosquito...
<elopio> jdstrand: oh nice, so I can just remove the overwrite.
<elopio> jdstrand: here's the yaml: https://github.com/elopio/snapcraft/blob/43d6ed402f98fa39046d455ffdcbbde0a244c943/examples/mosquitto/snapcraft.yaml (from the previous link I gave you you just have to swipe up :)
<fgimenez> elopio, the old server is up again http://162.213.35.179:8080/ after http://paste.ubuntu.com/14598180/
<elopio> and I didn't write any apparmor profile. But I saw the one from mosquitto upstream, let me find it again.
<fgimenez> elopio, i've taken the opportunity to spin up a vivid slave there too
<elopio> fgimenez: awesome. Let me join the hangout.
<asac> apw: ppisati: is it possible to use squashfs as initrd?
<apw> asac, initramfs is cpio.gz format, each segment of an initramfs has to be that format
<elopio> jdstrand: https://git.eclipse.org/c/mosquitto/org.eclipse.mosquitto.git/tree/security/mosquitto.apparmor
<elopio> I assume my snap is consuming that one. Is that right?
<asac> apw: hmm. i see this; http://lists.busybox.net/pipermail/buildroot/2013-January/066195.html
<apw> asac, legacy mode will mount other types, iff that type is not a module ... but why that format, when we have a format that is good
<asac> apw: just pondering as we use squashfs for snaps etc.
<asac> apw: do i need to enable some config to get legacy mode?
<apw> asac, it is enabled by default, though whether upstream will keep it long term is less clear
<jdstrand> elopio: can you give me /snaps/mosquitto.../current/meta/package.yaml and /var/lib/snappy/apparmor/profiles/mosquito... too?
<asac> right. maybe its not in trunk anymore? my kernel just detects junk according to log
<jdstrand> elopio: (fyi, I'm in and out of meetings so I will be laggy)
<apw> asac, with which kernel, i'd expect it to detect junk and then detect it if it was going to
<apw> but ... i am not sure it is a good idea to rely on it
<apw> noone uses those formats normally, everything is the new cpio format and has been for a long time
<asac> apw: yeah, it didnt detect it after seeing junk though... but ok, guess better not go down that path at all
<kgunn> mvo: hey there, i was just trying u-d-f from your all-snaps branch just now...but i can't quite figure out the commands....
<kgunn> i thot it would be
<kgunn> sudo /home/kg/Downloads/ubuntu-device-flash core rolling --channel edge -o xenial_core_amd64.img --developer-mode --gadget=generic-amd64 --size=5
<kgunn> but it keeps saying "expected 1 gadget snap"
<sergiusens> kgunn, maybe try --gadget=generic-amd64/edge ?
<kgunn> sergiusens: thanks...but no joy
<elopio> @kyrofa https://github.com/ubuntu-core/snapcraft/pull/202
<nothal> elopio: No such command!
<elopio> pleeeeaaase
<kyrofa> elopio, sheesh man
<kyrofa> Alright, time to move off the grid a bit to weather the storm. I'll be a bit difficult to reach I'm afraid
<elopio> jdstrand: ah, you meant the installed ones. I'm sorry. https://paste.ubuntu.com/14598353/
<mvo> kgunn: sorry that its a bit hard to use right now, there is an exmaple here http://people.canonical.com/~mvo/all-snaps/make-rpi2-all-snap and here is what I use for amd64 http://paste.ubuntu.com/14598354/
<elopio> kyrofa: good luck man! I'll wait for the cute new release pictures on monday ^_^
<kgunn> mvo: ta
<kgunn> will try in a moment
<kyrofa> elopio, ugh
<kyrofa> elopio, I might have to birth that boy myself :P
<elopio> hah, show the world that free software prepares you for absolutely everything. make us proud!
<kyrofa> elopio, hahahaha!
<Chipaca> JamesTait: thanks muchly
<Chipaca> JamesTait: no i'm not lagged why do you ask
<Chipaca> :-)
<JamesTait> ð
<JamesTait> Glad to be of service!
<elopio> fgimenez: can you upload your vivid udf somewhere?
<fgimenez> elopio, sure give me a second
<fgimenez> elopio, 10.55.32.74:/home/ubuntu
<elopio> thank you.
<Chipaca> JamesTait: question for you, v2
<JamesTait> No, we don't have a v2 api yet. ð
<Chipaca> https://search.apps.ubuntu.com/api/v1/search?q=name%3D%22http%22
<Chipaca> JamesTait: what's going on there? (what'm i missing?)
<Chipaca> JamesTait: because I *could* argue that the match from those names to "http" is rather poor
<Chipaca> JamesTait: if I were feeling ornery, I mean
<Chipaca> not that I am, in any way, trying to argue this, of course
<Chipaca> it just seems to me that "bankaustria.peter-bittner" does not, strictly speaking, if I were being picky, match "http".
<JamesTait> Hmmm...
<JamesTait> Looks to me like it's matching http from the description for some reason.
<JamesTait> Er, hang on... what's that %3D in there? Shouldn't that be %3A ?
<JamesTait> Ah, but that doesn't find your package because its full name is http.chipaca and it doesn't have an alias!
<Chipaca> d'oh! 3A!
<JamesTait> But dropping the %22 from the query to make it a keyword search instead of a literal phrase returns your package and one other.
<Chipaca> JamesTait: it's only exact matches when used like this?
<Chipaca> ah
<Chipaca> woooo!
<Chipaca> that's perfect, then
<Chipaca> so, name:$query
<Chipaca> not name=$query
 * Chipaca LARTs himself
<Chipaca> JamesTait: thanks again
<Chipaca> and sorry to have wasted your time a little there :-)
<JamesTait> q=[<field_name>:]value[,[field_name:]value]...
<JamesTait> Or q=[<field_name>:]"value"[,[field_name:]"value"]...
<JamesTait> Or some combination thereof.
<Chipaca> JamesTait: and if value contains " how do you quote it?
<JamesTait> That, sir, is an excellent question!
<Chipaca> or ,
<Chipaca> I mean, it could also be ","
<Chipaca> :-)
<Chipaca> because users are eeevil
<JamesTait> No! Say it ain't so!
<Chipaca> JamesTait: https://www.youtube.com/watch?v=ZGNtl9A1JwU
<JamesTait> Ah, Spongebob. Where would we be without you?
<jdstrand> elopio: security-override ended up in 'subscribe'. I think you want it in mosquito, no?
<JamesTait> Not in a pineapple under the sea, that's for sure.
<elopio> jdstrand: oh... I'm ashamed, I'm sorry :)
<JamesTait> I think the answer to your question is to \-escape them, but I'm looking for an example to verify that.
<elopio> fgimenez: m-o credentials ready, xenial slaves patched. Is it normal for the vivid slave to take that much time to go online?
<Chipaca> JamesTait: and is there documentation as to what things are "special" in a query? i notice "*" is special, for example
<Chipaca> JamesTait: as is ?
<fgimenez> elopio, great! it's still pulling layers from docker hub, but it seems that won't take too long, most of them are already pulled http://paste.ubuntu.com/14598736/
<elopio> ok, I'll wait.
<JamesTait> Chipaca, in fact, \-escaping the quote doesn't seem to make a difference, so I'm not sure.  The "special" characters mostly come down to those that Elasticsearch uses in its query syntax, which I wish I could find documented in a single place.
<Chipaca> and elasticsearch is just a frontend for lucene, is it not?
<elopio> fgimenez: I still don't understand vault to keep secrets. We would store the m-o password in a local vault, and then pass a token from an environment variable to read it?
<elopio> oh well, but it's late for you. That's for next week.
<fgimenez> elopio, np, yes they recommend a $VAULT_TOKEN var, anyway so far i had just looked into kubernetes secrets, the bin/create-secrets.sh script is about those
<fgimenez> elopio, vivid slave is about to show up
<jdstrand> elopio: np
<fgimenez> o/ nice weekend everyone
<elopio> today I'm going to take a looong lunch to teach a class of geographers about openstreetmap
<elopio> let's see how it goes.
<elopio> bbl.
<kyrofa> elopio, quick one: https://github.com/ubuntu-core/snapcraft/pull/253
<wiggleworm> I am looking for help with enabling console but with a twist - I want to see the systemA/systemB login via console
<wiggleworm> I am able to enable cosole ttyS(x) and see the boot process
<elopio> <- back
<wiggleworm> I want to be able to see the boot choices systemA/systemB
<elopio> wiggleworm: we are leaving the systemA/systemB implementation
<elopio> now everything is handled as snaps, even the boot files.
<elopio> maybe you should explain what's your goal, and then somebody will be able to give you pointers.
<elopio> however, it's friday and it's late. The developers are already afk.
<tsimonq2> elopio: although there still might be some developers in the US that are lurking! :)
<elopio> tsimonq2: right. [Most] devs are afk. And if they are not, they should starting the party right now. It's been a good week :)
<tsimonq2> elopio: well, again, some devs are still in the US, and idk if most of them are in Europe anyways :)
<tsimonq2> Â¯\_(ã)_/Â¯
#snappy 2016-01-23
<The_Letter_M> Hello
<The_Letter_M> Hola
<enoch85> kyrofa, Hi! Here is a nice summary: https://github.com/owncloud/pi-image/issues/17
<qengho> I don't understand configuration yet. Does anyone have, or know of, a practical snappy configuration script? I have only found weirdly abstract ones so far.
<aatchison> hello. Would anyone know how to use the --trusted-host option when installing requirements with pip in snappy?
<aatchison> I'm using snapcraft 2.0
<vir17> hi, anyone knows how to activate SPI in ubuntu snappy?
<qengho> I want to test a package I'm fabricating. I used snapcraft 2. Do I need a newer image than 15.04 for that kind of snap package?
<vir17> I get this error: Unable to open SPI device: Permission denied
<vir17> solved
<vir17> i forgot to put "sudo"
<qengho> "can not parse package.yaml: missing required fields 'vendor'", I guess the new format doesn't work with older images. Dang.
<qengho> Surely there are newer images, then. Unreleased ones.
<aatchison> ls
<aatchison> lol
#snappy 2016-01-24
<The_Letter_M> Hello
<om26er> where can I download the latest snappy image from ? I need to run it on my laptop.
<om26er> i.e. I need the x86 image.
<ogra_> om26er, xenial ? http://people.canonical.com/~mvo/all-snaps/
<om26er> ogra_, what does all-snap mean ?
<om26er> *s
<ogra_> that everything is a snap ...
<ogra_> (kernel, os, gadget
<ogra_> )
<ogra_> om26er, it is the new image format (that we havent fully added to auto-builds yet) ... the old system-image images will go away within the next two weeks
<joeblew99> I must have ubuntu 16.04 to write snaps ? Just that it says 14.04 is ok here: https://developer.ubuntu.com/en/snappy/build-apps/get-started/
<joeblew99> here it says i MUST have 16.04: https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md
<joeblew99> Does anyone know if the latest version of Snappy supports building GUI apps ?
<ogra_> you could always "build" gi apps.... there is no way to run them since there is no displayserver yet
<ogra_> *gui
#snappy 2017-01-16
<lifeless> mwhudson: hey so, where should I file bugs about the image http://releases.ubuntu.com/ubuntu-core/16/ubuntu-core-16-amd64.img.xz
<mwhudson> lifeless: launchpad.net/snappy unlikely to be very wrong
<mwhudson> lifeless: although it depends a bit what you are complaining about i guess
<lifeless> mwhudson: that image fails to boot on hyper-v ; snappy is supported on Azure I believe, so I'm concluding that its not Snappy per se thats buggy, but the configuration of that image
<lifeless> it fails in local-premount trying to read /prov/device-tree/model
<lifeless> ultimately leading to no FS being mounted with LABEL=writable, and then drops to initramfs
<mwhudson> lifeless: can't think of a better place than bugs.launchpad.net/snappy so i'd file there and let people add bug tasks as appropriate i guess
<lifeless> cheers
<mwhudson> i definitely don't know where work on the initramfs magic is tracked :)
<lifeless> it may be a missing device driver etc
<lifeless> mwhudson: so https://bugs.launchpad.net/snappy/+bug/1639878
<mup> Bug #1639878: pc-kernel.snap missing drivers necessary for Hyper-v <cpc> <Snappy:Fix Committed by ogra> <https://launchpad.net/bugs/1639878>
<lifeless> looks like I've been there before :) - paging this back in
<mwhudson> lifeless: haha
<mwhudson> there must be newer images you can try somewhere
<lifeless> yeah, I'd love that. bbiab
<mwhudson> there's http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-amd64.img.xz at least
<mwhudson> probably built from edge rather than stable
<lifeless> mwhudson: thanks
<lifeless> mwhudson: that boots
<lifeless> \o/
<lifeless> mwhudson: one more question; whats the recommended webserver for snappy devices? I can't see nginx or apache2 from googling; I can see a third party index of apps, but nothing run by Canonical? <out of depth>
<mup> Bug #1639603 changed: LibreOffice Snap: unable to access documents outside of my home directory. <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1639603>
<lpotter> cd
<liuxg>  how can I install a debian package from non-ubuntu archive?
<liuxg> I want to package azure-iot-sdk-c-dev into my snap, but it is from ppa:aziotsdklinux/ppa-azureiot. Can I just find its debian package?
<Joe_Dong> what's the new ubuntu-image name?
<Joe_Dong> sudo snap install --stable --devmode ubuntu-image
<Joe_Dong> error: cannot install "ubuntu-image": snap not found
<mup> PR snapd#2628 closed: many: (mis)feature/no more snapd.socket <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2628>
<mup> PR snapd#2633 opened: docs: simplify HACKING.md that snapd itself supports setting up the sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/2633>
<zyga> good morning
<mup> PR snapd#2634 opened: tests: improve debug output when reexec is used  <Created by mvo5> <https://github.com/snapcore/snapd/pull/2634>
<mup> PR snapd#2635 opened: SNAPD_DEBUG is a boolean (we use GetenvBool() for it) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2635>
<mup> PR snapd#2623 closed: tests: add test ensuring manual pages are shipped <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2623>
<mup> PR snapd#2230 closed: Add an interface that allows clients to use media-hub over dbus <Decaying> <Created by jhodapp> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2230>
<bencc> any news about this feature?
<bencc> https://bugs.launchpad.net/snappy/+bug/1584779
<mup> Bug #1584779: Upgrade a running snap without restarting it <Snappy:Triaged> <https://launchpad.net/bugs/1584779>
<bencc> it says triaged but still unassigned
<zyga> jjohansen: I tested the kernel you gave me
<zyga> jjohansen: the error doesn't go away yet, I'll share the data I collected but I would appreciate hints on what to collect
<mup> PR snapd#2636 opened: tests: add "quiet" wrapper function that only prints output on failure <Created by chipaca> <https://github.com/snapcore/snapd/pull/2636>
<popey> I'm using classic with a snap, and when i try, it fails:- $ sudo snap try --classic prime/    leads to:- - Mount snap "demo" (unset) (snap "demo" requires consent to use classic confinement)
<popey> what have I missed?
<Chipaca> popey, does try work with classic?
<popey> I don't know :)
<popey> the help implies it does
<mup> PR snapd#2637 opened: tests: increase retries for service up <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2637>
<popey> "snap try --help" suggests --devmode, --jailmode and --classic are valid options
<Chipaca> popey, yeah. Sorry.
<Chipaca> we're not passing that to snapd
<popey> shall i open a bug?
<Chipaca> popey, you can use curl to poke the rest api directly for this
<Chipaca> popey, please
<popey> ok
<popey> Chipaca: bug 1656820
<mup> Bug #1656820: snap try with classic confinement doesn't work <Snappy:New> <https://launchpad.net/bugs/1656820>
<Chipaca> ta
<mup> Bug #1656820 opened: snap try with classic confinement doesn't work <Snappy:New> <https://launchpad.net/bugs/1656820>
<popey> heheh sorry mup :)
<popey> is cleanbuild not compatible with classic confinement?
<popey> "classic confinement requires the core_dynamic_linker to be set
<popey> ^ I get that when I do "snapcraft cleanbuild"
<ogra_> popey, with core or with ubuntu-core installed ?
<popey> core
<ogra_> afaik it only works with core atm
<Chipaca> there's a bug about that already
<Chipaca> 1 sec
<ogra_> weird
<popey> core          16.04.1          714  canonical      -
<Chipaca> ah not a bug
<Chipaca> snapcraft mailing list "Classic confinement and core_dynamic_linker"
<Chipaca> but also bug 1650946
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1650946>
<popey> thanks
<simosx> I am trying to build a snap with snapcraft on 16.04.1 for peek (https://github.com/phw/peek), using "classic" confinement. I get linking errors refering to libmircommon:
<simosx> [100%] Linking C executable peek
<simosx> /usr/lib/x86_64-linux-gnu/libmircommon.so.6: undefined reference to `typeinfo for std::thread::_State@GLIBCXX_3.4.22'
<simosx> (I am building in an LXD container).
<simosx> If I build the snap on my Ubuntu 16.04.1 (not in LXD container), it builds successfully.
<popey> you using "snapcraft cleanbuild" or just a vanilla lxd setup of your own?
<popey> is the container up to date?
<simosx> I am using a vanilla LXD setup of my own.
<simosx> I am trying out "cleanbuild". If it works, I am OK with that.
<simosx> I got an error with "cleanbuild". It refers to "core_dynamic_linker", which might be helpful with my vanilla LXD setup as well:
<simosx> Preparing to pull peek
<simosx> classic confinement requires the core_dynamic_linker to be set
<simosx> Stopping snapcraft-namely-hot-cow
<simosx> Command '['lxc', 'exec', 'snapcraft-namely-hot-cow', '--', 'snapcraft', 'snap', '--output', 'peek_latest_amd64.snap']' returned non-zero exit status 1
<simosx> Dejavu, it was the thing you were discussion ten minutes earlier... :-)
<Chipaca> simosx, the bug is marked fix-committed; if you're blocked, maybe try snapcraft from git?
<simosx> Chipaca, I'll try out snapcraft from git.
<popey> .oO( Maybe we should have a snap of snapcraft which has the latest crack du-jour )
<ogra_> i thought we do (at least in edge) now
<Chipaca> popey, snap info snapcraft
<popey> Chipaca: simosx using snapcraft from git will only work if you put that inside lxd, it won't fix the problem with cleanbuild
<popey> ooh
<popey> summary:   "Single-line elevator pitch for your amazing snap"
<Chipaca> dunno if it's kept up to date though
<popey> ahem
<Chipaca> kyrofa, ?
<icey> any idea when snapcraft 2.25 will be cut?
<popey> I'd imagine soon as it's in xenial proposed right now
<popey> bug 1656291
<mup> Bug #1656291: [SRU] New stable micro release 2.25 <verification-done> <snapcraft (Ubuntu):In Progress> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Committed> <snapcraft (Ubuntu Zesty):In Progress> <https://launchpad.net/bugs/1656291>
<davmor2> popey: elevator pitch is that a snap that just plays muzac at you
<mup> PR snapd#2638 opened: tests: change TRUST_TEST_KEYS to be controlled from the host <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2638>
<popey> davmor2: that is not a stupid idea. "snap install muzak" which just plays music constantly :)
<popey> for music on hold or whatever
<icey> +1 popey
<davmor2> popey: I'll expect my royalty cheque in the post what 50% of nothing again?
<didrocks> Mirv: hey, how are you? I'm going to push some fundamental changes to the launcher.
<didrocks> Mirv: this is before merging your PR, which may be incompatible, I would appreciate you testing the changes
<didrocks> Mirv: I guess you will need to add some small changes, to pick local QML files and such
<didrocks> (as now, it's either the runtime or the snap)
<didrocks> so probably something along the line https://github.com/ubuntu/snapcraft-desktop-helpers/blob/runtime-refactor/common/desktop-exports#L43
<mup> PR snapd#2277 closed: snap: add new `snap prepare-image --devmode` option <Blocked> <Critical> <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2277>
<mup> PR snapd#2360 closed: [WIP] Fix prefix search query; Fix empty query search; Find doc <Created by AlexandreAbreu> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2360>
<mup> PR snapd#2392 closed: partition: add support for native grubenv read/write and use it <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2392>
<mup> PR snapd#2407 closed: wrappers: add support for the X-Ayatana-Desktop-Shortcuts= extension <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2407>
<mup> PR snapd#2411 closed: interfaces: add history-related (what history?) interface <Created by renatofilho> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2411>
<Chipaca> renatu, ^
<renatu> Chipaca, ok, no problem we still discussing about that interface
<simosx> Okay, tried to install "snapcraft" in an LXD "ubuntu:x" container. I used these instructions and got an error (also in pastebin). Any hint appreciated. http://pastebin.ubuntu.com/23810783/
<simosx> The schema is in /usr/local/lib/python3.5/dist-packages/snapcraft-2.25-py3.5.egg/share/snapcraft/schema/snapcraft.yaml but snapcraft is looking somewhere else (let's add a print statement).
<simosx> okay, if you install snapcraft manually, it goes into /usr/local/ but the code is looking at /usr/share/snapcraft/schema/snapcraft.yaml to find the schema (that is, it's somehow hardcoded).
<simosx> Bug report, https://bugs.launchpad.net/snapcraft/+bug/1656884
<mup> Bug #1656884: Installation from source (git) error: snapcraft validation file is missing from installation path <Snapcraft:New> <https://launchpad.net/bugs/1656884>
<simosx> New snapcraft from git: classic confinement requires the core snap to be installed. Install it by running `snap install core`.
<simosx> Since it is in an LXD container, I first run "apt install squashfuse", then "snap install core".
<simosx> Finally, all good: Snapped peek_latest_amd64.snap :-)
<mup> PR snapd#2359 closed: spread: add boilerplate for Linode delta uploads <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2359>
<Trevinho> Buuuuuut... Is it normal that if I go in `snap run --shell whatever`...
<Trevinho> And I give the "ps aux" command I can see all the procs and command lines around?
<Trevinho> jdstrand: ^ It seems that while exe is not readable, cmdline it is
<ogra_> Trevinho, he is off today (teh whole US is)
<Trevinho> ah... ok
<ogra_> MLK day
<Trevinho> Anyway for something ran inside a confined snap run --shell, I have
<Trevinho> cat /proc/<any-pid>/cmdline all readable... looks weird
<ogra_> might be a bug in "run --shell"
<ogra_> i dont think it works on installed snaps
<ogra_> zyga would know (i think)
<Trevinho> mh, let me see but... I believe it will be there too
<mup> PR snapd#2638 closed: tests: change TRUST_TEST_KEYS to be controlled from the host <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2638>
<ogra_> unless your snap uses the process-control interface indeed
<Trevinho> no, no... there's no plug at all
<Trevinho> only unity7
<ogra_> oh
<ogra_> unity7 is indeed quite open i think
<mup> PR snapd#2631 closed: releasing package snapd version 2.21 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2631>
<ogra_> (thats actually X11)
<Trevinho> yeah, but not sure for that
<ogra_> i assume thats related though
<Trevinho> let me check
<zyga> Trevinho: hey
<zyga> Trevinho: how can I help?
<mup> PR snapd#2613 closed: interfaces: add new interface API <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2613>
<mup> PR snapd#2639 opened: snap: add {Plug,Slot}Info.SecurityTags <Created by zyga> <https://github.com/snapcore/snapd/pull/2639>
<mup> PR snapd#2640 opened: interfaces: allow querying added security backends <Created by zyga> <https://github.com/snapcore/snapd/pull/2640>
 * zyga EODs
<mwhudson> lifeless: oops, i'd run off to the cricket by the time you asked that
<mwhudson> lifeless: however i don't know the answer so you didn't miss anything
<mwhudson> zyga: ping
<alex-abreu> elopio,
<alex-abreu> ping
<zyga> mwhudson: hi
<mwhudson> zyga: i want to upload snapd 2.21 to debian today or so
<mwhudson> zyga: do you want to include apparmor disabling in that, do you think?
<zyga> mwhudson: hmm, if you could; but it would be a vendor patch
<zyga> mwhudson: since it is a conffile you'd have to use a maitainer script for this
<mwhudson> zyga: oh right
<zyga> mwhudson: I think disabling it is technically correct at this stage, nobody from security can ack as US is mostly off but I think the argument I made in the bug report is reasonable
<zyga> mwhudson: after snap-alter-ns I will work on various distro activities, including CIing debian
<mwhudson> that's faaaiirly easy though? echo rm_conffile /etc/apparmor/usr.lib.snapd.snap-confine > debian/snapd.maintscript
<zyga> mwhudson: yes but we found bugs in that (ask mvo)
<zyga> mwhudson: in rm_conffile specifically
<mwhudson> zyga: o/ awesome o/
<zyga> mwhudson: we did that when we removed ubuntu-core-launcher's apparmor profile
<zyga> mwhudson: you may also want to unload the profile if it is loaded
<mwhudson> zyga: alternative is i upload 2.21 just as broken as before, we wait until US wakes up again and upload 2.21-2
<mwhudson> leaning towards that option, tbh
<zyga> mwhudson: that's OK too, I think there were some concerns as to how many updates can we fit into stretch
<zyga> mwhudson: +1
<zyga> mwhudson: safer IMH
<zyga> IMHO
<mwhudson> ok
<zyga> mwhudson: on that note, 2.21 fixes classic snaps, you may find the "python0" snap curious :)
<mwhudson> zyga: heh, i made a go classic snap last week
<mwhudson> got confused trying to get it into the store though, i need to have another go at that
<zyga> mwhudson: what issues did you run into exactly?
<zyga> mwhudson: my snap was stuck in manual review but mvo kindly pushed that through
<mwhudson> just that i think
<zyga> mwhudson: http://github.com/zyga/python0
<mwhudson> "(NEEDS REVIEW) confinement 'classic' not allowed lint-snap-v2_confinement_classic"
<zyga> mwhudson: I think that is typical for now, I'll try to figure out what is the review policy for those and write that down on the wiki
<zyga> mwhudson: yeah, that error message cries "I need UX love"
<mwhudson> classic snaps not building on launchpad yet is kinda a bummer too
<zyga> oh, I wasn't aware of that
<mwhudson> you need the core snap installed
<zyga> mwhudson: what's the issue? CDN access for the core snap download?
<mwhudson> or at least, on disk
<mwhudson> launchpad builds run in a chroot
<zyga> mwhudson: I see, I didn't know this
<mwhudson> without snapd running (if it can even run in a chroot)
<zyga> mwhudson: classic also suffers from ubuntu-core/core split
<zyga> mwhudson: I think you don't need full snapd
<zyga> mwhudson: all you really really need is core snap unpacked/mounted at /snap/core/current/
<zyga> mwhudson: everything else is irrelevant
<mwhudson> yeah somehow i have the core snap installed as well as ubuntu-core
<mwhudson> zyga: yeah, but it's still not there :)
<zyga> mwhudson: one version of snapd allowed that
<zyga> mwhudson: this week we'll try to migrate that so that 2.22 will be good
 * mwhudson uploads snapd_2.21-1_source.changes
<zyga> mwhudson: nice, I'll check my sid box shortly :)
<zyga> mwhudson: thank you for packaging snapd :)
<mwhudson> oh good it got accepted this time
<mwhudson> zyga: no worries, it's not very onerous really :)
<zyga> mwhudson: btw are you aware of https://github.com/snapcore/snapd/wiki/Distributions
<mwhudson> zyga: i'd seen it
<mwhudson> i guess the debian section is a little inaccurate
<zyga> mwhudson: inaccurate how? (feel free to edit this, there's no pull request or review required)
<mwhudson> well snap-confine is gone for one
<mwhudson> i'll have an edit in a sec
<zyga> mwhudson: ah, indeed,
<zyga> mwhudson: thank you again :)
<mwhudson> eh well the snap-confine _source package_ is gone
<zyga> mwhudson: that's fine, we don't need to link to the binary package
<mwhudson> zyga: https://github.com/snapcore/snapd/wiki/Distributions/_compare/be17952ef93b02669f28e8d170e41d9bf784388e...cef68b00466b40e8e9b0d013964e6e2b6ed76da9
<zyga> mwhudson: looks great, thanks!
<zyga> mwhudson: you can also tweak the table up top where summary data is shown for all the distros
<mwhudson> zyga: i guess i should wait for the package to be published first...
<mwhudson> zyga: also what do i say, "supported" seems wrong, just "up to date"?
<zyga> mwhudson: yes, up-to-date feels better
#snappy 2017-01-17
<lifeless> mwhudson: o/
<lifeless> mwhudson: is there an index of snaps ?
<mwhudson> lifeless: there is https://uappexplorer.com/apps?type=snappy
<lifeless> mwhudson: yeah, but its pretty useless AFAICT - this https://uappexplorer.com/apps?type=snappy&q=nginx&sort=relevance
<mwhudson> lifeless: yeah no argument there
<lifeless> mwhudson: or this - https://uappexplorer.com/app/apache2.mcaps - I can't figure out how to install that
<mwhudson> lifeless: creation date suggests that's from the version 15 era
<mwhudson> lifeless: this timezone is pretty bad for figuring out what's going on in the snappy world sadly
<lifeless> mwhudson: thats sad; https://bugs.launchpad.net/snappy/+bug/1656976 is the next issue
<mup> Bug #1656976: classic mode cannot start services <Snappy:New> <https://launchpad.net/bugs/1656976>
<mup> Bug #1656976 opened: classic mode cannot start services <Snappy:New> <https://launchpad.net/bugs/1656976>
<nhaines> Could I get someone to peek at my app spacedrive?  :)
<nhaines> Also, the build failed (except for ppc64el) on Launchpad, which is odd because it's a script and some deb packages.
<nhaines> Not sure if this is public or not... https://code.launchpad.net/~nhaines/+snap/spacedrive
<mup> Bug #1657021 opened: Operator specified filesystem access <Snappy:New> <https://launchpad.net/bugs/1657021>
<zyga> good morning
<nhaines> zyga: good morning!
<didrocks> Mirv: hey! did you see my ping yesterday about the new runtime?
<mup> PR snapd#2641 opened: cmd: fix hardcoded paths to rst2man and support rst2man.py <Created by zyga> <https://github.com/snapcore/snapd/pull/2641>
<didrocks> Mirv: Just did a PR for reference: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/34
<mup> PR ubuntu/snapcraft-desktop-helpers#34: Runtime refactor <Created by didrocks> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/34>
<mup> PR snapd#2642 opened: tests: disable ipv6 before unpacking delta <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2642>
<r2geo> Hello, hen building a snap, launchpad throws a GPG error that I suspect is a launchpad problem, not related to my script. Am I correct? It may be related to 1626739? https://paste.ubuntu.com/23815514/
<tsdgeos> r2geo: you mean the F1831DDAFC42E99D warning?
<r2geo> correct
<r2geo> when I install on my pi3, it fails on: $ snap install openhab_r2geo_2.0.0.b4-7_armhf.snap
<r2geo> error: cannot find signatures with metadata for snap "openhab_r2geo_2.0.0.b4-7_armhf.snap"
<tsdgeos> r2geo: i understand you get that warning also "outside" of snap, right?
<r2geo> ? sorry, I don't understand your question
<tsdgeos> i you run apt-get update (i.e. nothing snap related)
<tsdgeos> you also get that warning, right?
<tsdgeos> should be fixed if you run something like
<tsdgeos> sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys F1831DDAFC42E99D
<tsdgeos> will you make trust the launchpad packages signed by that key
<r2geo> on the pi I don't use apt-get update. On my pc I do not get that error. The buildlog was from launchpad
<tsdgeos> ah
<r2geo> should that key be added to my pc (from which I request launchpad to build)? Or from the pi?
<tsdgeos> then i don't know, sorry
<r2geo> Just checked, but building on pc does not throw this error
<r2geo> so ... as the buildlog is created on launchpad, I suspect there is something wrong there. But I may be wrong. I will create a bug report - still if someone knows, I would be very happy to solve it via IRC. Thanks
<mup> PR snapd#2643 opened: many: add stub implementation of snap-alter-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/2643>
<mup> Bug #1656340 opened: XDG_RUNTIME_DIR is not created on app startup <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1656340>
<zyga> jdstrand: hey, can you please review https://github.com/snapcore/snapd/pull/2630
<mup> PR snapd#2630: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
<Trevinho> ogra_: about the thing I was pointing out last night... https://bugs.launchpad.net/snappy/+bug/1657080
<Trevinho> not snap run or unity7 specific
<Trevinho> jdstrand: ^
<mup> PR snapd#2642 closed: tests: disable ipv6 before unpacking delta <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2642>
<mup> Bug #1400802 changed: sudo snappy install should autocomplete <snappy-xp-console> <Snappy:Fix Released> <https://launchpad.net/bugs/1400802>
<mup> Bug # changed: 1500755, 1574114, 1574830, 1581596, 1588322
<mup> Bug # changed: 1593371, 1593956, 1598656, 1611641, 1622782, 1623589, 1627338, 1635264
<mup> Bug #1641590 changed: snap --help outline text <Snappy:Fix Released> <https://launchpad.net/bugs/1641590>
<mup> Bug #1641885 changed: jailmode doesn't work with snap try or snap install <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1641885>
<mup> Bug # changed: 1643885, 1643888, 1645413, 1646085, 1646479, 1647992, 1653955, 1654585
<mup> Bug #1537793 changed: Autoupdate should be less frequent and more randomly distributed <verification-done> <Snappy:Fix Released> <snapd (Ubuntu):Fix Released> <snapd (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1537793>
<mup> Bug #1654666 changed: snapd-xdg-open doesn't work in strict mode <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1654666>
<ogra_> Trevinho, ah
<mup> Bug #1595064 changed: 'snap refresh' return code unhelpful <amd64> <apport-bug> <canonical-is> <xenial> <Snappy:Fix Released> <https://launchpad.net/bugs/1595064>
<mup> Bug #1600083 changed: 'snap' tool bash completion does not complete local file names <Snappy:Fix Released> <https://launchpad.net/bugs/1600083>
<mup> Bug #1603481 changed: multiple binaries from the same package <openstack> <Snapcraft:Fix Released by joetalbott> <Snappy:Fix Released> <https://launchpad.net/bugs/1603481>
<mup> Issue snapd#2514 closed: seccomp tests fail on Ubuntu 14.04 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2514>
<mup> Bug # changed: 1605258, 1606053, 1616657, 1617890
<mup> Bug # changed: 1635016, 1636847, 1640874, 1645961
<mup> Bug #1654590 changed: docker interface should account for /run/shm/ in addition to /dev/shm <snapd-interface> <Snappy:Fix Released by jdstrand> <https://launchpad.net/bugs/1654590>
<eduardas_m> hello, I am currently building an embedded system with Yocto/OpenEmbedded. I am considering trying to port Ubuntu Core to my platform to get its update functionality. However I am unsure: does using Ubuntu Core on OEM devices require buying licences from Canonical?
<ogra_> zyga, bug 1656976 is on purpose, right ?
<mup> Bug #1656976: classic mode cannot start services <Snappy:New> <https://launchpad.net/bugs/1656976>
<ogra_> eduardas_m, nope, but we currently only support grub and uboot as bootloaders and you need full access to the source (we require a specific setup for the bootloader)
<ogra_> beyond this there is nothing required
<eduardas_m> ogra_, thank you for the answer... my platform (DART6UL SoM from Variscite) currently has u-boot 2015.04 revision... where can I check if this is supported?
<eduardas_m> also, is it possible to do kernel updates via snaps?
<ogra_> eduardas_m, well, you need the source and need to enable/change some config options
<ogra_> yes, os and kernel updates
<ogra_> eduardas_m, https://github.com/snapcore/pi3-gadget/blob/master/prebuilt/uboot.patch has an example patch
<eduardas_m> ogra_, thanks a lot... sounds good so far... will give it a shot
<ogra_> CONFIG_ENV_SIZE (with the right size), CONFIG_SYS_REDUNDAND_ENVIRONMENT, CONFIG_ENV_IS_IN_FAT and CONFIG_SUPPORT_RAW_INITRD are hard requirements
<zyga> ogra_: I believe so, yes
<ogra_> zyga,  iirc we support that you install services that you can also (temporary) start ... i wonder if that affects it
<ogra_> (so that you can experiment with apache until the next reboot where it wont be started anymore)
<ogra_> at least thats the wording i remember
<mup> PR snapd#2644 opened: snapctl: support running by the snap app itself, not only just from hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2644>
<mup> PR snapd#2634 closed: tests: improve debug output when reexec is used  <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2634>
<mup> Issue snapd#2541 closed: tests/main/interfaces-network-control-ip-netns test fails on ubuntu 14.04-32 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2541>
<mup> Issue snapd#2576 closed: snap-confine cannot be setuid root on openSUSE <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2576>
<mup> Issue snapd#2569 closed: snap-confine cannot perform namespace capture even with CAP_SYS_ADMIN <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2569>
<mup> Issue snapd#2568 closed: snapd needs a SELinux profile to run on Fedora <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2568>
<mup> Issue snapd#2553 closed: snapd is not tested against Debian <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2553>
<mup> Issue snapd#2552 closed: snapd is not tested against Arch Linux <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2552>
<mup> Issue snapd#2572 closed: .fstab files generated by snapd for the content interface do not follow the snap.<snap name> scheme <Created by morphis> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2572>
<mup> Issue snapd#2603 closed: Disk free space left check <Created by cyberb> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2603>
<mup> Issue snapd#2625 closed: feature request: ability to talk to sysctl <Created by battlemidget> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2625>
<mup> Issue snapd#2484 closed: Support removing all unused revisions <Created by niemeyer> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2484>
<mup> Issue snapd#2594 closed: Please add "install" hook <Created by jacekn> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2594>
<mup> PR snapd#2641 closed: cmd: fix hardcoded paths to rst2man and support rst2man.py <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2641>
<mup> PR snapcraft#1051 opened: misc: remove snapd "submodule" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1051>
<mup> PR snapcraft#1039 closed: Check the older ubuntu-core snap name for core dynamic linker <Created by thomir> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1039>
<mup> PR snapcraft#1045 closed: Handle parser errors better <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1045>
<stokachu> can i move my scripts and setup dir from snapcraft to just the snap dir in the top level directory of my project now?
<zyga> stokachu: I don't know, sorry
<stokachu> thanks
<mup> PR snapd#2645 opened: spread: exclude .o and .a files <Created by zyga> <https://github.com/snapcore/snapd/pull/2645>
<stokachu> zyga, where did https://github.com/snapcore/snapd/issue/2625 get moved to?
<zyga> stokachu: ohhh
<zyga> stokachu: hmm that's terrible,one cannot see the issues anymore
<zyga> niemeyer: ^ can we have read only issues so that people can see where they were moved?
<zyga> stokachu: all of those moved to launchpad.net/snapd but I cannot even give you the URL now :(
<stokachu> zyga, ah ok i figured you consolidated issue tracking
<eduardas_m> ogra_, my current u-boot has CONFIG_ENV_IS_IN_MMC since the board boots from SD card... is this option compatible with CONFIG_ENV_IS_IN_FAT?
<ogra_> nope
<ogra_> you need to use a uboot.env blob file
<ogra_> the userspace needs to be able to find it where it expects it to change variables on the fly
<ogra_> (there is interaction going on betweern snapd and the bootloader that needs to work)
<eduardas_m> ogra_, this blob is available for download?
<ogra_> look in the branch that has the patch above ... there is a uboot.env.in and there is the command you need to turn it into a uboot.env blob in the README.md
<ogra_> (the uboot.env.in should contain your default env like you get it on a serial console with printenv)
<eduardas_m> ogra_, thank you... that makes things clearer
<env_ro> Hi folks; I do have a question: snapd reads environment variables from /etc/environment file, how could I modify this file since fs is mounted as 'read only'? ;)
<env_ro> this is the first question. Second one is about to modifying the console command that connects to ubuntu-one so it obtains public key associated with a given account.
<env_ro> If I would be able to modify the above mentioned file (/etc/environment) so I would put there http_proxy settings, would then that initial script connect via the proxy?
<env_ro> I'm asking, because I'm not able to install ubuntucore in my lab infrastructure (http proxy is required)
<env_ro> So, maybe it would be a good idea if that script would take also the http proxy parameter?
<gbisson> Hi all! I'm experiencing with Ubuntu Core on RPi3 and have a few question, first I can't install webdm, it throws: (installation not allowed by "snapd-control" plug rule of interface "snapd-control")
<gbisson> so I've used snapweb instead
<gbisson> but is it webdm replacement?
<gbisson> is the error seen above normal?
<env_ro> Hi gibsson. Unfortunately, it appears that noone is here ;)
<env_ro> (i am not counting - newbie)
<gbisson> env_ro: thanks for your reply though, we're at least 2 listening ;)
<gbisson> I'll wait for a little bit, it can be early for some timezones
<mup> PR snapd#2368 closed: tests: parameterize remote store <Created by fgimenez> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2368>
<ogra_> gbisson, it was renamed to snapweb a while ago
<mup> PR snapcraft#1031 closed: store: fix sso_host for dev sso <Created by shawn111> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1031>
<zyga> jdstrand: good morning, thank you for triaging that bug
<jdstrand> np
<jdstrand> it will be nice to have it fixed, but that work is behind upstreaming (at least) atm afaik
<zyga> jdstrand: that's a good plan IMHO
<zyga> jdstrand: btw, do you know how far are we from upstreaming everything?
<stokachu> has anyone run into https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1656580?
<mup> Bug #1656580: snapd on trusty fails to install snap with error loading shared library <conjure-up> <snapd (Ubuntu):New> <snapd (Ubuntu Trusty):New> <https://launchpad.net/bugs/1656580>
<stokachu> references some apparmor issue
<jdstrand> zyga: I know a fair bit made the merge window. I don't have the details. perhaps tyhicks does?
<zyga> jdstrand: thanks, I'll ask jjohansen and tyhicks later today
<jdstrand> stokachu: fyi, I asked for more information in the bug
<stokachu> jdstrand, thanks redeploying 14.04 in my maas lab will get you that info
<tyhicks> zyga (cc jdstrand): a ton of patches will land in 4.11 (https://marc.info/?l=linux-kernel&m=148455878701987&w=2) but we're still months away from upstreaming everything
<tyhicks> zyga: now that the ball is rolling on the upstreaming effort, I think that the kernel development cycle cadence is going to limit how fast we can upstream things
<tyhicks> zyga: while that was a large number of patches, that's all we'll be able to get into the 4.11 kernel so we'll be queueing the next set of patches up for the 4.12 kernel security subsystem merge window
<stokachu> jdstrand, hmm 2.21~14.04.2 does't seem to show this problem
<stokachu> think that was released this morning
<stokachu> still testing though
<mup> PR snapd#2645 closed: spread: exclude .o and .a files <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2645>
<jdstrand> I know there has been a lot of 14.04 work lately. it doesn't surprise me it might be fixed
<stokachu> having systemd issues now but i dont think that apparmor is an issue any longer
<stokachu> where does snapd install the systemd files for 14.04?
<jdstrand> stokachu: cool. can you followup in the bug? note that when I was playing with 14.04, cgmanager would get in the way of systemd
<stokachu> jdstrand, http://paste.ubuntu.com/23816658/ thats what i see with systemd and my snap
<stokachu> journalctl -xn didn't give me much info though
<stokachu> can't seem to find my systemd service file
<stokachu> not in /lib/systemd
<stokachu> it looks like the systemd file shouldve been linked into /lib/systemd/upstart on 14.04
<zyga> tyhicks: that's some great news, thank you
<gbisson> ogra_: thanks!
<gbisson> in that case maybe webdm should be removed from the list or have a more explicit error message like "not supported any more, please use snapweb"
<zyga> jdstrand, tyhicks: FYI, I have extra data for the apparmor bug at https://github.com/snapcore/snapd/pull/2624 but I need some help to figure out what to collect
<mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Blocked> <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<zyga> I made it easy to re-run the spread test that uses the test kernel from jjohansen
<zyga> and to collect various things
<zyga> after running it the erorr I see is different, not sure if that is because of the older base kernel
<zyga> this log file has useful references: https://s3.amazonaws.com/archive.travis-ci.org/jobs/192346094/log.txt
<eduardas_m> I am trying out Ubuntu Core image on Virtual Box... Ubuntu store account is mandatory to even launch Ubuntu Core?
<zyga> scroll to the bottom please then look for:  linode:ubuntu-16.04-64:tests/regression/lp-1644439
<zyga> (hmm, I guess I need to stil tweak that to restore correctly)
<zyga> the results are much more comprehensive if the single regression test is executed
<zyga> eduardas_m: to log in, yes, otherwise anyone on the same network could "own" your device and that's not great for security
<niemeyer> zyga, stokachu: No, no way around that unfortunately
<zyga> jdstrand, tyhicks: let me know when would be a good time to try some interactive triage/debugging on this
<zyga> niemeyer: ah, too bad; on the up side all the reporters got the email that included the new URLs so I hope they can find that
<niemeyer> Yeah
<niemeyer> and we also only had two issues which were not filed by you or mvo
<eduardas_m> zyga, but if I want to use Ubuntu Core to be ported for an OEM device that is really bad
<ogra_> eduardas_m, it will launch without it ... but to log in you need one
<eduardas_m> ogra_, so lets assume that Ubuntu Core ships with hundreds of OEM devices..each one of these has to be tied to an Ubuntu Store account?
<zyga> eduardas_m: if you have something specific in mind I can get you in touch with our commercial people; this scheme is designed to be secure for end users;
<ogra_> thre is some way to set a local acocunt using a configuration on a usb stick on first boot
<ogra_> but i dont think thats documented or promoted yet
<zyga> ogra_: only the owner of the device brand can issue this assertion
<zyga> ogra_: and it only (sensibly) applies to unowned devices
<zyga> ogra_: and canonical does not issue this assertion yet
<ogra_> right
<zyga> eduardas_m: being tied an account also lets the user manage the device better, depending on the form factor and interaction methods it would be impossible to do otherwise
<tyhicks> ogra_: I just ping you in the github PR but there's a test kernel for you to test: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/2
<mup> Bug #1656121: unexpected errno=13 and disconnected path when trying to open /proc/1/ns/mnt from a unshared mount namespace <AppArmor:New> <https://launchpad.net/bugs/1656121>
<tyhicks> ogra_: bah, my bad... that message wasn't meant for you
<tyhicks> zyga: I just ping you in the github PR but there's a test kernel for you to test: https://bugs.launchpad.net/apparmor/+bug/1656121/comments/2
<zyga> tyhicks: I tested this kernel, all the stuff I said above was based on that
<tyhicks> oh
 * tyhicks rereads
<ogra_> see ... undocumented, so i know nothing about it obviously ;)
<zyga> tyhicks: one sec:
<ogra_> tyhicks, heh, i was starting to wonder already :)
<zyga> tyhicks: https://github.com/snapcore/snapd/pull/2624/files#diff-f3378ae971fb046662010c5acfd2c35cR21
<mup> PR snapd#2624: Re-associate with pid-1 mount namespace if required <Blocked> <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/2624>
<mup> PR snapd#2347 closed: overlord: flag required-snaps from model as required and prevent removing them <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2347>
<zyga> tyhicks: I've automated the testing process for that issue
<tyhicks> zyga: since it is a kernel bug, I think you're better off working directly with jjohansen on this when he starts his day
<zyga> tyhicks: yes, I agree
<renatu> zyga, hey, could you check if you are happy with this MR: https://github.com/snapcore/snapd/pull/2226
<mup> PR snapd#2226: interfaces/builtin: add evolution interfaces <Created by renatofilho> <https://github.com/snapcore/snapd/pull/2226>
<zyga> renatu: yes
<zyga> renatu: done
<renatu> zyga, thanks
<eduardas_m> I am having trouble logging in to Ubuntu Core on VirtualBox... I am trying my Ubuntu One username and password
<eduardas_m> I used a public ssh key I generated on my Ubuntu 14.04 host to put into my Ubuntu One account
<kyrofa> Chipaca, unfortunately the bug you referenced was just discussing how unhelpful the error is, not that it was impossible to cleanbuild
<kyrofa> Chipaca, but it's a known issue, there was a ML thread about it and we're working on it
<mup> PR snapcraft#1050 closed: repo: add multiarch support for stage packages <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1050>
<mup> PR snapcraft#1051 closed: misc: remove snapd "submodule" <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1051>
<niemeyer> zyga, jdstrand: Do you want to have a quick call to discuss the new interface system?
<jdstrand> niemeyer: I guess a call now is fine
<jdstrand> tyhicks: fyi ^. I can handle it but if you want to be there ^
<zyga> yes
<zyga> niemeyer: where shall we meet?
<niemeyer> https://hangouts.google.com/hangouts/_/canonical.com/new-interfaces?authuser=1
<niemeyer> jdstrand: ^
<eduardas_m> what is supposed to be the username/password combination for the ubuntu-core-16-amd64.img?
<eduardas_m> is it the username and password of my Ubuntu One account?
<ogra_> it is your username ... no password ... it uses the ssh key that you provided in your U1 account to provide ssh login
<kyrofa> eduardas_m, there's no local login by default
<ogra_> right, only ssh
<kyrofa> eduardas_m, the idea is, you go through the first boot wizard, provide your Ubuntu One login info, and it'll pull down the SSH keys you have uploaded. Then you can use those to SSH in
<eduardas_m> kyrofa, so I can not log in through tty1 in VirtualBox?
<kyrofa> ogra_, how is SSH configured by default? If a password is set, will one be able to SSH in with that password?
<eduardas_m> because it prompts me for a password there
<kyrofa> eduardas_m, not by default, but you can always set a password once you SSH in
<eduardas_m> kyrofa, is this kind of interesting behaviour documented somewhere?
<eduardas_m> because I believe a lot of people would benefit from instructions on how to test Ubuntu Core on VirtualBox
<kyrofa> eduardas_m, yes indeed. I assume you started with the KVM option? https://developer.ubuntu.com/core/get-started/kvm
<mup> PR snapd#2646 opened: tests: fix failing snapd-reexec test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2646>
<kyrofa> eduardas_m, note that this behavior is a little out of the ordinary, but it's done to ship a secure image by default
<kyrofa> eduardas_m, default passwords etc. are why we have botnets of CCD cameras
<eduardas_m> eduardas_m, to be honest I am quite new to linux in general (haven't even spent a year with it) and have very limited experience with VirtualBox and VMware as it is...since KVM is totally unfamiliar to me, I did not even consider it
<kyrofa> eduardas_m, oh I don't blame you. I'm NOT new to Linux and I prefer vbox
<kyrofa> eduardas_m, but what image did you start with, then?
<eduardas_m> kyrofa, I did a VBoxManage convertdd ubuntu-core-16-amd64.img ubuntu-core-16-amd64.vdi --format VDI
<kyrofa> eduardas_m, or did you do something directly like this https://kyrofa.com/posts/ubuntu-core-on-virtualbox ?
<eduardas_m> I found these instructions online and it was the first thing I tried
<kyrofa> eduardas_m, ah
<kyrofa> eduardas_m, well, had you gone through the developer.ubuntu.com path, you would have seen docs for this behavior. But no matter!
<eduardas_m> kyrofa, thank you for the help so far... will continue exploring Ubuntu Core tomorrow
<ogra_> kyrofa, hmm, no idea, since the key always preceeds password i have never tested that
<mup> PR snapd#2647 opened: cmd: add autogen.sh <Created by zyga> <https://github.com/snapcore/snapd/pull/2647>
<mup> PR snapcraft#1052 opened: Make git pulls less error prone due to history changes <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1052>
<zyga> jdstrand: trivial: https://github.com/snapcore/snapd/pull/2648
<mup> PR snapd#2648: cmd/snap-confine: use flags rather than magic bool constants <Created by zyga> <https://github.com/snapcore/snapd/pull/2648>
<mup> PR snapd#2648 opened: cmd/snap-confine: use flags rather than magic bool constants <Created by zyga> <https://github.com/snapcore/snapd/pull/2648>
<mup> PR snapd#2649 opened: many: extract the logging http client and user-agent handling for use in devicestate <Created by pedronis> <https://github.com/snapcore/snapd/pull/2649>
<mup> PR snapd#2633 closed: docs: simplify HACKING.md that snapd itself supports setting up the sockets <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2633>
<mup> PR snapd#2647 closed: cmd: add autogen.sh <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2647>
<zyga> jdstrand: oldie but (hopefully) goldie: https://github.com/snapcore/snapd/pull/2416 -- it has one +1 and I'd love to land it
<mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
 * zyga takes a break
<pachulo> elopio: are you around?
<jdstrand> tyhicks, ratliff: zyga requested a review of https://github.com/snapcore/snapd/pull/2416 again. where should this be in terms of priorities?
<mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
<zyga> jdstrand: FYI not a urgent thing, just a poke as I was going over all pull requests
<zyga> it should land eventually :)
<zyga> jdstrand: feel free to delegate that to someone if you can
<jdstrand> tyhicks: ^
<ratliff> jdstrand, tyhicks: it seems like a nice refactoring and has been pending for a while, but I would put it below the seccomp arg filtering work that you are focused on this week
 * jdstrand adds card and moves to top of the list behind seccomp and other pending interface reviews
<zyga> thanks!
<mup> PR snapcraft#1053 opened: meta: ensure snap.yaml is desktop free <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1053>
<mup> PR snapd#2646 closed: tests: fix failing snapd-reexec test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2646>
<mup> PR snapd#2636 closed: tests: add "quiet" wrapper function that only prints output on failure <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2636>
<zyga> jdstrand: the thing from last week, https://github.com/snapcore/snapd/pull/2630 already +1 from mvo and waits from a review from you
<mup> PR snapd#2630: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
<zyga> super short apart from the spread test
 * zyga should really stop working
<jdstrand> zyga: yes, it is on my list
<zyga> jdstrand: great
<mup> PR snapcraft#1050 opened: repo: add multiarch support for stage packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1050>
<tito_> Hi
<tito_>  I do have a question regarding this document:
<kyrofa> Hey tito_, welcome
<tito_> https://docs.ubuntu.com/core/en/guides/build-device/image-building
<tito_> hi kyrofa
<tito_> in the end, one can see that console-conf is sheduled and that you need physical access to the machine to go through it
<tito_> imho , the last section (Known problems and limitations)
<tito_> should be extended with a proxy problem...
<tito_> because, how could I modify the image so it would use the proxy at that very initial moment?
<mup> PR snapcraft#1054 opened: snapcraft as a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1054>
<mwhudson> huh i can't install the core snap in a zesty lxd
<mwhudson> - Mount snap "core" (914) ([start snap-core-914.mount] failed with exit status 1: Job for snap-core-914.mount failed.
<kyrofa> tito_, indeed, good question. mwhudson how would one use a proxy in console-conf?
<mwhudson> kyrofa: missing feature
<mwhudson> i think there's a bug for it
<tito_> in my project :)
<tito_> this was a nearly killer
<tito_> The bug mentions about already up and running snappy core system
<mwhudson> huh can't find a bug
<mwhudson> tito_: can you file a bug here https://bugs.launchpad.net/ubuntu/+source/subiquity
<mwhudson> tito_: it shouldn't be incredibly difficult, i hope
<tito_> and concerns about snapd service that consumes /etc/environment file
<tito_> which, by the way, is mounted on RO partition thus I am unable to configure snapd later :(
<tito_> mwhudson - I'm going to do this
<tito_> so, does the console-conf python script utilize snapd at some way while connecting to ubuntu.one ?
<mwhudson> uh is /etc/environment really not writable? fun times
<pedronis> mwhudson: asking, I'm a bit surprised too
<tito_> is really really.
<mwhudson> yeah seems so
<mwhudson> that's fixable too of course
<tito_> and is also nearly killer for my project frankly saying
<tito_> If we/you/someone would fix those two things
<tito_> it would be so perfect
<mwhudson> can use systemd drop-in files for snapd.service specifically
<tito_> so,I've red somewhere that I could do: systemctl edit snapd.service
<mwhudson> but probably it should go in /etc/environment
<tito_> right?
<mwhudson> yeah that should work i think
<tito_> what should i put there ?
<tito_> Environment=someproxyaddress:port ?
<tito_> tfu
<tito_> Environment=http_proxy=someproxyaddress:port
<tito_> ?
<mwhudson> Environment="http_proxy=blahblah:blah"
<mwhudson> & https_ &c
<tito_> and then
<tito_> systemctl restart snapd.service would restart it with new hook for Environment right?
<mwhudson> yes
<tito_> (checking :))
<pedronis> mwhudson: anyway it might be that /etc/environment is meant more for classic, not sure the thinking there
<tito_> pedronis: now, snapd looks for Environment variables in that file
<tito_> mwhudson: does not work unfortunately
<tito_> root@localhost:/tmp# snap install gcc error: cannot install "gcc": Get https://search.apps.ubuntu.com/api/v1/snaps/details/gcc?channel=stable&confinement=strict: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers) root@localhost:/tmp#
<mwhudson> bah snapd in my xenial vm has got itself confused
<mwhudson> pedronis: the bug is clear, the path to a fix not quite so
<mwhudson> Jan 18 09:22:20 ubuntu snapd[2557]: 2017/01/18 09:22:20.086213 patch.go:65: Patching system state from level 3 to 4
<mwhudson> Jan 18 09:22:20 ubuntu /usr/lib/snapd/snapd[2557]: patch.go:72: Cannot patch: cannot get snap state for "core": <nil>
<tito_> mwhudson: the layout of snapd.service edit looks like: Environment="http_proxy=sss:ppp https_proxy=sss:ppp HTTP_PROXY=sss:ppp HTTPS_PROXY=sss:ppp"
<mwhudson> pedronis: any ideas ^ ?
<mwhudson> tito_: not sure you want those quotes like that
<mwhudson> tito_: i think that syntax will set the value of the env var "http_proxy" to "=sss:ppp https_proxy=sss:ppp HTTP_PROXY=sss:ppp HTTPS_PROXY=sss:ppp"
<mwhudson> er minus that first = but you get the idea
<mwhudson> pedronis: i was a bit surprised when snapd install core wanted to install ubuntu-core, i guess snapd was too?
<tito_> mwhudson: fair point
<tito_> but I believe that this trick is overriden by snapd.conf
<tito_> which reads /etc/environment anyway
<tito_> because setting proxies like that (edit snapd.service) does not work unfortunately
<tito_> Ok actually "snapd.conf" is not a proper name, but there is some file that holds already "Environment" entry right?
<mwhudson> tito_: environment entries are cumulative
<mwhudson> so that's not the reason for it not working
<pedronis> mwhudson: you had a very old snapd in that vm?
<mwhudson> pedronis: nope, i installed it from scratch yesterday!
<pedronis> mwhudson: from scratch ?
<pedronis> mwhudson: the base ubuntu-server image has a very old snapd
<mwhudson> installed from 16.04.1 media, apt update, apt dist-upgrade
<mwhudson> and *then* snap install core
<pedronis> that is weird
<pedronis> there's a problem if you try to use snapd before doing apt upgrade
<mwhudson> ubuntu@ubuntu:~$ snap version
<mwhudson> snap    2.20.1+ppa149.4ca4ce07-1
<mwhudson> snapd   unavailable
<mwhudson> series  -
<pedronis> but shouldn't be there after
<pedronis> your snapd is dead
<mwhudson> indeed
<mwhudson> because of the journal entries i pasted above
<pedronis> yes, but those make sense only for an old snapd
<pedronis> not 2.20 or 2.21 (afaik)
<pedronis> (and afaiu)
<mwhudson> hmm
<tito_> btw: my snap version is 2.16 and I took the image from: http://cdimage.ubuntu.com/ubuntu-core/16/current/
<mwhudson> where is the snapd binary?
<mwhudson> ubuntu@ubuntu:~$ /usr/lib/snapd/snapd --version
<mwhudson> error: cannot read the state file: open /var/lib/snapd/state.json: permission denied
<mwhudson> bah
<mwhudson> ii  snapd                            2.0.10                amd64                 Tool to interact with Ubuntu Core Snappy.
<mwhudson> waaaiiiiiiiiiit what
<pedronis> ah
<pedronis> that is compatible
<pedronis> with the logs
<pedronis> you got
<mwhudson> maybe i hadn't run dist-upgrade after all :)
<pedronis> ok
<pedronis> sadly base image has  a very old snapd
<tito_> which is 2.16
<pedronis> no 2.0.10
<tito_> maybe 2.16 does not have the fix for proxy?!
<pedronis> fix for proxy?
<tito_> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1574702
<tito_> this one
<mup> Bug #1574702: 'snap' does not appear to use proxy settings <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1574702>
<mwhudson> awesome time for a system crash
<mwhudson> pedronis: i guess i'll need to purge snapd to fix the mess i have in my vm
<pedronis> mwhudson: yes
<mwhudson> tito_: oh great
<tito_> mwhudson can you tell me what is great ? :)
<mwhudson> tito_: that bug
<mwhudson> tito_: and, in case it wasn
<pedronis> well the fix was adding /etc/environment to the unit afaik
<mwhudson> t obvious, i was being sarcastic :)
<mwhudson> oh ok
<pedronis> (don't know why the bug wasn't updated)
<pedronis> IÂ mean go runtime should do the right thing (tm)
<pedronis> already
<mwhudson> yeah it seems to be odd ball and respect HTTP_PROXY not http_proxy
<tito_> I've mixed all possibilities
<tito_> and no success :/
<pedronis> mwhudson: it should consider either these days
<tito_> maybe I should upgrade snapd itself to latest released version (in the network without proxy)
<tito_> ?
<mwhudson> pedronis: feel free to try sudo snap install --edge --classic go-17-mwhudson if you like :)
<mwhudson> (trying that out was the reason i was futzing about in the vm anyway)
<mwhudson> snapcraft.yaml at https://code.launchpad.net/~mwhudson/+git/gosnap/+ref/master
<mwhudson> tito_: certainly more things are likely to work if you can upgrade snapd
<mwhudson> tito_: but i'm not sure about this thing specifically tbh
<mwhudson> tito_: did you file a but yet?
<mwhudson> i need to afk for a few
<mwhudson> *bug
<tito_> regarding this console-conf proxying?
<tito_> not yet
<tito_> (tried all the time to enable proxy in snapd first)
<ogra_> kgunn, hmm ... i was just wondering, how hard would it be to run an XMir instance on top of the mir-kiosk snap ... that way one could package an X11 session :)
<ogra_> (indeed you'd have to bundle all X apps in the session snap ... )
<tito_> I've even installed snap with wget wrapper
<tito_> so I have tested the proxy itself
<tito_> and it works. But not in case of snapd
<kgunn> ogra_: it'd certainly be possible, i dont see why not
<tito_> and this trick over Environment in snapd.service config
<kgunn> that would be xmir as a system compositor
<ogra_> heh ... so unity7 on pi3 on top of mir *g*
<pedronis> tito_: afaik it should work , we even use it for the snapd own autopackage tests: https://github.com/snapcore/snapd/blob/master/debian/tests/integrationtests
 * pedronis needs to go afk
<tito_> folks, I've put the bug for a console-conf + proxy : https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1657254
<mup> Bug #1657254: console-conf - unable to connect over proxy <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1657254>
<tito_> will back later
<tito_> btw - i love this mup bot ;)
<tito_> ok guys. will talk to you later
<tito_> c u
<mwhudson> oh maybe tito_ wasn't running systemctl daemon-reload
<pedronis> mwhudson: systemctl edit should do that for you
<mwhudson> oh right
<pedronis> anyhow
 * pedronis -> rest
<pedronis> ttfn!
<mwhudson> bye
<wililupy> Question: What is the context for my snapcraft yaml to stage packages for local deb's?
<kyrofa> wililupy, I don't really understand the question
<kyrofa> Context?
<wililupy> kyrofa: My build machien doesn't have internet access, but I have all my stage debians on a flash drive and I want to use that for staging my dependencies for my snap.
<kyrofa> wililupy, eww :P
<kyrofa> wililupy, I wouldn't do it that way, then
<kyrofa> wililupy, because there's no way to tell snapcraft "I want these stage packages... but don't hit the internet"
<kyrofa> wililupy, but you can use .debs as sources
<kyrofa> wililupy, how many stage packages are we talking?
<wililupy> kyrofa: gotcha. Main thing is that this debian repository is unsigned and untrusted so trying to add it to sources.list fails.
<kyrofa> wililupy, yeah if you've got the debs already and don't care about checking for updates etc. just use them as parts
<wililupy> 8
<wililupy> The rest can be pulled from repos...
<kyrofa> wililupy, you could make 8 parts, then, each with a `source: that/one.deb`
<kyrofa> and the dump plugin
<kyrofa> Or you can use the `make` plugin and write a Makefile that just extracts them all in one go
<wililupy> kyrofa: I'll give that a shot.
<kyrofa> Oh no, what am I thinkin
<kyrofa> You can use scriptlets now instead of the Makefile approach
<kyrofa> But yeah, keeping them all as separate parts is probably the easiest if you're okay doing that 8 times
<kyrofa> If you had like 20 though, that would get old
<wililupy> kyrofa: Thanks, I'll try that and let you know how it goes.
<kyrofa> wililupy, sure thing
#snappy 2017-01-18
<Tcab> Can i package a wxpython based app as a snap?
<mup> PR snapd#2635 closed: SNAPD_DEBUG is a boolean (we use GetenvBool() for it) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2635>
<mup> PR snapd#2397 closed: interfaces: add iio <Created by lpotter> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2397>
<mup> PR snapd#2529 closed: interfaces: mm: permissions for protocol proxies <Created by alfonsosanchezbeato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2529>
<zyga> tyhicks: woot, I just read the thead about complain mode for seccomp
<zyga> nice :)
<Tcab> Can i package a wxpython based app using snap?
<zyga> Tcab: hey
<zyga> Tcab: it should be doable, just enough massaging to fit all of the bits in /snap
<eduardas_m> hello, is this an appropriate place to write feedback on Ubuntu Core tutorials that are on ubuntu.com?
<zyga> eduardas_m: I would also recommend https://rocket.ubuntu.com/channel/snapcraft or the snapcraft mailing list
<eduardas_m> zyga, I do not know if this is appropriate, but I filed my minor gripe with documentation here: https://github.com/ubuntu/codelabs/issues/17
<eduardas_m> Because that is where the "Did you find a mistake? Please file a bug." link directs me to from the tutorials page
<zyga> AlbertA: hey, I'd like to discuss https://github.com/snapcore/snapd/pull/2256/files
<zyga> AlbertA: can you please ping me when you have the chance
<Tcab> Ok thanks
<Tcab> Would be great if there  was a simple examp,e / template for a wxpython app.  It could thenbe used by many others
<Tcab> Wxpthon probably means compiling wxpython ? As part of the build process?
<mup> PR snapd#2648 closed: cmd/snap-confine: use flags rather than magic bool constants <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2648>
<mup> PR snapd#2650 opened: also include system-shutdown helper in snapd.install <Created by chipaca> <https://github.com/snapcore/snapd/pull/2650>
<mup> PR snapd#2600 closed: tests: remove the snapd dirs last (should fix random test errors) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2600>
<Person1> Join
<mup> PR snapd#2651 opened: interfaces,overlord/ifacestate: small refactor around reference methods <Created by zyga> <https://github.com/snapcore/snapd/pull/2651>
<tito_> Hi all
<tito_> pedronis: thanks for the yesterday's link to the integration tests
<tito_> man. that was a trip...
<tito_> I used systemctl edit snapd.service to inject http_proxy for snapd daemon
<tito_> it occured that this file, has to contain Service section before the Environment declarations
<tito_> I've lost some time on it :) maybe it is worth to mention in a official documentations?
<tito_> anyway, here is how /etc/systemd/system/snapd.service.d/override.conf should look like:
<tito_> cat /etc/systemd/system/snapd.service.d/override.conf
<tito_> [Service]
<tito_> Environment=HTTPS_PROXY=bla:port
<tito_> Environment=HTTP_PROXY=bla:port
<tito_> Environment=http_proxy=bla:port
<tito_> Environment=https_proxy=bla:port
<tito_> without the [Service] section , does not work.
<mup> PR snapd#2256 closed: overlord/ifacestate: fix missing security setup for connected slot <Created by albaguirre> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2256>
<mup> PR snapd#2651 closed: interfaces,overlord/ifacestate: small refactor around reference methods <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2651>
<mup> PR snapd#2328 closed: Add download manager interface <Created by Elleo> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2328>
<mup> PR snapd#2652 opened: overlord/ifacestate: setup security of snaps affected by auto-connection <Created by zyga> <https://github.com/snapcore/snapd/pull/2652>
<mup> PR snapd#2653 opened: tests: skip i18n test when no "snappy.mo" file is available <Created by mvo5> <https://github.com/snapcore/snapd/pull/2653>
<morphis> ogra_: where is the right location of our reference gadget snaps these days? I see https://docs.ubuntu.com/core/en/reference/gadget#examples-of-production-ready-gagdet-snaps pointing to launchpad but I also see them on github.com/snapcore
<ogra_> morphis, https://github.com/snapcore/pi3-gadget and https://github.com/snapcore/pi2-gadget
<ogra_> updating the latter atm)
<morphis> ogra_: then documentation really needs to be updated
<ogra_> yeah
<morphis> otherwise we're pointing people to old stuff :-)
<ogra_> who owns that nowadays ?
<ogra_> davidcalle, ^^^ is that still your area ?
<morphis> ogra_: I guess you can just do a PR against https://github.com/CanonicalLtd/ubuntu-core-docs or file a bug there
<davidcalle> @ogra_  yes, PR is fine :)
<nothal> davidcalle: No such command!
<davidcalle> ogra_: please have a look at other links you find in the gadget area, in case there is more to update
<ogra_> will do
<davidcalle> Thanks
<eduardas_m> hello, is the image ubuntu-core-16-amd64.img outdated when it comes to snapcraft tutorials in any way?
<morphis> eduardas_m: where do you have it from?
<eduardas_m> morphis, http://releases.ubuntu.com/ubuntu-core/16/ubuntu-core-16-amd64.img.xz
<eduardas_m> I believe I am using this one
<morphis> eduardas_m: should be ok
<morphis> eduardas_m: worth running $ snap refresh inside to get the latest updates
<eduardas_m> the thing is I am trying to follow the snapcraft tutorials word by word... and I found something that works differently
<morphis> eduardas_m: what is it?
<eduardas_m> this might be nitpicking, but I do not get the snap build failure described in https://tutorials.ubuntu.com/tutorial/create-first-snap#3
<eduardas_m> bash installs on first go without adding configflags: ["--infodir=/var/bash/info"]
<eduardas_m> so I thought either the tutorials are outdated or the image is
<eduardas_m> checked the sources of both GNU hello and bash
<eduardas_m> both use the same directory for infodir
<eduardas_m> but no conflict described in tutorial
<longsleep> Quick snapcraft question, which package sources are used for stage-packages - is it the /etc/apt/sources.list.. from the system where snapcraft is run?
<zyga> jdstrand: comments changed as requested, thank you for the capabilities angle, I didn't consider this https://github.com/snapcore/snapd/pull/2630
<mup> PR snapd#2630: many: detect potentially insecure use of snap-confine <Created by zyga> <https://github.com/snapcore/snapd/pull/2630>
<mup> PR snapd#2654 opened: i18n: look into core snaps when checking for translations <Created by mvo5> <https://github.com/snapcore/snapd/pull/2654>
<eduardas_m> if possible, I would like an explanation: Ubuntu Core is for headless systems only or a GUI on a TFT LCD can be added for handheld device?
<eduardas_m> are there pre-build snaps that enable X server + desktop on Ubuntu Core or somehing similar?
<stokachu> longsleep, yea its from your hosts sources.list
<longsleep> stokachu: ok great thanks!
<stokachu> i'd prefer it had its own sources though so i could stage packages from zesty et
<stokachu> etc*
<stokachu> longsleep, np
<mup> Bug #1616629 changed: could not unmarshal state entry "snap-type" <Snappy:Invalid> <https://launchpad.net/bugs/1616629>
<mup> PR snapd#2230 opened: Add an interface that allows clients to use media-hub over dbus <Decaying> <Created by jhodapp> <https://github.com/snapcore/snapd/pull/2230>
<mup> PR snapd#2448 closed: interfaces,snap: account for trusty-specifics in interfaces <Created by vosst> <Closed by vosst> <https://github.com/snapcore/snapd/pull/2448>
<mup> PR snapd#2653 closed: tests: skip i18n test when no "snappy.mo" file is available <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2653>
<mup> PR snapd#2575 closed: cmd: move snap-discard-ns to dedicated directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2575>
<mup> Bug #1649934 changed: USB Auto-mount for assertion import fails <Snappy:Invalid by awe> <https://launchpad.net/bugs/1649934>
<tyhicks> zyga: I should be done with version 2 of the seccomp patches this week so everything is still looking good
<zyga> tyhicks: will you also work on snap-confine changes?
<zyga> tyhicks: do you know if those patches will find their way back to the xenial kernel?
<tyhicks> zyga: yeah, I should be able to do the snap-confine changes
<tyhicks> zyga: I'll be backporting the kernel and libseccomp changes all the way back to xenial
<zyga> tyhicks: and trusty I assume
<tyhicks> zyga: ah, right... libseccomp changes will go back to trusty
<mup> PR snapd#2542 closed: many: use snap-confine to save cost of repackaging core snap for testing <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2542>
<mup> PR snapd#2528 closed: tests: speed up update_core_snap_with_snap_exec_snapctl <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2528>
<mhall119> jdstrand: is the new 'dbus' interface in snapd 2.20?
<mhall119> and is it provided by ubuntu-core, or only core?
<jdstrand> mhall119: yes: https://github.com/snapcore/snapd/wiki/Interfaces#dbus
<jdstrand> mhall119: I don't know the status of ubuntu-core vs core. it is in snapd 2.20. snap --version on an ubuntu-core system should tell you what it has
<jdstrand> I think they are in sync again, but I don't know when that happened
<mhall119> jdstrand: I have 2.20.1ubuntu1, but "snap interfaces" doesn't show dbus
<jdstrand> mhall119: no, it won't because it isn't an implicit slot. it is for providing snaps to use
<mhall119> popey: can you run "snap interfaces" and see if you have "dbus"? IIRC you switched from ubuntu-core to core
<mhall119> oh, nvm popey
<jdstrand> it won't be there
<jdstrand> install corebird-diddledan or ktuberling
<mhall119> I have ktuberling
<mhall119> ktuberling
<mhall119> Qt: Session management error: None of the authentication protocols specified are supported
<mhall119> "Couldn't register name 'org.kde.ktuberling-19990' with DBUS - another process owns it already!"
<jdstrand> mhall119: refresh it
<mhall119> it's brand new from upstream
<jdstrand> mhall119: this morning it was approved
<jdstrand> mhall119: like, less than 1 hour ago
<mhall119> jdstrand: I got it from KDE's build servers directly
<jdstrand> I have no idea what they have. I can tell you that what is in the store is implementing the dbus interface
<mhall119> jdstrand: which store channel?
<jdstrand> edge r5
 * diddledan pricks his ears up
<jdstrand> mhall119: also, 'another process owns it already' suggests that you have multiple ktuberlings running that are allowed to use the interface
<jdstrand> so I think it is working as expected
<mhall119> I don't have other instances of ktuberling running
<mhall119> I suspect it takes a failure to secure the dbus service name as an indication of another being there
<jdstrand> I don't know why it would say what it is saying then
<jdstrand> perhaps something in the backgoround>? </guess.
<jdstrand> >
<mhall119> is there a way to list dbus session services?
<jdstrand> install d-feet
<jdstrand> there are other commands, but I don't know the invocation otoh
<jdstrand> regardless, if you install r5 from the store then do 'snap interfaces' you should see an interface called ktuberling:session-dbus-interface
<mhall119> jdstrand: yup, and I can confirm that the versions in the store do in fact work and it secures the dbus name, so it's something wrong with the new builds, sorry to bother you
<jdstrand> np
<Chipaca> youtube believes this is relevant to my interests: https://www.youtube.com/watch?v=vPBM0g9usMs
<Chipaca> (it isn't *wrong*, per se)
<jdstrand> mhall119: what is the name of the content snap?
<mhall119> kde-frameworks-5
<jdstrand> mhall119: it doesn't seem to be installed when I do 'snap install ktuberling --edge' fwiw
<jdstrand> ah, in --edge
<mhall119> IIRC, snapd doesn't auto-install needed content snaps yet
<jdstrand> mhall119: ok, after installing, connecting the content snap and doing 'sudo /usr/lib/snapd/snap-discard-ns ktuberling' I can confirm that 2.20.1ubuntu1 works as advertised
<jdstrand> that isn't surprising; ktuberling was one of the test snaps for the interface :)
<mhall119> jdstrand: right, I just unpacked the one from their build server and it doesn't have the dbus session interface in snap.yaml, I'll work with them to fix it
<jdstrand> cool
<AlbertA> zyga: ping
<ogra_> tedg_ or mterry, coudl one of you trigger a rebuild of the unity8-session snap ? theer were mir fixes in the overlay PPA that should make it work on the pi, i'd like to try them
<mterry> ogra_: you got it
<Kaleo> sergiusens, not sure if I'm asking the right person but here it goes: what's the difference between the ubuntu-core snap and the core snap?
<mup> PR snapd#2639 closed: snap: add {Plug,Slot}Info.SecurityTags <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2639>
<ogra_> Kaleo, one has ubuntu- in the name
<Kaleo> sergiusens, installing a local snap with classic confinement if you don't have the core snap installed (but the ubuntu-core snap instead): should it work?
<Kaleo> ogra_, :)
<sergiusens> Kaleo, ubuntu-core is deprecated and the snapd team is working on a migration path away from it
<ogra_> (they are identical )
<Kaleo> ogra_, ah ok
<ogra_> but snapcraft requires the core one for classic builds i think
<Kaleo> sergiusens, oh sweet, so will people eventually get core installed automatically?
<ogra_> (it checks for the name)
<ogra_> thats the plan
<sergiusens> Kaleo, new installs already do, people with older installs will transition
<Kaleo> sergiusens, sweet; I guess I'll follow https://bugs.launchpad.net/snappy/+bug/1655599
<mup> Bug #1655599: No migration of ubuntu-core to core <Snappy:New> <https://launchpad.net/bugs/1655599>
<Kaleo> sergiusens, ok and so, installing a local snap with classic confinement if you don't have the core snap installed (but the ubuntu-core snap instead): should it work?
<sergiusens> Kaleo, it won't
<sergiusens> Kaleo, if you are not invested in snaps yet apt remove --purge snapd
<sergiusens> if not, wait
<mup> PR snapd#2655 opened: cmd: switch to non-recursive make <Created by zyga> <https://github.com/snapcore/snapd/pull/2655>
<Kaleo> sergiusens, I did not understand what you meant with being invested
<Kaleo> sergiusens, thanks for the answers
<sergiusens> Kaleo, using snaps a lot, as puring snapd makes you lose all your snap data
<Kaleo> sergiusens, ah yes
<Kaleo> sergiusens, ok
<ogra_> mterry, doesnt feel like it ... i just end up with a black screen (mir-kiosk at least gives me a cursor and turned on backlight on black screen, unity8 doesnt, backlight of the monitor goes off, no cursor)
<ogra_> http://paste.ubuntu.com/23822572/ is the unity8 log
<ogra_> looks like it misses the gallium driver
<ogra_> sadly i need to re-flash the SD so i cant test further ...
<mterry> ogra_: well all I did was rebuild it after you mentioned -- does https://launchpad.net/~unity-team/+snap/unity8-session-silo/+build/17398 have the versions of packages that you expect?
<ogra_> mterry, i guess it does ... but i think we are missing a mesa driver that kgunn provides in his mir-kiosk snap
<ogra_> i cant imagine mesa-kms or mesa-x11 to work on a pi
<mterry> hmm, if you know of a package we ought to include, I can add it.  But drivers seem low-level for the unity8 snap, long term.  Maybe we're including them now as a stop-gap tho
<ogra_> mterry, well, i'm not sure what mir-kiosk includes that you dont ... else i'D simply tell you :)
<mterry> ogra_: sure  :)   I'll make a note to ask kgunn for his snapcraft.yaml
<ogra_> mterry, hmm, it might actually be something different, i see the snap ships its own cgmanager service and tried to start it ... which clashes with the system cgmanager that is already running
<mterry> ogra_: oh is that provided by a different snap now?
 * ogra_ sees complaints in the logs
<mterry> that was just to get us going
<ogra_> mterry, it is provided by the OS on the ubuntu-core pi2/3 images
<ogra_> though that shouldnt be any different to the ubuntu-core kvm images ...
<ogra_> perhaps its a red herring
<ogra_> i only noticed it complaining in the logs
<mterry> sure, but that's a good bit of cleanup we can do regardless
<ogra_> not sure if snaps actually have access to it though ... when not running in --devmode
<mterry> ah no interface yet
<ogra_> yep
<mup> PR snapd#2545 closed: overlord: allow max 500 changes in "ready" state to avoid growing changes for 24h <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2545>
<mup> PR snapd#2656 opened: spread: refresh apt cache before first install <Created by zyga> <https://github.com/snapcore/snapd/pull/2656>
<mup> PR snapd#2657 opened: snapmgr, ifacemr: add automatic ubuntu-core -> core transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/2657>
<roadmr> hello folks. I want to build a classic-confinement snap. How do I set the "core_dynamic_linker"?
<kyrofa> roadmr, you need the core snap
<roadmr> kyrofa: AH
<roadmr> kyrofa: thanks :)
<kyrofa> roadmr, dreadfully unhelpful error, we know-- it's fixed in the next release
<roadmr> kyrofa: yes, I just found it by grepping around on snapcraft's source :) installing core now... yay
<mup> PR snapd#2656 closed: spread: refresh apt cache before first install <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2656>
<roadmr> kyrofa: can't install core while ubuntu-core is installed, but can't remove ubuntu-core :(
<kyrofa> roadmr, indeed-- you have to purge remove snapd I'm afraid. The snapd team are working on a migration to make that bette
<kyrofa> r
<zyga> kyrofa: mvo just proposed a pull request for this
<kyrofa> zyga, nice!
<zyga> kyrofa: it will be likely fixed next week
<zyga> (next release)
<kyrofa> zyga, thanks for the heads up
<roadmr> kyrofa: /o\ not ideal :) but it'll do. Purging!
<roadmr> kyrofa: my shiny classic snap is ready :) thanks!
<kyrofa> roadmr, any time, sorry for the inconvenience!
<kalikiana> ogra_: Thanks for your comment on bug 1576282. Could you perhaps try to summarize exactly how data behaves? I might not have my details right. My assumption was, that snaps are compressed, but at one point they will be uncompressed in memory or possibly swap space - so eventually 3.5M becoming 35M, or 5M becoming 125M if we wanted more locales, would still weigh down on the system
<mup> Bug #1576282: Snaps built from deb can't be gettext translated <personal> <snap-desktop-issue> <Canonical System Image:In Progress by kalikiana> <Snapcraft:New>
<mup> <Ubuntu App Platform:In Progress by tpeeters> <snapcraft (Ubuntu):Confirmed for sergiusens> <unity8 (Ubuntu):Confirmed> <https://launchpad.net/bugs/1576282>
<ogra_> kalikiana, they are just loop mounted as-is ... run "mount" on your pc ;)
<kyrofa> zyga, this question could use you: https://askubuntu.com/questions/872991/trying-to-install-via-snap?noredirect=1#comment1355694_872991
<kalikiana> ogra_: Well, surely apps have to access them uncompressed since they're not aware of the filesystem details?
<ogra_> kalikiana, indeed if you copy anything out of the snap into a common dir or the user dir it gets uncompressed
<zyga> kyrofa: looking
<kalikiana> Maybe I'm just thinking about it the wrong way
<ogra_> kalikiana, they are uncompressed on the fly when accessed ... any only the bits that go into ram
<ogra_> by the kernels squashfs driver
<ogra_> that is how we fit a 2GB filesystem onto a 600MB CD since years already ;)
<kalikiana> ogra_: Hmmmm so maybe I should look at the data, locales in the particular case, that the app actively uses, to see what memory it will require?
<ogra_> there is a loop mount and the inodes are exposed (so you have file references) on access data is decompressed on the fly
<kalikiana> Right, I know the disc can be smaller, but those CDs usually require a lot of memory
<ogra_> well, but not 2GB ... it is really only what is actively open that occupies RAM
<ogra_> for your locales only the files in use will be in ram
<ogra_> but they wont need any diskspace or have to be uncompressed anywhere
<ogra_> thats the beauty of squashfs
<ogra_> you can safley measure a snaps size by its actual size ... only if you have any scripts that unpack stuff to a userdata dir or into the common dir your snap will occupy more
<kalikiana> I guess I'm used to thinking worst case. But indeed the memory of a single locale would be small if all strings were loaded
<ogra_> yeah
<ogra_> and the unudes locales just sit in the compressed snap
<ogra_> if adding locales adds 3.5MB thats about it ... it wont grow in any way
<ogra_> this is why the ubuntu-core image effectively only occupies ~150MB for everything even though it would be closer to 500 if you actually unpacked all the files
<kalikiana> Maybe we can get all locales in then - I was making a snap with only the subset used on the phone as the original data is quite big
<ogra_> ogra@localhost:~$ sudo du -hcs /snap/core/922
<ogra_> 186M	/snap/core/922
<ogra_> 186M	total
<ogra_> ogra@localhost:~$ df -h | grep core/922
<ogra_> that might give you an impression ;)
<ogra_> err
<ogra_> ogra@localhost:~$ df -h | grep core/922
<ogra_> /dev/loop3       65M   65M     0 100% /snap/core/922
<ogra_> better :)
<ogra_> effectively it only occupies 65M ... even though the content is actually 3x the size
<popey> Anyone seen a snap fail to run with accessing /run/user/1000/snap.<snapname>  ?
<popey> http://paste.ubuntu.com/23823245/  getting that, maybe jdstrand knows? :)
<popey> it's installed in devmode
<jdstrand> popey: "No such file or directory"
<jdstrand> popey: mkdir -p /run/user/1000/snap.servo
<jdstrand> there is a bug on that. let me find it
<popey> make the dir as part of the launcher?
<jdstrand> as a workaround for the bug, yes
<popey> that'll do for now, thanks
<popey> I guess I should parameterise it? $UID or whatever for 1000 ?
<kalikiana> ogra_: Impressive indeed. Thanks for enlightening me
<jdstrand> popey: https://bugs.launchpad.net/snappy/+bug/1656340
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <Snappy:Confirmed for zyga> <https://launchpad.net/bugs/1656340>
<jdstrand> popey: no, XDG_RUNTIME_DIR is correctly set. just do 'mkdir $XDG_RUNTIME_DIR'
<popey> jdstrand: thanks
<jdstrand> popey: there is an alternative way to do it in comment #1
<popey> will subscribe to bug and workaround for now.
<kyleN> Ihow do I determine the key associated with my "brand", where I created my sso account a long time account. (myapps.developer.ubuntu.com lists my Account-Id but I am not sure which (if any) key that is associated with.
<kyleN> a long time AGO (I meant)
<kyleN> none of my local snap keys (snapcraft list-keys) have the same fingerprint as the Account_id listed in the store.
<Chipaca> pedronis, is the relation between account id and keys documented anywhere?
<mup> Bug #1657552 opened: [spread] install-sideload:reexec0 failure <Snappy:New> <https://launchpad.net/bugs/1657552>
<pedronis> kyleN: are you logged in as that SSO account ?
<zyga> jjohansen: hey, in case you are around, I had a look at the new kernel and I've collected some data (attached to the bug) but perhaps it would be better if you had a look and told me what to look for
<zyga> jjohansen: it seems that the failure I get is different than before
<zyga> jjohansen: (before == stock kernel)
<zyga> jjohansen: in any case, I will be around for a few more moments, please ping me with instructions if you can
<jjohansen> zyga: yep, just getting in, I will have a look at it
<zyga> oh hi :)
<zyga> great
<kyleN> pedronis, yes
<pedronis> kyleN: snapcraft can get for the store enabled keys that are not local, but doesn't have a way to print them afaik atm
<pedronis> s/for the store/from the store/
<kyleN> pedronis, ok. I'll keep looking around. thanks
<mup> PR snapcraft#1024 closed: gradle plugin: update gradle plugin to support both gradle and gradlew <Created by ZenHarbinger> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1024>
<pedronis> kyleN: this might print relevant info:  python3 -c "import snapcraft.storeapi; print(snapcraft.storeapi.StoreClient().get_account_information().get('account_keys'))"
<sergiusens> stgraber, have you seen LP: #1657252 ?
<mup> Bug #1657252: lxd no longer works with 2.21 <snapd:New for zyga> <https://launchpad.net/bugs/1657252>
<stgraber> sergiusens: I believe I commented in it
<sergiusens> ah, sorry, you have
<sergiusens> I didn't refresh!
<kyrofa> jdstrand, just so I'm clear, the serial port interface attributes you mentioned here does not currently exist? https://bugs.launchpad.net/snappy/+bug/1645445/comments/2
<mup> Bug #1645445: Turtlebot needs /dev/kobuki <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1645445>
<sergiusens> jdstrand, is there a way to manually connect?
<mup> PR snapd#2652 closed: overlord/ifacestate: setup security of snaps affected by auto-connection <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2652>
<jdstrand> sergiusens: is snap connect not working for you?
<jdstrand> kyrofa: they all exist. see https://github.com/snapcore/snapd/wiki/Interfaces#serial-port. note this is slot side in the gadget snap
<kyrofa> jdstrand, ah excellent, I misunderstood then
<mup> PR snapcraft#1055 opened: store: proper error colors for login failures <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1055>
<jdstrand> sergiusens: I responded in the bug
<mup> PR snapd#2655 closed: cmd: switch to non-recursive make <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2655>
<mup> PR snapd#2658 opened: cmd: add mount / unmount helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2658>
<zyga> jdstrand: ^^ I'd like to use those helpers for snap-alter-ns
<zyga> jdstrand: essentially mount/umount with loggin
<zyga> logging*
<mup> PR snapd#2659 opened: tests: fix path used when debugging <Created by zyga> <https://github.com/snapcore/snapd/pull/2659>
<pedronis> jdstrand: about the lxd bug, it seems not even network is autoconnected, that is weird
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2643/files is the stub snap-alter-ns (does nothing), I'd like to land it to focus subsequent reviews on what matters
<mup> PR snapd#2643: many: add stub implementation of snap-alter-ns <Created by zyga> <https://github.com/snapcore/snapd/pull/2643>
<zyga> pedronis: could it be a locally built lxd without assertions?
<pedronis> zyga: no, from the store, also as I said, seems even network is not autoconnected
<jdstrand> zyga: I'm focused on several other things atm. I will add this to my list. won't be today
<pedronis> zyga: there's more new info in the bug
<zyga> jdstrand: ack
<zyga> pedronis: checking
<zyga> hmm
<zyga> we have real tests for auto-connection, I wonder if they are not that real or is there something else at play
 * zyga needs a break
<zyga> ttyl
<jdstrand> pedronis: it is weird indeed
<mup> PR snapcraft#1056 opened: schema: print allowed length for length failures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1056>
<stokachu> im having some issues getting a systemd script to start, hitting this error, http://paste.ubuntu.com/23824282/, my snapcraft is setting up a oneshot service so that some iptables rules get set on reboot/boot https://github.com/conjure-up/conjure-up-snap/blob/master/snapcraft.yaml
<stokachu> this is a classic snap and these start/stop scripts are used in our debian packaging without an issue
<stokachu> if i run the commands that are generated in the systemd file they work
<stokachu> how do i force install the snap even though the start snap "conjure-up" services fail?
<stokachu> i also dont see the generated systemd file inside my prime directory
<kyrofa> stokachu, yeah, snapd does the systemd bits, not snapcraft
<kyrofa> stokachu, I'd refer you to one of them, but they're all EOD by now
<stokachu> so the service file is like ExecStart=/usr/bin/snap run conjure-up.service
<stokachu> if you run that directly it works
<stokachu> ah ok
<kyrofa> stokachu, when you install the snap, snapd interrocates the meta/snap.yaml file to determine what services it contains, as well as their properties, then generates systemd unit files for them
<stokachu> ah i see the snap.yaml
<stokachu> kyrofa, so can i add some debugging to these command wrappers that are generated in the prime directory and rebuild?
<kyrofa> stokachu, of course
<stokachu> ok cool lemme dig into those files
<kyrofa> stokachu, though if you mess with snapcraft's auto-generated stuff, don't just run `snapcraft` again (as it'll regenerate those files over the top of your changes)
<stokachu> ah
<kyrofa> stokachu, instead you can run `snapcraft snap prime` to just tell snapcraft "make a snap out of this directory"
<stokachu> kyrofa, gotcha, thanks
<stokachu> so another issue i noticed is my aliases doesn't seem to be working
<stokachu> where i have 'conjure-up.juju' i wouldn't thought that aliases would've given me just 'juju' as the executable
<stokachu> would've*
<pedronis> stokachu: did you enable them?
<stokachu> pedronis, if it's a setting then no i didnt
<pedronis> stokachu: they are just an hint, the admin needs to use "snap alias"Â to enable them
<stokachu> pedronis, how can i automate that?
<pedronis> later there will be ways to ask for them to auto enabled them but it's a shared namespace so not everything foes
<stokachu> ah ok
<pedronis> s/foes/goes
<stokachu> makes sense
<sergiusens> pedronis, it already works, lxd is using it
<stokachu> that's where i got the example from
<sergiusens> the problem with juju is the colision with the actual juju snap
<stokachu> i assume that's enabled on the backend
<sergiusens> yes
<sergiusens> someone like jdstrand would do it
<stokachu> so i can just leave it at conjure-up.juju
<stokachu> no biggie and it makes sense as im not the upstream of juju
<pedronis> sergiusens: yes, the tech bits are there, the processes aren't
<sergiusens> but for juju it seems it might be a bit more complicated. Why do you nee juju aliased instead of just calling juju; the juju in your snap should have precedence to anything external
<pedronis> stokachu: yes, the idea here is that usually aliases will got to upstreams (afaiu)
<stokachu> it is called juju but it ends up being conjure-up.juju
<stokachu> pedronis, ack
<stokachu> sergiusens, fwiw i dont need it aliased
<stokachu> i just saw it in lxd and wanted to be like the cool kids
<stokachu> sergiusens, now if i could just get my systemd stuff to work i'd be in good shape
<stokachu> also i have a snapcraft and a snap directory, can i consolidate and just put my snapcraft/{setup,wrappers} in the snap directory?
<sergiusens> stokachu, as soon as I get a PR in, should be doable in snapcraft 2.26
<stokachu> sergiusens, thanks
<stokachu> sergiusens, im running from master anyway
<sergiusens> stokachu, I'll get to you as soon as those are migrated.
<mup> PR snapcraft#1053 closed: meta: ensure snap.yaml is desktop free <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1053>
<sergiusens> balloons, hey, on https://github.com/juju/juju/blob/master/snapcraft.yaml#L16 why don't you do `source: .`?
<sergiusens> no need to double checkout if not, and would be interested in a bug if this was tried and did not work :-)
<diddledan> heads'-up I've just released corebird 1.4.1 (corebird-diddledan) :-)
<wililupy> kyrofa: The snap builds. I'm tweaking my wrapper script for the service to start, but I keep getting permission denied errors and no extra details as to why it is denied. The library paths are 755 so I'm not sure what to check next....
<zyga> wililupy: dmesg | grep DENIED
<wililupy> zyga: doesn't return anything
<zyga> wililupy: okay, good
<zyga> wililupy: can you tell me more about your snap and the service, where does the error occur, what is the actual precise message
<wililupy> sure.
<wililupy> My snap runs a service through a wrapper script to pass the correct paths to the configs and PID locations, but when it tries to load libraries, it gets Permission Denied Errors in the /var/log/syslog
<zyga> how does it load libraries?
<zyga> where are the libraries it wants to load
<mup> PR snapd#2659 closed: tests: fix path used when debugging <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2659>
<wililupy> I tried adding the export LD_LIBRARY_PATH= to the wrapper which fixed the first missing library error I was getting.
<zyga> jjohansen: hey, I'm about to go to bead
<zyga> bed*
<zyga> jjohansen: anything I can do tomorrow to help you out?
<wililupy> They are located in $SNAP/usr/lib and $SNAP/usr/lib/x86_64-linux-gnu
<zyga> so far so good
<zyga> is this a snap with classic confinement?
<wililupy> I added the other two paths, but get a permission denied for $SNAP/usr/lib and $SNAP/usr/lib/x86_64-linux-gnu and it says it can't find a shared library in that path.
<wililupy> No, it using devmode.
<zyga> wililupy: are you aware of the snap execution environment differences, the chroot and other bits?
<wililupy> my next step if I couldn't get it to work in devmode was classic and install these libraries in /usr/lib...
<zyga> wililupy: did you try snap run --shell yousnap
<zyga> wililupy: and explore how the filsystem look like
<zyga> wililupy: don't add classic to the mix unless running in classic is your goal, I think it will be significantly easier this way
<zyga> wililupy: classic confinement is not without a grain of salt and complexity of its own
<wililupy> zyga: I'll try the snap run command to see what happen...
<wililupy> will snap run work with daemons?
<zyga> wililupy: yes, it runs with anything
<zyga> wililupy: daemons run via snap run
<zyga> wililupy: snap run --shell is special
<zyga> wililupy: it sets up confinement the same way but runs shell instead
<wililupy> snap run --shell fboss returns error: cannot find app "fboss" in "fboss"
<zyga> you need to run snap.app
<zyga> wililupy: try snap run --shell fboss.fboss
<zyga> or whatever the application name is
<mup> PR snapd#2660 opened: cmd: fix typo (thanks to jdstrand!) <Created by zyga> <https://github.com/snapcore/snapd/pull/2660>
<wililupy> hmm. In my snapcraft.yaml I call the app wedge_agent but when I try to run snap run --shell fboss.wedge_agent it says error: cannot find app "wedge_agent" in "fboss"
<zyga> the app cannot be called wedge_agent
<zyga> can you show me the apps section please
<zyga> jdstrand: thanks for spottng the typo
<wililupy> zyga: http://pastebin.ubuntu.com/23824832/
<zyga> jdstrand: and sorry for messing up any changes in flight
<zyga> wililupy: the app name is wedge-agent
<zyga> wililupy: try snap run --shell fboss.wedge-agent
<wililupy> zyga: damnt typos... thanks.
<wililupy> ubuntu@wedge100:/snap$ sudo snap run --shell fboss.wedge-agent
<wililupy> support process for mount namespace capture exited abnormally
<zyga> check "journalctl -f" please
<zyga> wililupy: which version of snap are you on?
<zyga> snap --version
<wililupy> 2.20
<zyga> is this core or classi
<zyga> *classic
<wililupy> classic
<wililupy> zyga: http://pastebin.ubuntu.com/23824848/    journalctl dump.
<wililupy> so I think that answers my question. The software was built to look in those hard directories for the libraries...
<zyga> Jan 18 23:21:25 wedge100 audit[28539]: AVC apparmor="ALLOWED" operation="getattr" info="Failed name lookup - disconnected path" error=-13 profile="snap.fboss.wedge-agent//null-/bin/journalctl" name="dev/pts/1" pid=28539 comm="journalctl" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<wililupy> zyga: so why is that getting denied?
<wililupy> zyga: That path doesn't exist on here.
<jjohansen> zyga: sorry, I am not sure yet. I will make sure to fill in the bug
<zyga> jjohansen: thanks
<zyga> wililupy: did you run journalctl from the spawned shell?
<wililupy> yes
<zyga> wililupy: can you run it from the regular environment instead (then reproduce the problem and see the new messages)
<wililupy> Sure.
<zyga> wililupy: thanks, I need to sleep now, please leave me a message
<wililupy> zyga: will do. thanks!
#snappy 2017-01-19
<mup> PR snapcraft#1044 closed: tests: use python2 to check the CLA <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1044>
<mup> PR snapcraft#1032 closed: Use more secure temporary directory for parser runs <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1032>
<mup> Bug #1657633 opened: console-conf shows the previous IP address after reconfiguration <Snappy:New> <https://launchpad.net/bugs/1657633>
<Gcode> Help
<Gcode> i want to learn python, for ethic hacking and sockts
<morphis> ogra_: is https://code.launchpad.net/~snappy-dev/core-snap/trunk the right place to look for the core snap?
<ogra_> morphis, yep
<ogra_> morphis, what do you need ?
<morphis> ogra_: we're close to add a configure hook to the core snap, so just checking where the source for it is :-)
<ogra_> oh
<ogra_> the backend needs to go into some deb ... probably ubuntu-core-config
<ogra_> from the image PPA
<morphis> ogra_: so what assembles the core snap then?
<ogra_> live-build
<ogra_> (with livecd-rootfs holding the config and possible hacks)
<morphis> and how can we get the meta/hooks/configure script added
<ogra_> hmm, you want to put the whole of it there ? uncludion the binaries you need ?
<ogra_> *uncluding
<ogra_> bah
<ogra_> *including
<morphis> ogra_: it will be a simple bash script
<ogra_> ah, k
<ogra_> yeah, that might be fine
<morphis> we just need one option to enable/disable sshd
<mup> PR snapd#2660 closed: cmd: fix typo (thanks to jdstrand!) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2660>
<ogra_> morphis, that will need more i guess
 * ogra_ tries to touch /etc/ssh/sshd_not_to_be_run on a running system 
<ogra_> ah, no, seems fine, it is writable
<morphis> :-)
<morphis> ogra_: I guess that the configure hook within the core snap should have rights to do anything or is it run inside a confined environment too?
<ogra_> i thought we had only made individual files writable in that dir ... then you are fine just add or remove the file (and stop/start with systemctl)
<ogra_> morphis, how would it if the file is in the squashfs ?
<ogra_> it cant physically write to it then
<morphis> that is true
<ogra_> but here we're fine, all of /etc/ssh is writable so you can just touch and remove it as you need
<morphis> good
<morphis> ogra_: so where is ubuntu-core-conf these days, still a single deb package sitting in the ppa or is a there a repository for it?
<ogra_> i dont think there is a repo
<ogra_> just grab the source deb from the ppa, make your changes and give it to someone who can upload
<morphis> ogra_: aye
<ogra_> :)
<ogra_> morphis, you probably want to add some checks that a user exists and has a local password to not make it possible that the admin completely locks out himself
<ogra_> you are quite screwed if you disable ssh and have no local console access either
<morphis> yeah
<morphis> ogra_: what do we have to change in livecd-rootfs then?
<ogra_> nothing, meta/hooks/configure should be fine unless you need additional stuff from the image itself
<morphis> so meta/hooks/configure inside ubuntu-core-conf, correct?
<ogra_> hmm
<ogra_> well, livecd-rootfs might work too ... i'm not sure if the build will respect an existing /meta dir inside the chroot though, might be that snapcraft ignores it
<morphis> ogra_: so you're using snapcraft to build the final snap?
<ogra_> or that we actually delete it ... need to check the code ... there was something about old /meta
<Kaleo> mvo, the ubuntu-core to core transition patch will be part of the next snapd release?
<ogra_> morphis, http://bazaar.launchpad.net/~snappy-dev/core-snap/trunk/view/head:/Makefile ... line 26 :/
 * ogra_ goes to check the bug, perhaps we can drop that nowadays
<morphis> :-)
<mvo> Kaleo: that is the goal, you can test the ppa that I gave to pat the other day if you want, I think the transition code is ok, I'm currently working on robustness and some warts but I think the core (no pun intended) is ok, so if you tst it I would appreciate results
<morphis> ogra_: I will tell whoever will add the configure hook from our team to check with you first :-)
<Kaleo> mvo, superb
<Kaleo> mvo, I already manually migrated unfortunately
<mup> PR snapd#2549 closed: cmd/snap-confine: add shutdown helper <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2549>
<ogra_> morphis, iirc the issue was that snapcraft didnt create anything in meta/ if the dir already existed ... so i'm not sure we can actually use that
<morphis> ogra_: you could use a new part in snapcraft.yaml with the dump plug
<ogra_> we need to try what happens i fear
<morphis> s/plug/plugin/
<Kaleo> mvo, is there any way for a single snap to be installable in either classic or devmode confinement?
<morphis> then we don't have to maintain the hook inside ubuntu-core-conf at all
<ogra_> well, feel free to try it ... we can do tests in edge, that is what it is for ;)
<morphis> good
<ogra_> in any case that line from the Makefile will likely need to go
<mup> PR snapd#2449 closed: overlord/patch: patch to flag in the state required snaps from model <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2449>
<mup> PR snapd#2650 closed: also include system-shutdown helper in snapd.install <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2650>
<mvo> Kaleo: I think there is no way  for a single snap to be installable in either classic or devmode confinement. but Chipaca might have ideas here
<Kaleo> mvo, thanks
<Chipaca> i'm not sure i understand the question
<Kaleo> Chipaca, let's say I have an app snapped up
<ogra_> you can only install them in pairs ?
<ogra_> :P
<Kaleo> Chipaca, and I'd like to be able to install it forcing either classic confinement or devmode confinement
<Kaleo> Chipaca, why? because IIUC you cannot install an app with classic confinement in an all snaps image, right?
<ogra_> yeah
<Chipaca> Kaleo, there isn't a way to do that today
<Kaleo> ogra_, Chipaca, mvo: at the core of the issue, think about how you would go about snapping gnome-terminal
<Kaleo> with the goal to make it one day work fine in an all snaps image
<Kaleo> Chipaca, right, to do that, you can use classic confinement
<Kaleo> Chipaca, ok
<ogra_> make it use a gazillion interfaces ?
<Chipaca> Kaleo, in general however that's not something that makes sense
<Chipaca> i mean, installing a classic snap on an all-snaps image
<Chipaca> classic snap means it needs all the accoutrements of a classic system
<Kaleo> ogra_, right
<Kaleo> Chipaca, yeah, I'd like to install it confined, ie. override the classic confinement
<Chipaca> which are not present in all-snaps
<Kaleo> Chipaca, so let me explain
<Kaleo> Chipaca, the main reason you want to use classic confinement for a terminal is to have / be /
<Kaleo> Chipaca, and let the user of terminal have access to all commands available on the base system
<ogra_> which is probably not such a good idea in an all-snaps image anyway
<ogra_> (have / be / )
<Kaleo> ogra_, it depends if you envision say desktop users using an all snaps version of ubuntu or not
<ogra_> well, 96% of / will be readonly
<Kaleo> ogra_, readonly is good
<Kaleo> ogra_, it's not about writing on /
<Kaleo> ogra_, it's about reading
<ogra_> and for the other 4% you want no user to touch the majority of it since it is managed via the system tools internally
<Kaleo> ogra_, yep, I don't want anyone to write
<ogra_> so changing stuff underneath might break things badly
<Kaleo> ogra_, no writes
<Kaleo> ogra_, readonly /
<pedronis> but with classic you can write there assuming you have sudo
<Kaleo> pedronis, yes
<Kaleo> pedronis, and that's a side effect I don't care for
<ogra_> i guess for that you could special case the apparmor rules
<ogra_> and have manual approval for that one package
<Kaleo> ogra_, pedronis, what I just need for a terminal is / to be /
<Kaleo> without / being writable
<ogra_> indeed thats a major security issue
<pedronis> I really think that if the end goal is working on all-snaps, is better to start thinking what you need there
<ogra_> since you can see what other processes do
<Chipaca> Kaleo, on all-snaps / is already /
<ogra_> Chipaca, but you cant look at all of it
<ogra_> i guess that is what he wants
<ogra_> which defeats security ... kind of
<pedronis> so it's a bit of ther reverse problem, on classic /Â is not / unless classic
<Chipaca> Kaleo, there's nothing stopping you from installing an 'strict' snap with --classic btw
<ogra_> Chipaca, on an all-snaps image ?
<Chipaca> no, on classic
<ogra_> oh, you mean the other way around
<ogra_> yeah, ignore me ... coin took a bit to drop :P
<morphis> Chipaca: for installation but I guess for running apps from it there is as from what I've heard from zyga
<Chipaca> zyga, ^?
<Chipaca> morphis, it's possible we've got bugs there :-)
<Chipaca> I know of at least one
<Kaleo> Chipaca, oh my god
<Kaleo> Chipaca, how come I did not realise that
<Kaleo> Chipaca, / is / with all snaps
<Kaleo> Chipaca, " there's nothing stopping you from installing an 'strict' snap with --classic btw"
<Kaleo> Chipaca, I was testing that just now
<mup> PR snapd#2417 closed: interfaces/builtin: add uhid interface <Created by bergotorino> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2417>
<Kaleo> Chipaca, http://pastebin.ubuntu.com/23827096/
<Chipaca> Kaleo, it's a devmode snap, devmode+classic won't work
<Chipaca> note i said strict
<Kaleo> Chipaca, yep
<Chipaca> k
<Kaleo> Chipaca, though I need it to be devmode on all snaps because?
<ogra_> yeah, devmode wont buy you much if you want to use the store and snap find to find it
<Kaleo> ogra_, you mean devmode makes it non visible in the store?
<ogra_> devmode cant go to the stable channel ...
<mup> PR snapd#2546 closed: overlord: use a ticker for the pruning <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2546>
<Chipaca> can't go to any stable-grade channel even
<ogra_> yeah
<Kaleo> ok
<Chipaca> Kaleo, you sure you need it devmode in all-snaps?
<Kaleo> maybe not
<Kaleo> I need to think that through
<Kaleo> let's imagine that I don't
<Chipaca> Kaleo, look at the things the htop snap uses
<Kaleo> 1) is there a way to upload a strictly confined snap and have it be installed with --classic on classic automatically?
<ogra_> well, that only accesses parts of proc
<Kaleo> 2) is there a programmatic way to detect what confinement we are under?
<Chipaca> Kaleo, (1), no
<Chipaca> Kaleo, (2), no
<Chipaca> (2) should be easy to implement iffen jdstrand thinks it's a good idea (i'm not too sure it is)
<Chipaca> (1) is a bad idea
<Kaleo> (2) I'm not sure I will need it
<Kaleo> (1) right, but then I need some other tool
<Kaleo> (1) cause people really need / to be / for their terminal on a classic ubuntu
<ogra_> 2 -> grep snap_core /proc/cmdline ...
<Kaleo> ogra_, nice
<ogra_> the prob is that you might not be able to access that
<ogra_> (at least not before manually connecting an interface ... so you wont be able to automate)
<Chipaca> today you can
<ogra_> Chipaca, from a strict snap ?
<Chipaca> yes
<ogra_> oh
<ogra_> i thought most of /proc was blocked by default
<Chipaca> less is blocked than we want
<ogra_> except for /proc/self/
<Chipaca> because of issues
<ogra_> ah
<mup> PR snapd#2661 opened: tests: skip on untrusted keys <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2661>
<Chipaca> so i wouldn't count on it without checking with people that know more than me
<ogra_> yeah
<timp> is this the correct channel to ask questions about snapcraft?
<ogra_> i'm pretty sure long term we dont want that
<ogra_> timp, try asking one and you will see ;)
<timp> the store tells me for my snap: desktop interfaces (unity7) specified without meta/gui/*.desktop. Please provide a desktop file via setup/gui/*.desktop if using snapcraft or meta/gui/*.desktop otherwise. It should reference one of the 'apps' from your snapcraft/snap.yaml. lint-snap-v2_meta_gui_desktop
<Kaleo> Chipaca, I switched the snap to strict then installed it with snap install --classic --dangerous ubuntu-terminal-app_0.11_amd64.snap
<Kaleo> Chipaca, it looks like / is not /
<Kaleo> Chipaca, even though it installation went fine
<timp> in which step is this desktop file checked? I wonder if I need to have this desktop file available for the first step, or it can be there later. My snap is built from downloaded debs that already include desktop files
<Kaleo> Chipaca, checking
<Chipaca> Kaleo, in what sense is / not /? (not saying you're wrong, but wondering)
<Kaleo> Chipaca, as in the / inside the snap environment is not the same filesystem as the / outside
<Kaleo> Chipaca, double checking now
<Chipaca> timp, it needs to be there in prime/ as far as i know
<Chipaca> zyga, you here?
<Kaleo> Chipaca, right, for example the contents of /bin are different inside of the snap and outside
<timp> Chipaca: okay, thanks
<Chipaca> Kaleo, but confinement lets you do pretty much everything?
<Kaleo> Chipaca, checking
<Chipaca> Kaleo, probably just something we need to do
<Kaleo> Chipaca, (I think so)
<Chipaca> (that's what i checked, that confinement seemed to be as expected)
<pedronis> Kaleo: / is / doesn't mean we don't bind mount thing on top
<Kaleo> pedronis, agreed
<Kaleo> pedronis, but there is _less_ stuff
<Chipaca> pedronis, yeah, but classic means don't do as much of that
<Chipaca> i think?
<Chipaca> paging dr zyga
<zyga> hey
<pedronis> Chipaca: we do less, but IÂ think it still defeats the goal, though there is probably some way out of that
<zyga> sorry, I don't get notifications for IRC
<Kaleo> pedronis, knowing that when the same snap was built with confinement: classic instead of confinement: strict, there was way more content accessible
<Kaleo> pedronis, even though both were installed with --classic
 * zyga still needs to make a system that takes stuff from irssi on one VM and pushes it somewhere (say a lava lamp)
<zyga> so how can I help?
<Chipaca> zyga, installing a strict snap with --classic
<Chipaca> zyga, the mounts seem to be wrong
<Kaleo> zyga, let's take it from the core of the issue: trying to have a terminal (say gnome-terminal) snapped and still useful on both classic ubuntu and all snaps ubuntu
<Kaleo> ok :)
<mup> PR snapd#2662 opened: interfaces: network-manager: allow rw access to /etc/netplan <Created by morphis> <https://github.com/snapcore/snapd/pull/2662>
<Kaleo> zyga, strict snap with --classic: / seems to be the core snap, not the / of the classic ubuntu
<zyga> strict snap with classic is meaningless
<zyga> it will never work
<zyga> as strict snaps are not built in a way that allows them to run in classic
<Kaleo> zyga, ok
<Kaleo> zyga, that's clear then
<zyga> Kaleo: FYI, you cannot reuse binary packages easily for classic confinement snaps
<Chipaca> zyga, we should block it then :-)
<zyga> Kaleo: IMHO everything should be rebuilt
<Kaleo> zyga, so back to the core of the matter:  trying to have a terminal (say gnome-terminal) snapped and still useful on both classic ubuntu and all snaps ubuntu
<Kaleo> zyga, Chipaca, or maybe we could publish 2 versions of a snap?
<Kaleo> zyga, Chipaca, one classic and one strict
<Chipaca> this is an all-snaps ubuntu that presumably has X somehow?
<Kaleo> zyga, Chipaca, would the store allow that?
<Kaleo> Chipaca, yeah
<Kaleo> Chipaca, or MIR
<Chipaca> MIR I buy :-)
<Chipaca> Kaleo, with different names, sure
<Kaleo> Chipaca, or whatever, just a display and a keyboard :;)
<Kaleo> Chipaca, ideally with the same name :)
<Kaleo> Chipaca, different name, I guess it's just a matter of having 2 entirely separate "snaps"
<Chipaca> niemeyer, you here?
<Kaleo> Chipaca, it's unpractical from a source code perspective: having 2 snapcraft.yaml
<Kaleo> Chipaca, and not as nice for the user
<zyga> Kaleo: the core version would need to snap the whole display stack (or use interfaces)
<zyga> Kaleo: how do you expect to use it?
<zyga> Kaleo: FYI, on core I think there's no good way to ship a terminal emulator that would be useful for developers
<Chipaca> Kaleo, i've pinged niemeyer so we can think about how we *want* this to be
<Kaleo> zyga, I would rather imagine it would uses interfaces (such as unity8)
<zyga> Kaleo: interfaces give you permissions
<zyga> Kaleo: what about all the runtime libraries, gtk, mir
<Chipaca> Kaleo, as to how things are, today, i'm afraid it's two separate snaps (and i'm not sure you'll get what you expect/want even then)
<Kaleo> zyga, right
<zyga> Kaleo: content interface is not supported for snaps using classic confinement
<zyga> Kaleo: I think the issue at hand is this:
<zyga> Kaleo: you can make a perfect strictly-confined terminal emulator
<Kaleo> zyga, that's indeed another issue I bumped into (I have a big snap atm)
<zyga> Kaleo: but to be useful it must be allowed to run an unconfined shell
<zyga> Kaleo: otherwise this is somewhat pointless
<Kaleo> zyga, yeah
<zyga> Kaleo: AFAIK gnome-terminal has a daemon process and is tied to the session bus
<zyga> Kaleo: all this makes it a lot more complicated
<Kaleo> zyga, you need to be able to do something as far as launching gnome-calculator from said terminal
<niemeyer> o/
<Kaleo> zyga, yeah, let's take a simpler terminal to think about it
<Kaleo> zyga, ubuntu-terminal :)
<zyga> Kaleo: launching one snap from another is forbidden and there's no interface for that yet
<Chipaca> running one snap's apps from another snap's app was not supported last time i checked
<zyga> (and there's a kernel bug that prevents this right now)
<Chipaca> zyga, have we done the legwork to support swapping profiles like that?
<zyga> Chipaca: swapping apparmor profile is easy
<niemeyer> Yeah, it's not
<niemeyer> supported, that is
<zyga> Chipaca: there are other things at play and they are broken (the reassociate-fix branch as all the details)
<zyga> terminal emulators are like desktop environments
<zyga> they run various apps
<Chipaca> zyga, crazy to the head?
<zyga> they feel like having super-powers
<Chipaca> ah, that also
<niemeyer> There are reasonable paths for us to support that, but not there yet
<zyga> yeah
<Kaleo> zyga, Chipaca, so right now, we can do the following: have 2 separate snaps, one classic, one confined; the classic one can be useful on classic and the confined one will be somewhat of limited usefulness
<timp> any ideas why for the ubuntu-ui-toolkit-examples snap, I only have the options to release it to beta and edge? No candidate or stable
<Chipaca> timp, it's devmode?
<Kaleo> - but better than no terminal in an all snaps image
<timp> Chipaca: right.... thanks :)
<zyga> Kaleo: where do you expect to run the confined snap today?
<zyga> Kaleo: on classic desktop or on something like raspberry pi?
<Kaleo> zyga, the confined snap, on a desktop type device for which we might have an all snaps image; which I don't know we have
<zyga> Kaleo: the classic snap would be an interesting thing to try anyway
<Kaleo> zyga, the classic snap already works
<zyga> Kaleo: just to see how hard it would be to take a complex real-world codebase and build it for classic
<zyga> Kaleo: please do that regardless and work with sergio and kyrofa to make them aware of feedback
<Kaleo> zyga, I switched ubuntu-terminal to classic (from devmode) and it works
<zyga> Kaleo: how did you build the classic snap? did you try it on 14.04? (I suspect it doesn't work  there)
<Kaleo> zyga, tried on 16.04
<zyga> Kaleo: building and testing on 16.04 is somewhat tricky as you may build a broken snap that will only work on 16.04
<Kaleo> zyga, I kept all the stage-packages as they were when confined
<Kaleo> zyga, so I would expect that the right libs are there in the snap and linked
<zyga> Kaleo: building classic snaps with stage packages is wrong
<zyga> Kaleo: sadly the only sane way is to build from source
<zyga> (this is why it is hard)
<Kaleo> zyga, even to prevent breakages?
<Kaleo> zyga, I don't understand whyh
<Kaleo> -h
<zyga> Kaleo: do you want to?
<zyga> :-)
<Kaleo> to understand? :)
<Kaleo> sure
<zyga> Kaleo: because that snap transparently relies on your ubuntu system, for a correct snap it should only rely on /snap/core/current and /snap/$SNAP_NAME/current
<Kaleo> zyga, yeah so you might forget snap-packages or might forget to change some paths
<zyga> Kaleo: at almost every detail, from the dynamic linker, dynamic libraries, helper executables and data files
<zyga> Kaleo: if you ever move away from 16.04 it will stop working
<zyga> Kaleo: no, it's not "some paths"
<Kaleo> zyga, but since I made the snap work in devmode
<zyga> Kaleo: prebuilt packages will not work
<zyga> Kaleo: you *must* built it from source and snapcraft must support classic confinement in each plugin you use
<Kaleo> zyga, then I don't understand the point of classic snaps
<zyga> Kaleo: that's the unfortunate reality; I would encourate you to check this on kde or on 14.04 kde for a "good test"
<zyga> Kaleo: the point is as you thought it to be a moment ago
<zyga> Kaleo: but the technical reality is that they cannot be built from binary packages
<Kaleo> zyga, which you said is not reality
<Kaleo> zyga, so no point :)$
<zyga> Kaleo: no, the point is to have no confinement in the way
<Kaleo> zyga, I see
<zyga> Kaleo: you can bring in gcc as a classic snap
<zyga> Kaleo: git, vim
<Kaleo> zyga, ok
<zyga> Kaleo: gedit as well, but you must build from source
<zyga> Kaleo: and all the build bits must do what is required (magic in snapcraft or hand-holding)
<zyga> Kaleo: e.g. I've built a python0 snap as a classic confinement snap
<zyga> Kaleo: look at the build system:
<zyga> https://github.com/snapcore/snapd/pull/2581/files
<mup> PR snapd#2581: debian: remove trusty specific bits <Created by mvo5> <https://github.com/snapcore/snapd/pull/2581>
<zyga> I bet you this will work on any system under the sun
<Kaleo> zyga, so, for right now, I can test the snap on more systems, and publish it only if it works ok; and even then work on a way to make terminals useful when fully confined?
<zyga> Kaleo: but I had to do stuff manually as snapcraft doesn't support everything yet: https://github.com/zyga/python0/blob/master/python0.Makefile#L10
<zyga> Kaleo: not sure which snap you mean, you said you have a few
<Kaleo> zyga, ubuntu-terminal
<zyga> Kaleo: (one problem at a time please, I'm somewhat distracted doing a few things already)
<Kaleo> zyga, ubuntu-terminal-app
<Kaleo> zyga, it's only the one thing we are talking about
<Kaleo> zyga, making snapped terminals useful
<Kaleo> zyga, starting with ubuntu-terminal-app
<zyga> Kaleo: do you want a confined or classic snap
<Kaleo> zyga, since you said classic snaps are basically unreliable, it cannot be classic in the long ruin
<Kaleo> -i
<Kaleo> zyga, so confined
<zyga> Kaleo: no, I didn't say that: I said that you must build classic snaps from source and do it correctly, they are 100% reliable then
<Kaleo> zyga, lol
<zyga> Kaleo: ok, confined
<Kaleo> zyga, I mean unreliable for actual end users
<Kaleo> zyga, (actual end users don't compile their software)
<zyga> Kaleo: again, I didn't say that
<zyga> Kaleo: actual users don't build snaps either
<Kaleo> zyga, so I don't understand
<zyga> Kaleo: as long as the snap is built correctly it will be reliable
<zyga> Kaleo: ok
<mup> PR snapd#2663 opened: run "go test -i" before go test itself <Created by chipaca> <https://github.com/snapcore/snapd/pull/2663>
<zyga> Kaleo: fact of life: building classic snaps from binary packages is incorrect
<Kaleo> zyga, "build classic snaps from source" means what?
<zyga> Kaleo: fact of life: snacpraft doesn't support building everything magically yet
<zyga> Kaleo: well, you build the .c files and the .cpp files
<zyga> Kaleo: you cannot download debs and copy them over
<Kaleo> zyga, of the software? or of the software and all its dependencies?
<zyga> Kaleo: that's what I mean by "build it from source"
<zyga> Kaleo: all of it
<Kaleo> zyga, of all the deps, I see
<niemeyer> zyga: For the record, the jury is still out on this one
<zyga> Kaleo: everything you hope to see in your snap
<niemeyer> zyga: There's no agreement that building from binary packages is incorrect..
<niemeyer> zyga: So "fact of life" seems a bit harsh
<zyga> niemeyer: I'll agree when I see a viable way that works; the only think I can think of are binary editing hacks
<Kaleo> niemeyer, zyga, ok, so I can start classic with binary packages dependencies, test on a few systems, if it works, publish that as a _first_ step?
<zyga> niemeyer: you'd have to alter all the hardcoded paths, all the elf parts to look at the new places
<zyga> Kaleo: sure, don't take what I say as "this is wrong and you cannot publish your snap"
<zyga> Kaleo: I'm just saying that it may not be what you expected
<Kaleo> zyga, ok
<niemeyer> zyga: You can agree or not.. that's not the point.. let's just not purport such ideas as being settled on stone when they are actually just being released and we're still learning to use them ourselves
<Kaleo> niemeyer, ok
<zyga> ok, so "using binary packages for snaps using classic confinement is strongly discouraged" is more accurate
<niemeyer> zyga: Classic snaps were supposed to make things easier.. if we can't use binary packages and it's completely non-intuitive, classic snaps are pointless..
<Kaleo> zyga, so step 2, figuring out a way for confined terminals to be more useful
<zyga> niemeyer: well, that I agree with entirely
<niemeyer> zyga: So we should do some more research and see how/if we can make them reach their actual goal
<zyga> niemeyer: though the pointless bit is perhaps too strong, they have a point but their utility is limited
<Kaleo> zyga, _very_ limited ;)
<niemeyer> zyga: No, really.. the only reason we worked on this at all is to provide a smooth entrance into confinement
<zyga> niemeyer: IMHO with my technical knowledge it is super hard if you expect them to work outside of ubuntu 16.04; I can tell you all the technical details why I believe this to be the case
<Kaleo> zyga, that'd be really great to have a little write up with the details?
<niemeyer> zyga: If it's _harder_ to build a classic snap than a strict one, I'd argue to kill classic snaps
<Kaleo> niemeyer, +1 unless it can be fixed
<zyga> ok, let's discuss that at the standup
<Kaleo> zyga, so step 2, figuring out a way for confined terminals to be more useful
<zyga> I'd rather not kill them yet, the only hard part is the building part and I'd say that for some classes of software this is not hard; for some classes it is but killing it now would feel premature
<zyga> Kaleo: that one is more easy, it feels like an interface
<niemeyer> Kaleo: Yeah, I wouldn't mind looking into a potential interface for that
<zyga> Kaleo: that lets you run shells unconfined
<niemeyer> zyga: Yes, we shouldn't kill them yet, we should make them sane
<zyga> Kaleo: the details can be ironed out but this feels well-defined and doable quickly
<zyga> niemeyer: I think the difficulty is now on the snapcraft side;
<niemeyer> zyga: Asking people to build everything from source when they don't do that for strict snaps isn't reasonable
<zyga> niemeyer: there's little we can do in snapd IMHO
<Kaleo> niemeyer, zyga, right, the main thing I noticed is needed: / inside the terminal snap being the actual / of the classic system
<zyga> niemeyer: well, maybe
<niemeyer> zyga: Yeah, we should talk to Sergio about these details
<zyga> +1
<Kaleo> niemeyer, zyga, can that be an interface?
<zyga> Kaleo: perhaps
<niemeyer> Kaleo: Yes, it can.. not sure if it should yet, but it can
<niemeyer> Kaleo: It's a pretty different mode of operation, so an interface is a bit misleading
<zyga> Kaleo: we don't have support to let a confined snap run a process that is both unconfined and uses the normal filesystem
<Kaleo> niemeyer, right
<zyga> Kaleo: it would be a combination of an interface (I can run bash unconfined) and a helper that returns to the normal filesystem IMHO
<zyga> the interface is very easy
<zyga> the helper is easy but would require some C code
<Kaleo> niemeyer, zyga, another tricky thing I encountered was that inside the shell of the terminal, the environment variables are those of the terminal snap, including things that disturb operations, instead of being the environment variables of say the parent process that started the terminal
<zyga> so technically gnome-terminal would run "snap-escape-ns /bin/bash" (names tentative)
<zyga> Kaleo: can you give us some examples of which variables are problematic?
<Kaleo> zyga, yes
<Kaleo> zyga, all the SNAP_* variables
<niemeyer> Kaleo: It's both, actually
<Kaleo> zyga, and all the environment variables set by the "desktop helper"
<zyga> Kaleo: hmm
<Kaleo> GDK_PIXBUF_MODULEDIR, GIO_MODULE_DIR, etc.
<niemeyer> Kaleo: env vars do get into the process
<Kaleo> niemeyer, zyga, right now I have a piece of code that reset the environment to be the same as the parent process of the terminal
<Kaleo> +s
<zyga> Kaleo: I believe that (at least for some of those) the snap-escape-ns could dothat
<Kaleo> zyga, interesting
<zyga> Kaleo: but it would not know to reset things you just mentioned, like GDK
<zyga> Kaleo: for those I believe the terminal should be patched to run the shell process without those
<zyga> Kaleo: (as this is internal implemnetation detail of the snap)
<zyga> *implementation
<Kaleo> zyga, it is true that it's technically the terminal setting those vars
<Kaleo> zyga, even though the code that does that is from snapcraft-desktop-helpers
<Kaleo> zyga, the main issue with asking the terminal to reset these variables is that we will be asking all terminal packagers/developers to do the same
<zyga> Kaleo: do you see another way to do this?
<Kaleo> zyga, the way I do it today
<zyga> Kaleo: you could run the terminal to run a shell
<zyga> Kaleo: but the shell would be another helper wrapper
<zyga> Kaleo: that would undo all the stuff and run the escape tool
<Kaleo> zyga, right
<Kaleo> zyga, 1) we could make that code common
<Kaleo> zyga, but it's not simple because that specific unsetting of variables depends on what kind of desktop helper you used (for example a qt or a gtk one)
<Kaleo> zyga, or 2) we could have that code be more generic like I do today: copy the environment from the parent process of the terminal
<Kaleo> zyga, or 3) we could make it somehow possible for the terminal to not fork the shells itself
<Kaleo> zyga, but have the parent process do that for the terminal
<zyga> Kaleo: yes but that should live with the helper, I'd rather not mix snapd-the-system and particular-snap boundaries, otherwise things will get out of sync and break
<zyga> Kaleo: (for 1)
<Kaleo> zyga, right, that's true
<zyga> Kaleo: FYI: I'm very glad you are pushing the boundary
<Kaleo> zyga,  1) something in the helper to unset in a non generic way
<Kaleo> zyga, :)
<zyga> Kaleo: as niemeyer said, the point of classic snaps is to make things easy
<Kaleo> zyga, 2) something generic to reset the variables that could live in snapd
<zyga> Kaleo: I'm sorry if you regarded my earlier comments as harsh, that was not my intention (this is just the side effect of working on afew things at the same time)
<Kaleo> zyga, don't worry
<zyga> Kaleo: I think we should meet with sergio and kyrofa_ to discuss how to make building snaps easier
<Kaleo> zyga, classic snaps you mean?
<zyga> Kaleo: snaps using classic confinement
<Kaleo> yep
<zyga> (this naming super confusing because we have the actual "classic" snap and we have "classic" distributions as well)
<Kaleo> zyga, or 3) some kind of facility where the terminal can ask for a binary to be exec
<Kaleo> zyga, indeed
<Kaleo> zyga, I think 3) would be fantastic actually, cleaner somehow, more widely useful
<zyga> Kaleo: can you explain 3 more?
<Kaleo> zyga, so let me get some code to be concret
<Kaleo> e
<zyga> sure
<zyga> Kaleo: can I ask you do move to rocket
<zyga> Kaleo: I get notifications there
<zyga> Kaleo: and diconnets are less of a problem
<pachulo> elopio: ping
<zyga> https://rocket.ubuntu.com/channel/snapcraft
<zyga> Kaleo: ^^
<Kaleo> zyga, sure
<Kaleo> zyga, we can even hangout
<Kaleo> I mean video chat
<zyga> Kaleo: rocket could be better for kyle and sergio to catch up with the discussion
<zyga> (and also lighter on my bandwidth)
<Son_Goku> sergiusens, I hope you didn't mean to say you broke symlink handling of deb sources in the snapcraft 2.25 release notes
<Son_Goku> "deb sources are now being handled with python-debian which does incorrecly handle symlinks."
 * Son_Goku sighs
<Son_Goku> python-debian is a new dep?
<Son_Goku> :(
<Son_Goku> Git is evil, moving files around causes the history of the file to not show up anymore :(
<Son_Goku> kyrofa_, though I do like the refactor you've done to sources
<Son_Goku> it's much easier to figure out and compare sources now
<Son_Goku> :/
<Son_Goku> though I feel like I should add my name to the license header of the Rpm source files...
<Son_Goku> since the git history no longer shows it anymore :(
<kalikiana> That's good practice anyway, although not stricyl required so long as you can track down the author via git
<kalikiana> Unless all commits were rebased by somebody else without your name that is
<Son_Goku> yep
<Son_Goku> that pretty much happened
<Son_Goku> well, sort of
<Son_Goku> because the original file is deleted, it no longer shows up in Git history
<Son_Goku> Canonical did not write any of the Rpm stuff, I did...
<Son_Goku> but it's one of those PRs that some people really don't like
<Son_Goku> kalikiana, it also looks like the blob history is gone too
<Son_Goku> so much for Git's object blob tracking
<kalikiana> Son_Goku: How are you checking it? If that's really what happened it seems very wrong
<Son_Goku> git blame on the Rpm files
<Son_Goku> git blame is supposed use the object blob tracking
<Son_Goku> so that even if you moved stuff around, it should be tracked properly
<Son_Goku> but it doesn't seem to work :(
<flexiondotorg> willcooke Perhaps useful for asterisk? http://snapcraft.io/docs/build-snaps/scriptlets
<kalikiana> Hmm it says Kyle as the author here
<sergiusens> kalikiana, vbecause e moved the stuff around
<zyga> Son_Goku: --follow
<zyga> Son_Goku: it's not default
<zyga> Son_Goku: git log --follow
<zyga> (hi btw)
<Son_Goku> hello
<Son_Goku> in retrospect, I should have added my name onto the original file
<kalikiana> Son_Goku: git blame -C seems to try harder
<Son_Goku> hmm
<Son_Goku> I did put in the test file, but I didn't in the implementation file
<Son_Goku> that's my bad :(
<Son_Goku> sergiusens: would it be okay if I added my name to the Rpm source headers in a PR?
<sergiusens> Son_Goku, if it means that much to you sure; I'd guess it would be easier to start a CONTRIBUTIONS.md if you don't mind that path instead
<Son_Goku> hmm
<Son_Goku> it's not on the top of my list atm, and I think my local git copy of snapcraft is busted :/
<sergiusens> Son_Goku, how can that be? we don't change history in master!
<sergiusens> I hope no one has at least
 * Son_Goku shrugs
<Son_Goku> it's forcing me to do a merge
<Son_Goku> oh, yay
<sergiusens> Son_Goku, local commits?
<Son_Goku> the blob history works with "git blame -C"
<Son_Goku> sergiusens: *shrugs*, I reset the HEAD to some random earlier time and it worked
<Son_Goku> it's interesting to see how git treats the blobs, though
<sergiusens> Son_Goku, yeah -C does the trick and we get to see your kanji, hiragana or katagana (not sure which one it is) :-)
<Son_Goku> Katakana
<Son_Goku> though my original commits didn't have that
<Son_Goku> only my GitHub user has it :)
<Son_Goku> because you squashed the commits, you got that instead :P
<Son_Goku> GitHub is weird like that
<Son_Goku> I don't think that happens when you squash commits locally in git...
<Son_Goku> anyway...
<sergiusens> Son_Goku, I am not so much a fan of github in some aspects, but oh well, everyone wants stuff there and not sign up of anything else
<Son_Goku> sergiusens: I prefer GitLab myself
<Son_Goku> my personal projects are all over on GitLab instead of GitHub
<sergiusens> right, well it needs something to base the squash out of
<Son_Goku> I moved it there two years ago
<zyga> I don't think how git behaves is related to either hosting solution
<Son_Goku> sergiusens: though honestly the most compelling reason for picking GitLab vs something like Gogs or Gitea is the awesome CI capabilities
<Son_Goku> it has first class support for flexible CI built in, and a great API for integrating external CI providers
<Son_Goku> and has an excellent model for representing CI with internal and external things at once
<Son_Goku> see for example: https://gitlab.com/osslugaru/lugaru/blob/master/.gitlab-ci.yml and https://gitlab.com/osslugaru/lugaru/commit/b9a46d8e2b7e7e22c706e7dd3734f31015db4408/pipelines
<Son_Goku> the only weak part of GitLab is git :P
<Son_Goku> (of course, that's just because I prefer Mercurial)
<sergiusens> lol
<sergiusens> everything has ups and downs
<Son_Goku> yeah, of course
<Son_Goku> there are weaknesses to GitLab, of course
<Son_Goku> the most annoying thing is that uploading binaries doesn't work if it's larger than 10MB
<Son_Goku> which also includes source tarballs
<Son_Goku> but it's been easier to engage with GitLab about issues than it has with GitHub about the same things
<mup> PR snapcraft#1055 closed: store: proper error colors for login failures <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1055>
<mup> PR snapd#2586 closed: daemon: make 201 and 202 responses have a Location header as per doc <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2586>
<jdstrand> Kaleo: there is a somewhat ugly way to figure out what confinement you are under: try to read a file that is readable with classic but not in strict
<Kaleo> jdstrand, smart
<Kaleo> jdstrand, thax
<Kaleo> thanks
<zyga> maybe we should add a variable like SNAP_CONFINEMENT=
<mup> PR snapcraft#1056 closed: schema: print allowed length for length failures <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1056>
<jdstrand> ogra_, Chipaca, Kaleo: @{PROC}/cmdline is allowed by default and I don't think we'd remove that one (it isn't problematic). there are a few other /proc accesses I'd like to be limited, but we need kernel side apparmor variables for that (which are planned, but not for the short term)
<jdstrand> timp: your snap needs to simply have meta/gui/*.desktop. snapcraft provides a way to make that happen
<Kaleo> zyga, jdstrand, note that I don't think I'll need that anymore given the discussion afterwards
<jdstrand> sergiusens: did snapcraft change how it does desktop files? I may need to update the review tools message for that
<Kaleo> jdstrand, timp, I read in the snapcraft release email today that there is a new way to provide the desktop file
<jdstrand> Kaleo: so, I may have confused what you meant by 'classic'. if you want to see if you are on a classic system, ogra_'s method of checking /proc/cmdline will work. if you want to know if the snap uses 'confinement: classic', you can use the file access method I mentioned
<Kaleo> jdstrand, yeah, I meant confinement of the snap
<Kaleo> jdstrand, but don't worry, I won't be needing this
<ogra_> yeah, the cmdline is only useful to find out if you are on an all-snap system
<ogra_> iirc that was the context i mentioned it in
<mup> PR snapd#2663 closed: speed up unit test run by doing "go test -i" before go test itself <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2663>
<oSoMoN> Iâm getting a warning from the store automated review when using the new "desktop" key in snapcraft.yaml:
<oSoMoN> unknown fields for app 'webbrowser-app': 'desktop' lint-snap-v2_apps_unknown (webbrowser-app)
<oSoMoN> Iâm guessing because the field gets copied to meta/snap.yaml
<oSoMoN> not sure whether the field should not be copied, or whether the review tools need an update?
<sergiusens> oSoMoN, I fixed that already and will be in 2.26
<sergiusens> oSoMoN, https://github.com/snapcore/snapcraft/pull/1053
<mup> PR snapcraft#1053: meta: ensure snap.yaml is desktop free <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1053>
<oSoMoN> sergiusens, thanks, thatâs something that I had overlooked indeed
<oSoMoN> sergiusens, do you know who can approve my snap upload in the store, the warning appears to be blocking
<jdstrand> sergiusens: is 2.26 an emergency release? should the review tools change? at this point, they can't be changed probably until monday on prod, but maybe I could get them to do it sooner
<jdstrand> sergiusens: wrt desktop and snapcraft. is setup/gui/*.desktop still supported? should I start recommending desktop: usr/share/applications/my-app.desktop?
<jdstrand> sergiusens: ah, I see from the email it is still supported
<jdstrand> I'm not going to fix the tools to mention the new method until 2.26 is released since that will only create store approval friction
<mup> PR snapd#2664 opened: cmd: move seccomp cleanup functionto seccomp-support <Created by zyga> <https://github.com/snapcore/snapd/pull/2664>
<sergiusens> jdstrand, we are going to be moving `setup` stuff into `snap` in the future though and deprecate `setup`, this will consolidate most assets
<sergiusens> jdstrand, I can cut a new snapcraft release tomorrow, I'll check, but my trusty QA guy is on holidays !!
<oSoMoN> jdstrand, can you approve my last 3 webbrowser-app snap uploads? the review tools are warning about the desktop key in snap.yaml, afaik this is harmless but I canât publish
<jdstrand> oSoMoN: yes. note you could also use the previous method until 2.26 is out ^
<oSoMoN> jdstrand, I know, but Iâve been eagerly awaiting for that new feature to avoid having to ship a copy of the generated desktop file in setup/gui, so now that Iâve removed it Iâm reluctant to adding it back
<mup> Bug #1657751 opened: 'snap info' doesn't show price of snap <Snappy:New> <https://launchpad.net/bugs/1657751>
<mup> Bug #1657752 opened: 'snap find' doesn't tell me the price of a snap I have bought <Snappy:New> <https://launchpad.net/bugs/1657752>
<jdstrand> oSoMoN: approved
<oSoMoN> jdstrand, thanks!
<ogra_> mterry, FYI .. https://git.launchpad.net/mir-kiosk/commit/?id=7c8c501b67bb9ca2059838947b8eab918779fd36 ... seems it simply hasn't landed in any deb yet (mir-kiosk is built from source directly) ... thats bug 1656164 ... so unity8-session cant work yet it seems
<mup> Bug #1656164: Black screen with Raspberry Pi 3 VC4 Mesa driver <black-screen> <Mir:Fix Committed by albaguirre> <https://launchpad.net/bugs/1656164>
<mterry> ogra_: ok cool.  So we could also workaround it...  is there an urgency to it working for ya?
<ogra_> mterry, no urgency, just a personal desire to show off unity on the pi ;)
<mterry> :)
<timp> tim@XPS-13-9350:~/src/snaps/ubuntu-ui-toolkit-examples$ ubuntu-ui-toolkit-examples.jokes
<timp> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
<timp> file:///snap/ubuntu-ui-toolkit-examples/x1/usr/lib/x86_64-linux-gnu/qt5/examples/ubuntu-ui-toolkit/examples/jokes/jokes.qml:20 plugin cannot be loaded for module "QtMultimedia": Cannot load library /snap/ubuntu-ui-toolkit-examples/x1/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/qml/QtMultimedia/libdeclarative_multimedia.so: (libpulsecommon-8.0.so: cannot open shared object file: No such file or directory)
<timp> kalikiana: do you think the pulse libs should be in the examples snap, or part of the platform snap?
<timp> hmm, looks like it tries to get it from the platform snap.
<kalikiana> timp: Since pulse is considered the standard for audio, intuitively I think it could be in the platform snap. Virtually anything that plays audio can use it
<kalikiana> Tho you might have a core image w/o pulse, if you do have audio it would be pulse
<timp> ubuntu-app-platform/22/usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so
<timp> it is there.. but maybe somehow cannot be found.
<kalikiana> Ah, so it's probably a dependency of QtMultimedia already
<zyga> the pulseaudio subdirectory is not on search path
<timp> zyga: right. Should I fix that in the app snap or the platform snap?
 * zyga is not sure
<zyga> can you fix it in the platform snap?
<ogra_> if platform ships it ...
<kalikiana> timp: In the launcher I should think
<kalikiana> The platform snap can't set the path
<kalikiana> Until some day it becomes possible to set env vars, that is
<zyga> btw
<zyga> is there a card tracking that
<zyga> we are so able to do that now for ages
<zyga> feels like a disconnected dot somewhere
<zyga> and missing docs and tests
<timp> kalikiana: so you'd say in desktop-launch? I don't see it here https://github.com/ubuntu/snapcraft-desktop-helpers
<timp> ah it is created from other files
<kalikiana> timp: Yep, that's the one I mean
<timp> this looks like a good place to add it https://github.com/ubuntu/snapcraft-desktop-helpers/blob/master/qt/launcher-specific
<timp> kalikiana, zyga: https://github.com/ubuntu/snapcraft-desktop-helpers/issues/37
<zyga> thanks
<timp> hmm, maybe there is a PR already to fix it https://github.com/ubuntu/snapcraft-desktop-helpers/pull/25
<mup> PR ubuntu/snapcraft-desktop-helpers#25: Add pulseaudio to the LD_LIBARY_PATH of the platform snap <Created by tjyrinki> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/25>
<kalikiana> Yeah, looks to be discussing the same issue
<mup> PR snapd#2665 opened: cmd: more build system cleanups and a small fix <Created by zyga> <https://github.com/snapcore/snapd/pull/2665>
<jdstrand> cprov (cc, nessita): I know we talked about this before and I think it is a TODO, but it would be great if the reviewer could click on something to see the snap yaml. with all the kde snaps coming in (which is great), I have to download each one, extract the yaml and find the dbus name so I can update the snap declaration
<cprov> jdstrand: right, we talked about it and I haven't proposed anything.
<jdstrand> cprov: do you need a bug? if so, where to file it?
<cprov> jdstrand: yes, please, https://bugs.launchpad.net/software-center-agent
<mup> PR snapcraft#1057 opened: godeps plugin: support for go-packages <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1057>
<jdstrand> cprov: bug #1657812
<mup> Bug #1657812: please provide snap.yaml to reviewer <Software Center Agent:New> <https://launchpad.net/bugs/1657812>
<cprov> jdstrand: thanks, quick shortcut until it's released `curl -s -H 'X-Ubuntu-Series: 16' https://search.apps.ubuntu.com/api/v1/snaps/details/<SNAP-NAME> | jq '.snap_yaml_raw' | xargs echo -e`
<cprov> jdstrand: only works for public snaps on stable channel.
<jdstrand> cprov, pedronis (cc nessita, ratliff_, tyhicks): fyi, I also just filed bug #1657816 and bug #1657825
<mup> Bug #1657816: please provide way to see LP group memberships for publisher <Software Center Agent:New> <https://launchpad.net/bugs/1657816>
<mup> Bug #1657825: please add mechanism to enforce trusted LP builds for snaps <Software Center Agent:New> <https://launchpad.net/bugs/1657825>
<jdstrand> cprov: and thanks for the curl command! /me adds to his repertoire
<jdstrand> of course, it doesn't work on any of the 3 snaps I am looking at now :P
<cprov> jdstrand: let me try, which ones ?
<jdstrand> cprov: none are released
<jdstrand> so not in stable channel
<cprov> jdstrand: yes, only their publisher can see them ... let me work on the review UI quickly.
<jdstrand> cprov: thanks!
<jdstrand> mhall119: fyi, apachelogger uploaded several kde snaps that used the dbus interface. I granted the snap declaration and they passed review, but he needs to release them
<mhall119> jdstrand: ack, thanks
<mcphail> kyrofa_: hi - is there a bug tracker for the nextcloud snap? I don't think the ".well-known" DAV redirects are being triggered by the .htaccess file
<kyrofa_> mcphail, https://github.com/nextcloud/nextcloud-snap
<mcphail> kyrofa_: thanks
<kyrofa_> mcphail, that bug has been logged, though I'm not quite sure how to fix it
<kyrofa_> mcphail, since Let's Encrypt uses that path as well
<kyrofa_> And they both go through Apache
<mcphail> kyrofa_: does the .htaccess get read at all? It _should_ work ok
<kyrofa_> mcphail, yeah it does, though it's read-only
<mcphail> that should be fine, I think
<mcphail> it seems to match my self-installed version
<kyrofa_> I just need time to sit down and poke at it. But time is in short supply at the moment
<mcphail> kyrofa_: :) - I'll try to compare to my setup over the weekend
<kyrofa_> mcphail, yeah any help is appreciated :)
<kyrofa_> Thank you!
<mcphail> kyrofa_: I'm fairly sure the <Directory "${SNAP_DATA}/certs/certbot/.well-known"> stanza in your httpd.conf must have a role to play here. I'll need to have a poke around to see how let'sencrypt has been implemented in the snap. Hmm...
<kyrofa_> mcphail, indeed
<kyrofa_> mcphail, if I understand the .htaccess well enough, it looks like it won't attempt to redirect an acme challenge
<kyrofa_> That just needs to get sent to a directory
<mcphail> kyrofa_: I'm wondering if the acme challenge should be added (whith the specific .well-known/acme-challenge/{token}) path to the htaccess file instead of redireccting all of .well-known (as apache.conf does now)
<mcphail> The redirect in apache.conf is too greedy at present
<kyrofa_> Indeed, when it was written I didn't even realize nextcloud cared about .well-known, heh
<mcphail> :)
<kyrofa_> When that bug was logged I was like "Wha... ?"
<kyrofa_> Modifying the .htaccess in the snap won't scale, though, and I expect it'll fail the integrity check as well
<mcphail> Might be OK to change the Alias in the conf file
<kyrofa_> Yeah the conf is fair game
<mcphail> OK, I'll play around when I get a chance over the weekend. Cheers for the pointer!
<kyrofa_> Any time!
<Beato> When trying to install a snap it fails with this error - https://paste.ee/r/F7XfL
<Beato> any ideas?
<ogra_> Beato, is this on ubuntu ?
<Beato> Yes
<ogra_> xenial ? (16.04)
<Beato> Yes
<Beato> It is a OpenVZ based VPS though, so maybe it's that
<ogra_> ah
<ogra_> uname -a ?
<Beato> Linux PC 2.6.32-042stab120.16 #1 SMP Tue Dec 13 20:58:28 MSK 2016 x86_64 x86_64 x86_64 GNU/Linux
<ogra_> lol
<ogra_> yeah, that wont ever work with snaps
<ogra_> get a kernel thats not antique ...
<Beato> OpenVZ
<Beato> Not my call
<zyga> Beato: hmm, wow, interesting combination; I'm afraid snapd and systemd require a more recent kernel
<ogra_> it is really interesting that 16.04 runs at all
<popey> (arguably not actually Ubuntu)
<ogra_> (you will probasbly hit very interesting issdues with such a setup)
<ogra_> definitely nothing you should use any production services on
<zyga> Beato: which provider are you using?
<Beato> https://openvz.org/Download/template/precreated kek
<Beato> zyga: http://woothosting.com/
<popey> I recommend http://bitfolk.com/ :)
<popey> (tell them I sent you) :D
<ogra_> "Award-winning network that keeps your business ALIVE" ... since 300 years with the same kernel :P
<ogra_> zombyism galore ...
<Beato> That's an OpenVZ thing though. Pretty much all cheap VPS run OpenVZ 6 and they use a custom 2.6 kernel with a lot of stuff backported (that's why I can run systemd for example)
<popey> yeah
<ogra_> well
<zyga> Beato: interesting
<popey> Bitfolk uses Xen, which means my vps is running 4.4.0-57-generic
 * ogra_ remembers a friend telling him "running doesnt necessarily mean working" ... 
<ogra_> i guess that applies here
<zyga> Beato: snapd depends on some recent kernel features so it will be quite hard to even install and run hello-world there
<ogra_> not only snapd though
<Beato> Yeah, Xen, KVM, VMWare and HyperX allow you to load your own kernel so you can just update manually
<zyga> Beato: I'm afraid there's no better advice than try something that runs genuine xenial kernel
<ogra_> i'd be surprised if that ubuntu actually fully behaves
<popey> sorry about that
<Beato> ogra_: it does though. Like I said, OpenVZ has backported a lot of the features.
<Beato> popey: Cheers, was just curious. I'll just install the app manually then.
<zyga> Beato: if it did you would not have that problem
<zyga> Beato: technically, what failed?
<Beato> Well not, all I guess Â¯\_(ã)_/Â¯
<ogra_> Beato, well, it might seem like it works ... i really wouldnt trust itz
<ogra_> *it
<popey> ogra_ has trust issues
 * ogra_ has been burned to often 
<ogra_> and i know how many userspace bits nowadays rely on kernel features "someone" might have forgotten to port
<ogra_> its really a gambling setup ...
<davmor2> popey: no he doesn't I have trust issues ogra is just slightly damaged
<Beato> Well I do use it as my personal playground, so I don't really care too much.
<ogra_> fro that it is probably fine
<ogra_> just dont run anything serious on it
<Beato> I wasn't going to, but now... Watch me ;)
<ogra_> heh
<ogra_> Beato, well, good luck with it ... but forget about snaps on this
<roadmr> hello folks! what's the story about running snapd inside an lxc container? right now it doesn't work :(
<zyga> roadmr: hey, I don't know fully, I think that on recent enough everything there are still some cases that don't work
<roadmr> zyga: oh but it *should* be working?
<zyga> roadmr: no
<zyga> roadmr: AFAIK
<roadmr> zyga: haha :)
<zyga> jdstrand: ^ correct me if I'm wrong, snapd inside lxd is till a no-go, right?
<kyrofa_> zyga, does this answer your question? https://www.stgraber.org/2016/12/07/running-snaps-in-lxd-containers/
<zyga> kyrofa_: looking
<zyga> roadmr: ^^
<mhall119> zyga: jdstrand: hexchat is in the snap store, but for some reason when you install it the Exec= lines in it's .desktop file are being removed
<mhall119> http://paste.ubuntu.com/23829632/
<mhall119> what might be causing that?
<mhall119> is it because he uses ${SNAP} in the Exec=?
<jdstrand> mhall119: I don't recall. it has to do with the desktop file rewriting code. I bet if you used bin/hexchat %U it would work
<roadmr> thanks zyga
<oh4> running ubuntu 16.04, when trying to run 'sudo snap install canonical-livepatch', it fails with 'error: cannot communicate with server: Post http://localhost/v2/snaps/canonical-livepatch: dial unix /run/snapd.socket: connect: connection refused'
<oh4> snapd is installed but doesn't want to run. Looking at the status of snapd, I see this:
<oh4> https://www.irccloud.com/pastebin/v1KfOv5Y/
<sergiusens> oh4, dmesg|grep DEN
<oh4> https://www.irccloud.com/pastebin/6IXONJOg/
<sergiusens> oh4, oh, snapd doeesn't want to start, `journalctl --no-pager -u snapd`
<oh4> https://www.irccloud.com/pastebin/lkp5OdCw/
<mhall119> jdstrand: actually, it's probably unhappy about it pointing to a binary inside the snap, rather than the one in /snap/bin/
<mhall119> jdstrand: I was right, using just Exec=hexchat fixed it
<mhall119> zyga: sergiusens: ^^ we should give better feedback to the developer on this, rather than silently breaking the .desktop file
<sergiusens> mhall119, yeah, I logged countless bugs or complaints for the snapd team to fix those silent errors
<popey> sergiusens: i keep getting errors from snapcraft telling me files are already in the directory when it's staging
<popey> it's lying because the files aren't in any other part
<popey> when using the dump plugins mostly
<mup> PR snapd#2579 closed: many: auto-connect plugs and slots symmetrically <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2579>
<mup> PR snapcraft#1058 opened: Return an error code if an origin is missing a part <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1058>
#snappy 2017-01-20
<mup> PR snapd#2664 closed: cmd: move seccomp cleanup function to seccomp-support <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2664>
<mup> PR snapd#2661 closed: tests: skip on untrusted keys <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2661>
<wililupy_> I just noticed something interresting. I build an ubuntu-core image with a custom kernel, and when I load the system, it boots up and I can login, but when I look at /lib/modules/`uname -r` there is no directory. Is this something new?
<mup> PR snapcraft#1059 opened: pluginhandler: support more complex stage-packages <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1059>
<wililupy_> nm, I think I figured it out.
<wililupy_> just to verify in the assertion file, model and gadget are core now, or is it still pc?
<mup> Bug #1643292 changed: /snap/bin/hello - fails to execute with apparmor error. <Snappy:Expired> <https://launchpad.net/bugs/1643292>
<mup> PR snapd#2666 opened:  Add ability to set system time zone to timeserver_control interface <Created by justincan> <https://github.com/snapcore/snapd/pull/2666>
<mup> PR snapd#2637 closed: tests: increase retries for service up <Created by fgimenez> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2637>
<mup> PR snapd#2591 closed: wrappers: add DBusActivatable to the allowed values for desktop files <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2591>
<gbisson> wililupy_: Hi! I have the same issue with latest core (893), how did you fix it?
<gbisson> (issue being no /lib/modules nor /lib/firmware)
<mup> PR snapd#2667 opened: tests: ensure systemd override directory is available before using it <Created by mvo5> <https://github.com/snapcore/snapd/pull/2667>
<morphis_> ogra_: just tried to build the core snap from lp:core-snap, but things are failing with https://paste.ubuntu.com/23832507/
<morphis_> ah my fault
<morphis_> should run it as root
<ogra_> i'ÃD guess some package is missing
<ogra_> oh and that, yeah :)
<morphis_> ogra_: btw. is there any testing for the core snap?
<morphis_> or does that have to go into snapd?
<ogra_> theer are regular image tests, yes ... for releasing something into beta/candidate as well as for releasing into stable
<ogra_> there are zero tests for edge since that is developer playground and allowed to break
<morphis_> ogra_: so where would I add a test for the configure hook I am adding now into lp:core-snap
<ogra_> (i'm personally running edge on all boards here though, they auto-update and i usually nothice if they dont boot ... so there is some minimal recofnition of serious breakage)
<ogra_> morphis_, you apply a patch to fgimenez i guess ;)
<morphis_> hah
<ogra_> (the automated spread tests only run for amd64 currently though)
<morphis_> hm
<morphis_> fgimenez: ping
<fgimenez> hey morphis_ :) about the above question you can propose the tests to snapd itself and restrict by system
<morphis_> sounds good
<morphis_> fgimenez: but that would require me to get a new core snap into edge first, right?
<morphis_> ogra_, fgimenez: https://code.launchpad.net/~morphis/core-snap/add-configure-hook-sshd-service/+merge/315203
<fgimenez> morphis_, well, you could use the external backend and run against a prebuilt image, that's how we are testing the board images now
<morphis_> ah
<morphis_> good idea
<ogra_> morphis_, thats definitely not enough ... you need to add tests if there is a local login
<fgimenez> morphis_, here are the details https://github.com/snapcore/snapd/blob/master/tests/external-backend.md
<ogra_> else any admin can accidentially completely lock himself out
<morphis_> ogra_: sure, that is why its set as wip
<ogra_> morphis_, i'd also use start/stop instead of restart ... but thats just a matter of taste
<morphis_> two commands instead of a single?
<ogra_> no
<ogra_> start for enabled ... stop for disabled
<mup> PR snapd#2668 opened: interfaces: abbreviate ConnRef construction <Created by zyga> <https://github.com/snapcore/snapd/pull/2668>
<ogra_> but as a i said, matter of taste restart will indeed work fine
<ogra_> (it is just that you trigger two actions with it instead of the one you actually want)
<morphis_> ogra_: you're ok with the name?
<morphis_> was wondering if I should use service.ssh or service.sshd
<morphis_> both are the same for systemd
<ogra_> yeah, i'm fine with either, make your pick
<mup> PR snapd#2665 closed: cmd: more build system cleanups and a small fix <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2665>
<ogra_> probably sshd for consistency ... after all you disable the daemon not the client
<morphis_> yeah, but that is why it has the service. prefix
<morphis_> let me leave service.ssh
<morphis_> I guess niemeyer and mvo will have a opinion too :-)
<morphis_> ogra_: what would be the best way to check for a local login?
<ogra_> hmm
<morphis_> passwd -S maybe
<ogra_> the most minimal would be to check for non-zero size of /var/lib/extrausers/passwd
<ogra_> passwd -S will only show the current user
<ogra_> which in case of a config option will be root i guess
<morphis_> something like
<morphis_> test `passwd -S simon | awk '{print $2}'` = P
<ogra_> and how do you know "simon" ?
<morphis_> and then looping through the extrausers db and checking each user
<morphis_> if one found with passwd then we're ok
<morphis_> + check if he is sudo or not
<ogra_> ogra@localhost:~$ test -e /etc/sudoers.d/create-user-* && echo foo
<ogra_> foo
<ogra_> that is probably sufficient for finding out there is an admin user
<ogra_> (console-conf creates that file)
<morphis_> why that?
<morphis_> ah
<ogra_> the last bit of the filename is the login
<morphis_> but that still doesn't give us if that user has a password set
<ogra_> right, then check for that
<morphis_> ah
<ogra_> should be a cheap way to get the login
<morphis_> however in our case that doesn't work :-)
<morphis_> as we have a system-user assertion creating a user admin
<morphis_> and there could be other user assertions creating different users
<ogra_> and that doesnt enable sudo ?
<ogra_> all you want to make sure is that there is a sudo user with a password
<ogra_> and /etc/sudoers.d/ is the only way to create one, /etc/sudoers is readonly
<morphis_> the other question is, this is policy, do we really want to encode this in the option? in our case a management snap will take care about the whole system and will also have access to the extrausers database
<ogra_> even your system-user assertion needs to create a file there if there is a sudo capable user
<ogra_> hmm
<morphis_> so it may want to enforce that there is not a user at all
<morphis_> but just the management snap provide a nice UI to manage everything
<ogra_> tricky
<morphis_> it is
<ogra_> and also perhaps something that requires wider discussion via the ML
<morphis_> I tend to say this is just meant to turn sshd off and the caller needs to know about the consequences
<ogra_> i personally wouldnt allow turning off sshd through a manually toggleable option if there is no way to get in anymore ...
<ogra_> probably there is another way to inject that during image creation
<ogra_> i belive there will be more images like this where you actually dont want a user to exist ... but at the same time it should never be possible to lock yourself out if one exists
<ogra_> probably the answer is to not make the option runtime switchable at all
<ogra_> so it can only be triggered by assertion or some such
<morphis_> maybe
<morphis_> ogra_: let me get a first working version and then we can discuss this further
<ogra_> +1
<mup> PR snapd#2669 opened: asserts: don't use 'context' for the path of attributes, want to reuse the concept for something else <Created by pedronis> <https://github.com/snapcore/snapd/pull/2669>
<mup> PR snapd#2670 opened: tests: use higher version number during tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2670>
<mup> PR snapd#2667 closed: tests: ensure systemd override directory is available before using it <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2667>
<mup> PR snapd#2668 closed: interfaces: abbreviate ConnRef construction <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2668>
<morphis_> fgimenez: ok, I've build my own core snap now and use it to generate an image with ubuntu-image, do I have to set anything specific as snapd doesn't accept it or do I have to rebuild snapd in a special way?
<morphis_> ogra_: how are you testing locally build core snaps?
<ogra_> i boot the image ... install some snaps that use different interfaces (typically htop)
<ogra_> and usually i leave the image running and watch it update itself daily (since i most of the time look at edge)
<fgimenez> morphis_, i don't think so, you can execute your tests following https://github.com/snapcore/snapd/blob/master/tests/external-backend.md, you could filter by your own test, something like 'spread -v external:ubuntu-core-16-64:tests/main/my-test'
<fgimenez> morphis_, the external backend doesn't make any assumption about what snapd is running, it just tries to connect and execute the given tests
<morphis_> ogra_, fgimenez: https://paste.ubuntu.com/23833054/ is what I am running into after building an image with $ ubuntu-image --extra-snaps core_16.04.1_amd64.snap -o pc.img pc.model
<morphis_> so wondering if there is any trick or if snapd should accept my core snap as is
<ogra_> morphis_, and your model assertion is properly signed with a valid key ?
<morphis_> ogra_: sure, with my developer key
<mup> PR snapd#2670 closed: tests: use higher version number during tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2670>
<ogra_> do you see any other errors during boot ? like the firstboot setup job failing or some such ?
<ogra_> looks really like the initial device setup didnt run
<ogra_> also, does snap list work at all ?
<morphis_> it does but lists nothing
<morphis_> ogra_: none of the snaps from the seed are imported
<mup> PR snapd#2669 closed: asserts: don't use 'context' for the path of attributes, want to reuse the concept for something else <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2669>
<morphis_> trying to get a few more details
<ogra_> yeah, that smells like the device initialization hasnt run ...
<morphis_> ogra_: but yeah, I passed console-con
<ogra_> yeah, thats unrelated
<ogra_> do you have an existing /var/lib/snapd/seed/seed.yaml and the correct content ?
<morphis_> ah seems to be my fault
<morphis_> Jan 20 12:13:27 localhost /usr/lib/snapd/snapd[1082]: task.go:303: DEBUG: 2017-01-20T12:13:27Z ERROR rm: cannot remove '/etc/ssh/sshd_not_to_be_run': No such file or directory
<morphis_> that fails the the installation of the core snap
<ogra_> just add a "|| true" to the end of the line as a quick hack
<popey> hm, it's not possible to build classic snaps in lxd due to it needing core installed?
<popey> related to bug 1650946 which changed the error message
<mup> Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <launchpad-buildd:Triaged> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1650946>
<popey> oh, sergiusens dropped
<ogra_> your question probably scared him :)
<ogra_> there ... he's back :)
<mup> PR snapd#2671 opened: add --classic support to try and revert, and make missing these things a little harder <Created by chipaca> <https://github.com/snapcore/snapd/pull/2671>
<oh4> still having issues getting snapd started and not sure what the culprit is
<oh4> https://www.irccloud.com/pastebin/JTrFROJh/
<mup> PR snapd#2672 opened: cmd: ensure that all .c files have a -test.c file <Created by zyga> <https://github.com/snapcore/snapd/pull/2672>
<oh4> mup: is that related to my issue?
<mup> oh4: I really wish I understood what you're trying to do.
<popey> sergiusens: is there a plan to allow building classic snaps inside cleanbuld lxd?
<popey> sergiusens: the error message is now nicer, but... :)
<oh4> mup: I am trying to install 'sudo snap install canonical-livepatch' but it requires snapd to be up and running. If I run that command, I get: 'error: cannot communicate with server: Post http://localhost/v2/snaps/canonical-livepatch: dial unix /run/snapd.socket: connect: connection refused'
<mup> oh4: Unknown commands are unknown.
<oh4> mup: so then I checked snapd and it isn't running and when I try to start it, I get the error above
<mup> oh4: Can't grasp that.
<seb128> oh4, what's the status of snapd.service ?
<popey> oh4: mup is a bot, ignore it.
<sergiusens> popey, I discussed on a solution, just need to work on it, it is top two on my list
<oh4> popey: oh...lol
<oh4> https://www.irccloud.com/pastebin/ecaBvAIR/
<oh4> popey: ^
<popey> sergiusens: awesome, thanks.
<oh4> seb128: I meant you...sorry ^
<popey> oh4: is that on ubuntu 16.04?
<oh4> yep
<seb128> oh4, not snapd.refresh.service, snapd.service
<seb128> the refresh is another job
<oh4> oops..I meant this, seb128
<oh4> https://www.irccloud.com/pastebin/6K03T5Rn/
<popey> jdstrand: filed this, but not sure if it's snappy or apparmor.. bug 1658086
<mup> Bug #1658086: profile has merged rule with conflicting x modifiers <Snappy:New> <https://launchpad.net/bugs/1658086>
<ogra_> oh4, this is a plain local ubuntu desktop or server install ?
<oh4> ogra_: desktop
<ogra_> oh4, i.e. not some remote cloud system or container or some such
<ogra_> k
<oh4> yep, my workstation here at home
<ogra_> (that should rule out any kernel issues then)
<mup> Bug #1658086 opened: profile has merged rule with conflicting x modifiers <Snappy:New> <https://launchpad.net/bugs/1658086>
<ogra_> oh4, also using the default kernel from the install ?
<oh4> correct, ogra_
<ogra_> hmm, weird
<oh4> no mods...fresh install yesterday
<oh4> even ran full upgrade and nothing
<ogra_> yeah, snapd should just run then ...
<ogra_> do you see anything intersting grepping fro snapd in syslog perhaps ?
<ogra_> *for
<oh4> following 'egrep -nri "err|warn|fail" /var/log/syslog", I see the following
<oh4> https://www.irccloud.com/pastebin/BfvADh36/
<ogra_> just grep for snap or snapd
<mup> PR snapd#2673 opened: cmd: add fault injection support code <Created by zyga> <https://github.com/snapcore/snapd/pull/2673>
<oh4> but those errors are from when I attempted to use 'snap install canonical-livepatch', I believe
<oh4> here some more just for snap
<oh4> https://www.irccloud.com/pastebin/4avvevRr/
<oh4> it looks like it started at some point?...hmm
<oh4> or maybe it try to start when I run 'snap install <package>'
<oh4> not sure
<ogra_> oh4, well, looks like snapd starts but then fails when the livepatch thing comes into play
<ogra_> does "snap list" work ?
<oh4> nope, snap list gives the same error
<oh4> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<ogra_> what does: dpkg -l snapd return as version ?
<oh4> ii  snapd                                                  2.20.1ubuntu1                    amd64                            Tool to interact with Ubuntu Core Snappy.
<ogra_> thats running here as well on all my machines ... strange
<popey> might need a livepatch kernel person?
<ogra_> zyga, what were the magic commands to clear up all snap related bits on a classic install ?
<ogra_> popey, yeah, but first we cant even have the core snap installed
<ogra_> so first i'D like to get the livepatch snap completely ripped out and snapd into a virgin state
<ogra_> the livepatch snap seems to be sitting in queue now so starting snapd will immediately try to run it and fall flat on its face
<zyga> ogra_: I don't know if they work now
<zyga> ogra_: just prune snapd
<zyga> ogra_: er. purge
<ogra_> purge you mean
<zyga> ogra_: that should do the same
<ogra_> oh4, sudo apt purge snapd
<ogra_> then install it again
<zyga> yep
<ogra_> and then try something like: sudo snap install htop
<ogra_> or snap install hello or so
<ogra_> that should install the core snap alongside
<ogra_> after that see if snap list then works
<mup> Bug #1658086 changed: profile has merged rule with conflicting x modifiers <eco-team> <Snappy:Confirmed> <https://launchpad.net/bugs/1658086>
<sergiusens> diddledan, hey, nice corebird update! Would you mind writing up on the steps you went through to get xdg-open working so others can follow your lead?
<mcphail> I'm hacking https://github.com/nextcloud/nextcloud-snap . If I change the apache.conf file (which is from the apache-customizations part) how do I rebuild the snap with just those changes?
<diddledan> thanks. I don't think I did anything except installing snapd-xdg-open via apt
<diddledan> where would be appropriate to post that? I can pop it on my own site but that won't be very discoverable..
<sergiusens> diddledan, is your snapcraft.yaml anywhere I can peek at?
<diddledan> yes, it's on launchpad git: https://git.launchpad.net/~diddledan/+git/corebird?h=master
<diddledan> the direct link to the yaml: https://git.launchpad.net/~diddledan/+git/corebird/tree/snapcraft.yaml
<sergiusens> diddledan, I wonder if it is now part of desktop-gtk3
<diddledan> not sure. all I could discern was that the apt package snapd-xdg-open was required and once installed everything "just works"
<diddledan> I think it would be nice for snapd deb to depend or recommend that package - it's not discoverable that you need to install it for xdg-open to work
<sergiusens> diddledan, well I do have it installed but only yours actually gets it done
<sergiusens> seb128, Trevinho would you have an idea about this? ^
<diddledan> odd
<diddledan> maybe other snaps aren't actually using the xdg-open mechanism but trying to call things directly
<diddledan> I can try digging into xorebird source to see whether they shell-out or call the dbus directly
<sergiusens> diddledan, that would explain it for some, but not all (I don't think the recent kde frameworks based apps are different)
<sergiusens> or maybe it is a case like that
<oSoMoN> jdstrand, when you have a minute, may I ask you to review https://myapps.developer.ubuntu.com/dev/click-apps/6219/rev/2/ ? the same warning as my webbrowser-app upload the other day is blocking publication
<mcphail> kyrofa_: is there any reason we can't have "AllowOverride All" for the nextcloud install directory, to use the .htaccess file in there? I'm not sure the "Include" directive in your apache.conf is doing what we need it to do...
<jdstrand> mhall119: I'll add a todo for the review tools for Exec= so at least if it hits the store, people will get the feedback
<seb128> sergiusens, diddledan, what is the question?
<sergiusens> seb128, xdg-open (again :-) )
<diddledan> ok, the way that corebird calls URLs is via GLib: GLib.AppInfo.launch_default_for_uri (uri, null);
<sergiusens> seb128, corebird-diddledan works just fine, wondering why others don't and if there is some sort of guide for this
<seb128> sergiusens, gio should work fine
<seb128> if the snapd-xdg-open is installed on the system
<seb128> which mvo is looking at getting installed by default I think (that was a while ago and I didn't see any update)
<jdstrand> popey: it is snappy. I responded in the bug
<sergiusens> seb128, great, so if an app in snap calls xdg-open it needs to be provided in the snap?
<sergiusens> Or is this a zyga question?
<oSoMoN> jdstrand, thanks!
<ogra_> sergiusens, it should be used from the core snap (where we install the script yb default)
<ogra_> though weather snap-confine allows execution is indeed actually a zyga question
<jdstrand> oSoMoN: yw
<jdstrand> sergiusens: iirc, no. the xdg-open is in /usr/local/bin in the core snap and snaps have the permissions to call that
<jdstrand> I may be misremembering-- the way we do xdg-open is a little twisty
<jdstrand> but I don't think the snap has to ship it
<ogra_> in fact it breaks if you ship it
<ogra_> because then the distro script goes to /usr/bin and overrides the core script in /usr/local/bin
<ogra_> (or rather to $SNAP/usr/bin)
<mup> PR snapd#2672 closed: cmd: ensure that all .c files have a -test.c file <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2672>
<mup> PR snapd#2640 closed: interfaces: allow querying added security backends <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2640>
<mhall119> thanks jdstrand
<mvo> seb128: sorry, I was not pushing snapd-xdg-open recently :/
<seb128> mvo, no worry, I just mentioned it because I think you said that it was on some of your backlog
<mup> PR snapd#2674 opened: snap: show price in `snap info` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2674>
<mup> Bug #1657752 changed: 'snap find' doesn't tell me the price of a snap I have bought <Snappy:Won't Fix> <https://launchpad.net/bugs/1657752>
<mvo> seb128: it is still there, keeps getting pushed aside by more important tasks
<seb128> mvo, no worry, thanks for the status update
<mup> PR snapd#2630 closed: many: detect potentially insecure use of snap-confine <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2630>
<mup> PR snapcraft#1060 opened: options: if host is 32bit use the relative backward compatibility architecture <Created by 3v1n0> <https://github.com/snapcore/snapcraft/pull/1060>
<popey> jdstrand: thanks!
<zyga> jdstrand: hey, this has been reviwed by two other people and waits for a month for a review; I think we should just merge it and carry on; I have a branch that drops privs around argument parsing and I plan on landing it before actually using this new (parser) module.
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2416
<mup> PR snapd#2416: cmd/snap-confine: add snap-confine command line parser module <Created by zyga> <https://github.com/snapcore/snapd/pull/2416>
<zyga> *reviewed
<zyga> jdstrand: unless you critically want to review it I plan on merging it when it turns green
<jdstrand> zyga: as agreed to earlier, this is behind a couple of other things and iirc, tyhicks and I felt it needed a review. please talk to ratliff and tyhicks if you want that prioritized ahead of the current work
<jdstrand> also, it is a bit unfair to characterize it in the way you did. yes, it has been open for a month, but it also has never been on the critical path for anything
<morphis_> ogra_: Jan 20 15:29:14 localhost.localdomain kernel: audit: type=1400 audit(1484926154.100:17): apparmor="DENIED" operation="exec" profile="snap.core.hook.configure" name="/bin/systemctl" pid=1378 comm="configure" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<morphis_> that is interesting but I guess that is just normal confinement and core isn't taken differently
<jdstrand> not to mention, part of that month was a bunch of holidays :)
<ogra_> morphis_, see rthe other channel :)
<morphis_> ogra_: the above is a different problem
<morphis_> ogra_: the access to /run/snapd.socket is a thing I've filed a bug for some weeks ago
<ogra_> oh
<ogra_> yeah, core has strict confinement by default
<kyrofa_> mcphail, doing that wastes resources because it crawls looking for that file on requests. The idea was to disable it in order to obtain better performance on low-end hardware (e.g. the rpi2)
<kyrofa> mcphail, my research led me to believe the Include was equivalent but had the downsides I mentioned in the comment
<morphis_> ogra_: guess we need an interface or so
<ogra_> could be, not sure, i think pstolowski might know more how it is supposed to work in core
<ogra_> i'd actually not expect an interface to be needed here
<tyhicks> zyga: hey - I'll set aside this seccomp work and review the arg parsing PR
<mup> PR snapd#2675 opened: asserts: implement SuggestFormat to help avoid specifying the wrong format iteration for an assertion <Created by pedronis> <https://github.com/snapcore/snapd/pull/2675>
<tyhicks> that code is in too critical of a section to not receive a close security review
<mcphail> kyrofa: I'm still experimenting, but it works if I AllowOverrides but not with the Include. I'll keep hacking. Hadn't thought of htaccess causing a performance hit
<kyrofa> mcphail, yeah, check this out: https://httpd.apache.org/docs/2.4/misc/perf-tuning.html
<mup> PR snapcraft#1061 opened: Fix Exec key in desktop files for apps named like their parent package (LP: #1658123) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/1061>
<zyga> tyhicks: thanks!
<zyga> jdstrand: ack
<mcphail> Looks like we really do need to get this in the conf file if possible, although I don't think performance gains are worth the loss in functionality if we can't get it to work
<zyga> jdstrand: (I didn't think of the holidsys, sorry about that)
<kyrofa> mcphail, agreed
<kyrofa> mcphail, so it works with no other changes if you just allowoverride all ?
<pstolowski> ogra_, i'm not sure what was the question... was it far it the backlog? looks like it's not about snapd.socket again;) ?
<ogra_> pstolowski, yeah, that tricked me too on first sight ;) morphis_ is actually calling systemctl there from his core config hook
<mcphail> kyrofa: i've made a few changes, including changing that alias for acme-challenge. I need to unpick them now and see what breaks
<ogra_> pstolowski, and gets a denial ... should that work ?
<pstolowski> ogra_, oh, sorry, i'm familiar with that.. zyga may know?
<pstolowski> *i'm not*
<mup> PR snapd#2676 opened: cmd: collect string utilities in one module, add missing tests <Created by zyga> <https://github.com/snapcore/snapd/pull/2676>
<kyrofa> ogra_, how does confinement work on the core snap?
<kyrofa> ogra_, obviously on a normal snap a denial would be expected
<ogra_> kyrofa, heh, no idea, thats a snapd/snap-confine question
<kyrofa> ogra_, does the core snap have any apps?
<ogra_> nope
<kyrofa> ogra_, that'd be a good way to experiment-- make an app and see if it's confined
<ogra_> but it is supposed to have a config hook option
<kyrofa> I suspect it is
<kyrofa> But then... it's trying to execute stuff within it so
<kyrofa> Odd
<jdstrand> davidcalle: hi! you probably have in your email something about a new version of the security whitepaper
<jdstrand> davidcalle: but if not, I just updated it for a bunch of series 16 items, urls, etc
<davidcalle> jdstrand: how do you know I was going to ask you about an eta for the next update? :)
<jdstrand> davidcalle: hehe
<jdstrand> davidcalle: I'd been getting an inkling recently that people might have been reading that doc which had a few out of date items. I guess you had the same inkling :)
<davidcalle> jdstrand: indeed, also, we have been discussing the doc recently in the Marketing team, so, good timing :) I'll publish it on monday, I'm about to eod
<zyga> ogra_, pstolowski: how can I help?
<pstolowski> zyga, <ogra_> pstolowski, yeah, that tricked me too on first sight ;) morphis_ is actually calling systemctl there from his core config hook
<pstolowski> zyga, <ogra_> pstolowski, and gets a denial ... should that work ?
<zyga> pstolowski: no
<ogra_> morphis_, ^^^
<jdstrand> davidcalle: thanks. I'm not sure where the doc fits in wrt recent documentation discussions, but it is in the form it is in due to customer requirements (ie, PDF). if the format needs to change (eg, to markdown), I'd be happy to review the conversion but you might want to talk to awe_ about the customer requirement
<zyga> morphis_: systemctl talks to systemd over dbus and your hook is confined
<zyga> jdstrand: I'd love to put the whitepaper on the wiki
<zyga> jdstrand: if you want I can do that
<jdstrand> zyga: let davidcalle, marketing and awe discuss that
<jdstrand> it is in the format it is in based on custor requirements. maybe those requirements changed or can change
<jdstrand> customer*
<awe_> jdstrand, I don't think it's a requirement that the document be in PDF form, especially when it's something public like your whitepaper.
<jdstrand> awe_: you'd be surprised. they very specifically wanted a PDF whitepaper
<awe_> jdstrand, I can think of some other PDFs that might be useful to land on the wiki (TPM2)
<awe_> jdstrand, OK I'll check with Ak on where that came from
<jdstrand> awe_ (cc davidcalle): of course, there is nothing saying the source form couldn't be markdown and that converted to PDF. at the time of the requirement, people said a google doc was better
<awe_> jdstrand, the original document was a gdoc, so I think we need to ask Google for an "export to markdown" function
<awe_> ;)-
<awe_> jdstrand, +1
<jdstrand> anyway, I don't think it is a big deal, just want to make sure all the stakeholders agree
<jdstrand> awe_: hehe :)
<awe_> sure, as mentioned I'll check with ak
<jdstrand> thanks
<zyga> jdstrand: there's a markdown -> latex tool that could give us acceptable output
<mup> PR snapcraft#1008 closed: Add a simple straightforward conan.io plugin <Created by Fohlen> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1008>
<larryprice> hello! i'm trying to wrap my head around the "alias" property in snapcraft - i built/installed the my-alias snap in snapcraft/integration_tests/snaps/alias, but i don't see any aliases in /snap/bin?
<larryprice> latest zesty, so snapd 2.21 and snapcraft 2.25
<zyga> larryprice: I think it's too late this week; Ask pedronis` next week
<larryprice> zyga, ok thanks
<Chipaca> larryprice, I think your snapd needs to be really new to get aliases automatically
<Chipaca> larryprice, and it's possible the 'alias' snap doesn't have auto-aliases
<Chipaca> dunno
<larryprice> Chipaca, hmm what do you mean auto-aliases?
<mup> PR snapcraft#1017 closed: make: add support for cwd path <Created by 3v1n0> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1017>
<mup> PR snapcraft#1018 closed: autotools: extend Make plugin instead of repeating code <Created by 3v1n0> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1018>
<Chipaca> i'm not sure right now if you need anything extra for them to happen on their own
<kyrofa> Chipaca, i.e. that's something controlled by declarations?
<Chipaca> i think so, but i'm not 100%
<kyrofa> jdstrand might be able to verify that
<larryprice> maybe they don't happen automatically in devmode? seems the lxd aliases are working as expected
<morphis_> zyga: yeah feared that, somehow thought core is taken differently than other snaps :-)
<Chipaca> larryprice, try installing test-snapd-auto-aliases
<jdstrand> a store reviewer can setup auto-aliases today. for example, the lxd snap uses it
<jdstrand> Chipaca, kyrofa: ^
<kyrofa> jdstrand, so it is an assertion-related thing?
<Chipaca> jdstrand, thanks for the confirmation
<larryprice> Chipaca, ah ok that did install what looks like aliased snaps
<jdstrand> kyrofa: yes
<kyrofa> Good deal, thank you :)
<Chipaca> larryprice, so in your snap.yaml you ask for them, but you get them from the store with human intervention
<jdstrand> the snap declares its aliases. the user makes them go live on the system. a snap declaration can make that automatic
<Chipaca> larryprice, jdstrand said it so much better :-)
<larryprice> Chipaca, jdstrand, ok this is all adding up now
<jdstrand> larryprice: they store isn't going to block or anything if you declare them. the user installs your snap and can decide to apply the aliases. in some cases, it might make sense to have a snap declaration in the store to tell snapd to do it automatically
<larryprice> jdstrand, who should i contact when requesting an auto-alias for one of my subcommands (canonical-owned snap)?
<jdstrand> larryprice: there isn't a form to request them, so you would need to ping a reviewer: https://launchpad.net/~myapps-reviewers/+members#active
<larryprice> jdstrand, ok good to know
<larryprice> Chipaca, jdstrand, thanks!
<Chipaca> larryprice, meanwhile, "snap alias" is your friend
<Chipaca> larryprice, and "snap aliases" if your snap/d is new enugh
<mup> PR snapd#2677 opened: snap: improve the error message for `snap try` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2677>
<gbisson> wililupy_: around?
<wililupy_> yes.
<wililupy_> gbisson: what can I do for you?
<telelaci> Hi wililupy can I have a question
<Blu2> thank you for https://tutorials.ubuntu.com/ !!
<wililupy> telelaci: Sure
<telelaci> yesterday you said your /lib/modules dir has disappeared
<telelaci> i have the same problem
<telelaci> /li/modules and /lib/firware both totally empty
<kyrofa> Blu2, has it proved helpful?
<telelaci> but if I extract the kernel snap , the files are inside
<gbisson> wililupy: yes, telelaci is taking over, we have the same question ;)
<wililupy> telelaci: yes. I had this happen in the past when I built images and didn't use specific names for my kernel snap.
<telelaci> and it this was good last week
<telelaci> what specific names ? what do you mean ?
<Blu2> kyrofa, not yet, but I will take a closer look at it tonight :)
<kyrofa> Blu2, if you do, you should send a note to the list-- its authors are on a different timezone and I'm sure they'd love to see that it was helpful
<zyga> tyhicks: thank you for the review
<wililupy> I used to say my kernel was the actual kernel_4.8.0-RC1_amd64.snap name in my assertion instead of the name: value in my snapcraft.yaml for my kernel, which was kernel. Once I put kernel: kernel and then when I built the image used the --extra-snaps=kernel_4.8.0-RC5_amd64.snap everything worked.
<zyga> tyhicks: I'll read it and try to get back to you quickly
<wililupy> However, I ran into this problem yesterday becuase my model: pc needed to be changed to model: core. I'm testing it right now to verify that this fixes it. If it does, I'll let everyone here know.
<mup> PR snapcraft#1062 opened: tour: add g++ as dependency to 01-reusable-part <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1062>
<telelaci> thank you so much I had no idea at all, because I couldn't even roll back the project on git, last week worked, today doesn't work. the same code
<telelaci> please share everything what you experience with this thing, because its very mysterious error
<wililupy> hmm. Interresting. I now get the lists of installed snaps, where I wasn't getting that before, but I still don't have anything mounted in /lib/modules from my kernel snap. They are all there in my /snap/kernel/x1 directory. Anyone else here in the channel have any insight?
<mup> PR snapcraft#1063 opened: file_utils: copy symlinks to directories as symlinks <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1063>
<telelaci> wililupy: same here. but not only /lib/modules , but /lib/firmwares as well.
<wililupy> telelaci I see that as well.
<telelaci> do you have the /lib/firmwares in place ?
<telelaci> wililupy: none of them mounted in your system as well, or just the modules missing ?
<palasso> hey is this website new? https://tutorials.ubuntu.com/
<wililupy> telelaci: none mounted. and I'm not seeing any errors specific to this.
<telelaci> same
<telelaci> but of course the system doesn't work properly without firmware and modules
<mterry> I notice that snapd trunk can't be built as a deb without first getting all the deps, which requires network access.  Looks like for archive builds, you folks release a tarball with all the deps built in to get around this.  Is that a desired setup, or would a pull that changes the debian packaging to Build-Dep on the various golang packages in the ubuntu
<mterry> archive to get the deps instead be welcome? (with the goal of being able to PPA-build a git branch directly)
<mup> PR snapd#2678 opened: interfaces: interface to allow autoilot introspection <Created by sbaldassin> <https://github.com/snapcore/snapd/pull/2678>
<pedronis`> mterry: the switch to vendoring was a conscious decision, it was setup the other way around before
<mterry> pedronis: understood, thanks.  Makes playing with a patched snapd harder, but I assume there was good cause behind the change somewhere
<mterry> jdstrand, slangasek, ratliff: Is bug 1658181 accurate?  I just noticed this, and jdstrand didn't know about it, just wanted to make sure if this was a discussion I missed
<mup> Bug #1658181: snapd bundles golang dependencies despite being in main <snapd (Ubuntu):New> <https://launchpad.net/bugs/1658181>
<jdstrand> it looks accurate to me. JamieBennett should be made aware as well, but he seems offline atm
<mterry> pedronis ^ can you offer any history for that decision in the bug, if you know it?
<slangasek> mterry: yes, I raised that with the snappy and security teams when that change went through
<mterry> slangasek: ah good cool.  Was there a satisfying conclusion and I can close that bug or is the bug still useful?
<slangasek> mterry: I didn't really see much follow-up tbh; I passed it over to the security team, they were aware of it
<jdstrand> slangasek: I don't recall seeing this (maybe I am misremembering). ratliff and tyhicks, did you? ^
<tyhicks> mterry, slangasek, jdstrand: I don't recall a discussion around snapd vendorizing packages
<tyhicks> I have had some discussions around other projects vendorizing things in stable releases when they have new upstream releases that depend on packages that aren't in the archive
<tyhicks> I don't recall that for snapd though
<slangasek> tyhicks: I sent mail on it Oct 12 to you + ratliff
<slangasek> tyhicks: with an earlier thread Oct 6 to ratliff + JamieBennett + mvo
<tyhicks> ok, I see the Oct 12 email
<tyhicks> jdstrand: if they're build-depending on dh-golang, is it sufficient to have just the following line in the control file for snapd:
<tyhicks> Built-Using: ${misc:Built-Using}
<tyhicks> seems like that's probably not sufficient
<tyhicks> for us to track everything
<jdstrand> tyhicks: no. built using is useful for static build that use golang-*-dev packages from the archive
<jdstrand> tyhicks: they are using embedded copies and thus can't be tracked
<jdstrand> tyhicks: unless we put that somewhere
<tyhicks> oh, right
<mcphail> kyrofa: sent a PR. I think this fixes things. dav .well-known paths and let'sencrypt both seem to work
<mup> PR snapcraft#1064 opened: pluginhandler: support colliding with directories <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1064>
<kyrofa> mcphail, thank you for reading the contributing guide :)
<mcphail> kyrofa: hah!
<kyrofa> You're the first to get it right!
<kyrofa> Dang, even the commit message
<mcphail> kyrofa: having vim set up correctly to nag makes commit messages easier
<kyrofa> mcphail, I've got a few questions-- want to chat here, or want me to comment on the PR?
<mcphail> kyrofa: either is fine. GH may be better to keep conversation documented
<kyrofa> mcphail, alright
<kyrofa> mcphail, wait, I lied-- I answered my own question. This looks really nice, thank you :) . I'll take it for a spin
<mcphail> kyrofa: quite late here, so I'll catch any questions in the morning
<mup> PR snapcraft#1057 closed: godeps plugin: support for go-packages <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1057>
#snappy 2017-01-21
<oh4> https://www.irccloud.com/pastebin/ciyJB4J9/
<oh4> ogra_: it worked!!!
<oh4> sorry, had to leave this morning in a hurry for work ;)...thought I would have time to troubleshoot from the office but that was a negative ;)
<mup> Bug #1641958 changed: The Cliqz snap will not run from either menu or CLI <Snappy:Expired> <https://launchpad.net/bugs/1641958>
<bso> Hello, I am new to snap, and I have trouble with a snap flag --dangerous.
<bso> I installed snapcraft 2.25 and created a tutorial snap hello_2.10_amd64.snap.
<bso> But, the command "sudo snap install --dangerous hello_2.10_amd64.snap" failed with unknown flag "dangerous".
<bso> I am on Ubuntu 16.04.
<bso> Anybody know if this is a bug or the tutorial is outdated?
<nhaines> bso: what version of snapd do you have?
<mup> Bug #1658281 opened: --dangerous flag not recognized by snap <Snappy:New> <https://launchpad.net/bugs/1658281>
<bso> @nhaines, I just installed snapcraft 2.25 and it came with snapd 2.11+0.16.04
<nothal> bso: No such command!
<bso> @nothal, what do you mean? "sudo snap install --dangerous hello.snap" is not a right command?
<nothal> bso: No such command!
<bso> I was just following the tutorial in snapcraft.io/create
<bso> That is the snapcraft getting started guide, right?
<bso> @nothal, if the install command is not right, what is the right command I should use to install a snap?
<nothal> bso: No such command!
<bso> @nothal, are you a robot?
<nothal> bso: No such command!
<nhaines> bso: the current version of snapd is 2.20.
<nhaines> I don't think --dangerous was added until 2.18 or so.
<bso> ok, I am not sure how I got the old version.
<bso> The tutorial says I have to install snapcraft by "sudo apt install snapcraft", and it seems it installed snapcraft 2.25.
<bso> I did not install snapd separately.
<bso> Should I upgrade snapd separately?
<nhaines> Yes, they're not related.
<bso> Oh, I thought snapcraft installed snapd.
<nhaines> Nope, doesn't look like it from the package description.
<bso> then, probably Ubuntu 16.04 already installed snapd by default.
<nhaines> Yes, 16.04 comes with snapd.  But you should certainly upgrade your development environment when building.  :)
<bso> @nhaines, once I update snapd to the latest version, I was able to run snap-install successfully.
<nothal> bso: No such command!
<bso> Thanks a lot.
<nhaines> That's great!  :)
<mup> Bug #1658281 changed: --dangerous flag not recognized by snap <Snappy:Invalid> <https://launchpad.net/bugs/1658281>
<Skuggen> The --dangerous flag used to be --force-dangerous, just as a note
<mup> Bug #1658298 opened: The (administratively maintained) mapping file /etc/iproute2/rt_tables is not writeable. <Snappy:New> <https://launchpad.net/bugs/1658298>
<mup> PR snapd#2675 closed: asserts: implement SuggestFormat to help avoid specifying the wrong format iteration for an assertion <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2675>
<Roman> Hi, everybody! Would you, please, clarify current status of snap package manager on CentOS? Is it possible to install it with yum, or build and install it from sources? Thank you so much in advance.
<ivo_> Hey Guys, When I try to run a snappy app I get an error msg:  cannot create user data directory:  Read-only file system
<ivo_> can you help me solve the issue
<ivo_> It is happening with all snappy apps
<mup> Bug #1577472 opened: The remapped $HOME directory shows as read-only to applications running in a snap <snapd-interface> <Snappy:Confirmed> <https://launchpad.net/bugs/1577472>
<mcphail> kyrofa: Thanks for updating nextcloud! DavDroid is working perfectly now. Do the nextcloud apps always get disabled on an update? I had to re-enable them as I was working
#snappy 2017-01-22
<mcphail> longsleep: I'm not clear on the instructions on the spreed.me snap at https://raw.githubusercontent.com/nextcloud/spreedme-snap/master/README.md . If I'm running the nextcloud snap, do I have to set up another non-snapped apache instance to forward to the spreed client? Is there something automatic I'm missing?
<Guest7264> I maintain 2 Arch aur packages. Is there a tool or easy guide on how to create snapcraft.yaml based on a aur PKGBUILD file?
<Guest7264> Looking the getting started guide for snap, but I don't see how to format the source and state my dependencies
<Son_Goku> it is not possible to do what you ask at this time
<Son_Goku> unless you're talking about independently re-packaging as a snap?
<Guest7264> happy to create the yaml file for the snap package
<Guest7264> but I do not see where to state what the dependencies are or even how to pull my code from github
<Son_Goku> you don't pull code from github
<Son_Goku> snapcraft.yml is designed to be part of the source tree
<Son_Goku> much like how debian/ folder for debian packaging is
<Guest7264> I'm an Arch guy
<Son_Goku> as for build and runtime dependencies, they are described (in the form of ubuntu packages) in `stage-packages` and `build-packages`
<Son_Goku> so... mild refresher
<Son_Goku> Debian packaging is a merged source build
<Son_Goku> meaning that you must insert your packaging scripts into the original source tree to build
<Guest7264> How would I handle depends=('python' 'python-numpy' 'python-colorama')?
<Son_Goku> rather than external source build, like PKGBUILD and RPM spec, where the sources are retrieved and acted on independently
<Son_Goku> runtime dependencies are filled in as "stage-packages"
<Son_Goku> see here: http://snapcraft.io/docs/build-snaps/syntax#parts
<Son_Goku> makedeps are "build-packages"
<Guest7264> so I would need stage-packages for 'python' 'python-numpy',,, ?
<Guest7264> also how to I state where my source is ? i.e. source=("https://raw.githubusercontent.com/gps1539/stock_quote/master/stock_quote") (in PKGBUILD)
<Son_Goku> you can't
<Son_Goku> your snapcraft.yml needs to sit alongside the script
<Son_Goku> so basically create the project locally, have the stuff downloaded, and then do it
<Guest7264> thanks for your help
<Son_Goku> np
<ivo_> hey guys
<ivo_> how is everything
<lfaraone> zyga: soooooo, how much work would it be to move `/snap` â `/var/run/snap/`?
<lfaraone> or something.
#snappy 2018-01-15
<mborzecki> morning
<mup> Bug #1743301 opened: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301>
<mborzecki> mvo: morning
<mborzecki> mvo: something for snap-advise https://bugs.launchpad.net/snapd/+bug/1742677
<mup> Bug #1742677: snap run should error nicely when snap isn't installed <snapd:New> <https://launchpad.net/bugs/1742677>
<kalikiana> good morning
<mvo> mborzecki: thanks, checking
<mvo> kalikiana: good morning
<mvo> mborzecki: and good morning to you!
<pstolowski> mornings!
<mborzecki> kalikiana: pstolowski: morning
<zyga> o/
<zyga> mvo: good morning
<kalikiana> \o
<zyga> mvo: I have a question to you as a apt maintainer,
<zyga> mvo: when a hdd is corrupted and dpkg database is partially blown away, is it sensible to try to reinstall some packages
<zyga> mvo: or should I just backup home and reinstall the whole thing
<mvo> zyga: well, thats a tough one :) most of the time liberal use of "apt install --reinstall $stuff" makes things work again
<mborzecki> zyga: hey
<mvo> zyga: *but* the trouble with corruption is that you never know what is affected, so reinstalling packages is fine but your user data might be corrupted as well
<mvo> zyga: if there is no/little user data or if you can easily restore this in isolation the reinstall of packages is worth a shot
<mvo> and good morning pstolowski
<zyga> I tried a small reinstall but apt dpkg complained about some packages have empty list of files,
<zyga> I'll do full reinstall :/
<mvo> zyga: well, empty list of files should not be a hard error
<mvo> zyga: can you pastebin the error ?
<mvo> zyga: *if* you want to resovle this tihs way
<zyga> dpkg: unrecoverable fatal error, aborting
<mvo> zyga: there were some more before that I'm sure
<zyga> (then localized), list of files in package "libc6-dbg:amd64" contains empty file name
<seb128> hey there
<seb128> is bug #1742687 likely a regression in snapd?
<mup> Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1742687>
<seb128> the title might be misleading, he's using 2.30 which is not in other ubuntu series
<zyga> seb128: perhaps, I think the url opening moved to snapctl (but I may be mistaken)
<seb128> zyga, could somebody familiar with that part of the codebase check if there is an issue?
<mborzecki> 09:29:05 up 12:42,  7 users,  load average: 14.75, 13.00, 11.22 :/ building snapd yocto image on x220
<mvo> zyga: you could try "dpkg --purge libc6-dbg" but probably not worth it
<zyga> seb128: yes, for sure
<seb128> thx
<zyga> mvo: that doesn't work
<zyga> same error
<mvo> zyga: hm, mv /var/lib/dpkg/info/libc6-dbg:amd64.list /tmp/backup and ty again? (double check that I got the path of the .list file right please)
<zyga> k
<mvo> zyga: and then re-try the --reinstall ?
<zyga> mvo: that file doesn't exist at all
<zyga> ah, no sorry
<mvo> zyga: no "/var/lib/dpkg/info/libc6-dbg\:amd64.list " ?
<zyga> shell has issues with : in filenames :/
<zyga> heh
<zyga> mvo: I'll ski
<zyga> mvo: inside I see a DBUS XML profile
<mvo> zyga: haha
<zyga> mvo: my disk is a messed up soup
<mvo> zyga: there you go
<zyga> mvo: I'm making a bootable usb now
<zyga> :/
<mvo> zyga: well, you could try to repair this one
<mvo> zyga: of course if that is all over the place> FAIL
<zyga> mvo: fsck printed a huge list of changes
<zyga> mvo: I think that's not a happy disk
<mvo> ok
<mborzecki> zyga: smart did't raise a warning or anything?
<mvo> zyga: good luck - do you happen to have an 18.04 vm? or sebs bug?
<zyga> mborzecki: not a single one
<zyga> mborzecki: I'm running small test
<zyga> mvo: I don't have 18.04 vm yet, no
<mvo> ok
<mborzecki> zyga: at least tell us the band of the disk, and why it ahppens to be a seagate? :)
<zyga> mborzecki: wd
<zyga> mborzecki: they all eventually fail :/
<zyga> it's a 1TB blue
<zyga> 832 start/stop cycles
<zyga> 3 months and 1 day of uptime total
<zyga> so...
<mborzecki> :/
 * mborzecki goes to check smart log on his nas disks
 * zyga tarballs home and DDs 17.10 installer to usb
<zyga> mvo: do you think I could reinstall 18.04 instead
<zyga> I wonder if that could help with the bug in a meaningful way
<zyga> seb128: http://cdimage.ubuntu.com/releases/17.10.1/release/ - is the 17.10.1 release due to meltdown?
<mvo> zyga: sure, can't hurt to install 18.04
<seb128> zyga, no
<mvo> zyga: 17.10.1 might also be because of the bios issue with lenovo
<seb128> what mvo said
<zyga> ah, I see
<zyga> I'll do 18.04
<zyga> let's see what's coming
<zyga> hey there Chipaca
<Chipaca> zyga: o/!
<Chipaca> zyga: how's things?
<mborzecki> would appreciate if someone could take a look at https://github.com/snapcore/snapd/pull/4480 the only controversial thing may be stopping and cleaning up *.services files for services that came from snaps, eg. lxd
<mup> PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>
<Chipaca> mborzecki: is this for stopping and removing those things on purge?
<mborzecki> Chipaca: yes
<zyga> Chipaca: so so :) doing a reinstall now, hoping that my HDD isn't totally crazy :)
<zyga> Chipaca: just picking up some PRs to review while I wait
<Chipaca> mborzecki: I don't think that's controversial; that's what the deb package was supposed to do in its postrm
<mborzecki> zyga: FYI, today's supposed to be blue https://en.wikipedia.org/wiki/Blue_Monday_%28date%29 maybe your hdd just had a breakdown (sorry for dad joke)
<mvo> Chipaca: s/supposed to do/doing/ - no ?
<Chipaca> mvo: I assume it is also what it does, if that's your question :-)
<mborzecki> Chipaca: deb postrm is still is still a separate script under packaging/, don't have that must experience with debs as to move it to preprm and invoke snap-mgmt --purge
<Chipaca> mvo: I'd have to look at the current postrm to say for sure :-D
<pedronis> Chipaca: yes, it does that
<mvo> Chipaca: aha, thats fine. I was wondering if there is a bug in the postrm
<Chipaca> mvo: there's an expression in Spanish, 'no meto las manos en el fuego por nadie' :-)
<mvo> Chipaca: there is an expression in german: "Ich verstehe kein Spanisch"
<mvo> Chipaca: ;) anyway, thanks!
<pedronis> mborzecki: it does that also for mount units btw
<pedronis> (the deb postrm)
<Chipaca> mvo: there's an expression in French, "ils sont fous ces allemands"
<mvo> mborzecki: fwiw, unifying postrm and snap-mgmt is tricky because in the dpkg world you can do a "dpkg --remove" and everything from the regular deb is gone just the "post{inst,rm}" etc is left. so any purge would have to be "sourced" (copied) into the postrm
<mvo> mborzecki: I mean, any code sharing would have to be done via some magic that copies things into postrm
<mborzecki> mvo: sound ugly
<mvo> Chipaca: heh :) I think I know enough french for this one ;)
<mvo> mborzecki: yeah, britle and terrible
<pedronis> it could be done in the Makefile / rules
 * mvo hugs Chipaca and apologizes for trolling him on a monday morning
<mvo> pedronis: yeah, I think its doable, we just need to be careful and it will be a little bit ugly
<mvo> (of course it is, SMOP and all that :)
<zyga> mborzecki: haha
<zyga> mborzecki: nice ;)
<mup> PR snapd#4486 opened: snap: make `snap run not-install` output advise for not installed commands <Created by mvo5> <https://github.com/snapcore/snapd/pull/4486>
<zyga> mborzecki: just curl mgmg.snapcraft.io
<zyga> mborzecki: just curl mgmg.snapcraft.io | sudo sh
<zyga> mborzecki: ;-)
<zyga> mborzecki: no need to worry about postrm
<zyga> ;-)
<zyga> man, my typing sucks on this laptop
<mborzecki> hmm ok, seems like there's a bug in #4480
<mup> PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>
<mvo> mborzecki: is bug #1741474 something to set to "fix commited" ?
<mup> Bug #1741474: Migrating from snapd to snapd-git results in 'broken' snaps <snapd:Triaged> <https://launchpad.net/bugs/1741474>
<mborzecki> mvo: yeah, think it's ok to switch the status
<mvo> mborzecki: thank you! and thanks for the fix
<mborzecki> mvo: oh, it's not me, it's philm from manjaro who updated the packages
<mborzecki> anyways, they are in sync with ones from AUR now
<mvo> mborzecki: ta
<zyga> mvo: can 4424 land?
<mvo> zyga: let me look at this one more, maybe we don't need to honor this limit if pam is already doing the right thing internally
<zyga> pstolowski: is landing new interfaces problematic for you?
<zyga> pstolowski: can I land 4365? (do a qucik review maybe)
 * zyga requests review for 4329
<zyga> 4329 is from nov 2017 and fixes a bug
<pstolowski> zyga, by all means we should land new interfaces, i'll update my branch if needed
<pstolowski> zyga, let's just avoid any unnecessary refactorings around interfaces at this point and it will be fine
<pstolowski> so yes please land 4365
<zyga> pstolowski: kk
<pedronis> zyga: yes, I looked at the new package I'm using, what's the procedure for new deps ?
<zyga> pedronis: I don't think we have any really, I just wanted to double check someone from the team read that package
<zyga> jamesh: hey
<jamesh> zyga: hi
<pedronis> zyga: yes, IÂ read the package, it doesn't do networking, has good coverage
<pedronis> seems to do the job
<zyga> jamesh: so, how are we doing for per-user mount ns; with my mind busy on my box being broken I forgot the detailed agreements from last week
<pedronis> there are much more complicated packages for this, but seems overkill for these case
<zyga> jamesh: can I help you some way?
<pedronis> *this case
<zyga> pedronis: that sounds good to me
<mborzecki> zyga: pedronis: pushed a fix to #4480 can you take a look?
<mup> PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>
<zyga> mborzecki: aha
<mup> PR snapd#4365 closed: interfaces/mir: allow Wayland socket and non-root sockets <Created by gerboland> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4365>
<zyga> mborzecki: commentd
<mborzecki> zyga: thanks, the reload doesn't happen in postrm either, i'd say it's up to the caller to do a systemctl daemon-reload
<pedronis> Chipaca: zyga:Â I see for boltdb we added something like to the spec BuildRequires: golang(github.com/boltdb/bolt)  but I see for other/older package there are other bits as well by grepping about Requires and Provides
<Chipaca> pedronis: oh?
<pedronis> for example I see:  BuildRequires: golang(github.com/ojii/gettext.go)  Requires:      golang(github.com/ojii/gettext.go)  Provides:      bundled(golang(github.com/ojii/gettext.go))
<pedronis> the bundled bit I'm not sure what is about
<pedronis> Chipaca:  ^
<Chipaca> ah, me neither
<Chipaca> I added the BuildRequires because without it it wouldn't work :-)
<Chipaca> I don't know the significance of the rest
<pedronis> Chipaca: well IÂ didn't even add that, because fedora is off :/
<jamesh> zyga: just testing out the change for making /media shared again. I think that was the only thing we decided was needed before merging it
<Chipaca> pedronis: you can still run it by hand :-D
<pedronis> Chipaca: and see it fail for other reasons anyway?
<Chipaca> pedronis: running a test by hand has high chances of working
<pedronis> IÂ mean, we turned off fedora for reasons
<mborzecki> zyga: #4329, the code there is called with cgroup frozen?
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<Chipaca> pedronis: running all the tests has high chances of failing
<Chipaca> pedronis: Â¯\_(ã)_/Â¯
<pedronis> Chipaca: anyway, should we cargo cult the rest for boltdb?
<Chipaca> pedronis: I'd rather ask somebody that knows
<pedronis> I suppose all deps should be the same
<Chipaca> that's a good supposition, and we can go with it if neil doesn't show today
<Chipaca> ok?
<zyga> re
<pedronis> yea
<zyga> jamesh: cool
<zyga> jamesh: I don't know if *just* making it shared will be enough tho
<pedronis> Chipaca: could you look at #4481
<mup> PR #4481: image: let consume snapcraft export-login files from tooling <Created by pedronis> <https://github.com/snapcore/snapd/pull/4481>
<zyga> jamesh: otherwise the code that makes /media shared would be much much easier to write originally
<Chipaca> pedronis: on it
<pedronis> thank you
<zyga> jamesh: do a practical test please (ideally patch the /media spread test to also have a dummy per-user mount profile to see)
<zyga> mborzecki: no
<zyga> mborzecki: just with the per-ns lock held
<zyga> jamesh: when you make / rslave it is a one-way ticket, you cannot make it shared again (AFAIR), subsequent share will just make it a master for other slaves
<zyga> jamesh: I might be wrong but I think this is why the /media setup that we have now ended up so convoluted
<zyga> jamesh: (I stash away /media to recover it later)
<pedronis> Chipaca: I think Gustavo wants us to look into converging more login stuff between snapd and snapcraft and also we really need to teach download to use the creds inside snapd when it make sense
<pedronis> Chipaca: that's why I'm holding off adding command line options
<Chipaca> pedronis: i agree we want that, but we also want snap download to work in the absence of a running snapd (and we want to specify the arch anyway) i think
<Chipaca> nothing urgent and i didn't mean it needed doing right now
<pedronis> the arch yes
 * zyga is grumpy because the good green tea has run out
<Chipaca> snapshots also run in the absence of snapd :-D
<pedronis> just explaining why IÂ didn't add command line options so far
<zyga> and the store carrying it is on the other side of the city
<Chipaca> zyga: send your snappy-enabled drones
<zyga> Chipaca: arduino with a sign "will write model assertions for tea"
<Chipaca> zyga: hey now, no unlawfully competing with ogra_
<zyga> Chipaca: I think ogra would write beer, that's a different market segment
<zyga> we can coexist peacefully
<Chipaca> augh! i should've gone to physio
<jamesh> zyga: I think you're right.  I thought I had something working, but it doesn't seem to be propagating.
<jamesh> zyga: I do wonder if anything using the desktop interface would ever be affected by this though
<zyga> jamesh: I think it's not the point though, you can just rslave all top-level elements or rslave / and bind /media over from another place if you keep one handy
<jamesh> e.g. display security in current Ubuntu doesn't let root connect to the user's display
<jamesh> zyga: so I need to track down what all the top level mounts are then
<zyga> jamesh: no, no need
<zyga> jamesh: just opendir and iterate over top level elements
<zyga> and skip media
<jamesh> zyga: but the top level directories aren't all going to be mount points
<zyga> not a problem
<zyga> ah
<zyga> actually, you are right
<zyga> that is a problem
<zyga> rshare doesn't handle non-mount entries
<zyga> bummer :/
<jamesh> zyga: as I mentioned on the hangout, I think the long term solution is to construct separate mount namespaces for each user from scratch, working out some way to get the right parts shared
<niemeyer> pedronis: We've had so many issues with the differences in download that by now I'm seriously wondering if doing the opposite of what we do now wouldn't be a better approach. That is,
<zyga> jamesh: I honesntly don't even see how that can work
<zyga> jamesh: it's far more complex than what we have now
<zyga> jamesh: I'll dismiss that without any poc code
<niemeyer> ..., make download go through snapd by default, and only fallback if snapd is not available, in which case we warn that we're doing it locally and that differences may emerge
<ogra_> zyga, correct .... and also ... i dont touch systems without MMU ;)
<zyga> jamesh: (even back of the envelope pseudocode)
<jamesh> zyga: well, one option is to have snap-confine save one copy of the mount namespace before calling snap-update-ns, and reuse that if it is found
<mborzecki> zyga: went through #4329, left some comments
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4329>
<jamesh> zyga: then the per-user mount namespace would be cloned off that, and all mounts (both global and per-user) would be performed on top of that
<zyga> mborzecki: thank you
<zyga> mborzecki: looking now
<zyga> jamesh: maybe it's easier than I assume by I really would like to see some pseudocode written (e.g. forum thread)
<zyga> jamesh: I suspect the devil is in the details here, it's very delicate piece of code
<pedronis> niemeyer: I know we discussed this, we still haven't really prioritized the changes involved, in practice we need both path as you said, it's a matter of what is the default
<jamesh> zyga: anyway.  As the code currently stands, it won't do anything until an interface is modified to use it.  And the desktop interface isn't really appropriate for processes running as root.  So is this a big enough deal to block the initial landing?
<zyga> jamesh: I'd like to see how we could fix that, give me one day to come up with a plan and if not let's land it
<jamesh> okay
<mvo> hey cachio ! welcome back
<cachio> mvo, hey, thanks
<zyga> cachio: wow, hey
<cachio> mvo, glad to be here again
<cachio> zyga, hey, long time
<zyga> cachio: I hope you had great time :)
<cachio> zyga, yes it was, thanks
<cachio> mvo, any plan for beta validation?
<mvo> cachio: yeah, probably tomorrow, we had a bit of a setback because of spectre/meldown, no edge builds for a couple of days
<cachio> mvo, ok
<zyga> cachio: welcome back, the internet has melted and is chased by some spectres
<cachio> zyga, hehehe, yes
<cjwatson> Are you still blocked on the remaining ppa:snappy-dev/ubuntu/edge builds?
<cachio> zyga, no way to scape from that
<Chipaca> E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list
<cachio> zyga, is there any change in snapd for deal with those issues?
<Chipaca> quoth the raven, WAT
<mvo> cjwatson: well, sort of, for a new release we would need a core for all our supported arches. i understand the other arches are still disabled until we have new kernels fixes there too(?)
<zyga> cachio: no, just extra delays around
<zyga> cachio: probably new toolchains soon
<zyga> cachio: maybe a rebuild required, not sure
<cachio> zyga, ok
<cjwatson> mvo: What's the process for getting code into this PPA?  I see it goes via some snapd-vendor git repository - can you tell me how code gets there?
<mvo> cjwatson: its a sync from github.com/snapcore/snapd
<cjwatson> mvo: (we can whitelist builds, but we have to treat the builders as if they have no effective virtualisation at the moment)
<mup> PR snapd#4487 opened: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
<cjwatson> mvo: hmm, any reason it's not a Launchpad git-to-git import?  Is it gated in some way?
<mvo> cjwatson: and we only allow code in that we reviewed and that passed our test suite (and CLA)
<mvo> cjwatson: there is one complication - we do sync in the "vendor" tree into this git repo. i.e. all our vendored dependencies. nothing gets updated that we don't explicitly update via vendor/vendor.json but there is code that we did not control in there so it probably does not qualify as "ok" in this day-and-age
<mvo> cjwatson: (this is why the git tree is called snapd-vendor, i.e. snapd+vendor-code)
<cjwatson> ah, ok
<cjwatson> mvo: does your process for updating vendor/vendor.json at least involve eyeballing the upstream diff?
<zyga> (uncomfortable moment)
<zyga> ;-)
<mvo> cjwatson: yes, however we have no strict policy around this and have been not careful about this in the past. on the plus (or minus) side, we only update rarely
<mvo> cjwatson: anyway, I understand the current situation, I'm ok with waiting for more kernel/isolation fixes
<ogra_> cjwatson, the nplan build in https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial would also be needed for the next core (at least on armhf)
<mvo> cjwatson: obviously it depends on how long it will take if fixes are weeks away we need to consider what to do
<ogra_> would be nice if that could get an exception
<cjwatson> mvo,ogra_: I think at least these current ones are OK.  Scheduled
<ogra_> thx!!
<mvo> cjwatson: thank you!
 * kalikiana going for lunch in ~10
<mup> PR snapd#4488 opened: snap: make `snap find --section` show all sections <Created by mvo5> <https://github.com/snapcore/snapd/pull/4488>
<mborzecki> is tehre a way to tell if --argument was passed in command line?
<zyga> mborzecki: hmm?
<zyga> where?
<ogra> zyga, did you notice https://forum.snapcraft.io/t/how-to-get-snapd-to-work-with-external-mounts/3481 ? (that guy seems to slowly become grumpy)
<ogra> (and the subject is mis-leading ... its about the debian 9 kernel and apparmor)
<zyga> yeah, I see
 * pstolowski lunch
<mborzecki> zyga: i want to have something like this: `snap find --section`, i.e. have the parser allow `--section` without value even though it's defined as string
<zyga> mborzecki: I don't know, there may be a way to do that with go-flags (optional argument)
 * zyga coffee
<zyga> time to reinstall next, backup done
<mborzecki> came up with some workaround: https://paste.ubuntu.com/26391469/ this is for https://bugs.launchpad.net/snapd/+bug/1742960
<mup> Bug #1742960: snap find --section does not list sections <snapd:In Progress> <https://launchpad.net/bugs/1742960>
<mborzecki> haha, see that mvo  has opened a PR already :)
 * zyga keeps fingers crossed that bionic reinstall will work for this week and that hdd is not totally busted
<zyga> especially that smart was OK
<zyga> not sure what caused this
<zyga> at least I will have a fresh filesystem there
<zyga> kernel crashed on reboot
<zyga> well
<zyga> that's a good sign
<zyga> ...
<zyga> not
<zyga> hmm
<zyga> it's still doing something
<zyga> just spews ...
<zyga> ok
<zyga> ok
<zyga> this disk is gone
<zyga> just broke after install
<zyga> SMART my ass
 * zyga is grumpy now
 * Chipaca hugs zyga 
<mborzecki> salvage what you can, drill it through, throw it in the dumpster :/
<zyga> mborzecki: I have a full backup, so that's not a problem
<Chipaca> i was going to suggest opening it and peeing on it, but i decided against it
<zyga> mborzecki: and it "works" a little, just fails writes often
<mborzecki> every now and then
<zyga> Chipaca: I need some of that alien pee
<Chipaca> zyga: that's your call
<mborzecki> zyga: so now you can play with running linux on the chip that's inside the drive
<mborzecki> zyga: http://spritesmods.com/?art=hddhack&page=1
<zyga> mborzecki: or buy those discounted fireworks
<kalikiana> re
<pachulo> Hi! I have a doubt regarding the "base" system used to build the snaps in launchpad: when will it be changed to 18.04 (from 16.04)? Is there any established date?
<Chipaca> pachulo: not yet no
<pachulo> Chipaca: is there any rough guess? like: before the end of 2018?
<Chipaca> pachulo: I'd expect it to be done before 18.10
<Chipaca> pachulo: but after 18.04
<Chipaca> pachulo: JamieBennett might be in a better position to offer a firmer answer, if one exists
<pstolowski> niemeyer, one of my PRs that needs your re-review: https://github.com/snapcore/snapd/pull/4440
<mup> PR #4440: state: unknown tasks handler <Created by stolowski> <https://github.com/snapcore/snapd/pull/4440>
<mborzecki> niemeyer: https://github.com/snapcore/snapd/pull/4487 and https://github.com/snapcore/snapd/pull/4476
<mup> PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
<mup> PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476>
<mup> PR snapd#4481 closed: image: let consume snapcraft export-login files from tooling <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4481>
<mvo> zyga: fwiw, I can reproduce the dbus error on bionic, it does not make sense to me our rule looks good
<zyga> mvo: interesting, I can "try" on my current broken system
<mvo> pedronis: re 4481> we used to use https://packages.debian.org/sid/golang-github-mvo5-goconfigparser-dev in the past for ini parsing, this is packaged for debian and afaict also for fedora
<mvo> zyga: do you have any hints how to debug this?
<pachulo> ok, thanks Chipaca
<zyga> mvo: hold on, let me reproduce locally
<Chipaca> are there go build flags that can be used to build something only on 14.04?
<mvo> zyga: hm,hm, apparmor_parser -r /path/to/apparmor/profile seems to fix it :(
<zyga> ouch :/
<zyga> that's not good
<zyga> which profile did you reload, that of the app, right?
<mvo> zyga: correct
<mvo> zyga: its in a VM so copy/paste is a bit harder but essentially "apparmor_parser -r /var/lib/snapd/appamror/profiles/snap.gimp.gimp"
<pedronis> mvo: we can switch I suppose, the package I picked has a even simpler interface (but more code)
<mvo> pedronis: I am sitting on the fence, less code we need to maintain is good so I'm hesitant advocating for moving back to this code. otoh it will probably make life for the packagers easier
<pedronis> mvo: I need to go have my daily walk, IÂ let you think a bit more
<mvo> pedronis: I can to a POV port if you want (lets talk after your walk)
<mborzecki> hm we don't seem to clean up udev rules in postrm and snap-mgmt
<zyga> mvo: family calls for lunch now, I'll be back; the apparmor relead feels bad, I will see if I can reproduce (on clean bionic install)
<mborzecki> off to get the kids
<mvo> zyga: sure, lets talk in a bit
<mvo> zyga: so, it seems to be related to "peer=(label=unconfined)" when I rmeove this and reload things work. when I add it back things work still
<om26er> popey: Hey! mind taking a look at https://github.com/snapcrafters/android-studio/pull/13 ?
<mup> PR snapcrafters/android-studio#13: Export missing library paths <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/13>
<om26er> The change only affects the emulator.
<zyga> mvo: hmmm
<zyga> mvo: that's odd
<mvo> zyga: yes
<zyga> mvo: but the peer is an unconifned snap userd, right?
<mvo> zyga: I assume so - also its strange that I can change/add back and things keep working
<mvo> zyga: how can I find out if it is unconfined?
<zyga> mvo: add that "peer" constraint?
<zyga> mvo: and reload?
<zyga> or not
<mvo> zyga: thats what I did: first remove the peer constrain, reload -> works
<mvo> zyga: then re-add the exact same constrain as before, reload -> works
<zyga> which snap did you use for testing?
<mvo> zyga: gimp
<mvo> zyga: and reboot (with peer=(unconfined)) that worked before the reboot now fails again it seems.
<zyga> and reboot the OS?
<mvo> zyga: now I just rebooted the vm
<zyga> mvo: reproduced, I didn't change anything though, just installed gimp and attempted to open the developer website
<mvo> zyga: yeah, that fails for me as well
<mvo> zyga: to make it work I had to remove the peer=un constrain
<zyga> hmm, offtopic, installing snaps from gnome software shows the progress as stufk at 99% (after it completes in reality)
<zyga> mvo: so
<zyga> without touching the profiles or rebooting
<zyga> I ran "snap userd" from the shell
<zyga> and that made it work
<zyga> mvo:
<zyga> so this seems reproducible: activation doesn't work but after it is activated (in any way) it works correctly
<zyga> mvo: activation from either running snap userd manually or activating via d-feet
<zyga> mvo: I think we want to look at how that activation happens
<zyga> mvo: perhaps (somehow, no idea) when activation is processed by apparmor is goes to a confined helper
<zyga> mvo: (maybe that's the new thing in 18.04)
<zyga> mvo: that just transitions to our service
<zyga> mvo: note that the mechanism is just a speculation at this point
<elopio> Hello!
 * Chipaca -> physio
<jdstrand> peer=(unconfined) is not correct syntax
 * jdstrand looks
<mvo> zyga: aha, nice
<mvo> zyga: thanks, that explains why it works for me
<mvo> zyga: thanks for figuring this out
<mvo> zyga: will you update the bugreport or shall I?
<jdstrand> peer=(label=unconfined)  is correct and what is in the desktop interface
<zyga> mvo: I'm still digging
<zyga> mvo: yes, gladly
<zyga> jdstrand: it doesn't work for activation (apparently)
<zyga> jdstrand: I'm trying to understand how that happens in bionic
<zyga> jdstrand: it works once activated
<zyga> jdstrand: just tested on pristine install
<jdstrand> zyga: it should work
<jdstrand> userd is unconfined. dbus daemon may have a bug
<jdstrand> on non-bionic, is userd already running?
<jdstrand> ie, check if activation is working everywhere
 * jdstrand tries on artful
<zyga> jdstrand: I dind't check on pre-bionic yet
<zyga> jdstrand: on bionic I get an apparmor denial
<jdstrand> zyga: can you paste it?
<jdstrand> what is the binary in ps that I can check foruserd?
<jdstrand> s/userd/ userd/
<pedronis> mvo: I'm back
<zyga> jdstrand: it's "snap userd"
<zyga> jdstrand: one sec, separate box
<jdstrand> zyga: activation wrks on artful. browser opened just fine
<zyga-bionic> sty 15 15:34:45 kaedwen dbus-daemon[1242]: apparmor="DENIED" operation="dbus_method_call"  bus="session" path="/io/snapcraft/Launcher" interface="io.snapcraft.Launcher" member="OpenURL" mask="send" name="io.snapcraft.Launcher" pid=5773 label="snap.gimp.gimp"
<zyga> jdstrand: activation works on bionc if the requester is unconfined
<zyga> jdstrand: and doesn't work with this activation if the requester is confined (I used gimp, same as mvo above)
<jdstrand> huh, there is no peer label
<jdstrand> is that the complete line?
 * jdstrand used gimp snap on artful
<zyga> jdstrand: yes
<zyga> jdstrand: something must have changed in bionic
<jdstrand> zyga: hard to say if that is a libapparmor bug or a dbus daemon issue
<jdstrand> but dbus-daemon is not logging the peer_label, so that seems possibly to lean towards dbus-daemon
<zyga> I'll update the bug with more details and look at how that works
<jdstrand> zyga: what is the bug number?
<zyga> is that filtering done in userspace by dbus or in kernel space on the socket?
<zyga> jdstrand: my thought exactly, one sec
<jdstrand> zyga: the kernel mediates access to the unix socket. dbus-daemon mediates the messages and signals
<zyga> jdstrand: is dbusd using libapparmor?
<jdstrand> zyga: yes
<zyga> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1742687
<mup> Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687>
<jdstrand> zyga: for dbus policy, think of the kernel as the database of rules that dbus-daemon can ask if an access is allowed or denied
<jdstrand> zyga: it does that via libapparmor
<zyga> I see
<zyga> I'll have look, thankyou
<jdstrand> zyga: then dbus-daemon allows/blocks the access
<zyga> jdstrand: btw, I know you are sprinting but could you look at this apparmor profile change: 24 lines of diff , https://github.com/snapcore/snapd/pull/4472/files
<mup> PR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
<zyga> cachio: FYI: 2018-01-15 13:03:14 Cannot allocate linode:ubuntu-16.04-32: cannot perform Linode request: Post https://api.linode.com: net/http: TLS handshake timeout
<zyga> cachio: 2018-01-15 13:03:14 Aborted tasks: 1165
<cachio> zyga, ups
<cachio> zyga, which PR?
<zyga> 4472
<zyga> I'll restart
<zyga> maybe just a fluke
<cachio> zyga,
<cachio> zyga, when you have time could you please take a look to #4472
<mup> PR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
<cachio> zyga, #4307
<mup> PR #4307: tests: fix "job canceled" issue and improve cleanup for snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4307>
<cachio> sorry
<zyga> cachio: no https://github.com/snapcore/snapd/pull/4472
<mup> PR #4472: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <https://github.com/snapcore/snapd/pull/4472>
<zyga> mvo: there's a new patch for apparmor in bionic version of dbus
<zyga> I'll check that out
<zyga> and it talks about the connection security credentials
<zyga> ie. exactly what broke
<popey> diddledan: https://dashboard.snapcraft.io/snaps/opentyrian/ needs some screenshots :)
<mvo> zyga: cool, thanks for investigating - do you have  link?
<zyga> mvo: for the patch?
<zyga> mvo: it's in the bionic source package, I don't have a link
<mvo> zyga: ok, what is the name of the patch? I get the package
<zyga> aa-get-connection-apparmor-security-context.patch
<mvo> ta
<zyga> mvo: the idea is that ubuntu can use one of two ways to get security context
<zyga> the old way (apaprmor label)
<zyga> or the new way (generic dbus container via a mediator that introduces a new socket to dbus)
<zyga> there's pently of logging there, I just want to see it somehow
<mvo> zyga: aha, ok
<zyga> mvo: the dbus-tests package has dbus that has verbose debugging activate
<zyga> mvo: I think I don't need to build another copy, just make that active
 * zyga tries
<popey> 33
<zyga> wow
<zyga> I can cp a library over and my desktop explodes
<zyga> interesting :)
<popey> diddledan: also, micropolis
<diddledan> dang, you mean I need to start playing some games?! oh the horror!
<popey> diddledan: i have taken some if you want them, I'll put them in dropbox
<diddledan> cool
<diddledan> you da king of screenies
<mvo> zyga: *cough* mv is your friend
<zyga> mvo: I used cp because I didn't want to remove a file belonging to the package
<zyga> but anyway, I'm looking for the logs
<zyga> hmm, where is the systemd unit that describes the session bus?
<zyga> dbus deamon on session bus
<ogra> in Xorg it used to be part of the Xsession startup
<ogra> not sure where it moved in wayland
<zyga> I think I'm on xorg still actually
<ogra> well, dig in /etc/X11/Xsession.d/
<seb128> zyga, what are you trying to figure out?
<seb128> zyga, DBUS_SESSION_BUS_ADDRESS env variable?
<ogra> seb128, how the session dbus is started
<zyga> seb128: how to inject DBUS_VERBOSE=1 at the right spot
<zyga> seb128: I want to enable dbus_verbose calls
<diddledan> popey: done
<popey> thanks!
<diddledan> accidentally added the tyrian ones to micropolis for a second.
<popey> lulz
<seb128> zyga, you need to rebuild dbus for that I think
<seb128> "       DBUS_VERBOSE=1 will have NO EFFECT unless your copy of D-Bus was
<seb128>        compiled with verbose mode enabled. This is not recommended in
<seb128>        production builds due to performance impact"
<ogra> how developer friendly :P
<diddledan> wow, opentyrian is popular: 2,992 total downloads
<zyga> seb128: yes I thought the same but I replaced my bianries with those from dbus-tests package
<zyga> seb128: it contains a second build with that option set
<seb128> ah
<zyga> seb128: I think I just need to get the environment right now
<seb128> zyga, what the dbus-manapage recommends to do is
<seb128>  DBUS_VERBOSE=1 dbus-daemon --session --print-address
<seb128> then set  DBUS_SESSION_BUS_ADDRESS=<returned value> <yourprogram>
<zyga> ok, let's try
<ogra> seb128, but will that replace the already running dbus ?
<seb128> no
<seb128> that creates another bus
<ogra> right
<seb128> but if you set the env it just makes your prog uses the new one
<ogra> ah, indeed
<seb128> that might be good enough to debug the snapd issue
<ogra> yeah, zyga will have to restart snapd wth the var set though
<zyga> yes, trying now
<seb128> right
<diddledan> yeesh, gimp: 80,279 total downloads
<zyga> ogra: hmmm, that's curious
<zyga> I just need that in snap run gim
<zyga> not in snapd proper
<ogra> well, you want your userd to be connected to that bus
<ogra> not sure if thats coming from snapd or from something else
<zyga> ogra: userd is spawned by the session
<zyga> that's where the bug is
<ogra> (snapd-xdg-open was so much easier :P )
<ogra> zyga, right
<ogra> so you need the var in the userd startup script and need to restart userd
<diddledan> is this the 18.04 url problem you're working on?
<zyga> oh yeah
<zyga> the glory of logging
<zyga> all the way up to 11
<seb128> zyga, my usual hack for those type of situation otherwise "sudo mv binary binary.real" and make "binary" a shell script that export the env and call binary.real :p
<zyga> thank you seb128
<seb128> yw :)
<zyga> ogra: it's all temporary until that new IPC takes over ;)
<ogra> kdbus :P
<zyga> no, that newer one
<zyga> remote var something
<seb128> zyga, don't forget to make the script +x if you do that
<Pharaoh_Atem> mvo: so it seems that Debian is the weird one for the GCC arm triple
<Pharaoh_Atem> I just checked Fedora, Mageia, and SUSE, and the arm triple is the same for all three
<Pharaoh_Atem> there's nothing that specifies an override or anything
<zyga> hrm
<zyga> no new logs when I xdg-open with all the right bits inside
<zyga> probably dbus client code in the core snap is the problem
<mvo> Pharaoh_Atem: thanks for checking! sad that the triplet is so loosely defined
<zyga> jdstrand: I confirmed that dbus-daemon didn't respond in any way (in a super verbose build) to an incoming activation request, I suspect it gets filtered in the kernel before we se
<zyga> jdstrand: I ran "DBUS_VERBOSE=1 dbus-daemon --session --print-address" in one terminal
<zyga> jdstrand: then ran "snap run --shell gimp" in another one
<seb128> zyga, did you set DBUS_SESSION_BUS_ADDRESS= to the value from the one you started with verbose?
<Pharaoh_Atem> mvo: in fact, hilariously, there's a patch for Fedora python to fix armhfp detection because it has hardcoded the debian triple in its build process :/
<zyga> exported DBUS_SESSION_ADDRESS= in another one
<zyga> seb128: yes
<zyga> I also set DBUS_VERBOSE=1 on the client side but since it's the core snap, I suspect that is futile
<Pharaoh_Atem> mvo: I suspect that if you were to build gcc as a snap from vanilla sources, it would produce the triple used on Fedora, Mageia, and openSUSE
<zyga> gcc as a snap would be great
<zyga> especially with instances and tracks
<Pharaoh_Atem> zyga: don't get any ideas
<Pharaoh_Atem> :)
<zyga> Pharaoh_Atem: my idea for today is to get drunk
<Pharaoh_Atem> approved
<zyga> I just don't have alcohol
<zyga> so I'll make tea instead
<zyga> and read a book
<zyga> just as good
<Pharaoh_Atem> denied :)
<zyga> hrm
<zyga> hmm
<zyga> dbus doesn't build for me on bionic
<zyga> one of the tests fails
<seb128> ignore the test if it's for local testing?
<zyga> yeah, I guess I have to
<ogra> zyga, also, did you add DBUS_SESSION_BUS_ADDRESS= to the userd startup ?
<ogra> else it will simply connect to the default session but
<ogra> *bus
<ogra> i doubt a simple export in a shell will apply to a systemd user session start script
<zyga> ogra: userd is supposed to be started by the session
<zyga> ogra: this is what the bug is about
<zyga> ogra: it doens't run at all :)
<ogra> zyga, userd will likely be started by a systemd user session unit
<zyga> doesnt*
<zyga> no, it didn't start with the session
<ogra> if you dont do the export in the unit it wont have the var set
<zyga> and doesn't autostart (because of the bug) anyway
<zyga> it will have the var set
<zyga> because it's ... started by the session
<zyga> which I started
<ogra> oh, its a dbus service ?
<zyga> and to which I'm talking from snap run --shell gimp
<zyga> yes :)
<ogra> ah
<zyga> I don't have a fix yet, something is still fishy
<zyga> ogra: if I start it myself everything works (no bug)
<zyga> it's just activation that breaks
<ogra> right
<zyga> something is messing up the peer credentials
<zyga> I'm building without unit tests now
<steph250> hello all
<zyga> hello steph250
<kalikiana> steph250: what's up
<steph250> Trying to setup my 1st snap, on raspberry, but ...
<brunosfer> Hey guys, I'm buying another dev board to deploy ubuntu snappy core but I noticed that DragonBoard 410C was discontinued on seedstudio... Does anyone has any other dev board in mind except Raspberry Pi family?
<Chipaca> ogra: ^
<Chipaca> steph250: but...?
<zyga> brunosfer: depends on what your goal is
<zyga> brunosfer: to make software for core devices or to make core devices
<ogra> brunosfer, to my knowledge we dont have any plans on later dragonboards etc ...
<steph250> facing some issue with libraries, like "not found".
<zyga> steph250: those libraries must be in your snap, your snap needs to contain machinery (environment variables) to find them
<zyga> steph250: also mvo is exploring making some of those requirements obsolete eventually (snapcraft works around those today)
<ogra> brunosfer, there are some "community images" at http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ that you could use ... but only pi2/3 and dragonboard 410c are officially supported
<steph250> Not so sure, zyga. Just found some topics on the forum, for the same. Looking into that, at the moment.
<zyga> ah
<zyga> so the plot thickens
<zyga> the snap userd binary is not started by the dbus session bus now (obviously now that I think about it)
<zyga> but by systemd
<zyga> so I never hit my debug builds
<zyga> so now I really want to know where those generated units are
<zyga> or how do I edit my systemd-stared session bus to contain information about my verbose build
<zyga> mvo: ^ ideas welocme
<zyga> *welcome
<steph250> Trying to see the tutorials... So, starting from "snapcraft init" and ... it fails :-)
<zyga> steph250: what's your environment?
<zyga> where do you run snapcraft?
<brunosfer> zyga: It's to make software for core devices.
<zyga> ideally that would be ubuntu 16.04
<mvo> zyga: snapd userd is auto-started via /usr/share/dbus-1/services
<mvo> zyga: once it is used
<zyga> brunosfer: then don't bother, get another pi (e.g. pi3 if you had a pi2 before)
<brunosfer> ogra: but if the DragonBoard 410C is already discontinued, doesn't make much sense to buy it...
<zyga> mvo: thanks let me look at that
<mvo> zyga: so maybe that is something that in bionic system took over (is that what you are saying)?
<steph250> freshly installed Raspberry with Jessie
<ogra> brunosfer, well, we dont have any other board like this in the supported set atm
<zyga> mvo: I'm saying that systemd now starts that
<ogra> i.e. arm64 based
<zyga> mvo: it doesn't let the session auto start anymore
<brunosfer> zyga: my idea is to get a new architecture for testing. I already have the whole Pi family. But I would have to make sure the board I buy supports ubuntu core to deploy the snap I'm building
<zyga> it's not handled by systemd directly (AFAIR, I read about that a while ago)
<ogra> (though arm64 for embedded is the worst idea anyway... you really want to run armhf on these)
<zyga> brunosfer: I see, then getting a dragon is probably the "best" way because it's supported
<brunosfer> ogra: Yeah, maybe I'll check the Artik
<zyga> brunosfer: I have one but it's not a fantastic board IMO
<zyga> mvo: now I wonder how to coerce systemd to talk to my session bus
<ogra> zyga, !
<brunosfer> zyga: Yeah, I ordered one some time ago, however, never got it due to be discontinued...
<zyga> mvo: I may switch to that workaround session bus
<zyga> script that seb128 suggested
<ogra> the dragonboard is a fantastic arm64 board :)
<brunosfer> zyga: But I was looking to DragonBoard 410C exactly because canonical has an official image.
<mvo> zyga: systemd starts a user process afaik when you login
<zyga> ogra: no etherhet, no sata (with hrw voice), hardcoded ram split for gpu
<mvo> zyga: so systemd --user iirc
<zyga> ogra: I'd rather have 4GB RAM and ethernet
<mvo> zyga: and its per user, not per session
<zyga> oh? per user
<zyga> mvo: I'll copy the debug shell hack and
<zyga> mvo: and reboot
<mvo> zyga: I thnk so, iirc there is no systemd login session support
<zyga> mvo: I wanted to just redirect how snap userd is activated
<zyga> mvo: I feel I don't get how that really works now
<diddledan> if you want to change things that are defined in the service then surely you can `systemctl edit snap-userd` or whatever the unit is called?
<diddledan> the usual place for system-level definitions for services is at /lib/systemd/system
<zyga> diddledan: even for user session services?
<zyga> diddledan: and this seems to be a generated unit from the regular dbus unit generator
 * Chipaca wanders off to poke at broken things some more
<diddledan> looks like user-level services are at /usr/lib/systemd/user
<diddledan> e.g. zeitgeist
<steph250> back ;-)
<zyga> ah
<zyga> silly me
<zyga> systemct --user
<zyga> hmm, I don't think systemctl --user really does what I think it does, I don't see any user session things
<steph250> zyga: whatever I try with "snapcraft init" on RASPBIAN, I get "OSError: Could not locate nacl lib, searched for libsodium.so, libsodium.so.13, libsodium.so.10, libsodium.so.5, libsodium.so.4,  and tweetnacl.so"
<steph250> zyga: Any idea ?
<Chipaca> steph250: raspbian?
<Chipaca> isn't that arm6?
<steph250> PI-2, yes
 * kalikiana wrapping up for today
<Chipaca> I don't think we support raspbian
<ogra> Chipaca, arm6 != ARMv6 :)
<ogra> (we dont support either though)
<Chipaca> ogra: should I have said "isn't that ARMv6"?
<ogra> yeh
<ogra> *yeah
<Chipaca> ogra: i mean, it's armel
<Chipaca> we don't support armel, we support armhf
<Chipaca> so we support the pi 2, but not with raspbian because all the binaries are icky or something
<Chipaca> :-)
<zyga> steph250: that's not supported
 * Chipaca tries again to wander off to fix things
<ogra> arm6 is actually ARMv3
<steph250> I guessed, yes ...
<ogra> from around 1991 :)
 * zyga shakes fist at dbus
<zyga> I'll get to the bottom of this bug
<ogra> nobody supports that anymore ... not even armel
<steph250> so, no way to use SNAPS on raspberry PI2 ?
<ogra> steph250, ??
<ogra> http://cdimage.ubuntu.com/ubuntu-core/xenial/daily-preinstalled/current/
<ogra> there are pi2 ubuntu-core images
<zyga> steph250: note that raspberry pi 2 can run more modern software just fine, but you cannot use raspbian
<ogra> http://cdimage.ubuntu.com/ubuntu-server/xenial/daily-preinstalled/current/
<ogra> and here are classic ubuntu-server images that should be able to run snaps
<zyga> oh boy, my dbus logs a lot
<zyga> gdm doesn't start yet tho
<steph250> not good news :-(
<zyga> steph250: sorry, we cannot do anything about that
<steph250> no issue. any idea why it's not supported ? I mean, would it be possible ?
<zyga> steph250: because raspbian uses a different ABI that is compatible with older processors
<zyga> steph250: everyone else uses the newer ABI, snapd can be added to raspbian but snaps wound't work on some machines (pi zero)
<zyga> steph250: so there's no real support for raspbian yet
<steph250> this, I saw :-)
<diddledan> ogra: oh, awesome, I didn't know there were classic variants of ubuntu available for the pi
<ogra> diddledan, only pi2 afaik
<zyga> hmm
<zyga> so
<zyga> the debug build logs but doesn't start gdm
 * zyga inspects why
<zyga> sty 15 18:36:41 kaedwen dbus-daemon[1833]: [system] Activating service name='org.freedesktop.login1' requested by ':1.22' (uid=0 pid=3317 comm="/usr/sbin/gdm3 " label="unconfined") (using servicehelper)
<zyga> why the space?!
<ogra> probably there are args it chops off before
<ogra> (and does that badly)
<zyga> sty 15 18:38:13 kaedwen dbus-daemon[1833]: [system] Activating service name='org.freedesktop.systemd1' requested by ':1.26' (uid=0 pid=3404 comm="/lib/systemd/systemd-logind " label="unconfined") (using servicehelper)
<ogra> (or there are args it shoudl be adding but doesnt and you have an empty var with a space)
<ogra> i doubt that would make it fail though
<zyga> hmm mhmmm
<zyga> it's my hack with a shell script that execs the real thing
<zyga> but I don't see how
<zyga> this is what it does:
<zyga> exec /usr/lib/dbus-1.0/debug-build/bin/dbus-daemon "$@"
<diddledan> if $@ is empty then it'll send a string as the first argument with no content
<ogra> yeah
<diddledan> ie. empty string, not "no argument"
<zyga> oooh?
<zyga> shit
<zyga> shoud I use "$*" instead?
<zyga> I thought "$@" what the "right" way to do things
<diddledan> when $@ has nothing inside it, then "$@" will evaluate to "" which in bash will evaluate to an argument of zero length
<diddledan> that is it WILL be an argument
<zyga> man
<zyga> bash sucks
<zyga> shell sucks
<zyga> thank you for teaching me
<diddledan> so if you did `foo ""` then $1 in foo will exist, but be empty. it isn't the same as `foo` where $1 will not exist
<zyga> sure
<zyga> this is why it failed
<diddledan> bit silly really, you're right
<diddledan> it's a  legacy thing I guess
<diddledan> "why does it do this thing?" .. "because it always did the thing" .. "should we change it to make sense?" .. "no, because that's how it is done"
<zyga> diddledan: yes, that's true :)
<diddledan> I guess sometimes legacy can bite :-p
<zyga> 2251 "aliens to humans: why is $@ expaning to an empty string"
<zyga> ...
 * zyga wishes for FCKSH
<zyga> fricking sensible shell
<diddledan> lol
<diddledan> the "sh" is silent, and the "fck" is said like the popular swear
<diddledan> "I'm having trouble will my bash script" .. "just fck it, instead"
<zyga> hahaha
<mup> PR snapcraft#1872 closed: adding option to decompress tar.lzma cleanly <Created by heesen3> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1872>
<cjwatson> diddledan: no, that's wrong - "$@" has magic behaviour and does not expand to a single empty argument in the case of zero arguments
<zyga> ok, my hack boots now
<zyga> cjwatson: ah, so maybe my memory wasn't broken
<zyga> still, my ssystem is trying to start gdm, failing
<cjwatson> zyga: maybe the problem is at the next layer up
<zyga> cjwatson: it's speed, dbus is so slow now that things time out :-(
<cjwatson> chapter and verse from bash(1):
<cjwatson>               When there are no positional parameters, "$@" and $@ expand to
<cjwatson>               nothing (i.e., they are removed).
<diddledan> well that's even more weird legacy then :-p
<zyga> so I _was_ right to use "$@"
<zyga> at least I wasn't crazy that I thought it is special somehow
<cjwatson> yes, it is the right thing in that sort of wrapper
<zyga> hmm
<diddledan> "if a variable is empty, does it leave a string?" .. "yes. except when it doesn't"
<cjwatson> "$@" is the single exception
<zyga> ok
<zyga> so I have a hack workaround :)
<zyga> I booted gdm without debug
<zyga> now I can switch on debugging for the session where I log in
<zyga> woot
<diddledan> \o/
<zyga> and I'm logged in
<zyga> woooot
<zyga> ok, let's reproduce the bug now
<diddledan> now to actually do the debug
<diddledan> "my debug didn't work." .. "did you debug your debug?"
<davidcalle> kyrofa: fyi, just landed https://docs.snapcraft.io/build-snaps/syntax
<zyga> mm
<zyga> sty 15 19:04:56 kaedwen systemd-journald[273]: Forwarding to syslog missed 817 messages.
<zyga> how can I make journal not do that and instead give me the real thing
<diddledan> davidcalle: for the `version` docs you need to point out that a numeric-only value is incorrect UNLESS it is wrapped in quotes
<jdstrand> zyga: the kernel should only be mediating the unix socket. it won't get in the way of dbus rules because it isn't looking at them. if activation isn't sorking, it must be in dbus-daemon
<diddledan> i.e. `version: 1.0` is illegal
<zyga> jdstrand: yes, I think it's the new dbus + the ubuntu-only patch that broke it
<diddledan> `version: '1.0'` is correct
<jdstrand> zyga: journald also shouldn't be missing messages, it is the messages going to syslog that it may be dropping (aiui). I suggest journalctl --follow | grep DEN on newer release
<jdstrand> I see too much getting dropped in /var/log/syslog :\
<zyga> jdstrand: http://paste.ubuntu.com/26393153/
<zyga> this is the full-so-far log from when I try to use xdg-open
<diddledan> davidcalle: `assumes` says that it takes a list but doesn't tell where to find the valid values for that list.
 * zyga tries to get a better log
<jdstrand> zyga: I suspect the lack of peer_label in the log is a clue
<jdstrand> zyga: note that dbus is the thing logging
<zyga> https://paste.ubuntu.com/26393163/
<zyga> this is a better one
<jdstrand> if I were looking at this, I would take a look at those <null> entries in the log
<zyga> thanks, I'll look now
<zyga> I can build and iterate on this now
<jdstrand> sty 15 19:10:15 kaedwen dbus-daemon[2413]: 2413: 0x7f86619c78c0: 1516039815.743271 [bus/activation.c(1803):bus_activation_activate_service] activation not authorized: org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.74" (uid=1000 pid=4280 comm="dbus-send --print-reply --session --dest=io.snapcr" label="snap.gimp.gimp (enforce)") interface="io.
<jdstrand> I don't *know* that the null is meaningful. I do know that the lack of peer_label is definitely wrong
<jdstrand> since the rule specifies a peer label, if dbus-daemon doesn't find it correctly, that would suggest why it might not match
<jdstrand> zyga ^
<zyga> jdstrand: yes
<zyga> jdstrand: this also matches mvo's experiments where removing peer label requirement "fixed it"
 * jdstrand nods
<jdstrand> removing it would mean match any peer
<zyga> jdstrand: yep
<zyga> next up, dive into dbus
<zyga> but first
<zyga> does anyone know Jeremy Bicha
<zyga> he made the last upload with the new apparmor patch
<jdstrand> zyga: he participates on the desktop. see #ubuntu-desktop
<jdstrand> zyga: while Tyler is quite busy with sprint and kernel updates, he did a bunch of the dbus work (he upstreamed it), so he could be a resource (perhaps next week?)
<zyga> jdstrand: thank you! that's a nice idea
<zyga> jdstrand: hmm :)
<zyga> From: Tyler Hicks <tyhicks@canonical.com>
<zyga> the patch is from tyler
<zyga> I should have spotted that a long time ago
<zyga> my bet is that that patch doesn't work
<zyga> or isn't applied (I'll check but I'd be suprirsed)
<zyga> so maybe getly ask tyler if it works on his bionic :)
<zyga> I'll get something to drink and get back to digging
<jdstrand> possible. also possible is  libapparmor change. I'm just guessing at this point since I haven't looked at any of this
<davidcalle> diddledan: thanks for the feedback, it's mostly a layout update, content fixes on their way
<zyga> jdstrand: I'll look at changelogs
<jdstrand> iirc, the patch doesn't have to do with peer labeling, but closing a hole wrt dbus snooping
<jdstrand> I guess I could pull down the package...
<zyga> hmm, are you sure?
<zyga> Allows the AppArmor label that is attached to a D-Bus connection to be
<zyga> queried using the unique connection name.
<zyga> that's the patch description ^
<zyga> I also added it to the forum
<jdstrand> oh, well, that certainly seems on point. maybe it doesn't need to be applied or needs to be applied differently
<zyga> jdstrand: no worries, I'm just broadcasting my progress
<zyga> jdstrand: I'll look at what's going on there, I never touched dbus guts before
<zyga> but first, something to drink
<jdstrand> zyga: I'm betting something changed with how it determines the label of a non-activated service
<jdstrand> (since it isn't running yet)
<jdstrand> anyhoo
<jdstrand> zyga: good luck! :)
<zyga> mmm, good idea
<zyga> thanks, just looking at call graph
<zyga> ok, back
<zyga> shower should help to attack this problem :)
<zyga> so I see where the peer label is set
<zyga> I'll debug there
<zyga> seems like the only place that can go wrong
<zyga> (or that this code is now unused due to other changes0
<cachio> zyga, there?
<cachio> zyga, in file cmd/snap-mgmt/snap-mgmt-sh-in, "@SNAP_MOUNT_DIR@" is /snap for fedora
<cachio> zyga, sorry, for opensuse
<cachio> zyga, is it ok, right?
<NateGraham> Hello Snappers! I'm a KDE developer working on Discover, our softwar center, and I'm trying to improve Snap support. I'm hoping someone can help me debug an issue on my test system
<NateGraham> When I try to install a snap, I get an error on the console:
<NateGraham> (process:1984): Snapd-CRITICAL **: snapd_client_install_stream_finish: assertion 'request->request_type == SNAPD_REQUEST_INSTALL_STREAM' failed
<NateGraham> the distro is KDE Neon, which is based on Ubuntu 16.04
<NateGraham> @Riddell! Do you know if Snap is expected to work in KDE Neon?
<Riddell> NateGraham: well yes but it gets precious little testing so thanks for looking at it
<Riddell> NateGraham: do you have snapd installed and kde-frameworks snap installed?
<NateGraham> let me see
<NateGraham> I definitely have snapd installed; what's the package name for the framework though?
<zyga> cachio: yes
<zyga> cachio: yes, it's /snap for opensuse
<zyga> NateGraham: hello!
<cachio> zyga, tx
<NateGraham> Hello
<zyga> NateGraham: do you know what happens under the hood there? what kind of request flies to snapd?
<zyga> I
<NateGraham> I haven't a clue; I'm new to Snap
<zyga> I'm a snapd developer though you probably want to talk to Chipaca about that particular problem
<zyga> NateGraham: which API are you using to talk to snapd?
<NateGraham> if you'd like, I can try to focus on a CLI test case so we can nail it down
<zyga> NateGraham: that's okay, eventually all APIs talk to snapd over a socket, there's one real API internally
<zyga> NateGraham: though for gnome-software there's extra work on authentication
<zyga> NateGraham: and there's some polkit around that as well, but I think transparently and internally in snapd
<NateGraham> we're using snapd-glib
<zyga> NateGraham: that's great
<zyga> it talks to the socket under the hood so you should be good
<Riddell> NateGraham: kde-frameworks-5 snap needs to be installed  before any Neon snaps will work
<zyga> Riddell: snapd doesn't yet handle that AFAIK but this functionality is coming via the default provider work that mvo is doing
<Riddell> zyga: right, that's why it needs to be installed first
<zyga> (so eventually this fact will be handled internally)
<Riddell> which should be the case with a KDE neon install
<zyga> right
<NateGraham> RIddell: are you sure that's the package name?
<zyga> NateGraham: you can manually try if it works "snap install kde-frameworks-5"
<Riddell> NateGraham: yep, I have..
<Riddell> Name              Version  Rev   Developer  Notes
<Riddell> core                       3748  canonical  broken
<Riddell> kde-frameworks-5           13    kde        broken
<zyga> broken?
<zyga> that looks bad
<zyga> hmm
<NateGraham> oh oh course, this is a snap package, not an apt package, pardon my ignorance
<NateGraham> it is indeed already installed
<zyga> NateGraham: I'm worried by those broken notes
<NateGraham> that's on Riddell's system, not mine :)
<NateGraham> though of course mine may be broken, too
<zyga> NateGraham: can you pastebin logs from snapd.service please?
<Riddell> I was fiddling around with them earlier to fix my plasma screenshots which I guess broke them
<zyga> ah
<zyga> so they are not generally broken
<zyga> having broken core is definitely a problem for installing snaps
<zyga> so if you can get that in order you may have more luck
<Riddell> I mounted the snaps manually and I guess it didn't like that
<NateGraham> https://pastebin.com/a9X5kjBC
<Riddell> unmounted rather
<zyga> otherwise I'm happy to help but I was on my way out already, maybe Chipaca is still up (though also past EOD today)
<zyga> Riddell: if you mount it does snap list show it as non-broken?
<Riddell> zyga: I don't know how to mount them again
<Riddell> I am destroyer of snapd
<zyga> Riddell: just start the systemd mount unit
<zyga> (for that particular snap and revision)
<Riddell> zyga: well a reboot started my issue, but I still can't get my snaps to work
<Riddell> oh hoorah found one which does run, falkon
<Riddell> but mm plasma-discover integration not happy
<Riddell> NateGraham: so aye maybe snaps not in a great shape just now I'm afraid :(
<Riddell> NateGraham: at least in kde neon dev unstable that I have plasma discover just loads forever when I search for say falkon and doesn't list the snaps
 * Riddell out
<NateGraham> do you have the snap backend installed?
<NateGraham> compiled from git master, that part works for me, at least
<seb128> zyga, thanks for the work on debugging that dbus issue, let me know if we can help
<zyga> seb128: I took a break to spend time with family but I think I have a clue to follow now, just need to try a few extra prints
<seb128> zyga, that commit seems new in  the updated version, https://cgit.freedesktop.org/dbus/dbus/commit/?h=dbus-1.12&id=dc25979eb
<seb128> from the description might have to do with the topic?
<seb128> "If the .service file contains AssumedAppArmorLabel=/foo/bar then we will do the AppArmor query on the assumption that the recipient AppArmor label will be as stated. Otherwise, we will do a query with an unspecified label, which means that AppArmor rules that do specify a peer label will never match it."
<zyga> yes, looks new and interestingly contains
<zyga> +  if (dst_con != NULL)
<zyga> +    {
<zyga> +      dst_label = dst_con->label;
<zyga> so ... maybe :)
<seb128> jdstrand, ^
<zyga> I will definitely try that (but watching new startrek with wife now :)
<zyga> bbl :)
<seb128> zyga, enjoy!
<mwhudson> cleanbuild with snapcraft tip or near tip is failing for me
<mwhudson> error: open /var/lib/snapd/hostfs/home/mwhudson/snap/lxd/common/snapcraft2c0cyxw6/core_3748.assert: no such file or directory
<mwhudson> (building a classic snap, if that matters)
<Chipaca> I wasn't here, but I am here now. Can I still help?
<Chipaca> if no reply in a minute, I shall take the dog for a walk.
<Chipaca> ok two minutes
<mwhudson> cleanbuild with snapcraft tip *built as a snap* is failing for me
<zyga> mwhudson: hey
<zyga> mwhudson: do you think you would have some time to update snapd in debian?
<zyga> mwhudson: it seems people still have issues with apparmor there
<mwhudson> zyga: there is a new one in sid
<mwhudson> zyga: would be interesting to know if it works at all :-)
<zyga> mwhudson: thank you for letting me know, I will try it and reply to the people on the forum
<mwhudson> hmm why can i not install the new snapd in this vm
 * zyga pulls in 200MB of sid updates
<mwhudson> uh no really why
<zyga> what's wrong?
<mwhudson> 2.30-3 is in the pool but not the indices
<zyga> that's ... odd
<mwhudson> oh wait
<zyga> some migration script didn't publish it?
<mwhudson> no only the dsc is in the pool, the debs are not
<mwhudson> maybe i'm about to learn something about debian
<mwhudson> ah yeah look https://buildd.debian.org/status/package.php?p=snapd <- uploaded, not installed
<zyga> mips -- build attempted
<mwhudson> yea but they've never built
<zyga> mwhudson: do we have more arch blacklisting to do?
<mwhudson> and i didn't  think failed builds prevented publication to unstable
<zyga> mwhudson: so is it just pending publishing or do you need to do another upload with some arches disabled?
<zyga> curious, I updated apt and then apt found way more updates
<zyga> meh, time to sleep
<zyga> ttyl
<mwhudson> zyga: i don't know
#snappy 2018-01-16
<mborzecki> morning
<tyhicks> zyga: hey - I just saw that you were debugging a dbus apparmor query bug
<tyhicks> zyga: did you get to the bottom of it?
<tyhicks> (I see the dc25979eb commit)
<mup> Bug #1743504 opened: Ubuntu 16.04 snapd service not working <Snappy:New> <https://launchpad.net/bugs/1743504>
<mup> PR snapd#4489 opened: vendor: remove x/sys/unix to fix builds on arm64 and powerpc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4489>
<mborzecki> mvo: morning
<zyga> good morning
<zyga> I'll get some coffee and will be back shortly :)
<mborzecki> zyga: hey
<mborzecki> have you guys seen this? https://forum.snapcraft.io/t/ubuntu-16-04-snapd-fail-to-start/3529
<zyga> mborzecki: looking
<mvo> hey mborzecki ! good morning
<mvo> and good morning zyga
<zyga> looks like #include maybe (vs include)
<zyga> but not sure
<zyga> mvo: hey!
<zyga> -> coffee
<mborzecki> zyga: apparmor thing?
<zyga> yes, we delt with this in the past, that's the only thing that I can recall having an '#' issue
<zyga> but
<zyga> this is not a guarantee this is it
<jdstrand> that error is talking about the '#' being a problem
<jdstrand> the issue you were thinking of was a missing '#'
<zyga> indeed
<zyga> hey jdstrand :)
<jdstrand> hey
<zyga> I'm not used to you being in the same timezone
<zyga> how was day one? :)
<jdstrand> but regardless, snapd was not affected by the '#' or lack of '#', it was the apparmor python tools. I think this is unrelated to all that
<jdstrand> day one went fine
<zyga> ah, indeed, I think you are right
<mvo> zyga, mborzecki doing a "grep -r" for the error message in vendor/ and /usr/share/go-1.8/src indicates its a json decode error, so probably corrupted state.json
<mvo> mborzecki: (as you already guessed :)
<jdstrand> no time to do any engineering really. lots of meetings, lots of interrupts when I thought I had time to do something
<jdstrand> typical sprint :)
<jdstrand> zyga: ftr, I have a slew of PRs scheduled for review. just need time to focus on them. they will be at the top of my list next week if I can't get to them this week (and I don't expect I can)
<mborzecki> mvo: makes me wonder, unless hand edited, how would # end up in state.json?
<zyga> jdstrand: ack
<mvo> mborzecki: yeah, a good question, we would need the state.json to inspect, might be a bit flip, once you have enough users this will happen (we saw that with e.g. the dpkg/apt database frequently). or a corrupted hdd like zyga  had earlier. hard to say (or of course our fault somewhere in our state saving code)
<mborzecki> it's not part of the pacakge right? so there's no chance of state.json getting updated as part of package upgrade?
<zyga> jdstrand: how's the weather like?
<jdstrand> zyga: beautiful
<zyga> mborzecki: or if you remember my crazy hdd yesterday, may be the xml profile in place of json :)
<zyga> mborzecki: on my disk the dpkg database contains random files
<jdstrand> zyga: sounds like a fun day :)
<mborzecki> zyga: yeah, that's possible too :/
<kalikiana> sliff
<pstolowski> good morning!
 * kalikiana feeling a bit under the weather this not so good morning  :-(
<mvo> mborzecki: correct
<zyga> kalikiana: ouch
<zyga> hey pstolowski
<pstolowski> kalikiana, sad to hear that.. take it easy and get well!
<zyga> mwhudson: snapd in debian is updating now
<mvo> zyga, mborzecki, pstolowski quick question - what feels more natural to you: `snap run --strace-opts="-tt" hello` or `snap run --strace="-tt" hello` ?
<zyga> mvo: the latter
<pstolowski> mvo, the latter
<mvo> (the former could also be written as `snap run --strace --strace-opts="-tt"  `
<mvo> ok - cool, I look at it
<mvo> thanks for your feedback
<zyga> great, thanks for asking :)
<zyga> snapd is now at 2.30-4 in sid :)
<zyga> mwhudson: thank you for pushing that!
<mborzecki> mvo: yup, the latter
<mvo> mborzecki: ta!
<mborzecki> mvo: btw. it'd also be a nice feature to be able to disable filtering out of pre snap-exec starce output
<zyga> mvo: does the method to run strace scale to things like gdb?
<mup> PR snapcraft#1869 closed: cli: exported login should only be readable by owner <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1869>
<mvo> mborzecki: interessting idea
<zyga> mvo: though gdb is also more complex because od symbols
<pstolowski> and valgrind? ;)
<zyga> hmm
<zyga> I need to reboot my laptop
<mvo> zyga: for gdb one would have to automatically set a breakpoint at "execve("the-snap-app")" and then run it
<zyga> it goes crazy after suspend and all the textures blink
<pstolowski> just kidding, valgrind is tricky for many reasons I suppose.. just gdb would be cool
<zyga> brb
<mup> PR snapd#4490 opened: tests/main/snap-service-after-before: add test for after/before service ordering <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4490>
<zyga> hmmm
<zyga> I think I need to power it off
<zyga> it's still wonky
<zyga> and wifi is wonky  too
<mborzecki> the year of linux desktop :P
 * zyga looks for debian topics on the forum
<mup> PR snapd#4491 opened: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4491>
<mvo> kalikiana: hey, iirc you had some suggestion for `snap refresh --amend`, a better term. now is a good time to add them to 4356 as samuele also expressed that its not super clear to him
<zyga> mvo: I didn't like amed too
<zyga> mvo: I proposed one alternative on the forum but I forgot what it was
<pedronis> mvo: IÂ could think:  --reestablish  otherwise I thing we need more than one word with store in it somehow
<pedronis> *I think
<mvo> pedronis: I like --reestablish - feel free to add to the PR. I'm addressing your comments now fwiw
<pedronis> mvo: and we have other plans for "replace"
<pedronis> that might happen or not, but IÂ don't think we want to use that
<kalikiana> pedronis, mvo: I commented on the PR https://github.com/snapcore/snapd/pull/4356#discussion_r160633033
<mup> PR #4356: many: add new `snap refresh --amend <snap>` command <Created by mvo5> <https://github.com/snapcore/snapd/pull/4356>
 * kalikiana getting more tea, with an extra slice of lemon
<pedronis> mvo: put a rambling there about this
<mvo> ta
<zyga> snapd 2.30 on debian sid works well, spotify, gimp and brave tested
<mvo> yay
<mborzecki> mvo: will the strace PR will work with classic snaps too?
<zyga> mborzecki: classic snaps don't need anything for strace
<zyga> though it'd be nice if they also worked with the same U
<zyga> \UI
<mborzecki> what i meant if you do `snap run --starce <some-classic-snap>` will it work too?
<zyga> right
<zyga> I don't know :)
<mvo> mborzecki, zyga: do we run snap-confine on classic snaps at all? iirc we do and if so strace should work
<mwhudson> zyga: np, does it work? :)
<zyga> mwhudson: yes
<mwhudson> oh good
<zyga> mwhudson: with apparmor enabled
<zyga> so good work :-)
<mborzecki> mvo: tried `snap run --strace` with a classic snap just now, works fine :)
<mwhudson> i should send some of the changes your way
<mvo> mborzecki: \o/
<mwhudson> the "arch all only builds fail" thing would happen with ubuntu packaging too i'm fairly sure
<mborzecki> mvo: https://paste.ubuntu.com/26396653/ the default value for --strace in --help is a bit confusing, i think you need to add `default-mask:""` or something similar
<mvo> mborzecki: aha, good point. quirks with the go-flags
<mvo> mborzecki: thanks, let me fix this
<mvo> mborzecki: there is a failure in 4490 on 14.04 that looks vaguely ral
<mvo> real
<Chipaca> good morning peeps
<mvo> Chipaca: hey, good morning!
<Chipaca> just popping in to let you know (because I completely forgot yesterday)
<mborzecki> mvo: thanks, looks like the formatting changed between systemd versions :/
<Chipaca> that i've got two long parent meetings at the school today, so i've taken half a day off
<mborzecki> Chipaca: morning
<mvo> mborzecki: :(
<zyga> hey there john!
<Chipaca> so, hello and goodbye :-)
<zyga> mborzecki: oh, "fun"
<mvo> Chipaca: sure - when you have a moment 4489 is an easy win
<zyga> how can projects do that :/
<mvo> or someone else :)
<Chipaca> mvo: ack
<Chipaca> mvo: reach me on telegram if you need me though
<mborzecki> zyga: systemctl --porcelain :)
<zyga> mvo: did you see http://travis.debian.net/ ? :)
<zyga> would be cool to have instructions like that for snapcraft
<mvo> zyga: might cool
<mvo> mborzecki: you mentioned you would be interested in havng "snap run --strace" not hide anything (so include the snap-confine traces). do you think a environment options is appropriate? or an extra option to `snap run --strace-it-all` or something?
<mborzecki> mvo: enabling it via environment sounds good to me, SNAP_STRACE_EARLY=1 or something similar
<mwhudson> zyga: what's the motivation for wanting to update snapd in stretch?
<mwhudson> the version released with stretch re-execs i think...
<zyga> mwhudson: yes, thought I don't know if that enables all the features
<zyga> mwhudson: it would be a nice thing to update it
<zyga> mwhudson: flapak gets the updates, for example
<mwhudson> oh ok
<mwhudson> zyga: looks like the newest flatpak is only in backports?
<mwhudson> which would be an easier thing to do i guess
<zyga> mwhudson: yes, that's a good thing IMO
<mup> PR snapd#4492 opened: spread: try to enable Fedora once again <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>
<zyga> mvo: can you please try to review https://github.com/snapcore/snapd/pull/4471  today?
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
 * zyga cannot stop laughing 
<zyga> https://twitter.com/Lilobase/status/952504781515509761
<mup> PR snapd#4489 closed: vendor: remove x/sys/unix to fix builds on arm64 and powerpc <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4489>
<mup> PR snapd#4482 closed: cmd/libsnap-confine-private: add debug build of libsnap-confine-private.a, link it into snap-confine-debug <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4482>
<mvo> mborzecki: 4483 has feedback - seems super close to handling
<mvo> zyga: sure, going over the open PRs now
<mborzecki> mvo: thanks for the reviews
<zyga> thank you! :)
<mvo> mborzecki: the failure in bboozzoo/snap-mgmt-extend-tests is very strange, could you please merge master and see if it persists? does not make much sense to me (spread failure in go unit tests on 14.04)
<mborzecki> mvo: i'll be pushing more commits in a while and i'll merge master as well
<mvo> mborzecki: ta
<mborzecki> mvo: i'll have to open a follow-up pr anyway, for now i only merged master and pushed to #4480
<mup> PR #4480: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4480>
<pedronis> mvo: so far we implemented   Type=notify for snapd but no the watchdog stuff, right?
<mborzecki> fedora currently fails with: 'No package golang(github.com/Thomasdezeeuw/ini) available.', any ideas?
<zyga> that's a new dependency
<zyga> we need to package it apparently
 * kalikiana taking a break, not feeling awesome at all
<Alexander_> Bumping into some problems with using iptables on ubuntu core. I have been trying to put in some dnat rules and they have not be working at all. Tcpdump is showing the packets going to the host machine. Any thoughts?
<zyga> Alexander_: hmm, are the right modules loaded?
<mborzecki> from a quick survey, github.com/go-ini/ini seems to be avialble in fedora/ubuntu/debian
<mborzecki> and this one too github.com/vaughan0/go-ini
<Alexander_> zyga: I do not know, I have just been call iptables from command line in normal userspace and the "classic" space. How could I find out?
<zyga> Alexander_: lsmod may tell you that
<zyga> mborzecki: maybe it's just a missing dep then, low hanging fruit to add
<mborzecki> zyga: you mean replace github.com/Thomasdezeeuw/ini with one of the 2 i listed above?
<zyga> mborzecki: ah
<zyga> sorry I misread
<zyga> I think go-ini is the one that pedronis was unhappy about
<zyga> but if that's not the case and we could use that then yes, that's a quick win
<Alexander_> $ lsmod | grep ip
<Alexander_>  gives me
<Alexander_> iptable_filter  ip_tables ip6table_filter ip6_tables x_tables
<Alexander_> I assume ip_tables is the support for iptables?
<pedronis> zyga: mborzecki: mvo proposed to use our old goconfigparser, that should have been packaged already too
<mborzecki> pedronis: is it in the tree now?
<pedronis> mborzecki: no, it's on github though
<pedronis> probably best to wait for mvo to decide what to do
<mborzecki> ok
<zyga> hmm
<zyga> I'm learning more aboud dbus the hard wy
<zyga> way*
<mvo> pedronis, zyga either way is fine with me, if we decide on the old parser I'm happy to look into the porting
<pedronis> mvo: I think I would prefer the old parser  over go-ini
<mvo> pedronis: works for me, I will look into the porting (unless you want to do it)
<ikey> dbus is the debil
<zyga> ikey: debil?
<ikey> devil.
<zyga> ah :D
<zyga> in polish debil has another meaning and I was now wondering if that's an english word as well
<ikey> ah ok
<ikey> waterboy reference :P
<zyga> https://translate.google.com/#pl/en/debil ;-)
<ikey> hah nice
<ikey> that works too
<mvo> pedronis: heh, fun! goconfigparser is even part of the vendoring still as we use it in one of our tests
<pedronis> mvo: yes, I see
<mvo> pedronis: fwiw, I addressed the points in 4356
<mborzecki> don't remember the details of fedora policy on go packages, but if it's under vendor then there musn't there be a real package with that dep too?
<zyga> mborzecki: it depends on where it is, it needs to be marked as an embedded package, in some places it's embedded (centos) and in some places it's not (fedora)
<zyga> mborzecki: that's what I remember, I'm sure Pharaoh_Atem can correct me if I'm wrong
<mborzecki> zyga: i think https://github.com/snapcore/snapd/blob/master/dirs/dirs.go#L234 is causing https://bugs.launchpad.net/snappy/+bug/1743301 korora is derived from fedora and apaprently it's picking the wrong libexedir
<mup> Bug #1743301: cannot install apps using snap on Korora <Snappy:New> <https://launchpad.net/bugs/1743301>
<mvo> pedronis: I pushed a PR and have lunch now. wonder if I should add more unit tests for the error cases? or do you think its sufficient?
<mup> PR snapd#4493 opened: image: port ini handling to goconfigparser <Created by mvo5> <https://github.com/snapcore/snapd/pull/4493>
<mborzecki> zyga: we should do release.DistroLike() probably
<mborzecki> zyga: do you know what os-relase looks like on rhel and cetos?
<pedronis> mvo: I think the error handling is easy enough to follow
<pedronis> mvo: pushed couple of comments
<zyga> mborzecki: looking
<zyga> mborzecki: yep
<zyga> mborzecki: sure
<zyga> mborzecki: one sec...
<zyga> https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt
<zyga> https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt
<zyga> :-)
<zyga> enjoy! and add anything you find missing please
<mborzecki> zyga: hah, thanks
 * zyga still fights dbus
<mborzecki> zyga: url open thing?
<zyga> mborzecki: hmm?
<zyga> mborzecki: ah, yes
<zyga> but in reality dbus bug
<mborzecki> interesting, does it warrant a blog post? :)
<zyga> mborzecki: ha, I can write about that though it's pretty obscure and I haven't fixed it yet
 * pstolowski lunch
<zyga> hey there neal!
<mborzecki> zyga: https://github.com/zyga/os-release-zoo/pull/26
<mup> PR zyga/os-release-zoo#26: korora: add Korora 26 <Created by bboozzoo> <https://github.com/zyga/os-release-zoo/pull/26>
<zyga> merged
<zyga> thank you
<zyga> man
<zyga> building dbus sucks, it's hediously complex
<zyga> I ended up rebuilding the package
<zyga> I have no idea how things get configured apart from 'by magic' there
<mup> PR snapd#4494 opened: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4494>
 * Chipaca is back but really exhausted from the meetings
<zyga> joining
<niemeyer> Speaking of which, I won't join you today
<zyga> niemeyer: thanks for the heads up!
<ondra> ogra ping
<ogra> ondra, yo
<mup> PR snapd#4307 closed: tests: fix "job canceled" issue and improve cleanup for snaps <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4307>
<zyga> pstolowski: sudo snap debug get-base-declaration
<pstolowski> zyga, thanks!
 * Chipaca hugs niemeyer 
<pedronis> pstolowski: do you have a pointer to a place where we iterate of attrs (not constraints)
<pstolowski> pedronis, 1 sec
<JonelethIrenicus> what do I have multiple snappy cores?
<Chipaca> JonelethIrenicus: pardon?
<JonelethIrenicus> if I open up something like firelight I see mutliple snappy core "disks"
<JonelethIrenicus> old versions
<JonelethIrenicus> /snap/core/3604
<JonelethIrenicus> /snap/core/3748
<JonelethIrenicus> etc..
<ogra> for rollback
<mup> PR snapcraft#1873 opened: elf: cleaner patchelf experience <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1873>
<zyga> JonelethIrenicus: those are multiple revisions of one snap
<zyga> JonelethIrenicus: snapd maintains up to three revisions per snap
<zyga> JonelethIrenicus: they get recycled automatically
<ogra> on classic you always need to have two ... on ubuntu-core you need three (two for rollback, one for factory reset)
<JonelethIrenicus> i see
<ogra> (i think snapd doesnt make any difference between core and classic on that level currently, so you will end up with three on classic too ... )
<mvo> pedronis: I updated the ini pr and addressed your feedback (thanks again for this)
<Chipaca> JonelethIrenicus: you can remove them if you need to via "snap remove --revision=<rev#> <snapname>"
<JonelethIrenicus> Chipaca: good tip thanks
<Chipaca> JonelethIrenicus: if you try to remove the current one it'll tell you to behave :-)
<JonelethIrenicus> haha well that is never going to happen
<pedronis> mvo: looks good, you miss a bundled(...) in one of those packaging lines though
<mvo> pedronis: uh, thanks. silly copy/paste
<pstolowski> pedronis, hmm I think I was wrong and confused the loop over constraints with looping over attributes
<mborzecki> does snapcraft need to know about after/before properties in apps now that the systemd after/before ordering is merged?
<pedronis> pstolowski: IÂ suppose better this way, but that's what IÂ wondered, because IÂ don't remember code like that (but it was a long time ago)
<pstolowski> pedronis, yes, that solves half of the problems
<zyga> lunch is soon, let's do one more test
<mvo> mborzecki: one question about 4494> did you check that rhel and centos have a DISTRO_LIKE=fedora ? i.e. that we won't regress on those?
<mup> PR snapd#4494 closed: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4494>
<mborzecki> mvo: i checked in zyga's os-release-zoo https://github.com/zyga/os-release-zoo/blob/master/redhat/rhel7.txt https://github.com/zyga/os-release-zoo/blob/master/centos/centos-7.txt
<mvo> mborzecki: neat, thanks
<Chipaca> mborzecki: that project takes patches (e.g. korororora?)
<mborzecki> sounds kiwi'sh
<Chipaca> my dad skills have spilled into the forum! first time i've used "you (plural)" like that that i know of :-D
<Chipaca> anyhoo, work calls
<mborzecki> since korora is basically fedora, I wonder if Son_Goku could cherry-pick the patch when updating the package to 2.30
<Son_Goku> mborzecki: which patch do I need to cherry pick?
<mborzecki> Son_Goku: https://github.com/snapcore/snapd/pull/4494
<mup> PR #4494: dirs: check if distro 'is like' fedora when picking path to libexecdir <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4494>
<Son_Goku> mvo: I thought I had gotten all of these things when I attempted to fix this for Korora last time?
<Son_Goku> I swear I did...
<Son_Goku> oh, geez
<Son_Goku> there was another check for libexecdir
<mvo> Son_Goku: :/ well, I guess we now have them all!
<Son_Goku> are we really sure this time?
<Son_Goku> now even I'm not sure...
<Son_Goku> mborzecki: but yeah, I'll be cherry-picking this
<mborzecki> Son_Goku: great, thanks
<Son_Goku> mvo, could you just make sure the PR is cherry picked into the 2.30 branch?
<Son_Goku> it makes it easier for me to keep track of these things
<mvo> Son_Goku: sure
<mvo> Son_Goku: its in release/2.30 now
<Son_Goku> thanks
<Son_Goku> I'm going to be preparing the backport later today
<Son_Goku> err, upgrade
<mborzecki> mvo: since you're cherry picking to 2.30, can you also pick https://github.com/snapcore/snapd/pull/4432 ? Son_Goku left a note there, but I don't see it in release/2.30
<mup> PR #4432: cmd/snap,  tests/main/classic-confinement: fix snap-exec path when running under classic confinement <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4432>
<mvo> mborzecki: sure, looking
<mvo> mborzecki: done
<mborzecki> mvo: thanks
<Son_Goku> mvo: I just want to avoid being forced to have my own source maint tree
<Son_Goku> because in my opinion, such things are counterproductive with ensuring fixes are upstream
<Son_Goku> (it's one of the reasons I dislike the Debian/Ubuntu model of packaging with gbp trees)
<Son_Goku> today, there's exactly ONE downstream patch that's not upstream
<mvo> Son_Goku: +1
<mvo> Son_Goku: ping me anytime if you need something cherry-picked
<Son_Goku> cool, thanks
<mvo> zyga: 4483 needs a second review, iirc you looked at this before so should be trivial
<Son_Goku> God knows, I could actually do my own source trees for packaging, but I hate that stuff
<Son_Goku> it's far too easy to get lazy and complacent
<mvo> Son_Goku: plus the collaborating with upstream is usually very healthy
<Son_Goku> yeah
<mvo> (and great for upstream because they understand the needs of the packages better etc etc)
<Son_Goku> I think what really burned me was my experience with Debian as an upstream software developer
<Son_Goku> one of my software packages was effectively forked and they never bothered to talk to me
<Son_Goku> meanwhile I was listed as a contact point in the copyright, so I got weird questions from people using the Debian version
<mvo> Son_Goku: uh, that sucks - may I ask what the package name was?
<Son_Goku> lugaru / openlugaru
<Son_Goku> they'd also converted the source tree from Mercurial (as it was at the time) to Git
<Son_Goku> which meant it was painful to figure out where they actually were
<mvo> Son_Goku: uh, I see, that sounds painful
<Son_Goku> needless to say, it annoyed me
<mvo> Son_Goku: *nod*
<Son_Goku> when development of lugaru restarted, I switched to Git (as everyone else wanted it), and did significant work
<mvo> Son_Goku: I hope it got better over time
<Son_Goku> unfortunately, their little weird tree meant that they spent a year arguing about how to refork the source tree into Alioth for packaging
<Son_Goku> Debian was *the last* distribution to get the new Lugaru, and they missed the first release
<Son_Goku> I wish it wasn't common practice to fork source trees for packaging in Debian, because it seems to lead to people cheaply patching things without talking to upstream
<Son_Goku> the upstream project (that is me and a couple of others) requested that they didn't fork the tree again, and we were told to butt out :(
<Son_Goku> it's not like I don't understand how to handle the upstream/downstream relationship
<Son_Goku> but that was cold :/
<mvo> Son_Goku: :(
<mvo> Son_Goku: sorry to hear this bad experience
<Son_Goku> yeah, well, I've made a point now to avoid what I call merged source trees for packaging
<Son_Goku> I don't want to inflict that kind of mess onto someone else
<Son_Goku> mvo: that said, it's not like I don't understand why debian is evolving towards that form of packaging
<Son_Goku> debian source control is designed to be integrated with source trees, always has and always will
<Son_Goku> it's even in the name ;)
<Son_Goku> but it's one of the reasons I prefer the way RPMs are packaged, because it solidifies that split
<mborzecki> off to pick up the kids
<Son_Goku> most packaging formats impose that split (RPM Spec, Arch PKGBUILD, Solus ypkg, etc.)
<Son_Goku> and personally, I think it's a very good thing
<mvo> Son_Goku: right, well, there is a concept of orig.tar.gz in the deb sources as well. but yeah, its easy to fork
<mvo> zyga: I looked at 4471 and it seems there is some good feedback already so I am happy to have another look once this feedback is addressed
<Son_Goku> mvo, which reminds me, why aren't you just using the deb sources multi-tarball thing to deal with bundling squashfuse?
<Son_Goku> the go hack is kind of garbage, tbh, and I don't think it's worth risking making it a permanent part of snapd
<Son_Goku> it really only needs to exist for 16.04, as 18.04 could just have squashfuse declared as a proper dependency (since dist-upgrade is used for that process)
<zyga> mvo: thanks!
<zyga> mvo: looking at the earlier one as well
<mvo> Son_Goku: I need to look into this, it will make the packaging slightly more complicated, but might be worth checking. I kind of like the facts that its inside vendor/ as this is the place where we put stuff we "vendor" :) the fact that its a bit hacky around that makes me slightly sad, I need to explore if the other options are better
<Son_Goku> mvo: well my thought is that "snapfuse" is a workaround for an apt deficiency
<Son_Goku> the proper thing to do is depend on squashfuse
<mvo> it is
<Son_Goku> again, I want to avoid the risk of "snapfuse" being a mandatory dep
<Son_Goku> in Fedora, I just introduced squashfuse as a dependency and we were good to go
<tedg> cjwatson: sergiusens: Good morning, I have Inkscape master building in a "snapcraft cleanbuild" well, but it fails on the builders in a weird way. https://code.launchpad.net/~ted/+snap/inkscape-master
<tedg> I'm not sure what could be different between the two (at all), but much less that could cause something like this.
<tedg> Or frankly, what the error really is there.
<mup> PR snapd#4495 opened: data/dbus: add AssumedAppArmorLabel=unconfined t <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495>
<cjwatson> tedg: maybe cleanbuild uses a slightly different sources.list by default?
<tedg> cjwatson: Yeah, I did have to add software-proprties-common as add-apt-repository wasn't on the builders but was in cleanbuild. So there are certainly some slight differences.
<cjwatson> right, that's a difference in the default installed package set which is slightly different although conceivably also relevant
<cjwatson> tedg: my first guess would definitely be that it's something broken in ppa:ubuntu-desktop/ubuntu/gnome-3-26, although I don't know why you wouldn't see that in cleanbuild
<tedg> Hmm, and kenvandine is suspiciously not here :-)
<mvo> pedronis: did you notice that master is currently failing? it looks like it cannot install test-snapd-private
<tedg> seb128: Do you know about the gnome-3-26 backport PPA?
<seb128> tedg, what about it?
<tedg> seb128: My snap is failing to build with it, cjwatson thinks that it may be an issue with a package there. (I'm not sure what's up personally)
<seb128> tedg, Ken did recent uploads there, I guess it's not impossible that he screwed
<seb128> if your issue is in the gtkmm stack
<seb128> we didn't do recent builds afaik so I'm unsure if the ppa got tested since those uploads
<cjwatson> aha, reproduced, ish
<tedg> Yeah, and he added that at my request as it was needed to get Inkscape building.
<seb128> so you blame him but it's your fault :p
<tedg> (well, building with the new GTK)
<cjwatson> tedg: https://paste.ubuntu.com/26398323/
<tedg> Haha
 * cjwatson adds a few more packages to drill down
<pedronis> mvo: no
<mvo> pedronis: aha, nevermind
<cjwatson> https://paste.ubuntu.com/26398330/
<mvo> pedronis: I think its just a change error message, I will fix it
<mvo> pedronis: strange that we did not see it in PRs
<cjwatson> so the basic problem is a conflict somewhere in that set
<pedronis> mvo: ah
<cjwatson> libgdk-pixbuf2.0-dev Depends: libpng-dev
<mvo> pedronis: aha, of course, we only run this test against main, right? I think you told me a while ago
<tedg> Hmm, so perhaps I need to explicitly remove the older libpng?
<seb128> cjwatson, tedg, Ken is back tomorrow if he needs to fix something
<pedronis> mvo: yes,  that's because of travis security rules, secrets are set only for main repo branches
<pedronis> not PRs
<cjwatson> tedg: dropping libpng12-dev and adding gtk-update-icon-cache (I'm not sure why ...) seems to work at least in my reduced test case
<mup> PR snapd#4496 opened:  tests: update auto-refresh-private to match messages from current master <Created by mvo5> <https://github.com/snapcore/snapd/pull/4496>
<mvo> pedronis: indeed, PR on the way
<tedg> cjwatson: Thanks, I'll give those a try! (it'll take a while to get test builds done)
<elopio> hey kyrofa, should I make a PR to try one of the desktop solutions so we can discuss there?
<mup> PR snapcraft#1874 opened: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1874>
<pstolowski> hey tedg, howdy!
<tedg> Howdy pstolowski !
<diddledan> what's the mechanism for including my own plugin to build my project? I have written the pyhton script but can't get snapcraft to recognise it
<diddledan> (I modified the PythonPlugin and saved it to ./snap/plugins/foo.py)
<kyrofa> diddledan, try naming it x-foo.py
<kyrofa> Or maybe x_foo.py... now I can't remember :P
<kyrofa> Probably the latter
<diddledan> doesn't make a difference
<kyrofa> diddledan, what name are you using in the YAML?
<diddledan> oh, wait, that made it work, but doesn't list it in `snapcraft plugins`
<kyrofa> diddledan, no, those are just the built-in plugins
<kyrofa> elopio, we can chat a little in the meeting if you like
<elopio> sure
<Pharaoh_Atem> mborzecki: new deps need to be packaged for fedora
<Pharaoh_Atem> but for epel7, bundling is allowed
<Pharaoh_Atem> that's the only reason there's a bundled mode
<Pharaoh_Atem> (in re fedora packaging)
<mvo> Pharaoh_Atem: for 2.31 we have a new boltdb dep, but this might be packaged already for fedora, its quite popular aiui
<pedronis> mvo: do you know what core-snap-refresh  (but it checks boot envs)  vs core-snap-refresh-on-core are about?  I expected the first to have bits only about classic
<pedronis> they are manual
<mvo> pedronis: let me look, they are confusing
<mvo> pedronis: core-snap-refresh-on-core is about refresh and revert working, it is also the newer one of the two and should be used in spread-cron (I need to double check this though)
<mvo> pedronis: the other one looks like we should simplify it, i.e. just test that a new core snap survies refreshes and we can ignore core devices for this test because we already test that in the other test
<pedronis> mvo: so make it classic only , and remove the bits about boot envs ?
<mvo> pedronis: that would be my suggestion
<pedronis> ok
<mvo> pedronis: yeah, I think that is sufficient. we may need to add a loop to wait until snapd is active in `snap changes` though, I think as it is currently written it is racy
<mvo> pedronis: i.e. after the reboot we may call `snap changes` before snapd has started (but then we have some wait-time for snap to wait for the socket so maybe not an issue)
<pedronis> we do that in other places
<pedronis> I haven't seen (yet)Â issues with that
<mvo> pedronis: even better, then lets ignore it
<mup> PR snapd#4497 opened: many: make rebooting of core on refresh immediate, refactor logic around it <Created by pedronis> <https://github.com/snapcore/snapd/pull/4497>
<pedronis> mvo: IÂ proposed this  ^    though spread tests need a bit more work (for example those two), also there may be different approaches/policies
<mvo> pedronis: cool, I have a look in a bit (fighting with seccomp just now)
<mup> PR snapd#4496 closed:  tests: update auto-refresh-private to match messages from current master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4496>
<pedronis> mvo: thx, is not super urgent but wanted to push it before leaving,  it's been a todo since long, can wait after I'm back for sure to land
<mvo> pedronis: ok, thank you
<mvo> zyga-ubuntu: hey, welcome back - does https://travis-ci.org/snapcore/snapd/builds/329513349#L1950 make any sense to you?
<zyga-ubuntu> mvo: hey
<zyga-ubuntu> mvo: sorry, some stuff at home
<mvo> zyga-ubuntu: in my strace PR there is a failure in the snap-update-ns test
<zyga-ubuntu> mvo: I'm not back for real yet
<zyga-ubuntu> mvo: great insight on your PR
<zyga-ubuntu> (on the older one with dbus)
<mvo> zyga-ubuntu: that looks like it is happening consistently but it does not make sense to me
<mvo> zyga-ubuntu: aha, no worries
<mvo> zyga-ubuntu: well, that PR is yours really, you figured it all out :)
 * mvo hugs zyga-ubuntu 
<zyga-ubuntu> looking
<zyga-ubuntu> mvo: that strace branch is interesting
<mvo> zyga-ubuntu: the fun part is that #4473 (which contain most of it) is green
<mup> PR #4473: snap: add `snap run --strace` to be able to strace snap apps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4473>
<zyga-ubuntu> that's .... unexpected
<zyga-ubuntu> mvo: as for the dbus problem I think there is a real bug in dbus now but I your patch works around it (and is not incorrect)
<zyga-ubuntu> mvo: and will save me exploring that (which is painful becauese iteration is annoyingly slow)
<zyga-ubuntu> mvo: I'm still trying to grok the strace bug, does it happen in interactive debug as well?
<mvo> zyga-ubuntu: I have not tried that yet
<mvo> zyga-ubuntu: we can talk about it tomorrow, its just puzzling and maybe things get clearer if my initial strace PR is merged
<mvo> (as the diff will get smallre)
<mvo> smaller
<zyga-ubuntu> mvo: ok, that sounds good to me
<zyga-ubuntu> mvo: I will be back in 15 minutes, just some constant interrupts at home now
<zyga-ubuntu> mvo: nothing in that PR screams at me 'here'
<zyga-ubuntu> mvo: unless there's a typo that makes strace go where it shouldnt
<zyga-ubu1tu> re for good
<pedronis> did travis change their timeout?
<pedronis> there's a run that is finished after 1h+
<pedronis> *is not finished
<boopy> how do you update snap and how do you recover from this?
<boopy> > snap "ubuntu-core" has changes in progress
<cachio> niemeyer, when you have a free slot, could you please take a look to the PR #49 for spread
<mup> PR #49: allow (optional) snappy update $pkgname <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/49>
<mup> PR snapd#4418 closed: tests: enabling opensuse for tests <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4418>
<mup> PR snapd#4490 closed: tests/main/snap-service-after-before: add test for after/before service ordering <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4490>
<Pharaoh_Atem> mvo: it looks like we're not testing against Fedora in snapd CI
<Pharaoh_Atem> what happened here?
<mvo> Pharaoh_Atem: there were a bunch of issues with the fedora repos, there is a PR to enable fedora again iirc
<mup> PR snapcraft#1875 opened: Remove deprecated 'snap' recommendation <Created by ted-gould> <https://github.com/snapcore/snapcraft/pull/1875>
<Pharaoh_Atem> mvo: that means I probably have idea if the deps for master are satisfiable
<Pharaoh_Atem> have no idea, I mean
<mvo> Pharaoh_Atem: yeah, we are unhappy about this too: https://github.com/snapcore/snapd/pull/4492
<mup> PR #4492: spread: try to enable Fedora once more <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>
<mvo> Pharaoh_Atem: actually, this one fails because of a new dep, there is a fix already for this
<mvo> (in 4493)
<niemeyer> cachio: Will do
<cachio> niemeyer, tx
<robert_ancell> Snap packages are installed in a queue right? Does anyone know if there's a plan to be able to install in parallel?
<nacc> robert_ancell: LP: #1585403 ?
<mup> Bug #1585403: please support parallel operation <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1585403>
<robert_ancell> nacc, thanks!
<pedronis> robert_ancell:  there is no queue,  some single things are serialized
<nacc> robert_ancell: np
<robert_ancell> pedronis, so can a second install start before the first one is complete currently?
<pedronis> yes,   at least  if core is already there
<robert_ancell> pedronis, ok, thanks!
<pedronis> if they need core they will wait on that
<robert_ancell> I'm asking because there's a discussion in GNOME Software about parallel vs. queued installation and I'm giving the snap datapoint.
<pedronis> as I said, there's no queue in snapd, there are conflict checks between ops (usually at the level of each single snap), and some internal ops (like changes to security) are serialized, but overall install can be started in parallel
<pedronis> and most of it will proceed in parallel
<robert_ancell> e.g. downloading?
<pedronis> right
<nacc> pedronis: does that imply the above bug should be closed?
<pedronis> yes, except IÂ have no idea why my colleagues didn't close it, what they were thinking
<pedronis> with their answers
<niemeyer> I think it can be closed
<niemeyer> snapd indeed operates closer to make -j than it does to apt or deb in that regard
<niemeyer> Those really serialize all steps of the installation, while snapd goes wild and only rejects known conflicts as you pointed out pedronis
<niemeyer> make -j also doesn't parallelize _everything_ either.. just the things it knows are independent.. so vaguely resembling snapd's behavior indeed
<nacc> pedronis: niemeyer: sounds good, thanks
<niemeyer> It's quite awkward to say "Fix Released" for something that was always like that.. and curious that there's no better option.
<niemeyer> nacc: np
<nacc> niemeyer: yeah, you can change the state of the bug to Invalid, if that's actually the case
<nacc> (IMO)
<nacc> roughly like NOTABUG in bugzillas
<robert_ancell> niemeyer, yeah, it always feels weird doing a Fix Released like that.
<nacc> niemeyer: but yeah, the states aren't quite what i expect, ever :)
<niemeyer> nacc: Invalid also feels wrong.. it's not invalid.. it's a valid feature request, and it's implemented, and always was. :)
<robert_ancell> The other option is invalid, but that seems a bit harsh if it was a valid request at the time.
<nacc> niemeyer: yeah, but it soudns like it was't a valid feature request then either?
<niemeyer> Yeah, it's more like "Yay!"
<niemeyer> :)
<nacc> dunno, it's a lose-lose :)
<nacc> a good comment and whatever terminal state you want :)
<niemeyer> nacc: yeah details.. from a human perspective, a person asked for a behavior, and it's already in place.. it's not "Okay I did it", and it's not "That's wrong" either
<nacc> niemeyer: yep, agreed
<niemeyer> GitHub gets that right.. it's just Closed
<nacc> right
<nacc> the graph for LP doesn't match my brain often
<niemeyer> I'd suspect it inherited from Bugzilla, but it's been such a long time that I can't even remember..
<niemeyer> Anyway.. it's closed. :)
<robert_ancell> Is there any online documentation on the policy for snapd updating snaps? They're always automatically updated on a schedule, right?
<robert_ancell> And you can manually update them at any time.
<robert_ancell> This seems to be the closest I can find: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/4
<mup> Issue snapcraft#1876 opened: Cleanbuild doesn't work with SSH based Git repos <Created by ted-gould> <https://github.com/snapcore/snapcraft/issue/1876>
<niemeyer> robert_ancell: Right, that's it
<niemeyer> robert_ancell: The default schedule right now is 4 times within the day
<niemeyer> robert_ancell: At random times
<niemeyer> That is, once every 6h window
<niemeyer> robert_ancell: We have improvements landing right now (just reviewed a PR on that, actually) that introduce monthly support in the scheduling
<robert_ancell> niemeyer, nice
<niemeyer> So people will be able to pick a specific day within the month
<niemeyer> The syntax is documented in ...
<niemeyer> https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239
<niemeyer> and the options for core in general are documented in ...
<niemeyer> https://forum.snapcraft.io/t/configuration-options-for-core-snap/87
<niemeyer> The latter was not yet updated with the former because it's not yet publicly available
<robert_ancell> I feel like we need a snapd section (perhaps a different name) in https://docs.snapcraft.io/ as that seems to cover the snap format and snapcraft
<niemeyer> robert_ancell: I would prefer to just drop these pages there and make them point to our forum, which is easier to keep up to date and more visible
<niemeyer> For example, the format is documented at
<robert_ancell> niemeyer, that would work for me
<niemeyer> https://forum.snapcraft.io/t/the-snap-format/698
<niemeyer> And we have similar pages for each of the fundamnetal snaps (gadget, kernel, etc)
<niemeyer> Alright, I'm going to call it a day and see if I can get some proper sleep for a change..
<niemeyer> Have a good night all
<Pharaoh_Atem> niemeyer, zyga-ubuntu: it seems that we might want to reprovision the Fedora 27 Linode VM from scratch: https://pagure.io/Fedora-Council/tickets/issue/99
<Pharaoh_Atem> that will let us add tests for SELinux stuff
<Pharaoh_Atem> c.f.: https://pagure.io/Fedora-Council/tickets/issue/99#comment-480742
#snappy 2018-01-17
<tedg> cjwatson: sergiusens: Okay, so it seems the root difference is in ordering of the parts. For whatever reason on the builders the remote parts run first, while in my cleanbuild they run last. I copied the remote part and hardcoded its order, and things seem good now.
<tedg> FWIW, only having single direction ordering made me have to copy. Where if I could have put a "before" in I could have achieved the result without the copy.
<tedg> Probably not worth the work to add to snapcraft.
<cjwatson> tedg: Glad you got it sorted out
<tedg> cjwatson: thanks for the help, I was sure stuck!
<mup> PR snapcraft#1877 opened: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
<sergiusens> tedg so strange as we load everything into an OrderedDict (I haven't read through the full thread)
<mborzecki> morning
<mup> Bug #1638537 changed: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1638537>
<mup> Bug #1611638 changed: snap upgrade hook <snapd:Fix Committed> <snapd (Ubuntu):Fix Committed> <https://launchpad.net/bugs/1611638>
<mup> Bug #1637325 changed: snapd provides no way to register a new account <snapd:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1637325>
<zyga-ubuntu> o/
<zyga-ubuntu> mborzecki: some snow :)
<mborzecki> zyga-ubuntu: mvo: morning
<mborzecki> zyga-ubuntu: yeah, though it'll probably be gone in a matter of days
<mborzecki> damn i hope it will be gone
<mborzecki> otoh, at least driving a car if fun again :)
<mvo> mborzecki: good morning! and good morning to zyga-ubuntu
<mup> PR snapd#4498 opened: debian/tests: add missing autopkgtest test dependencies for debian <Created by mvo5> <https://github.com/snapcore/snapd/pull/4498>
<zyga-ubuntu> good morning mvo :)
<mup> Bug #1673539 changed: snapd doesn't clean up imported (snap) assertions <snapd:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1673539>
<mup> PR snapd#4499 opened: packaging/14.04: move linux-generic-lts-xenial to recommends <Created by mvo5> <https://github.com/snapcore/snapd/pull/4499>
<zyga-ubuntu> mborzecki: can you please do a 2nd review on 4495
<zyga-ubuntu> I provided some context that should make it easier
<zyga-ubuntu> jdstrand: good morning
<zyga-ubuntu> jdstrand: can you please have a loot at 4495 as well, it's based on your suggestion
<pstolowski> morning!
<zyga-ubuntu> o/
<mborzecki> pstolowski: hey
<mup> PR snapd#4493 closed: image: port ini handling to goconfigparser <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4493>
<zyga-ubuntu> mborzecki: 4492 can be rebased now, it should land ok
<mborzecki> doing that right now
<mborzecki> and pushed
<zyga-ubuntu> thanks, I'm mid rebase myself so didn't want to do that
<mvo> quick brainstorm: what would be a better sentence for "No snaps to auto-refresh found" apparently someone reads this as "my snaps cannot be auto-refreshed". but we want something like convey: "No new snap revisions to auto-refresh to found" - any ideas about a good sentence for this?
<zyga-ubuntu> mvo: "all snaps are up-to-date"
<zyga-ubuntu> mvo: "snap foo is already up-to-date"
<zyga-ubuntu> mvo: "snaps foo, bar and froz are already up-to-date"
<mvo> zyga-ubuntu: "auto-refresh: all snaps are up-to-date" ?
<zyga-ubuntu> mvo: sounds good
<mborzecki> mvo: +1
<mvo> thanks!
<zyga-ubuntu> if you need the prefix for some reason, I think it's hard to misunderstand that "all up to date" message
<mvo> mborzecki: if you run "snap version" on arch, do you get correct output?
<mvo> zyga-ubuntu: its in the logs, this is why I think the prefix is since, to give context to the log message
<mborzecki> snap    2.30.r545.g0d212818e-1
<mborzecki> snapd   2.30.r545.g0d212818e-1
<mborzecki> series  16
<mborzecki> arch
<mvo> mborzecki: ta
<mborzecki> kernel  4.14.13-1-ARCH
<mborzecki> snap    2.30.r545.g0d212818e-1
<mborzecki> snapd   2.30.r545.g0d212818e-1
<mborzecki> series  16
<zyga-ubuntu> mvo: ah, I ee
<mborzecki> arch
<mborzecki> kernel  4.14.13-1-ARCH
<zyga-ubuntu> *see
<mborzecki> snap    2.30.r545.g0d212818e-1
<mborzecki> snapd   2.30.r545.g0d212818e-1
<mborzecki> series  16
<mborzecki> arch
<mborzecki> kernel  4.14.13-1-ARCH
<mborzecki> snap    2.30.r545.g0d212818e-1
<mborzecki> snapd   2.30.r545.g0d212818e-1
<mborzecki> series  16
<mborzecki> arch
<mborzecki> kernel  4.14.13-1-ARCH
<mborzecki> pff
<mborzecki> glowing bear :/
<zyga-ubuntu> uff :)
<zyga-ubuntu> heheheh
<zyga-ubuntu> "once more with feeling"
<mup> PR snapd#4500 opened: snapstate: make no autorefresh message clearer <Created by mvo5> <https://github.com/snapcore/snapd/pull/4500>
<kalikiana> good(?) morning
<zyga-ubuntu> kalikiana: hey, are you saying that good may be NULL?
<zyga-ubuntu> kalikiana: it's snowing heavily here :)
 * kalikiana still deciding if fit for work
<kalikiana> Heh, yeah, good might be undefined
<zyga-ubuntu> oh, digitalocean has updated their prices, there are much better droplet configurations for the same price available!
 * zyga-ubuntu looks at wind blowing heavy snowfall
<zyga-ubuntu> hey spineau
<zyga-ubuntu> how are you doing? long time no see :)
<spineau> hi zyga-ubuntu
<spineau> very well, thx
<spineau> zyga-ubuntu: and you, are you missing Spain those days ;) ?
<mborzecki> zyga-ubuntu: DO adjusting their prices after meltdown/spectre?
<zyga-ubuntu> spineau: some of us here are :-)
<zyga-ubuntu> spineau: my daugther prefers Poland, my son prefers Spain
<zyga-ubuntu> spineau: I miss the constant sunshine and good mood
<zyga-ubuntu> mborzecki: they give x2 more for the same price
<zyga-ubuntu> mborzecki: and some new features too, like spaces (kind of like volumes but not really), super cheap
<spineau> zyga-ubuntu: sun helps, I miss it too since my recent move to French east border. I'm now very close to Switzerland
<spineau> it's a drastic weather change, especially in January
<zyga-ubuntu> spineau: oh, that's harsh, why did you move?
<spineau> zyga-ubuntu: my wife's new job
<zyga-ubuntu> spineau: I see, well
<zyga-ubuntu> do you see any mountains or hills? :)
<spineau> little hills :)
<zyga-ubuntu> that's one of the things I miss as well, Poland is too flat for my taste
<zyga-ubuntu> in Spain we could drive for 30 minutes and be at the base of serious mountains :)
<spineau> Spain rocks, definitely
<zyga-ubuntu> or go north for a little longer and have all the mountains and snow we'd ever need
<zyga-ubuntu> well
<zyga-ubuntu> maybe for holidays :)
<spineau> hehe, it was good to hear some news from you.
<spineau> ttl
<zyga-ubuntu> same :)
<mup> PR snapd#4501 opened: configcore: ensure config.txt has a final newline <Created by mvo5> <https://github.com/snapcore/snapd/pull/4501>
<mvo> zyga-ubuntu: do we need a jamie review for 4329?
<zyga-ubuntu> mvo: I think so
<zyga-ubuntu> we need a formal one
<zyga-ubuntu> he looked at it before
<zyga-ubuntu> but I'd rather wait
<mvo> zyga-ubuntu: ok
<mborzecki> mvo: trying out the strace build and have some trouble  with it, --strace no longer works
<mborzecki> mvo: looks like the actual strace output was filtered out too
<sergiusens> kalikiana hey, feeling better today?
<mvo> mborzecki: uh, the first of the strace PRs?
<kalikiana> hey sergiusens
<mborzecki> mvo: #4491
<mup> PR #4491: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <https://github.com/snapcore/snapd/pull/4491>
<mborzecki> mvo: looks like the 2nd strace loop filters everything out
<kalikiana> sergiusens: Yeah, better so far
<mvo> mborzecki: can you please apply https://paste.ubuntu.com/26403283/
<mvo> mborzecki: and pastebin the output?
<mvo> mborzecki: did you add any specific option?
<mborzecki> mvo: i have this diff http://paste.ubuntu.com/26403285/ and the log http://paste.ubuntu.com/26403287/
 * mvo looks
<mvo> mborzecki: do you use /snap on your distro as prefix?
<mvo> mborzecki: still filtering 2: "[pid  6906] execve(\"/snap/hello-world/27/bin/echo\", [\"/snap/hello-world/27/bin/echo\"], 0xc8200b4a00 /* 73 vars */ <unfinished ...>\n" is the line I see - but *maybe* thats the issue
<mvo> mborzecki: i.e. that inside the snap env it is always /snap not dirs.SnapMountDir
<zyga-ubuntu> mvo: inside the env it's always /snap
<zyga-ubuntu> mvo: *except for classic
<zyga-ubuntu> on any distro
<mvo> mborzecki: you found a bug
<mborzecki> yeah, looks like it ;)
<mborzecki> sorry
<mvo> mborzecki: haha, the opposite, you should be proud!
<mvo> mborzecki: fixing, thank you!
<mborzecki> mvo: yw
<zyga-ubuntu> uh
<zyga-ubuntu> thereare 4 CVEs on irssi
<mvo> mborzecki: could you please "git pull; git checkout naive-strace" and see if the last commit fixes the issue?
<mvo> mborzecki: ups, sorry, of course git fetch mvo5 etc
<mborzecki> mvo: works now
<mborzecki> mvo: and classic works too
<mup> Issue snapcraft#1876 closed: Cleanbuild doesn't work with SSH based Git repos <Created by ted-gould> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1876>
<jdstrand> zyga-ubuntu: re 4495> added
<zyga-ubuntu> jdstrand: thank you!
<jdstrand> zyga-ubuntu: btw, I was looking at an unsupported distro for something unrelated and snapd is running. I installed a snap and was able to run hello-world on first invocation
<zyga-ubuntu> jdstrand: nice :-)
<jdstrand> zyga-ubuntu: but on second invocation, the mnt file in /run/snapd/ns is empty
<zyga-ubuntu> oh
<zyga-ubuntu> it got unmounted?
<jdstrand> zyga-ubuntu: so the machinery tries to move into that namespace but fails
<jdstrand> I don't know yet
<jdstrand> my question is if this rings any bells on where to look. it is a 4.9 kernel if that helps
<jdstrand> zyga-ubuntu: snap-discard-ns resolves the issue (of course)
<zyga-ubuntu> jdstrand: what was the exact error message?
<mvo> mborzecki: yay, thanks for double checking
<zyga-ubuntu> jdstrand: there are several places where we want to jump into a namespace
<zyga-ubuntu> jdstrand: and they should all handle this well
<zyga-ubuntu> jdstrand: it doesn't ring any bells on first thought yet
<jdstrand> zyga-ubuntu: unfortunately, I didn't write it down and it isn't at hand. I'll see if I can get more detail
<zyga-ubuntu> jdstrand: if you give me the distro I can look
<jdstrand> zyga-ubuntu: I don't really want to distract you, but it sorta sounded familiar to some old issues, but they've been long resolved so nothing came to mind otoh either
<zyga-ubuntu> jdstrand: so, on 1st try it just constructs
<zyga-ubuntu> jdstrand: on 2nd try it will inspect it (even if the outcome is unused today)
<jdstrand> right
<jdstrand> there was enough info that 'file' showed it was empty, which I thought was odd. but now looking at my 17.10 system, file shows them as empty, so file probably isn't dtrt
<jdstrand> ok, I need to play more. thanks
<zyga-ubuntu> jdstrand: yes, they are always empty
<zyga-ubuntu> jdstrand: you want to "stat -f" them
<mup> PR snapd#4068 closed: interfaces/builtin: add support for content "source" section <Blocked> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/4068>
<pedronis> not really here but  https://travis-ci.org/snapcore/snapd/builds/329545603?utm_source=github_status&utm_medium=notification is very strange, there seems to be two runs in the log there
<jdstrand> zyga-ubuntu: ah right. I forgot I needed to use stat on those
<mvo> mborzecki: thanks for your feedback, I addressed your points for naive-strace-opts (which is not that naive anymore actually ;)
<zyga-ubuntu> mborzecki, pstolowski: can you please look at 4502
<mup> PR snapd#4502 opened: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>
<pstolowski> kk
<zyga-ubuntu> pstolowski: for attribute / slot / plug usage (I think ok but just in case)
<zyga-ubuntu> mborzecki: as a iteration of closed 4068
<mborzecki> looking
 * zyga-ubuntu -> small break
<zyga-ubuntu> actually, maybe in 15 minutes
<Saviq> can I somehow refresh from a "local" snap to a store one without purging data for the snap? I often have to move between a store snap and a local one for development and purging hundreds of megs of data every time is :(
<zyga-ubuntu> Saviq: that's mvo's snap refresh --amend branch
<zyga-ubuntu> with new name coming for amend
<Saviq> aha, glad it's coming
<mborzecki> zyga-ubuntu: reviewed 4502, not sure about MountEntries()
<zyga-ubuntu> mborzecki: good catch, it should be used in mount/backend.go but itsn't
<zyga-ubuntu> mborzecki: i will fix that
<mborzecki> great :)
<zyga-ubuntu> mborzecki: I don't think the code should be in add mount entries, it may be needed to push it back even more to the backend
<zyga-ubuntu> we'll see
<zyga-ubuntu> this code didn't run with spread yet (it depends on other parts) so it's likely something is lurking
<mborzecki> zyga-ubuntu: while at it, consider putting it into a helper func
<zyga-ubuntu> mborzecki: declash?
<ppisati> this, in a clean xenial amd64 chroot this morning: https://pastebin.ubuntu.com/26403870/
<ppisati> sergiusens: ^
<mborzecki> zyga-ubuntu: yeah
<ppisati> kalikiana: ^
<ppisati> kyrofa: ^
<zyga-ubuntu> ok, I'll think
<mborzecki> zyga-ubuntu: if you happen to move the declash into a place where snap names are known, it'd be great to log them
<kalikiana> ppisati: you should be running from a python virtual env
<kalikiana> is that the case?
<ppisati> kalikiana: let me try
<baimafeima> hi does anyone know whether it would be possible to create a snap for this game? http://zod.sourceforge.net/
<kalikiana> ppisati: https://github.com/snapcore/snapcraft/blob/master/HACKING.md
<mvo> Chipaca: does "src/github.com/snapcore/snapd/osutil/sys/sysnum_32.go:26:25: error: reference to undefined identifier âsyscall.SYS_GETUID32â" ring any bells? build failure on powerpc on xenial
<mcphail> hi sergiusens. when the build servers are fully up and running again would it be ok if i ask you to keep https://bugs.launchpad.net/snapcraft/+bug/1718245 in mind? it would be great to get svn repos working
<mup> Bug #1718245: svn source-type not honoring proxies <Snapcraft:Triaged> <https://launchpad.net/bugs/1718245>
<mborzecki> mvo: iirc it was added for 32bit systems where they use SYS_GETUID32 instead of SYS_GETEUID on 64bit
<mvo> mborzecki: ok, I think we need to do something about this if it is not defined
 * kalikiana tea break, brb
<cory_fu> sergiusens: Can I find you and get a few minutes of your time when you have a minute?
<sergiusens> cory_fu where are you?
 * zyga-ubuntu goes out
<cory_fu> sergiusens: I'm in Hudson right now.  I can meet in the plenary
<sergiusens> cory_fu that's where I am, come over :-)
<sergiusens> Hudson is freezing iirc :-)
 * pstolowski lunch
<mvo> Chipaca: fwiw, I poked a bit at the powerpc issue and my feeling is that for gccgo (powerpc) we need a different approach for osutil/sys/syscall.go. slightly sad but there seems to be no syscall.SYS_GETPID32 - I poke a bit more after lunch
<mvo> Chipaca: but there is syscall.SYS_GETPID so maybe we need to make do with that. anyway, after lunch
<tedg> sergiusens: In the original case there was no specified ordering between the parts, so I imagine they ended up in the map effectively randomly?
<greyback> jdstrand: question for you: I'm snapping chromium-on-XWayland, to run with the mir-kiosk snap. I'm hitting issue with confinement where XWayland wants ability to bind sockets. Would adding that to the wayland interface be a bit much?
<greyback> else I'll change tack and have mir-kiosk implement the x11 interface, and have XWayland in there instead. I'm less enthusiastic about this option due to X being harder to secure
<Chipaca> mvo: remind me, is powerpc 32 bits?
<jdstrand> greyback: does simply plugging the x11 interface not work?
<jdstrand> greyback: if not, can you show me the denials?
<jdstrand> greyback: note, I'm at a sprint and may be laggy. don't hesitate to ping me if I don't respond
<greyback> jdstrand: ack. I'll try and let you know
<jdstrand> greyback: we can look at the denials, but I consider Xwayland a special X server
<jdstrand> so x11 seems like the first thing to at least think about if things are broken
 * kalikiana going for lunch in a few and taking a break from fighting tar
<zyga-ubuntu> re
<zyga-ubuntu> Chipaca: yes
<greyback> jdstrand: adding x11 plug doesn't help, as core has no x11 slot I can connect it to. x11 is classic only. It seems like a pity to expose that x11 is being used at all, ideally it is an internal implementation detail of the chromium snap
<Chipaca> zyga-ubuntu: thanks
<jdstrand> ah
<zyga-ubuntu> Unable to process SAML login request
<zyga-ubuntu> hmmm
<zyga-ubuntu> this is me trying to open the calendar
<greyback> jdstrand: denials & interfaces: https://pastebin.ubuntu.com/26404327/
<zyga-ubuntu> hmm, worked now
<jdstrand> greyback: ah right. so if your snap provides xwayland, then (conceptually) it should 'slots: [ x11 ]', which would mean doing for the x11 interface what you did for the wayland. that said, let me look at your paste
<greyback> jdstrand: the snap provides wayland, yes, but not in a way that other snaps should be able to conenct to. It shoud be exclusively for chromium (also in the snap)
<greyback> s/wayland/xwayland/
<jdstrand> yeah, so that unix socket is exactly what is in the plugs of the x11
<greyback> right
<mup> PR snapd#4448 closed: Add rules for Media API to the BlueZ D-Bus policy <Created by lhartung> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4448>
<jdstrand> the shm denial is different
<jdstrand> (though we need to handle it)
<greyback> I've tried redirecting /dev/shm to /dev/shm/$SNAP.** with LD_PRELOAD, not had success yet
<jdstrand> greyback: can you expand on 'exclusively for chromium'?
<mvo> Chipaca: it is
<jdstrand> greyback: I don't think that will work. that is the special mir socket from mirPermanentSlotAppArmor
<jdstrand> (I think)
<jdstrand> which, iirc, is a special kernel file that you can't adjust the path on
<jdstrand> it just happens to show up as a regular file rule. Ideally we would have shm mediation that would handle that better. anyway...
<greyback> jdstrand: sure. Desire is for single chromium snap to run on mir-kiosk. Chromium's wayland support is broken, so XWayland is needed. So I thought it sensible to have XWayland inside the Chromium snap, which exclusively Chromium can connect to with the X protocol. Xwayland then talks to mir's wayland interface. So from the outside you woudn't know/care xwaylad was involved at all
<jdstrand> oh I see
<jdstrand> greyback: I have to attend a meeting. let me ponder this. I may be laggy
<greyback> blocker is that xwayland needs a socket for chromium to connect to, which seccomp isn't allowing
<greyback> since most gui apps don't want that
<greyback> jdstrand: no worries, please chew it over
<greyback> in the mean time I'll see how terrible it is to have mir-kiosk implement the x11 slot itself
<zyga-ubuntu> ok, actualy working this way is not too bad
<zyga-ubuntu> I'm mounted via sshfs to my desktop and I can keep working on the same files :)
<cachio_> zyga-ubuntu, trying to join but no power at home
<zyga-ubuntu> cachio_: we've finished now, no worries
<zyga-ubuntu> cachio_: is everything ok?
<cachio_> zyga-ubuntu, yes, but electricity has gone during the night in all the neighborhood
<Chipaca> mvo: it seems powerpc wasn't a thing before the uid_t became 32 bits, so getuid is the syscall we want
<mvo> Chipaca: \o/
<Chipaca> mvo: want me to propose a pr?
<mvo> Chipaca: yeah, unless you are busy please go ahead
<Chipaca> zyga-ubuntu: all hail your lab :-D
<zyga-ubuntu> :D
<cachio_> zyga-ubuntu, now I am using phone connection
<Chipaca> mvo: raise your hand if you aren't busy
<Chipaca> zyga-ubuntu: do you have a i386 hanging off of this?
<Chipaca> zyga-ubuntu: otherwise I can take you an eeepc :-)
<zyga-ubuntu> Chipaca: no but I have one and I can add it tomorrow
<zyga-ubuntu> (real i386)
<zyga-ubuntu> Chipaca: I also have a mips but it's not reliable (bad ddr)
<Chipaca> zyga-ubuntu: well, i586 at least plz :-D
<zyga-ubuntu> Chipaca: it's an atom
<zyga-ubuntu> Chipaca: actually
<zyga-ubuntu> 32bit only
<Chipaca> nice
<zyga-ubuntu> so, ... tomorrow :)
<zyga-ubuntu> or later today
<Chipaca> zyga-ubuntu: no hurries, it's mostly curiosity
<zyga-ubuntu> I'll put classic on it as it has an PATA ssd that didn't work in core (no IDE support)
<zyga-ubuntu> Chipaca: anything else? :D
<Chipaca> zyga-ubuntu: uh.... no, it'd be greedy of me
<Chipaca> also we don't support pep8
<Chipaca> pdp8
<Chipaca> that
<zyga-ubuntu> hahaha :D
<zyga-ubuntu> I was thinking about adding a server (UEFI) armv8 later
<zyga-ubuntu> soon people will start to sell those first gen boxes
<mvo> Chipaca: haha - point taken
 * Chipaca squints at git
<Chipaca> what's the point of doing 'gt mv' if it then just does whatever
<Chipaca> ah no maybe it's just 'get status' that gets confused
<Chipaca> eh
 * Chipaca gets on with it
<zyga-ubuntu> man
<zyga-ubuntu> I'm so dumb
<zyga-ubuntu> I was staring at a compile error, trying to understand it
<zyga-ubuntu> when I typed "function() errror" instead of "func() error"
<zyga-ubuntu> mvo: btw, any luck with that strace test failure?
<mvo> zyga-ubuntu: not yet, let me run with -debug now
<mvo> zyga-ubuntu: hm, no, some 2.31 prep first
<Chipaca> mvo: 4503 is what it is
<mup> PR snapd#4503 opened: osutil/sys: ppc has 32-bit getuid already <Created by chipaca> <https://github.com/snapcore/snapd/pull/4503>
<jdstrand> greyback: I think the x11 slot implementation would actually be quite easy compared to wayland, but, I have a couple of questions
<jdstrand> greyback: is a snap shipping Xwayland a common pattern, or something unusual?
<zyga-ubuntu> Chipaca: typo
<zyga-ubuntu> contsants
<Chipaca> zyga-ubuntu: I don't know what you're takling about
<greyback> jdstrand: the use-cases I have for it are things like chromium (for web kiosks) and electron (more kiosky bits)
<greyback> jdstrand: wherever xwayland lives, is really just an implementation detail.
<zyga-ubuntu> Chipaca: you made a typo in your PR
<zyga-ubuntu> Chipaca: 4530
<zyga-ubuntu> 4503
<greyback> jdstrand: I leaned toward xwayland in the app snap, just for security reasons
<Chipaca> zyga-ubuntu: i never make any typos, you're liying
<greyback> but I'm not forcing that as the only option
<zyga-ubuntu> Chipaca: drat, cosmic rays hit your keyboard then!
<Chipaca> zyga-ubuntu: obviosuly
<zyga-ubuntu> Chipaca: put tinfoil around your room ;-)
<Chipaca> i've got a better idea
<Chipaca> and it involves lunch
<cachio_> mvo, hey
<zyga-ubuntu> pstolowski, mborzecki: https://github.com/snapcore/snapd/pull/4471
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<zyga-ubuntu> updated, should be good now
<cachio_> mvo, sorry to skip the daily today
<zyga-ubuntu> Chipaca: ^^
<zyga-ubuntu> I'll rebase stuff stacked on top of that to see if all the extensive unit tests (>>1K diff) passes
<cachio_> mvo, any idea why travis jobs are not starting?
<mvo> cachio_: no worries about the standup, hope your elecricity is back. no idea about travis, let me check if I find anything out
<pstolowski> zyga-ubuntu, thank you, will re-review soon
<mborzecki> cachio_: mvo: https://www.traviscistatus.com/ show some major outage today
<mvo> yeah, backlog of ~650 container jobs
<mvo> ups. no, sorry
<mvo> active builds, woah
<Chipaca> zyga-ubuntu: I didn't mean for you to use my names for the helpers /o\
<mborzecki> cachio_: i'll close #4492 if #4336 is to be merged soon
<mup> PR #4492: spread: try to enable Fedora once more <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4492>
<mup> PR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
<cachio_> mborzecki, ok
<zyga-ubuntu> Chipaca: better names welcome :)
<cachio_> mborzecki, thanks for the info
<Chipaca> zyga-ubuntu: if I were good at names, I'd be good at names
<Chipaca> ah
<zyga-ubuntu> hm?
<elopio> good morning! I will start a few minutes late today to take my girlfriend to her office.
<elopio> bbs
<kalikiana> re
<zyga-ubuntu> mborzecki: there's no advantage from moving this into the backend
<kalikiana> elopio: you're such a gentleman :-D
<mborzecki> zyga-ubuntu: ok
<zyga-ubuntu> mborzecki: it's a public thing so we need to declash in specification anyway
<zyga-ubuntu> mborzecki: I'm trying to see how to make the logging friendlier
<zyga-ubuntu> mborzecki: I think we can use the same trick that other backends use
<zyga-ubuntu> mborzecki: store the snap as a hint
<mborzecki> zyga-ubuntu: yeah, that would work
<zyga-ubuntu> though need to think about the result first
<zyga-ubuntu> what we want
<zyga-ubuntu> (what the error message should look like
<mborzecki> zyga-ubuntu: how about this: "detected a path conflict at '/some/path' coming from snaps 'foo' and 'bar', '/some/path' from snap 'bar' will be mounted at '/some/path-2'" ?
<zyga-ubuntu> mborzecki: all of those are from one snap, the backend doesn't know enough to have that information
<zyga-ubuntu> mborzecki: the spec is for a snap (always)
<zyga-ubuntu> mborzecki: then each interface will influcnce it
<zyga-ubuntu> mborzecki: we could look at connected plug/slot to get the 2nd snap info
<zyga-ubuntu> mborzecki: but those are not conveyed by mount.Entry
<zyga-ubuntu> mborzecki: we could patch it to do that (store some snap name hint in the mount entry)
<zyga-ubuntu> mborzecki: but feels icky at that level
<zyga-ubuntu> mborzecki: I could patch mount.Specification to instead remmeber this in a side table
<zyga-ubuntu> mborzecki: not sure
<mborzecki> zyga-ubuntu: and if you declash in AddMountEntry() ?
<zyga-ubuntu> mborzecki: that's the same, those don't know anything about plug/slot
<zyga-ubuntu> mborzecki: I could declash there, not sure what's best
<zyga-ubuntu> mborzecki: but it doesn't help logging
<mborzecki> zyga-ubuntu: AddMountEntry() could return a custom error, eg ErrMountPointConflict that has an extra method returning the path the conflict was resolved to, then you could log at least one snap
<zyga-ubuntu> mborzecki: but then each caller would have to do that
<zyga-ubuntu> mborzecki: I think the trick is to figure out how to give it context without making it annoying to use
<cachio_> mborzecki, I need to work on PR 4336
<mup> PR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
<cachio_> mborzecki, for some reason fedora 27 machines are not working at all
<cachio_> mborzecki, I'll merge with latest changes and research a bit about what's happeninig
<mborzecki> cachio_: sounds like a plan :)
<Chipaca> mborzecki: the changes i asked you to block #4464 are there now
<mup> PR #4464: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4464>
<Chipaca> mborzecki: sprinkle a 'for' into that sentence somewhere for it to make sense
<zyga-ubuntu> or a comma
<zyga-ubuntu> hmm, there's a glibc update with lots of security fixes, feels like new core snap is needed
<mvo> zyga-ubuntu: indeed
 * zyga-ubuntu gardens email
<zyga-ubuntu> (using a scythe)
<kalikiana> ppisati: did you get the env to work?
<mup> PR snapd#4498 closed: debian/tests: add missing autopkgtest test dependencies for debian <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4498>
<diddledan> hello. is this hole in a random app something that highlights a way an application could bypass our sandbox? https://nvd.nist.gov/vuln/detail/CVE-2017-12904
<zyga-ubuntu> diddledan: looking
<diddledan> it's an interesting quesiton becuase theoretically the application developer opts-into the sandbox by distributing a snap but that vector could allow him to escape his self-imposed prison..
<zyga-ubuntu> diddledan: hmmm
<zyga-ubuntu> diddledan: this is a bug in a particular app
<diddledan> yes. but it highlights that code can be executed via terminal escape sequences
<zyga-ubuntu> diddledan: the app can be simply a "rm -rf /home/*"
<zyga-ubuntu> diddledan: ah
<zyga-ubuntu> hmm
<diddledan> it was just that it triggered me to thinking about vectors
<zyga-ubuntu> it doesn't look like it
<zyga-ubuntu> https://github.com/akrennmair/newsbeuter/commit/96e9506ae9e252c548665152d1b8968297128307
<zyga-ubuntu> this talks about subshell invocation
<zyga-ubuntu> so it's not a bug in the way terminal emulators implement parsing of ansi escape codes and other magic
<diddledan> well yes, that one application fixes it
<zyga-ubuntu> just in what this app wants to do
<diddledan> aha
<zyga-ubuntu> diddledan: disclaimer, I'm not a security engineer so please ask someone from the security team for official confirmation
<zyga-ubuntu> diddledan: but obviously the attack vector of printing stuff that chokes the terminal somehow is real
<zyga-ubuntu> diddledan: and it would be some kid of sandbox escape, yes
<diddledan> I guess I misread the Gentoo securty advisory: "A remote attacker, by enticing a user to open a feed with specially crafted URLs, could possibly execute arbitrary shell commands with the privileges of the user running the application."
<diddledan> I read that as "escape sequences used for display"
<diddledan> "Newsbeuter does not properly escape shell meta-characters in the title and description of RSS feeds when bookmarking."
<diddledan> it's an age-old unsanitized variable used in command line then
<diddledan> that in itself wouldn't escape the sandbox
<diddledan> phew. crisis averted.
<Chipaca> diddledan: meta-character != escape sequence though
<diddledan> this was a drill
<diddledan> there is NOT an ICBM heading to hawaii
<diddledan> that we know of. I mean there _might_ be an ICBM but we didn't alert you about that. We only alerted you about a fake ICBM that doesn't exist. If there is in fact an ICBM then as we didn't warn you: "our bad"
 * zyga-ubuntu heads ohme
<zyga-ubuntu> *home
<zyga-ubuntu> ttyl
<diddledan> tata
 * kalikiana thinks "ohme" should be the plural for units of resistance
<mborzecki> Chipaca: posted random ideas about symlinks, feel free to ignore :)
<Chipaca> mborzecki: I am going to ignore.
<Chipaca> mborzecki: mostly because it's work that can be done iteratively
<Chipaca> mborzecki: but partly because it'd need some more work to get some form of Readlink to work somehow
<Chipaca> mborzecki: in any case, it's for a follow-up
<mborzecki> Chipaca: yup, i'm not going to be adamant about it either :)
<Chipaca> mborzecki: yeah, something like what you pasted would work
<Chipaca> that and the extra check on things that go 'outside' are worth adding at some point
<diddledan> isn't an ohme a "brother from another mother" in London?
<diddledan> I is wiv me ohme's innit blood!
<mvo> cachio_: I updated core for a new stable release and pushed the result to beta, could you please validate it?
<mvo> cachio_: not sure we need the full validation as its just a respin with updated packages
<ogra> mvo, seems the multi-volume fix doesnt work ... :/
<cachio_> mvo, sure
<mvo> ogra: oh? what is the error?
<ogra> mvo, https://pastebin.canonical.com/207779/
<ogra> several OOPSIDs you can look up on errors.u.c
<ogra> mvo, looks the same as before "ERROR cannot read gadget snap details: bootloader already declared"
<mvo> ogra: it looks like snapd 2.30 runs on the image
<ogra> (i used the core from edge from 15min ago)
<mvo> ogra: but the fix is only in 2.30+git
<mvo> ogra: before image building did not work, right?
<ogra> oh, i thought that was in edge already
<ogra> image building did always work
<ogra> only device init after boot didnt
<mvo> ogra: it should be in edge, I had 2.30 in edge for ~20min or so to build a new stable
<ogra> same error as above
<mvo> ogra: could you please double check, edge is edge again
<ogra> ogra@localhost:~$ snap version
<ogra> snap    2.30
<ogra> snapd   2.30
<ogra> hmpf
<ogra> ok ...
<ogra> seems we picked up the stable 2.30 in edge
<mvo> ogra: sorry
<ogra> i'll goback to my manual hack (i just had validated the image to give to the customer when LP started building core again ... had just hoped we could give them the fix)
 * elopio is back and ready.
<mvo> ogra: edge should be ok again, you can give it one more try
<ogra> oh, did you re-build ?
<mvo> ogra: re-published
<mvo> ogra: the earlier core, not sure when exactly this one was build, I asked in between for a build, but not sure if it contains the fix or not
<ogra> mvo, according to the manifest both have 2.30
<ogra> i think there is a 2.30 in the image PPA still
<mvo> ogra: edge should be at 2.30+git497 - and yes, no new update in the ppa, I'm fixing this right now .)
<ogra> yeah, dashboard only shows git477 for armhf ... 479 was only in x86 arches
<zyga-ubuntu> Chipaca: could you please spare another look at 4471
<zyga-ubuntu> I really am blocked by that one landing so I'll be bugging you all until I get it resolved :)
<zyga-ubuntu> mvo: if you want to use your voice in the naming / refactoring discussion there
<zyga-ubuntu> once I get +2s from you I will ask gustavo to re-review
<zyga-ubuntu> pstolowski: 4472 needs a 2nd review, should be good now
<pstolowski> k
<zyga-ubuntu> thank you
 * zyga-ubuntu is still downtown
<zyga-ubuntu> the traffic is bad and it will be an hour before I get home
<pstolowski> +1
<zyga-ubuntu> thank you!
<zyga-ubuntu> I will re-run integration tests in my main integration branch to see if anything broke
<Chipaca> git doesn't respect file permissions, that's why my spread tests that check for them fail
<zyga-ubuntu> Chipaca: it respects +x
<zyga-ubuntu> Chipaca: what do you need
<Chipaca> zyga-ubuntu: everything
<Chipaca> zyga-ubuntu: also it respects +x in the sense that if it has any +x, it sets all +x and viceversa
<Chipaca> also if i hadn't checked this out on another machine there was no way i'd've figured it out
<Chipaca> because on my other machine everything works, with git saying 'yep no changes'
<zyga-ubuntu> Chipaca: well, depending on system those are not representable much
<Chipaca> >:-(
<zyga-ubuntu> I think it's better to chmod yourself
<zyga-ubuntu> chmod chmod chmod
<zyga-ubuntu> I'll go to the tube now, let's hope it's not super crowded (it will be)
<zyga-ubuntu> ttyl
<mup> PR core#74 opened: 10-remove-documentation: preserve changelogs <Created by mvo5> <https://github.com/snapcore/core/pull/74>
<mvo> a quick review -^ would be appreciated, should be trivial (cc ogra) - this will give us changelogs again
<mvo> cachio_: I will need to build another beta core, this one killed all changelogs which is a bit harsh, i.e. our http://people.canonical.com/~mvo/core-changes/html/stable/2.29.4.2_2.30.html will break for the "Package changelogs" section
<mvo> cachio_: sorry for this
<cachio_> mvo, np
<cachio_> mvo, I'll download the new ones once they are ready
<ogra> mvo, ack'ed
<mup> PR snapcraft#1878 opened: repo: use debian.arfile instead of dpkg-deb <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1878>
<kalikiana> ^^ sergiusens
<mup> PR core#75 opened: ensure that all live-build/hooks run with `set -e` <Created by mvo5> <https://github.com/snapcore/core/pull/75>
<cachio_> zyga-ubuntu, any idea if we could replace the dependency golang(github.com/Thomasdezeeuw/ini) with another on fedora?
<cachio_> zyga-ubuntu, we are having this error No match for argument: golang(github.com/Thomasdezeeuw/ini)
<cachio_>  
<cachio_> after do dnf -y --refresh -v install 'golang(github.com/Thomasdezeeuw/ini)'
<mup> PR core#74 closed: 10-remove-documentation: preserve changelogs <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/74>
<mborzecki> cachio_: this has been resolved in master
<mborzecki> cachio_: #4493
<mup> PR #4493: image: port ini handling to goconfigparser <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4493>
<cachio_> mborzecki, nice
<cachio_> thanks
<cachio_> mborzecki, ok, I'll make the change proposed by pedronis and pushe it to #4336
<mup> PR #4336: spread.yaml: add fedora 27 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
<mup> PR snapd#4483 closed: cmd/libsnap-confine-private: print failed mount/umount regardless of SNAP_CONFINE_DEBUG <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4483>
<cachio_> mborzecki, testing now, it goes slow because I am using my phone connection
<cachio_> mborzecki, and I also have 2 hours of laptop battery
<cachio_> mborzecki, I hope electricity comes back soon
 * kalikiana wrapping up for the day
<leftyfb> How does snappy deal with custom configuration files? As a very simplified example, lets say I wanted to configure openssh to listen on a port other than 22.
<nacc> leftyfb: so you mean a snapped ssh-server?
<nacc> leftyfb: classic or confined?
<leftyfb> probably classic to start with. But yeah. ssh server is just an example
<nacc> leftyfb: if it's classic, the snap can read the host OS
<leftyfb> wpasupplicant would be a better example in our case actually
<nacc> leftyfb: so, in theory, given the same sort of options are passed to the build (i.e, read /etc/ssh/...), a classic snapped ssh server would be no different than a non-snap
<nacc> as far as config goes, i mean
<Chipaca> leftyfb: there's a wpa-supplicant snap, but I'm not sure it'll answer your question
<leftyfb> we're looking to replace pxe/kickstart/ansible/catkin with a full snappy core + snaps. How would we deal with all the custom configs
<Chipaca> leftyfb: if your question is how does "snap get" and "snap set" interact with a pre-existing software's configuration, that's up to the snap
<nacc> if you were to confine it, i think you need to provide app(s) that expose the config you want to expose
<nacc> Chipaca: ah yes, i forgot that `snap {set,get}` exist :)
<nacc> leftyfb: so, e.g., a ssh server snap could expose a port config option
<Chipaca> leftyfb: if your question is "how can i read/write etc", you typically don't; things can usually told to read their config from elsewhere
<Chipaca> i meant "how can i read/write /etc/" in case that was unclear
<leftyfb> I'm not sure I'm following. Basically I want to create a snappy core image to be dd'd onto a drive and have all the configs ready to go. wpasuppplicant being an example, how would I go about configuring the ssid/password during the creation of the snappy core image?
<nacc> leftyfb: if it's your own wpasupplicant snap, just put it in your snap?
<leftyfb> ok, so we can put custom configs in the snaps?
<Chipaca> leftyfb: there's typically a factory setup step where you drop things like that in place, if I'm following you
<leftyfb> what about if it's a config that is part of the core OS and we don't want to recreate a new snap just so we get a custom config?
<Chipaca> leftyfb: ondra might have more experience with this than myself (I don't know what nacc works on :) )
<nacc> Chipaca: a little bit of everything :)
<nacc> (it feels like)
<Chipaca> leftyfb: what's the config? (it'll depend)
<Chipaca> nacc: :-)
<leftyfb> Chipaca: there's lots. We build robots :)
<Chipaca> leftyfb: right, but not a lot in the core os is about robots
<Chipaca> augh
<Chipaca> leftyfb: not a lot in the core _snap_ is about robots
<Chipaca> there, better
<leftyfb> for example, with wpasupplicant we have a custom wpasupplicant.conf and a custom systemd unit file for it
<nacc> leftyfb: right, so it's important to distinguish the bits here
<nacc> core snap + app snaps
<leftyfb> ugh, I have to step away for a bit.
<leftyfb> I'll come back and try to come up with other examples
<Chipaca> leftyfb: there is no wpa supplicant in the core os as far as i know
<Chipaca> leftyfb: so that's from a snap :-)
<Chipaca> (i could be wrong!)
<nacc> and how or what you do with a config is totally up to that snap
<Chipaca> granted if it's a service in the core os config can be tricky, but we've tried to keep that to a minimum
<Chipaca> because of this trickiness :-)
<Chipaca> ogra: do we ship wpa-supplicant in core?
<ogra> Chindeed we do
<ogra> geez
<ogra> Chipaca,
<nacc> lol
<ogra> get a bettar nick !
<Chindeed> ogra: ok
<ogra> :)
<Chipaca> ogra: then I'm confused by the wpa-supplicant snap :)
<ogra> Chipaca, but netplan only supports normal modes, no enterprise WPA or some such fancy stuff
<Chipaca> ahh
<ogra> NM and the wpa-suppl. snap solve that
<Chipaca> ogra: netplan doesn't, or consoleconf doesn't?
<Chipaca> ahh
<ogra> netplan doesnt
<ogra> theer was a recent discussion on the forum and with cyphermox about this
<Chipaca> ogra: link?
 * Chipaca so lazy
<ogra> Chipaca, https://forum.snapcraft.io/t/standard-for-bootstrapping-network-on-raspberry-pi-and-similar-devices/3137
<Chipaca> leftyfb: ^
<mup> PR snapd#4501 closed: configcore: ensure config.txt has a final newline <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4501>
<mup> PR snapd#4419 closed: tests: fix snapctl configure core tests for rpi2 and 3 <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4419>
<cachio_> mvo, are you uploading the new cores?
<cachio_> I just see the one for amd64
<mvo> cachio_: I can't :( the build farm is disabled because of spectre for most architectures. so I can only do amd64/i386 without help from the launchpad team. I was not able to reach someone this evening so I will try again tomorrow.
<mvo> cachio_: you can poke a bit at the amd64 version but it should be fine
<mvo> cachio_: here are the changes http://people.canonical.com/~mvo/core-changes/html/beta/2.30_2.30.html
<cachio_> mvo, ok, I'll try the amd64
<cachio_> mvo, it should be quick
<mvo> cachio_: thank you!
<ogra> mvo, oh ... i thought we were already back in business for all arches ...
 * ogra turns the daily core snap builds back off to not get bombed with build failure mails ...
<cachio_> mvo, my internet connection sucks today, still downloading the image
<cachio_> downlaoding at 19.7kB/s
<kyrofa> arrrgh ROS changed how their CLI tools work between when I wrote the script and when I recorded the videos...
<leftyfb> welcome to open source/api's :)
<leftyfb> I was just getting a handle on init scripts when systemd became the thing ... I thought I mastered ifupdown and now netplan is the thing :/
<kyrofa> leftyfb, but those are different technologies! catkin_create_pkg suddenly works differently, in the same ROS release :P
#snappy 2018-01-18
<mup> PR snapcraft#1879 opened: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
<niemeyer> Morning all
<niemeyer> Saviq: I've added the additional machines you requested on Spread, should be accessible to you already
<Saviq> niemeyer: fantastic, thank you
<mborzecki> morning
<mup> PR snapd#4464 closed: overlord/snapstate: do a minimal sanity check on containers <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4464>
<mvo_> cachio: everything ready in the beta channel for validation. as yesterday no new snapd, just package updates (see http://people.canonical.com/~mvo/core-changes/html/beta/ for details)
<mborzecki> mvo_: morning
<mvo_> hey mborzecki !
<mborzecki> mvo_: do you know if snapcraft also needs to do some work on https://forum.snapcraft.io/t/snap-service-start-ordering/1470/ ?
<mborzecki> mvo_: that's also what pedronis suggested, what leaves me wondering if i should poke someone from the snapcraft
<mborzecki> team
<mvo_> mborzecki: I think it does, it has a yaml schema for everything that can go into snapcraft.yaml. so the new things need to be added there iirc
<mvo_> mborzecki: you can poke sergiusens (at a sprint) or kalikiana
<mborzecki> ok, thanks
<mvo_> mborzecki: probably relatively easy, you could give it a stab yourself
<zyga-ubuntu> good morning
<mborzecki> zyga-ubuntu: hey
<zyga-ubuntu> how are you all feeling? :)
<kalikiana> hey mborzecki
<kalikiana> I can give you some pointers if needed
<kalikiana> adding that should be pretty straightforward
<kalikiana> assuming you'll want basically the same yaml as in the snap.yaml
<sergiusens> mvo_ mborzecki we got guidance at the sprint that the user docs need to be written first before proceeding on features so a PR against the docs would be nice to see
<zyga-ubuntu> sergiusens: interesting, thanks for sharing
 * zyga-ubuntu enjoys morning coffee
<pstolowski> mornings!
<zyga-ubuntu> o/
<mup> PR snapd#4492 closed: spread: try to enable Fedora once more <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4492>
<mup> PR snapd#4504 opened: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<mborzecki> figured i might as well add support for the watchdog if i'm to update snapcraft and the docs
<mvo_> mborzecki: +1
<mup> PR snapd#4500 closed: snapstate: make no autorefresh message clearer <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4500>
<zyga-ubuntu> 4499 needs a 2nd review
<zyga-ubuntu> pstolowski: perhaps?
<zyga-ubuntu> trivial
<pstolowski> loooooking, but github is sooo slooow atm
 * Chipaca waves
<zyga-ubuntu> mborzecki: does this need a gustavo approval? https://github.com/snapcore/snapd/pull/4487
<mup> PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
<zyga-ubuntu> Chipaca: o/ \o \o/
<mborzecki> zyga-ubuntu: yes, probably
<Chipaca> mvo_: I'd added the "sleep 1" thinking that the reason it wasn't seeing the messages in the journal was a race, when in the end it was git being a git
<zyga-ubuntu> k
<Chipaca> mvo_: so i was able to drop the sleep 1 \o/
<mborzecki> asked niemeyer to take a look at both #4487 and #4476
<mup> PR #4487: cmd/snap: snap refresh --timer, hide --time <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4487>
<mup> PR #4476: overlord/{snapstate,configstate}, daemon: introduce refresh.timer, fallback to refresh.schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4476>
<pstolowski> uhm no github for me atm, anyone else having problems?
<zyga-ubuntu> pstolowski: works for me
<mvo_> Chipaca: yeah, I noticed
 * zyga-ubuntu solicits reviews for https://github.com/snapcore/snapd/pull/4471
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<mvo_> mborzecki: I added a suggestion to the 4467, maybe a personal thing, but I found it slighly easier this way. please check it out.
<mborzecki> mvo_: it's much cleaner indeed, thanks
<Chipaca> hurray for enabling opensuse spread tests again, but â¦ they're failing again? :-(
<mvo_> mborzecki: thank you
<mvo_> Chipaca: yeah, tests are a bit unstable again :/
<Chipaca> with the EOF thing I thought was my fault in the user pr!
<Chipaca> that one was driving me crazy(er)
<Chipaca> good luck :-D
<mvo_> mborzecki: thanks for working on 4504! quick question: aiui for watchdogSec to work the app must call sd_notify() which needs to talk to a system socket - does that mean this pr also needs apparmor rules so that the app can access this socket?
<Chipaca> mvo_: hah! i just commented trying to point mborzecki along those lines :-D
<Chipaca> get out of my head :-p
<mborzecki> mvo_: yeah, this was mentioned by Chipaca in https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives/2268
 * mvo_ hugs Chipaca (from the inside)
<mborzecki> anways, i'm about to find out the hard way :)
<mvo_> mborzecki: haaha
 * Chipaca installing every app in /var/cache/snapd/names to check for validation problems
<Chipaca> s|app|snap with type:app|
<mvo_> mborzecki: its slightly annoying that the NOTIFY_SOCKET is set via an env, it seems it is currently /run/systemd/notify it seems there is no grantee about this
<mvo_> Chipaca: what is annoying is that 4503 failed three times already for different reasons :(
<Chipaca> mvo_: if you've restarted it 3 times, then it's been restarted at least 5
<zyga-ubuntu> oh, I restarted it too
<mvo_> Chipaca: *weep*
<mvo_> lol
<zyga-ubuntu> that's one unlucky bastard then
<mvo_> and also *moreweep*
<zyga-ubuntu> maybe it will be around when we hit PR 10K
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<Chipaca> we should have a 'carbon footprint per PR' competition
<mvo_> pr #100
<mup> PR #100: Ongoing work on the capability APIs <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/100>
<mvo_> pr #1000
<mup> PR #1000: debian: use sudo in setup of the proxy environment <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1000>
<mvo_> pr #1
<Chipaca> showoff
<Chipaca> :-)
<mvo_> Chipaca: heh, pretty even, no? 10: you, 100: zyga, 1000: me
<mvo_> pr 1
<mvo_> *pff* no pr 1?
<Chipaca> nope
<Chipaca> it was probably an issue
<zyga-ubuntu> bug #1 ;-)
<mup> Bug #1: Microsoft has a majority market share <canonical> <iso-testing> <microsoft> <package-qa-testing> <Clubdistro:Confirmed> <Computer Science Ubuntu:Confirmed for compscibuntu-bugs> <LibreOffice:New> <dylan.NET.Reflection:Invalid> <dylan.NET:Invalid> <EasyPeasy Overview:Confirmed for ramvi>
<mup> <Ichthux:Invalid by raphink> <JAK LINUX:Invalid> <LibreOffice:In Progress by bjoern-michaelsen> <Linux:New> <Linux Mint:In Progress> <The Linux OS Project:In Progress> <Neobot:New> <Novabot:New> <OpenOffice:In Progress by lh-maviya> <ReactOS Core Operating System:Incomplete> <Tabuntu:Invalid by
<mup> tinarussell> <Tivion:Invalid by shakaran> <Tv-Player:Invalid> <Ubuntu Malaysia LoCo Team:In Progress by apogee> <Wine:Confirmed> <Ubuntu:Fix Released> <Arch Linux:New>
<mup> <Baltix:Confirmed> <Debian:In Progress> <Fedora:Confirmed> <Fluxbuntu:Confirmed> <openSUSE:In Progress> <Tilix:New> <https://launchpad.net/bugs/1>
 * zyga-ubuntu gets back to work
<Saviq> jdstrand: fwiw, it's just a case of installing xrdp and a desktop environment, and putting the session name (like "mate-session") in ~/.xsession
<zyga-ubuntu> kind ping about 4471
<zyga-ubuntu> it's blocking everything for me
<zyga-ubuntu> please halp
<ogra> mvo_, i have some weird behaviour of core on one of my boards here, seems it auto-refreshed to the beta one even though it tracks edge
<mvo_> ogra: what do you see in "snap changes"?
<ogra> mvo_, https://paste.ubuntu.com/26409733/
<ogra> tracking:    edge
<ogra> installed:   16-2.30 (3872) 71MB core
<mvo_> ogra: I switched edge/beta around a bit in the morning, so maybe you see effects from this
<ogra> in the morning ? ... thats 3:30am !
<mvo_> ogra: this an non i386/amd64 system, right?
<ogra> (admittedly in technical sense that is "morning" indeed :P )
<ogra> mvo_, armhf
<mvo_> ogra: heh :) yeah, I did not mess around with things at this time
<mvo_> ogra: when is the next auto-refresh (snap refresh --time)?
<ogra> $ snap refresh --time
<ogra> schedule: 00:00-05:59/6:00-11:59/12:00-17:59/18:00-23:59
<ogra> last: 2018-01-18T06:21:00Z
<ogra> next: 2018-01-18T15:55:00Z
<mvo_> ogra: I wonder if the next auto-refresh will push you back to a +git version
<ogra> the revision is lower now ...
<ogra> (in edge(
<ogra> i could run a manual refresh ...
<mvo_> ogra: yeah, this is what I did this morning, moved edge back to a git version
<mvo_> ogra: yeah, just snap refresh should bring you back. I think its "expected" (in an unexpected way)
<ogra> (should not be different from auto, right ?)
<ogra> and so it does ...
<ogra> Make snap "core" (3852) available to the system
<ogra> ...
<mvo_> ogra: i.e. yesterday edge was "2.30" and there was a core snap build in the night which also had 2.30, then later your board refrehsed to 2.30 and in my morning I pushed edge back into +git land and now it should refresh to this (does that make sense)
<ogra> yeah, makes complete sense
<ogra> thanks for clearing the myth :)
<mvo_> ogra: its all (more) confusing because no auto-builds, everything need to be manually approved for building
<ogra> (i only noticed because i had put the revision into a release note for a customer ... and was just shocked that i typoed 3852 for 3872 when i looked at it this morning :P )
<ogra> mean that the revisions were so similar :)
<mvo_> heh
<mvo_> ok
<ads20000> Speaking of `beta`s...the beta is a different revision to candidate/stable but the same version number? Seems confusing...what happened there?
<ads20000> Was it just because you were switching them around? :
<ads20000> * :P
<ogra> version numbers in snaps are shallow
<ogra> they are just a string in snapcraft.yaml ...
<ogra> revisions are what counts
<Chipaca> well
<ogra> that said ...
<Chipaca> versions are for human consumption :-)
<ogra> it is likely the content is actually the same in the case of core
<Chipaca> and are merely descriptive
<ogra> (unless some of the additional packages changed ... the core snapcraft.yaml actually generates the version from the snapd version)
<zyga-ubuntu> Chipaca: it failed again
<zyga-ubuntu> on fedora
<mup> PR snapd#4503 closed: osutil/sys: ppc has 32-bit getuid already <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4503>
<zyga-ubuntu> mvo_: was it green in the end/
<mvo_> zyga-ubuntu: no, i merged it anyway
<mvo_> zyga-ubuntu: I need to get a deb build to see if it fixes the build failure
<Chipaca> "contact develper"
 * Chipaca looks for a brown paper bag
<mvo_> *cough*
<Chipaca> and i only realised when writing https://forum.snapcraft.io/t/snapd-is-now-doing-a-little-sanity-check-on-install/3566
<zyga-ubuntu> hmm?
<zyga-ubuntu> what is contact developer about?
<mvo_> zyga-ubuntu: "develper"
<zyga-ubuntu> ah
<zyga-ubuntu> typo
<jdstrand> zyga-ubuntu: fyi, I reviewd 4472
<jdstrand> reviewed even
<zyga-ubuntu> thank you!@
<zyga-ubuntu> thanks! I'll update the rules and merge
<zyga-ubuntu> jdstrand: I'm working on layouts now, while they won't work (apparmor) they are now applied to mount profile, the PR will need some discussion but it looks like a good start
 * pstolowski lunch
<jdstrand> greyback: ok, so, in thinking about this, I think we want to adjust the *mir*ConnectedPlugAppArmor policy to have '/{dev,run}/shm/\#* mrw,', then have your snap plugs mir and x11
<jdstrand> greyback: the idea is that if your snap snips xwayland, it is a mir client, so needs to 'plugs: [mir]', then the thing that talks to x11 needs to 'plugs: [x11]'
<greyback> jdstrand: xwayland is a wayland client, it's not using the mirclient libraries
<jdstrand> greyback: this is slightly odd because the app is really the slot for x11 though
<greyback> yeah I know
<jdstrand> greyback: the shm access is really a mir thing though, no?
<greyback> is having a separate xwayland snap, which has the x11 slot, too much?
<greyback> jdstrand: that is something I've never quite figured out
<greyback> perhaps I should, to get things straight
<jdstrand> greyback: in terms of policy, the shm access is only in mir
<greyback> true
<jdstrand> I was extrapolating from there when I suggested adjusting mir
<greyback> yep, understood
<jdstrand> I also understand the the shm access within the context of mir is considered safe
<greyback> let me ask around and try verify that
<greyback> or at least figure out exactly what in /dev/shm is needed
<greyback> and by what
<jdstrand> greyback: ftr, having a separate xwayland snap would not be required. you could embed it; your snap would just slots x11 (assuming we had that policy)
<jdstrand> so you slot it to yourself
<jdstrand> but, let me read something back you said a minute ago
<greyback> I didn't know you could slot to yourself
<greyback> that would do the trick
<jdstrand> let's assume that xwayland is one command in your snap and chromium another
<jdstrand> (for clarity)
<jdstrand> if xwaland is a wayland client, it should plugs wayland (let's not worry about shm for the moment)
<jdstrand> chromium is not a wayland client, so it should plugs x11
<jdstrand> xwayland command is providing x11
<jdstrand> so xwayland slots x11
<jdstrand> so
<jdstrand> the x11 interface grows the slot side (perhaps we can put the shm access in PermanentSlotAppArmor...)
<greyback> right so ar
<greyback> far
<jdstrand> the you have
<jdstrand> name: foo
<jdstrand>   apps:
<jdstrand>     chromium:
<jdstrand>       plugs: [ x11 ]
<jdstrand>     xwayland:
<jdstrand>       slots: [ x11 ]
<jdstrand>       plugs: [ wayland ]
<jdstrand> greyback: I think that aligns with how you described how xwayland works
<mvo_> Chipaca: and another ppc failure: https://paste.ubuntu.com/26410328/ - this time in boltdb
<greyback> jdstrand: yes that makes sense
<greyback> I'll give that a go
<greyback> jdstrand: thanks for the advice
<jdstrand> greyback: *today* a full on Xorg xserver wouldn't be able to run with the slot policy you right for x11, but that is ok. if that ever comes up, we can adjust the policy. this way you can focus just on the xwayland bits
<mup> PR snapd#4505 opened: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
<jdstrand> right?
<jdstrand> s/right/write/?
<jdstrand> (what an ugly typo)
<zyga-ubuntu> Chipaca: ^ early PR for layouts,
<zyga-ubuntu> mvo_: ^
<mvo_> ta
<greyback> jdstrand: heh, silly english with homonyms
<zyga-ubuntu> small, just for quick feedback on the idea
<jdstrand> greyback: for your testing, perhaps just tuck the shm access into the PermamentSlotAppArmor bit of x11 and add a TODO comment to investigate. before we merge, you investigate. it might be that we adjust mirConnectedPlugAppArmor to have the shm access and xwayland to plugs: [ wayland, mir ] since *this* wayland client happens to need it cause of some mir thing
<jdstrand> obviously depending on your investigation
<greyback> jdstrand: *nod*
<greyback> that's a plan
<jdstrand> greyback: ok, sorry for the lagginess on this. I'll be back from sprinting next week
<greyback> jdstrand: not at all, thank you for the help
<jdstrand> np
<mup> PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506>
<zyga-ubuntu> Chipaca: sorry to bug you but could you please (perhaps) split that PR into distinct commits that can be reviwed earliy
<zyga-ubuntu> *easily
<zyga-ubuntu> Chipaca: maybe one for typo, one for mv, more for extra features
<zyga-ubuntu> otherwise that's a 1K diff
<Chipaca> zyga-ubuntu: I can. Most of the diff is the move from snapstate to snap, i guess
<Chipaca> lemme close that
<Chipaca> before it chomps up a travis
<zyga-ubuntu> thanks
<zyga-ubuntu> oh drat, standup
<zyga-ubuntu> ... quick coffeee
<zyga-ubuntu> eeeeeeeeeeee
<mup> PR snapd#4506 closed: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4506>
<Chipaca> zyga-ubuntu: there you go
<mup> PR snapd#4506 opened: iterate on the container sanity check: patch typo, move to snap, add to pack <Created by chipaca> <https://github.com/snapcore/snapd/pull/4506>
<mup> PR snapd#4499 closed: packaging/14.04: move linux-generic-lts-xenial to recommends <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4499>
<mborzecki> cachio: do you the version of fedora kernel used on linode?
 * kalikiana time for lunch
<zyga-ubuntu> woot, one branch merged :)
<mup> PR snapd#4472 closed: cmd/snap-confine: allow snap-update-ns to poke writable holes in $SNAP <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4472>
<zyga-ubuntu> pstolowski: about 4358, how to approach it?
<zyga-ubuntu> pstolowski: any advice on how to review it?
<tyhicks> zyga-ubuntu: hey - I never saw if you got the apparmor label query issue straightened out?
<zyga-ubuntu> tyhicks: yes and no
<zyga-ubuntu> tyhicks: I drowned in dbus, iteration is a pain
<zyga-ubuntu> tyhicks: but mvo added a label that jdstrand suggested that fixed the problem
<zyga-ubuntu> tyhicks: (labeling the snap userd service as unconfined)
<tyhicks> zyga-ubuntu: do I need to fix a bug caused by that upstream change?
<zyga-ubuntu> tyhicks: it looks like the bug is real but it's not a pressing issue for us now
<zyga-ubuntu> tyhicks: I think so, it will affect other things
<zyga-ubuntu> (not just snapd)
<tyhicks> zyga-ubuntu: what's a simple reproducer? attempt to query a label of a peer connection in bionic?
<zyga-ubuntu> tyhicks: on bionic, revert mvo's change (I'll give you a link in a moment), install gimp (probably works with other snaps but this works for sure); snap run --shell gimp; xdg-open http://example.org
<zyga-ubuntu> tyhicks: the logs indicate that there's no peer label information and thus the rule for peer=unconfined doesn't apply and the activation is denied
<pstolowski> zyga-ubuntu, it would probably make sense to start by getting the understanding of the associated spread test and its 2 test snaps and their hooks
<zyga-ubuntu> tyhicks: it's *just* activation that is broken
<zyga-ubuntu> tyhicks: once activated it works correctly
<zyga-ubuntu> pstolowski: thank you, let's see
<zyga-ubuntu> tyhicks: I attached logs on the forum if you need those
<zyga-ubuntu> (and some advice on how to collect them)
<zyga-ubuntu> tyhicks: I think activation should happen regardless and not bail out on lack of the label
<zyga-ubuntu> tyhicks: or activation should carry implicit confinement "unconfined"
<zyga-ubuntu> tyhicks: reading the code it seems that activation should fail (by design) only on explicit deny rules
<zyga-ubuntu> tyhicks: that was the intent
<zyga-ubuntu> tyhicks: but this is not how it behaves
<pstolowski> zyga-ubuntu, then repo.go and doConnect handler. policy and connection.go changes last
<tyhicks> zyga-ubuntu: thanks - that helps a lot to understand the problem
<tyhicks> zyga-ubuntu: I have some ideas about how to do this correctly
<zyga-ubuntu> tyhicks: the branch to revert, once it lands, is https://github.com/snapcore/snapd/pull/4495
<mup> PR #4495: data/dbus: add AssumedAppArmorLabel=unconfined <Created by mvo5> <https://github.com/snapcore/snapd/pull/4495>
<jdstrand> tyhicks: bug #1742687
<mup> Bug #1742687: Launching URLs in snapped applications no longer works in 18.04 <AppArmor:Invalid> <D-Bus:New> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1742687>
<seb128> jdstrand, zyga-ubuntu, is there really a bug there? to be it looks like that dbus/apparmor enforces more checking that it used to and that the autoactivated services that AssumedAppArmorLabel info by design
 * zyga-ubuntu lunch
<zyga-ubuntu> seb128: yes, I think so
<zyga-ubuntu> seb128: reading the code and patch descriptions seems to imply it should not behave this way
<zyga-ubuntu> seb128: I'll defer to tyhicks's decision
<seb128> zyga-ubuntu, you should report it upstream, they might just fix it for us
<zyga-ubuntu> seb128: yeah, I can do that, good idea
<seb128> zyga-ubuntu, thanks
<zyga-ubuntu> ok, let's review things
<zyga-ubuntu> then let's file that bug
<zyga-ubuntu> and then, let's ... not sure yet :)
<kalikiana> re
<zyga-ubuntu> mborzecki: https://github.com/snapcore/snapd/pull/4505
<mup> PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
<zyga-ubuntu> mborzecki: would the group / user thing be a problem on arch?
<mborzecki> zyga-ubuntu: there's a 'nobody' group around here only
<mborzecki> zyga-ubuntu: the uids in tests are hardcoded too
<mborzecki> zyga-ubuntu: maybe it would be best to guess nobody/nogroup the same way we deal with directories
<mborzecki> zyga-ubuntu: li.Group is coming from the snap right?
<zyga-ubuntu> mborzecki: hymm
<zyga-ubuntu> mborzecki: yes
<zyga-ubuntu> mborzecki: I think that I need to tweak that to contain a fixed mapping
<zyga-ubuntu> mborzecki: this mapping must make sense on the inside, not for classic host
<zyga-ubuntu> mborzecki: and we only support 'root' and 'nobody'
<zyga-ubuntu> Chipaca: did you see 4506 failures?
<Chipaca> zyga-ubuntu: i saw your comment
<Chipaca> i'll dig in a bit
<Chipaca> (that pr is a backburner one)
<jdstrand> seb128 (cc zyga-ubuntu and tyhicks): tyhicks and I talked about it. it is fine that dbus is offering more mediation, but the way it is doing it is a bit weird. tyhicks will comment in the bug
<zyga-ubuntu> k
<seb128> jdstrand, thanks
 * kalikiana really, really hates regex today
 * kalikiana getting more tea
<zyga-ubuntu> kalikiana: regex is your friend, imagine if you had to do it by hand
<zyga-ubuntu> kalikiana: btw, do you knof about regex derivatives?
<zyga-ubuntu> kalikiana: I found that interesting a while back
<zyga-ubuntu> kalikiana: https://en.wikipedia.org/wiki/Brzozowski_derivative
<mvo_> Chipaca: looks like we need https://paste.ubuntu.com/26411304/ in upstream bolt (funny enough this seems to be not fixed in the coreos fork either - ppc seems to be not super popular)
<zyga-ubuntu> mvo_: before it blows up, can we check if this builds on other fringe arches?
<mvo_> zyga-ubuntu: which one do you have in mind?
<zyga-ubuntu> mvo_: s390 and all the other ones nobody has but will block us in next package build in the archive
<Chipaca> ooh, just got a very helpful email, trying to sell me email listings of redhat users
<kalikiana> zyga-ubuntu: hmmm I did not know that! will have to read up on it
 * Chipaca considers forwarding it to info@centos.org :-p
<zyga-ubuntu> kalikiana: it's not useful very often as it's not something implemented in any standard library I know
<zyga-ubuntu> kalikiana: but since I love that topic, I wanted to share it :)
<zyga-ubuntu> Chipaca: how much?
<kalikiana> zyga-ubuntu: usually I adore the concept as well, just not today when I'm fighting with a tricky case :-P
<zyga-ubuntu> kalikiana: what is the case? I will be your garden dwarf friend
<zyga-ubuntu> kalikiana: explain the problem to me
<cachio> niemeyer, when you have some time, could you please take a look to https://github.com/snapcore/spread/pull/49
<mup> PR spread#49: send keepalive packets every 10 seconds to avoid losing the connection <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/49>
<kyrofa> kalikiana, I also find rubular.com to be helpful
<zyga-ubuntu> pstolowski: some early feedback on 4358
<Chipaca> zyga-ubuntu: no idea
<zyga-ubuntu> pstolowski: marked as requeste changes because I'm still going through it and I have more questions pending
<zyga-ubuntu> pstolowski: sorry about that but if you follow the diff from the end and go up the order of my questions will be more logical
 * zyga-ubuntu reads diffs from the other end usually
<pstolowski> zyga-ubuntu, ty!
<pstolowski> :)
<zyga-ubuntu> can I ask for firmer vote on https://github.com/snapcore/snapd/pull/4502
<mup> PR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>
<zyga-ubuntu> pstolowski: sorry for the needs fixing, I don't see anything strongly broken, just want to understand it
<zyga-ubuntu> pstolowski: what's the idea with the new interface btw? are we adding a new interface designed for testing?
<pstolowski> zyga-ubuntu, sure, no worries
<Chipaca> here's an initeresting test to do: set up a long loop that installs and removes the same snap. compare how long it takes to install the 2nd time, vs the Nth time.
<zyga-ubuntu> Chipaca: what's the result you got?
<pstolowski> zyga-ubuntu, yes, this is something I brought up on the standup (limited testatibility with existing ifaces) and Gustavo suggested to created a new interface just for testing
<kalikiana> zyga-ubuntu, kyrofa: I'm staring at this `\A(on)\s+([^,\s](?:,?[^,\s]+)*)(\s(to)\s+([^,\s](?:,?\S+)*)|)\Z` which rejects "on i386, ubuntu to armhf" as invalid. due to the extra space after the comma. Except we *want* to parse it so we can show a special error. Now if I remove the change the two `[^,\s]` to `[^,]` it parses but the groups are merged in one
<Chipaca> on this machine, subjectively (because i didn't start out to measure this) it looks like as changes hit 10k, things get a lot slower
<zyga-ubuntu> pstolowski: should it be in a different file name?
<zyga-ubuntu> pstolowski: er, should the file have a different name
 * kalikiana finds https://regex101.com/ quite nice but sadly it can't extrapolate the intended use case
<zyga-ubuntu> pstolowski: test_... go is not usually built, rightt?
<Chipaca> I don't think I'll have time to run that test today, but i might tomorrow :-)
<zyga-ubuntu> kalikiana: looking
<pstolowski> zyga-ubuntu, i'm open to renaming it. I if the only expectation is about display name, it should clearly indicate it's not an interface for normal use
<pstolowski> d/I if/
<zyga-ubuntu> pstolowski: yes, i would add some provisions for hiding it (though not needed now)
<zyga-ubuntu> kalikiana: man, that could use the mode that enables whitespace and comments
<zyga-ubuntu> kalikiana: did you think about using a lexer and parser to make things like that easier to follow?
<zyga-ubuntu> kalikiana: can you please remind me what \A and \Z does in the engine you are working with (I presume python)
<Chipaca> zyga-ubuntu: start and end of string
<kalikiana> zyga-ubuntu: start and end of the string
<kalikiana> and yes, it's Python
<zyga-ubuntu> kalikiana: are those different from ^ and $?
<Chipaca> zyga-ubuntu: the m modifier changes ^ and $ to start of lines inside the string, so you need a bigger anchor
<zyga-ubuntu> ah
<zyga-ubuntu> I see
<Chipaca> or was it the s modifier
<Chipaca> one of 'em two
<zyga-ubuntu> I think it's 'm'
<zyga-ubuntu> kalikiana: ok and the (?: ) syntax, what does that introduce?
<kalikiana> zyga-ubuntu: it ignores the group in the results
<zyga-ubuntu> ok,
<zyga-ubuntu> kalikiana: that's dangerous perhaps
<zyga-ubuntu> kalikiana: it can cause states to be combined in the resulting DFA
<zyga-ubuntu> I'm not sure how much nfa->dfa action happens in python tho
 * zyga-ubuntu experiments 
<Chipaca> zyga-ubuntu: it's like () but without capture
<Chipaca> zyga-ubuntu: which is nice, because (foo)+ is weird
<zyga-ubuntu> perfect, thank you
<zyga-ubuntu> kalikiana: and what would you like this to match, in geral
<zyga-ubuntu> *general
<zyga-ubuntu> kalikiana: do you have a spec of what is valid (in english)
<zyga-ubuntu> kalikiana: I'll be back, I need to walk outside for an hour, see you later (just write the spec please)
<kalikiana> zyga-ubuntu: enjoy!
<Chipaca> mvo_: I subscribed you to #1744113 because I thought you might have something to add to the discussion
<mup> Bug #1744113: should the /names endpoint include kernels, gadgets, cores? <Snap Store:New> <https://launchpad.net/bugs/1744113>
<kalikiana> kyrofa: if you wanna have a look wrt the refactor, to re-uses on now in snapcraft#1800 - aside from my fighting with the regex the code works
<mup> PR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
<Chipaca> mvo_: dear IT worker, Good work.
<Chipaca> mvo_: that doesn't happen often! :-)
<mup> PR snapd#4336 closed: spread.yaml: add fedora 27 <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4336>
<kalikiana> kyrofa: I've found an interesting problem btw. having both `to armhf` and `on i386 to armhf` will be counted as duplicates. I'm not sure how to address that... the refactoring is turning out to be a little less straightforward
<kyrofa> kalikiana, well they kind of are, aren't they?
<kyrofa> It's possible for them both to match
<kyrofa> elopio, what's on your docket for today? Looks like I owe you a few reviews
<elopio> kyrofa: I want to finish collecting all the existing translations for the repo, and start the docs that Sergio requested.
<elopio> kyrofa: I am on vacations tomorrow, so it would be nice to finish the PRs today too.
<kalikiana> kyrofa: I found myself trying out `on amd64 to amd64` because why not, and that's an error. Which is probably fine since it's somewhat pointless. But separate `on amd64` statements probably do make sense in some cases.
<cachio> zyga-ubuntu, please take a look to #4351 when you have a time
<mup> PR #4351: tests: new test to validate location control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4351>
<blackboxsw> good day folks, I'm looking at creating a snapd/seed  directory for curtin & cloud-init  and wanted to chat about what I might be missing. Is it preferable for me to start a forum post for that?
 * kalikiana going to wrap up for today in a bit
<kyrofa> kalikiana, curious to hear what cases
<kyrofa> I can't think of any cases where they couldn't be merged
<kyrofa> Hahaha snapcraft#1877 is hilarious
<mup> PR snapcraft#1877: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
<kyrofa> Easiest review ever, close my eyes and +1
<kyrofa> elopio, any chance you made sure autopkgtests ran correctly as well (since those are effected by this as well)?
<kalikiana> kyrofa: Yeah. Arguably it's totally okay to fail like that. I just wanted to be sure to bring it up. Could still add that later in any case.
<blackboxsw> also quick question on snap auto-import. Is this command line utility which is actually searching for /var/lib/snapd/seed ?
<kyrofa> kalikiana, yeah it's part of the initial yaml spec, which may not grow quite as well as we would hope
<kyrofa> Not yaml spec, sorry, grammar spec
<elopio> kyrofa: we can get the bot to do that
<kyrofa> elopio, oh wait, amd64 is back huh?
<kyrofa> elopio, I've just been assuming everything was still down
<elopio> snappy-m-o autopkgtest 1877 xenial:amd64
<snappy-m-o> Computer says nooo. See logs for details:
<snappy-m-o>  Command '['/tmp/tmp02uqh_h1/retry_autopkgtest.sh', '1877', 'xenial:amd64']' returned non-zero exit status 1
<kyrofa> :(
<mvo_> Chipaca: sure, looking
<mvo_> Chipaca: re dear it works> where did you see that?
<Chipaca> mvo_: #1743079
<mup> Bug #1743079: apparmor exit code 123 <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1743079>
<kyrofa> elopio, I assume you have access to those logs?
<elopio> kyrofa: yes, checking.
<elopio> It would be more useful if the bot made a summary of the exception, instead of just exit 1
<mvo_> Chipaca: haha - right
<mvo_> Chipaca: I guess I will make this my new job title "IT worker"
 * Chipaca bbiab
<mup> PR snapcraft#1874 closed: kbuild: pick up CROSS_COMPILE only if it's not empty <Created by piso77> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1874>
<elopio> kyrofa: it's replying with a 500, so not yet.
<elopio> I'll give them a try here.
<kyrofa> Uh oh
<cjwatson> kyrofa: Surprising that GH doesn't handle that.  I fixed that kind of thing in LP a while back AFAIK (https://bugs.launchpad.net/turnip/+bug/1712754)
<mup> Bug #1712754: git diffs do not track renames <canonical-is> <turnip:Fix Released by cjwatson> <https://launchpad.net/bugs/1712754>
<zyga-ubuntu> back now
<zyga-ubuntu> cachio: approved
<cachio> zyga-ubuntu, tx
<blackboxsw>    
<zyga-ubuntu> so now that we have slack
<zyga-ubuntu> is there a slack for snappy?
<zyga-ubuntu> hmm
<mup> PR snapd#4507 opened: advisor: use forked bolt to make it work on ppc <Created by mvo5> <https://github.com/snapcore/snapd/pull/4507>
<kyrofa> elopio, I really only have one issue with snapcraft#1879
<mup> PR snapcraft#1879: extractors: replace desktop file ids with paths <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1879>
<lotuspsychje> good evening to all
<lotuspsychje> i have a wish for a snap command, whats the prefered way to do this? bug/wishlist?
<zyga-ubuntu> lotuspsychje: try opening a forum topic on forum.snapcraft.io
<lotuspsychje> zyga-ubuntu: ok thank you
<zyga-ubuntu> lotuspsychje: pleasure :)
<lotuspsychje> zyga-ubuntu: https://forum.snapcraft.io/t/req-snap-list-command-to-see-latest-added-snaps/3581
<zyga-ubuntu> lotuspsychje: nice! I commented alreay
<zyga-ubuntu> *already
<lotuspsychje> zyga-ubuntu: nice thank you!
<lotuspsychje> zyga-ubuntu: sudo snap find lists a few  but not all right
<zyga-ubuntu> lotuspsychje: yes, those are "curated snaps" (not really curated much ATM)
<zyga-ubuntu> lotuspsychje: but a feed of recently added or refreshed snaps would be interesting
<lotuspsychje> zyga-ubuntu: atm i always have to go to the store website and filter recently added
<mvo_> Chipaca: my bbolt (coreos fork) PR for fixing ppc got merged within 30min, that is quite impressive
<Chipaca> mvo_: niice
<Chipaca> mvo_: tag me on the pr, i'll look at it later tonight
<Chipaca> bye for now
<Chipaca> mvo_: i mean on the pr to move to the fork, if there is one :-)
<smiso> hi: Any one who any ideeas how to persistent add ip forwarding to ubuntu core?
<zyga-ubuntu> smiso: hey
<zyga-ubuntu> smiso: you can implement that in a snap that uses the network-control interface
<zyga-ubuntu> let me check
<zyga-ubuntu> smiso: you may need either or both network-control and firewall-control
<zyga-ubuntu> and then you should be able to set that up yourself (in your snap)
<zyga-ubuntu> I don't think we offer any default way to manage that today
<zyga-ubuntu> only as interfaces to snap applications
<cachio> zyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/
<cachio> zyga-ubuntu, this is executed with the interface connected https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind
<Snapdragon> Hello
<blackboxsw> hrm. snap known --remote model series=16 model=generic-classic brand-id=generic returns an ill-formed yaml file for sign-key-sha3-384 value the multi-line value doesn't use
<blackboxsw> nevermind.... not supposed to be yaml
#snappy 2018-01-19
<mup> PR snapd#4508 opened: New spread test for hardware-random-observe interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4508>
<mborzecki> morning
<mvo> hey mborzecki - good morning
<mup> PR snapd#4480 closed: snap-mgmt: extend spread tests, stop, disable and cleanup snap services <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4480>
<mborzecki> mvo: watchdog notify is a bit of a hassle, i got the apparmor rule for /run/systemd/notify (the path is hardcoded) then figured i could use systemd-notify from the shell script to avoid making a heavier snap, turns out we may need to tweak NotifyAccess for this to work
<mvo> mborzecki: what does notifyacess do?
<mborzecki> mvo: https://www.freedesktop.org/software/systemd/man/systemd.service.html#NotifyAccess= aiui it selects who, from the spawned process group, can send notifications to systemd (or rather whose notifications will be accepted)
<mvo> mborzecki: interssting - and slightly strange because we use type=notify in snapd but we do not set notifyaccess
<mborzecki> mvo: it defaults to main, so the main rpocess can send notifications
<mvo> mborzecki: aha, indeed. sounds like we need to support it for the poor souls who need != main then
<mborzecki> right
<mborzecki> i'm thinking, cause using systemd-notify is actually a legitimate case (found some java library that does exactly that), so the apparmor template would need to allow `/bin/systemd-notify ixr` and `/run/systemd/notify w`
<mborzecki> and NotifyAccess on top :/
<mvo> yeah, worthwhile to talk to jdstrand if we need a special interface for this
<mborzecki> mvo: also thought that the service will run under the same systemd as snapd does, so we could take NOTIFY_SOCKET from our env and adjust apparmor rule dynamically
<mvo> mborzecki: that is a nice idea!
<mvo> mborzecki: because I'm concerned that we can't hardcode this
<jdstrand> mvo, mborzecki: it's been in our queue to look at an interface for this. Chipaca and I discussed it a while ago (around the time of the comments in the forum)
<jdstrand> mvo, mborzecki: it is behind quite a few things at this point though
<jdstrand> mvo: what is the priority of this work relative to layouts, portals, userd/xdg-settings and priv dropping?
<jdstrand> note: there are other snappy items that are higher priority atm too
<mborzecki> jdstrand: i can try and propse and interface
<jdstrand> well, developing the interface isn't necessarily the issue, it is the investigation on its safety
<jdstrand> and that kinda needs to happen beforehand. honestly, idr all the details for why this is needed atm since this was from afew months ago
<jdstrand> mborzecki: what is requiring it?
<mborzecki> jdstrand: i have a PR #4505 that implements WatchdogSec= in service spec
<mup> PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
<mborzecki> w8, bad number
<mborzecki> #4504
<mup> PR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<jdstrand> mborzecki: I'm going to infer a couple things from that pr. please correct as needed cause, as mentioned, I've not done any investigation and haven't used watchdog personally
<jdstrand> mborzecki: so, we declare some yaml so systemd can keep an eye on a service
<jdstrand> mborzecki: that service then needs some sort of security policy to receive sd_notify events?
<jdstrand> no that isn't quite right
<mborzecki> jdstrand: yes, it needs to sendmsg on $NOTIFY_SOCKET (set by systemd), which is /run/systemd/notify atm
<jdstrand> it is starting to come back
<jdstrand> https://www.freedesktop.org/software/systemd/man/sd_notify.html
<jdstrand> right, systemd doesn't poll, the service pushes via sd_notify()
<jdstrand> mborzecki: iwhat is $NOTIFY_SOCKET?
<jdstrand> like, name based file, abstract socket, anonymous socket, ...?
<mborzecki> it's the path to the notification socket, it's set by systemd in service'env when running the service
<jdstrand> mborzecki: ok, I'm now caught up with what I was concerned about
<jdstrand> mborzecki: so, it appears (again, inferring here), that systemd will set NOTIFY_SOCKET per service (fine)
<sergiusens> willcooke you around?
<jdstrand> mborzecki: but what is the *actual* value of NOTIFY_SOCKET? I suspect that it is not namespaced wrt to the snap. eg, maybe it is a random string, etc
<mborzecki> jdstrand: it's /run/systemd/notify
<jdstrand> mborzecki: ok, so if we give all snaps (or an interface) access to that, what would prevent one snap from reporting events for another snap?
<jdstrand> mborzecki: ie, what isolation guarantees are in place in systemd? if it is system's design and implementation that this is secure and you can't spoof notifications, then we could just allow it, and accesses violating that just become security bug that would get a CVE
<mborzecki> jdstrand: from what i see, systemd will look at ancilliary data and figure out a pid of the sender, then depending on the NotifyAccess= setting in service files, either all processes in process group of the service can send the nofication or jsut the main process
<jdstrand> mborzecki: but if there are no guarnatees, then we have to decide what to do
<mborzecki> jdstrand: i.e.even if you send MAINPID=<other-service> and that other-service is not part of your pg systemd will reject the notification
<jdstrand> mborzecki: if that were true, and the enforcement was real, then it would be fine to allow by default
<jdstrand> mborzecki: but now we are where I was a few months ago-- need to look at that. if you want to do that investigation and provide details on your findings, that might help move things along
<jdstrand> mborzecki: for the moment it sounds like it is safe, but that needs to be verified. assuming for a moment it is safe, then it might make sense to only add the access to the socket *if* the watchdog yaml is present
<jdstrand> mborzecki: today, we don't really have a way to do that (a sort of implied interface). it could be a separate sd notify interface, but it feels weird to way you want watchdog *and* you need to declare an interface for it to work
<jdstrand> mborzecki: ie, snapd already has all it needs to with either
<jdstrand> mborzecki: actually, could look at it the other way. create a watchdog interface, and plugging that is what adds the bit to the service definition
<jdstrand> (just food for thought)
<mborzecki> jdstrand: right, a separate 'watchdog' or 'software-watchdog' interface sounds right
<jdstrand> we came across this type of thing with the dbus service discussions, which I think was before you starting focusing on snappy. I mention that only because the idea of declaring in one place something that affects service and interfaces is useful to more than just this
<mborzecki> jdstrand: now the second part, with spread test https://github.com/snapcore/snapd/commit/9ec6594c4d53d4b548e964e7d66ea4ba68dea89e i also need to allow ixr on systemd-notify, that why using a separate interface would make more sense
<jdstrand> mborzecki: what is a little weird about declaring it in 'plugs' is that 'plugs' can be toplevel, and therefore apply to the whole snap. I guess if you did that, you would simply apply watchdog to all services (so not really that weird after all)
<mborzecki> jdstrand: systemd-notify is just a helper that does the notification thing on behalf of the caller
 * jdstrand nods
<jdstrand> 'Note that systemd will refuse reception of status updates from this command unless NotifyAccess= is set for the service unit this command is called from.'
<jdstrand> that is consisent with what you said earlier
<jdstrand> consistent*
<zyga-ubuntu> good morning
<jdstrand> hey zyga-ubuntu
<mborzecki> jdstrand: i had to set NotifyAccess=all to get it to work
<mborzecki> zyga-ubuntu: morning
 * zyga-ubuntu catches up on backlog
<jdstrand> mborzecki: hmm. the man page says that 'systemd-notify will first attempt to invoke sd_notify() pretending to have the PID of the invoking process. This will only succeed when invoked with sufficient privileges.'
<jdstrand> daemons run as root, so we probably have sufficient privileges to use sd_pid_notify() for anything
<jdstrand> so my plan was to pore through the man pages for sd_notify and sd-notify, then go through the code and see what could be attacked by a malicious root user with access to the socket
<jdstrand> I feel that is still needed after reminding myself of sd_pid_notify. again, if you'd like to provide that investigation,I can take a look and that might make things go faster. if not, need mvo's input on relative priority for me to look at this
<jdstrand> if we can't come up with something reasonable there, we can raise this up to ratliff to see if someone else could look at it. the timing of meltdown/spectre makes that problematic though
<mborzecki> jdstrand: ok, let's do this, i'll label #4504 as blocked for now and propose an separate PR with software-watchdog interface, then once the security check is complete the code will be there already
<mup> PR #4504: snap, wrappers: systemd WatchdogSec support <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4504>
<mborzecki> jdstrand: we can start simple by just allowing write on /run/systemd/notify
<jdstrand> ok. I'll futz our board to bubble this up a little higher, but it is still behind quite a few things
<jdstrand> well
<jdstrand> sd-notify is just a wrapper around sd_notify() and friends
<jdstrand> if the socket api allows specifying arbitrary pids, that (may) mean that the root daemon could spoof notify events
<jdstrand> for the interface to go through, we'd need to understand that to set the auto-connection policy accordingly
<mborzecki> jdstrand: i'm looking at systemd code right now, the itneresting bits are https://github.com/systemd/systemd/blob/07fbf8807c7555981c9449151bdc51ba867cde1e/src/core/service.c#L3375 and https://github.com/systemd/systemd/blob/07fbf8807c7555981c9449151bdc51ba867cde1e/src/core/manager.c#L1992
<zyga-ubuntu> spineau: o/
<jdstrand> mborzecki: looking at my notes from before, it looks like I was strongly leaning for the socket (and sd-notify) to be in a separate interface
<jdstrand> so that is consistent with what we came up with here
<mborzecki> right
<jdstrand> note I'm at a sprint atm and note able to provide the focus needed for this
<jdstrand> not*
<jdstrand> I've grabbed those urls and put them in the card (where my notes are)
<mborzecki> jdstrand: sure, thanks for your input anyway :)
<mborzecki> i'm marking 4504 as blocked and will leave a note there
<jdstrand> mborzecki: ok. if this is problematic or needs to be reprioritized, ping me again and we can pull in mvo and ratliff and decide on a path forward
 * kalikiana sliff
<zyga-ubuntu> kalikiana: hey
<zyga-ubuntu> kalikiana: you didn't write that spec for me last night
 * jdstrand puts entire conversation into trello
<zyga-ubuntu> kalikiana: I'd love to help you with that regexp
<mborzecki> jdstrand: sure, thanks
<pstolowski> mornings!
<zyga-ubuntu> hey pawel
<spineau> morning zyga-ubuntu
<kalikiana> zyga-ubuntu: what kind of spec do you imagine? this is in the context of snapcraft#1800
<mup> PR snapcraft#1800: grammar: on..to statement <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1800>
<zyga-ubuntu> kalikiana: yes, that one
<zyga-ubuntu> did you get it to work in the end?
<zyga-ubuntu> I can still help you write the regular expression
<kalikiana> zyga-ubuntu: nope. I pushed it because the code refactoring is done, but there's still a test failure due to the regex
<zyga-ubuntu> k, let me look at what it's supposed to do by reading some of the PR log and iterate on my small regexp here
<zyga-ubuntu> kalikiana: ok
<zyga-ubuntu> https://pastebin.ubuntu.com/26415334/
<zyga-ubuntu> and obviously I pasted the older version
<zyga-ubuntu> https://pastebin.ubuntu.com/26415337/
<zyga-ubuntu> kalikiana: so what else do we need here?
<zyga-ubuntu> kalikiana: https://pastebin.ubuntu.com/26415372/
<zyga-ubuntu> kalikiana: how am I doing?
<kalikiana> zyga-ubuntu: this `on amd64, ubuntu` should parse as "amd64, ubuntu" despite the space
<kalikiana> zyga-ubuntu: oh, I think you just did that one
<zyga-ubuntu> what is ubuntu, the os name?
<zyga-ubuntu> I didn't see that in the spec
<kalikiana> wait no
<kalikiana> zyga-ubuntu: No. It's a test string. The grammar doesn't care what the value is, as long as it is a string
<kalikiana> it could be `on i386, amd64` or `on spams, eggs`
<zyga-ubuntu> https://pastebin.ubuntu.com/26415382/
<zyga-ubuntu> try this
<zyga-ubuntu> https://pastebin.ubuntu.com/26415383/ improved comments
<zyga-ubuntu> hey koza
<zyga-ubuntu> koza: white easter coming ;)
<kalikiana> zyga-ubuntu: how do you actually run this? just in a python console?
<koza> zyga-ubuntu, hey, yeah although I expect meltdown soon ;-)
<zyga-ubuntu> kalikiana: in ipython3
<mborzecki> koza: ha ha
<zyga-ubuntu> kalikiana: it's very good at iteration as the history and editing is superb
<kalikiana> zyga-ubuntu: erm. let me try to be clear on what those things are. `on foo,bar,spam,eggs` can be a very long list of arbitrary things. there's not going to be a "host os" or anything like it
<zyga-ubuntu> ah, ok
<zyga-ubuntu> sorry ;)
<zyga-ubuntu> just a moment
<kalikiana> zyga-ubuntu: no worries, I should've pointed this out properly
<kalikiana> zyga-ubuntu: note "on foo" also works, no list at all
<zyga-ubuntu> so there's no split for architecture and os?
<zyga-ubuntu> https://pastebin.ubuntu.com/26415395/
<zyga-ubuntu> (this one still assumes there's a split)
<zyga-ubuntu> without a split the code can be simpler
<kalikiana> zyga-ubuntu: practically speaking only architectures are recognized atm. they'll be evaluated much later
<kalikiana> zyga-ubuntu: also, this can only be "on foo" or "on foo to bar", the rest is yaml
<zyga-ubuntu> kalikiana: https://pastebin.ubuntu.com/26415406/
<zyga-ubuntu> kalikiana: it matches that, just not sure what foo and bar are here
<zyga-ubuntu> see if this makes sense in the last pastebin
<kalikiana> zyga-ubuntu: I mean there won't  be : [bla,blub]
<kalikiana> that's handled by yaml
<zyga-ubuntu> aha
<zyga-ubuntu> well, cut that part out :)
<zyga-ubuntu> I think doing this in verbose mode is much more manageable
<zyga-ubuntu> does this help you get what you want?
<kalikiana> zyga-ubuntu: I think so, typing it all in here to test it atm
<kalikiana> zyga-ubuntu: NoneType has no attribute 'goupdict', and have to retype. this is tedious to do with so many lines :-P
<zyga-ubuntu> kalikiana: no no
<zyga-ubuntu> run ipython
<zyga-ubuntu> go up (keyboard)
<zyga-ubuntu> and just edit :)
<zyga-ubuntu> don't retype this insanely
<kalikiana> oh, didn't see the i there
<zyga-ubuntu> ipython3 is your friend
<zyga-ubuntu> there are even shinier versions but this is a big step up from python
<zyga-ubuntu> check out tab completion
<zyga-ubuntu> or foo? for docs
<zyga-ubuntu> kalikiana: for ultimate shiny try bpython3 (b)
<zyga-ubuntu> kalikiana: though ipython handles multiline far better
<kalikiana> zyga-ubuntu: woot, it actually has multi-lines. this is crazy
<zyga-ubuntu> kalikiana: bpython is crazier for UI
<kalikiana> hmmmm still this "AttributeError: 'NoneType' object has no attribute 'groupdict'"
<zyga-ubuntu> kalikiana: then it doesn't match
<zyga-ubuntu> kalikiana: the problem with REs is that it's all or nothing
<zyga-ubuntu> kalikiana: I'd say, that at the complexity you are now
<zyga-ubuntu> kalikiana: it's better to use a parser
<kalikiana> oh, haha, silly me, you're right
<zyga-ubuntu> kalikiana: because then you have sensible error recovery and you can introduce syntax for errors with tailored messages
<zyga-ubuntu> kalikiana: anything like extra commas, repeated entries, wrong order, whatever, can be parsed and just handled explicitly
<zyga-ubuntu> kalikiana: it's a step up from REs but the results are also a lot better
<kalikiana> zyga-ubuntu: perhaps that's the next step. introducing two expressions side by side is what's making it complex now
<kalikiana> hmmm ipython is fun
<zyga-ubuntu> try ??
<kalikiana> Object `` not found
<zyga-ubuntu> define a function
<zyga-ubuntu> and then type "function_name ??"
<zyga-ubuntu> (try with ? and ??)
<kalikiana> oh, neato
<kalikiana> quick help
<zyga-ubuntu> kalikiana: ping me if I can help somehow, I'll get back to snapd now
<zyga-ubuntu> E: Failed to fetch http://mirrors.linode.com/ubuntu/pool/main/s/systemd/libpam-systemd_204-5ubuntu20.25_amd64.deb  Connection failed [IP: 2600:3c01:1::607e:6379 80]
<zyga-ubuntu> hmm
<zyga-ubuntu> src/github.com/snapcore/snapd/advisor/backend.go:26:2: cannot find package "github.com/snapcore/bolt" in any of:
<zyga-ubuntu> 	/root/rpmbuild/BUILD/snapd-1337.2.30/src/github.com/snapcore/snapd/vendor/github.com/snapcore/bolt (vendor tree)
<zyga-ubuntu> 	/usr/lib/golang/src/github.com/snapcore/bolt (from $GOROOT)
<zyga-ubuntu> 	/root/rpmbuild/BUILD/snapd-1337.2.30/src/github.com/snapcore/bolt (from $GOPATH)
<zyga-ubuntu> 	/usr/share/gocode/src/github.com/snapcore/bolt
<zyga-ubuntu> mvo: ^ what shall we do about bolt on fedora?
<zyga-ubuntu> error: Bad exit status from /var/tmp/rpm-tmp.VNVcCw (%build)
 * zyga-ubuntu begs for reviews of 4471
<mvo> zyga-ubuntu: yeah, this all sucks, I'm not sure what is the best way forward, let me take a walk and think about it
<Chipaca> is it known that the maas snap dumps core on install on 16.04?
 * Chipaca pastebins the configure hook output and continues
<zyga-ubuntu> mborzecki: can you have a 2nd look at https://github.com/snapcore/snapd/pull/4505 please
<mup> PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
<zyga-ubuntu> mborzecki: it should now work ok for arch
<zyga-ubuntu> mvo: thank you
<zyga-ubuntu> Chipaca, mvo: can you please review/approve 4471
<zyga-ubuntu> I'm blocked by this
<Chipaca> pr 4471
<mup> PR #4471: cmd/snap-update-ns: refactor and improve Change.Perform to handle EROFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4471>
<zyga-ubuntu> mvo: I think we just have to package bolt
<zyga-ubuntu> mvo: is it ready in debian?
<Chipaca> zyga-ubuntu: we could carry on using regular bolt outside of ppc
<Chipaca> probably needs some build shenanigans for ppc though :-/
<zyga-ubuntu> Chipaca: bolt doesn't exist for fedora now, that's a separate problem
<Chipaca> ah, ok
<Chipaca> i need to go out for a bit before it's too late for me to go out for a bit :-)
 * Chipaca runs, leaving things ticking over
<zyga-ubuntu> ttyl
<zyga-ubuntu> mvo: I have a crazy plan to make layouts easier
<zyga-ubuntu> mvo: I may do a spike around that today,
<zyga-ubuntu> make / a tmpfs,
<kalikiana> zyga-ubuntu: all looking very nice now on the grammar front! thank you for pulling me out of that mental swamp!
<mborzecki> zyga-ubuntu: https://src.fedoraproject.org/rpms/golang-github-boltdb-bolt ?
<mup> PR snapd#4509 opened: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<zyga-ubuntu> mborzecki: ah, cool so perhaps we just need to add a new dependency to packaging
<zyga-ubuntu> kalikiana: glad to hear that!
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/4505 is green and easy to review :)
<mup> PR #4505: interfaces/mount,snap: early support for snap layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4505>
<mvo> zyga-ubuntu: you mean we need to package bbolt? or bolt? bolt is packaged, we could patch it with our fixes
<mvo> zyga-ubuntu: but that still would not solve our vendor'ed version (boltdb/bolt would still be buggy on ppc)
<zyga-ubuntu> niemeyer: can you please re-review 4471 now
<ogra> mvo, did you notice that we ship update-motd in core (seems to be pulled in by libpam-modules recommends for whatever reason) ... so https://github.com/snapcore/core/blob/master/live-build/hooks/14-set-motd.chroot only applies half and we always get the additional update-motd info
<ogra> mvo, do you think we could purge update-motd during build ?
<koza> or instead put correct files to /etc/update-motd.d and forget about the /etc/motd
<koza> mvo, ogra ^^
<mvo> ogra: I was not aware of this
<mvo> thanks
 * kalikiana taking a break, back in a few
<koza> anyways the welcome motd seems just not right with all of the links pointing to desktop-centric resources also referencing 'Snappy Ubuntu Core' which as far as I understand is now just called Ubuntu Core
<koza> mvo ^^
<mvo> koza: +1
<ogra> mvo, it is mainly this part we should drop i think:
<ogra> printf " * Documentation:  https://help.ubuntu.com\n"
<ogra> printf " * Management:     https://landscape.canonical.com\n"
<ogra> printf " * Support:        https://ubuntu.com/advantage\n"
<ogra> sice it points to completely generic ubuntu docs and services
<koza> or replace with Core & Stacks documentation links
<ogra> well, /etc/motd already points to the snappy docs
<koza> desktop/snappy ;-)
<ogra> if we move that over we should be fine
<koza> imho it should point here: https://www.ubuntu.com/core
<mvo> ogra, koza I think we need a forum post with the prosoal for the update so that gustavo can weight in. but +1 for fixing the motd!
<ogra> koza, well, it is supposed to tell you how to use snaps ... not how to create core :)
<ogra> (i guess at least)
<ogra> probably it should point to both :)
<koza> it is up to mvo and the team but I see a two worlds collide here: a) static motd from /etc/motd; b) dynamic approach via update-motd; I would suggest one or another - not mix them. I mean if /etc/motd is the choice then remove update-motd package as it runs every 10 mins stealing cycles ;-)
<koza> otherwise kill /etc/motd as it just creates confusion to where the stuff is coming from
<mvo> koza: I'm in favor of the static motd, simpler this way
<ogra> well
<ogra> we might want to be able to abuse it for IoT status information
<koza> yeah, good point
<ogra> (at least that sounds like a useful feature)
<ogra> so keeping the functionality might make sense
<mvo> ogra: fair enough, if that is planned in the (near) future that is fine with me
<ogra> (perhaps even an interface that could allow writing such info would)
<ogra> mvo, i'm only brainstorming :) nothing specific is planned ... but such a future feature sounds like a reason to keep update-motd
<ogra> (instead of having to pull it in again later)
<mborzecki> zyga-ubuntu: left some comments in 4505, also the unit tests pass on arch (none of this is really dynamic by anyway)
<zyga-ubuntu> mborzecki: thank you, examining
<mborzecki> Chipaca: idk if you noticed this: https://paste.ubuntu.com/26416072/ it's not failing though
<koza> mvo, https://github.com/snapcore/core/pull/76 and lets take it from here
<mup> PR core#76: hooks: update the set-motd hook to provide better motd <Created by bergotorino> <https://github.com/snapcore/core/pull/76>
<mup> PR core#76 opened: hooks: update the set-motd hook to provide better motd <Created by bergotorino> <https://github.com/snapcore/core/pull/76>
<koza> mvo, asked Thibaut about what he thinks about changing motd, you are on cc
<greyback> jdstrand: https://pastebin.ubuntu.com/26416195/ snapd not liking plug and slot in same snap :(
<greyback> I'll have a look to see why that is
<greyback> anyone recommend an IDE for go?
<mup> PR snapd#4510 opened: asserts: use Attrer in policy checks <Created by stolowski> <https://github.com/snapcore/snapd/pull/4510>
<zyga-ubuntu> greyback: plug and slot must have unique names
<zyga-ubuntu> greyback: just call one x11-slot
<zyga-ubuntu> greyback: I use sublime text
<zyga-ubuntu> greyback: and vim
<zyga-ubuntu> greyback: both with go-specific plugins
<greyback> zyga-ubuntu: just installed sublime :)
<greyback> zyga-ubuntu: my trouble is that I was trying for one app to provide the x11 slot, so that the other app can plug into it
<zyga-ubuntu> greyback: that's ok, it's just that the string "x11" is no longer unique
<zyga-ubuntu> you need to name the plug and the slot uniquely
<zyga-ubuntu> both can be of type "x11" (just say interface: x11)
<greyback> zyga-ubuntu: oh ok, I understand
<zyga-ubuntu> pstolowski: do you have an URL with smaller diff
<pstolowski> zyga-ubuntu, what do you mean? can I do that with github?
<zyga-ubuntu> yes, something that can be reviewed more easily
<pstolowski> zyga-ubuntu, I know how to do that in LP (set a base branch for a proposed branch), but not with github. let me see
<zyga-ubuntu> pstolowski: I think you can ask github for a diff between any two points
<cachio> zyga-ubuntu, any idea why netlink-audit interface could be denying the connection https://paste.ubuntu.com/26412541/
<cachio> zyga-ubuntu, this is executed with the interface connected https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind
<zyga-ubuntu> [  515.303103] audit: type=1400 audit(1516303185.355:62): apparmor="DENIED" operation="capable" profile="snap.test-snapd-netlink-audit.bind" pid=25254 comm="python3" capability=37  capname="audit_read"
<zyga-ubuntu> this says it all
<zyga-ubuntu> the interface doesn't grant the capability audit_read
<zyga-ubuntu> the interface must define an apparmor rule that grants access to that capability
<zyga-ubuntu> now
<zyga-ubuntu> if this is sane or not, I don't know
<mup> PR core-build#25 opened: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <https://github.com/snapcore/core-build/pull/25>
<pstolowski> zyga-ubuntu, I'm able to do that only if my repo is the landing target
<Chipaca> mborzecki: I hadn't noticed that (but I added those to stress test this :)) but it's interesting; what's doing the stat?
<Chipaca> ogra: you!
<ogra> mvo, https://github.com/snapcore/core-build/pull/25 is an additional one for the topic ...
<mup> PR core-build#25: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <https://github.com/snapcore/core-build/pull/25>
<Chipaca> ogra: you *you* you
 * ogra hugs Chipaca 
<Chipaca> ogra: error: cannot perform the following tasks:
<Chipaca> - Mount snap "packageproxy" (1) (snap is unusable due to bad permissions; contact develper)
<mvo> ogra: thank you, looking
<ogra> huh ?
<ogra> Chipaca, any more details ? i run packageproxy on several machines without issues here
<Chipaca> 2018/01/19 12:46:33.887323 check_snap.go:338: in snap "packageproxy": "meta/gui/icon.png" should be world-readable, and isn't: -rw-------
<Chipaca> ogra: /ÊnËjuËzÉb(É)l/
<ogra> ogra@acheron:~/Devel$ snap services packageproxy
<ogra> Snap          Service  Startup  Current
<ogra> packageproxy  approx   enabled  active
<mborzecki> zyga-ubuntu: are you planning to push more patches to #4502?
<mup> PR #4502: interfaces/builtin: add support for content "source" section (v2) <Created by zyga> <https://github.com/snapcore/snapd/pull/4502>
<ogra> Chipaca, woah
<zyga-ubuntu> mborzecki: not
<zyga-ubuntu> mborzecki: I'm planning a follow up with spread test but it dependson 4471
<ogra> Chipaca, thanks, will fix that (or even drop the icon, we'll see )
<mborzecki> zyga-ubuntu: ok
<cachio> zyga-ubuntu, well the idea of that interface is to access specifically to that
<zyga-ubuntu> cachio: netlink audit vs cap audit_read, fly this past jdstrand and it should be simple to patch
<cachio> zyga-ubuntu, sure, tx
<kalikiana> brrrrrr
<cachio> jdstrand, the test for the netlink-audit interface is getting this denial of the connection https://paste.ubuntu.com/26412541/
 * kalikiana sat on the balcony with the laptop for a bit because it's sunny... but also freezing :-/
<zyga-ubuntu> kalikiana: at least it's sunny
<zyga-ubuntu> kalikiana: it's ~0 but cloudy all day here
<cachio> jdstrand, this is the code https://github.com/sergiocazzolato/snapd/blob/tests-interface-netlink-audit/tests/lib/snaps/test-snapd-netlink-audit/bin/bind
<kalikiana> zyga-ubuntu: sometimes direct sun briefly lets me forget about the cold. not strong enough today it seems
<zyga-ubuntu> my fingers were freezing last time I tried that
<zyga-ubuntu> (but it was far warmer then)
<kalikiana> in fairness, I'm fairly cold tolerant and massively addicted to sun, so I'm persistent :-D
 * kalikiana getting a hot beverage
<ogra> Chipaca, so since i "helped" you so much, mind giving a second ack on https://github.com/snapcore/core-build/pull/25 ? (trivial change)
<mup> PR core-build#25: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <https://github.com/snapcore/core-build/pull/25>
<Chipaca> ogra: ( Â¬_Â¬)
<mvo> ogra: I look forward to the day we can bury writable-path (this is my "Ceterum censeo Carthaginem esse delendam" from now on)
<Chipaca> mvo: "Ceteru censeo /etc etc"
<ogra> mvo, well, if someone comes up with something super bright to replace it :)
<ogra> (i still dont see how ... )
<zyga-ubuntu> mborzecki: updated the layout PR
 * zyga-ubuntu reboots
<mup> PR core-build#25 closed: make /etc/update-motd.d writable for branding purposes <Created by ogra1> <Merged by ogra1> <https://github.com/snapcore/core-build/pull/25>
 * kalikiana lunch
<mborzecki> they're having some perfromance at my daugter's school, gotta run, bbl to read more on apparmor and unix sockets
<zyga-ubuntu> ttyl
<zyga-ubuntu> 4505 needs a 2nd review now
<kalikiana> re
<pstolowski> zyga-ubuntu, updated the desc 4510 with an URL that only shows the relevant changes, minus interface hooks PR
<zyga-ubuntu> pstolowski: thank you!
<zyga-ubuntu> looking
<zyga-ubuntu> pstolowski: small comments there
<pstolowski> thanks
<pstolowski> zyga-ubuntu, re interface-hooks, do you have any suggestion for the naming of test-snapd interface? just snapd-test maybe?
 * zyga-ubuntu walk
<zyga-ubuntu> pstolowski: I'll be back in one hour
<pstolowski> k
<zyga-ubuntu> pstolowski: hmm, maybe 'dummy
<zyga-ubuntu> or fake or something appropriate
<zyga-ubuntu> so that it is a "real" interface
<zyga-ubuntu> just a no-op
<pstolowski> indeed, nice idea
<zyga-ubuntu> no-op
<mvo> hm, I have a peculiar issue here - when I run snapcraft inside travis in my makefile $(DESTDIR) is "" but its clear from the log that make DESTDIR=/dfasf was used and it works locally. (context is https://github.com/snapcore/base-18/pull/34)
<mup> PR base-18#34: add .travis.yml <Created by mvo5> <https://github.com/snapcore/base-18/pull/34>
<zyga-ubuntu> make DESTDIR=foo and DESTDIR=foo make are distint
<zyga-ubuntu> they have different override priorities
<zyga-ubuntu> and now I'm gone, sorry
<kalikiana> mvo: whom are you expecting to set DESTDIR?
<mvo> kalikiana: snapcraft, but I found it now, travis is using an older make so I had to update the makefile a bit
<kalikiana> mvo: you might want to build in lxd to get xenial tooling
<mborzecki> mvo: do you think it makes sense to to look into abstract sockets in #4509 even if those do not seem to be used by systemd for notifications?
<mup> PR #4509: interfaces/builtin: add support for software-watchdog interface <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4509>
<mvo> mborzecki: if they are not used, then no, I think not
<mvo> kalikiana: this is in .travis.yml need to see if that works
<mvo> kalikiana: anyway, I'm good for now,thanks!
<kalikiana> mvo: for the record, yes it does https://github.com/CanonicalLtd/multipass/blob/master/.travis.yml
<mborzecki> mvo: while at it, could you glance over 4509 when you're done with the makefile? :) hope i didn't do anything too stupid there
<mvo> kalikiana: cool
<mvo> mborzecki: sure!
<mborzecki> mvo: thanks
<mup> PR snapcraft#1880 opened: Provide stub for when /etc/os-release doesn't exist <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1880>
<kalikiana> Pharaoh_Atem: ^^ you might be interested in this one. it's the "other distros", but even worse
<Chipaca> kalikiana: workaround: install an actual distro?
<Chipaca> :-)
<kalikiana> Chipaca: nice try :-D
<mborzecki> mvo: thanks for the review, right the reset code is only needed if i use the 'cached' snipped, otherwise i can drop it altogether
<kalikiana> sergiusens: kyrofa FYI snappy-docs#325
<kalikiana> hmmm bot fail
<kalikiana> https://github.com/canonical-docs/snappy-docs/pull/325
<mup> PR canonical-docs/snappy-docs#325: Explain how to use "to" in conjunction with "on" <Created by kalikiana> <https://github.com/canonical-docs/snappy-docs/pull/325>
<Chipaca> mardy: ping
<Chipaca> mardy: your "visualsfm-mardy" has a 0600 file in meta/ that'll make it uninstallable in an upcoming release
<Chipaca> mardy: given the file in question is meta/gui/.VisualSFM.desktop.swp, I suspect it's included in the snap in error
 * kalikiana calling it a week
<zyga-ubuntu> re
<Chipaca> I think I'm calling it a week as well
 * Chipaca needs to go to the shops, might as well go now
<zyga-ubuntu> ttyl
<mborzecki> i'm done for this week too
<mborzecki> enjoy your weekend guys
<kyrofa> I swear, whenever I need to record some sound effects someone decides to cut down a tree
<ikey> *snort*
<kyrofa> It must be the biggest tree of all time, too
<zyga-ubuntu> kyrofa: I hope the tree respawns for another recording session
<jamesb192> I am working on a *ntoo package for snapd. I have a manifest of files in the latest iteration of the package -> https://paste.debian.net/1006034/ . How much am I missing?
<kyrofa> jamesb192, you probably want zyga-ubuntu, but he may be gone already (he's in Poland)
<jamesb192> I figured. I worked from his blog post on centos. It will keep.
<palasso> jamesb192: There was a gentoo overlay that had been done about 1.5 year ago
<jamesb192> the latest there was 2.15.2 I'm working on 2.30 atm. git pull will come later.
<SuperJonotron> docker snap on ubuntu core giving "no space left on device" error
<SuperJonotron> plenty of space left, completely removed all containers, images and volumes and removed and installed the snap
<SuperJonotron> still reporting this issue which didn't happen until i tried to install a second image
<SuperJonotron> any ideas on how to fix this docker snap issue?
#snappy 2018-01-20
<mup> PR snapd#4511 opened: tests: new spread test for ssh-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4511>
#snappy 2018-01-21
<mup> PR snapd#4512 opened: tests: new spread test for ssh-public-keys interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4512>
<mup> Bug #1744584 opened: Exclude Snap .cache from Dejadup backups <DÃ©jÃ  Dup:New> <Snappy:New> <https://launchpad.net/bugs/1744584>
<popey> ogra_:  do you know if there is a fix of any kind for the ropey wifi in the nanopi-air?
<mup> PR snapd#4513 opened: dirs: fix snap mount dir on Manjaro <Created by mati865> <https://github.com/snapcore/snapd/pull/4513>
<memphisto_> hi
<memphisto_> i've installed LibreOffice as a snap, and i've noticed that it can't open remote files
<memphisto_> it complains they don't exist
<memphisto_> but if i copy them to my home it LO can open them
<memphisto_> do you know of a workaround or a fix for this
<mcphail> memphisto_: you may want to post at https://forum.snapcraft.io/t/call-for-testing-libreoffice-5-4-4/3542 . It may be a use case which has been forgotten about
<mcphail> i'd imagine this would open a can of worms about dealing with gvfs etc
<memphisto_> hi
<memphisto_> sorry i got disconnected; so i'll repeat the question
<memphisto_> does anyone now how to fix issue with LibreOffice(snap) can't access files from remote filesystem
<gunix> is this thechannel for snapd ?
#snappy 2019-01-14
<koala_man> I've installed a snap that just has 'home' permissions. Can I choose to give it unfettered access to my filesystem?
<zyga> Hello
<mborzecki> morning
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<mborzecki> mvo: have you heard from zyga or pedronis?
<mvo> mborzecki: not yet
<jamesh> zyga: hi.  If you're looking at refactoring the user mounts code, I've got a PR with some new spread tests for the behaviour I care about: https://github.com/snapcore/snapd/pull/6313
<mup> PR #6313: tests: add a tests for xdg-desktop-portal integration <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/6313>
<jamesh> this is testing integration with the real xdg-desktop-portal/xdg-document-portal services for a few features
<jamesh> should give coverage for bind mounting a fuse file system owned by a non-root user too
<mup> PR snapd#6371 opened: tests: exclude some more slow tests from runs in autopkgtest <Created by mvo5> <https://github.com/snapcore/snapd/pull/6371>
<mvo> sil2100: hey, good morning! do you happen to know what the autopkgtest test timeout on the autpkgtest servers for tests is. the source in lib/adt_testbed.py defines it as 10000s but I some logs where this seems to be exceeded on amd64 but then I also see logs where we hit a this timeout on i386. do you happen to know more about this?
<mvo> sil2100: aha, correction, arm64 takes longer
<mup> PR snapd#6371 closed: tests: exclude some more slow tests from runs in autopkgtest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6371>
<mup> PR snapd#6372 opened: [RFC] tests: define new "tests/smoke" suite and use that for autopkgtests <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6372>
<pstolowski> mornings
<mvo> hey pstolowski - good morning
<mborzecki> pstolowski: hey
<mborzecki> https://www.reddit.com/r/linux/comments/af9gjf/snap_flatpak_appimage_from_a_software_deployment/
 * Chipaca currently hunting for a tricky, racy failure in snapshots
<Chipaca> I know how to fix it, and I know what the bug is â¦ but I can't trigger it
<Chipaca> a user did instead
<mborzecki> Chipaca: genuine race condition bug :)
<Chipaca> yeah
<mup> PR snapd#6373 opened: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6373>
<mborzecki> pstolowski: something for you ^^
<pstolowski> k
<mborzecki> pstolowski: think i owe you a review too
<pstolowski> mborzecki: oh yes, that would be great
<mup> PR core18#112 opened: hook-tests: add test for the 002,008, 012, 014 hooks <Created by mvo5> <https://github.com/snapcore/core18/pull/112>
<Chipaca> got it!
 * Chipaca takes a break
<mborzecki> pstolowski: left a comment under #6113 not entirely convinced if it's worth the extra test though, so it's up to you
<mup> PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
<pstolowski> mborzecki: thank you, checking
<pstolowski> mborzecki: i'll add a test for this as a followup ok?
<mborzecki> pstolowski: works for me
<pstolowski> mvo: would you like to take a look at #6113 as well (it got reviews from Samuele and Maciej), or can I land it?
<Chipaca> mvo: is 2.37 branched already? if so I could add something to it?
<mup> PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
<mup> PR snapd#6374 opened: snapshotstate: don't task.Log without the lock <Created by chipaca> <https://github.com/snapcore/snapd/pull/6374>
<Chipaca> ^^^ a crasher
<mvo> Chipaca: it is branched
<mvo> Chipaca: adding is easy, just tag for 2.37
<Chipaca> mvo: tagged
<Chipaca> mvo: do i need a separate pr for 2.37?
<mvo> Chipaca: I can cherry pick if its just 1-2 commits
<Chipaca> mvo: I'll keep it to 1
<mvo> Chipaca: \o/
 * Chipaca equips a *glowing* rod of +3 force-push
<popey> When do we plan to add the feature to only update snaps if they're not running?
<mvo> popey: this cycle, zyga is working on this
<mvo> popey: conceptually working on it already, I don't think we have real code yet
<popey> Ok, So the workaround for now is to defer updates, if you don't want something refreshed while you're using it?
<mvo> popey: yeah, its unfortunate
<popey> ok, thanks
<cmatsuoka> is there an interface to allow a snap package to add entries to cron.d, systemd timers or something like that?
<zyga> popey: yes, definitely this cycle
<zyga> popey: we are going to discuss details later today
<zyga> cmatsuoka: no but snaps can use timer units
<zyga> cmatsuoka: you can just define a timer for a given app to run on a schedule
<popey> zyga: ok, thanks. I have passed on the necessary details for deferring snap refresh as a workaround
<zyga> popey: passed where?
<cmatsuoka> zyga: ok thanks, I'll check that
<ogra> cmatsuoka, https://forum.snapcraft.io/t/timer-string-format/6562 should help
<zyga> cmatsuoka: https://docs.snapcraft.io/the-snap-format/698?_ga=2.240122053.717610322.1547464203-2031546527.1547290160 defines the general format
<zyga> the link that ogra gave (thanks! :) is the specific format for timers
<cmatsuoka> got it, thanks
<mup> PR snapd#6374 closed: snapshotstate: don't task.Log without the lock <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6374>
<mvo> Chipaca: ^- also cherry-picked now
<zyga> mborzecki: some comment about connection state APIs: https://github.com/snapcore/snapd/pull/6373/files#r247456024
<mup> PR #6373: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6373>
<mborzecki> zyga: thanks
<mup> PR snapd#6366 closed: cmd/snap-discard-ns: fix name of user fstab files <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6366>
<mup> PR core18#110 closed: [RFC] hooks: add support for `.test` files and add some initial tests <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/110>
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/6365
<mup> PR #6365: cmd/snap-update-ns: manually implement isspace <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6365>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6365 updated with islower/isdigit now
<mup> PR #6365: cmd/snap-update-ns: manually implement isspace <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6365>
<zyga> mvo: replied on https://github.com/snapcore/snapd/pull/6364
<mup> PR #6364: cmd/snap-update-ns: let the go parser know we are parsing -u <Per-user mount ns  ð> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6364>
<mvo> zyga: ta
<zyga> mvo: I think travis is broken on https://github.com/snapcore/snapd/pull/6362
<mup> PR #6362: cmd/snap-update-ns: explicitly check for return value from parse_arg_u <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6362>
<zyga> as in, there's no travis run even registered
<zyga> not sure what to do on that branch
<mvo> zyga: ok, I check it after lunch
<popey> zyga: a prominent developer of applications in our store. Their end users were upset that the app fails when it's refreshed.
<zyga> popey: what's the workaround? I was specifically asking about what the idea is, not who it is for
<popey> defer updates to later when you're not working
<popey> sorry, I thought I made that clear above.
<zyga> thanks, all is good :)
<popey> :)
<pstolowski> mvo: would you like to take a look at #6113 (it got +2 from Samuele and Maciej), or can I land it?
<mup> PR #6113: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6113>
<cachio> mvo, hey
<cachio> mvo, I finished the tests execution
<cachio> but I found some errors related to gpio
<cachio> like thi https://paste.ubuntu.com/p/dWkbxBjrGM/
<cachio> mvo, these are the logs http://paste.ubuntu.com/p/8hQpc94jWW/
<cachio> the interface is not available
<cachio> it is easy to reproduce
<mborzecki> mvo: intersting question, https://forum.snapcraft.io/t/stracing-a-configure-hook/9452
<mborzecki> off to get the kids
<mvo> pstolowski: looking at it in a wee bit, can be merged today, promised :)
<mvo> cachio: oh, interessting
<mvo> mborzecki: interessting forum post indeed, thats food for thought
<mvo> cachio: the gpio issue sounds like a regression :/
<cachio> mvo, yes
<cachio> I though perhaps some change was missing to be merged on the 2.37 branch
<mvo> cachio: needs digging, the test itself changed back in Nov, maybe its just a test issue
<pstolowski> mvo: ok :)
<cachio> mvo, but it pass in the regular google run
<cachio> mvo, I'll give another look and I'll debug it
<mvo> cachio: I think I have an idea
<mvo> cachio: I think it was not run on the external backend before because it had a check for TRUST_TEST_KEYS in the past
<mvo> cachio: however when this got refactored this check was removed
<mvo> cachio: there is no reason for this check, however it indirectly helped it seems
<mvo> cachio: I should have a fix soon(ish)
<cachio> mvo, ahhh, that could be
<zyga> re
<popey> zyga / mvo: (q from developer) "is there a ticket / forum thread / anything else where we can watch for snapd progress" (on not updating/refreshing while open) ?
<zyga> popey: yes, there is
<zyga> popey: let me find it
<popey> (also) " Is there a way for an application to be "pinged" about a new version? Or should it just poll the directory?"
<popey> (it's a classic snap)
<zyga> popey: https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/33
<zyga> but I'm inclined to create a new thread with the things we just discussed
<zyga> popey: eventually yes, not initially
<zyga> popey: it cannot poll anything by itself
<popey> if you do, please link to that thread
<zyga> certainly
<popey> is there no environment variable which indicates you're on an 'old' version or something?
<popey> SNAP_REVISION might help?
<zyga> popey: no
<zyga> popey: I mean, you can look at $SNAP_REVISION
<zyga> popey: but that doesn't change in existing processes
<zyga> popey: the snap will not be refreshed until the app is running
<popey> and it's not robust to be looking in $SNAP/../ ?
<zyga> popey: I will write down the current discussion soon, let's postpone the details until you read that
<popey> ok
<Chipaca> degville: https://pastebin.ubuntu.com/p/WMHpQCFXHm/ <- wdyt?
<Chipaca> mborzecki: ^ also
<Chipaca> things to note: it prints the warning only on install, and before the "done" message, and only once per install action
<mborzecki> s/Warning/WARNING/ ?
<mborzecki> Chipaca: maybe we should point to the docs instead?
<Chipaca> mborzecki: I didn't want to get shouty (it'll be bold though)
<Chipaca> I'll add a space between the warning and the "done" message
<mborzecki> Chipaca: this topic mentions adding /snap/bin to $PATH
<mborzecki> https://docs.snapcraft.io/commands-and-aliases/3950
<Chipaca> seems to help: https://i.imgur.com/YnB3EXV.png
<mborzecki> Chipaca: mhm, nicer
<Chipaca> mborzecki: I was thinking more of a "in this distro, this desktop, this shell, do this to get it on the path: <...>
<Chipaca> "
<mborzecki> Chipaca: sounds like something that could be put in the forum/docs page, once it's in the snap binary it'll be harder to update
<degville> mborzecki, Chipaca: I think we should set up a specific forum topic, that way the comments can help too, especially if this is a common problem. I think that's what Chipaca is thinking anyway.
<degville> But I'm a little worried that we're ignoring the original problem, which is that the snapd installation somehow didn't add it to the path (by just writing instructions on how to add it to the path).
<Chipaca> degville: I'm hoping having the warning pointing to the forum will also tell us about distros that aren't getting the integration done
<Chipaca> so we fix it there
<degville> Chipaca: good point, yep.
<Chipaca> or, say, if $random_shell needs some file in /etc, we could ship it
<Chipaca> etc etc
<mborzecki> Chipaca: something like 'include you $SHELL and distro when reporting a problem'?
<Chipaca> mborzecki: in the forum topic, sure
<ogra> just ask for "snap version" and add "$SHELL" to the snap version output ? ;)
<Chipaca> snap debug environ
<mup> PR snapd#6375 opened: tests: fix enable-disable-unit-gpio test on external boards <Created by mvo5> <https://github.com/snapcore/snapd/pull/6375>
<mup> PR snapd#6364 closed: cmd/snap-update-ns: let the go parser know we are parsing -u <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6364>
<mup> PR core18#112 closed: hook-tests: add test for the 002,008, 012, 014 hooks <Created by mvo5> <Merged by sil2100> <https://github.com/snapcore/core18/pull/112>
<mup> PR snapd#6365 closed: cmd/snap-update-ns: manually implement isspace <Per-user mount ns  ð> <Simple ð> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6365>
<mup> PR snapd#6350 closed: cmd/snap-confine: don't preemptively create .mnt files <Per-user mount ns  ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6350>
<mup> PR snapd#6344 closed: cmd/snap-confine: join freezer only after setting up user mount <Per-user mount ns  ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6344>
<mup> PR snapd#6113 closed: overlord/ifacestate: handler for hotplug-connect task <Hotplug ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6113>
<ahasenack> hi, I asked this user to post to the forum, but here is the original report in case someone is interested: https://askubuntu.com/questions/1108780/permission-denied-when-running-snap-applications-on-ubuntu-16-04-as-a-ldap-use
<mvo> pstolowski: I merged your PR, thanks again for this work! one question/idea inline though, not sure if its useful, I remember we talked about something similar in the past and there extracting common bits was considered unhelpful
<Chipaca> ahasenack: I think the short answer to the user's question is "no"
<Chipaca> ahasenack: the long answer is "no, sorry"
<ahasenack> the home interface is really about /home/<user>, and not the actual home in the case it's different?
<ahasenack> i.e., it's /home/<user>, and not $HOME?
<zyga> mvo: based on our discussion before I'd like to merge https://github.com/snapcore/snapd/pull/6294
<mup> PR #6294: packaging/ubuntu: build with golang 1.10 <Core18> <Created by zyga> <https://github.com/snapcore/snapd/pull/6294>
<Chipaca> ahasenack: the interface itself uses apparmor's idea of what home is
<Chipaca> ahasenack: why?
<Chipaca> there are other parts of the thing that don't understand homes outside of /home/ though
<Chipaca> and nss in a snap won't be happy
<Chipaca> but, I think jamesh mentioned that if you install nscd (or unscd) things should work
<Chipaca> but I haven't tested it
<ogra> also, $HOME is typically pointed to $SNAP_USER_DATA before the snap app is run ... (or did that change) ... so $HOME might not be what you expect
<zyga> ogra: that has not changed
<zyga> ogra: unless it's a snap using classic confinement
<pstolowski> mvo: awesome, thank you! yes, there is probably some potential for extracting common bits. i'll take a look at this kind of refactoring when everything hotplug-related lands; there is almost definately some room for refactoring in unit tests. i'm refraining from it atm as it would only complicate things for my split PRs. might be easier to look at it (and review) as a whole when it's in master
 * cachio lunch
<mvo> pstolowski: sounds good
<mup> PR core18#113 opened: hook-tests: add more hook tests <Created by mvo5> <https://github.com/snapcore/core18/pull/113>
<Chipaca> Wimpress: can you follow what this person is saying? https://forum.snapcraft.io/t/wp-office-no-internet-menu-shortcut-link-solved/9459
<cachio> snap list
<`dw> is there some magic incantation to run a snap program under perf? e.g. 'perf stat snap run' output shows counters are not being inherited by the target application, i assume due to the setuid helper
<zyga> `dw: not that I know of, perhaps we want to support snap run --perf ...
<`dw> well, the point of the exercise to measure cpu and delays of snap itself, not sure how much of that work exists pre-helper
<`dw> i can accomplish the same with isolcpus=, its just a pain :)
<`dw> hmm, perf's cgroup filter can probably do it, unless snap is fiddling with cgroups too
<zyga> `dw: snapd uses cgroups but most snaps cannot use cgroups themselves
<Trevinho> How a snapped application can know its confinement type at runtime?
<Trevinho> checking freezer value to have /snap.* confinement is enough?
<`dw> zyga: joyfully there is a perf_event cgroup that can be used with 'perf stat -G'
<`dw> so after a little digging, it seems the answer to the question of why libreoffice takes twice as long and burns 3x as much cpu starting up than a regular install is due to squashfs. further digging reveals in order to save on memory, all requests to squashfs are serialized in the kernel at least on ubuntu, meaning my 8 thread nvme-equipped computer is entirely wasted for any snap app
<`dw> digging futher on why squashfs at all, i'm hitting a bit of a blank. the snap format page claims it speeds installation and makes it impossible to modify the snap contents, but the speedup is only true during the one-time installation process, after which an extreme penalty is paid for every access (the common case), and it contributes nothing to the user's ability to mutate the snap file (he can just rebuil
<`dw> the squashfs)
<`dw> is there some better snapd design document or similar, or perhaps a better question, has anyone seriously proposed extricating squashfs entirely? its use here seems extremely costly for little gain
<`dw> i noticed various relationships/interactions with lxd, but google doesn't seem to explain those well either
<popey> `dw: that's interesting data, would you be able to put a forum post together for wider spread of the info and discussion? (I suspect many have ended for the day)
<`dw> popey: yeah sure, will try to tidy up and post
<popey> thanks so much!
<popey> I know some of the team are looking at performance issues, and I'm sure they'd appreciate the additional data
<`dw> for now i'm just avoiding the libreoffice snap, the difference is very noticeable
<leinardi> Hi, I'm trying to build a Snap for a Gtk/Python3 app but I am having hard time to find some snapcraft.yaml from similar apps. The app builds with meson and  requires GTK 3.24 (Gnome 3.30) and several Python dependencies all available on PyPI. Does someone know a similar project with a working snapcraft.yaml?
<leinardi> is there a better place where I can look for help? I already tried on the forum but also there I got no answers...
<mup> PR snapd#6376 opened: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
#snappy 2019-01-15
<NickZ> kyrofa: is there any documentation on the changes to the catkin plugin syntax when you specify a base core?
<`dw> is there some way to get around the forum's "new users may only include (1 pictures|2 links)" restriction on the forum?
<mup> PR snapd#6377 opened: tests: auto-clean the test directory <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6377>
<kyrofa> NickZ, sorry, we're not timezone aligned this week at all! When you specify a base, the catkin plugin will use the ROS release that corresponds to it. core/core16 will use kinetic, core18 will use melodic
<kyrofa> We've moved away from being able to specify the rosdistro so that we can ensure we're running the supported ROS distro on the supported ubuntu distro
<mborzecki> morning
<mvo> hey mborzecki !
<mborzecki> mvo: hey hey
<mborzecki> #6370 is finally green
<mup> PR #6370: interfaces/builtin/opengl: allow access to NVIDIA VDPAU library <Created by cgutman> <https://github.com/snapcore/snapd/pull/6370>
<mborzecki> mvo: can you take a look ^^ ?
<mvo> mborzecki: I just have it open - the author has signed our CLA?
<mborzecki> mvo: the cla check is green, hope that's the same as confirmation he's signed it :)
<mvo> mborzecki: yeah, let me do a quick check
<zyga> Good morning
<mvo> mborzecki: yeah, looks good
<mvo> hey zyga ! good morning
<mborzecki> #6326 sound like 2.37 material too, jdstrand requested changes there, but it's fixed already
<mup> PR #6326: interface: raw-usb: Adding ttyACM ttyACA permissions <Created by kubiko> <https://github.com/snapcore/snapd/pull/6326>
<mborzecki> zyga: hey
<zyga> how was yesterday?
<zyga> I saw some failures on master
<mvo> zyga: things are mostly ok
<mvo> zyga: very few failures
<mvo> zyga: afaict at least
<mvo> mborzecki: I taged it 2.37 but will consider it a target of opportunity. I would really like to have the +1 from jdstrand on pr#6326 before merging it
<zyga> mvo: that's good, must have been a fluke on one branch then
<pstolowski> morning
<mvo> hey pstolowski - good morning
<mvo> mborzecki: meh, this configure hook with network-control forum topic is a bit of a can of worms, looks like we have a bug in snap-confine for hooks, the cgroup name is incorrect so no devices are part of the cgroup :/
<pstolowski> oh, what's that?
<mvo> pstolowski: there is this forum topic "stracing a configure hook"
<mvo> pstolowski: and it points to a real bug it seems in snap-confine
<pstolowski> interesting, thanks
<mborzecki> mvo: which topic is that?
<mborzecki> mvo: ah the strace topic
<mvo> mborzecki: yeah, I think I'm close, its quite twisted though
<mvo> mborzecki: anyway, just wanted to let you all know that I look into it (to avoid duplication of effort)
<mborzecki> mvo: no worries, i was looking into https://forum.snapcraft.io/t/restart-a-snap-background-service-on-resume-from-suspend/9182/5, power mgmt can of worms
<mborzecki> i don't understand why it's so convoluted
<mvo> mborzecki: yeah :/
<mvo> mborzecki: thanks for looking into this one
<mborzecki> mvo: about cgroup, iirc we add a bunch of /dev/* by default
<mborzecki> mvo: including /dev/null
<mborzecki> mvo: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/udev-support.c#L168
<mvo> mborzecki: yeah, its all good
<mvo> mborzecki: I mean, its not :)
<mvo> mborzecki: but the code is mostly DTRT, it seems there is a bug in the cgroup name generation
<zyga> re
<mvo> mborzecki: so we do DTRT just to the wrong cgroup (test-snapd-with-configure-nc_hook.hook_configure vs test-snapd-with-configure_nc_hook_configure
<mvo> hey zyga
<zyga> mmm
<mborzecki> mvo: interesting
<zyga> cgroup name for hooks
<zyga> interesting
<zyga> I'll let you handle that but one word of advice
<zyga> device cgroups sticks around
<mvo> zyga: :) ok
<zyga> you can run something and then, at your leisure, look at it later
<zyga> and you can move a shell there for full hands on
<zyga> let me know if you need help with any of that
<mborzecki> pstolowski: hi, can you take a look at https://github.com/snapcore/snapd/pull/6373 ?
<mup> PR #6373: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6373>
<mborzecki> guys, if you have any thoughts about presenting disconnected plugs/slots or undesired connections in the output of snap connections, feel free to share them ehre https://forum.snapcraft.io/t/rfc-snap-connections-command/4296/12
<Chipaca> mborzecki: o/
<mborzecki> Chipaca: hey
<Chipaca> mborzecki: I'll reply there
<mborzecki> Chipaca: sure
<mborzecki> pstolowski: yeah, maybe the endpoint should only return connections, connected or undesired, but no plugs/slots list like we get from /v2/interfaces
<pstolowski> mborzecki: ah, going even further. might be a good idea
<mup> PR snapd#6378 opened:  cmd: fix snap-device-helper to deal correctly with hooks  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6378>
<Chipaca> mborzecki: there ya go
<Chipaca> hah
<mborzecki> Chipaca: thx, reading
<Chipaca> pstolowski: agreed on -d :-)
<Chipaca> woops typo
 * Chipaca fixes
<Chipaca> mborzecki: wrt my last comment, I can do that in a followup if you'd rather not bash your head against tabwriter and escape sequences :-)
<mborzecki> Chipaca: tis fine, go ahead
<mup> PR snapd#6379 opened: ifacestate/tests: extra test for hotplug-connect handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6379>
<Chipaca> degville: o/
<degville> Chipaca: hello!
<Chipaca> degville: PM
<Chipaca> degville: should I create the topic for #6369, or would you rather do it? (if I do it it'll be a placeholder for now)
<mup> PR #6369: Add check for snap binaries dir not being in path <Simple ð> <Squash-merge> <Created by liamg> <https://github.com/snapcore/snapd/pull/6369>
<degville> Chipaca: feel free to create the topic. I guess you'd want it to be as short as possible. I can always add the text.
<Chipaca> degville: I'll leave it unlisted for now :-)
<mup> PR snapcraft#2439 closed: snap: add xslt dependencies for lxml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2439>
<mup> PR snapd#6380 opened: Nm iface add perms <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6380>
<mborzecki> Chipaca: https://paste.ubuntu.com/p/VVNpnmJ6QY/
<mborzecki> still have to add the count of disconnected/unconnected ifaces
<pstolowski> hey marcustomlinson :)
<marcustomlinson> hey pstolowski !
<mborzecki> off to pick up the kids
<pstolowski> mborzecki: can you take a look at https://github.com/snapcore/snapd/pull/6379 ?
<mup> PR #6379: ifacestate/tests: extra test for hotplug-connect handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6379>
<Gargoyle> Hey all.
<Gargoyle> Is there any fix for broken electron snaps on 18.10 yet. I now have no text in atom's menu bar! :/
<Chipaca> Gargoyle: I wasn't aware they were broken :-)
<Chipaca> let me start an 18.10 vm to have a look
<Chipaca> Gargoyle: is there a bug or forum post talking about the issue?
<Chipaca> Gargoyle: I have text in atom's menu bar here
<Chipaca> Gargoyle: https://i.imgur.com/56r236E.png
<Chipaca> mborzecki: Conflicts=sleep.target WFM AFAICT FWIW
<Chipaca> but maybe I should test it a bit more :-)
<mborzecki> Chipaca: interesting, i'll play a bit more with these on the laptop
<jdstrand> mvo: hi! miss you in sunny cape town :)
<jdstrand> mvo: it seems like you are looking into this, so fyi, https://forum.snapcraft.io/t/stracing-a-configure-hook/9452/7
<jdstrand> mvo: also, I'll look at PR 6326 again
<mup> PR #6326: interface: raw-usb: Adding ttyACM ttyACA permissions <Created by kubiko> <https://github.com/snapcore/snapd/pull/6326>
<Chipaca> mborzecki: to be clear, Conflicts=sleep.target works to stop the service before suspending
<Chipaca> mborzecki: you need something else to wake it after resuming
<jdstrand> mvo: re 6326, just need a one character fix then feel free to commit
<Chipaca> mborzecki: you'd think there'd be a resume.targt, but lennart says "Why would a service need something like this? This sounds systematically flawed"
<mborzecki> Chipaca: hahah
<mborzecki> Chipaca: hard to disagree with him
<Chipaca> mborzecki: that's https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744753#30 fwiw
<mborzecki> Chipaca: on a side note, the use case from the forum should probably hook to nelink and act on interface state changes
 * Chipaca covers his ears and goes LALALALA
<zyga> https://github.com/snapcore/snapd/pull/6380
<mup> PR #6380: Nm iface add perms <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6380>
<zyga> this is one terse commit message
<zyga> I re-wrote the PR title
<mvo> jdstrand: cool, will look at it
<mvo> jdstrand: heh - I miss the sun as well! next time I can make it again. I am looking into the strace right now, I think I have a fix
<mvo> jdstrand: not strace, the device cgroup with configure hook support
<mborzecki> Chipaca: left a note in the forum, imo the guy should really be using avahi
<mup> PR core18#114 opened: Set the C.UTF-8 locale for the 001-extra-packages.test <Created by sil2100> <https://github.com/snapcore/core18/pull/114>
<mup> PR snapd#6381 opened: devicestate: add initial Remodel support <Created by mvo5> <https://github.com/snapcore/snapd/pull/6381>
<mborzecki> Chipaca: hm that interface count is quite interesting, the API actually does some filtering and returns only connected interfaces by default, unless the client asked for all
<Chipaca> mborzecki: isn't this the api that you're adding in the same PR?
<Chipaca> #6373
<mup> PR #6373: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6373>
<Chipaca> ah no
 * Chipaca looks more
<Chipaca> #6333
<mup> PR #6333: daemon: introduce /v2/connections snapd API endpoint <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
<mborzecki> Chipaca: not the same PR, but yes, that's the API i'm adding, that's why it's helpful to get some feedback on the functionality people expect
<Chipaca> oh and it's 'changes requested' by me and I never looked again
<Chipaca> I'm a horrible person
 * Chipaca wanders off
<mborzecki> haha :P
<Chipaca> :-)
<mborzecki> Chipaca: so the API actually takes ?select=all to include disconnect plugs/slots and undesired conections, otherwise it's just connected
<mborzecki> i could push everything and filter in the client
<Chipaca> mborzecki: or, add counts to the interfaceJSON (if I'm reading the code right)
<mborzecki> Chipaca: hm some itneresting bits are still missing in that pr
<Chipaca> mborzecki: how is gnome software going to use v2/connections?
<mborzecki> Chipaca: that's what I discussed with pedronis but haven't pushed out yet: https://paste.ubuntu.com/p/G4h3q4n2Zz/
<Chipaca> aha
<mborzecki> Chipaca: Established is what's currently connected, so one does not have to dig inside Plugs/Slots, Undesired is what's manually disconnected
<Chipaca> mborzecki: what about things that aren't undesired and aren't connected?
<Chipaca> i mean established
<Chipaca> i mean: established means connected right now, undesired means manually disconnected?
<mborzecki> Chipaca: yes, established === connected, undesired === manually disconnected
<Chipaca> mborzecki: so what about the other ones?
<Chipaca> where do they appear?
<mborzecki> Chipaca: that's where you dig into Plugs/Slots
<mborzecki> Chipaca: iow, pairs that could be connected, but aren't right?
<Chipaca> yeah
<mborzecki> Chipaca: yup, so that's in Plugs/Slots, unconnected ones have len(Plug.Connections) == 0
<mborzecki> Chipaca: but there is no indication what given plug/slot could be connected to
<mvo> fun! core18 fails to boot in spread :( spread qemu:ubuntu-core-18-64
<mborzecki> Chipaca: to be fair, you could connnect any pair that uses matching interface
<Chipaca> mvo: excessive collisions & not enough packet ambulances ?
<Chipaca> mborzecki: I'm never fair
<mborzecki> hah :)
<mvo> mounting /dev/sda3 on /tmpmnt_writable failed: device or resource busy
<mvo> cachio: ^- could you please have a look? maybe a new kernel or a new core18 that breaks this
<mvo> cachio: I need to leave for ~2h for a kids appointment unfortunately so can't look right now
<cachio> mvo, in 10 minutes after lunch :)
<cachio> mvo, Ill leave the tests running
<mup> PR snapd#6377 closed: tests: auto-clean the test directory <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6377>
<mup> PR snapd#6382 opened: tests: use pc-kernel from stable instead of edge to build core-16 and core-18 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6382>
<Chipaca> ouch, EOD
 * Chipaca runs
<cachio> mvo, hey
<cachio> mvo, same issue I see when I start a core-18 vm locally
<cachio> related to lack of entropy
<cachio> we are currently faking the entropy source on google instnaces, perhaps we could do the same on this core instance before booting it
<mvo> cachio: I was getting a busybox shell when running spread on ubuntu-core-18 here locally
<mvo> cachio: you can run SPREAD_QEMU_GUI=1 spread ...
<mvo> cachio: and then you get the qemu window and can get around the entropy problem
<mvo> cachio: and thanks for looking into it! if reverting to the stable kernel fixes all issues we should probably let the kernel guys know :)
<cachio> mvo, it fixes the problem
<cachio> but now I see other issues becuase it refreshes the kernel snap
<cachio> during the execution
<cachio> mvo, I'll need to omve the IMAGE_CHANNEL to stable too
<cachio> mvo, not sure if it if gonna work
<mup> PR core18#114 closed: Set the C.UTF-8 locale for the 001-extra-packages.test <Created by sil2100> <Merged by sil2100> <https://github.com/snapcore/core18/pull/114>
<mvo> cachio: ok
<mvo> cachio: not sure what is going on, please keep me updated! I can start digging into that in my morning
<cachio> using the image and gadget snap = stable it wokrs
<cachio> it is a workaround until the issue is fixed
<mvo> cachio: yeah, interessting!
<cachio> there is a PR with thnat changge
<mvo> cachio: I wonder if we can figure out what happend, i.e. what the root cause is
<cachio> well, the pc-kernel snap has changed
<cachio> from edge to candidate
<cachio> no idea yet which change on the kernel is producing the error
<cachio> still researching
<mvo> cachio: thank you
<mvo> cachio: interessting, there was a new pc-kernel upload 8h ago and a new one 2h ago
<mvo> cachio: maybe that helped with things?
<mvo> klebers: hey, I saw two kernel uploads recently. one 8h ago and one 2h ago. are there any known issues in the prev kernel or just an update?
<mvo> cachio: do we have all must-have 2.37 PR (that fix the tests etc) tagged in github?
<cachio> I think there are nice to have
<cachio> mvo,
<cachio> It is not needed to add them to 2.37
<mvo> cachio: great, thanks
<cachio> mvo, yaw
<mvo> cachio: I go over the PRs in the morning, I hope we can finalize 2.37 then
<cachio> mvo, great
<cachio> I'll check the status tomorrow morning
<cachio> thanks!!
<mup> PR snapd#6383 opened: tests: provide a fake random device to the core images <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6383>
<kravietz> hi everyone, I build a snap with PhantomJS that works well in  classic mode, but when in full confinement it cannot load libfreetype and libfontconfig libraries, even though they are packaged (in $SNAP/usr/lib...)
<kravietz> I'm a bit confused - from where the confined binary should load the libraries? from system-wide /lib & /usr/lib or the $SNAP/lib $SNAP/usr/lib ? in such case why cannot it see them by default?
<kravietz> LD_LIBRARY_PATH="/snap/webcookies/x23/usr/lib/x86_64-linux-gnu" seems to help but why isn't it set by default if libraries are snapped?
<Gargoyle> In answer to my own question from earlier - In synaptic you can select a package and choose "lock version". So I was able to pick my way through and change from PPA version to official cosmic version.
<Gargoyle> Chipaca: https://i.imgur.com/YVeUqls.png
#snappy 2019-01-16
<zyga> good morning :)
<mborzecki> morning
<mvo> good morning mborzecki
<mborzecki> mvo: so crng init struck core image now?
<mvo> mborzecki: it seems to have done so yesterday - not so sure about today, there was a new kernel update
<mvo> mborzecki: so maybe that fixed things I'm just looking
<mvo> mborzecki: hm, the diff is gigantic, no idea
<mborzecki> mvo: kernel diff?
<mborzecki> mvo: do you have a link?
<mvo> mborzecki: sure: https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic
<mvo> mborzecki: the first one is linux-4.15â¦
<mup> PR snapd#6382 closed: tests: use pc-kernel from stable instead of edge to build core-16 and core-18 <Created by sergiocazzolato> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6382>
<mup> PR snapd#6370 closed: interfaces/builtin/opengl: allow access to NVIDIA VDPAU library <Created by cgutman> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6370>
<mup> PR snapd#6362 closed: cmd/snap-update-ns: explicitly check for return value from parse_arg_u <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6362>
<mvo> degville: could you please do a final look/approval on pr#6369 (the one about PATH)? feel free to merge if you are happy
<zyga> Hey
<mvo> hey zyga
<mborzecki> zyga: hey
<mup> PR snapd#6372 closed: tests: define new "tests/smoke" suite and use that for autopkgtests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6372>
<mborzecki> mvo: PRs are turning green ;)
<mup> PR snapd#6373 closed: overlord/ifacestate: helper API to obtain the state of connections <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6373>
<mborzecki> mvo: wdyt about this one? https://github.com/snapcore/snapd/pull/6383
<mup> PR #6383: tests: provide a fake random device to the core images <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6383>
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mvo> mborzecki: I was thinking about it this morning
<mvo> hey pstolowski
<mvo> mborzecki: I think its ok, we do the same on classic afterall
<mborzecki> mvo: yes, we do
<mvo> mborzecki: but it won't help with the entropy misisng on boot
<mvo> mborzecki: so I think its ok to have it but we shouldn't expect much from it except that it speeds up key generation when we do gpg tests (which iirc we skip on core anyway because we have no gnupg snap)
<mvo> mborzecki: wdyt?
<mborzecki> mvo: yeah, gppg and maybe ssh would benefit
<mvo> mborzecki: aha, ssh indeed
<mvo> mborzecki: that might be a good reason, we generate ssh host keys on first boot
<zyga> re
<mvo> welcome back zyga
<mborzecki> mvo: i'm looking at the prepare code, maybe w could generate the host keys while preparing the image and just copy them over to system-data/etc/ssh/
<mborzecki> this would speed up the first boot
<zyga> hey, how are things on your side guys?
<zyga> I'm looking at debian package update now
<mvo> mborzecki: yeah, that would work
<degville> mvo: will do!
<mvo> mborzecki: we should measure first though
<mvo> mborzecki: I mean, it might be just so fast its not worth the work on our side :)
<mup> PR snapd#6375 closed: tests: fix enable-disable-unit-gpio test on external boards <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6375>
<mup> PR snapd#6326 closed: interface: raw-usb: Adding ttyACM ttyACA permissions <Created by kubiko> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6326>
<klebers> mvo, hi, we have refreshed the pc-kernel snaps to add some fixes to the image. smb has more details about it, he's working on that
<mvo> klebers: thanks for getting back to me. we had trouble with the previous kernel, it failed to boot in most tests but the most recent one is fine again.
<klebers> mvo, we are planning to update soon the version on 18/stable, would that affect someone?
<mvo> klebers: we don't have that many 18 users yet, but let me check
<mvo> hey Chipaca ! good morning
<Chipaca> IÃ¤! IÃ¤! mvo fhtagn!
<mborzecki> haha
<ogra> was that finnish ?
<Chipaca> ogra: the long form is Â«IÃ¤! IÃ¤! mvo fhtagn! Ph'nglui mglw'nfah mvo R'lyeh wgah'nagl fhtagn!Â» if that gives you any more clues
<mborzecki> cthulu language, rly'something
<ogra> oh, chtulu !
 * Chipaca practices for the post-brexit world
<ogra> heh
<Gargoyle> Chipaca: I think you were offline by the time I got back last night. My Atom looks like this :-( https://i.imgur.com/YVeUqls.png
<Chipaca> Gargoyle: looks like a problem in the theme to me
<Chipaca> Gargoyle: is that plain Ubuntu?
<Gargoyle> Yup. 18.10 with Yaru theme
<Gargoyle> I have been playing with builder a few months ago - wonder if some dev libraries are messing things up?
<Chipaca> Gargoyle: is there a bug or forum post talking about the issue?
<Gargoyle> Not that I have found. There is one relating to file open/save dialogs which are all messed up too.
<mborzecki> Chipaca: isn't that some ubuntu specific gtk extension that moved the menu bar somewhere to the top bar under unity?
<Chipaca> mborzecki: in 18.10? not that I'm aware
<Chipaca> Gargoyle: so when you asked "is this issue fixed yet" you were assuming we had some kind of telepathic power? :-)
<Gargoyle> OK. You are correct Chipaca. Switched "Applications" theme to Adwaita and atom's menu and file dialogs look normal again.
<Gargoyle> Chipaca: It's related to the filesystem one
<Gargoyle> *filesystem dialogs one
<Chipaca> Gargoyle: how so?
<mvo> Chipaca: haha - I read a lot of lovecraft but forgot this one
<Chipaca> Gargoyle: in any case I can confirm in 18.10 with the default theme in atom the menu line is black-on-black or something
<Chipaca> also it takes almost a minute to start the first time
<Chipaca> (but this might be the snapd version)
<Chipaca> s/almost/what feels like/
<Gargoyle> It's something to do with the GTK themes and the switch to 18.10 and Yaru. I asked a while ago and someone like popey confirmed there was an ongoing issue. Didn't get a link to a forum post though.
<Gargoyle> I can't find one now ether, so I'll grab some screenshots / video and post one up this morning.
<Chipaca> Gargoyle: ta
<mup> PR snapd#6369 closed: Add check for snap binaries dir not being in path <Simple ð> <Squash-merge> <Created by liamg> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6369>
<mup> PR snapd#6384 opened: snapd: fix race in TestSanityFailGoesIntoDegradedMode test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6384>
<mborzecki> mvo: left a comment ^^
<mvo> mborzecki: \o/ for that
<mvo> mborzecki: excellent catch
<mup> PR snapd#6385 opened: debian: fix silly typo in the spread test invocation <Created by mvo5> <https://github.com/snapcore/snapd/pull/6385>
<Gargoyle> Chipaca: Found the underlying issue - it's electron and not specific to the snap. (https://github.com/electron/electron/issues/15194)
<Gargoyle> dum di dum.... Electron api demo app works fine. Building atom from source...
<mup> PR snapcraft#2437 closed: repo,baseplugin: support trusting repo keys <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2437>
<pstolowski> mborzecki: hey, can you take a look at https://github.com/snapcore/snapd/pull/6379 ?
<mup> PR #6379: ifacestate/tests: extra test for hotplug-connect handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6379>
<mup> PR snapd#6386 opened: tests: skip lp-1802591 on "official" images <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6386>
<pstolowski> (the test you suggested in previous hotplug PR)
<mborzecki> pstolowski: ack
<pstolowski> thanks
<greyback> hi all, can anyone interpret why spread failed for me: https://travis-ci.org/snapcore/snapd/builds/479834032 ?
<mborzecki> Chipaca: i've updated #6333
<mup> PR #6333: daemon: introduce /v2/connections snapd API endpoint <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6333>
<mborzecki> greyback: sorry the link doesn't seem to work, which PR is this?
<mborzecki> greyback: 6361?
<greyback> mborzecki:  https://github.com/snapcore/snapd/pull/6361
<mup> PR #6361: kvm: load required kernel modules if necessary <Created by gerboland> <https://github.com/snapcore/snapd/pull/6361>
<greyback> yep
<mborzecki> greyback: hmm, the link to travis job from the PR doesn't work either, wth?
<zyga> mvo: hey, can we get the 2.37 release tarballs on the release page please
<greyback> mborzecki: hmm, I just tried it now, broken here too ("We couldn't find repo snapcore/snapd") Worked ~10 mins ago
<mborzecki> travis induced coffee break :)
<greyback> :D the new https://www.xkcd.com/303/
<zyga> mvo: I'm working on the 2.37 debian update
<zyga> finally got over the hurdles there
<zyga> (in the early prep of how-do-I-even-start)
<mborzecki> greyback: i've restarted the spread job
<greyback> mborzecki: thank you
<zyga> or I guess I can do that too
<Chipaca> mborzecki: is connectionJSON used outside of api_connections/
<Chipaca> ?
<Chipaca> mborzecki: in the whole picture i mean
<mborzecki> Chipaca: yes, there's corresponding struct in the client package
<mborzecki> planned to push the client bits to #6016
<mup> PR #6016: [RFC] move various name validation helpers to snap/name package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6016>
<mborzecki> uh, #6079
<mup> PR #6079: [RFC] `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
 * pstolowski lunch
<Chipaca> mborzecki: is there a reason to have the structs twice? I've been trying to avoid that unless there's a reason
<Chipaca> bah, maybe it's "it still uses the old json stuff that's in daemon and i didn't want to refactor", that's a reason for example :-)
<zyga> cachio: hey, what's the state of 2.37
<zyga> I'm trying to determine if the debian update should go with 2.36.x or with 2.37
<zyga> mvo: ^ CC please comment as well if you can
<mvo> zyga: 2.37
<zyga> mvo: hey :)
<mvo> zyga: I'm working on it right now and we should (fingers crossed) have a 2.37 final today or tomorrow
<zyga> I tried to get the tarballs and I was in a busy meeting
<mvo> zyga: I really really want it today
<zyga> is there a .0 release yet?
<zyga> and you will go with .1
<zyga> or is the work now focused on 2.37.0
<mvo> zyga: its not out just yet, we are at 2.37~rc1
<mvo> zyga: two more PRs
<zyga> ok
<mvo> zyga: one race fix, one autopkgtest fix
<zyga> I'll continue to assess the debian side, we should have some actions there
<zyga> for one
<mvo> zyga: and  thanks for working on the update
<zyga> I would like to go through all the build deps
<mvo> zyga: \o/
<zyga> (which are really runtime deps)
<cachio> zyga, hey
<zyga> and then check if we are comfortable with them being as old as they are
<zyga> hey cachio, how are you doing?
<mvo> zyga: there is one potential PR I might pull in (6378)
<cachio> zyga, initial validation for pre~1 is completed
<zyga> mvo: and if no, actually go to salsa, work on updates (despite most likely missing this freeze)
<cachio> zyga, mvo is gonna generate a new release soon
<zyga> mvo: and I would honestly put this on us each release
<zyga> mvo: where if we pay the painful price now once
<zyga> mvo: we should be in a good place for each release (it should be cheap)
<cachio> mvo, next friday 25 is my last day before vacations
<cachio> mvo, I mentioned that in the standup but I think you were already on vacations
<cachio> it was on december
<mvo> cachio: ok
<mvo> cachio: should be enough time for the validation
<mvo> zyga: yeah, maybe we need to do it
<mvo> zyga: not great but better than the alternatives it seems
<cachio> mvo, I hope so
<mup> PR snapd#6387 opened: client: introduce helper for querying snapd API for the list of slot/plug connections <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6387>
<mborzecki> Chipaca: opened the client bits ^^
 * Chipaca shakes fist at the internet at large, and goes for coffee
<diddledan> â
<cachio> pstolowski, hey
<cachio> pstolowski, when you have time, could you please take a look to this one? #5887
<mup> PR #5887: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
<cachio> pstolowski, it is related to nested suite
<pstolowski> cachio: will do
<Gargoyle> How do we find out who is currently doing the packaging for Atom if it currently just says "snapcrafters" on the store page?
<cachio> pstolowski, thanks
<diddledan> Gargoyle: that's the snapcrafters, which means anyone on the snapcrafters org lead by popey and wimpress
<mup> PR snapd#6385 closed: debian: fix silly typo in the spread test invocation <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6385>
<Gargoyle> diddledan: OK. I've got a "working" build of atom. I say "working" because the menu and file dialogs are rendering properly but atom's own test suite fails horribly. But I can't get my head rount the branching on atom's github page! :/
<mup> PR snapd#6359 closed: tests: fix listing tests to match "snap list --unicode=never" <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6359>
<mup> PR snapd#6386 closed: tests: skip lp-1802591 on "official" images <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6386>
<mvo> 6384 needs a second review
<mup> PR snapcraft#2440 opened: meta: make hooks executable instead of complaining they're not <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/2440>
<diddledan> Gargoyle: the snap of atom is created from https://github.com/snapcrafters/atom
<pstolowski> cachio: btw 5887 has conflicts
<cachio> pstolowski, ohh, sorry
<cachio> pstolowski, fixed
<cachio> thanks
<mborzecki> mvo: i think we could land #6368 as it is now, even with the typo, given the spread job on master has failed because of this problem
<mup> PR #6368: tests: fix daemon-notify test checking denials considering all the log lines <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6368>
<mvo> mborzecki: if you are happy with it: +1
<mup> PR snapd#6368 closed: tests: fix daemon-notify test checking denials considering all the log lines <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6368>
<mvo> mborzecki: thank you!
<mup> PR snapd#6378 closed:  cmd: fix snap-device-helper to deal correctly with hooks  <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6378>
<mvo> 6384 needs a second review
<Chipaca> mvo: lgtm
<mvo> ta!
<mup> PR snapd#6384 closed: snapd: fix race in TestSanityFailGoesIntoDegradedMode test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6384>
<Gargoyle> Seems I'm trying all the broken snaps today! :/
 * ogra hugs Saviq for https://bugs.launchpad.net/bugs/1812003
<mup> Bug #1812003: hooks should be made executable instead of erroring out <Snapcraft:New> <https://launchpad.net/bugs/1812003>
<Gargoyle> Jenkins can't use https (probably any SSL) due to a trust store error.
<mup> PR snapd#6388 opened: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
<Gargoyle> Does it need access to etc/ssl ?
 * cachio lunch
 * zyga resumes work on debian packaging
<zyga> eh, quilt
<zyga> how I love the
<zyga> (not)
<zyga> thee
<Gargoyle> created report here:- https://forum.snapcraft.io/t/jenkins-cannot-access-update-server-via-https/9499
<mup> PR snapd#6389 opened: cmd/snap: small refactor of cmd_info's channel handling <Created by chipaca> <https://github.com/snapcore/snapd/pull/6389>
<mup> PR snapd#5887 closed: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
<Chipaca> ok, EOD from me
<Chipaca> ttfn
<mup> PR snapd#6390 opened: release: 2.37 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6390>
<mvo> cachio: all arches have 2.37 in beta now, just fyi
<cachio> mvo, great
<cachio> starting right now
<mvo> cachio: \o/
<mup> PR snapd#6390 closed: release: 2.37 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6390>
<mup> PR snapd#6391 opened: tests: simplify interfaces-contacts-service test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6391>
#snappy 2019-01-17
<mborzecki> morning
<mvo> hey mborzecki - good morning
<mborzecki> i see that 2.37 is out :) time to update arch packages
<mvo> mborzecki: yeah, I need someone approve the SRU uploads still but otherwise most things are in place now
<zyga> Hi
<mvo> hey zyga
<zyga> Hey, all good
<zyga> Details later today :-)
<mup> PR snapcraft#2441 opened: legacy/meta: make hooks executable instead of complaining they're not <Created by Saviq> <https://github.com/snapcore/snapcraft/pull/2441>
<mborzecki> pushed an update to arch, seems to work fine locally
<pstolowski> hey
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<zyga>  hey pawel
<zyga> mborzecki: thank you :)
<zyga> I will push suse updates after returning
<zyga> I want to test them locally
<mup> PR snapcraft#2442 opened: cli: enable cleaning of parts <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2442>
<mborzecki> turns out that plug name sorting spread error was a regression after all
<mborzecki> and we're missing a unit test for /v2/interfaces (legacy connections) that checks whether returned data is sorted
<mborzecki> snap interfaces makes doesn't do anything about sorting of plugs/slots and conencted endpoint, so i guess it's implied that the data is sorted already
<pstolowski> mborzecki: was it a regression after yesterday's PR?
<pstolowski> need 2nd review for simple https://github.com/snapcore/snapd/pull/6379
<mup> PR #6379: ifacestate/tests: extra test for hotplug-connect handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6379>
<Chipaca> huh, I don't  understand #6388
<mup> PR #6388: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
<mborzecki> pstolowski: no, it's a regression in my connections endpoint PR
<Chipaca> for two reasons: that install test should fail all the time now because of #6339
<mup> PR #6339: cmd/snap: only auto-enable unicode to a tty <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6339>
<Chipaca> but at the same time --unicode=never should not make a difference, for the same reason
<Chipaca> so somehting's off
<pstolowski> mborzecki: ack. the client should be fixed to sort imho
<mborzecki> Chipaca: there shuld be a git revision in the build log that cachio linked
<mborzecki> s/shuld/should/
<mborzecki> Chipaca: heh, can't find one :/
<Chipaca> mborzecki: issue is on master as well
<Chipaca> mborzecki: I suspect there's a sneaky en dash that isn't coming from an escapes struct
 * Chipaca greps
<mborzecki> heh, en dash, wreaking havoc since MS started replacing - with it in their office/outlook suites :P
<Chipaca> actually, no
<Chipaca> that's never an en dash
<Chipaca> what
<Chipaca> ah
 * Chipaca stops, steps back, and hits the coffee
<kyrofa> That's always my solution as well
<Chipaca> mborzecki: I was so indignant at people using 1252 instead of latin 1
<mborzecki> Chipaca: 1250 here :P
<Chipaca> mborzecki: I guess you had the same thing going with latin 2?
<mborzecki> Chipaca: yup
<Chipaca> although probably not as bad, given what html 5 does
<mborzecki> Chipaca: haha, https://github.com/snapcore/snapd/pull/6388#discussion_r248595404 so the font rendering i get in FF makes - and en dash virtually indistinguishable
<mup> PR #6388: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
<Chipaca> mborzecki: https://github.com/snapcore/snapd/blob/master/cmd/snap/main.go#L500
<mborzecki> Chipaca: at 250% zoom it's slightly longer and slimmer than -
<mup> PR snapd#6392 opened: interfaces: helpers for sorting plug/slot/connection refs <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6392>
<mborzecki> trivial one ^^
<Chipaca> mborzecki: connRef already has sorting tests?
<mborzecki> Chipaca: yes
<mborzecki> just above the first hunk in sorting_test.go
<mborzecki> i'm suprised how the test suite is mostly non-flaky recently
<Chipaca> mborzecki: don't jinx it
<mup> PR snapd#6392 closed: interfaces: helpers for sorting plug/slot/connection refs <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6392>
<mborzecki> prepare of google:arch-linux-64:tests/{main,regression,completion,smoke}/ suites failed, with an awkward error
<kenvandine> pedronis`: https://bugs.launchpad.net/snapd/+bug/1768419
<mup> Bug #1768419: Pass through snapd client User-Agent to store requests snapd <snapd:Triaged> <https://launchpad.net/bugs/1768419>
<Chipaca> kenvandine: ?
<kenvandine> Chipaca: we were just discussing that and i was sending pedronis` the link
<Chipaca> fwiw we do now have context in more places, but it'd still be a bunch of work to get it everywhere
<Chipaca> (context is needed to do what that says)
<kenvandine> Chipaca: could you comment on that bug with any concerns?
<kenvandine> we are trying to make sure the store team is on board as well
<Chipaca> kenvandine: is "it's work" a concern? :-)
<kenvandine> a little
<kenvandine> it's something we really want
<kenvandine> not just us but advocacy
<Wimpress> degville: Do you have any docs (draft or otherwise) that explain the key signing of snaps?
<Wimpress> I have an ISV asking after details for a security review.
<mborzecki> Chipaca: pushing that user-agent info through all the layers without context sounds nightmarish
<Chipaca> mborzecki: "a lot of work"
<mborzecki> Chipaca: and when complete, it'd probably be nothing to be proud of :)
<Chipaca> mborzecki: eh, dunno about that
<Chipaca> mborzecki: it is the kind of thing that would make a refactor of daemon more urgent though
<degville> Wimpress: no, sorry - not specifically. The closest is likely the Ubuntu Core image building doc: https://docs.ubuntu.com/core/en/guides/build-device/image-building.
<Chipaca> anyway, commented there
<Chipaca> degville: Wimpress: wasn't there a whitepaper?
<Wimpress> degville: I suspected ;-) Thanks for looking. I'll prepare a reply.
<Wimpress> I have the whitepaper, very old now. Orientated toward Ubuntu Core rather than just snaps.
<degville> Wimpress: we can create one - happy to prioritise it - especially if there's a Whitepaper.
<Wimpress> degville: Please do add creating snap signing/integrity checking to your TODO list :-)
<degville> Wimpress: will do - thanks. This seems important.
<Wimpress> I'll prepare a reply and let the ISV know this is something we're working on.
<mup> PR snapd#6393 opened: packaging: import debian salsa packaging work <Created by mvo5> <https://github.com/snapcore/snapd/pull/6393>
<greyback> hey, I'm trying to install Core on my RPi3 - I used the edge image - it has stuck at the account email setup with "x509: certificate expiired or not yet valid". Appears networking set up ok, I can ping and attempt ssh connection. Any idea what's wrong?
 * Chipaca â lunch
<popey> greyback: time and date wrong?
<greyback> popey: how can I check that?
<greyback> this is during Core first setup
 * greyback plugs out and in again, in case it helps
<greyback> nope
<popey> I don't know, but that's where cert errors often come from
<popey> also if you're behind a proxy
<popey> are you in capetown? Is the IS transparent proxy in the way and doing something silly?
<greyback> no, but I'm in a new office
<ppisati> ogra: how do i install hcitool in ubuntu core? core16 doesn't have it
<cwayne> ppisati: bluez snap
<popey> greyback: does it have a captive portal?
<greyback> popey: no, and no sign of a proxy.
<ppisati> cwayne: yeah. i found it
<popey> greyback: does it work in a vm? on your laptop?
<greyback> popey: worth a shot
<popey> Otherwise I'm a bit out of ideas, sorry.
<popey> But it all smells of crappy network doing stuff if your certificates are wonky
<popey> (also, does a core16 image work?)
<greyback> popey: thanks for the help. I've mostly carted around VMs, so this is the first time I've done the core initial setup in a while
<greyback> I'll see what I can figure out
 * pstolowski lunch
<mup> PR snapcraft#2443 opened: schema: allow before and after <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2443>
<zyga> mvo: hey
<zyga> mwhudson: thank you!
<zyga> mvo: I wasn't aware (or I missed because steve told me) that mwhudson is going to be back today
<zyga> mwhudson: we're working on the 2.37 debian release
<zyga> mwhudson: I think it's safe to say that we will sync with you next week, this week we're okay and it's best that we just take the responsibility of landing this release out there, we can definitely upload more changes later if needed
<zyga> mwhudson: we also discussed ideas on how to improve the situation in both snapd upstream (how to test it so that we detect this early) and in debian (improvements to salsa packaging, packaging missing things, updating packages for stale things)
<zyga> mvo: mwhudson ran tests on debian kernel and they did not fail so I suspect some interaction between unit tests and ubuntu kernel running in debian userspace chroot
<mborzecki> off to pick up the kids from school
<ogra> ppisati, it comes with the bluez snap
<ppisati> ogra: yep, found it
<ogra> ppisati, btw, the forum indicates that more and more people use your sample-kernel trees from GH ... are they still kept up to date ?
<ogra> (/me saw three users alone in the last ten days)
<ogra> (different ones)
<mvo> zyga: aha, cool
<mvo> mwhudson: https://github.com/snapcore/snapd/pull/6393 <- might be interessting for you (cc zyga)
<mup> PR #6393: packaging: import debian salsa packaging work <Created by mvo5> <https://github.com/snapcore/snapd/pull/6393>
<zyga> mvo: I'll gladly look next week unless you believe there is some value to cherry pick as debian/patches
<mvo> zyga: if you package works, no need to cherry pick anything
<mvo> zyga: if the package does not work there might be fixes worth getting there
<ppisati> ogra: they never meant to be updated, they are just there as an example how to make your kernel work with ubuntu core
<ogra> hmm, k, people seem to actually use them
<Chipaca> getting tea, bbiab
<ppisati> ogra: what's the best strategy to build a snapdragon ubuntu core image that uses a kernel snap with a custom dtb?
<ogra> ppisati, build a normal image, put dtb into system-boot partition next to the default one, stop boot at u-boot prompt and point to the new dtb with the fdt_file var (or however that was called on db)
<ogra> if you actually want to build from scratch and your dtb has a special name, you need to build a modified gadget with changed uboot.env.in with the same change as above
<ogra> easiest is indeed just building a default image and simply ship your dtb in your kernewl snap as a replacement of the default file ... (same filename) then you dont need to touch anything
<ppisati> ogra: ok so, my kernel snap contains the custom dtb and it has the same name, does it replace the one from the gadget snap?
<mborzecki> Chipaca: looking at the overlord loop, looks like we could detect when the time jumps by some reasonable amount (eg. some mulitple of ensure intervals?) and skip one call to ensure
<ogra> there is none in the gadget snap on db
<ppisati> *the same name as the one normally used to boot the board
<ogra> it is used from the kernel snap
<ppisati> ogra: oh cool
<ogra> so as long as you keep the same name it will just be used
<ogra> even if you manually install your kernel snap on an image
<ppisati> ogra: k, thanks
<mborzecki> Chipaca: anyways, we'll know more once we have some feedback from popey
<Chipaca> mborzecki: time changed between 1.6 and 1.11 (was it 1.7?) and started including two times per time
<Chipaca> mborzecki: we'd have to test both :-)
<Chipaca> but, yes
<Chipaca> mborzecki: that is, 1.6 didn't have monotonic timers
<mborzecki> Chipaca: we're switching to 1.9 though? :P
<Chipaca> mborzecki: so if the machine suspends for an hour half an hour before a dst change, Â¯\_(ã)_/Â¯
<Chipaca> mborzecki: aye
<mborzecki> Chipaca: i mean we can try and reduce the changes of this happening, but that's probably it
<zyga> Chipaca: papercut: search for test that uses "snapname" and revision 42
<zyga> it's not mocking and ends up writing to ~/snap/
<Chipaca> zyga: ouch
<Chipaca> zyga: spread, or unit?
<zyga> :)
<zyga> unit
<zyga> maybe sudo mkdir snap/snapname
<zyga> and chmod 000
<zyga> to catch it
<Croepha> is there still a download for ubuntu core?
<zyga> Croepha: https://www.ubuntu.com/download/iot
<zyga> mvo: about cmd/snap-seccomp, question about build-deps
<zyga> do I recall correctly that needs some i386 headers?
<Croepha> zyga: thanks :)
<zyga> if so, how is that expressed?
<zyga> https://www.irccloud.com/pastebin/lvJKcDgF/
<mvo> zyga: I don't remember, maybe thats it
<zyga> I wonder how that looks like because nothing in debian/control looks appropriate
<Chipaca> zyga: instead of making me hunt, if you already know the test can you tell me? if you don't then i can hunt no problem
<Chipaca> there are a lot of tests in snap-exec that use snapname at rev 42
<Chipaca> also snapenv
<zyga> Chipaca: I don't know the test
<zyga> just noticed when I ran go test ./...
<zyga> uh
<zyga> ok
<zyga> not urgent :)
<Chipaca> ok
<zyga> dreaded 42 :)
<Chipaca> mborzecki: https://github.com/davecheney/junk/blob/master/clock/clock_linux.go fwiw
<mborzecki> shall we land #6388?
<mup> PR #6388: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6388>
<Chipaca> mborzecki: +1
<mup> PR snapd#6388 closed: tests: fix install-snaps test by changing the snap info regex <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6388>
<roadmr> Chipaca hi :) does snapd 2.37 currently in beta have full support for epochs?
<Chipaca> roadmr: define "full support"
<Chipaca> roadmr: #6356 isn't on master yet, so 2.37 doesn't have it, so I don't consider epochs "done"
<roadmr> Chipaca: hm I guess not refreshing to a revision of the snap that isn't epoch-compatible with the one I have
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<roadmr> Chipaca: ah - yes, that was sort of it, I didn't check/track the actual PR. I'll keep an eye on that one then :) thanks!
<Chipaca> roadmr: the "don't refresh if not epoch-compatible" work is in 2.37 yes
<roadmr> Chipaca: (and indeed it was to mention something about epochs in our weekly report - but I'll just leave it at "RSN!")
<roadmr> Chipaca: ah, so #6356 is the "eager refresh" thingy?
<mup> PR #6356: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <https://github.com/snapcore/snapd/pull/6356>
<Chipaca> roadmr: yes
<roadmr> great! thanks Chipaca
 * cachio lunch
<mup> PR snapd#6394 opened: tests: iterate getting journal logs to support delay on boards <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6394>
<mup> PR snapd#6395 opened: cmd/snap: use a fake user for 'run' tests <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6395>
<Chipaca> zyga: ^
<cachio> mvo, 2.37 is in candidate
<mvo> cachio: yay
<mvo> cachio: thank you!
<cachio> mvo, :)
<zyga> Chipaca: thank you!
<cachio> mvo, yesterday I saw a mount error again
<cachio> forgot to mention :(
<cachio> I think it was on 2.37
<cachio> on ubuntu-core-18
 * zyga EODs
<cachio> zyga, is it needed the change I did time ago on upgrade backend?
<zyga> cachio: I don't know what you mean, sorry
<zyga> I'm too tired today
<zyga> long day
<zyga> 7:30 -> 19:30
<cachio> zyga, ahh, ok
<cachio> let's talk tomorrow
<zyga> +1
<cachio> thanks
<mvo> cachio: oh? if you see the mount error again, please give me an url, that is really sad if the bug is not actually fixed
<mup> PR snapd#6393 closed: packaging: import debian salsa packaging work <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6393>
<mup> PR snapd#6396 opened: packaging: import debian salsa packaging work <Created by mvo5> <https://github.com/snapcore/snapd/pull/6396>
<zyga> mwhudson: hey, for tomorrow, just to let you know, we are working on the package with mvo
<zyga> mwhudson: my fork of salsa is at https://salsa.debian.org/zyga-guest/snapd/commits/debian
<diddledan> https://openfaas.bowlhat.net/function/awesomify?q=snap+craft
<Pharaoh_Atem> popey: did you poke anyone to add CentOS/RHEL 7 instructions for installing and using snaps?
<Pharaoh_Atem> I didn't do all that work to make it available in EPEL for nothing, did I? :P
<popey> haha!
<popey> I did poke, I need to re-poke
<popey> will do so tomorrow morning
<popey> Thanks for the nudge
<zyga> indeed!
<mwhudson> zyga: great
<mwhudson> zyga: didn't you get your dd hat yet?
 * cachio afk
<mup> PR snapd#6397 opened: tests: Use backend: [autopkgtest] for smoke test suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6397>
#snappy 2019-01-18
<Chipaca> mwhudson: o/
<mwhudson> Chipaca: hello
<Chipaca> mwhudson: question about snapd on debian
<Chipaca> mwhudson: in 'man snap', if you look for the entry for 'info', is it indented too much compared to the other commands?
<mwhudson> Chipaca: let's see
<Chipaca> if so, that's the main bug we revved go-flags for
<Chipaca> there are others around it using too much space needlessly, but those are less ugly
<Chipaca> in any case it's not something critical :-)
<mwhudson> ha this chroot doesn't have man
<Chipaca> I'd make fun of your chroot, but UC doesn't have man either
<mwhudson> Chipaca: man page looks like this https://paste.ubuntu.com/p/Qq7KPtZrQq/
<mwhudson> which is pretty bad (what are those Help Options about?) but doesn't sound like what you are saying
<Chipaca> whoa
<Chipaca> mwhudson: well, maybe
<Chipaca> mwhudson: we "hid" the help options
<Chipaca> mwhudson: which starts showing off the other bug, where it doesn't de-dent if a command only has hidden options
<mwhudson> this is 2.30
<mwhudson> ah ok
<Chipaca> so then we fixed go-flags
<mwhudson> is the fix upstream?
<Chipaca> yes
<mwhudson> i guess i can rev it in debian and see what falls out there
<Chipaca> the fix is https://github.com/jessevdk/go-flags/commit/14b8957836290f46f473f39b104761889b2f0af0
<Chipaca> but there are a bunch more fixes that are nice to have so if you can rev it, all the better
<mwhudson> bah not in latest release
<Chipaca> psh, "releases", who uses those
<Chipaca> anyway, I should go do that "sleep" thing that seems popular around here
<Chipaca> just out of FOMO
<mwhudson> Chipaca: good night
<Chipaca> \o
<mwhudson> heh https://github.com/jessevdk/go-flags/issues/288
<Chipaca> yeah what he said
 * Chipaca â zzzz
<mup> PR snapd#6398 opened: tests: update systems for google sru backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6398>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> wow amdgpu-pro driver is a mess, no wonder nobody uses it
<mvo> mborzecki: meh! on fridays I only want good news ;)
<mborzecki> mvo: good news: today is friday :P
<mvo> mborzecki: heh :)
<mborzecki> heh no way that driver is going to work on arch, it's super outdated and i'd have to downgrade xorg and the kernel :/
<mup> PR snapd#6398 closed: tests: update systems for google sru backend <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6398>
<zyga> hey ho
<zyga> mvo: I'm back to work from yesterday
<zyga> my two multipass machines lost their disks, I fortunately pushed everything out
<mborzecki> zyga: mvo: left some comments in the debian packaging pr
<zyga> mborzecki: thank you
<zyga> mborzecki: I think my focus today is to do the downstream package release
<zyga> it still fails to build correctly
<zyga> unit tests fail in sbuild
<zyga> but pass in the same machine running debian 10 normally
<zyga> some a bit mysteriously
<mborzecki> oh, sbuild is just chrot?
<mborzecki> chroot
<mvo> mborzecki: thanks!
<mvo> zyga: I had the "smoke" suite passing and the main ones are running but of course that is not inside sbuild
<mvo> zyga: also its still a snapshot, would love to try a 2.37.1 package build from a git tag too
<zyga> mvo: yeah,
<zyga> ideas on why it would fail in sbuild appreciated
<zyga> I'm rebuilding my environment
<mvo> zyga: let me try to run the import-debian-salsa-no-history .dsc in sbuild
<mvo> (this will take a bit to setup the env)
<zyga> import-debian-salsa-no-history?
<zyga> that's a branch?
<zyga> I haven't look at git much yet
<zyga> ah
<zyga> mvo: do let me know if you have any unit test failures
<mup> PR snapcraft#2443 closed: schema: allow before and after <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2443>
<mup> PR snapd#6399 opened: packaging: make sure that /var/lib/snapd/lib/glvnd is accounted for <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6399>
<mborzecki> zyga: ^^ no rush, you can look at it when you get back
<zyga> mborzecki, mvo: shall we merge the opensuse packaging branch
<zyga> and then separately have someone look at bcond/with part of it
<zyga> because I think we are paying the price for the divergence way too often
<zyga> and that is managed there
<mborzecki> zyga: sounds good to me
<zyga> mborzecki: +1 on your branch but I'd rather work on reusing that for arch/debian than just keep whack-a-mole
<zyga> mvo: if you agree then let's please land the opensuse PR
<zyga> and if we do a .1 I would have an easier life for suse release too
<pstolowski> mornings
<mborzecki> pstolowski: hey
<zyga> hey pawel
<zyga> oh, btw, I will be off on monday
<mborzecki> zyga: i can later look into bcond_with thing, hopefully my opensuse installation is still working
<zyga> mborzecki: thank you
<zyga> actually
<mvo> zyga: I need to look at this again, I'm slightly wary that it might lead us to a tangent that makes the debian release slower, but I really need to look first
<zyga> mvo: it's not affecting debian
<zyga> mvo: it's an opt-in
<zyga> only suse uses it now
<zyga> any work to enable it for more distros is explicit
<zyga> but
<zyga> it's a reference list to look at
<mvo> zyga: ok, I check it out in a wee bit, just need to do one more remodel thing
<zyga> thank you!
<zyga> it's not urgent but I'd love to improve upon that
<zyga> and not stay in the current split model where we pay the price for each distro/release
<mup> PR snapcraft#2444 opened: snap: move to core18 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2444>
<zyga> mvo: any luck with sbuild and tests?
<zyga> hey Chipaca :)
<Chipaca> moin moin
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6395#pullrequestreview-193983092 :)
<mup> PR #6395: cmd/snap: use a fake user for 'run' tests <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6395>
<Chipaca> :-)
<mup> PR snapd#6395 closed: cmd/snap: use a fake user for 'run' tests <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6395>
<zyga> thank you sir :)
<zyga> btw, I know this is a bit big but I'd love have some quick pass on the design in https://github.com/snapcore/snapd/pull/6360
<mup> PR #6360: cmd/snap-update-ns: refactor of profile application <Per-user mount ns  ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6360>
<zyga> I think it's sufficient if one reads one function there
<zyga> the rest is plumbing into that idea
<zyga> specifically this one https://github.com/snapcore/snapd/pull/6360/files#diff-d5f861571a1e368f7c7f933b29316750R37
<zyga> the whole PR is about allowing that function to exist
<zyga> and the fuction is a generalization of the existing algorithm (that part is unchanged)
<zyga> but the details of system vs user profile are abstracted behind the interface
<zyga> so reuse, easier testing and less code (the tests cover more code now so there's more +es than -es)
<mborzecki> one interesting spread failure: https://paste.ubuntu.com/p/Tz4JCptgPb/ pstolowski something you may want to look at
<mborzecki> pstolowski: on a second look, doesn't seem to be related to hotplug
<pstolowski> mborzecki: hmm something went terribly wrong with reboot?
<pstolowski> localhost.localdomain systemd[1]: etc-shadow.mount: Failed to check directory /etc/shadow: Not a directory
<pstolowski> etc
<mborzecki> pstolowski: ah, watchdog timeout
<mvo> zyga: re sbuild> running but slow, hopefully finishing soon
<mborzecki> pstolowski: actually itnersting, snapd was waiting for system reboot, and got killed by systemd because of watchdog timeout
<mvo> zyga: hrm, I'm confused, it fails in sbuild early but works in pbuilder, need to look closer
<mvo> zyga: I get errors in sbuild using an ubuntu kernel I think you had this too, trying on pure debian noe
<mvo> now
<mvo> zyga: TestSetupSnapConfineGeneratedPolicyError bits
<zyga> mvo: iterating on sbuild
<zyga> mvo: oh!
<zyga> that's interesting
<zyga> mvo: I'll pastebin my errors
<zyga> we can compare
<zyga> mvo: note, I got errors on both kernels
<zyga> mvo: both ubuntu and debian-10
<mvo> zyga: interessting, my debian-sid sbuild is still building
<zyga> I had to spend a moment to add caching to my setup as otherwise iteration was mostly network bound
<zyga> now it should be quite a lot faster
 * Chipaca â break
<zyga> mvo: FYI: https://salsa.debian.org/debian/snapd/merge_requests/1
<zyga> mvo: that's just last evening state
<mvo> zyga: nice
<mvo> zyga: yeah, same errors in debian too
<mvo> zyga: http://paste.ubuntu.com/p/5D3dggjbvM/ full log
<zyga> that's the same that I see
<zyga> ok
<zyga> I think you can put this on hold now
<zyga> let's attack it tomorrow in master
<zyga> I'll work on packaging only
<zyga> unless you see a point I think we should not both spend time on it today
<mvo> zyga: its fine, I try to minimize the time on this
<mvo> zyga: working mostly on remodel now
<Chipaca> pedronis: if-and-when you have a chance, a short glance at #6400 would be good
<mup> PR #6400: overlord/snapstate: use an ad-hoc error when no results <Created by chipaca> <https://github.com/snapcore/snapd/pull/6400>
<mup> PR snapd#6400 opened: overlord/snapstate: use an ad-hoc error when no results <Created by chipaca> <https://github.com/snapcore/snapd/pull/6400>
<Chipaca> pedronis: it's +30-7, so should be quick
<Chipaca> this is to block the "yeah sure switch to non-existent channel"
<Chipaca> but, it has more consequences, because of course it does :-)
<mvo> mborzecki: nice catch (6317)
<mvo> Chipaca: do you have a moment for me? I was wondering where the api of remodel should life: /v2/remodel? or /v2/model/ and a GET to get the current and a POST to post a new one?
<Chipaca> mvo: where is the model kept?
<mvo> Chipaca: in the state
<Chipaca> mvo: what would you GET?
<mvo> Chipaca: the currently get model
<mvo> Chipaca: I implemented this for testing already as part of debug but was wondering if it should be more official
<mvo> Chipaca: hence my wondering
<mvo> Chipaca: the important use case for this endpoint is to post a new model :)
<Chipaca> mvo: I think /v2/model would be fine
<Chipaca> mvo: how is it used?
<mvo> Chipaca: thanks, I think that makes sense
<mvo> Chipaca: we will provide it via an api endpoint mostly
<mvo> Chipaca: but I think there will also be a "snap remodel" command
<Chipaca> mvo: ah, no 'snap model --re
<Chipaca> '
<Chipaca> oh
<mvo> Chipaca: interessting, maybe `snap model {get,set}`?
<mvo> Chipaca: we have not talked much about the cli yet
<zyga> mvo: I like snap model get
<zyga> though I very much like "snap remodel"
<zyga> it spells out explicitly this is an operation that can change things more than "assign a value"
<mvo> zyga: yeah
<mvo> zyga: I did "snap debug get-model" for now, not sure if we need something on the cli, will talk with samuele
<zyga> mvo: I like that
<mborzecki> amdgpu-pro is so much fun, i'm typing something in the terminal, suddengly gnome-session fails and the whole Xorg goes down :/
<mborzecki> and it's mind boggling qt wants to compile shaders to display a piece of text from qml
<mup> PR snapd#6401 opened: many: add /v2/model API, `snap remodel` CLI and spread test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6401>
<pstolowski> mborzecki: i don't think it's unique to amdgpu ;)
<mborzecki> pstolowski: frankly the windows drivers aren't much better, i've deliverately skipped the last 3 updates :P
<pstolowski> :)
<greyback> mborzecki: qml's text renderer uses distance field rendering technique, good for UIs where text can change size a lot (especially animated) to avoid lots of cpu-bound rasterisation. Yep it needs shaders, but why not? :)
 * greyback puts https://github.com/snapcore/snapd/pull/6361 out there
<mup> PR #6361: kvm: load required kernel modules if necessary <Created by gerboland> <https://github.com/snapcore/snapd/pull/6361>
<mborzecki> greyback: interesting, sounds like i should search qt blog archives for the details :P
<cachio> mvo, my internet connection is breaking up
<cachio> can't connect ot the hangouts
<mup> PR snapd#6361 closed: kvm: load required kernel modules if necessary <Created by gerboland> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6361>
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/6399 super simple review
<mup> PR #6399: packaging: make sure that /var/lib/snapd/lib/glvnd is accounted for <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6399>
<mup> PR snapd#6317 closed: overlord/snapstate/backend: call fontconfig helpers from the new 'current' <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6317>
<mborzecki> mvo: thanks!
<mup> PR snapd#6399 closed: packaging: make sure that /var/lib/snapd/lib/glvnd is accounted for <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6399>
<mvo> mborzecki: thanks, merged and I cherry picked it into 2.37 in case we do anohter release of that
<mup> PR snapd#6397 closed: tests: Use backend: [autopkgtest] for smoke test suite <Created by sergiocazzolato> <Closed by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6397>
<Chipaca> booo, multiple progress bars doesn't work :-(
 * Chipaca takes a breaks
 * cachio lunch
<pstolowski> mvo: hey, do you have a moment for https://github.com/snapcore/snapd/pull/6379 ?
<mup> PR #6379: ifacestate/tests: extra test for hotplug-connect handler <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6379>
<mvo> pstolowski: do you need a review?
<pstolowski> mvo: yes, 2nd review
<pstolowski> it's just a test
<mvo> pstolowski: sure, looking
<pstolowski> thanks!
<Chipaca> I'm off to the gym. Will bbl, but if I don't see y'all, have a good weekend!
<mup> PR snapd#6379 closed: ifacestate/tests: extra test for hotplug-connect handler <Hotplug ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6379>
<pstolowski> mvo: ty!
<Croepha> so, I have added wget in a stage-packages list, but that command isnt found when I try to run it from a shell script inside the snap... am I missing something?
#snappy 2019-01-19
<Croepha> nvm
<mup> PR snapcraft#2445 opened: Add core18 support to dotnet plugin <Created by ed10vi> <https://github.com/snapcore/snapcraft/pull/2445>
<Croepha> with ubuntu core, is there a way to change the partiton labels? im having a problem where I have one installation on a thumbdrive and another installation on the main mmc, and i think its getting confused...
<fallenour> o/
<fallenour> Hey is anyone else having significant issues with 18.04 LTS snap installs? All of mine are taking up 100% of the space allocated for them, and I cant even list my containers because theres no space avialble. Can anyone give any insights into this? I cant even finish installs of my snaps until this is resolved.
<fallenour> This is what Im seeing on disk so far: http://paste.ubuntu.com/p/dQ3PZ8vwwc/  and http://paste.ubuntu.com/p/WkznvBsZRR/    The issue is, I cant even execute "docker container list" becuse it says not enough disk space. Total usage on the disk is maybe 10 Gb? On a disk thats well over 1TB in total size. Its a completely fresh Ubuntu 18.04LTS install, the only change is I also installed Ubuntu-Desktop.
<MattJ> fallenour, I'm no snap expert, but I believe that's totally normal
<MattJ> snaps are essentially disk images, they are no larger than the files they contain. They get mounted, read-only, and that's why it will always say 100% used.
<MattJ> I've encountered problems with monitoring on production systems where I would get disk usage alerts on snap installs :)
<fallenour> MattJ: Well the problem with that is, It installed by default on the system, but it wont even let me finish the snap install. I cant even configure the items snap installed. If I cant configure it, I cant use it, and effectively, its broken. If its unconfigurable, its worthless.
<MattJ> 100% on your / partition is obviously a problem
<fallenour> MattJ: Yea thats the same though Ihave. My question is, why doesnt it do to 75% instead, and scale due to isntall size, that way it always has room for changes?
<MattJ> Because snaps are read-only by design
<leftyfb> fallenour: there are no changes within the snap container
<leftyfb> fallenour: it's a version of software. If you installed a new version, then the new snap gets symlinked to "current"
<fallenour> MattJ: The other question is, how do I change it so I can configure the services. leftyfb Then how am I supposed to configure Nextcloud for instance to use a database? If I cant complete the isntall, it wont work.
<MattJ> They just contain the application, any data that the application generates doesn't go into the snap but into your usual system partition
<fallenour> MattJ: That I get, but even when Ive used snaps previously, tehy at least allowed me to configure the application first. I cant even do that here.
<leftyfb> fallenour: you've mentioned docker, lx(c/d) and nextcloud. Lets start with testing a simple snap. Maybe try installing vlc
<MattJ> fallenour, because your main disk is full
<leftyfb> fallenour: configuring the application is done outside of the snap container in your root filesystem
<fallenour> leftyfb: Ok, Im game. ill try it.
<MattJ> fallenour, can you do a `df -h /`?
<fallenour> leftyfb: MattJ Im getting connection refused for snap. My disk: http://paste.ubuntu.com/p/HdmdQXXrns/
<leftyfb>  /dev/mapper/ubuntu--vg-ubuntu--lv   4062912 4046528         0 100% /
<leftyfb> you have zero space left on your drie
<leftyfb> drive*
<leftyfb> you are out of disk space, nothing to do with snaps
<MattJ> fallenour, I asked for with -h
<fallenour> Sorry about that MattJ http://paste.ubuntu.com/p/NXNH85Qwgn/ leftyfb Thats the thing though, I know I shouldnt be. The server its on has at least 800 GB of dedicated space across multiple drives. Theres no way its full.
<leftyfb> fallenour: you only have 4G in your root partition
<MattJ> fallenour, that's what you need to fix... the root partition is only 4GB
<MattJ> I've done installations before where the installer only creates a relatively small root partition (when using LVM)
<MattJ> You have to grow the partition manually
<fallenour> MattJ: leftyfb Ok, how do I do that? more specifically safely, the other question is how do I check to see how many disks my server can see.
<fallenour> MattJ: leftyfb All of the installs were done with LVM
<MattJ> https://wiki.ubuntu.com/Lvm is a good place to start I guess
<fallenour> MattJ: leftyfb when did Ubuntu start doing this? this wasnt an issue in 16.04, they would jsut use the full space availble. Im confused as to why this is a thing now
<MattJ> I don't know, I don't typically use LVM
<fallenour> MattJ: I normally do, but I only use it so that I can expand drive space later with LVM when I upgrade the harddrives in the future. But like I said before, I never had this issue. THe only thing Ive done differently this time is use 1 Raid 0 instead of 6.
<leftyfb> fallenour: the default install of Ubuntu server should use up the remaining space by default. How did you do the install?
<leftyfb> Btw, raid 0 is begging for data loss. Hope you don't care about the data on it
<fallenour> leftyfb: I used the built in process through cd install. generic "install with * using LVM" option. As for the data itself, I have replication between the servers on the databases, web app servers are using raid 1 with the data between HA Master-Master with 15 minute backups to cold storage.
<fallenour> leftyfb: MattJ odd idea, but how do I list all the physical disks that the system can see? I tried df -aTh, anything else I can try to see what it can see? It may not be seeing my drives and using only ram, if thats a thing.
<leftyfb> lsblk
<leftyfb> You might be better off in #ubuntu-server at this point since this isn't a snap issue
<fallenour> leftyfb: I think we just found the problem http://paste.ubuntu.com/p/nfFdh3SRDh/
<leftyfb> Yeah, like we said, you only created a 4g partition for root
<fallenour> leftyfb: So weird. I have no idea why it did this, or why it added all the space to sda3. Is there a fast fix for this?
<MattJ> fallenour, try #ubuntu-server
#snappy 2019-01-20
<thaostra_> Hey, does anyone know if there's a way of downloading a snap without using the snap utility?
<popey> thaostra_: sure, you can get the path to the snap from the api
<popey> so a bit of curl
<thaostra_> popey, Ah do you have a link to the API docs? My searches have turned up nothing useful
<popey> https://github.com/snapcore/snapd/wiki/REST-API
<thaostra_> Thanks!
<thaostra_> popey, Do you have an example for getting info on a snap from snapcraft? I'm trying do use some of the listed routes for getting info from snapcraft.io but they're not working
<popey> i don't
#snappy 2020-01-13
<mborzecki> morning
<sdhd-sascha> morning :-)
<zyga> good morning
 * zyga applies updates
<mborzecki> zyga: hey
<zyga> :-)
<zyga> hey, how are you doing?
<mborzecki> zyga: caught a cold :/
<zyga> given where we live I think it is inevitable
<mborzecki> zyga: but managed to build centos cloud image, since there's still no official ones yet
<zyga> I spent most of the weekend doing homework with kids
<zyga> I spent some hours on manual pages for API docs
<mborzecki> zyga: bet is was much fun ;)
<zyga> I'll try to publish my toy library next weekend
<mvo> hey zyga and mborzecki
<mvo> zyga: what is you library about?
<zyga> hey mvo, how are you?
<mborzecki> mvo: hey
<zyga> mvo: testing! :)
<zyga> mvo: libzt, robust and simple testing
<zyga> for C
<zyga> tested, documented, building in all major OSes
<zyga> (that's the goal)
<zyga> I'm maybe 60% there
<mborzecki> zyga: zt? libzygatest?
<zyga> mborzecki: over time my private libraries evolved in their naming scheme but I guess z is just z, not an acronym
<zyga> t is indeed for "testing"
<zyga> I ended up writing it after another private toy project needed more testing than I could do by just playing with it
<zyga> and I didn't want to depend on glib
<zyga> or anything that's a mess to build outside of linux
<zyga> anyway
<mvo> zyga: nice! I'm good, thanks, didn't sleep that well though :/
<zyga> today is snap run --explain day :)
<zyga> jamie is off this week so I will focus on things that don't touch C
<pstolowski> morning
<zyga> hey pawel
<pstolowski> o/
<zyga> gosh bugzilla is such a dinosaur
<zyga> trying to find snapd bugs
<mborzecki> pstolowski: hey
<zyga> is search implemented by grepping the database?
<mborzecki> zyga: rhbz? or suse one?
<zyga> suse
<zyga> I clicked "search" like two minutes ago
<zyga> ...
<zyga> and got 400
<zyga> https://bugzilla.novell.com/buglist.cgi?query_format=specific&order=Importance&no_redirect=1&bug_status=__all__&product=&content=snapd
<mvo> hey pstolowski !
<mborzecki> zyga: hmm maybe they structured the project differently than rhbz has
<mborzecki> zyga: in rhbs it's product - pick fedora or EPEL, component - pick snapd, status all open and that's it
<zyga> I'll search in my mail instead
<mborzecki> at least it's not mantis, had trouble running a trivial search in centos bug tracker
<zyga> brb, tea refill
<zyga> rainy morning
<mborzecki> oh, and it's possible to install snapd on centos8, but one has to enable `cr` repository as well, sice the selinux packages are part of 8.1 that's not in base os repo yet
<zyga> cr?
<mborzecki> zyga: continuous release, iow upcoming updates
<zyga> aha
<zyga> oh well :)
<mup> PR snapd#7979 closed: many: drop NameAndRevision, use snap.PlaceInfo instead <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7979>
<mup> PR snapd#7978 closed: data/selinux, test/main/selinux-clean: update the test to cover more scenarios <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7978>
<mborzecki> degville: hi, i've added a note about CentOS CR repo under https://forum.snapcraft.io/t/installing-snap-on-centos/10020 can you take a look? :)
<mborzecki> heh, suprised one took the time to write this https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1859185/comments/3
<mup> Bug #1859185: No (obvious) way to turn autorefresh off <amd64> <apport-bug> <bionic> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1859185>
<degville> mborzecki: will do - thanks for letting me know.
<pstolowski> zyga: got your new mbp yet?
<zyga> pstolowski: no, it's still in netherlands
<zyga> pstolowski: and only with a shipping label :/
<zyga> pstolowski: so sigh
<zyga> pstolowski: I don't doubt it will arrive on time but they said 14-15th
<zyga> probably waiting just to arrive "on time"
<pstolowski> mhm
<pedronis> Chipaca: hi, are there open problems with #7984 (just skimmed it) or are you ok with it?  if not I'm happy to discuss
<mup> PR #7984: store, overlord/snapstate, etc: SnapAction now returns a []â¦Result <Created by chipaca> <https://github.com/snapcore/snapd/pull/7984>
<Chipaca> pedronis: I'm ok with it
<Chipaca> pedronis: it's shorter than my first attempt so that's a plus :-)
<pedronis> Chipaca: ok, let me know if we land in trouble further down, but let's go this way for now
<Chipaca> pedronis: ok, next pr should be up before noon
<Chipaca> stacked on this one i mean
<pedronis> understood
<pedronis> mborzecki: I did a quick pass about the changes in #7972
<mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<mborzecki> pedronis: cool, thanks
<pstolowski> pedronis: hey, do you have a moment to talk quickly about some aspect of snap disconnect --forget?
<pedronis> pstolowski: can do in ~20 mins ?
<pstolowski> pedronis: sure
<zyga> brb
<pedronis> pstolowski: I'm available now
<pstolowski> pedronis: ok, coming to standup ho
<mup> PR snapd#7985 opened: tests: use snap remove with --purge flag in most of the spread tests <Test Robustness> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7985>
<pstolowski> ^ pretty mechanical
<mvo> looks like core18 is failing right now in master, has anyone already looked? if not, I'm doing so now
<zyga> haven't looked, can look if you are busy
<pstolowski> Chipaca: ty!
<Chipaca> pstolowski: i was about to ask about just setting the option, but this way it's explicit so +1
<mvo> zyga: thanks, should be fine
<pstolowski> Chipaca: yeah i was thinking about some magic, but preferred explicit
<mvo> pstolowski: nice PR, thanks for this
<pstolowski> mvo: i should have thought about it earlier!
<mvo> pstolowski: do we have (at least) one test left that run snap remove without purge? I assume we do, just want to double check :)
<pstolowski> mvo: yes, a few tests that test remove itself, snapshots test, and selinux tests (i mentioned this in the commit and PR desc)
<mvo> pstolowski: \o/
<cachio> mvo, hey
<cachio> mvo, about beta release
<cachio> are you planning a 2.43.1 ?
<cachio> or it needs to be discussed?
<mvo> cachio: I'm not aware of 2.43 issues right now, so hopefully we don't need 2.43.1. or am I missing something?
<cachio> mvo, I fwd an email on friday
<mup> PR snapd#7985 closed: tests: use snap remove --purge flag in most of the spread tests <Simple ð> <Test Robustness> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7985>
<mvo> cachio: oh, missed that, yes, this sounds very much like we need 2.43.1
<mvo> cachio: let me read the full bug
<cachio> mvo, nice, thanks
<mvo> cachio: thank you!
<Chipaca> pedronis: https://github.com/snapcore/snapd/pull/7986/commits/479e46211c3ec18c95b6634d1b33fb54acc5ff4c
<mup> PR snapd#7986 opened: store, o/snapstate: send default-tracks header, use RedirectChannel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7986>
<mup> PR #7986: store, o/snapstate: send default-tracks header, use RedirectChannel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7986>
 * Chipaca will start abbreviating overlord to ð
<Chipaca> alas there is no panopticon emoji
<Chipaca> emojus?
<Chipaca> emoja?
 * Chipaca hides
<mup> PR snapd#7987 opened: snap: make `snap version` output host without extra whitespace <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7987>
<Chipaca> mvo: is the host-and-virt-in-version only just getting released?
<mvo> Chipaca: yes, part of 2.43 which is in beta right now, never made it beyond beta afaict
<Chipaca> mvo: use U+2620 instead of / :-p
<mvo> Chipaca: heh
<Chipaca> mvo: did you mean to target it to master?
<pedronis> Chipaca: mvo: we need to discuss that bit
<mvo> Chipaca: yes, I will backport it from there once we have a agreement
<mvo> pedronis: sure, should we do it right after the standup?
<pedronis> mvo: yes
<mvo> ok
<mup> PR snapd#7987 closed: snap: make `snap version` output host without extra whitespace <â  Critical> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7987>
<zyga> re
<mup> PR snapcraft#2868 opened: cli: implement progressive releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2868>
<mup> PR snapd#7988 opened: snap: remove "host" output from `snap version` <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7988>
<mup> PR snapcraft#2869 opened: build providers: use multipass from stable <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2869>
<Chipaca> mborzecki: wrt 596,523 hours, it's weird because nowhere do we format numbers with a comma like that
<Chipaca> mborzecki: that's not snapd :)
<Chipaca> mborzecki: in particular snapd's progress bar would've printed "68y" if it had to render that number
<zyga> Chipaca: libc may do that
<zyga> Chipaca: , is a common 1k separator
<Chipaca> which, sure, weird, but that's why i'm asking where that's coming from
<Chipaca> zyga: yes i know it may
<Chipaca> zyga: but we don't use libc to format how long is left for a download in snapd
<Chipaca> so that's why i'm asking :)
<mborzecki> Chipaca: hmm right
<pedronis> there's not much info there, wouldn't do anything unless they give more info
<mborzecki> Chipaca: otoh, i should probably open a PR to tweak quantity formatting in the progress bar, sub second values are the funny ones i mentioned
<Chipaca> mborzecki: :)
<Chipaca> mborzecki: there are probably bugs (tm)
<mborzecki> s/bugs/features/
<Chipaca> mborzecki: rather, we have yet to adequately sample the probability cloud of bugs
<Chipaca> certainly bug(xâ) > 0 â xâ
<roadmr> ð§
<Chipaca> mborzecki: what kind of weirdness, btw?
<mborzecki> Chipaca: when the download is close to finishing sometimes the left time reported is in us/ns range
<mborzecki> Chipaca: as in right before it's finished
<Chipaca> mborzecki: ah, yes
<Chipaca> mborzecki: I've wondered what it goes on to do after finishing :)
<ijohnson> pedronis: mvo: is it safe to say that all the tests that are uc20 specific are given by function name `Test*20*` ? Using a similar regex I found these tests: https://pastebin.ubuntu.com/p/NHq7sB68dj/
<ijohnson> do y'all think that's exhaustive or are there other packages/test suites that I need to look at as well ?
<pedronis> ijohnson: yes, it's reasonable, but some one have the 20 in the suite
<pedronis> not each test
<ijohnson> ah good point
<ijohnson> pedronis: so that adds these 3: https://pastebin.ubuntu.com/p/FNdtRsttBc/
<ijohnson> is that probably all of the uc20 specific tests ?
<pedronis> ijohnson: seems right to me
<ijohnson> ack, thanks
<pedronis> (I'm in a meeting)
<cachio> mvo, this is the model I am usign https://github.com/sergiocazzolato/snapd/blob/tests-enable-nested-on-core20/tests/lib/assertions/nested-20-amd64.model.json
<zyga> brb
<mvo> cachio: thank you! I think I have an idea what might need tweaking. I am in a meeting right now but let me try to help
<cachio> mvo, great, thanks
<mvo> cachio: I think this needs "grade: dangerous" (or something) and a snaps: subsection, here is an example https://github.com/snapcore/snapd/blob/master/tests/lib/assertions/ubuntu-core-20-amd64.model
<cachio> mvo, nice, thanks
<ijohnson> mvo: pedronis: cmatsuoka: thoughts on having modeenv.Write() also return the filepath where the modeenv was written out? this will make mocking easier in tests
<pedronis> ijohnson: still in meeting
<ijohnson> oh ok
<Chipaca> grr jq in 14.04 doesn't like dashes in object keys
<pstolowski> Chipaca: use jq snap
<Chipaca> yeah
<mvo> ijohnson: sounds fine to me
<ijohnson> mvo: ack, I will file a quick PR for that this morning then
<ijohnson> thanks
<pedronis> ijohnson: I have another meeting, but I'm a bit unclear why you need that? it writes thing in a predictable place
<pedronis> no?
<ijohnson> pedronis: yes it's predictable, but in all these tests I have to call modeenv.Write(), then immediately do a filepath.Join(dirs.Root /*or c.tmpdir*/,dirs.SnapModeenvFile) to remove it after the tests
<ijohnson> pedronis: so it would be nice to just have `f, err := m.Write(); defer os.Remove(f)`
 * cachio lunch
<pedronis> ijohnson: ok, I would prefer not to do it, because usually we don't have that style
<pedronis> ijohnson: you can have a test helper if needed, you can use AddCleanup in it
<ijohnson> pedronis: ok
<pedronis> ijohnson: not a lot of the tests you listed have a devicemgr around
<pedronis> ijohnson: are you adding write modeenv to a lof of places?
<pedronis> I fear I'm missing something here
<ijohnson> pedronis: well it's probably fine to just have the same modeenv in most tests, but other tests are not consistent about the name of the base/kernel for uc20 tests iiuc
<ijohnson> it's fine I guess to have a helper
<pedronis> ijohnson: ok, notice that we might need a higher level helper anyway at some point
 * zyga-laptop had dinner and need a moment to rest
<zyga-laptop> code review time!
<ijohnson> yes perhaps
<roadmr> zyga's laptop had dinner? ð
<zyga-laptop> roadmr sadly the laptop recharges while I'm not looking ;)
<pedronis> ijohnson: we bootloadertest.MockBootloader but it doesn't fit quite the fact that Core20 has boot state in more than one location
<pedronis> *we have
<pedronis> that one has things like SetBootBase and SetBootKernel etc
<pedronis> but there's mismatch with Core20
<ijohnson> pedronis: yes I added a number of functions to the MockBootloader for the ExtractedRunKernelImage interface
<Zylop> hello, i have a lot of time for your kind reply, i get this error when installing youtube music cannot self-bind mount /run/snapd/ns: Cannot allocate memory
<Zylop> 5.5.0-1-MANJARO
<cachio> mvo, hey
<Zylop> i will check if there's a new kernel beta soon
<Zylop> thank you
<cachio> mvo, using snaps as you did in the other model
<cachio> I get error: cannot decode model assertion "/home/gopath/src/github.com/snapcore/snapd/tests/lib/assertions/nested-20-amd64.model": assertion model: type of snap "snapd" must be one of app|base|gadget|kernel|core
<zyga> Zylop: hello
<cachio> mvo, which type we should use for snapd?
<zyga> Zylop: that's interesting, I've never seen an error like that before
<ijohnson> zyga: Zylop: I seem to remember seeing that error on the forum recently
<zyga> Zylop: perhaps it's some kind of new hardening or bug
<Zylop> or just downgrade to 5.3
<Zylop> its a bug in 5.4 and 5.5
<Zylop> kernel
<Zylop> patched in 5.5rc5
<ijohnson> Zylop: zyga: see https://forum.snapcraft.io/t/on-ubuntu-18-04-3-with-5-4-5-5-kernels-snaps-are-not-launching/14662/18
<Zylop> witch atm its not officially launched so im downgrading to 5.3 for while
<Zylop> i founf this
<Zylop> ah ok
<Zylop> ty
<Zylop> i see in arch forum
 * zyga l boks 
<zyga> thanks ijohnson
<mup> PR snapcraft#2869 closed: build providers: use multipass from stable <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2869>
<mup> PR snapcraft#2870 opened: snap: set PYLXD_WARNINGS to inhibit unknown LXD attribute warnings <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2870>
<mup> PR snapd#7989 opened: devicestate: do not allow remodel between core20 models <Created by mvo5> <https://github.com/snapcore/snapd/pull/7989>
<pedronis> cachio: that means the snapd is too old
<pedronis> we allow type: snapd now
<cachio> pedronis, ah, ok, that makes sense
<cachio> thanks!!
<Zylop> working
<Zylop> thanks
<ijohnson> :-)
<mup> PR snapcraft#2871 opened: snaps: account for forwarded (effective) installation channels <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2871>
<ijohnson> pedronis: oh also I was going to ask you if we expect classic devices with the new uc20 models to have modeenv? currently my HasModeenv method just checks if the model is not ModelGradeUnset
<ogra> is the forum down again ?
<ijohnson> seems like it
<ogra> it should really be added to status.snapcraft.io
<ijohnson> +1 for that
<cachio> pedronis, which version of snapd is needed?
<ijohnson> snapcraft.io/docs should be on status.snapcraft.io too
<cachio> i just tried with the 2.42.1 and did't work
<cachio> pedronis, and core 2.42.8
<cachio> 2.42.5
<cachio> pedronis, with 2.43 works
<mup> PR snapcraft#2861 closed: meta: remove Application's `prepend_command_chain` <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2861>
<pedronis> ijohnson: we don't let you set classic and grade at the same time atm, we will need to think through what a core20 model means for classic
<pedronis> cachio: yes, it was in the 2.43 dev cycle
<ijohnson> pedronis: ack that's what I thought
<cachio> pedronis, yes, the image is created now
<cachio> pedronis, thanks for the help+
<grewtin> noice
<mup> PR snapcraft#2866 closed: spread tests: limit adapter test to amd64 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2866>
<mup> PR snapcraft#2870 closed: snap: set PYLXD_WARNINGS to inhibit unknown LXD attribute warnings <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2870>
<cmatsuoka> zyga: could you have a quick look at https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1859160 to see if it's something you recognize?
<mup> Bug #1859160: Snapd fails to delete obsolete dev-loops, thus causing delay at lockscreen <snapd (Ubuntu):New> <https://launchpad.net/bugs/1859160>
<mup> PR snapcraft#2858 closed: add support for system-usernames <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2858>
<mup> PR snapcraft#2872 opened: Release/3.9.5/cherry picks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2872>
<mup> PR snapcraft#2867 closed: elf: remove return parameters for ElfFile's _extract() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2867>
<mup> PR snapd#7990 opened: many: misc tweaks <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7990>
<mup> PR snapd#7947 closed: boot,bootloader: support new UC20 style kernel extraction <UC20> <â Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7947>
<mup> PR snapd#7991 opened: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7991>
<mup> PR snapcraft#2872 closed: Release/3.9.5/cherry picks <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2872>
<mup> PR snapcraft#2868 closed: cli: implement progressive releases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2868>
<mup> PR snapd#7992 opened: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
#snappy 2020-01-14
<genii> Is pulseaudio now snap only install?
<cjwatson> pulseaudio is still in Ubuntu.  The snap seems pretty out of date.
<cjwatson> (still in Ubuntu as a .deb, I mean)
<genii> cjwatson: Thanks. Looks like an update to 7.5 was reverted to 7.4, causing issues in apt/dpkg
<Kyoku> is there a way to do full disk encryption on ubuntu core for Pi4 without paying $30,000 for a smart start plugin?
<mup> PR snapcraft#2658 closed: candidate testing <do-not-merge> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2658>
<mup> PR snapcraft#2873 opened: candidate testing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2873>
<mborzecki> morning
<mup> PR snapd#7988 closed: snap: remove "host" output from `snap version` <â  Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7988>
<mborzecki> mvo: morning
<mborzecki> mvo:  can you cherry pick #7988 to 2.43?
<mup> PR #7988: snap: remove "host" output from `snap version` <â  Critical> <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7988>
<mvo> mborzecki: good morning!
<mvo> mborzecki: yes, will do now
<mvo> mborzecki: do you know if we need anything else for .1 ?
<mborzecki> mvo: hmm, selinux policy would be nice
<mvo> mborzecki: yeah, could you please tag as 2.43?
<mborzecki> mvo: https://github.com/snapcore/snapd/pull/7978 want me to open a PR with backport?
<mup> PR #7978: data/selinux, test/main/selinux-clean: update the test to cover more scenarios <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7978>
<zyga> good morning
<mvo> mborzecki: backport is fine, if its small I can cherry-pick
<mvo> zyga: good morning
<zyga> mvo: .1 release coming for that snap version output changeW?
<mvo> zyga: yes, anything from you we need for .1 ?
<zyga> no, sorry
<zyga> I'll try to do better today
<mvo> zyga: that's fine
<mvo> zyga: no worries
<mvo> mborzecki: it's just three commits, if they apply cleanly I will just cherry pick them
<mborzecki> mvo: yeah, that should be fine
<mvo> mborzecki: yeah, no conflicts, done
<mborzecki> mvo: cool, thank you!
<mvo> mborzecki: thank you !
<mvo> mborzecki: I will wait for pawel and samuele to double check if they think we need to add anything and then proceed with the release of .1
<mup> PR snapd#7981 closed: snap-bootstrap: create encrypted partition <UC20> <Created by cmatsuoka> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7981>
<zyga> https://github.com/snapcore/snapd/pull/7974#issuecomment-574050904 is the weirdest python review I ever made
<mup> PR #7974: many: run black formatter on all python files <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7974>
 * zyga reviews indirect download PR
<pstolowski> mornings
<zyga> hey pawel
<zyga> pstolowski: it's coming today
<zyga> pstolowski: :)
<pstolowski> zyga: yay :)
<mvo> hey pstolowski ! good morning! anything you can think of we need/should include in 2.43.1 ?
<pstolowski> mvo: hey, nothing from me
<mvo> ta
<mborzecki> errand, back in 1h or so
<zyga> brb
<pedronis> mvo: hi, I commented on #7989
<mup> PR #7989: devicestate: do not allow remodel between core20 models <Created by mvo5> <https://github.com/snapcore/snapd/pull/7989>
<pedronis> mborzecki: mvo: #7990 is missing some end of doc comment sentence .
<mup> PR #7990: many: misc tweaks <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7990>
<mvo> pedronis: thank you
<mvo> pedronis: makes sense
<zyga> back
<zyga> mvo: https://github.com/snapcore/snapd/pull/7977#pullrequestreview-341982749
<mup> PR #7977: snap: add (hidden) `snap download --indirect` option to download via snapd <Created by mvo5> <https://github.com/snapcore/snapd/pull/7977>
<zyga> mvo: not sure if I'm right, otherwise +1
<zyga> mvo: though I want to check one more thing that landed before
<zyga> mvo: as it is realted
<zyga> *related
<zyga> checked out, ok
<mvo> zyga: aha, nice one. I need to double check but I think you are right
<mvo> zyga: \o/
<mborzecki> re
 * zyga reviews the SnapAction PR next
<zyga> mvo: just for reference, I checked if the remote download API cannot be used to abuse snapd to write to arbitrary files
<zyga> mvo: but I'm happy to see it is not that
<zyga> mvo: the API is just streaming the file via snapd, correct?
<zyga> (that's how I understood the api_download.go code)
<mvo> zyga: correct, in this regard there is no change to the old download code, the old code would connect to the download server directly, the new code connects to snapd for the download
<zyga> mvo: right, I was specifically looking for how the write to disk is done
<zyga> mvo: it is done via snap download running as user, which is what was important to me
<zyga> mvo: and specifically there is no path that snapd writes to that could be used to attack anything
<Chipaca> mvo: could we create a test-snapd- snap to test default tracks?
<mvo> zyga: correct
<mvo> Chipaca: yes
<Chipaca> mvo: in the snaps@ account an' everything?
<mvo> Chipaca: please create it under your account for now and then share with me/cachio - I need to create/use the new snapd-testing store account but I have not yet :( probably this is a good time to do that but I don't want to block you
<Chipaca> mvo: ok
<pedronis> Chipaca: share it with me too
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/7984#pullrequestreview-342411978
<mup> PR #7984: store, overlord/snapstate, etc: SnapAction now returns a []â¦Result <Created by chipaca> <https://github.com/snapcore/snapd/pull/7984>
<Chipaca> zyga: ack
<Chipaca> i'll do it in a followup when i switch to the new snap
<pstolowski> oh well, we have a bug
<zyga> pstolowski: oh?
<pstolowski> snap connections and snap interfaces reports connections for missing slots/plugs (e.g. after refreshing to a snap that doesn't have a plug/slot anymore). the repo doesn't have such plug/slot anymore, but api reads "conns" and doesn't intersect with repo (or snap.yaml data)
<zyga> I think we knew about this
<zyga> it's reported AFAIK
<pstolowski> hmm maybe you're right. i think issues around that had a few incarnations
<pstolowski> fwtw it's just the list of connections affected; security profiles are generated from repo data so they're fine
<pstolowski> anyway.. i'll look at fixing it
<zyga> pstolowski: do you have an idea on how the fix should look like?
<pstolowski> zyga: quick/rough one:L maybe collectConnections() in the daemon should (or ifaceMgr.ConnectionStates() one level deeper) intersect conns with repo
<pstolowski> i'll look at details later. i stumbled on it accidently when working on spread test for snap disconnect --forget
<zyga> pstolowski: I'll give it some thought and get back to you
<mborzecki> Chipaca: hmm hmm https://forum.snapcraft.io/t/596-523-hours-left-0-bytes-sec/15033/7 IDK what to say ;)
<Chipaca> mborzecki: moved it to the cafe
<mborzecki> Chipaca: thx
<pstolowski> zyga: thanks
<pedronis> pstolowski: hi, I did a pass on #7982
<mup> PR #7982: o/snapstate, wrappers: enable services on start <Complex> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7982>
<pstolowski> pedronis: ty
<mborzecki> quick errand
<pedronis> Chipaca: hi, it seems 7984 can be merged
<Chipaca> pedronis: yep
<Chipaca> pedronis: was waiting for a nod on the next one; don't want to merge it if I then need to change the refactor
<Chipaca> pedronis: but I guess I have that
<pedronis> pstolowski: mborzecki: we need to remember to try to s/GetType/Type/ at some point before .44
<Chipaca> as your comments were about the details, not about the guts of it
<Chipaca> so, yeah, merging
<pedronis> Chipaca: one non-blocking question is whether it would make logic sense to move EffectiveChannel to SAR as well or not
<mup> PR snapd#7984 closed: store, overlord/snapstate, etc: SnapAction now returns a []â¦Result <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7984>
<Chipaca> pedronis: the followup (7986) is red because the snap i use to test isn't in i386, so i decided to create our own snap now
<Chipaca> pedronis: (i had planned to that sometime anyway, which is why i put it in a variable :) )
<pstolowski> pedronis: right
<Chipaca> pedronis: right
<mup> PR snapd#7990 closed: many: misc tweaks <Simple ð> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7990>
<zyga> pstolowski: https://forum.snapcraft.io/t/opera-requests-auto-connect-to-gnome-3-28-1804-interface/14505/14
<zyga> pstolowski: can you snap install `opera-developer` it looks like we have a serious autoconnect issue
<zyga> I just want to double check that it's equally broken on Ubuntu for you
<zyga> looking at what's going on now
<pstolowski> zyga: will do in a sec
<zyga> pstolowski: I think it's caused by the snap declaration
<pstolowski> zyga: confirmed, gnome-3-28 content plug is not autoconnected
<zyga> pstolowski: check my response on the forun
<zyga> pstolowski: I don't recall how that part works
<zyga> pstolowski: if we have a snap declaration with plugs/content/allow-auto-connection entry
<zyga> pstolowski: does it mean _only_ that entry is auto-connected
<zyga> pstolowski: or does it mean that defaults apply but those are extras?
<pedronis> zyga: yes, if the snap has a content thing like that then it will not use the slot one
<zyga> pedronis: what do you mean by "it will not use the slot one"?
<pedronis> I mean  that the slot side snap-declaration on gnome-* will not be used
<pedronis> the only content auto-connection they wil get is the one they are allowing in their declaration
<pedronis> there is n merging
<pedronis> there is no merging
<zyga> mhm
<zyga> so there are two bugs here
<zyga> 1) the declaration for opera-developer needs fixing
<zyga> 2) this is not discoverable much
<pedronis> discoverable what?
<pedronis> they asked somebody in the store for that declaration
<zyga> pedronis: snap install did not respect auto-connection that otherwise normally happens
<zyga> pedronis: and didn't say anything about why
<pedronis> why would it? the declaration asked for this
<pedronis> is not something the user can fix
<zyga> pedronis: why would it? because the developer defined a plug and a default provider
<mborzecki> re
<zyga> and we used additional data to ignore that
<zyga> I think this warrants a message
<pedronis> zyga: data that they asked for
<zyga> and I think the existence of that thread agrees
<pedronis> anyway user != developer
<zyga> pedronis: if I have a snap and I say I want to connect to a default provider snapd should 1) connect to it 2) tell me why it doesn't
<pedronis> I wonder what is that snap
<zyga> anything else is silent behavior that defies request
<pedronis> this is not a typical scenario
<zyga> no but I think my point stands
<pedronis> I wonder if they were early adopter of something
<zyga> we should say "not connecting despite default provider because snap-declaration data <reference> says not to"
<zyga> pedronis: I would also argue that part of no-merging is also a bug / surprising
<zyga> I know it's the design, since I've been to that meeting
<zyga> but it's surprising
<pedronis> zyga: we will not change that
<zyga> pedronis: I think the only thing that really needs to be changed in snapd is to make this more discoverable
<pedronis> anyway they are connecting to chromium-ffmpeg
<pedronis> that's what  that connect is
<zyga> so that it doesn't require a snapd developer to debug each time
<pedronis> but now they need something else to connect to gnome as well
<zyga> pedronis: and if they didn't need ffmpeg they would get the connection to gnome-* by default
<zyga> pedronis: I know you said we're not doing merging but I think you can see how that is surprising
<pedronis> zyga: the correct solution is probably to move that decl on the chromium-ffmpeg side
<pedronis> zyga: we publish chromium-ffmpeg it seems, it should have a policy of what snaps can use it (any snaps, some publishers, don't know)
<pedronis> zyga: to be clear my impression is that this is particularly brittle because content is essentially a completely different interface for each value of the content label
<pedronis> but is still a single interface for a our logic
<zyga> pedronis: I agree entirely
<zyga> re
 * zyga was upstairs to help with Lucy
<zyga> pedronis: can you comment on the thread with your preference please
<zyga> pedronis: I've advised jdstrand to issue a declaration for opera-* snaps
<mborzecki> pedronis: updated #7972
<mup> PR #7972: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<pedronis> zyga: btw jdstrand is off this week
<pedronis> zyga: I need to check something, but my preference would be for chromium-ffmpeg to control access to itself
<pedronis> we probably need desktop input on that
<zyga> pedronis: yes, as a tweak to assertions it would be preferable O(1) vs O(N) solution
<zyga> man, my hand :/
<zyga> my wrist hurts so badly today, I was wrestling with Janek over weekend and I think I hurt myself
<zyga> (Janek = son)
<zyga> it was so-so yesterday but today it just hurts to do anything
<zyga> it's my right hand so I don't use it as often but man, so annoying
<mvo> pedronis: I updated 7989 based on your suggestion
<cachio> mvo, hello
<mvo> cachio: good morning
<cachio> mvo, any idea if there is any special configuration for qemu to run core20 images? I see this log trying to start the image https://paste.ubuntu.com/p/QKJw2fPmXt/
<mvo> cachio: anything I should add to 2.43.1 before the release?
<mvo> cachio: looking
<cachio> mvo, no
<cachio> tests for 2.43 ran almost with almost 100% of pass rate
<mvo> cachio: the pastebin lookslike something is not quite right with the image, do you have a link to the work-in-progress PR of yours? then I can poke a bit how ubuntu-image and qemu are called
<mvo> cachio: e.g. the qemu needs -bios /usr/share/OVMF/...
<cachio> mvo, this is the branch https://github.com/sergiocazzolato/snapd/tree/tests-enable-nested-on-core20
<cachio> mvo, I'll try that
<mvo> cachio: /usr/share/OVMF/OVMF_CODE.ms.fd to be precise, but I think it depends on the version of ubuntu where that file is :/
<ogra> mvo, did you see https://forum.snapcraft.io/t/how-to-use-camera-in-ubuntu-core18/14971/5 ? seems the start_x parameter does not work for the core18 pi installs
<cachio> mvo, thanks for the info, I'll try and debug
<mvo> ogra. meh, I have not, looking
<mvo> cachio: yeah, I suspect that might be it
<ogra> i wonder if there is some pattern match falling over the underscore ?
<mvo> cachio: or at least this must be tweaked too, maybe there is more
<mvo> ogra: I don't think we support "_" in the config, I wonder if start-x=1 will help
<mvo> ogra: but this should behave the same on uc16 and uc18, if not I'm puzzled
 * mvo also has not read the whole thread yet, it seems to be quite long
<ogra> ogra@pi4:~$ snap set system pi-config.start-x=1
<ogra> ogra@pi4:~$
<ogra> ogra@pi4:~$ snap set system pi-config.start_x=1
<ogra> error: cannot perform the following tasks:
<ogra> - Run configure hook of "core" snap (invalid option name: "start_x")
<ogra> ogra@pi4:~$
<ogra> yeah, its the underscore
<pedronis> zyga: afaict only opera is connecting to chromium-ffmpeg
<pedronis> all their various snaps: opera, opera-beta, opera-developer
<zyga> pedronis: still, I think it makes sense to do what you said about the assertions
<pedronis> yes
<mup> PR snapcraft#2874 opened: LP-1661626 : Symlink $XDG_RUNTIME_DIR/../dconf/user <Created by MarcusTomlinson> <https://github.com/snapcore/snapcraft/pull/2874>
<pedronis> zyga: I added something to thread and pinged kenvandine there
<zyga> pedronis: thank you! :)
 * Chipaca steps out for a bit
<mborzecki> pedronis: started adding https://github.com/snapcore/snapd/pull/7991#pullrequestreview-342491713 to ian's PR
<mup> PR #7991: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7991>
<mborzecki> quick errand, back in 20 or so
<cachio> mvo, hey, I see these errors starting the core20 image https://paste.ubuntu.com/p/FJfZdsNVrM/
<cachio> these 3 services cannot be started
<cachio> correctly
<cachio> mvo, do you know if any other configuration is needed for qemu?
<mvo> cachio: the e2scrub_reap service is known, the other two are not
<mborzecki> re
<zyga> Chipaca: could you please split https://forum.snapcraft.io/t/snapd-2-36-snap-confine-logic-walkthrough/7843/4 into a new topic
<zyga> "cannot fsck volume mounted on /var/snap"
<zyga> Chipaca: last two messages there please
<Chipaca> zyga: title?
<zyga> "cannot fsck volume mounted on /var/snap"
<Chipaca> zyga: in snapd?
<zyga> yes please
<zyga> thank you!
<Chipaca> zyga: done
<zyga> super :)
<Chipaca> gosh, almost standup time already
<Chipaca> where did my morning go
<zyga> right? :)
<mup> PR snapd#7993 opened: devicestate: enable encryption based on model grade <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7993>
<zyga> mvo: is .1 out?
<mvo> zyga: not yet, one question (if 7879 can be included pending for pedronis  first)
<mvo> zyga: why, do you have something?
<zyga> mvo: I have a 1 liner fix
<zyga> mvo: for a small bug
<zyga> yeah
<mvo> zyga: please push it then
<zyga> yup one sec
<mvo> zyga: and we can decide. thank you
<zyga> mvo: https://github.com/snapcore/snapd/pull/7994
<mup> PR #7994: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7994>
<mup> PR snapd#7994 opened: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7994>
 * Chipaca sneaks in a risk level "mauve"
<kenvandine> oSoMoN: can you please respond to the question about chromium-ffmpeg in https://forum.snapcraft.io/t/opera-requests-auto-connect-to-gnome-3-28-1804-interface/14505/19
<oSoMoN> sure
<mborzecki> ijohnson: looking at https://pastebin.ubuntu.com/p/568vkDFB7P/ from you standup
<ijohnson> zyga: thanks for that python0 patch, I commited it to the PR :-)
<ijohnson> hopefully the tests are happy again on this
<zyga> ijohnson: my pleasure :)
<ijohnson> mborzecki: nice thanks
<zyga> ijohnson: I only know because I made the python0 snap
<ijohnson> mborzecki: that one at least is easier cause you have a backtrace from SIGQUIT the other ones are just "timed out" :-(
<mborzecki> ijohnson: looks like a deadlock, between the snippet at standby_test.go:135 and m.Stop()
<ijohnson> zyga: :-) programming archeology indeed
<mborzecki> ijohnson: there's no channel cleaneup, none of the ch{1,2} are closed, so if the we're stuck in querying the opinions, stop will hang
<ijohnson> mborzecki: ah good find
 * zyga breaks for lunch 
<pedronis> oSoMoN: sorry, I mean are we genereally comfortable with any snap using chromium-ffmep?
<oSoMoN> pedronis, the typical use case is third-party browser snaps, but IÂ don't see why other snaps couldn't connect to it if they wanted to
<pedronis> oSoMoN: I'm trying to remove the step where they need to ask for auto-connection, because as opera shows it's likely to get wrong, because all content conection nees to take care holistically
<pedronis> *needs to be taken care holistically
<pstolowski> degville, ijohnson re snapctl start & --enable (if I got Graham's remarks right), it seems that snacptl start --help is not listing enable even though it's in the code; seems that the command descriptions are not set up correctly (i haven't investigated if it works as expected)
<degville> pstolowski: thank you! that's exactly what I was looking for.
<pstolowski> degville: snap start --help works as expected
<pedronis> oSoMoN: I have tried to ask this in the forum
<degville> pstolowski: thanks!
 * cachio lunch and bank
<oSoMoN> pedronis, that would certainly be better for third-party browser snaps
<ijohnson> degville: pstolowski: yes sorry got distracted, shall I still find you the relevant code snippet?
 * ijohnson was busy reading about how old python 0.9.1 is 
<pstolowski> haha
<pstolowski> ijohnson: i looked at ctlcmd/start.go and it seems wrong as far as help is concerned. but maybe i misunderstand what the issue was
<pstolowski> ijohnson: the flag itself should work, i'm talking only about help
<ijohnson> pstolowski: yes the help message there does need to be updated
<ijohnson> degville: as for finding where snapctl is implemented, were you able to sort through the code? snapctl specifically is a bit weird in that really the command options are stored inside the code for the snapd binary and not in the code for the snapctl binary
<degville> ijohnson: yes, thank you! I've got it now - I've got enough to update the docs.
<ijohnson> degville: great glad to hear it
<pedronis> oSoMoN: if you answer on the forum we can take it from there
<ijohnson> also zyga did you have any thoughts on having black run on all the python code in the snapd repo?
<zyga> ijohnson: we should do it
<zyga> :)
<zyga> I regard black as a good thing
<ijohnson> should we do it as part of run-checks or like spread-shellcheck do you think ?
<ijohnson> personally, I wouldn't really be happy if to contribute to snapd (a Go project) I needed to standup python tools just to run checks
<ijohnson> so I'm leaning towards having a spread test which checks all the formatting in the python code
<zyga> ijohnson: I would not go there
<zyga> ijohnson: it's not ultra-relevant and any kind of enforced format things ended up sucking IMO
<ijohnson> zyga: ok fair enough
<pedronis> ijohnson: I reviewed #7992, it seems to be missing unit tests afaict
<mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
<ijohnson> pedronis: did you mean unit tests of the grub methods?
<ijohnson> yes I think I am missing those now that you mention it
<pedronis> yes
<ijohnson> sorry I will add those today
<pedronis> there seem to be a buglet as well
<pedronis> which hopefully those will find :)
<ijohnson> pedronis: yes :-)
<ijohnson> pedronis: also regarding "." do you just mean in comments that are for doc-comments on exported methods or do you mean everywhere I should use "." ?
<pedronis> ijohnson: my POV on that is doc comment for exported things, I don't have a strict pattern for internal comments, it depends
<ijohnson> pedronis: ok IMHO I don't think it's needed for internal comments so I will just add to exported doc-comments then
<ijohnson> pedronis: do you want me to open the third PR for you to use for context now (even though it has still at least one bug) ?
<pedronis> ijohnson: as you prefer, this one looks good to me, except the missing tests etc
<ijohnson> pedronis: ok I wasn't sure if you were able to review the design of that interface without seeing it used in other places
<pedronis> ijohnson: well I proposed that design, so I have I sense how I imagine it used
<ijohnson> yes :-)
<pedronis> my imagination might be wrong, but it doesn't really affect the PR in itself
<pedronis> mborzecki: there's a preexisting bug in readModeenvImpl
<mborzecki> pedronis: hm?
<pedronis> mborzecki: modeenvPath := filepath.Join(rootdir, dirs.SnapModeenvFile) doesn't make sense
<pedronis> dirs stuff has already a rootdir in it,  we need a SnapModenvFileUnder helper instead
<pedronis> same approach as SnapStateFileUnder(rootdir string) for example
<mborzecki> hah
<mborzecki> right
<pedronis> mborzecki: can you look into this when you have moment
<mborzecki> pedronis: yes, sure
<pedronis> thx
<pedronis> mborzecki: thansk for the changes to 7991, I made one more nitpick comment that relates to this.
<ijohnson> mvo: I noticed https://forum.snapcraft.io/t/the-snapd-roadmap/1973 is a bit out of date now for 2.43 estimates?
<mvo> ijohnson: yes, I need to update it, hopefully later today
<ijohnson> great, thanks
<ijohnson> pedronis: as I'm updating the doc-comments on those grub methods it occured to me that currently EnableKernel() and EnableTryKernel() don't check that the kernel snap referenced there exists, do you think we should error out if an incorrect kernel snap is passed to those things?
<pedronis> also the only topic there will not make 2.43, but I doubt is the only thing we did in 2.43
<pedronis> ijohnson: that makes sense, OTOH Disable should probably be ok even the symlink is not there
<ijohnson> pedronis: ack, and yes agreed about Disable()
<mup> PR snapd#7995 opened: debian: check embedded keys for snap-{bootstrap,preseed} too <Created by mvo5> <https://github.com/snapcore/snapd/pull/7995>
<pedronis> I added some obvious things based on the trello column
<zyga> mborzecki: hey
<zyga> I saw this denial just now
<zyga> type=AVC msg=audit(01/14/20 15:50:55.249:2747) : avc:  denied  { mounton } for  pid=25654 comm=snap-update-ns path=/usr/lib/fontconfig/cache dev="sda1" ino=26841099 scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir permissive=1
<zyga> does this ring a bell?
<zyga> there were a few others
<zyga> https://www.irccloud.com/pastebin/Jgba6EB1/
<mborzecki> zyga: this in tests or a live desktop system?
<mborzecki> zyga: oh, and is it updated? the labeling bug https://bugzilla.redhat.com/show_bug.cgi?id=1659905 was fixed in july
<zyga> mborzecki: that's from spread
<zyga> mborzecki: it's the unstable suite so maybe it's expected but I wanted to ask you first
<mborzecki> zyga: centos then?
<zyga> centos 7, yep
<mborzecki> zyga: hmmm, it's s-u-n, probably setting u desktop iface mounts right? maybe we should allow that
<zyga> mborzecki: I presume so
<mborzecki> zyga: i suppose the policy won't get updated on centos7 :/
<zyga> why? because it's a separate package?
<mborzecki> zyga: because selinux-policy-targeted should be fixed to label /usr/lib/fontconfig/cache as fonts_cache_t like it does in F29+, rather than lib_t
<zyga> mborzecki: and it won't be or ... I don't follow, sorry
<mborzecki> zyga: i can file a bug, but hype seems to be about centos8 now :)
<zyga> aha
<zyga> I see
<zyga> thanks, I just wanted to check
<mup> PR snapd#7989 closed: devicestate: do not allow remodel between core20 models <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7989>
<pedronis> mborzecki: thanks for the changes to 7991
<pedronis> ijohnson: I think #7991 can be merged if you are ok with the changes in it
<mup> PR #7991: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7991>
<ijohnson> pedronis: ok, let me look I think it's probably fine but give me a minute
<pedronis> ijohnson: np, feel free to tweak/merge at your pace
<mup> PR snapd#7996 opened: overlord/standby: fix possible deadlock in standby test <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7996>
<mborzecki> ijohnson: ^^
<zyga> mborzecki: for .1 as well?
<ijohnson> thanks mborzecki
<mborzecki> that failing tests/core18/snapd-failover test makes me think we need to improve logging
 * zyga EODs and goes to do homework
<zyga> mvo: https://github.com/snapcore/snapd/pull/7994 needs a 2nd review but is otherwise ready
<mup> PR #7994: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7994>
<oSoMoN> jdstrand, may IÂ ask you to comment on the proposal in bug #1859643 (adding a personal-files plug on $HOME/.pki/nssdb) ?
<mup> Bug #1859643: [snap] cannot use shared NSS db <snap> <chromium-browser (Ubuntu):Triaged by osomon> <https://launchpad.net/bugs/1859643>
<pedronis> oSoMoN: jdstrand is off this whole week
<oSoMoN> ah, thanks
<oSoMoN> I'll make a note to ask him again next week
<Chipaca> woo, #7986 is green
<mup> PR #7986: store, o/snapstate: send default-tracks header, use RedirectChannel <Created by chipaca> <https://github.com/snapcore/snapd/pull/7986>
<Chipaca> (needing another review, hint hint)
<mvo> zyga looked at some test timeout right now, will try to look at it right after this
<Chipaca> EOD for me
<Chipaca> ð
<pedronis> ijohnson: something seems very unhappy in your HasModeenv branch, not sure why given it's no used yet
<ijohnson> pedronis: thanks for the ping, looking now
<ijohnson> though I'm about to head off for lunch so might be after your EOD that I get to the bottom of it
<pedronis> ijohnson: devicestate tests are unhappy
<ijohnson> pedronis: ah actually I know why this is happening, but I didn't think it would be caused until my next PR (where I have a fix for this)
<ijohnson> pedronis: it seems I will need to bring that fix in
<ijohnson> pedronis: not sure why it's caused by the modeenv branch, but the issue is that essentially the snap mapper (i.e. system -> core|snapd) doesn't get reset properly between the uc20 boot tests and uc16 ones
<pedronis> interesting
<ijohnson> the fix is to explicitly mock the snap mapper in devicestate in the test setup, adding a cleanup for the restore function
<pedronis> it doesn't seem the problem though, it happens even running just one test
<pedronis> ijohnson: it's Maciej last change actually
<ijohnson> pedronis: oh well then it's not what I ran into then
<ijohnson> pedronis: because what I ran into with my future changes was only a problem for multiple tests, not single ones
<pedronis> yea, no, it's something related to faking Modeenv reading
 * cachio afk
<ijohnson> pedronis: ok, I'll take care of it after my lunch if you haven't fixed it already
<pedronis> ijohnson: I'm trying to fix it
<ijohnson|lunch> pedronis: ok thanks
<cachio> pedronis, hey, do you know if core20 supports cloud config to setup a user
<cachio> I use cloud-init for core18 on nested vms
<cachio> but I think what is failing on core20 is that the user is not being created properly
<pedronis> cachio: not yet
<pedronis> I think
<pedronis> there's extra work to be done for it to work
<cachio> pedronis, a user assertion could work?
<pedronis> those maybe works
<cachio> pedronis, ok, I'll try that, thanks!!
<pedronis> done
<pedronis> ijohnson|lunch: pushed something (analogous as what we do in bootloader.Find)
<mup> PR snapd#7997 opened: overlord: increase settle timeout for slow machines <Created by mvo5> <https://github.com/snapcore/snapd/pull/7997>
<mup> PR snapd#7998 opened: httputil: use shorter timeout in TestRetryRequestTimeoutHandling <Created by mvo5> <https://github.com/snapcore/snapd/pull/7998>
<mup> PR snapd#7999 opened: devicestate: allow encryption regardless of grade <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/7999>
<ijohnson> pedronis: looks good to me, am I good to merge when green again?
<ijohnson> I guess I hadn't totally understood the relationship between the various dirs.Snap___ variables and dirs.GlobalRootDir
<pedronis> ijohnson: well it was simple and implicit, until because of UC20 we need to use them sometimes with rootdirs that are not "/" or the mocked value
<ijohnson> right with the /run/mnt/ubuntu-boot and such
<pedronis> to be clear we could also make the *Under functions more magic
<pedronis> it wouldn't still cover 100% of the situations though
<pedronis> so not sure
<pedronis> it's mostly boot, bootloader that need to care
<pedronis> ijohnson: but yes, feel free to merge if it gets green
<ijohnson> pedronis: ack
<mup> PR snapd#7991 closed: boot: add HasModeenv to Device <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7991>
<mup> PR snapd#7994 closed: cmd/snap-discard-ns: fix pattern for .info files <Bug> <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7994>
<mup> PR snapd#7996 closed: overlord/standby: fix possible deadlock in standby test <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7996>
<mup> PR snapd#8000 opened: release: 2.43.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8000>
<mvo> cachio: with a bit of luck I can give you 2.43.1 in beta tonight (well, my night :)
<cachio> mvo, perfecto
<cachio> I'll monitor the execution once it starts
<mvo> cachio: thank you! just released and baby-sit the build for core now
<cachio> mvo, nice, you can enjoy your night now :)
<mvo> cachio: almost :) need to trigger the core-beta snap build once the ppa finished building :) but then I will enojoy the night!
<ijohnson> cachio: where can I get a version of spread that can boot uc20 images with the PR's that Michael opened? do I just have to build it locally? I seem to remember you telling me about "spread2" that has all the patches we needed
<cmatsuoka> ijohnson: I built it locally, not sure if it's available pre-built
<ijohnson> cmatsuoka: sure fair enough. is it just https://github.com/snapcore/spread/pull/96 and https://github.com/snapcore/spread/pull/95 that need to be built into spread to boot uc20 ?
<mup> PR spread#96: spread: add support for system specific "flags" and use in qemu <Created by mvo5> <https://github.com/snapcore/spread/pull/96>
<mup> PR spread#95: spread: add support to define a custom bios with the qemu backend <Created by mvo5> <https://github.com/snapcore/spread/pull/95>
<cachio> ijohnson, which PR?
<cachio> 95?
<ijohnson> cachio: the PR's I just mentioned, 95 and 96 I think ?
<ijohnson> I don't know which PR's are fully needed
<cachio> ijohnson, there is no spread with that
<ijohnson> cachio: do I need those PR's to be able to boot uc20 with the ovmf/uefi stuff with the qemu backend?
<cachio> ijohnson, I think just the 95
<cachio> you can just build it
<ijohnson> cachio: ok I will build locally with 95 then
<cachio> and use it
<ijohnson> thanks
<cachio> ijohnson, np
<cmatsuoka> ijohnson: yes, I used those
<cmatsuoka> ijohnson: one is to use ovmf, and the other is to use virtio? you'll need both, otherwise the system will take 2 minutes to boot
<ijohnson> cmatsuoka: thanks yeah I built it with both of those patches
<mup> PR snapcraft#2875 opened: WIP: split debug information <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2875>
<mup> PR snapcraft#2239 closed: WIP: pluginhandler: after building a part, separate debug info from executables and strip them <Created by jhenstridge> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2239>
#snappy 2020-01-15
<mup> PR snapd#8001 opened: boot: enable UC20 kernel extraction and bootState20 handling <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8001>
<mborzecki> morning
<mborzecki> interesting postrm test failure on debian: https://paste.ubuntu.com/p/WVGk8pW7rF/
<mup> PR snapd#8002 opened: tests/core18/snapd-failover: collect more debug info <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8002>
<mborzecki> another one in 2.43.1 PR https://paste.ubuntu.com/p/F2WWvNc3Gv/
<mborzecki> mvo: hey
<mvo> mborzecki: good morning!
<mborzecki> mvo: can you upload the snapd release tarballs for 43 and 43.1?
<mvo> mborzecki: yes, sorry, will do that now!
<mborzecki> mvo: thank you!
<mvo> mborzecki: also need to update the roadmap and some more things related to the release. there were some build failures (mostly 7997 related) that delayed things
<mvo> mborzecki: big thanks for 8002
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski - good morning!
<pstolowski> o/
<mborzecki> mvo: btw. some weird interaction between apt command-not-found and snap advise https://paste.ubuntu.com/p/F2WWvNc3Gv/
<mvo> pstolowski: the server team is asking for a meeting about boot speed today, I added you, hope you have time. you will also need to refresh my memories where we stand here
<pstolowski> mvo: sure, thanks for invite
<mvo> mborzecki: this logs fails with  snapd : Depends: apparmor (>= 2.10.95-0ubuntu2.2) but 2.10.95-0ubuntu2 is to be installed - which looks unrelated to c-n-f. what am I missing :) ?
<mborzecki> mvo: uh,w8 not that one, this one https://paste.ubuntu.com/p/WVGk8pW7rF/
<mvo> mborzecki: looking
<pstolowski> mvo: it got side-tracked by the need of fixing services (generating wrappers, enabling them with regard to install hook and start-snap-services). first PR of the firsboot stuff landed (snap-preseed command), but will become usable once the snapd changes PR lands (blocked by services). services fixes have one open PR atm, there will be one more touching snapctl side.
<mvo> mborzecki: thanks, that " E: Could not read response to hello message from hook [ ! -f /usr/bin/snap ] || /usr/bin/snap advise-snap --from-apt 2>/dev/null || true: Broken pipe
<mvo> quiet: end of output" might be interessting for juliank. I remember him fixing a issue there a while ago but it seems like it's coming back
<zyga> good morning
<mvo> pstolowski: that's what I remember, I wonder if we could build a version that works without services or is that just impossible? i.e. we need the changes there
<mborzecki> mvo: oh cool, i was a bit confused that it'd call cnf handler on removal too
<mborzecki> zyga: hey
<zyga> hey, what's up?
<juliank> mborzecki: what's the apt version?
<mborzecki> juliank: let me check
<zyga> I'll try to do coding today but my hand hurts even more :/
<zyga> I wonder if this is that wrist injury that some coders have
<zyga> and that little wrestling with Janek is unrelated
<zyga> or i can type with just one hand, dunnop
<mvo> mborzecki: I don't remember the details but it's a bit strange
<mvo> mborzecki: tarballs updated
<mborzecki> juliank: it's 1.8.0~alpha3, though i see there's 1.8.4 uploaded already but we don't update it in the tests
<mborzecki> mvo: thanks!
<juliank> mborzecki: that needs updating, that's even a pre-release apt
<mborzecki> juliank: got it, thanks!
<mvo> mborzecki: sounds like sergio needs to update the images?
<mborzecki> mvo: yup
<mborzecki> mvo: i'll ping him when he gets online
<mvo> juliank: thank you! and sorry for the noise, we should have figured this out ourselfs
<mvo> mborzecki: thank you
<juliank> just let me double check
<juliank> yup
<juliank> that bug was fixed in 1.8.0~rc1
<pedronis> mvo: mborzecki: we need to chat about boot partition layouts, because I probably misunderstood something, and we are producing confusing code as a consequence, also I'm not sure the differences between 20 and 18/16 for boot have a reason or just arbitrary
<mborzecki> juliank: thanks for double checking! we'll update the spread images, and hopefully the problem will go away ;)
<mvo> pedronis: sure, when do you want to chat?
<pstolowski> mvo: yes, it's possible, that's what i did originally
<pedronis> mvo: mborzecki: in 5-10 mins ?
<mvo> pstolowski: ok, maybe worth a chat with pedronis if we can give the server team something before we nail services
<mvo> pedronis: works for me, standup channel in 10min?
<pedronis> yes
<mborzecki> pedronis: sure, let me grab some coffee
<pstolowski> mvo: sure, sounds good
<pedronis> mborzecki: mvo: I'm in the standup
<zyga> afk for a moment
<zyga> re
<pstolowski> mvo, pedronis let me know if/when we can talk about firstboot & services
<mvo> pstolowski: either around 11:30 or after the standup, depends how my meeting at 11:00 goes but probably after the standup
<mvo> pstolowski: does not have to be long, just making sure we have a common understanding going into the other meeting today with server
<pstolowski> mvo: ok, either sounds fine
 * zyga goes upstairs to make cofee
<zyga> *coffee
<mup> PR snapd#8003 opened: o/ifacestate, api: implementation of snap disconnect --forget <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
<sdhd-sascha> hi,
<sdhd-sascha> i have trouble with glibc. Is it possible to deliver my own glibc inside a snap ?
<zyga> sdhd-sascha: yes though I'd like to understand why you think that is required
<zyga> I'll be back shortly, I really need to make that coffee
 * zyga gets up and leaves
<sdhd-sascha> zyga: i use `libsnapcraft-preload.so`. And in `canonicalize.c` is a macro: "`#if SHLIB_COMPAT(libc, GLIBC_2_0, GLIBC_2_3)`". I want to remove this part, because the `realpath` function only works if the `resolved` is non NULL
<sdhd-sascha> zyga: i already asked sergiusens. But he's really busy.
<sdhd-sascha> Maybe there is another solution, which i didn't see. (My C++ knowledge is very old and non-practical)
<sdhd-sascha> This is the source, which works only without `snapcraft-preload`.
<sdhd-sascha> With `snapcraft-preload` one call of `realpath` failed.
<sdhd-sascha> https://www.irccloud.com/pastebin/wyZvthyv/
<sdhd-sascha> Is there already a non-compat glibc which could be packaged with a snap ?
<zyga> re
<sdhd-sascha> :)
 * sdhd-sascha lunch
<mborzecki> hmmm - Download snap "strace-static" (18) from channel "stable" (http2: server sent GOAWAY and closed the connection; LastStreamID=1, ErrCode=NO_ERROR, debug="")
<mvo> GOAWAY is rude
 * mvo shakes fist
<mborzecki> log if anyone's interested: https://paste.ubuntu.com/p/NMRnvTRTqP/
<zyga> mvo: we should rename it to PLEASESTOP
<mborzecki> zyga: mvo: and the client sends BENICE
<zyga> it should just return BEHAVE!
<mvo> :-D
<mborzecki> btw https://github.com/systemd/systemd/issues/10872 is fixed, i'm trying the reproducer right now to confirm it's fine
<mborzecki> (across a decent number of runs)
<Chipaca> is http2 secretly intercal
<pedronis> mvo: mborzecki: I made this comment in the UC20 boot PR: https://github.com/snapcore/snapd/pull/7992#issuecomment-574609408
<mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
 * sdhd-sascha re
<pstolowski> sigh, 'git push merge master' should dwim
<sdhd-sascha> zyga: what do you think, what is the best way to solve the issue with realpath ? Would be nice, if it would be possible to mount tmpfs over /dev/shm. So i didn't need the preload library with the realpath issue.
 * Chipaca brb
<zyga> sdhd-sascha: is the problem that realpath() does not behave as it is documented to?
<sdhd-sascha> zyga: with the preload library, realpath goes the call-path, like GLIBC <= 2.3. Without it like modern. The preload code, seems to choose a wrong entry point for realpath.
<sdhd-sascha> I mean: with preload: it returns NULL instead of the path, if the seconde param is NULL.
<zyga> sdhd-sascha: can this be fixed by changing the preload library?
<zyga> sdhd-sascha: perhaps fixing it in snapcraft itself
<sdhd-sascha> zyga: yes, i'm sure, it could be fixed by changing the preload library. But i don't know yet, how i could make this function call `dlsym (RTLD_NEXT, FUNC_NAME)` to choose the correct version.
<sdhd-sascha> The preload-library isn't part of snapcraft, yet. https://github.com/sergiusens/snapcraft-preload
<zyga> I see
<zyga> sdhd-sascha: can you use dlvsym?
<zyga> it allows you to pick the version you want
<sdhd-sascha> zyga: well, i can think about it, to change all library calls... good, idea
<sdhd-sascha> zyga: what glibc version would you prefer for the future ?
<zyga> >
<zyga> I have no idea what I am supposed to answer
<sdhd-sascha> maybe, 2.19 ?
<sdhd-sascha> zyga: thank you
<zyga> no idea :)
<zyga> can you explain why one over another?
<zyga> perhaps you should dlvsym the newset that you knew about
<zyga> and then fall back
<zyga> note that it is not library version
<zyga> but symbol version
<zyga> check the symbol versions available for realpath
<zyga> and probably pick the one that works the way you want
<zyga> (one exact hit)
<sdhd-sascha> zyga: no, i have to read the documentation. Many of the redirected calls are from linux itself, and i only need to redirect the stdlib, and so ...
 * zyga doesn't understand how that is related
<zyga> or doesn't understand the original question
<mup> PR snapd#8000 closed: release: 2.43.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8000>
<sdhd-sascha> zyga: sorry. I think you understand me. My last sentence was about specific to serguissens code ;-)
<sdhd-sascha> zyga: i ask about the version. Because i would create a PR, if i get it worked. I need at least > 2.3
<zyga> you can always reimplement realpath
<zyga> if good version in glibc -> use it
<zyga> otherwise -> here's one from scratch
<sdhd-sascha> zyga: well. my problem is not realpath. It's /dev/shm. That's why i use the preload. But then the realpath didn't worked...
<zyga> sdhd-sascha: what's with /dev/shm that is a problem for your app?
<sdhd-sascha> zyga: yes. Apparmor says permission denied for /dev/shm/....
<zyga> right, because apps tend to drop random bits of shm there and we don't want them to use it as unmediated IPC
<sdhd-sascha> Yes, and here, i first patch sway to use "mktemp...". Then the "application menu" wants to write /dev/shm too...
<zyga> interplay of apps and /dev/shm is ... complex
<sdhd-sascha> I mean, i patched "wlroots", which i base library for wayland desktop's.
<sdhd-sascha> is
<sdhd-sascha> It would be nice, if a snap could mount tmpfs over /dev/shm. But is then with xdg-proxy, i some application want to talk
<sdhd-sascha> What is with xdg-proxy... I mean "inter-snap" communication of snaps over "/dev/shm"
<sdhd-sascha> zyga: you already helped me. I think i try to fix the preload-library ?!
<zyga> sdhd-sascha: I think that usage of /dev/shm must be changed and reorganized
<zyga> sdhd-sascha: currently it's pretty much like exchanging files via /tmp
<sdhd-sascha> Oh, well... What if i use dlvsym with version... And then there are some more preloads used
<zyga> sdhd-sascha: we don't have private per-snap /dev/shm because that would break everything
<zyga> sdhd-sascha: but I think something along those lines would help a _lot_
<sdhd-sascha> Maybe, for my case is to recompile glibc, without the old `realpath`. Or, like you says. Write another `realpath`. Or i patch sway, to use the old calling convention
<zyga> what I was describing was a long term plan
<zyga> for short term we need hacks and hacks and tweaks to apparmor policy
<zyga> sadly :/
<sdhd-sascha> I think, something like chroot and overlayfs would change the snap world.
<zyga> you can use chroot
<zyga> but I don't think that helps with the complexity of modern IPC
<Chipaca> sdhd-sascha: do you have a minimal snapcraft with a .c that tries to use realpath and fails?
<zyga> wayland + pulseaudio == loads of /dev/shm usage
<sdhd-sascha> This code, fails on local machine, too. If i use the LD_PRELOAD=./libsnapcraft-preload.so
<sdhd-sascha> https://www.irccloud.com/pastebin/GubDCCNh/
<sdhd-sascha> on, eoan
<mborzecki> cachio: hi, can you trigger an update of debian-sid base image?
<mborzecki> cachio: apt in that image needs to be updated, otherwise this problem can happen occassionally https://paste.ubuntu.com/p/WVGk8pW7rF/
<mvo> I guess "apt full-upgrade -y" is not a bad idea
<sdhd-sascha> zyga: the code above, goes in gdb the way to "glibc-2.30"/stdlib/canonicalize.c" :
<cachio> mborzecki, hello, sure, let me take a look
<sdhd-sascha> https://www.irccloud.com/pastebin/kL1fM19L/
<sdhd-sascha> And there, it's returns NULL as path
<sdhd-sascha> If i use, dlvsym, then no other preload can overwrite realpath.
<sdhd-sascha> Or, i'm wrong ? not sure
<zyga> sdhd-sascha: I dont think that works this way
<zyga> sdhd-sascha: but I cannot focus on this right now, sorry
<zyga> sdhd-sascha: dlvsym is really just "in the symbols I've loaded, find the one with the version marker as well"
<zyga> it's not "load just that version"
<zyga> you really only open one glibc.so
<zyga> inside you look for a symbol with matching name *and* version
<zyga> that's the trick
<zyga> IMO
<cachio> mborzecki, https://travis-ci.org/snapcore/spread-cron/builds/636199611
<cachio> mborzecki, it was updated on  Monday
<cachio> the image we use for our tests
<sdhd-sascha> zyga: thank you. I was wrong. It's still possible to use other preloads, because of the loading order of the libs ;-)
<mup> PR snapd#7986 closed: store, o/snapstate: send default-tracks header, use RedirectChannel <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7986>
<mup> PR snapd#8004 opened: cmd/snap: print full channel in 'snap list' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8004>
<Chipaca> pedronis: do we want snap info to explicitly point out a default track?
<Chipaca> as in, default-track: foo if foo != ""
<mborzecki> cachio: so maybe we need to do a full-upgrade like mvo indicated, apt version in sid is 1.8.4 atm, but our image has 1.8.0~alpha3 for some reason
<cachio> mborzecki, ok
<cachio> mborzecki, we are not doing the full upgrade for sid because of this
<cachio>     # We are not making dist-upgrade because it is creating a dependencies issue
<cachio>     # which is making fail the preparation of the snapd test suite
<cachio> I'll manually trigger and then we can see how it works
<cachio> mborzecki, running
<cachio> in case the image breaks we can revert it
<zyga> brb.
<mvo> cachio: aha, this is sid? yeah, then feel free to just uprade apt
<cachio> mvo, I updated the file and am upgrading sid, it will be ready for testing in few minutes
<mvo> cachio: nice, thank you
<mborzecki> cachio: thanks!
<pedronis> Chipaca: there was this proposal to put a default note on the most stable risk of it
<pedronis> Chipaca: if we add default-track:  it should probably be only in --verbose
<Chipaca> pedronis:   foo/candidate âª :)
<pedronis> Chipaca: this re-landed only recently right: https://forum.snapcraft.io/t/behavior-change-risk-only-channel-specifications-will-not-switch-track/11769  , it's not in 2.43 ? cc mvo
<pedronis> context: https://forum.snapcraft.io/t/the-snapd-roadmap/1973
<mvo> ijohnson: sure thing, we are in the standup ho now
<Chipaca> failures in debian-sid are expected right now, yes?
<sergiusens> pstolowski: hey there, mind taking a look at https://github.com/snapcore/snapcraft/pull/2876
<mup> PR snapcraft#2876: meta: handle plug & slot string objects <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2876>
<pstolowski> sergiusens: sure, with a caveat that my python foo got a bit rusty ;)
<pstolowski> but it's better than my vala foo ;)
 * zyga still fights with a bug
<zyga> I should break for coffee and think instead of just hammering the keyboard
<sergiusens> pstolowski: insights appreciated more around the semantics around slots/plugs than the code :-)
<ijohnson> mvo: should we add `system-backup` (and potentially any other new interfaces in 2.43) to the snapd release roadmap as new features for 2.43?
<mvo> ijohnson: yes! feel free to edit
<ijohnson> mvo: cool :-)
<pedronis> Chipaca: does our snap/partial caching do nothing in this case? https://forum.snapcraft.io/t/failure-to-fetch-assertions-stops-installation-immediately/15059
<Chipaca> pedronis: no
<Chipaca> pedronis: not if the change was aborted
<pstolowski> sergiusens: reviewed
<sergiusens> thanks pstolowski
<pstolowski> yw
<mup> PR snapcraft#2876 closed: meta: handle plug & slot string objects <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2876>
 * cachio lunch
<mup> PR snapd#8005 opened: api: don't return connections referring to non-existing plugs/slots <Created by stolowski> <https://github.com/snapcore/snapd/pull/8005>
<mup> PR snapcraft#2878 opened: extensions: fix merge_lists to handle non-string list cases <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2878>
<mup> PR pc-amd64-gadget#33 opened: grub.cfg-boot: use $prefix/kernel instead of $ubuntu-boot/kernel <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/33>
<mup> PR snapcraft#2879 opened: [3.9-backport] meta: ensure Snap's `assumes` is initialized as a set <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2879>
<mup> PR snapd#8006 opened: tests: skip interfaces-network-manager on arm devices <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8006>
<pedronis> ijohnson: do we still need Recovery: true in the new tests in 7992
<mup> PR snapd#8007 opened: tests: remove execution of ubuntu 19.04 from google backend <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8007>
<mup> Bug #1745772 changed: Can't run snap in lxd container <Snappy:Fix Released> <https://launchpad.net/bugs/1745772>
<mup> Bug #1664427 changed: thefuck snap gets an apparmor denial even in classic confinement <classic> <isv> <Snappy:Confirmed> <https://launchpad.net/bugs/1664427>
<mup> Bug #1675413 changed: snap disconnect doesn't support tab completion <Snappy:Fix Released> <https://launchpad.net/bugs/1675413>
<mup> PR snapd#8008 opened: render: add the render package and basic widgets <Created by zyga> <https://github.com/snapcore/snapd/pull/8008>
<mup> PR snapcraft#2880 opened: [RFC] schema: introduce configuration for package management repositories <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2880>
#snappy 2020-01-16
<mup> PR snapcraft#2877 closed: [3.9 backport] meta: handle plug & slot string objects <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2877>
<mup> PR snapcraft#2879 closed: [3.9-backport] meta: ensure Snap's `assumes` is initialized as a set <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2879>
<mup> PR snapcraft#2881 opened: meta: fix missing provider case for get_provider_content_directories() <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2881>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mup> PR snapd#7998 closed: httputil: use shorter timeout in TestRetryRequestTimeoutHandling <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7998>
<zyga-laptop> o/
<zyga-laptop> mborzecki hey
<zyga-laptop> I will be back shortly, the office is still super cold after the night
<mborzecki> zyga-laptop: hey
<zyga-laptop> I need to catch up with things from yesterday
<zyga> oh, iCloud is back!
<zyga> ircloud
 * zyga builds 2.43.1 update
<zyga> mborzecki: we have a new dependency on Suse?
<zyga> we need fake root for tests
<mborzecki> zyga: hm?
<zyga> mborzecki: without fake root dependency
<zyga> https://www.irccloud.com/pastebin/08hHDzfx/
<zyga> I'll send a patch shortly
<zyga> https://github.com/snapcore/snapd/pull/8009
<mborzecki> zyga: yeah, we shuld porbably skip those tests
<mup> PR #8009: packaging/opensuse: build-depend on fakeroot <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8009>
<mup> PR snapd#8009 opened: packaging/opensuse: build-depend on fakeroot <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8009>
<mborzecki> zyga: otoh, fakeroot is mocked in those tests, the test will fail if it's called and not mocked by some useful code
<zyga> hmm?
<zyga> what?
<mborzecki> zyga: 2 lines up from the first point it failed
<mborzecki> zyga: https://github.com/snapcore/snapd/blob/master/gadget/mkfs_test.go#L60
<zyga> dunno
<mborzecki> zyga: was this on obs?
<zyga> no, in "osc build"
<mborzecki> zyga: can you run those tests with -check.work and inspect the test dir afterwards?
<zyga> mborzecki: in osc build or manually?
<zyga> (in either case, later, updating TW now)
<zyga> I'll grab some food, see you after breakfast
<pstolowski> morning
<mborzecki> mvo: side note, does it make sense to start console-conf in install mode at all?
<mvo> mborzecki: it does not
<mvo> pstolowski: good morning
<mborzecki> pstolowski: hey ;)
<pstolowski> o/
<sdhd-sascha> good morning,
<sdhd-sascha> zyga: yesterday, i solved it. i found in glibc, that dlvsym is like dlsym with version equal null. So i add a PR for snapcraft-preload. And it works for sway :-)
<mvo> mborzecki: do you remember if we had a forum top to the parallel seccomp setup?
<mborzecki> mvo:  let me check
<mvo> mborzecki: no need to create it if it's not there, I'm just updating the snapd roadmap with interessting bits of 2.43
<mborzecki> mvo: no, i don't think we had a topic for that
<mvo> that's fine, thanks for checking
<mborzecki> hm wonder whether we could build an image with systemd.debug-shell=1 out of the box
<zyga> back now
<zyga> sdhd-sascha: cool, I'm glad you solved it :)
<zyga> hey mvo :)
<zyga> hey pawel :)
<sdhd-sascha> zyga: thank you. Just talk about the problem with you, was a great help to choose a solution ;-)
<zyga> mvo: I published the render code and will try to sync with chipaca about it
<zyga> mvo: I need to send some tweaks that I thought about while sleeping but it's mostly enough what I need for explain
<zyga> mvo: I published 2.43.1 in suse, shall I do fedora/debian before jumping into regular PR work?
<Chipaca> zyga: your implementation of RuneWidth is rather optimistic :)
<zyga> Chipaca: I was sure you'd be interested in that one :)
<zyga> Chipaca: yeah, that's why it is in the heuristic package
<zyga> Chipaca: happy to take feedback on every part
<zyga> Chipaca: if you are reading it already, the two changes I was thinking about are: relative positioning (d'oh, why did I do absolute) and changing Pre widget to Paragraph that I also implemented but left out - paragraph does text folding
<zyga> I think it's just generally better than a fixed text thing
<pstolowski> hey zyga
<zyga> hey pawel :)
<mvo> hey zyga, good morning
<Chipaca> zyga: does it support truncation / elision of text?
<zyga> Chipaca: no, it supports folding into available width - the whole design of this is like printer paper
<zyga> you have a fixed with
<zyga> but all the height you want
<zyga> Chipaca: it supports clipping though, so you can force it to occupy some space
<Chipaca> zyga: thinking of things we are doing that would benefit from something like this, find and list come directly to mind
<Chipaca> but both of them require elision
<zyga> Chipaca: I think the thing you should look at is the signature of Widget.Pack
<mvo> zyga: release> not super urgent to release 2.43.1, I think it's fine to release when it hits our candidate channel
<zyga> if we give it information about what the constraints are (currently it's just the remaining width) we could do what you just described
<zyga> mvo: ok
<zyga> Chipaca: do you have time now? we could jump into a HO and talk about this
<Chipaca> zyga: I'm having breakfast, now :)
<zyga> Chipaca: ah, sorry
<Chipaca> zyga: for 'snap list' one problem you have is that almost every field needs shrinking, and some are more 'important' than others
<zyga> indeed, I was thinking about tabular widget
<Chipaca> doing that in a generic way is doable, but you might need to be knuth
<zyga> right now vbox and hbox are insufficient to perfectly replicate a table
<zyga> Chipaca: heh, I remember reading that paper a few years ago - about table layout problems
<zyga> it's a surprisingly hard problem
<mup> PR snapd#8010 opened: snap-bootstrap: add support for "recover" mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8010>
<Chipaca> zyga: the good news is fixed-width makes it a little simpler :)
<Chipaca> the bad news is double-width characters make it hard again
<mup> Bug #1655376 changed: Add support for android/touch type images <personal> <Canonical System Image:Invalid by pat-mcgowan> <Snappy:Won't Fix by ogra> <https://launchpad.net/bugs/1655376>
<mup> PR snapd#7997 closed: overlord: increase settle timeout for slow machines <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7997>
<mborzecki> zyga: heh, pstolowski correctly spotted that those tests are in snap-bootstrap
<zyga> mborzecki: hmm?
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8009#pullrequestreview-343774644
<mup> PR #8009: packaging/opensuse: build-depend on fakeroot <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8009>
<zyga> pstolowski: thanks pawel!
<sdhd-sascha> What is you opinion. What should happened if a symlink couldn't created. I think the snap shouldn't abort installation.
<sdhd-sascha> `cannot update snap namespace: cannot create symlink in "/etc/sway": existing file in the way`
<zyga> hmm
<zyga> so do we use fakeroot in the real code?
<zyga> sdhd-sascha: layouts are required, if it cannot be created and there are install hooks or configure hooks then installation is aborted
<pstolowski> yw, good!
<sdhd-sascha> I have to handle two case's. Case 1: no desktop packages are installed on the host. Case 2: a desktop installation exists on the host.
<sdhd-sascha> E. g. openGl drivers are on the host. Then the snap don't need to deliver them.
<sdhd-sascha> ...
<sdhd-sascha> Would it make sense, to add "try-symlink" to layouts ?
<sdhd-sascha> And/Or "try-bind" mount
<mborzecki> zyga: yes, we do, but that's relevant only for uc20 atm
<mborzecki> zyga: got a fix, can open a PR
<mborzecki> it's a single patch, so you should be able to cherry pick it without trouble
<zyga> mborzecki: cool, thank you!
<zyga> sdhd-sascha: I don't know, can you give me an example please?
<zyga> sdhd-sascha: but it feels like unrelated to layouts
<zyga> sdhd-sascha: layouts cannot grab data from the host
<zyga> sdhd-sascha: what you are describing seems more like interface connections
<sdhd-sascha> zyga: currently i used this:
<sdhd-sascha> layout:
<sdhd-sascha>   /etc/sway:
<sdhd-sascha>     symlink: $SNAP/etc/sway
<mup> PR snapd#8009 closed: packaging/opensuse: build-depend on fakeroot <Simple ð> <Created by zyga> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8009>
<mup> PR snapd#8011 opened: cmd/snap-boostrap: add mocking for fakeroot <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8011>
<sdhd-sascha> zyga: but this is not urgent.
<mborzecki> mvo: posted a little guide for working with vm cloud images (incl. uc20) and feedimg some quick setup via cloud-init https://gist.github.com/bboozzoo/a1303a1e4deb516c2ad9a1e64835c341
<sdhd-sascha> i had another case in the past. But can't remember, so i can give more examples in the next days. Current i test, sway on both case's.
<zyga> mborzecki: maybe mention the gist on the forum
<zyga> mborzecki: it will be easier to find
<mvo> mborzecki: nice!
<mup> PR snapd#8012 opened: o/devicestate: do not create perfTimings if not needed inside ensureSeed/Operational <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8012>
<mvo> mborzecki: did you end up with network in the qemu vm?
<pstolowski> Chipaca: hey, conflict in #8004
<mup> PR #8004: cmd/snap: print full channel in 'snap list', 'snap info' <Created by chipaca> <https://github.com/snapcore/snapd/pull/8004>
<mvo> mborzecki: I remember there was an issue yesterday?
<mborzecki> mvo: we got it resolved once the system booted into the run mode and kernel module were mounted at the right location
<pstolowski> pedronis: boot speed ho?
<mup> PR snapcraft#2881 closed: [backport] meta: fix missing provider case for get_provider_content_directories() <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2881>
<zyga> brb
<zyga> re
<Chipaca> going to take a break in a few minutes. Nothing particularly noteworthy in triage today.
<mup> PR snapd#8002 closed: tests/core18/snapd-failover: collect more debug info <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8002>
<mborzecki> mvo: this will help a little https://i.imgur.com/86JdDRU.png
<mborzecki> not sure why the quantity got badly formatter, maybe it's not bytes (?)
<mborzecki> heh, the conversion is wrong ;)
<mvo> mborzecki: nice!
<mvo> mborzecki: you rock
<mborzecki> btw. u-i should probably create an image large enough to fit the layout too
<mvo> mborzecki: yes, probably something for sil2100 to make ubuntu-image smarter so that it knows how much space to reserve when building a uc20 image (right now it creates an image that is too smalll to fit the partitions)
 * Chipaca afk
<pedronis> mvo: I'm looking at #7992, yes I think the issue is that all the fixture code is recovery oriented but shouldn't for this new stuff
<mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
<pedronis> mvo: I'll see if I can untangle that a bit
<mvo> pedronis: nice, thank you!
<zyga> Chipaca: hey, is this a good time?
<pedronis> mvo: done, but there is probabably a bit more to do there
<mborzecki> Chipaca: there's no code for format MiB/GiB quantities in the tree, is there?
<zyga> pedronis: I'd like to merge https://github.com/snapcore/snapd/pull/7875 as-is
<mup> PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
<zyga> do you think it's possible to get your review today?
 * zyga jumps to another PR
<pstolowski> ijohnson: hi, thanks for the insight into the root cause of https://github.com/snapcore/snapd/pull/7871 failures! i got it working (i don't know yet if it passes on all systems, waiting for travis, but as far as this denial is concerned, it should be fine now)
<mup> PR #7871: tests: add spread test for hook permissions <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871>
<popey> I have asked this before, sorry. When are we getting the "don't update me please, I'm running" for applications?
<pstolowski> i think zyga worked on this ^
<zyga> popey: it's stuck in review for ... months?
<zyga> popey: I just resolved a merge conflict https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mup> PR snapd#8013 opened: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
<pstolowski> zyga: i'll take a look at it later today
<zyga> pstolowski: super, thanks!
<zyga> I'll push a small tweak for older merge breaking after test rename
<mup> PR snapd#8011 closed: cmd/snap-boostrap: add mocking for fakeroot <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8011>
<mborzecki> zyga: you can cherry-pick the patch now ^^
<zyga> mborzecki: I released a variant with fakeroot build-dep
<zyga> mborzecki: I'll get this for 2.44 :)
<mborzecki> ah, ok
<zyga> mborzecki: or I can do a -2 if there's some other things to cherry pick
 * pstolowski lunch+errand, bbl
<ogra> zyga, should all layouts be set up when i use snap run --shell for a daemon ?
<zyga> ogra: yes
<ogra> hmm, weird
<ogra> ls prime/etc/dbus-1/system.d/
<ogra> org.freedesktop.DisplayManager.conf
<ogra> root@localhost:/home/ogra# ls /etc/dbus-1/system.d/
<ogra> wpa_supplicant.conf
<ogra> the above is from the packaging dir ... the below one from snap run --shell ... i have a bind layout defined for /etc/dbus-1
<ogra> i dont get any error when installing or anything ... so i'd expect to find that org.freedesktop.DisplayManager.conf file somehow ...
<mup> Bug #1859974 opened: failing to release devmode revisions to edge/beta channels <Snappy:New> <https://launchpad.net/bugs/1859974>
<zyga> ogra: can you show me the relevant parts of snap.yaml please
 * zyga jumps to setgid branch
<zyga> looking at those failures now
<sil2100> mvo, mborzecki: on it! (soon)
<mvo> sil2100: thank you
<mvo> sil2100: not a blocker but certainly will improve the experience :) (all of us ran into this problem)
<sil2100> mvo: yeah, when I switched to the 'cleaner' way of handling system-seed, I guess I forgot about the image-size calculation
<mborzecki> sil2100: thanks!
<mborzecki> mvo: uc20 rite of passage
 * zyga sighs at inability to stop spread
<mborzecki> zyga: ^\ doesn't work?
<mborzecki> zylop: i mean sigquit
<mborzecki> zyga: ^ :)
<zyga> mborzecki: yeah but that leaves garbage
<mborzecki> zyga: you need to spread -discard -spread-pid=<..> later
<zyga> yeah but ... why do I need to :/
<mborzecki> cmatsuoka: mvo: do you have any notes on runnnig qemu with tpm?
<cmatsuoka> mborzecki: once you have the tpm simulator installed, you must run qemu the the appropriate parameters
<cmatsuoka> mborzecki: see them here: https://github.com/snapcore/spike-tools/blob/master/run-test.sh
<mborzecki> cmatsuoka: thanks
<cmatsuoka> mborzecki: it's the line with tpms in it
<zyga> brb
<ijohnson> morning folks
<ackk> hi, I'm seeing an issue when using snapcraft candidate. it seems the command-*.wrapper files are not being created. did something change there?
<Chipaca> sergiusens: ^
<ackk> oh I'm not on the latest candidate, I guess it just got udpated
<zyga> degville: please ping me when you look at the content interface docs, there's some rarely known features there
<zyga> s/'s/are
<mup> Bug #1859974 changed: failing to release devmode revisions to edge/beta channels <Snap Store:New> <https://launchpad.net/bugs/1859974>
<degville> zyga: will do, thank you!
<sergiusens> ackk: wrappers are now gone, instead what used to be in the wrapper is now part of the command-chain, this allows for "snap run --shell <snap.app>" to have the right command from the get go
<mup> PR pc-amd64-gadget#33 closed: grub.cfg-boot: use $prefix/kernel instead of $ubuntu-boot/kernel <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/33>
<ackk> sergiusens, is there a way from inside the snap to run stuff as if it were from the outside? we currently call the wrapper script explicitly since we need to call stuff under snapcraft-runner for the LD_PRELOAD/PATH exports
<ackk> sergiusens, I guess we can wrap everything with our wrapper otherwise
<mup> PR core20#18 closed: static: try using /run/mnt/snapd first in run-snapd-from-snap <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/core20/pull/18>
<sergiusens> ackk: hmm, that wrapper was always an implementation detail, that said, "$snap/command-chain/snapcraft-runner" will have most of what you need
<mup> PR core20#17 closed: Drop encoding digits in units and code paths.  <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/17>
<ackk> sergiusens, I see, thanks
<ackk> sergiusens, is snapcraft-runner used both for apps and daemons?
<ackk> ah yeah it is, cool
 * zyga goes to grab lunch
<sdhd-sascha> sil2100: hi. Is there a tool to use, to generate the changelog entry's for ubuntu-image ?
<ijohnson> pedronis: thanks for the patches to 7992, I guess I never quite understood what you meant by NoSlashBoot option when you mentioned it in our meetings but I see what you meant now.
<pedronis> np
<mup> PR snapd#8007 closed: tests: remove execution of ubuntu 19.04 from google backend <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8007>
<mup> PR snapd#8014 opened: tests: run `uc20-snap-recovery-encrypt` test on 20.04-64 as well <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8014>
<cachio> mvo, pedronis should I enable ubuntu 20.04 tests?
<cachio> as 19.04 is gone
<cachio> I already have an image
<cachio> or should I make it once I am back from my vacactions
<cachio> ?
<sil2100> sdhd-sascha: hey! I usually just add one with dch for that - but I can also create those for you, as long as everything else is good to go
<Girtablulu> when I try to start snap-store voa terminal, I get no protocol specified and Unable to init server: Could not connect: Connection refused - what's the issue?
<sdhd-sascha> sil2100: i cleaned up, rootfs_size ( 182 ) and added one test.
<Chipaca> Girtablulu: and if you try to launch it in a different way?
 * cachio lunch
<Girtablulu> Start menu and terminal both dont work
<Chipaca> Girtablulu: sounds like a bug to me
<Girtablulu> mmmh okay
<roadmr> Girtablulu: https://launchpad.net/snap-store to report it maybe
<Girtablulu> yea will do
<mvo> cachio: yeah, I think we should enable 20.04-64, maybe to unstable at first
<Chipaca> Girtablulu: please include the output of 'snap version' there
<Girtablulu> will do
<cachio> mvo, sure, I'll add this after lunch
<Chipaca> Girtablulu: thanks
<zyga> fd
<zyga> re :)
<zyga> mvo: can we merge https://github.com/snapcore/snapd/pull/7238 ?
<mup> PR #7238: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Security-High> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7238>
<zyga> mvo: +3 and green
<zyga> I can merge master into it to ensure tests passed recentlty
<zyga> *recently
<pedronis> zyga: it can be merged, but yes best to merge master first
<zyga> ok
<zyga> jd
<mvo> zyga: looks like samuele and jamie are happy so I see no reason not to merge it
<zyga> cool, I'll merge it after it passes one round of tests
<mvo> ok
<pstolowski> zyga: i did one pass over #7825, i'll continue tomorrow morning
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<pstolowski> cachio, ijohnson can you take another look at #7871 if/when it gets green (just had to restart the job, it seemed to be stuck)
<mup> PR #7871: tests: add spread test for hook permissions <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871>
<ijohnson> pstolowski: sure
<pstolowski> thanks
<pstolowski> eod, cu
<mup> PR snapd#8015 opened: [RFC] daemon, store: support download resume from /v2/download <Created by mvo5> <https://github.com/snapcore/snapd/pull/8015>
<pedronis> zyga: I pushed a tweak to #7875 along the last comments, it can go in if it gets green
<mup> PR #7875: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7875>
<mup> PR snapcraft#2882 opened: extensions: change extension merge-strategy to fix build-environment <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2882>
<mup> PR snapd#8016 opened: gitignore: ignore snap files <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8016>
<mup> PR snapd#8004 closed: cmd/snap: print full channel in 'snap list', 'snap info' <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/8004>
<cjp256> on a 16.04 system using the snapd deb (2.34.2),  should one be able to just run `sudo snap install snapd` to get the latest?
<cjp256> or would there other steps to take?
<mup> PR snapd#8017 opened: tests: add ubuntu 20.04 to the tests execution and remove tumbleweed from unstable <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8017>
<ijohnson> cjp256: I'm not sure about 16.04, but I know on 18.04 if you don't have snaps, it will use the snapd snap when you first install a snap
<ijohnson> cjp256: if you wanted to get the latest on 16.04 I'd just say do `sudo snap refresh core`
<ijohnson> cjp256: though I did just check on 16.04 and it should be fine to install snapd like you have it
<cjp256> thanks ijohnson.  i did a similar test and was OK, but recalled a conversation between sergiusens and Chipaca about some flag I can't  recall, wanted to make sure it wasn't generally relevant :D
<cjp256> my test is on a fresh lxd image, so it's probably much newer base than theirs
<ijohnson> cjp256: as long as you are doing this fresh without any snaps installed it is okay to install snapd, otherwise you would need to migrate from core -> snapd which does require a flag
<ijohnson> err "okay to install the snapd snap" is what I meant
<cjp256> oh, what flag is that?
<ijohnson> let me find it, it's an experimental flag
<cjp256> ijohnson: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/build_providers/_snap.py#L332 ?
<ijohnson> cjp256: ah yep there it is
<cjp256> tried searching for it earlier and couldn't find it because I was checked out on an old tag ð¤¦
<ijohnson> that's the flag you need to use if you have the core snap installed, and want to use the snapd snap instead
<Chipaca> ijohnson: cjp256: snapcraft needs to work on the un-updated snapd that didn't know about the snapd snap
<cjp256> Chipaca: thanks! ijohnson gave me a lot of background info and I just confirmed running an old version of snapd (2.34.2): `error: cannot install "snapd": cannot install snapd snap on a model without a base snap yet`  so the two options they have are `apt update; apt install snapd` or `sudo snap install core` to get working.
<Chipaca> cjp256: that's why snapcraft sets an experimental flag
<Chipaca> cjp256: but even that needs a new enough snapd
<cjp256> if eventually installing core snap anyways, is the apt update/upgrade wasting cycles?
<Chipaca> cjp256: the experimental.snapd-snap=true
<Chipaca> cjp256: I can't answer that question with enough confidence one way or the other
<Chipaca> cjp256: it depends
<Chipaca> cjp256: an update would bring in apparmor updates also hopefully, which would be good
<Chipaca> but, given it's a throwaway, maybe it's fine as long as the snapd in the original deb understands that experimental flag
<Chipaca> because at one point it didn't
<cjp256> yeah no dice on that flag: `Run configure hook of "core" snap (run hook "configure": cannot set "core.experimental.snapd-snap": unsupported system option)`
<cjp256> not with their version anyhow
<Chipaca> so you had to install core first to get a new enough snapd to install snapd
<Chipaca> and that always results in the conflict
<Chipaca> (#1859469 is a conflict error)
<mup> Bug #1859469: snapcraft lxd + snapd transition in progress <Snapcraft:Confirmed for sergiusens> <https://launchpad.net/bugs/1859469>
<Chipaca> so, in that sense, if you use apt to refresh the packaged snapd, and that way get a new enough snapd that it doesn't need the flag (or at least understands the flag!), then it's slower but safe
<Chipaca> OTOH it's a conflict, all you have to do is retry
<cjp256> gotcha, thanks!  i'll just stick with the `apt` route and encourage them to update their image :D
<ijohnson> Thanks Chipaca
<Chipaca> at the same time, i need to discuss with pedronis about snap returning a particular return value on conflict
<Chipaca> cjp256: i thought running on that particular image was a requirement, as it's what you got from some clouds and we wanted snapcraft to work well there
<Chipaca> anyhoo, I shouldn't be on here :-)
<Chipaca> but it's raining so i didn't take the dog for a walk
<Chipaca> ð
<ijohnson> cjp256: so did you get it all sorted out?
<ijohnson> I'm still around for a bit if you need to discuss
#snappy 2020-01-17
<mup> PR snapcraft#2878 closed: extensions: fix merging of build-environment <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2878>
<zylop> everyday less channels interesting here
<zylop> after an uodate from 28.8bps modem to a 5Mbps fiber t1 Line
<zylop> its sad
<zylop> at least #snappy doesnt have trolls thank god
<zylop> well too late for chat today, maybe i'll create a project called aspies/will/be/ddosed
<zylop> ciao and thanks
<cjp256> ijohnson: yes, thanks! https://github.com/travis-ci/dpl/pull/1154
<mup> PR travis-ci/dpl#1154: Update snapd <Created by BanzaiMan> <https://github.com/travis-ci/dpl/pull/1154>
<mborzecki> morning
<zyga> almost te
<zyga> re
<zyga> outside is lovely today
<zyga> pstolowski: how does it look like outside for you?
<pstolowski> zyga: hey, chilly (-1C) but sunny
<mborzecki> zyga: pstolowski: -1 here too, mornig frost everwhere, yesteday evening was -3 and super foggy (no surprise though, +10 during the day)
<zyga> re
<zyga> -2 here when I woke up
<zyga> and fog thick like cream
<zyga> https://usercontent.irccloud-cdn.com/file/Phm3QnMj/image.png
<zyga> when I finally got out to take Bit for a walk it was clearing
<zyga> but still foggy
<zyga> last night I read a little about table layout problem
<zyga> and I decided not to  :)
<zyga> at least not during work hours
<zyga> it's a significant chunk of work
<zyga> today I'll start with selinux
<sdhd-sascha> good morning :)
<sdhd-sascha> what is table layout problem ?
<zyga> sdhd-sascha: you have a table comprised of cells
<pstolowski> zyga: what about selinux?
<zyga> sdhd-sascha: some cells may span several rows or columns
<zyga> sdhd-sascha: each cell has text inside
<zyga> sdhd-sascha: text can wrapped according to typical rules (e.g. break on spaces)
<zyga> sdhd-sascha: the problem is
<zyga> sdhd-sascha: given set width
<zyga> sdhd-sascha: compute the minimum height of the table
<zyga> sdhd-sascha: this is NP complete
<zyga> sdhd-sascha: then you have more constraints, e.g. to make text look good according to some optimization function
<zyga> sdhd-sascha: there are some heuristics to follow (that all the implementations use)
<sdhd-sascha> ah, ok, cool
<zyga> sdhd-sascha: there are perfect solutions using very expensive algorithms, mainly to measure the speed and quality of a given heuristic
<sdhd-sascha> sounds like perfect for functional programming and recursion
<zyga> sdhd-sascha: but they all involve heavy math and optimization problems
<zyga> sdhd-sascha: linear algebra, dynamic programming
<zyga> sdhd-sascha: not "I'll write this after reading a paper" in one evening
<zyga> sdhd-sascha: the problem of figuring out how to size a cell is called cell configuration
<zyga> sdhd-sascha: and each cell has a finite set of configurations
<zyga> sdhd-sascha: typically one is best but it's quadratic or O(N^2/3) at best with tricks  to find cell configuration that's good
<zyga> sdhd-sascha: that's per cell with N being word legth
<zyga> *count
<zyga> sdhd-sascha: anyway
<zyga> sdhd-sascha: it's fun but not for work
<sdhd-sascha> zyga: maybe, find the cell with the least possibilities. Then call the next, with least possibilities... Could be a starting point
<sdhd-sascha> zyga: yes, that's really fun :-) And true, it needs time
<zyga> This problem has been researched since 1960s
<zyga> There are lots of good algorithms but they are all complex to implement
<sdhd-sascha> 1960s - hmm, sounds like functional programming
<sdhd-sascha> it's sure a compination of bread first and deep first searches
<sdhd-sascha> combination - (sorry)
<zyga> https://people.eng.unimelb.edu.au/gkgange/pubs/table_11.pdf
<sdhd-sascha> and, sorry not "bread" - i mean breadth-first
<sdhd-sascha> cool - thank you :-)
<sdhd-sascha> zyga: hmm - because of the symlink not possible problem in snap. I will give the user at first a setup.sh script like alan it does.
<sdhd-sascha> Maybe i can set an alias after the first start from setup-script to real-app.
<zyga> we should discuss the problem
<zyga> and come up with a strategy to fix it
<zyga> pstolowski: I have a selinux denial to fix in my pR
<pstolowski> ic
<jamesh> zyga: while updating one of my PRs related to portal support, I noticed that a test I'd added was failing on Fedora 31 due to it using cgroups v2.  Is that something that is likely to be fixable?
<zyga> jamesh: can you be more specific please?
<zyga> jamesh: I have this for cgroupv2 https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> jamesh: but it needs another review
<zyga> it's open since november
<jamesh> zyga: it was code using this snapFromPid() code: https://github.com/snapcore/snapd/blob/master/usersession/userd/helpers.go#L76
<zyga> jamesh: ah, yes
<jamesh> which has a "if cgroup.IsUnified()" error case at the top
<zyga> jamesh: I need to look but I think can be fixed
<zyga> jamesh: we have some generic code in sandbox/cgroup
<zyga> jamesh: so I think the answer is "yes"
<zyga> jamesh: it literally needs reviews and nothing else I think
<jamesh> zyga: I'm mainly concerned because I'd like to reimplement a quick "is this a snap?" check for xdg-desktop-portal itself (to replace the one relying on AppArmor)
<zyga> yeah I remebmer that
<zyga> I think mvo is trying to get reviews to work better
<zyga> specifically security reviews
<jamesh> and if the freezer cgroup thing can't be relied on in the snapd code, then I probably shouldn't be writing more code that uses that method
<zyga> it cannot be relied on
<jamesh> I remember at one point you'd talked about having some kind of marker file in the snap's mount namespace
<zyga> jamesh: yes, we explored many ideas
<zyga> jamesh: right now I cannot promise you the inode idea gets implemented
<zyga> jamesh: but the cgroup idea is very close and seems to be entirely generic as well
<zyga> jamesh: and all you need is one read() call to see which snap a process belongs to
<jamesh> but it'd be a different check compared to what that function is currently doing?
<zyga> jamesh: yes
<zyga> jamesh: the PR I referenced changes most (need to see if it changes userd code, I wasn't aware it does this)
<jamesh> zyga: I was looking at moving that utility function out of userd, so it could be used by the "snap routine portal-info" command
<jamesh> but it is still essentially the same code
<zyga> yeah I think it should move to sandbox
<zyga> mainly because it's one implementation over many
<zyga> jamesh: FYI I will land https://github.com/snapcore/snapd/pull/7238
<mup> PR #7238: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Security-High> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7238>
<zyga> jamesh: as soon as it goes green
<zyga> jamesh: oh, and I have a question for you
<jamesh> zyga: thanks
<zyga> jamesh: is https://github.com/snapcore/snapd/pull/7589 ok?
<zyga> jamesh: Samuele asked you to changed the PR description
<mup> PR #7589: cmd/snap: add ability to register "snap routine" commands <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
<zyga> but I wasn't following the history and not sure if you did or not
<zyga> jamesh: can you comment  there please
<jamesh> zyga: yep.  The initial comment was edited as requested.
<zyga> excellent
<zyga> I'll merge it as well
<zyga> I'll just merge master into it to ensure it's green still
<jamesh> zyga: out of interest, where in the sandbox package do you think that snapFromPid() function would best belong?
<zyga> jamesh: sandbox/cgroup as it models the source of that information
<jamesh> okay.  I was just wondering since the API is not particularly cgroup specific
<jamesh> it currently uses cgroups, but that seems like an implementation detail
<zyga> jamesh: yeah but that's how the sandbox package is modeled now, if it changes we can just adjust the calling code; I think it's more important to have one implementation than an abstract entry point
<zyga> (we can have both eventually)
<jamesh> fair enough
<zyga> mborzecki: I cannot understand that selinux denial at all, looking at selinux policy now
<mborzecki> zyga: got the avc log?
<zyga> mborzecki: same as before but that's not the point
<zyga> mborzecki: the denial is new
<zyga> mborzecki: the denial comes from snap-discard-ns
<zyga> mborzecki: using setegid
<zyga> mborzecki: which it starts to in this PR
<zyga> mborzecki: the point is - how can this be denied when it runs as root and snap-confine can setegid all it wants
<zyga> and it calls setegid just prior to the fork/exec call
<zyga> mborzecki: I must be missing something :/
<mborzecki> zyga: can you paste that denial? con't find it in history
<zyga> sure, one sec
<mup> PR snapcraft#2882 closed: extensions: change extension merge-strategy to fix build-environment <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2882>
<zyga> type=AVC msg=audit(01/16/20 18:15:29.361:1557) : avc:  denied  { setgid } for  pid=13356 comm=snap-discard-ns capability=setgid  scontext=system_u:system_r:snappy_mount_t:s0 tcontext=system_u:system_r:snappy_mount_t:s0 tclass=capability permissive=1
 * Chipaca prepping for the trip
<pedronis> mborzecki: mvo: hi, #7992 needs 2nd reviews and some tweaks (see my own review comments)
<mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
<mborzecki> pedronis: i can take care of the tweaks
<pedronis> mborzecki: thx, please double check that my suggestions make sense
<mborzecki> pedronis: ok
<mup> PR snapcraft#2847 closed: Catkin plugin: consider only 'local' workspaces <Created by artivis> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2847>
<mborzecki> zyga: hm does s-d-n explicitly setgid?
<zyga> mborzecki: yes, but it runs as root at that time
<mborzecki> zyga: that's the point of selinux, even though it runs as root, the policy is in effect
<zyga> mborzecki: snap-confine doesn't run with egid=0
<zyga> so it switches to egid=0 and back all the time
<zyga> ?
<zyga> sure
<zyga> but
<pedronis> mvo: open PRs have grown quite a bit again :/
<zyga> why nothing for snap-confine
<zyga> is it a separate policy?
<mvo> pedronis: yeah, today is a busy day for me but I will try to do some more reviews
<mborzecki> zyga: s-c already has setgid
<zyga> ahhh
<mborzecki> zyga: so selinux policy can actually confine root ;)
<zyga> sure
<zyga> I assumed that snap-confine policy would apply to snap-update-ns invoked from snap-confine
<zyga> not that it would have a standalone policy
<pedronis> zyga: my first impulse feeling on #8008 is that is too big
<mup> PR #8008: render: add the render package and basic widgets <Created by zyga> <https://github.com/snapcore/snapd/pull/8008>
<mborzecki> zyga: no, s-u-n and s-d-n are run with snappy_mount_t context which has a separate policy
<Wouter0100> Hey guys! Is there any timeline/progress on RPi4 support for Ubuntu Core? :D Curious, as we don't want to be stuck on RPi3 if I start building using Core now
<mborzecki> zyga: i see there's an entry with `allow snappy_mount_t self:capability {..}`, add setgid there
<Chipaca> pedronis: looking at how o/auth handles user addition and removal, don't we need a graveyard for users?
<Chipaca> pedronis: if you don't know offhand i can dig myself :)
<zyga> mborzecki: I see snappy_mount_exec_t
<zyga> is that the type?
<pedronis> Chipaca: I'm not even sure I understand the question tbh
<zyga> mborzecki: I don't see where it gets any permissions yet
<Chipaca> pedronis: you know how we do refreshes bunched by user id
<mborzecki> zyga: nope, snappy_mount_t, around like 426 in snappy.te
<pedronis> Chipaca: yes
<Chipaca> pedronis: when a user logs out, we delete the user completely
<Chipaca> pedronis: if they then log back in they get a new id
<zyga> mborzecki: how is snappy_mount_t related to snap-discard-ns?
<mborzecki> zyga: https://paste.ubuntu.com/p/P4q7VYpMh7/
<Chipaca> unless i'm missing something, that means the refreshes will be wrong?
<Chipaca> as in, they'll be done as root from there on
<pedronis> Chipaca: aren't the ids always growing
<Chipaca> pedronis: yes
<pedronis> we don't recycle ids, or do we
<Chipaca> pedronis: no we don't
<pedronis> Chipaca: well, the refreshes will already be not working once they log otu
<Chipaca> pedronis: but shouldn't they work again once they log back in
<zyga> mborzecki: but how is that related?
<zyga> *related
<pedronis> Chipaca: maybe yes
<Chipaca> pedronis: i know this sounds related to my current work but it's actually because i resucitated an old laptop and the macaroon had expired so i logged out and back in and that got me thinking
<mborzecki> zyga: both do stuff with mounts, so instead of making it even more fine grained both get the snappy_mount_t policy
<pedronis> Chipaca: you basically are saying that we should reuse the id if matching email
<pedronis> or something
<zyga> I mean how is snap-discard-ns associated with snappy_mount_t
<Chipaca> pedronis: meaning we should keep a graveyard of sorts to remember those things
<mborzecki> zyga: how does selinux figure that out?
<pedronis> Chipaca: what happens if you don't logout but login again?
<zyga> my point is that I cannot trace anything from snap-discard-ns
<pedronis> do we error?
<zyga> to that place where you say to patch things
<pedronis> or do something else?
<pedronis> or it's a nop
<pedronis> (I don't remember myself)
<mborzecki> zyga: quick HO?
<zyga> mborzecki: how are those entries connected
<zyga> mborzecki: sure
<Chipaca> pedronis: looks like you get new macaroni
<Chipaca> pedronis: it works
<Chipaca> pedronis: (so yes i should've done that)
<pedronis> Chipaca: ok, so we have an issue but is not as bad as it could be
<Chipaca> pedronis: yep
<Chipaca> well, the error could be better
<Chipaca> you just get an opaque 'invalid credentials'
<Chipaca> but not clear we can improve on that easily
<pedronis> Chipaca: we need to think a bit, can you create a bug or something
<pedronis> to remember this
<Chipaca> yes
<pedronis> thx
<Chipaca> pedronis: https://bugs.launchpad.net/snapd/+bug/1860102
<mup> Bug #1860102: snap logout and snap login with same account creates new user <snapd:New> <https://launchpad.net/bugs/1860102>
<pedronis> Chipaca: thanks, tracking as mine for now
<Chipaca> pedronis: ð
 * Chipaca goes back to laptop resuscitation
<mup> PR snapd#7238 closed: usersession: add systemd user instance service control to user session agent <Needs Samuele review> <Security-High> <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7238>
<pedronis> jamesh: hi, could you add the comment jdstrand asked for in #7555, then it could be merged
<mup> PR #7555: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7555>
<zyga> good luck Chipaca
<mborzecki> https://github.com/snapcore/snapd/pull/8013 needs 2nd review
<mup> PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
 * zyga looks
<zyga> mborzecki: is https://github.com/snapcore/snapd/pull/8013/files#diff-01caa2f676929e8131f31685ae61203cR216 a separate error that is fixed in this branch?
<mup> PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
<mborzecki> zyga: yes, separate patch in that branch
<zyga> mborzecki: I have a small comment on the size code
<mup> PR snapd#7366 closed: interfaces/gpg-keys: Allow access to gpg-agent and creation of lockfiles <Created by ppd1990> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7366>
<mup> PR snapcraft#2883 opened: docker: add core18 snap that snapcraft now uses as a base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2883>
<sdhd-sascha> Can i anything do, for #7927 ? I still need a patched `snapd` to start sway on classic ubuntu.
<mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
<pedronis> sdhd-sascha: is not green atm, and needs a jdstrand review (he is off this week)
<sdhd-sascha> pedronis: ok, i rebase it to current master
<zyga> mborzecki: I opened https://github.com/snapcore/snapd/pull/7980 for review now - the SELinux denial is gone
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
 * Chipaca brb
<mup> PR snapd#8017 closed: tests: add ubuntu 20.04 to the tests execution and remove tumbleweed from unstable <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8017>
<sdhd-sascha> Hi, as you know, i never worked with golang before. Is there a way to reset the source to a clean working state ? I deleted snapd/cmd/VERSION. And it's in `.gitignore`. So i wonder, how to reset without `go get ...`
<mup> PR snapd#8012 closed: o/devicestate: do not create perfTimings if not needed inside ensureSeed/Operational <Simple ð> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8012>
<pstolowski> sdhd-sascha: reset the git working dir of a project? 'git clean -xfd', beware it will forcefully remove any uncommited stuff in the working tree without asking
<mup> PR snapd#8006 closed: tests: skip interfaces-network-manager on arm devices <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8006>
<sdhd-sascha> pstolowski: thank you. I found mkversion.sh. But it's confusing if you change the branch and then the version remains nearly the same.
<sdhd-sascha> I build 2.43 and wonder, why it still reports 2.42 ...
<zyga> mborzecki: :) https://github.com/snapcore/snapd/pull/8016
<mup> PR #8016: gitignore: ignore snap files <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8016>
<mup> PR snapd#8016 closed: gitignore: ignore snap files <Simple ð> <Created by anonymouse64> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8016>
<zyga> pedronis__: does your blocked label mean that no progress can be done on the render branch for the next week?
 * zyga jumps into https://github.com/snapcore/snapd/pull/7614
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<sdhd-sascha> Hey, i read a lot of MAAS snap here. Is it in the store ? Or did i need to build it myself?
<Chipaca> sdhd-sascha: I think it's unlisted until default tracks work, as upgrades from latest to 2.7 are painful
<Chipaca> sdhd-sascha: but if you find sparkiegeek they might know more
<Chipaca> (default tracks should be working on edge! woop woop)
<sdhd-sascha> Chipaca: thank you. I'm already on 2.7 on local installation and want to migrate to snap.
<Chipaca> sdhd-sascha: note the versions in 'snap info maas'
<sdhd-sascha> hmm, i found it. thank you :)
<sdhd-sascha> Chipaca: did you know if there is a maas-rack and/or maas-region snap ? Or is it all-in-one ? If you didn't know. Then i will figure it out. No stress ;-)
<Chipaca> sdhd-sascha: I don't know either :) I know next to nothing about maas in fact
<sdhd-sascha> Chipaca: I am also at the experimental level. would like to use maas with lxd and juju.
<Chipaca> sdhd-sascha: #maas, maybe? (dunno)
<pedronis> Chipaca: I think #7589 could land once green, can you quickly double check it again
<mup> PR #7589: cmd/snap: add ability to register "snap routine" commands <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7589>
 * zyga looks at another PR
<mup> PR snapd#7623 closed: tests: check world-writable and test-owned files <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7623>
<cachio> mborzecki, hello
<cachio> I am reviewing a failing test
<cachio> selinux-clear which is failing on centos
<cachio> mborzecki, this is the error https://paste.ubuntu.com/p/5DxBHnD93d/
<cachio> seems to be real
<mborzecki> cachio: hah, yeah, known problem, i'll update the policy, keeping centos in unstable systems doesn't help with catching issues like this one early
<cachio> mborzecki, nice, thanks for the confirmation
<pstolowski> cachio: updated #7871, thanks for pointing out pkgdb
<mup> PR #7871: tests: add spread test for hook permissions <Created by stolowski> <https://github.com/snapcore/snapd/pull/7871>
<cachio> pstolowski, yaw
<mup> PR snapd#7875 closed: interfaces: refactor path() from raw-volume into utils with comments for old <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7875>
<pedronis> mborzecki: am I misreading or #7845 should be closed ?
<mup> PR #7845: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Simple ð> <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7845>
<mborzecki> pedronis: IMO yes, the problem should be addressed in systemd (if ever)
<pedronis> ok
<mup> PR snapd#7845 closed: cmd: add prefix to SYSTEMD_SYSTEM_GENERATOR_DIR <Created by sd-hd> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7845>
<mborzecki> added a note to 7845 with some suggestions on hot to approach this sdhd-sascha, it'd be nice to hear what upstream systemd suggest to use there
 * sdhd-sascha I'm back later. And look
<Chipaca> pedronis: agreed, 7589 can land once green
<pstolowski> pedronis: can we land #7934, and potentially address ijohnson's suggestion re test refactor in a followup?
<mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<pedronis> pstolowski: yes, I suspect it would be good to fix the misleading comment though
<pedronis> pstolowski: I'm taking care of that
<pstolowski> pedronis: ty
<pedronis> pstolowski: done, let's see if it gets green again
<Chipaca> pedronis: btw, did you see https://forum.snapcraft.io/t/snapctl-changing-channel-ability/14900?u=chipaca ?
<pedronis> Chipaca: yes, I don't think is something we want to let snap do
<pedronis> in general
<Chipaca> pedronis: right, not like that, but then they ask for more nuanced things in https://forum.snapcraft.io/t/snapctl-changing-channel-ability/14900/3?u=chipaca
<Chipaca> some of them we already wanted (were already implementing?)
<Chipaca> i mean, the 'are there updates in the current channel' one i thought was roadmapped even
<pedronis> yes
<pedronis> even refresh it's probably doable with some user confirmation
<Chipaca> pedronis: 'reading current channel' seems a'ight, also
<pedronis> changing channel likely not
<zyga> brb
<Chipaca> agreed, not without some way of asking the user
<mborzecki> https://github.com/snapcore/snapd/pull/8005 needs a 2nd review
<mup> PR #8005: api: don't return connections referring to non-existing plugs/slots <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8005>
<zyga> looking
<pedronis> Chipaca: answered or tried to
<Chipaca> pedronis: some from â some form
<Chipaca> :)
<pedronis> Chipaca: yea, fixed
<pedronis> already
<Chipaca> pedronis: having to check version info to know channel breaks QAing a snap along channels though
<pedronis> Chipaca: I don't know, there is a list of features there, not use cases
<Chipaca> pedronis: I've been tempted to make snapd always log verbosely when in edge or beta, for example
<pedronis> I would like to understand the use case more
<Chipaca> pedronis: yep yep
<zyga> hmm
<zyga> pstolowski: do you remember the discussions from Malta about how we want to show connections
<pedronis> Chipaca: is it realy about risks or is it about tracks?
<pedronis> etc
<zyga> pstolowski: when the thing is not present (e.g. dead hotplug connection)
<Chipaca> pedronis: k
 * zyga wonders where the notes from Malta might be
<zyga> I recall gustavo recorded those in a web tool of some sort
 * zyga looks
<pedronis> afaik the agreement was then copied into: https://forum.snapcraft.io/t/snap-connections-command/4296/20
<pedronis> and is what was implemented
<mborzecki> hmm something still not right in 7992
<pstolowski> zyga: i remember the topic and the general idea, but not details, i don't think we had a concrete plan
<zyga> pstolowski: I'm looking into this
<pstolowski> zyga: is this wrt my PR?
<zyga> yep
<zyga> give me a moment to go through what we planned to do
<pstolowski> zyga: my PR is not closing any doors, but atm user experience is confusing. i made a comment in the code about what needs tweaking when we have an egreement
<ijohnson> morning folks
<pstolowski> ijohnson: hi!
<ijohnson> thanks mborzecki and pedronis for the reviews/commits to the kernel things
<ijohnson> hi pstolowski
<mborzecki> ijohnson: hi, i'll push one more patch if you don't mind
<ijohnson> mborzecki: go for it
<mborzecki> ijohnson: ok, pushed now ;)
<ijohnson> thanks!
<zyga> pstolowski: reviewed
<zyga> https://github.com/snapcore/snapd/pull/8005#pullrequestreview-344593087
<zyga> oh
<zyga> standup
<mup> PR #8005: api: don't return connections referring to non-existing plugs/slots <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8005>
<pstolowski> zyga: ty!
<mup> PR snapd#8005 closed: api: don't return connections referring to non-existing plugs/slots <Bug> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8005>
<cjp256> zyga: sergiusens suggested you might know... when I have a slot defined `slot: mpris: {interface: mpris, name: foo}` , review-tools fails with `"human review required due to 'deny-connection' constraint (interface attributes)"`
<cjp256> review-tools specifically has a test case for this: https://git.launchpad.net/review-tools/tree/reviewtools/tests/test_sr_declaration.py#n5195
<cjp256> but for some reason, if we drop the optional "interface" key, it passes: `slot: mpris: { name: foo }`
<zyga> cjp256: I don't know the review tools code, I cannot explain why without jumping into it from scratch
<zyga> brb, need to check up on kids
<pedronis> ijohnson: if you are happy with the changes 7992 can land once it is green again
 * Chipaca goes to have his head seen to
 * Chipaca notes it's for a haircut
<ijohnson> pedronis: ack I will try to get it in and rebase the other one for shorter diff
<mup> PR snapd#7555 closed: tests: add a test demonstrating that snaps can't access the session agent socket <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7555>
 * cachio lunch
<mup> PR snapd#7589 closed: cmd/snap: add ability to register "snap routine" commands <Created by jhenstridge> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7589>
<pedronis> mborzecki: does #8013 need a review from cmatsuoka ?
<mup> PR #8013: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8013>
<zyga> re
<ijohnson> pedronis: shall I merge #7934 if it goes green today in my PM?
<mup> PR #7934: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<pedronis> ijohnson: if it's green, yes, I made a note to myself about the test refactor
<ijohnson> pedronis: ack
<ijohnson> pedronis: mborzecki: reviewing the patches to 7992, I notice that now DisableTryKernel returns nil if the symlink is _missing_, I thought that we wanted it to return an error if the symlink is missing, but if it's a dangling symlink we don't return error
<ijohnson> pedronis: mborzecki: the use case I was thinking of for that is that if we have a poorgramming error where we try to disable a try kernel when there isn't even a try-kernel.efi we still want to error
<ijohnson> specifically https://github.com/snapcore/snapd/pull/7992/commits/ac52ca80c27aa3a796177628701b07c95e01ab28#diff-637bfac32ed88896fef8c212d836bf11L217-R217
<mup> PR #7992: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
<mup> PR snapd#8013 closed: cmd/snap-bootstrap: check device size before boostrapping and produce a meaningful error <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8013>
<mup> PR snapd#7871 closed: tests: add spread test for hook permissions <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/7871>
<pstolowski> huh, finally, it took ages
<cjp256> zyga: just out of curiousity, would you expect behavior changes if "interface" is defined?  The docs say it's optional if the plug/slot name matches the interface?
<mup> PR snapd#8018 opened: spread.yaml: fix ubuntu 19.10 and 20.04 names <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8018>
<zyga> cjp256: snapd doesn't consider it any different, both result in identical slot
<zyga> cjp256: it feels like bug in the review tools to me
<cjp256> zyga: ok thanks, that's what I figured.  :) have a good weekend!
<zyga> thank you :)
<mup> PR snapd#7992 closed: bootloader: add ExtractedRunKernelImageBootloader interface, implement in grub <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7992>
<pedronis> ijohnson: in general given our use case we don't want to fail even if we get something wrong, we should fail if a kernel that we want to enable is not there, but if a symlink is not there that we are about too remove, well too bad
<ijohnson> pedronis: hmm ok
<pedronis> ijohnson: robustness and correctness is not always the same thing
<ijohnson> pedronis: I guess I was looking at it from the standpoint of having more certainy about what happened
<ijohnson> pedronis: less of a correctness thing and more of a logging thing, i.e. the fact that the symlink wasn't there when we delete it might be masking some other error that happened before
<pedronis> ijohnson: I understand but we don't devices stuck unless there is a strong argument why we can't move forward
<ijohnson> pedronis: sure I guess in that instance it would be a higher level thing and that the caller of DisableTryKernel would see "hey this symlink wasn't there" and still move on, but maybe could log a message
<ijohnson> (IMHO)
<pedronis> ijohnson: I see but it gets too subtle, locally it seems a reasonable enough call
<pedronis> also people don't look at logs of things at appear to work
<pedronis> s/at/that/
<ijohnson> pedronis: well I'll defer to your judgment about the design of this, but I do disagree that folks don't look at logs when things are working, I think looking at logs is often times a measurement of whether things are working, i.e. when you have a thousand devices you don't want to only monitor the ones that failed
<pedronis> ijohnson: being demanding of what we expect our code to do is a task for our tests, avoiding uncessary failure is something we do want at runtime
<pedronis> because the cost of failure is possibly very high
<ijohnson> pedronis: sure
<ijohnson> I agree with that
<pedronis> ijohnson: anyway we you think we should log that condintion then bootloader itself should do that
<pedronis> there's no point making it the task of one level up
<ijohnson> pedronis: that's fair I might do that then
<mup> PR snapd#7934 closed: o/ifacestate,o/devicestatate: merge gadget-connect logic into auto-connect <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7934>
<mup> PR snapcraft#2884 opened: plugs/slots: match output format read in snapcraft.yaml <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2884>
 * cachio afk
<mup> PR snapd#8019 opened: [RFC] interfaces/apparmor: don't omit deny rules in devmode confinement <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8019>
<mup> PR snapd#8020 opened: interfaces/apparmor: fix doc-comments, unnecessary code <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8020>
#snappy 2020-01-18
<sdhd-sascha> Is there a way, that a host-package must be installed before a snap can be installed ? Or something ? I have to ensure that XDG_RUNTIME_DIR is set ? Or could i use the user-id in then environment ?
<diddledan> sdhd-sascha, a snap should ship everything it needs within itself - you cannot install or require installation of any packages in the host
<sdhd-sascha> diddledan: sure. Was a weird question from me ;-)
<diddledan> :-)
<mup> PR snapcraft#2884 closed: plugs/slots: match output format read in snapcraft.yaml <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2884>
<mup> PR snapcraft#2883 closed: docker: add core18 snap that snapcraft now uses as a base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2883>
<mup> PR snapcraft#2885 opened: lifecycle: only warn when a default provider snap is missing <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2885>
<sdhd-sascha> whom, should i write - we have a new patch for systemd.pc ( systemd/systemd#14600 )
<mup> PR systemd/systemd#14600: pkgconf: add full generator paths <Created by sd-hd> <Merged by keszybz> <https://github.com/systemd/systemd/pull/14600>
 * sdhd-sascha i'm happy, because still new to contributing public...  (hope, i can help in future, too )
<sdhd-sascha> Is the next step launchpad or debian ?
<sdhd-sascha> Or handle ubuntu-core with `snaps` for the current time, itself ? ...
#snappy 2020-01-19
<mup> PR snapcraft#2851 closed: docker: test image builds with Travis CI <Created by abitrolly> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2851>
