#snappy 2015-09-21
<fgimenez> good morning
<davidcalle> Morning o/
<JamesTait> Good morning all; happy Monday, and happy Miniature Golf Day! ð
 * ogra_ puts
<sergiusens> Chipaca, around for a review?
<biezpal> Hello all. We've updated our Snappy Ubuntu to the latest stable and now our package version after installation is some random string (like IBQKIEHAHMYG) instead of 0.0.1 for example. Is it a new feature or bug? Where we can read about it?
<sergiusens> biezpal, it is a feature; for sideloaded apps; in order to have an upgrade path when iterating during development
<biezpal> sergiusens, how can we access data at this location without specifying version?
<sergiusens> biezpal, using SNAP_APP_DATA_PATH and other env vars
<sergiusens> biezpal, if you are not familiar with the env vars, maybe install hello-world and run hello-world.env
<biezpal> sergiusens, and what if we have build-in paths in executables?
<biezpal> some external soft which we cannot rewrite
<biezpal> lxc for example
<asac> biezpal: do you build lxc on your own? Otherwise I cannot see how it could work with anyway.
<biezpal> asac, yes, we are rebuilding lxc
<biezpal> we are using lxc as a virtualization provider in our own project
<ogra_> mvo, sergiusens, any idea how we can tackle bug 1497582 ? looks tricky given dget is involved
<ubottu> bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,New] https://launchpad.net/bugs/1497582
<ogra_> (kind of blocked me to pacckage up my IMAP server snap on the weekend
<ogra_> )
<sergiusens> ogra_, oh, I need to massage an MP form mvo
<sergiusens> ogra_, and we aren't using dget anymore
<ogra_> ah, we have a fix ?
<ogra_> neato :)
<sergiusens> ogra_, we are using python3-apt
<ogra_> cool, yeah, that should resolve the dep
<sergiusens> ogra_, yeah, I need to tinker it a bit since it has been targetting one of tedg's internal branches
<sergiusens> ogra_, I'll wait for tedg to see if he started or not to work on this; if not I'll get to it :-)
<ogra_> yeah, if sometihing is in the pipe i'm happy
<ogra_> after doing the irceproxy yesterday and ll the wrangling with the config stuff i guess the mailserver will rather be a multi day effort anyway
<ogra_> *all
<biezpal> asac, https://github.com/lxc/lxd-pkg-ubuntu/blob/snappy/build
<biezpal> we are using versioning in the similar way as in the lxd, but now it's impossible
<ogra_> longsleep, congrats to the release !
<asac> stgraber: heya see biezpal challenge above with lxc/lxd and requiring known, fixed path during package-as-snap time... anyway to make this relocatable?
<mvo> sergiusens: I thought this was part of ted MP? I can create a fresh MP and fix the outstanding issues, sorry, was not aware that the ball was in my court :)
<sergiusens> mvo, it is, but I want to streamline it into trunk directly as that MP might take a bit :-)
<asac> biezpal: so the problem really is that we plan to not enforce that you put a unique version into the version: field... but we will rather assign versions during upload. this means we will somehow also allow that two snaps with same version can be installed on same disk, which makes it impossible to use that version
<ogra_> i was surprised to see the virtual dep ... i thought the debian policy forbids such deps
<ogra_> but looking deeper it seems it is wildely used in perl packages
<sergiusens> ogra_, might be a dep for something that was removed from the archive?
<sergiusens> ah, perl; always doing dirty things ;-)
<ogra_> no, perl-base provides the virtual api package dep
<ogra_> and packages using perl base seem to all depend on it
<biezpal> asac, why don't you create "current" link as in the /apps directory?
<ogra_> how would that help with non-modifyable paths ?
<ogra_> (upstream paths i mean)
<asac> biezpal: we currently dont create current link for the sideloaded app?
<ogra_> asac, we dont create it for any *_DATA_* dirs
<ogra_> only for the package dir itself
<asac> ogra_: why is that?
<ogra_> no idea :)
<asac> feels like a bug to me
<ogra_> i know we used to have that link in the beginning
<biezpal> ogra_, if there will be "current" link we'd use it to access data
<ogra_> and for some reason it was decided to not have it anymore
<asac> i could see that apps shouldnt accidentially write in the wrong data dir, but confinement would protect us from that risk, no?
<ogra_> biezpal, well, use the env vars for that
<sergiusens> asac, ogra_ current link for data breaks security
<mvo> sergiusens: makes sense, I will get to it after lunch
<ogra_> ah, that was it
<asac> ogra_: well, lots of software has build time arguments like https://github.com/lxc/lxd-pkg-ubuntu/blob/snappy/build
<asac> think the less we ask folks to patch code the better :)
<asac> mvo: thoughts on current link for data?
<ogra_> asac, right, so we need to find a fix for that ... but seems "current" isnt the right solution
<asac> ogra_: why?
<ogra_> see what sergiusens said
<asac> sergiusens: that feels odd
<asac> jdstrand: tyhicks: how does current link for data break security? doesnt apparmor look at realpath to enforce confinement?
<asac> sergiusens: are you sure? when did we talk about this?
<sergiusens> mvo, maybe review my code instead and I can rebase ;-)
<ogra_> asac, it was removed after IOM iirc
<mvo> sergiusens: already done
<sergiusens> mvo, oh goodie, thanks
<asac> mvo: do you remember the current link discussion for data?
 * sergiusens gets started with breakfast
<ogra_> oh, thats a good idea
<sergiusens> asac, I am not sure; but we also wanted all symlinks killed
<asac> i really dont buy this... if a link allows to fake a path within a subtree, then folks can create links in their data directory to whatever place they want to hack on
<asac> unless we dont allow creation of symlinks at all ... which would surely be a big problem :)
<asac> guess lets wait for security friends to wake up
<mvo> asac: not much of it unfortunately, I will read backlog after lunch.
<biezpal> thanks for response, waiting for security friends :)
<soffokl> btw, apparmor confined path like "/var/lib/apps/foo/*/run/state r," anyway
<soffokl> s/confined/confine
<longsleep> ogra_: thanks ! Now that i have a release with firmware, i encountered several wifi related systemd services failing. I was planning to add a bug for each of them - do you think that makes sense?
<ogra_> yeah
<longsleep> i think wifi was not much tested with snappy yet. It works fine though, just scary error messages on boot.
<ogra_> yeah, we need to fix that
<jdstrand> asac: apparmor will resolve symlinks so /var/lib/apps/foo/current -> /var/lib/apps/foo/1.0, an app using current would evaluate to /var/lib/apps/foo/1.0 when rules are applied
<jdstrand> we use current for install directory, we should be able to use it for data dir
<ogra_> jdstrand, why did we remove it then ?
<jdstrand> I have no idea. I have always wondered why it wasn't there
<ogra_> well, all i remember is that it was removed after some discussion at the IOM sprint
<ogra_> we used to have it in the beginning
<jdstrand> I think it should be carefully tested, because the data dir has a bind mount for /tmp, but otoh I can't think of a reason why it wouldn't work
<ogra_> probably due to overlayfs plans ?
<jdstrand> istr (vaguely) it having to do with rollbacks
<jdstrand> like, something about it being confusing
<jdstrand> any decisions for current and security based on overlayfs would have been premature
<jdstrand> since overlayfs isn't ready to be used in this context
<asac> jdstrand: how is progress on that?
<jdstrand> (doesn't play well with LSMs in general)
<asac> thats really the golden bullet for everything
<jdstrand> asac: it is deprioritized
<asac> by whom?
<asac> upstream?
<jdstrand> it is our of our control
<asac> can we take control through investment?
<ogra_> by kernel versions :)
<jdstrand> idk
<jdstrand> we'd need a kernel developer to engage with them on the problems they have with LSMs
<jdstrand> we looked at it quite a bit, and we can pick it up again, but not while we have to focus on stacked namespacing (lxd)
<jdstrand> (which is why it is deprioritized on our board)
<jdstrand> to be clear, we plan to pick it up again, but not particularly soon
<jdstrand> I don't think investment is an option now that I think about it
<ogra_> well and if we hard-depend on it it will massively reduce the ability to use BSP kernels
<jdstrand> the principle author is a redhat employee and in tight control
<jdstrand> perhaps tyhicks has more background information
<dholbach> mvo, can you take a look at https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801?
<jdstrand> asac: reading our trello card, it is high priority but below namespace stacking. however, tyhicks said he might be able to reengage with upstream this month (september). based on sprint timing and identity (which is taking longer than expected), this is more likely next month
<jdstrand> asac: so, I slightly misremembered (sorry). it is deprioritized for one engineer, reassigned to another where it is only slightly deprioritized
<jdstrand> but, we still don't have control of upstream-- we'll be interacting with them and talking about what apparmor needs
<jdstrand> I don't know how overlayfs solves 'current' though
<asac> jdstrand: i thought there is no problem with current
<asac> or is there?
<jdstrand> I don't think there is. I'm just wondering how we got to overlayfs (golden bullet comment) after talking about current
<ogra_> well, it would be good to do some forensics why current was removed in the first place
<jdstrand> unrelated question-- are we copying the data dir for apps on app upgrades or do apps have to do it themselves?
<ogra_> i thinkwe do
<ogra_> at least it happens for me
<ogra_> (i.e. configs under /var/lib/apps move forward)
<sergiusens> mvo, I grabbed the work for apt and fixing, we indeed need manifest.txt in there or the downloaded package list is a bit to long
<mvo> sergiusens: oh, ok. I had hoped that we can get away with the priority
<mvo> sergiusens: if we need it, just revet the change that removes it
<mvo> sergiusens: or let me fix it, as you want
<sergiusens> mvo, I'll push a branch to ~snappy-dev if I can't around it
<sergiusens> mvo, building the examples is getting tricky with this pacakge set brought in
<mvo> sergiusens: push it now, I will pick it up
 * Chipaca waves hello from a train
<sergiusens> mvo, lp:~snappy-dev/snapcraft/more-apt
<mvo> sergiusens: ta
<mvo> sergiusens: how nice do you want this to be? we could (trivially) use geoip to select the country mirror for example
<mvo> sergiusens: looks very nice otherwise
<sergiusens> mvo, if it is not too much work, would be good :-) but then again, I'm not sure how to solve a broken archive issue, so maybe more into the future?
<ogra_> just enfoce usage of a stable archive ;)
<ogra_> LTS only or some such
<sergiusens> mvo, if only that branch worked, the examples (webcam-webdm) fails terribly; python3 goes on a CPU roll doing 'writing dependency_links to config.egg-info/dependency_links.txt'
<mvo> sergiusens: oh? give me a minute to check. releated to the python-apt changes you think?
<sergiusens> mvo, yeah, I can roll back to triple check
<sergiusens> but I'm pretty sure I built all the examples before this change
<mvo> sergiusens: at what point does it explode for you? I am just running it now and its downloading stuff
<sergiusens> mvo, on python3 setup.py install for the config part
<mvo> sergiusens: not sure whats going on, but webcam-webui_1_amd64_.snap was created succesfully for me
<sergiusens> mvo, oh, heh; I just cleaned up the python build stuff and trying again (remove 'build', 'dist' and egg stuff)
<ogra_> mvo, hmm, we didnt have dailies since friday on 15.04 edge
<sergiusens> mvo, if it works I'll propose the MP; and I was thinking of using trusy instead of vivid but not sure that would break anything, in any case, starting 16.04 we should stick to that
<ogra_> mvo, oh, i guess we trashed cdimage, seems one of us didnt put the proper linking in place when renaming the dirs
<sergiusens> mvo, it gets stuck on writing manifest file 'config.egg-info/SOURCES.txt', very cpu intensive
<mvo> sergiusens: if you don't mind I will commit geoip support
<mvo> ogra_: meh, that was probably me, sorry for that. are you fixing it or shall I do that?
<ogra_> well, still trying to find out why i only got one single failure mail
<ogra_> it should still have attempted a build every day since friday, but it didnt
<mvo> ogra_: ok, just let me know when I shall look at anything (don't want to duplicate effort)
<mvo> sergiusens: commited as r187, just uncommit if you think its not a good fit
<sergiusens> mvo, no worries; I'm still battling with this python issue
<tedg> Could we just check if the base system has a mirror set?
<tedg> grep /etc/apt/sources.list
<ogra_> hmm
<ogra_> is snapcraft shell supposed to work ?
<ogra_> (and if so, how ? since the staging area doesnt actually have a full chroot)
<ogra_> seems it installed a lot of crap into my host when i ran apt-get install under it
<ogra_> not really what i would expect when reading the help
<tedg> I'd guess it just sets up the env and cwd
<ogra_> well, it doesnt really "enter" the env though
<ogra_> apt-get install foobar after snapcraft shell will just happily install foobar on your host
<tedg> Hmm, yeah. I don't think we'll ever change that.
<ogra_> running snapcraft shell changes my prompt to green, thats the only difference i see :)
<tedg> We'd have to set up a lot more complex setup to get that to work.
<ogra_> well, then we should hit that in the help or some such
<tedg> We're running apt in custom setup, not changing the environment.
<ogra_> *hint
<tedg> Yeah
<ogra_> i can imagine a lot of people trashing their host with that
<ogra_> help cureently says: "shell               enter staging environment"
<ogra_> which makews me think of a protected chroot or container or some such
<sergiusens> ogra_, we can do like we do on the device ;-)
<sergiusens> mvo, btw, I reverted all changes, to trunk and it works fine now
<ogra_> "like we do on the device" ?
<sergiusens> mvo, I'm going mad as the package list is the same :-P
<mvo> sergiusens: hmmm
<dholbach> asac, I was wondering if we should set up milestones in LP for snapcraft and start targeting bugs, so it'll be easier to figure out what's planned next...
<sergiusens> dholbach, replicate trello then?
<dholbach> sergiusens, are the most important snapcraft bugs in trello?
<sergiusens> dholbach, yes
<ogra_> there are no bugs in snapcraft, just hidden features :)
<sergiusens> dholbach, I don't mind using lp, but it would be a pain to track in two locations
<sergiusens> ogra_, it is still unreleased ;-)
<dholbach> we are already tracking things in two locations
<ogra_> sergiusens, details :P
<dholbach> but sure, I'm happy to use whatever is more convenient
<tedg> sergiusens: Are you pulling the sources list specifying stuff into your branch? I had splitting that out on my todo.
<sergiusens> dholbach, I'll bring it up during standup
<sergiusens> tedg, yes, here lp:~snappy-dev/snapcraft/more-apt
<sergiusens> tedg, team effort now ;-)
<tedg> sergiusens: Heh, okay, I'll base off that branch.
<dholbach> sergiusens, so you'd recommend to just look at the "Development Experience" list in Trello to see what's planned in the next days/weeks?
<sergiusens> tedg, and mvo added geoip; I still have issues here with the branch building the examples though
<sergiusens> dholbach, yeah
<dholbach> ok
<tedg> sergiusens: I tried to throw a snapcraft at maas and it needs that branch.
<sergiusens> dholbach, if someone can, I'd integrate bug linking in trello somehow and moving columns change the status in lp ;-)
<dholbach> mh
<tyhicks> jdstrand, asac: I have no new information regarding better LSM support in overlayfs
<tyhicks> jdstrand, asac: I haven't had a chance to keep up with the linux-security-module mailing list over the last few weeks so I'll skim it some time this week to see if there is anything new there
<tedg> sergiusens: Why not have default sources be the one on the system?
<tedg> sergiusens: It seems like that'd match what people are used to the best.
<sergiusens> tedg, consistent base for the snap
<tedg> sergiusens: Like if you're confused on a dep you'd do "apt-cache depends foo" to figure it out.
<tedg> sergiusens: I think that we should allow people to set that, but we shouldn't choose it.
<sergiusens> tedg, not even depending on the target snappy release?
<tedg> sergiusens: No, I think that local machine makes sense. It's "my dev machine" â otherwise we're starting to do magic.
<sergiusens> tedg, we already are ;-)
<sergiusens> tedg, and then how do we solve jdstrand's bug in an easy transparent way?
<tedg> I mean, I understand from the reproducable build perspective. But I think that it seperates the developer from what she is building.
<ogra_> what i as developer want is to maintain my snapcraft dir in a branch and if the distro releases a security update to the package i user i just want to go into the branch and caall snapcraft again to get the update binary
<tedg> sergiusens: I think that it's pretty unlikely that people will have a deb installed on their system that they can't get...
<ogra_> thats my main purpose for using debs actually ... someone else does the maintenance of the binary for me
<tedg> ogra_: Sure, the question is whether we choose one release for everyone to be based on.
<ogra_> i would say LTS by default with the ability to override
<tedg> ogra_: And sergiusens says 15.04 because that is the snappy we're releasing right now.
<tedg> Fight!
<tedg> ;-)
<ogra_> if i'm after the stability and foreign maintenance above then non LTS doesnt make much sense for me
<sergiusens> tedg, but you missed the part of my comment that once 16.04 is released; that should be the base
<ogra_> if i'm after the latest and greatest it would be nice to have a --devel-distro switch
<sergiusens> ogra_, tedg snapcraft.yaml is supposed to have a target field which says which release to build for
<ogra_> buit effectively ... if you are after latest and greatest you should probably compile upstreams trunk
<tedg> I think that we should be able to switch, but the default should be your current system.
<tedg> It makes it easier to debug build failures.
<sergiusens> mvo, so so, it works now; I wiped the branch and started from a clean checkout (maybe __pycache__ was going nuts)
<ogra_> tedg, so i get 12.04 packages in a precise system ?
<mvo> sergiusens: ok, cool. anything  else I can help with with that branch?
<sergiusens> mvo, review, and maybe fight or side with tedg :-P
 * ogra_ proposes a round of bullshit bingo during standup, who wins decides ...
<sergiusens> mvo, tedg ogra_ MP is here fwiw https://code.launchpad.net/~snappy-dev/snapcraft/more-apt/+merge/271817
<sergiusens> tedg, using local sources also may provide unsharable builds as it might depend on the ppa set you have
<ogra_> well, you got vivid hardcoded there or do i read the code wrong ?
<sergiusens> ogra_, yes; that will change once target lands in snapcraft.yaml
<ogra_> right
<tedg> sergiusens: Sure, but I think what we want first is to make it easy to use, not universally correct.
<sergiusens> ogra_, targetting the right target
 * ogra_ thinks thats fine for a start 
<ogra_> tedg, you mean like we did with all the rest of snappy that we are redesigning over and over now ?
<ogra_> i think doing it correct from the start is the better approach :)
<tedg> ogra_: I believe the modern, hip word is "pivoting"
<ogra_> even if that means it isnt complete
<tedg> I disagree that it is correct.
<tedg> I think it's forcing someone to starting building a system that is correct from the start, it's okay if they don't make it perfect from the start.
<ogra_> i only disagree that we should use vivid as default
<tedg> We need it to be easier to play with from the start.
<sergiusens> tedg, why is it hard to play with this way?
<tedg> sergiusens: Because when it breaks you can't easily figure out why.
<sergiusens> I really want to avoid the 'works for me' converstions
<sergiusens> tedg, ah, but when it breaks and we get a bug report we can
<tedg> sergiusens: No, it'll be "eh, doesn't work, I'll use Docker" ;-)
<tedg> There'll be no bug report
<sergiusens> tedg, in any case we can add a cli switch to use the local cache
<sergiusens> tedg, well, we have 2 already
<tedg> Hmm, I think I broke it.
<tedg> Seems None is different than not a value.
<asac> tyhicks: thx!
<tedg> sergiusens: The exception test is failing, I'm not sure why.
<sergiusens> tedg, oh, because I didn't run the tests :-/ The mp spiraled out of control and ended up in an mp to see the diff
<sergiusens> let me fix those tests
<stgraber> asac: not really. We hardcode those paths for security reasons as some of the LXC binaries are setuid and so using relative paths would allow for a user to root escalation
<dholbach> fgimenez, good catch in your build-examples-test branch!
<dholbach> fgimenez, do you know if we are planning to hook up the dep8 tests with tarmac somehow?
<fgimenez> dholbach, thx :) no idea about the integration with tarmac, maybe elopio can help with that
<dholbach> I think it'd be fantastic if we could run exercise the snapcraft test machinery whenever we want to land stuff - not sure though how much work that would be or if it's planned
<ogra_> dholbach, isnt that the outstanding CI integration thing ?
<dholbach> ogra_, I don't know :)
<ogra_> :)
<Chipaca> sergiusens: where does the yaml requirement come from? i don't see it in config itself
<elopio> dholbach: tarmac is running ./runtests, which executes the integration tests.
<Chipaca> sergiusens: coreconfig, yes, because it yaml decodes it into a struct, but generic config just passes a string?
<jdstrand> tyhicks: re no new info> right that is fine and inline with our card priorities over the last few weeks. thanks! :)
<sergiusens> Chipaca, right
<sergiusens> Chipaca, you are right; I'm just talking spec wise
<sergiusens> Chipaca, code wise we are a bit more broken :-)
<Chipaca> ah, ok
<jdstrand> ogra_: re snapcraft and security updates-- yes, that sounds nice
<ogra_> :)
<jdstrand> and yes, choosing the LTS as the default sounds sane to me, with some way to choose another release
<dholbach> elopio, cool.... with the examples-test landing soon, can we add that too? :)
<dholbach> right now the py2- and py3- examples are broken
<dholbach> qml almost fixed
<elopio> dholbach: we can. What we can't yet is to run the tests in qemu.
<elopio> we need a bare metal machine for that.
<dholbach> ok, I see
<dholbach> thanks elopio
<sergiusens> mvo, so mind reviewing https://code.launchpad.net/~snappy-dev/snapcraft/more-apt/+merge/271817 ?
<sergiusens> Chipaca, in between RESTs ;-)
<Chipaca> sergiusens: clearly
<sergiusens> Chipaca, so never as you are always RESTing now ;-)
<asac> biezpal: hey, can you file a bug please and give it to me?
<asac> thanks
<elopio> ev: can I deploy this is jenkins in a local lxc? That would make the requests to RT easier.
<dholbach> all right my friends - I call it a day - see you all tomorrow!
<tedg> sergiusens: So we may need a way to filter out packages... the ros stuff is pulling in the whole kitchen sink
<tedg> sergiusens: Not sure if we should provide a way to basically say we already have some installed or provided
<sergiusens> tedg, as in, extend the manifest.txt thing?
<tedg> sergiusens: Or just provide a generic filter
<sergiusens> tedg, is this using the ros debs you created?
<tedg> sergiusens: Hmm, I guess I'm set for trusty, so that may be the problem.
<tedg> sergiusens: No, ROS debs from their official archive
<sergiusens> tedg, do most of these ros things need to be stage-packages contrary to build-packages?
 * sergiusens is catching up with ros
<tedg> sergiusens: Yeah, basically you're installing the RPC mechanism.
<tedg> Well, really it's an RPC broker
<jdstrand> zyga (though this may be a question for sergiusens/tedg): I tried to 'snapcraft' with this: https://git.launchpad.net/~zyga/+git/snap-example-hostapd/tree/snapcraft.yaml, and have:
<jdstrand> Namespace(cmd='snap', force=False, func=<function assemble at 0x7f1af125e510>)
<jdstrand> Unknown plugin: x-custom
<jdstrand> Could not load part x-custom
<jdstrand> I have the snapcraft from the tools-proposed ppa
<jdstrand> where does one get that plugin?
<tedg> jdstrand: There is an MR, but I doubt it'll be adopted.
<tedg> jdstrand: It runs scripts, which we were trying to avoid.
<ogra_> jdstrand, alsso the snapcraft.yaml format changed
<ogra_> http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/docs/your-first-snap.md
<sergiusens> jdstrand, did you delete the 'parts' dir in there? that's where local plugins live
<jdstrand> I didn't do anything
<jdstrand> :)
<jdstrand> zygo gave me this url at the beginning of last week
<sergiusens> ogra_, he already has that ;-)
<jdstrand> zyga*
<jdstrand> so I just tried to use it. I guess it needs work
<sergiusens> jdstrand, but yeah, that example won't work with trunk anymore
<jdstrand> zyga: do you have an updated snapcraft.yaml for the new tools?
<jdstrand> well, I don't really need it
<jdstrand> I tested my network-admin cap in other ways and will just add more rules as needed
 * zyga looks
<sergiusens> jdstrand, this MP is pretty straight forward in explaining why https://code.launchpad.net/~sergiusens/snapcraft/mapnames/+merge/271799
<zyga> jdstrand: no, that format works with trunk (it's already using the new format)
<zyga> jdstrand: the issue of running scripts from snapcraft.yaml vs from makefile that that snapcraft.yaml points at is not a priority for me now, I'm working on a commercial project now and I won't have time to look at this for a while
<zyga> jdstrand: it probably doesn't work with the version in the ppa but it does work with trunk
<jdstrand> ok, that's fine
<jdstrand> like I said, I tested what I'm doing in other ways
<zyga> jdstrand: if you branch lp:snapcraft and build it it should be fine
<jdstrand> zyga: thanks
<zyga> jdstrand: ok, sorry this is not more friendly :/
<jdstrand> zyga: ok, I was just going by what others said-- I have the branch from friday running here
<jdstrand> anyhoo
 * jdstrand tries to build a java one now
 * tedg sends flowers to jdstrand's CPU
<jdstrand> well, really, I have a jar file
<jdstrand> I just need to snag openjdk and then I can script the rest
<jdstrand> is there some easy way to say "give me these 5 debs and I'll provide 'services/binaries' that use them"?
<zyga> jdstrand: you can use the stage-debs key AFAIR
 * zyga looks
<zyga>         stage-packages:
<zyga> jdstrand: ^^
<jdstrand> sergiusens mentioned something about that on friday (ie, grab ufw from the archive and use parts for it), but this is different. I want openjdk. I'll just show a jar in the snap and script the rest
<ogra_> jdstrand, http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/snapcraft.yaml
<ogra_> stage-packages
<jdstrand> ok, thanks
<ogra_> (with dash in front)
<zyga> is there a manual page for snapcraft.yaml?
<jdstrand> s/show a/shove a/
<zyga> plainbox has close to two dozen manual pages now and it's a lot easier for developers to use it now
<ogra_> jdstrand, you want the copy plugin then
<zyga> maybe I should write some for snapcraft
<jdstrand> please note, I am a total newbie
<ogra_> jdstrand, look at my snapcraft.yaml above ... you should be able to mostly copy it and change the values
<zyga> jdstrand: that's why manual pages are great!
<sergiusens> jdstrand, you can use the jdk plugin as well
<jdstrand> I read the docs/* and a couple examples
 * jdstrand <3s manpages
<ogra_> sergiusens, will that copy a local jar in place ?
<sergiusens> ogra_, no; I thought he said he wanted a jdk environment :-)
<sergiusens> and grab a random jar
<ogra_> he has a jar and wants the env around it
<jdstrand> yes, what ogra_ said
<sergiusens> jdstrand, maybe the easiest path is ogra's
<jdstrand> ok
<sergiusens> jdstrand, the canonical example from sources is http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/files/head:/examples/java-hello-world/
<jdstrand> sergiusens: yeah, I saw that. I just have a jar, so
<ogra_> so put it next to your snapcraft.yaml and use the copy plugin like in mine ...
<ogra_> for stage-packages you add your jdk then
<ogra_> http://bazaar.launchpad.net/~ogra/+junk/ircproxy/files for reference
<jdstrand> yeah, I have openjdk-7-jre-headless
<sergiusens> zyga, is this fixed btw https://bugs.launchpad.net/snapcraft/+bug/1484596 ?
<ubottu> Launchpad bug 1484596 in PlainBox (Toolkit) "tests print a lot of warnings when they leave files on the working directory" [Undecided,Triaged]
<zyga> sergiusens: nope, not yet, though I did have a look at how to fix it and I think I can patch it in snapcraft directly without involving the more correct fix
 * zyga looks
<zyga> one logging call to silence
<zyga> sergiusens: I have a fix, testing now
<sergiusens> ack, ty
<sergiusens> jdstrand, right, no need to add the jdk if not building
<sergiusens> ogra_, btw, I just recalled; sources.list for armhf will be different (ports...)
<ogra_> yeah
<ogra_> and an /ubuntu-ports suffix
<sergiusens> ogra_, and no geoip I guess
<ogra_> no mirrors
<sergiusens> right
 * zyga adds some improvements for plainbox that snapcraft can use
<zyga> sergiusens: can I assume you run unit tests with the daily development snapshots of plainbox?
<jdstrand> ok, that seems to have worked, nice
<jdstrand> ogra_: thanks!
<sergiusens> zyga, whatever is in our readme
<sergiusens> zyga, sudo add-apt-repository ppa:hardware-certification/public
<zyga> sergiusens: excellent
<sergiusens> elopio or Chipaca mind walking down the pipe for https://code.launchpad.net/~sergiusens/snapcraft/1498140/+merge/271860 ?
 * guest42315 snappy <3
<zyga> sergiusens: testing now, I'll sent the MR in a sec
<zyga> sergiusens: wow, seing people crete new plainbox jobs is amazing
<zyga> sergiusens: FYI: ttps://code.launchpad.net/~zyga/snapcraft/fix-1484596/+merge/271863
<zyga> (still testing, give me one sec)
<sergiusens> zyga, that's empty ;-)
<zyga> ohh, sorry
<zyga> sergiusens: fixed, I'll pastebin the way it runs for me now
<zyga> (now with fixed merge conflict and typos)
<zyga> snapcraft/normal/assemble-meta fails for me (new laptop, perhaps some deps missing)
<sergiusens> zyga, strange
<zyga> sergiusens: I'll pastebin in a sec
<zyga> sergiusens: do I need snappy from the ppa or is wily fresh enough?
<sergiusens> zyga, ah, the ppa isn't fresh enough
<zyga> sergiusens: yes, but it won't prevent it from working
<zyga> sergiusens: I'll merge the fix to the ppa in a sec
<zyga> sergiusens: and fast-path to stable
<zyga> sergiusens: (though tomorrow, I need to ack this with spineau)
<sergiusens> zyga, tomorrow is fine
 * zyga still runs tests for the pastebin
<zyga> http://paste.ubuntu.com/12516689/
<zyga> sergiusens: ^^ I think you can merge this, those are just flags
<zyga> sergiusens: I'll write an article on the new feature and merge this into plainbox
<zyga> sergiusens: afk for a sec
 * zyga tests suspend
<zyga> sergiusens: add those flags to new jobs that are coming in
<sergiusens> ogra_, does this look ok to you?  https://code.launchpad.net/~sergiusens/snapcraft/1498157/+merge/271872
<sergiusens> elopio, finish up the reviews! :-)
<sergiusens> tedg, elopio https://code.launchpad.net/~sergiusens/snapcraft/1498212/+merge/271881
 * sergiusens will be back later tonight
<sergiusens> that fixes the broken setup.py's
#snappy 2015-09-22
<sergiusens> elopio, I've updated bug 1497108
<ubottu> bug 1497108 in Snapcraft "Long paths are not handled correctly when deleting partition mappings" [Medium,In progress] https://launchpad.net/bugs/1497108
<sergiusens> plars, btw ^
<sergiusens> plars, if you don't want u-d-f to bail with loops all around, use relative paths for output image :-)
<plars> sergiusens: ah, ok. I thought I had tried relative paths on an older version of udf  and it didn't like that
<sergiusens> elopio, btw https://code.launchpad.net/~sergiusens/snapcraft/1498157/+merge/271872
<tedg> sergiusens: Uhg, we need a way for plugins to tie into that processing...
<tedg> sergiusens: Or perhaps just append values instead of replacing the whole file.
<tedg> It's getting complex
<sergiusens> tedg, it is
<sergiusens> tedg, which part specifically? env?
<elopio> sergiusens: could you look at this one tomorrow please? https://code.launchpad.net/~dholbach/snapcraft/snapcraft-examples/+merge/271838
<sergiusens> elopio, since it is a merge into federico's branch I just skipped it
<sergiusens> elopio, and thought of reviewing once he merged it all in one shot
<sergiusens> elopio, I approved in any case ;-)
<elopio> sergiusens: thanks. It was you who requested it, so I wanted to make sure it made you happy.
<sergiusens> elopio, yeah, it is good :-)
<sergiusens> elopio, goodnight, just been through my last item for the day :-)
<elopio> sergiusens: good night.
<dholbach> good morning
<fgimenez> good morning
<clobrano> morning o/
<dholbach> hola fgimenez, hola dpm
<dholbach> morning clobrano
<guest42315> mornin'
<dholbach> hey guest42315
<guest42315> \o
<dholbach> wow, it looks like snappy land is just waking up! :)
<fgimenez> hey dholbach and all :)
 * guest42315 sudo snappy install coffee
<dholbach> :-)
<dholbach> mvo, can you take a look at https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801 and let me know if it's the right way to deal with the problem?
<dholbach> fgimenez, I wasn't quite sure if I was doing the right thing with my branch (https://code.launchpad.net/~dholbach/snapcraft/snapcraft-examples/+merge/271838) yesterday
<dholbach> fgimenez, from a packaging POV it's correct, but I don't know if the test machinery will be able to cope with it like that
<mvo> dholbach: sure, I have a look now
<dholbach> <3
<dpm> hey dholbach
<dholbach> mvo, https://bugs.launchpad.net/snapcraft/+bug/1497582 and https://bugs.launchpad.net/snapcraft/+bug/1495525 are examples you can use to test it
<ubottu> Launchpad bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress]
<ubottu> Launchpad bug 1497582 in Snapcraft "duplicate for #1495525 pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress]
<fgimenez> dholbach, totally, thanks a lot :) i need only to adjust the path to the examples directory and the dependencies to work with it, let me have a look
<dholbach> <3
<dholbach> awesome
<mvo> dholbach: hm, I think  lp:~snappy-dev/snapcraft/more-apt  solves this actually already :/
<dholbach> mvo, ok - that works for me
<dholbach> thanks mvo
<dholbach> fgimenez, do you still remember where the libssl-dev depends came from in https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798?
<dholbach> mvo, would it be easy to let apt download all the necessary packages in one go instead of one by one?
<fgimenez> dholbach, i was getting errors when building the examples without it, give me a second and i'll pastebin it
<dholbach> mvo, if you try the qmldemo example it feels veeery slow - also the remaining-download-estimate will never give you anything remotely accurate :)
<dholbach> fgimenez, maybe a missing build-packages in the case of downloader-with-wiki-parts?
<dholbach> mvo, I'm happy to file a bug for it though, so we can resolve it sometime later
<mvo> dholbach: right, we should probably download htem all togehter, I can prepare a branch, essentially we need to adjust dir::cache::archives to the download dir and run cache.fetch_archives()
<zyga> good morning :)
<dholbach> awesome - I'll file a bug and let you know
<dholbach> czeÅÄ zyga
 * zyga wants to try to re-iterate on hostapd example snap/part so that it can be merged
<dholbach> mvo, can you reject https://code.launchpad.net/~dholbach/snapcraft/1497582/+merge/271801?
<dholbach> and milestone https://bugs.launchpad.net/snapcraft/+bug/1497582 to 0.2?
<ubottu> Launchpad bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,In progress]
<zyga> dholbach: how do I say "hi" in German? I only remember tschus but AFAIR that's more like "bye"
<dholbach> zyga, 'hallo' :)
<zyga> dholbach: thanks :)
<dholbach> yes, "tschÃ¼ss" is "bye" :)
<dholbach> mvo, https://bugs.launchpad.net/snapcraft/+bug/1498333
<ubottu> Launchpad bug 1498333 in Snapcraft "Let apt download all packages in one go" [Undecided,New]
<mvo> dholbach: ta, shall I give it a go or do you want to do it?
<mvo> dholbach: happy to do it, just want to avoid duplication of effort
<dholbach> wow
<davidcalle> Hmm
<dholbach> I just asked on #ubuntu-irc
<dholbach> <Flannel> Looks like irccloud was k-lined.
<mvo> dholbach: I think I have a branch
<dholbach> <3
<dholbach> mvo, can you milestone bug 1497582 to 0.2?
<ubottu> bug 1497582 in Snapcraft "pulling ubuntu packages fails when dependencies on virtual packages exist" [Undecided,Fix committed] https://launchpad.net/bugs/1497582
<mvo> dholbach: sure
<dholbach> maybe at some stage I should join ~snappy-dev :)
<mvo> dholbach: do we have a 0.2 series yet?
<dholbach> no series, just a milestone
<mvo> dholbach: done
<fgimenez> dholbach, probably, this is the output http://paste.ubuntu.com/12519630/, i've pushed the changes needed to work with snappy-examples and removed the libssl-dev dependency, you should be able to see the error now
<dholbach> fgimenez, cool - I'll take a look in a sec
<dholbach> mvo_, will check it out in a sec
<mvo_> dholbach: no rush, all good
<mvo_> dholbach: the qml example is 350mb big
<mvo_> that explains why I had to wait a bit to get it :)
<dholbach> yep, I noticed :)
<dholbach> squid-deb-proxy to the rescue
<dholbach> it's the perfect example :)
<mvo_> hahaa
<mvo_> indeed
<dholbach> mvo_,
<dholbach> Get:823 http://de.archive.ubuntu.com/ubuntu/ vivid/main usb-modeswitch amd64 2.2.0+repack0-2ubuntu2 [51.2 kB]
<dholbach> Fetched 253 MB in 6s (25.9 MB/s)
<dholbach> :)
<dholbach> looks like it works ;-)
<dholbach> a thing of beauty
<dholbach> mvo_, just two small typos in https://code.launchpad.net/~mvo/snapcraft/lp1498333-even-more-apt/+merge/271918
<mvo_> dholbach: thanks for the review and yeah, python-apt rocks
<mvo_> (and apt as well!)
<dholbach> fgimenez, commented on https://code.launchpad.net/~fgimenez/snapcraft/build-examples-test/+merge/270798
<davidcalle> asac, jdstrand, mvo, lool, sergiusens, fyi, I've started porting the manual to markdown. I'd like to propose a string freeze on thursday european evening for a v0.1 of development basics, debugging basics (and, if ready,  app porting). In order to start publishing what we have before eow and solve our most prominent docs pain points asap.
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921
<fgimenez> dholbach, thanks! already pushed
<dholbach> great
<asac> davidcalle:  the application manual? think its a bit too early to do that porting
<asac> folks are still doing content etc.
<davidcalle> asac, I'm doing the general outline and already written sections (even if they change during the week), it gives me content to test on the automagic importer to dev.ubuntu.com
<davidcalle> asac, do you think we can have a freeze on some main sections this week? (at least yours and mvo's)
<JamesTait> Good morning all; happy Tuesday, and happy Business Womenâs Day! ð
<asac> davidcalle: maybe... have to check with team. My section I have to rewrite as the content is mostly the future. have to redo it with what is real right now
<asac> davidcalle: why do you want to freeze?
<asac> or is it about moving it top markdown and abandoning this doc at some point?
<davidcalle> asac, that too but it can happen later, mostly to be able to publish something in the rough timeline we have defined
<davidcalle> asac, I'm asking about these two sections, because they are the most important for app devs ( and snapcraft of course, but for now the trunk demos + currently published docs are fine)
<asac> davidcalle: so our tiemlnie is to get this doc done early octobver ... like 1st or 2nd
<asac> outline we need to finish today
<asac> first two sections is me and mvo... i think we can do it by EOW ... and given that we are busy next week I guess thats what we have to do
<davidcalle> asac, sounds good to me, are you fine with publishing sections as soon as they are ready? We'll be able to change and update them of course, but I think it makes sense to do it early, especially if we have snappy events and clinics coming up
<asac> true
<asac> when are we doing first clinic?
<davidcalle> dholbach, ^?
<asac> mvo_: can we get development basic and debugging section done by EOW?
<asac> you and me? :)
<asac> debuggin section includes sergiusens work
<dholbach> asac, on the clinic: no idea - I was sort of waiting on news regarding the competition
<dholbach> asac, but I'm working on bullet points for a presentation already
<asac> ok i will poke mectors
<asac> have a call with him in a bit
<dholbach> <3
<biezpal> asac, hey, bug filed - https://bugs.launchpad.net/snappy/+bug/1498396
<ubottu> Launchpad bug 1498396 in Snappy "Random string in data path breaks application" [Undecided,New]
<ogra_> mvo_, shouldnt snapcraft delete stage/usr/share/man ? we dont really need it
 * ogra_ notes that he has a ton of manpages there 
<asac> ogra_: you can use
<asac> snap:
<asac>  - -usr/share/man
<asac> or something
<asac> to strip stuff fromn snap that you dont want
<ogra_> well, i thionk it should be a default
<asac> why?
<asac> why wiouldnt someone just be able to ship manpages
<ogra_> at least for the debian packages
<ogra_> why would you ship them ?
<ogra_> nothing can use them
<asac> because someone might want to read the manpage for some cli you packaged
<asac> like for bip
<asac> makes sense
<ogra_> you would ahve to ship man yourself
<asac> sure ... still doewsnt mean that all want to strip it
<asac> i can also read manpages with vi
<asac> :)
<asac> anyway, talk to sergiusens and then have him align with niemeyer on this i guess
<ogra_> what use would he have to read that manpage ... the ircproxy package is fully cobfigured via snappy config
<ogra_> ok
<asac> ogra_: but the fact that its so nicely done with sanppy config is because your package is nicely done
<asac> doesnt mean that others want to do something like that
<ogra_> indeed
<asac> btw, we mifght watn to talk about how to ship docs at all
<asac> e.g. how would you now doc your nice ircproxy package
<ogra_> yeah
<asac> the config options you providem, how to use it, etc
<ogra_> well, theoretically i would describe it in the store description ... but only webdm will show that (hopefully one day :P )
<davmor2> asac: sanppy sounds like an awesome name for snappy san :)
<mvo_> ogra_: yeah
<ogra_> do we plan a snappy equivalent to "apt-cache show <package>" ?
<ogra_> that would show the store description ...
<mvo_> asac: develpment basics? is that also on my list? I was working on "Debugging basics" so far and its mostly done except strace/gdb because there is no package yet
<mvo_> ogra_: yes, its not speced yet, but snappy info <pkgname> is probably that
<ogra_> ah
<ogra_> asac, so that would be my docs then ... not sure we want some additional mechanism
<ogra_> probably the store could just have a field that specifically describes configuration
<ogra_> snappy info -c <packagename> could then spit our "snappy config" output with the possible values shown for each option
<ogra_> (or something like that)
<ogra_> hah, hello ogra2, hello snappy autopilot :)
<ogra_> (looks like my ircproxy machine just restarted itself)
<sergiusens> asac, you haven't sent out the docs?
<sergiusens> asac, I found it hard to describe snapcraft.yaml without describing parts, so was thinking of inverting the order
<pitti> mvo_, ogra_: hm, neither wget nor curl installed; what's the recommended way on snappy to download something?
<pitti> call python3?
<ogra_> pitti, download on your host and scp
<pitti> ogra_: well, this is for a "setup-classic" script I'm supposed to write
<ogra_> i have an unconfined wget snap too (amd64 only atm though)
<ogra_> pitti, ah, well, ship wget inside your sanp then
<ogra_> *snap
<ogra_> assuming your "classic" thing comes as snap
<pitti> mvo_: ^ will we have a snap for this "classic" setup, or will that need to go into snappy core then?
 * ogra_ thinks core is way way to bloated already 
<ogra_> we are slowly moving out of the embedded space
<pitti> would calling python3 -c ... with urllib.urlretrieve() be okay?
<pitti> or will python3 go away too/
<pitti> ?
<ogra_> once we drop clooud-init and system-image we might drop it
<ogra_> not sure about the first, the latter is actively worked on atm
<pitti> okay; this is just a PoC for now, we might even retrieve the "classic" environment through some other way, or bind this to comfy or whatever
<pitti> so I guess I don't worry about this too much for now
 * ogra_ would expect system-image to be gone with the next stable release 
<ogra_> pitti, i'm surprised systemd doesnt have a wget equivalent yet :)
<mvo_> pitti: there is apt-helper download
<mvo_> ogra_: apt has a wget ;)
<ogra_> hah
<pitti> mvo_: I thought apt would be gone?
<mvo_> pitti: yeah :(
<mvo_> pitti: its still there in 15.04
<sergiusens> pitti, I would expect that that would eventually manage setting this up (classic mode)
<pitti> mvo_: "403  Forbidden file type or location"
<pitti> sergiusens: what is "that"?
<ogra_> he means "this"
<ogra_> :P
<pitti> doesn't help :)
<sergiusens> pitti, err; I just woke up :-P first s/that that/snappy/
<pitti> sergiusens: ah, ok :) so this shell script PoC might be rewritten in go or so
<ogra_> sergiusens, so snappy woould have a builtin wget ?
<pitti> I suppose Go has some url retrieve API
<sergiusens> ogra_, no; setting up classic mode would be eventually driven by snappy
<mvo_> yeah, go can fetch stuff from http
<sergiusens> I'm just guessing
<ogra_> right
<ogra_> as long as we dont have to bloat core more and more ...
<pitti> right
<pitti> I'm using python3 in the PoC for now that shoudl survive at least next week (and then we might do this completely differently anyway0
<ogra_> yeah
<mvo_> pitti: you have a mail with slides :)
<zyga> sergiusens: this can land as-is https://code.launchpad.net/~zyga/snapcraft/fix-1484596/+merge/271863
<zyga> sergiusens: the plainbox bits are merge in trunk now
<zyga> sergiusens: and the will be a part of plainbox 0.23
<zyga> sergiusens: which is now in QA
<davmor2> mvo_: wow sliding mails what will you guys come up with next ;)
<dholbach> sergiusens, I'm not sure I understand your comment in https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921
<dholbach> sergiusens, AFAICS you need libgudev-1.0-dev installed as part of build-packages (for the build to pass locally) AND to bundle libudev-1.0-0 for the snap to work on a snappy system
 * mvo_ hugs dholbach for fixing bug #1498347
<ubottu> bug 1498347 in Snapcraft "godd example: error while loading shared libraries: libgudev-1.0.so.0: cannot open shared object file: No such file or directory" [High,In progress] https://launchpad.net/bugs/1498347
 * dholbach hugs mvo_ back :)
<dholbach> mvo_, is the MP the right way to fix it? it looks like sergiusens had reservations
<mvo_> dholbach: not sure if he has reservations in general
<dholbach> mvo_, no, I meant the comment in the MP
<mvo_> dholbach: aha, let me read
<sergiusens> dholbach, mvo_ since this is an example, I would use a stage-package without filesets (to remove the headers at least) so the snap doesn't have header file all over it
<sergiusens> mvo_, dholbach the other option is to stage-package the library itself and not -dev; but it makes it a nicer example if the stage-package is the dev one
<dholbach> sergiusens, I think that's what I'm doing
<dholbach> stage-packages: [libgudev-1.0-0]
<sergiusens> dholbach, yeah, but you should remove the build-package entry below :-)
<dholbach>  build-packages:
<dholbach> 10	     - libgudev-1.0-dev
<dholbach> why?
<sergiusens> dholbach, and use a fileset
<dholbach> it is required to build the package
<dholbach> hum
<dholbach> I never used filesets before
<sergiusens> dholbach, it shouldn't be needed; stage-package entries are also used for building
<dholbach> I see
<dholbach> mvo_, ^ do you have a strong opinion?
<sergiusens> tedg, hey, mind looking at https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751 https://code.launchpad.net/~ted/snapcraft/multi-python-version/+merge/271716 ?
<jdstrand> davidcalle: what manual are you referring to, the the enterprise manual?
<jdstrand> davidcalle: the parts I've written are only a first draft and I have two more sections. I already know there are edits I need to make to the sections I've written
<jdstrand> if we work off a single bzr tree for markdown, things are going to get complicated with merges
<davidcalle> jdstrand, no worries about that, bzr tree will come only after the first published version. DIfferent files for each section as well.
<davidcalle> jdstrand, we can even split it more if needed to ease having simultaneous editors working on it at the same time. Having a bzr trunk makes the publishing process very streamlined. Trunk would be pulled every 2h and turned into fancy cms pages.
<jdstrand> davidcalle: I'm only talking about this week
<jdstrand> davidcalle: what is the verdict? am I supposed to be editing markdown now?
<jdstrand> where is it?
<davidcalle> jdstrand, nope :)
<jdstrand> ok, cause assuming I don't get pulled aside (like the last three days), I plan to work on it after a couple of meetings
<davidcalle> jdstrand, keep going with the gdoc, no rush for this week on your end, by eow I'll publish what's ready: hopefully development basics and debugging basics. What's finished will be converted to markdown as well but I'm happy with this first iteration being in gdocs, I'll handle the publication related details.
<davidcalle> That's a big enough task, let's avoid editors being annoyed by formatting (yet :D)
<sergiusens> dholbach, https://code.launchpad.net/~sergiusens/snapcraft/doc-services/+merge/271959
<dholbach> ok... mvo is looking at right now as well
<tedg> sergiusens: Sure, BTW, I'm not sure the fixup code should go in the Ubuntu plugin. It seems like it'd be needed no matter how you installed libxml or libxslt.
<sergiusens> tedg, ok, makes sense
<sergiusens> mvo_, thanks for that apt improvement!
<jdstrand> davidcalle: ack, thanks. I hope to have all my parts written by eow at least in 1st/2nd draft quality
<jdstrand> so that seems to work well with your timeline (and moving into bzr)
<davidcalle> jdstrand, indeed, wfm :)
<pedronis> hey, is it expected/known that building a amd64 image with udf core 15.04 --channel edge and --developer-mode  sshing doesn't work? it works with stable though
<mvo_> sergiusens: your welcome!
<dholbach> sergiusens, so I'm going to merge mvo's work which does what I guess you were expecting (correct me if I'm wrong): https://code.launchpad.net/~mvo/snapcraft/1498347/+merge/271961
<mvo_> sergiusens, dholbach: so the godd example got a little bit more complicated due to the new libgudev dependency. now I could try to hack around that in godd by doing static linking with cgo etc, but it made me wonder if maybe we should do something smarter in snapcraft
<dholbach> sergiusens, I personally don't feel that snapcraft is easy to understand in this specific example or easy to handle
<dholbach> mvo_, I'm sure we are going to have more cases like that
<mvo_> sergiusens, dholbach: i.e. we could auto-copy all libs from the ldd output of each binary listed in binaries by default maybe?
<dholbach> add a build-dep, bundle a certain set of packages or set of files from other packages
<dholbach> mvo_, that would probably eliminate most of the hassle :)
<sergiusens> mvo_, stage-packages should get copied over by default
<dholbach> https://code.launchpad.net/~dholbach/snapcraft/1498347/+merge/271921 is up for review again
<sergiusens> mvo_, dholbach this looks nice!
<dholbach> sergiusens, I'm not sure I agree - I find it a bit hard to explain it to future snappers :)
<dholbach> or hard to explain the "here's how you debug which files are missing in your snap" iteration cycle :)
<dholbach> it'd be nice if it was easier at some golden, glorious and beautiful point in the future
<mvo_> maybe doing it magically is not the right way, but I would love to have something simple like snap: [$shlibs] or something, a magic var that snapcraft fills that contain the shlib depends?
<mvo_> dholbach, sergiusens: -^
<mvo_> we could even steal https://code.launchpad.net/~mvo/click/click-check-libs/+merge/235960 for this
<sergiusens> mvo_, as long as we look only in the parts
<sergiusens> mvo_, but not the host
<sergiusens> mvo_, but by default everything will be included
<sergiusens> dholbach, ^
<sergiusens> the fileset is just to make the final snap look nicer
<sergiusens> not mandatory
<sergiusens> I'm only saying we should use it as it is an example
<dholbach> ok, I think that makes sense
<Chipaca> mvo_: https://code.launchpad.net/~chipaca/snappy/husk/+merge/271965 if you're itching to review something juicy
<dholbach> we could have two examples, that's right
<sergiusens> but just using 'stage-packages' would of included the libs
<sergiusens> dholbach, the walkthrough goes over this fwiw
<mvo_> Chipaca: I love to review your stuff, you know that
<Chipaca> mvo_: âD
<sergiusens> mvo_, btw, I don't mind building in default fileset filters as you mentioned 'bins', 'shlibs', 'headers' or 'development'
<mvo_> sergiusens: I think that would be good, we need to prune the shlibs of course to filter out the ones we already have in core, but that should be straightforward
<sergiusens> mvo_, well, if grabbed from 'stage' it shouldn't matter too much
<sergiusens> then again, weird things can happen
<sergiusens> tedg, btw, do you want me to change env management to use dicts and have each plugin get a copy of the env, be able to add to it and return it when called?
<sergiusens> tedg, it could clean up the case where things get stepped over
<tedg> sergiusens: Are we still gonna do shell expansions?
<tedg> I think we need to keep those.
<sergiusens> tedg, I don't see why not
<elopio> ogra_: have you been able to use parted with --pretend-input-tty ?
<ogra_> elopio, i havent looked into resizing this week
<ogra_> on my TODO though
<ogra_> but RPi is more important
<elopio> ogra_: please let me know when you have time for this. For some reason, we are now getting a warning when shrinking the partition on the bbb.
<ogra_> on the BBB ?
<ogra_> that doesnt use the GPT codepath at all
<elopio> no hurry, but I can't use that option.
<elopio> ogra_: yes, on mbr.
<ogra_> well, MBR is not using any magic
<ogra_> just the resizepart command
<ogra_> whats the error you get ?
<elopio> ogra_: no, but if I can send a "yes" to parted on mbr, this could work.
<ogra_> we dont want it interactive at all
<ogra_> elopio, got some log with the actual error ?
<elopio> ogra_: sorry. one second.
<ogra_> mvo_, so even an image rebuild doesnt make cloud-init show up anymore on the 15.04 image ... do you know where it is seeded for 15.04 ?
<ogra_> (it is definitely not hardcoded in livecd-rootfs)
<mvo_> ogra_: its part of the "Task:" header
<mvo_> ogra_: which is not available in ppas, sowe need to fake it via "X-Tasks: ubuntu-core"
<ogra_> mvo_, well, or force install it from livecd-rootfs
<ogra_> live-build/auto/config for 15.04 is a mess already, adding one more line wouldnt hurt i guess
<mvo_> ogra_: sure, either way is fine
<ogra_> let me do that then
<elopio> ogra_: Warning: Shrinking a partition can cause data loss, are you sure you want to continue?
<ogra_> shrinking ?!?!
<ogra_> there is surely something wrong then
<elopio> ogra_: that's what I do to test your resize. That's on my script.
<longsleep> ogra_: Your resize code works perfectly for my testing so far by the way. So nice work!
<ogra_> longsleep, thanks, still a hack that will need fixing :)
<longsleep> ogra_: i am very happy with it :)
<ogra_> i'm actually pondering to just switch to gdisk
<ogra_> there is a minor chance you trash your disk if you have powerloss while resizing
<ogra_> i'd like ot get rid of that possibility ... or at least reduce it
<tasdomas> my snappy on RPi2 seems to be stuck "Starting kernel..." after update - where do I look to investigate the cause?
<ogra_> tasdomas, oops, i was supposed to mail about that ... you will need to manually copy the kernel and initrd from /boot/uboot/a to /boot/uboot/b for the upgrade to work
<ogra_> tasdomas, if you reboot the system should boot back into the a partition ... then run snappy update again and then do the file copy before reboot
<tasdomas> ogra_, ack - thanks
<ogra_> thats sadly caused by the non-official state of the RPi image ... (about to change for the next release)
<elopio> plars: could you provide us with an agent for prodstack snappy instances?
<plars> elopio: I thought you were working on that? We specifically said that we would not provide cloud instances since that's something that didn't require special hardware
<elopio> plars: I know. We have it solved for canonistack and now we need prodstack. I'm asking if we could add that as a new requirement for the lab.
<plars> elopio: how is it different from canonistack? Why would it be a lab thing?
<plars> we don't have any special connection to prodstack that you don't
<elopio> plars: I just don't want to maintain it. As you are maintaining all the other testbeds, I want you to maintain it.
<elopio> but if you can't or don't want to, I can do it. That's what I'm asking.
<plars> elopio: I can talk to cwayne about it, but I suspect it's going to fall into the same territory as canonistack
<plars> elopio: on the plus side, I'm very close to being able to provide you with rpi2
<elopio> plars: you see, you'll soon be out of things to do ;)
<plars> elopio: fighting with power problems at the moment - from what I understand, the pi's in the lab may only have a 200ma adapter on them, which makes me wonder how they are running at all
<elopio> plars: should I send an email to cwayne?
<plars> elopio: haha, I only wish I were out of things to do!
<plars> elopio: there's a LOT more coming
<plars> elopio: sure, just cc me on it please
<elopio> plars: it's a joke, of course.
<elopio> plars: sending email... Thanks.
<T-mon> Hello everyone!
<T-mon> I'm updating my snappy package and tested it with the new release
<T-mon> somehow, the SNAPP_APP_PATH env dissappeard
<T-mon> is there a new way to get the path?
<elopio> ogra_: how would you get the start of a partition, by number?
<elopio> like get_start /dev/mmcblk0 4
<ogra_> utlemming, the latest 15.04 edge has your cloud-init now
<ogra_> (sorry, that took quite a bit to have it land there)
<utlemming> ogra_: thank you kindly :)
<ogra_> elopio, there is code that uses sysfs, somewhere in that sysfs node you should be able to get the start and end bvalues
<utlemming> ogra_: what is the version number? 176?
<ogra_> utlemming, 177
<utlemming> ogra_: ack, thanks
<ogra_> sergiusens, you havent synced snapcraft -proposed into -daily yet, right ?
<ogra_> (LP uses -daily so my ircproxy test build failed ... )
<tedg> T-mon: I think you want SNAP_APP_PATH, only one P
<elopio> ogra_: in bytes :D
<T-mon> oh, did that change? 2 months ago it worked
<ogra_> elopio, an opportuntity to compute some math in shell for you \o/
<ogra_> tedg, i thought we still support the old way
<sergiusens> ogra_, oh yeah, daily is dead to me :-)
<elopio> ugh, last time I spent like an hour trying to take a percentage out of the end.
<sergiusens> ogra_, but I haven't told cjwatson yet
<ogra_> sergiusens, well, cjwatson uses it for pulling from
<ogra_> better tell him :)
<elopio> behold, /me does some shell math.
<sergiusens> ogra_, if I do, we should update the docs and prepare some for of announcement
<T-mon> tedg: thx, I'll try it right now :)
<ogra_> elopio, var=$((1+1))
<ogra_> elopio, echo $var
<ogra_> 2
<elopio> ogra_: I know that now. That double parentheses was tricky :)
 * ogra_ is afk for 1h
<sergiusens> ogra_, there, told him :-)
<sergiusens> elopio, mind looking at https://code.launchpad.net/~sergiusens/snapcraft/doc-services/+merge/271959 ?
<elopio> sergiusens: for you, anything.
<T-mon> tedg: SNAP_APP_DATA does not exist...the are no SNAP_* ord SNAPP_* env variables
<sergiusens> elopio, lol, it is a one liner in docs :-)
<elopio> sergiusens: two lines.
<sergiusens> elopio, sorry, my mistake
<tedg> T-mon: You can check the wrapper script for your binary by looking at /apps/bin
<elopio> sergiusens: could you review if our go is decent here? https://github.com/elopio/go-subunit/blob/master/subunit.go
<sergiusens> elopio, sure thing
<sergiusens> elopio, btw, any eta on landing the examples test branch?
<elopio> sergiusens: there is a tiny lintian error. I could top-approve it, and then give you another branch to fix the issue.
<elopio> sergiusens: not all the examples are building, but that's expected, right?}
<sergiusens> elopio, or just take over the branch and resubmit ;-)
<elopio> and take all the credit \o/
<elopio> sergiusens: top approved and https://code.launchpad.net/~elopio/snapcraft/fix_lintian/+merge/272023
<elopio> I felt bad to steal Federico's branch.
<sergiusens> tedg, mind adding a '-q' to the grep calls in the test in  https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751 ?
<tedg> sergiusens: Heh, because that's the biggest source of output ;-)  Will do.
<sergiusens> tedg, I hope and wish zyga gets his branch in soon ;-)
<longsleep> Is there any particular reason why "auto eth0" was added? I added bug #1498631 for this as it blocks boot for 2 minutes
<nothal> Bug #1498631: Snappy waits 2 minutes while booting if eth0 is not connected <Snappy:New> <http://launchpad.net/bugs/1498631>
<ubottu> bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [Undecided,New] https://launchpad.net/bugs/1498631
<sergiusens> longsleep, wasn't that always there?
<longsleep> sergiusens: i do not think so, boot delay started with release 5/stable
<sergiusens> longsleep, right, but auto eth0 was always there iirc
<sergiusens> longsleep, might be the first manifestation for something else blocking and I think it may be the wait4network thing
<sergiusens> Chipaca, ideas? ^
<longsleep> sergiusens: ok then some change in systemd might cause it or the ifup-wait-all-auto.service is new
<longsleep> that service does just wait for a pid file to appear for any interface which gets returned by ifquery --list --exclude lo --allow auto
<longsleep> maybe that has failed earlier for other reasons
<sergiusens> longsleep, that service does not ring a bell with me; I'll defer to ogra_ or Chipaca
<longsleep> sergiusens: yeah - just went through a test run and added 4 or 5 new issues to the tracker. But that one is the most annoying as it requires me to connect a network cable while testing :/
<tedg> sergiusens: greps are now quieter
 * tedg can now hear himself think
 * longsleep has turned on loud music and got drunk to prevent thinking
<sergiusens> yay
<Chipaca> longsleep: hi
<Chipaca> longsleep: you still there?
<Chipaca> oh, drunk longsleep might be even longer sleep
<sergiusens> tedg, the tests are failing on tarmac
<sergiusens> while running 'sed'
<Chipaca> ooh, nice ppp bug :-/
<tedg> sergiusens: Perhaps a dep?
<tedg> sergiusens: Where is the error?
<sergiusens> tedg, oh; so complicated; download https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751/comments/685604/+download
<sergiusens> tedg, and search for failed
<sergiusens> tedg, train your eyes to get rid of the Leftover thing
<sergiusens> ;-)
<longsleep> Chipaca: still there watching soccer
<Chipaca> longsleep: i presume you filed bug 1498631 ?
<ubottu> bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [Undecided,New] https://launchpad.net/bugs/1498631
<longsleep> Chipaca: yeah - it annoyed me pretty hard last couple of hours :)
<tedg> sergiusens: It seems to be failing on the greps... wish they weren't quiet ;-)
<tedg> sergiusens: Not sure what could be failing. Can you run the tests on your system?
<Chipaca> longsleep: could you add details like the architecture, and how you got the image?
<tedg> Curious if I've made a special snowflake here.
<Chipaca> longsleep: I don't think that particular aspect of the system changed; we added a wait4network and make network-needing services start after that, but it should not block boot
<longsleep> longsleep: Uhm sure - like armhf and u-d-f sytax you mean?
<Chipaca> longsleep: yeah
<longsleep> =n
 * longsleep can't type properly any more :)
<tedg> Soccer, does it to me too.
<Chipaca> longsleep: that way when whoever gets to poke at it does, they don't have to wonder/guess as much :)
<longsleep> Chipaca: if you have a snappy installation at hand, can you check if you have /lib/systemd/system/ifup-wait-all-auto.service
<Chipaca> longsleep: sure, let me boot a stable though
<longsleep> that service is responsible and i think it was not added by anything i did
<longsleep> actually i did not su much except using my own device and oem snap
<Chipaca> booting. with network -- i wonder if i can boot kvm without network
<longsleep> Chipaca: yeah, if you use virsh you can use domif-setlink
<Chipaca> longsleep: one thing is that we expect the first boot of an updated system to take a while
<Chipaca> longsleep: but i presume this isn't that
<longsleep> longsleep: no it waits on any boot until eth0 is up or 2 minutes systemd timeout
<longsleep> first boot takes longer because it creates keys and such
<longsleep> but on quad core 1.6 ghz arm it is almost no difference
<Chipaca> longsleep: first boot after update also needs to shunt kernel and initrd to their new! updated! locations, which is slow
<Chipaca> but that's just once, just on updated systems (ie systems that were updated, not created from scratch)
<Chipaca> anyway, yes it exists
<longsleep> so then ifquery --list --exclude lo --allow auto does return eth0 for you as well, meaning it will wait until the pid file is there
<longsleep> Chipaca: details added to bug #1498631
<nothal> Bug #1498631: Snappy waits 2 minutes while booting if eth0 is not connected <Snappy:New> <http://launchpad.net/bugs/1498631>
<ubottu> bug 1498631 in Snappy "Snappy waits 2 minutes while booting if eth0 is not connected" [Undecided,New] https://launchpad.net/bugs/1498631
<Chipaca> verterok: can you disable the bug plugin for nothal in this channel? it fights with ubottu :-/
<Chipaca> verterok: also: hello! long time no chat.
<Chipaca> longsleep: ifup-wait-yadda-yadda is there in stable 4 also
<longsleep> Chipaca: regarding the update of kernel, initrd and stuff i have bug #1464859 and it really took ages for me when i was testing upgrade to 5 yesteday and it does not even need the stuff
<nothal> Bug #1464859: /boot contains unused initrd.img <Snappy:Triaged> <Snappy 15.04:New> <Snappy trunk:Triaged> <http://launchpad.net/bugs/1464859>
<ubottu> bug 1464859 in Snappy trunk "/boot contains unused initrd.img" [High,Triaged] https://launchpad.net/bugs/1464859
<longsleep> Chipaca: yes, so something else must have triggered the new behavior, in 4 there was no boot delay.
<longsleep> Chipaca: i assumed that the eth0 auto was added, but sergiusens mentioned that was also there before
<Chipaca> longsleep: do you have snaps installed that have services that have external ports configured?
<longsleep> Chipaca: no, nothing installed - just the plain image
<Chipaca> k
<longsleep> Chipaca: it directly does that on first boot, so only snap installed is the oem snap and that has no services
<Chipaca> fwiw, â-net noneâ is what to add to a kvm commandline to get no network
<longsleep> Chipaca: ok, does it have a NIC then or do you end up without having eth0 ?
<Chipaca> with that added, i get no network interface
<Chipaca> and 15.04.5 is taking ages to boot
<Chipaca> :)
<Chipaca> but not two minutes
<longsleep> Chipaca: well there is a nice animation on the boot conole while it waits
<Chipaca> in fact, significantly less than two minutes
<longsleep> including countdown
<Chipaca> yeh, i need to reboot so i can set the console to the right place
<longsleep> but if you have no eth0 it will not wait
<longsleep> you need to have eth0 which does not have a connection
<verterok> Chipaca: hola!
<verterok> Chipaca: sure, will disable it asap
<Chipaca> longsleep: just confirmed, no waiting for network at all, here
<verterok> Chipaca: done
<Chipaca> longsleep: need to dig a little more
<Chipaca> longsleep: will do so in a bit
<Chipaca> verterok: thanks!
<Chipaca> bug #1
<ubottu> bug 1 in Ubuntu Malaysia LoCo Team "Microsoft has a majority market share" [Critical,In progress] https://launchpad.net/bugs/1
<Chipaca> \o/
<longsleep> Chipaca: yeah, you can easily test with ifquery, if that returns nothing then it will never wait
 * Chipaca facepalms
<longsleep> Chipaca: exactly with 'ifquery --list --exclude lo --allow auto'
<Chipaca> longsleep: yeah, sorry
<Chipaca> longsleep: ok, reproduced
<longsleep> Chipaca: ok great, any ideas why it did not happen on previous builds?
<Chipaca> longsleep: no
<Chipaca> longsleep: baby steps :)
<Chipaca> longsleep: meanwhile you can change that yourself using ubuntu config, yes?
<longsleep> Chipaca: uhm, sure i just removed auto eth from /etc/network/interfaces.d/eth0 - not sure about ubuntu config
<longsleep> Chipaca: what is "ubuntu config" ?
 * longsleep is probably just too drunk 
<Chipaca> um
<Chipaca> or i'm too tired
<Chipaca> because i meant snappy config :)
<Chipaca> something like
<longsleep> ah :D
<Chipaca> echo -e "config:\n ubuntu-core:\n  network:\n   interfaces:\n   - name: eth0\n     content: |\n       ohgodwhy" | sudo snappy config ubuntu-core
<longsleep> not sure, does ubuntu-core config now expose network config? I missed the last bunch of weeks snappy development :/
<Chipaca> longsleep: yes
<Chipaca> longsleep: not very cleanly yet, but it gets the job done
<Chipaca> longsleep: expect it to change
<Chipaca> longsleep: also, apparently, expect it not to work for ppp :-(
 * Chipaca needs to check on that
<longsleep> Chipaca: ah yes i see, seems one can now handle the content of the eth0 file with snappy config via the oem snap
<Chipaca> yes
<longsleep> Chipaca: so yes - no blocking issue for my use case then
<Chipaca> longsleep: however, note that on first boot a file will be created
<Chipaca> :-/
<Chipaca> so, it will continue to annoy you for a bit
<longsleep> Chipaca: what do you mean? What file?
<Chipaca> longsleep: that eth0 file is created on first boot
<longsleep> Chipaca: right, why would that be a problem?
<Chipaca> longsleep: doesn't oem config happen at image creation time?
<longsleep> Chipaca: this is on my list of things to test
<Chipaca> i have not looked into the oem config magic, though, so i might be wrong :)
<longsleep> I got told by ogra_ that oem config is applied on first boot, but i might remember it wrong.
<Chipaca> ogra would know :)
<longsleep> Chipaca: regarding ppp, did you see #1498620 - i just added some more details
<longsleep> bug #1498620
<ubottu> bug 1498620 in Snappy "Failed to start Restore /etc/resolv.conf if the system crashed before the ppp link" [Undecided,New] https://launchpad.net/bugs/1498620
<Chipaca> longsleep: i didn't, but did you see https://lists.ubuntu.com/archives/snappy-devel/2015-September/001047.html
<longsleep> Chipaca: ah i did not, but that is the problem for #1498620 - so i might have added a duplicate
<Chipaca> longsleep: i don't think there's a bug for the mailing list message
<Chipaca> longsleep: are you subscribed? otherwise i'll point him at the bug myself
<longsleep> Chipaca: yes, i am subscribed - though i can reply tomorrow from the office only
 * longsleep does not want to read office mail now :)
<Chipaca> SGTM :)
<Chipaca> bug 1498620
<ubottu> bug 1498620 in Snappy "ppp files are created one level too deep" [Undecided,New] https://launchpad.net/bugs/1498620
<Chipaca> \o/
<Chipaca> or /o\
<Chipaca> depending
<longsleep> Well thats an easy one so \o/ for sure :)
<jakew> As far as I can tell, snapcraft doesn't currently support building armhf snaps.  Is that correct?
#snappy 2015-09-23
<dholbach> good morning
<clobrano> good morning dholbach, good morning to all ;)
<dholbach> hey clobrano
<clobrano> :)
<fgimenez> good morning
<davidcalle> Morning o/
<dholbach> mvo, hum... I get the following when I try to run the autopkgtest of snappy:
<dholbach> Package gudev-1.0 was not found in the pkg-config search path.
<dholbach> Perhaps you should add the directory containing `gudev-1.0.pc'
<dholbach> maybe build-tools is still required?
<dholbach> or does libgudev-1.0-dev need to be added to the test depends?
<dholbach> fgimenez, ^
<dholbach> I used the following to run the test:
<dholbach> adt-run --setup-commands="apt-get update" --source ../snapcraft_0.2.dsc --- qemu ~/vm/adt-wily-amd64-cloud.img
<fgimenez> dholbach, i'll try to reproduce, give me a second
<dholbach> no worries, take your time
<longsleep> Good morning snappy :)
<Chipaca> longsleep: o/
<Chipaca> mvo: o/
<mvo> hey Chipaca
<Chipaca> mvo: mo'in! What's the plan with trunk vs 15.04?
<Chipaca> clobrano: would you mind signing the CLA, so I can review & land your branch?
<mvo> Chipaca: I would say lets keep them in sync for now, until the next huge change (the os/kernel snap/squashfs work)
<mvo> Chipaca: or how do you feel about it?
<Chipaca> mvo: i ask because we have some branches aimed at one, and some aimed at the other :)
<mvo> clobrano: here is the link (in case you do not have it yet) http://www.ubuntu.com/legal/contributors
<mvo> Chipaca: yeah
 * Chipaca just wants to land all the good stuff
<mvo> Chipaca: ok, lets land it all in trunk
<dholbach> lool, asac, mvo, ogra, davidcalle, can we move the community sync half an hour earlier today? UE Personal has an Allhands call at the same time
<ogra_> fine with me
<Chipaca> mvo: that means resubmitting your untar perms fix
<Chipaca> mvo: so i agree ;)
<Chipaca> (it's the smallest resubmission, compared to landing everything in 15.04, or >shudder< landing in both and two-way-merging
<Chipaca> )
<Chipaca> husk retargeted
<mvo> Chipaca: thanks, retargeted
<lool> dholbach: fine with me too
<Chipaca> mvo: did you have a chance to look at fgimenez's comment & error & patch on https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176 ?
<JamesTait> Good morning all; happy Wednesday, and happy Restless Legs Awareness Day! âº
<Chipaca> JamesTait: are you ever not aware of restless legs? isn't that the whole problem?
<fgimenez> Chipaca, mvo lot's of things have change since then, let me check again
<JamesTait> Chipaca, for those who suffer from the condition, yes.  I think the point is for those who don't even know it exists, to know it exists.
<dholbach> mvo, asac, davidcalle: fine to move community sync today half an hour earlier?
<mvo> dholbach: fine with me
<fgimenez> dholbach, i can confirm the problem but can't find a proper solution from the test side, it keeps trying to find the seemingly unexisting gudev-1.0 package, maybe mvo can help
<dholbach> ok
<davidcalle> dholbach, not sure I'll be able to make it, but that's fine :)
<dholbach> ok davidcalle, no worries
<dholbach> fgimenez, thanks a lot for checking
<mvo> fgimenez: what command should I run to reproduce the issue?
<dholbach> mvo,
<dholbach> adt-run --setup-commands="apt-get update" --source ../snapcraft_0.2.dsc --- qemu ~/vm/adt-wily-amd64-cloud.img
<mvo> ta
<mvo> dholbach, fgimenez sorry that this took forever, but I know now why the godd example fails, it looks like "go get" already runs pkgconfig (for gudev)  which is a bit odd and breaks snapcraft that only installs it in the build stage
<dholbach> don't worry - thanks a lot for looking into it
<mvo> dholbach: I'm trying to fix it no
<mvo> w
 * dholbach hugs mvo
<fgimenez> dholbach, ok thanks a lot :)
<fgimenez> mvo,  ^^ :)
<mvo> fgimenez, dholbach: do we have a bug for this autopkgtest failure already?
<dholbach> no, I don't think
<sergiusens> mvo, dholbach that is strange, stage-packages are downloaded and unpacked during 'pull'
<mvo> sergiusens: yeah, I think I found the issue
<sergiusens> mvo, ted has a branch to fix paths from pkg-config fwiw
<sergiusens> but it is failing its tests :-)
<mvo> sergiusens: give me 5min to verify, it seems like its downloading and building when it really should just download
<mvo> sergiusens: I push a branch
<sergiusens> mvo, okie dokie
<sergiusens> mvo, btw, wrt pkg-config https://code.launchpad.net/~ted/snapcraft/pkg-config-sysroot/+merge/271751
<mvo> sergiusens: yeah, this one is missing
<sergiusens> dholbach, want to look at this one https://code.launchpad.net/~sergiusens/snapcraft/pull-python-projects/+merge/272057 ?
<dholbach> sergiusens, I'm a but busy with something else right now
<dholbach> asac, around?
<Chipaca> sergiusens: what was it you wanted me to review?
<Chipaca> elopio: fgimenez: could you guys not be shy with "needs fixing" in reviews? makes finding things needing reviews a lot easier
<Chipaca> e.g. https://code.launchpad.net/~fgimenez/snappy/1504_validation/+merge/271777
<Chipaca> that's a needs fixing, if i'm reading elopio's comments right
<Chipaca> same as https://code.launchpad.net/~elopio/snappy/new_kernel_file_name/+merge/271901 wrt fgimenez's comment
<sergiusens> Chipaca, https://code.launchpad.net/~sergiusens/snapcraft/pull-python-projects/+merge/272057
<Chipaca> fgimenez: mvo: also what's up with https://code.launchpad.net/~mvo/snappy/lp1480248-test-reenable/+merge/269176
<sergiusens> fgimenez, all plainbox changes are missing in snapcraft now :-P
<Chipaca> it's nearly a month old, and i don't know
<fgimenez> Chipaca: wrt https://code.launchpad.net/~elopio/snappy/new_kernel_file_name/+merge/271901 i'm asking for confirmation, not sure if my results are reproducible, anyway you are right, i'll try to be more explicit
<clobrano> Chipaca, mvo: sorry I was out of office, I'll look at it as soon as possible
<mvo> no worries :)
<fgimenez> Chipaca, i'll take a look at test-reenable branch, iirc there's other disabled test that we should be able to reenable
<fgimenez> sergiusens, "missing" sounds bad... :)
<sergiusens> fgimenez, it seems to work now... not sure if it was a plainbox thing, as I got a huge message saying it was analyzing stuff and then exited
<clobrano> mvo: what's "Project Contact" in CLA?
<Chipaca> clobrano: Alexander Sack, afaik
<clobrano> Chipaca: ok, thanks
<Chipaca> asac: right?
<dholbach> mvo, ogra, lool: I haven't heard back from asac about the call, but didn't have too much to bring up apart from a clinic date - I can talk now, but can't in 30m - what do we do?
<lool> clinic?
<lool> dholbach: I dont have much either
<lool> dholbach: I wonder: should we pull in davidcalle in these calls in the future? he's been working on the public facing docs too IIUC
<dholbach> lool, snappy clinic
<lool> oh right
<dholbach> lool, yes, he's invited
<dholbach> but he couldn't attend today
<lool> ah ok
<lool> dholbach: well I dont mind if we skip today, albeit I have missed last week so perhaps you want to sync real quick
<dholbach> sure
<lool> dholbach: asac is often triple-booked, so I wouldn't worry about his avail as much
 * lool joins HO
<lool> let me grab a headset of some sort
<ogra_> one sec, gimme 3min
<mvo> dholbach: sure, joining now
<mvo> dholbach: hm, ff crashed, one sec
<clobrano> Chipaca: CLA signed, thank you ;)
<sergiusens> dholbach, btw, is there a calendar entry for the snappy clinic?
<sergiusens> or am I meddling :-)
<sergiusens> ?
<ogra_> sergiusens, there isnt
<ogra_> (we were just searching)
<dholbach> sergiusens, no - I have no idea -- we just thought about it and asked if we shouldn't do it on Friday or are you flying there?=
<asac> dholbach: for me that comm call is at 3 :)
<tedg> sergiusens: were you able to get the pkgconfig tests to fail locally?
<dholbach> asac, I have a call at the same time
<sergiusens> tedg, hah, dholbach has
<sergiusens> tedg, well he added the exact cause to the MP
<sergiusens> dholbach, I am out Friday
 * tedg looks
<dholbach> sergiusens, ok.....
<tedg> Hmm, mail still syncing
<sergiusens> tedg, that's not a problem with webmail
<sergiusens> :
<sergiusens> :-P
<tedg> sergiusens: Yes, but *everything* else is :-)
<sergiusens> fgimenez, should we make tarmac run the examples?
<dholbach> sergiusens, lool suggested tomorrow 12:30 UTC - would that work for a clinic for you?
<sergiusens> dholbach, perfect
<lool> 13:30 UTC actually
<lool> oh sorry
<tedg> sergiusens: dholbach: I'm not seeing it... where was it?
 * tedg can't beleive that LP didn't send him e-mail about something
<dholbach> tedg, it's a new suggestion
<lool> half an hour ago, tomorrow
<sergiusens> tedg, look it up on the web, don't be lazy ;-)
<lool> in 23h30
<fgimenez> sergiusens not sure, i think that elopio and dholbach talked about that a few days ago
<dholbach> tedg, it never was in the calendar :)
<tedg> Ah, on the MR.
<Chipaca> clobrano: did you get an email or something when signing the CLA?
<Chipaca> clobrano: trying to figure out why the person that does the paperwork at our end hasn't received the email yet
<clobrano> Chipaca: nope
<clobrano> no emails
<sergiusens> Chipaca, clobrano if it is showing up on launchpad I think it should be fine
<Chipaca> sergiusens: it isn't
<Chipaca> sergiusens: that step is manual, unless i'm very mistaken
<Chipaca> that is: there is a person at canonical that receives a particular email, and adds people to a particular laucnhpad group
<clobrano> maybe I'm missing the GPG key..
<Chipaca> but maybe the email goes to asac?
<sergiusens> yeah, that cn do it
<clobrano> openPGP
<sergiusens> gpg missing means there is nothing to sign with
<sergiusens> fgimenez, super simple one https://code.launchpad.net/~sergiusens/snapcraft/no-test-print/+merge/272099
<rickspencer3> hi all
<rickspencer3> I'd like to upgrade my rpi2 to the latest and greatest with rolling
<rickspencer3> can anyone easily give me the right commands to get and build the correct image?
<ogra_> rickspencer3, wily you mean ?
<fgimenez> sergiusens ok done, if needed the tests could use the logging module
<rickspencer3> ogra_, I dunno, I'd like to get daily updates
<rickspencer3> I assumed that I would get on "rolling" for that
<ogra_> rickspencer3, well, we do daily builds in 15.04/edge and in rolling/endge
<ogra_> the latter is wily based
<rickspencer3> ogra_, I think rolling/edge
<ogra_> ok ... not sure if it works, i doubt anyone ever tried booting that on a rpi ....
<rickspencer3> ogra_, ok, nm
<rickspencer3> I'll take 15.04/edge, then :)
<ogra_> sudo ubuntu-device-flash core rolling --channel edge --developer-mode --oem pi2 --device-part  device-pi2-0.15.tar.xz -o pi2-rolling-edge.img
<ogra_> that would be the line for rolling
<ogra_> and indeed you need the device tarball
<ogra_> from http://people.canonical.com/~platform/snappy/raspberrypi2/
<rickspencer3> ogra_, right, but if it is not even tested to boot on the rpi2 yet, I think I would be better off with 15.04, I guess
<ogra_> then you just replace the "rolling" in that line with 15.04
<sergiusens> rickspencer3, we don't guarantee a boot on edge though
<ogra_> i'm waiting for the kernel package to land in the archive (stuck in -proposed) and will then provide an upgraded device tarball
<rickspencer3> ogra_, so I should wait until later today?
<ogra_> right, what sergiusens said ... but i booted edge the last days
<rickspencer3> I kind of sorta am desperate for pwm support
<ogra_> rickspencer3, depends on how fast the archive admins and rtg are
<ogra_> there is a packaging bug he needs to fix
<rickspencer3> ok
<tedg> sergiusens: Adding PKG_CONFIG_PATH, can't really remove GLib on my system to test it though. I still doesn't fail here :-)
<ogra_> i wouldnt hold my breath for "landing today"
<ogra_> but there is always hope indeed :)
<sergiusens> Chipaca or mvo mind looking at https://code.launchpad.net/~sergiusens/snapcraft/printless/+merge/272101 ?
<rickspencer3> ogra_, well, if I won't get pwm today, there is no point to upgrade, I'll stick with what I have for now
<ogra_> by end of week i hope we'll have an auot-built rolling/edge image ... if that works i'll move that to 15.04 next week
<ogra_> *auto-built
<sergiusens> tedg, run in lxc/lxd or apt remove glib
<sergiusens> tedg, no one builds with glib these days anyways ;-)
<ogra_> inbetween i might do a release of 15.04 #5 for the RPi
<tedg> Doesn't systemd use glib?
<tedg> Oh, I guess this is only the dev package.
<sergiusens> tedg, yeah :-)
<sergiusens> tedg, or chose a different -dev pkg with pkg-config support :-)
<ogra_> the binary only uses the "c" version of glib
<ogra_> :P
<tedg> It seemed like the others would all pull in glib.
<tedg> Sure there's some
<mvo> sergiusens: I got some extra homework, I'm not sure I can get to it
<sergiusens> mvo, ok, I'll bug Chipaca or maybe tedg :-)
<clobrano> Chipaca: the CLA seems signed now
<rickspencer3> ogra_, I guess I should ask .. does the rpi2 current support spi?
 * rickspencer3 asks after having fully wired it together with his MCP3008
<ogra_> rickspencer3, find /sys -name '*spi*'
<ogra_> ;)
 * rickspencer3 hopes that is a "yes" :)
<ogra_> i see devices when i do that but i have no idea if the default devicetree enables any of them
<ogra_> you might need to apply an overlay for it
<rickspencer3> arg
<rickspencer3> ok, I'll have to wait a bit to try it out
<rickspencer3> will see later
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ cat  /sys/firmware/devicetree/base/soc/spi@7e2004000/status
<ogra_> disabled
<ogra_> yeah, as expected
<sergiusens> tedg, any luck with pkg-config?
<tedg> sergiusens: Still building the lxc image
<tedg> sergiusens: I'm now getting this, no clue what to do with it: http://paste.ubuntu.com/12531319/
<sergiusens> tedg, oh nice,
<sergiusens> tedg, merge trunk; the run test rework reverted a change to only mccabe check or project
<sergiusens> should be fixed in trunk again; this most likely happened after pulling in external sources
<tedg> sergiusens: Merged trunk, still got the same error
<clobrano> QUESTION: what is snappy update --automatic-reboot? How it is triggered?
<Chipaca> clobrano: what do you mean how is it triggered?
<tedg> sergiusens: Thinking let's just let tarmac give it another try.
<mvo> clobrano: we have a systemd unit that runs it every N hours
<mvo> tedg: at what point in the build do you get that?
<sergiusens> tedg, sure; did you fix anything already?
<mvo> tedg: do you use LC_ALL=C in your environment? could you try LC_ALL=C.UTF-8 instead?
<tedg> mvo: When doing "./runtests.sh"
<tedg> sergiusens: Yeah, I added the environment variable and cleaned up the long lines.
<clobrano> mvo, Chipaca: I was testing snappy, and I got a message like "another snappy is running". Does it really do an automatic reboot from time to time?
<elopio> sergiusens: tedg: what I know is that I got the same error in testtools because my locale is EO https://github.com/testing-cabal/testtools/issues/76
<tedg> mvo: Cool, that moved forward. New error :-)
<Chipaca> clobrano: unless you've disabled that, yes
<tedg> We need a release so that apt-get build-dep works again :-)
<sergiusens> tedg, hah :-)
<Chipaca> clobrano: if you're logged in when it happens, you'll get a message plus given a way to cancel the reboot
<clobrano> oh ok, I didn't see that message, yet
<elopio> ogra_: is it safe to assume that sectors will be 512 bytes?
<ogra_> elopio, i think sergiusens hardcoded that recently, so yes
<elopio> yay for sergiusens!
<sergiusens> ogra_, that's such a stron word :-P
<tedg> sergiusens: Okay, verified it works :-)
<sergiusens> tedg, \o/
<ogra_> elopio, i think sergiusens polished the code to support that recently, so yes
<ogra_> sergiusens, sounds better ?
<ogra_> :)
<elopio> it's configurable, but only one option is supported at the moment :)
<sergiusens> elopio, choose wisely!
<sergiusens> tedg, your mixing of " and ' will disturb elopio :-P
<elopio> tedg: oh yes. No beers for you on our next sprint!
<ogra_> tedg, just switch to Â» and Â«
 * tedg uses all the quotes
<bjf> i'm trying to use the doc @ developer.ubuntu.com for the rpi2 regarding "building your own image". neither example actually works
<tedg> sergiusens: I think that " is only used for shell strings...
<bjf> 1. can we clean up the examples to ones that work and 2. is there other documentation that is more up-to-date?
<sergiusens> tedg,         env.append("PKG_CONFIG_PATH=" + ':'.join([
<sergiusens> tedg, in PKG_CONFIG_PATH ;-)
<sergiusens> tedg, I can build godd again, so I don't care ... mvo and his project names ;-)
<sergiusens> tedg, building a couple of c based projects to triple check
<elopio> finally, the resize test passed again!
<elopio> bjf: can you please report bugs for the issues you are getting?
<bjf> elopio, against which package/project?
<elopio> bjf: ogra_ here is working on rpi, so he can tell you more.
<longsleep> bjf: Take a look at https://github.com/longsleep/snappy-odroidc - thats how i build my images if you want to look at working examples
<tedg> Ah, found one. Fixed it.
<elopio> bjf: https://bugs.launchpad.net/developer-ubuntu-com/
<ogra_> bjf, hmm, what exactly isnt working ?
<ogra_> (i know they did once mention versions, but we replaced that by * )
<bjf> ogra_, https://pastebin.canonical.com/140433/
<bjf> ogra_, there is a link there "from Paolo Pisati's binary build" that says it's to a device tarball but pulls down a .deb
<ogra_> bjf, well, i'm in the process to make official images, that whole section will be obsolete in a week or so
<ogra_> hmm, your paste looks like someone reverted my changes
<elopio> sergiusens: I think that on your release notes you should mention more clearly that yamls with the previous format won't work, and need to be updated.
<sergiusens> elopio, sure, feel free to write that down
<ogra_> bjf, "On this page, you will find pre-built bits to bootstrap your Raspberry Pi 2 with a Snappy image." ... there is a link in that line
<ogra_> i dont think it is wrong to mention that the device tarball includes palos kernel
<bjf> ogra_, yup and that works. i get an image that i can dd and the rpi2 will boot
<ogra_> (or to link to it)
<ogra_> could surely be phrased better
<ogra_> but as i said, will be obsolete very soon
<ogra_> we'll soon have all bits properly on the server once the linux-raspi2 package migrates out of -proposed
<bjf> ogra_, i am trying to build my own image and the instructions for doing so don't work. do you suggest i wait for a couple of weeks and try again?
<elopio> Chipaca: the 15.04 we want to release is in edge now?
<Chipaca> elopio: at this stage, i don't know
<Chipaca> elopio: it's on trunk
<Chipaca> elopio: is edge getting built from trunk?
<Chipaca> elopio: I don't know
<Chipaca> ogra_: do you?
<elopio> should be, but that something fails. Chipaca, but lp:snappy/15.04 right, not lp:snappy ?
<ogra_> bjf, didnt you just say it works ?
<bjf> ogra_, i just read it all a couple more times, maybe i see my mistake
<Chipaca> elopio: lp:snappy
<Chipaca> elopio: which should be in sync with 15.04
<Chipaca> let me just doublecheck that
<ogra_> edge is getting built from the PPA
<ogra_> wether your trunk change ends up in the PPA snappy package by default i dont know
<Chipaca> ogra_: 15.04 edge
<ogra_> yes
<Chipaca> ok
<elopio> Chipaca: right, I see the latest merge. But now I'm confused, why do we have the 15.04 branch?
<Chipaca> elopio: because they're in sync only because disruptive changes haven't landed yet
<Chipaca> elopio: and because mvo is in pre-sprint-rush so is less tidy than usual
<elopio> right. Not complaining here :)
<Chipaca> nor here
<Chipaca> elopio: trunk has two revs that are not in 15.04
<Chipaca> elopio: and we want them in the release
<Chipaca> as they're both small but nasty bugs
 * Chipaca hugs 'bzr missing'
<elopio> if I understand correctly, the recipe for lp:snappy/15.04 puts the vivid version on the ppa, which is used to build 15.04 edge. The recipe for lp:snappy puts the wily version on the ppa, which is used to build rolling edge.
<ogra_> elopio, right, someone needs to move the commits over
<elopio> Chipaca: if so, we need your update-qualified-name backported to the lp:snappy/15.04, rerun the recipe, and ask somebody to trigger and edge build.
<ogra_> and we need to decide if we should just drop lp:snappy/15.04
<ogra_> and simply use lp:snappy for both
<Chipaca> elopio: ahead of you :)
 * ogra_ would actually prefer if we did all developmennt in 15.04 
<ogra_> saves all the backporting :)
<Chipaca> elopio: https://code.launchpad.net/~chipaca/snappy/trunk-to-15.04/+merge/272140
<bjf> ogra_, i think i'm closer. i downloaded all the files "this page" pointed me at of pre-built bits. https://pastebin.canonical.com/140436/
<ogra_> bjf, hmm, is your ubuntu-device-flash outdated ?
<bjf> ogra_, ubuntu-device-flash          0.31-0ubuntu1
<elopio> wow, launchpad is really crazy
<bjf> ogra_, does it look in the current directory for what is specified by the --oem flag ?
<ogra_> it shoudl
<ogra_> bjf, the 0.15 pi2 sanp is in the store though, "--oem pi2" should work as well
<elopio> Chipaca: take a look at the recent revisions in https://code.launchpad.net/~snappy-dev/snappy/snappy
<elopio> what it shows as merged branches don't match with the rev.
<elopio> somebody will have to calm William's wrath for breaking launchpad.
<bjf> ogra_, similar error trying just "--oem pi2": pi2 failed to install: snappy package not found
<ogra_> bjf, very weird
<bjf> ogra_, indeed. feels like i have some basic misconfiguration which i don't understand
<ogra_> well, the official image was created exactly the same way
<ogra_> bjf, i'm super busy with some customer stuff, i'll take a look later and try to roll an image here
<bjf> ogra_, ack
<ogra_> (if you dont find a solution before)
<ogra_> bjf, any reason why you dont use the pre-built image ?
<bjf> ogra_, that does work... i'm trying to come up to speed so i can start testing rpi2 kernels
<ogra_> bjf, ah
<ogra_> well, you can just cp the binaries in place over the ones in /boot/uboot/b and /system-b/lib/modules as a quick fix ... then run: sudo fw_setenv snappy_ab b ... and reboot
<ogra_> (that will boot into the b system, and should reboot back into a if something fails
<ogra_> )
<elopio> Chipaca: snappy 15.04 failed to build for arm64. We don't care about that one, right?
<ogra_> nope
<ogra_> definitely not on 15.04
<elopio> ogra_: can you kick 15.04 edge to pull this version?
<ogra_> not yet
<ogra_> waiting for a few other changes before i can build an image
<ogra_> but yeah, as soon as i can
<elopio> ogra_: cool. Let me know.
<elopio> sergiusens: what you want to release is snapcraft from trunk, or snapcraft from the tools-proposed ppa?
 * Chipaca hugs elopio 
<elopio> :D
<ogra_> Chipaca, elopio, image build kicked off
<elopio> dholbach: I think you send the wrong date on your clinic invitation.
<elopio> dholbach: really cool idea btw, thanks.
<dholbach> elopio, sent an update
<dholbach> Jeff Lane noticed the same
<dholbach> sorry, mail was in the moderation queue
<sergiusens> elopio, snapcraft - 0.2-0~207~ubuntu.* which is building now
<sergiusens> elopio, build is done; I'm doing a test build of all the example packages
<rayn> hello there. Cant find a way to edit files, like in nano. Is there an editor?
<plars> ogra_: does the boot process on rpi2 read snappy-system.txt at any point? I'm not seeing where it does, but if not, I'm confused how it knows whether to use snappy-a or snappy-b
<ogra_> plars, out of uboot.env
<ogra_> snappy-system.txt is obsolete
<ogra_> rayn, there is vi
<plars> ogra_: oh! that could mess me up I guess
<plars> ogra_: so if I'm booting snappy from a usb stick, is it going to rewrite the one on the mmc or on the usb stick?
<ogra_> plars, it is like that since the 15.04 #4 release ... i.e. like 8 weeks ago (or was it more) for all arm boards
<plars> ogra_: It just recently started mattering for me, due to looking at how to automate rpi2
<ogra_> it is going to rewrite the one in /boot/uboot/a|b
<ogra_> the rewriting happens from a systemd job
<plars> ogra_: ok, so it's going to rewrite the one on usb, which is safer, but I'm not going to be able to see those changes
<rayn> ogra_ thanks
<ogra_> fw_printenv will show them
<ogra_> we ship it
<ogra_> (and you can modify them with fw_setenv if needed)
<plars> ogra_: I'm not sure how that will help me unfortunately :(
<plars> but thanks
<plars> this may just be a limitation on rpi for now
<ogra_> it is like that on all arm installs now
<elopio> sergiusens: I've verified all the points on your release notes. I'm happy with this release.
<plars> ogra_: well, on bbb we have two places to boot from, so it's fine
<elopio> and tomorrow we'll get many new eyes to catch interesting bugs for 0.3
<plars> ogra_: but on rpi2 we have to fake it
<sergiusens> elopio, yup; ok now I need confirmation from asac ;-)
<sergiusens> well I guess he already knew :-P
<elopio> sergiusens: we can blame him when things are on fire because he missed the stand up ;)
<asac> sergiusens: whats the one line summary of what i knew? :)
<sergiusens> asac, looking good (is that a valid summary?)
<elopio> sergiusens: could you push a new version to the store for a package with no alias?
<sergiusens> elopio, which package?
<elopio> sergiusens: anyone from our examples.
<elopio> but please tell me before you do it so I can check.
<sergiusens> elopio, examples from snapcraft?
<elopio> sergiusens: no, like hello-world and those. I'm not sure which have alias.
<elopio> I just need one with no alias to show me an update.
<sergiusens> elopio, oh, it is easy to check
<sergiusens> elopio, but why not upload hello-world to your own account?
<sergiusens> elopio, unless you are talking about an automated tests
<elopio> sergiusens: no, I think that will work.
<elopio> let me play with my own account.
<sergiusens> elopio, it should :-)
<elopio> Chipaca: I installed 15.04 alpha #179 and it seems to lad the ppp service properly. But after updating #178 to #179, it shows the same bug.
<elopio> s/lad/load
<Chipaca> grmbl
<elopio> hum, what's the command to update one snap?
<elopio> I think I've never tried that.
<Chipaca> elopio: there isn't one
<Chipaca> elopio: not from the commandline
<sergiusens> elopio, I don't think you can
<sergiusens> elopio, well, you can try and install it again
<Chipaca> elopio: you can via the REST API though :)
<elopio> yeah, the problem is that if I'm in #178 and do snappy update, it will go to #179 instead of updating the snap.
<Chipaca> elopio: rest api rest api
<elopio> so I can't confirm the problem. But I could update hello-world on #179. Is that good enough Chipaca?
<Chipaca> no
<Chipaca> because hello-world has an alias
<Chipaca> :)
<Chipaca> or :-(
<elopio> Chipaca: not the one I'm using. hello-world.elopio.
<Chipaca> ah, ok :)
<Chipaca> then yes :)
<Chipaca> elopio: "list -u" is also broken before
<Chipaca> elopio: ie it doesn't show an update for a non-aliased package
<Chipaca> elopio: and the broken part is the same between that and update
<elopio> ok, let me try that.
<Chipaca> elopio: otherwise echo '{"action":"update"}' | uPOST /1.0/packages/hello-world.elopio
<Chipaca> for funky values of uPOST
<elopio> #178 doesn't show the update. #180 shows it. All good.
<elopio> so, the two bugs are fixed. But for the ppp one, it will remain failing if you are updating from our previous stable.
<Chipaca> elopio: is that even if you haven't touched the config?
<elopio> Chipaca: the only thing I did was systemctl status.
<elopio> I restarted the service in #180 and now it seems fine.
<jdstrand> whoever implemented 'snappy service', kudos!
<jdstrand> asac: feel free to pass that along :) ^
<jdstrand> it works great and is super helpful
<sergiusens> Chipaca, ^
<Chipaca> jdstrand: and it's not finished yet!
<jdstrand> I can't wait to see the new stuff :)
<Chipaca> jdstrand: it should give you service and security logs
<jdstrand> oh, nice indeed
<jdstrand> I think it has service logs already, no?
<jdstrand> or is that different?
<Chipaca> ah, yes, just not in 'status'
<Chipaca> original request was to have all that in status output
<jdstrand> I see
<Chipaca> but i think it'd be messy unless you're asking about a particular service
<Chipaca> anyway, thanks :)
<jdstrand> Chipaca: re messy: fwiw, I like the separate logs command for that reason. status is different than logs imho
<Chipaca> oh, it wouldn't replace the separate logs, just give you a snippet if you've got space
<Chipaca> *handwaving intensifies*
#snappy 2015-09-24
<zyga> morphis: hey
<morphis> zyga: hey!
<fgimenez> good morning
<dholbach> hello hello from mvo's place :-)
<clobrano> morning :)
<ogra_> moinsen
<Odd_Bloke> Morning all.
<Odd_Bloke> We have a fix for cloud-init for snappy on Azure; where in the normal Ubuntu development lifecycle does this have to get for edge builds to pick it up?  Will an upload to wily be sufficient?
<ogra_> Odd_Bloke, stable pulls from the official vivid archive (incl. sercurity and updates) and from https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<ogra_> s/stable/15.04/
<ogra_> rolling pulls from wily
<Odd_Bloke> ogra_: Cool, thanks. :)
 * guest42315 they see me rollin' la la la
<ogra_> uh
<ogra_> my snapcraft build doesnt build anymore
<ogra_> Branched 4 revisions.
<ogra_> [1mIssues while validating snapcraft.yaml: [{'exec': 'usr/bin/bipmkpw', 'name': 'bipmkpw'}] is not of type 'object'[0m
<ogra_> Traceback (most recent call last):
<ogra_> what does that mean ?
<ogra_> did the definition for "binaries"  change since yesterday ?
<mvo> ogra_: I think so :/
<ogra_> where is that documented then ?
<mvo> ogra_: where is your project? could you push it somewhere?
<mvo> ogra_: I hope in the snapcraft docs of the branch
 * ogra_ is happy to make changes as long as he knows which :P
<ogra_> mvo, not really, thats onle the generic stuff from the website
<mvo> ogra_: binaries:\n  name: foo -> changes to binaries:\n  foo:\n    exec: foo"
<mvo> ogra_: if you push your stuff I can have a look and help with the diff
<mvo> ogra_: if its not documented we need to fix that too :/
<ogra_> well, the docs dir in the snapcraft tree has exactly the two pages we have on developer.u.c
<ogra_> not sure there are other docs hidden anywhere
<ogra_> bah, and the services description changed too it seems
<ogra_> ah, got it by blindly poking around
<ogra_> (and by looking at the schema file)
<ogra_> and hello snappy-bip !
<JamesTait> Good morning all; happy Thursday, and happy Punctuation Day! ð
<Chipaca> JamesTait: instead of punctuation day today I'm celebrating I've been a dad officially for 11 years and haven't killed anybody yet \o/
<JamesTait> ð
<ogra_> congrats to the calmness !
<JamesTait> Chipaca, that definitely is cause for celebration!
<JamesTait> Is there cake?
<Chipaca> there is not. Because the boys are in France on a school trip.
<Chipaca> \\\\\o//////
<clobrano> ;D
<davmor2> for the last 11 years no wonder you haven't killed them
<Chipaca> instead i can stay hacking until 4am and not have to get up at 6 to kickstart their day :)
<Chipaca> davmor2: har :)
<Chipaca> davmor2: just this week :)
<Chipaca> davmor2: for several of those years i couldn't afford the milk they needed, let alone fancy schmancy france :)
<Chipaca> well. maybe it was a couple of months. felt like years :)
<davmor2> Chipaca: hahaha
<Chipaca> kas1000, wherever you are, i hope your rabbits are all dead
<Chipaca> clobrano: thanks to your branch we found we were misfiling the CLA emails, so double thanks for that :)
<clobrano> :D, I find also bugs I am not even looking for
<Chipaca> clobrano: reviewed!
<Chipaca> clobrano: needs fixing, but good job
<Chipaca> clobrano: (i wouldn't be surprised if you told me the code you're replacing suffers from the same problems i called out in your code, fwiw)
<Chipaca> clobrano: another alternative would be to write a couple of variations of the AtomicWrite helper, one for append, one with a line-at-a-time interface
<Chipaca> or maybe write a whole atomic-writable type that did the whole dance behind the scenes
<clobrano> Chipaca: I'll have a look at it ;)
<Chipaca> clobrano: fwiw I think you should do as i suggested in the review
<Chipaca> clobrano: the other things can be done in later branches
<clobrano> Chipaca: ook
<Chipaca> clobrano: sorry if the "atomic-writable file type" sounded very exciting
<Chipaca> :)
 * Chipaca would be tempted too
<Chipaca> but that's how branches get un-reviewable
<clobrano> :D
<clobrano> well, actually I thought about using AtomicWriteFile, but I misinterpreted the description and didn't look at the code well
<Chipaca> asac: ricmm: http://chipaca.com/post/129773078277/talking-http-to-an-abstract-unix-socket fwiw
<Chipaca> asac: ricmm: as people trying to use the rest api have stumbled on this a bit
<Chipaca> clobrano: https://github.com/dchest/safefile fwiw :)
<Chipaca> pitti: when you have a bit of time, i've got a systemd question just for you
<Chipaca> pitti: not urgent, not work related
<Chipaca> trying to start a user unit on a udev event; have gotten the device to show up, but the user unit doesn't
<pitti> Chipaca: what is your udev rule?
<pitti> Chipaca: we do that quite a lot, usually through something like ..., ENV{SYSTEMD_WANTS}+="my_unit.service"
<pitti> Chipaca: for those (SYSTEMD_WANTS) you need to add TAG+="systemd" so that systemd creates a .device unit for it
<pitti> Chipaca: or you can call systemctl start --no-block in a RUN rule directly too, of course
<Chipaca> pitti: sorry, xchat crashed and missed that, let me pastebin the bits i have
<Chipaca> pitti: this is 99-batteries.rule: http://pastebin.ubuntu.com/12541325/
<Chipaca> pitti: which results in
<Chipaca>  sys-devices-LNXSYSTM:00-LNXSYBUS:00-PNP0C0A:01-power_supply-BAT1.device                   loaded active plugged   /sys/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0C0A:01/power_supply/BAT1
<Chipaca> pitti: and this is cbatticon@.service: http://pastebin.ubuntu.com/12541330/
<Chipaca> pitti: i tried with BindTo=%i.device also, and didn't have it work
<pitti> Chipaca: BindTo= doesn't exist, you probably mean BindsTo=
<pitti> Chipaca: but what is that supposed to do? the After= should already be implied
<Chipaca> pitti: the internets told me to do it!
<Chipaca> couldn't find documentation that mentioned BindTo
<pitti> Chipaca: WantedBy= also seems redundant/unnecessary as you start this from an udev rule, not from a target
<pitti> Chipaca: man system.unit
<pitti> Chipaca: but aside from these nitpicks, what does it do? if you plug in the battery, what does systemctl status -l .. show?
<pitti> Chipaca: i. e. does it get activated and fail, or not activated at all, etc?
<Chipaca> pitti: it never shows up in systemctl --user status
<pitti> Chipaca: why would it be in --user?
<Chipaca> pitti: because SYSTEMD_USER_WANTS?
<pitti> you start it through udev, that's system
<pitti> Chipaca: oh sorry, I thought that's SYSTEMD_WANTS
<Chipaca> pitti: the device unit does show up, as above
<zyga> hey everyone
<guest42315> QUESTION: what's the difference between snaps and clicks?
<morphis> hey!
<zyga> we're building a small experimental framework
<zyga> we're (morphis and me) using bluez 5.34
<pitti> Chipaca: ok, then I don't have an off-hand answer, I'm afraid
<ogra_> yay, bluez support !
<zyga> if anyone is interested to follow us, the code is currently in https://git.launchpad.net/~zyga/+git/snap-manual-bluez5/tree/
<Chipaca> guest42315: you can think of snaps as clicks v2
<zyga> ask us questions about this anytime if you are interested
<pitti> Chipaca: "systemd-analyze set-log-level debug", and watching the journal while you plug in the battery might be insightful
<Chipaca> guest42315: also, HELLO, why the QUESTION format? :)
<ogra_> click is in "maintenance mode"
<ogra_> snap is actively going forward
<zyga> morphis: passing bt via -bt hci,host didn't work
<zyga> morphis: I'll try -bt hci,null
<morphis> zyga: for too
<zyga> morphis: just to see if there's anything on the inside
<morphis> fails with a: qemu: `hci0' not available
<zyga> morphis: for too?
<guest42315> Chipaca, oh, is not live yet?
<zyga> morphis: oh, where did you see that
<Chipaca> pitti: found BindsTo, dunno why i was reading it as BindTo all the time (and unable to find it like that)
<zyga> morphis: in my branch I have redirected qemu lots
<zyga> logs*
<zyga> morphis: so that they don't spam the terminal
<zyga> morphis: but  Ididn't see anything about hci
<zyga> (I think)
<Chipaca> guest42315: 12:30 utc is in 17 minutes
<zyga> morphis: trying now with: qemu-system-x86_64 -m 768 -nographic -snapshot -redir tcp:8022::22 -bt hci,null kvm.img >qemu-serial.log &
<guest42315> oh, soon then
<guest42315> so Chipaca  .. what would be the name for v3? v1 is clicks, v2 is snaps,
<zyga> guest42315: claps ;)
<Chipaca> guest42315: pops
<Chipaca> guest42315: poofs
<guest42315> no no no
<Chipaca> guest42315: booms
<Chipaca> guest42315: kapows
<Chipaca> probably not "no no nos", no
<JamesTait> Cracks
<guest42315> ^^ +1
<JamesTait> As in "I'm addicted to updating, I just have to have the latest Crack."
<guest42315> hehe
<zyga> JamesTait: heh :)
<Chipaca> or maybe we sell out and call it the Big CoproporationTM Asynchronous Atomic Secure Boring System And Package Maintenance Agent, or bcaasbsapma for short
<guest42315> home edition?
 * Chipaca would not put any chits on that number
<Chipaca> guest42315: the home edition would let you use more than one core at a time!
<Chipaca> guest42315: for only 99 a month more
<guest42315> :)))
<guest42315> 10 min left
<dholbach> yep :(
<dholbach> :-)
<morphis> zyga: problem solved, do a sudo hciconfig hci0 up
<Chipaca> dholbach: you have people queueing up to see you. It's the price of fame I'm afraid.
<morphis> but before: systemctl stop bluetooth
<dholbach> Chipaca, they all want to see sergiusens
<Chipaca> dholbach: ah. So you're the bass player in the group, I see.
<JamesTait> Drummer. ð
<zyga> ohh
<zyga> I'm such a dummie
<zyga> I kept running the old snap :)
<zyga> morphis: so what is that with host or null?
<morphis> with host
<morphis> push a chnage in a minute
<Chipaca> pitti: do i have to "enable" the @.service, or is that automatic?
<dholbach> Chipaca, JamesTait: works for me - hip hip chin chin to the rhythm section
 * JamesTait is the roadie or something.
<morphis> zyga: pull
<zyga> morphis: nice!
<morphis> we could also use vhci support if we want
<zyga> morphis: trying
<zyga> morphis: what is vhci exactly?
<morphis> qemu seems to have support for that
<morphis> a virtual HCI device
<pitti> Chipaca: no, if you start it from udev you don't want/need to start it at boot (which is what enabling does -- you say that some target that is already started at boot pulls in that)
<zyga> morphis: is it a totally virtual bt
<morphis> yes
<zyga> morphis: or some sort of sharing from the real one
<zyga> morphis: can we boot two qemu boxes
<morphis> no, totally virtual
<zyga> morphis: and have them talk over those virtual bts?
<morphis> never tried that
<zyga> I'll check that passthrou works
<zyga> morphis: what do we do next if this works?
<morphis> zyga: verify if we find any available bluetooth devices :)
<zyga> morphis: ok, let's see
<morphis> doing that already
<zyga> morphis: mine stil boots
<morphis> hm
<morphis> why doesn't the bluetooth device appear
<zyga> morphis: is it possible that we need udev rule for something
<morphis> it isn't in /sys
<morphis> that is where it should be
<morphis> there is no bt device in 7dev
<zyga> morphis: where should it be in /sys/ ?
<zyga> sys/class/hci or somethingf?
<zyga> (slow slow slow)
<morphis>  /sys/class/bluetooth
<guest42315> QUESTION: can i install snappy on my home router?
<zyga> morphis: yep, it is empty
<dholbach> just about to start
<zyga> morphis: any modules we might be missing?
<guest42315> live
<zyga> morphis: what does your systemctl status say? mine says degraded
<ogra_> yay
<guest42315> wave o/
<yashi_> live :)
<guest42315> install snappy on a toaster! live
<morphis> zyga: rebooting ..
<davidcalle> o/
<zyga> morphis: where do logs go? syslog or dedicated
<morphis> zyga: that is what I am not sure about
<morphis> trying to figure out how this bt forwarding works
<ogra_> journalctrl or syslog
<ogra_> (both atm)
<guest42315> starcraft?
<ogra_> snapcraft is our start, yes
<ogra_> *star
<ogra_> :)
<guest42315> :D
<morphis> zyga: some documentations says only the M800, M810 qemu machine type has a emulated hci ctrl
<zyga> morphis: I think the mistake is that we switch off bluez on the host
<zyga> morphis:     (bluez only) The corresponding HCI passes commands / events to / from the physical HCI identified by the name id (default: hci0) on the computer running QEMU. Only available on bluez capable systems like Linux.
<morphis> "The Transport Layer is decided by the machine          type.  Currently the machines "n800" and "n810" have one HCI and         all other machines have none."
<zyga> morphis: it seems that the actual hardware says on the host, what happens is tha the gues just sees some events injected by qemu?
<morphis> no
<zyga> morphis: ok, let's try USB pass-thru
<morphis> the host interface needs to be on
<zyga> morphis: that works for sure (we used it)
<morphis> qemu will forward all HCI commands to the enabled host interface
<noizer> Is there an gui for snappy?
<ogra_> noizer, only a web gui for the store atm
<noizer> When will there an release with a gui?
<morphis> zyga: looks like the missing emulated device in qemu is the reason
<zyga> morphis: I think you are right
<guest42315> and a snap scope? on the phone?
 * zyga looks at how to identify the right bt device to use
<morphis> zyga: so usb forwarding ..
<ogra_> noizer, planned for the future, but the focus is currently headless ... once that is 100% solid there will be UI bits on top (essentially anything that can use Mir/XMir
<ogra_> no ETA yet though
<ogra_> guest42315, i thinnk that exists already (but doesnt do much, needs snap integration on the bottom layer)
<morphis> zyga: look at /sys/class/bluetooth/hci0/device/uevent
<morphis> gives you PRODUCT=
<zyga> morphis: lsusb
<guest42315> ogra_, yeah someone posted a video on youtube, if i remember correctly
<zyga> morphis: for me that says Bus 004 Device 003: ID 0a5c:2145 Broadcom Corp. BCM2045B (BDC-2.1) [Bluetooth Controller]
<morphis> or that way
<zyga> morphis: then I just add     -usb -device usb-host,hostbus=4,hostaddr=3 \
<zyga> morphis: testing now
<zyga> morphis: needs sudo :)
<morphis> is a bit more complex here
<morphis> connected over an internal hub
<zyga> morphis: how?
<rbasak> mvo wrote a God daemon? :)
<ogra_> rbasak, to make snappy rule the world ;)
<ogra_> it is confined though
<zyga> morphis: I removed the hci up and service shut-down
<morphis> zyga: do I have to leave the port number just out when setting up the forwarding?
<zyga> morphis: not sure if that's needed
<morphis> zyga: you need to unload the bluetooth driver your system has loaded
<zyga> morphis: port number for tcp redirects?
<morphis> btusb normally
<morphis>     |__ Port 11: Dev 13, If 0, Class=Wireless, Driver=btusb, 12M
<zyga> (booting now, we'll see shortly)
<zyga> morphis: for wifi we did not touch any modules
<zyga> morphis: maybe bt is different, let's see what I get
<ogra_> staging the stage
<sergiusens> staging phase
<dholbach> :)
<willcooke> thanks dholbach
<carif_> uoa question: are the sections/stanzas for the .yaml file described in detail somewhere?
<ogra_> carif_, there si a schema file in the snapcraft source that is supposed to be turned into a proper doc
<zyga> morphis: success
<zyga> morphis: it worked!
<morphis> yeah!
<morphis> didn't get my usb device forwarded yet
<carif_> ogra_, ty
<zyga> morphis: I'll push my setup
<ogra_> carif_, http://bazaar.launchpad.net/~snappy-dev/snapcraft/core/view/head:/schema/snapcraft.yaml
<ogra_> there will be a proer example snapcraft.yaml based on that
<ogra_> *proper
 * guest42315 witchcraft
<yashi_> uoa: it's very nice to see that snapcraft pulls all dependencies for you
<zyga> morphis: but I can already see that confinement aside this really works
<morphis> zyga: yeah!
<morphis> zyga: next things:
<morphis> run bluetoothctl
<morphis> > power on
<morphis> > scan on
<morphis> waiting for devices being found
<zyga> morphis: works
<zyga> morphis: I see my speaker!
<morphis> wow!
<zyga> morphis: it works :D
<zyga> haha
<zyga> nice
<yashi_> uoa: any reason why libgthread is not listed in snap: section?
<zyga> how long did it took us?
<zyga> :D
<morphis> zyga: you have some LE device?
<zyga> o/
<zyga> morphis: no, I don't :-(
<morphis> zyga: half a day :)
<morphis> zyga: I have one
<zyga> morphis: amazon links appreciated
<zyga> morphis: test it!
<morphis> search for TI sensortag
<morphis> zyga: let me get some lunch first
<pratt> QUESTION: do the asterisks at the end of the file names in the yaml file have significance?
<morphis> zyga: would be great if you can help until I am back with how to forward my usb device the right way: http://paste.ubuntu.com/12541750/
<zyga> morphis: ok
<morphis> it's: |__ Port 11: Dev 13, If 0, Class=Wireless, Driver=btusb, 12M
<zyga> morphis: lsusb?
<carif_> UOA question: can I use language packages as parts, e.g. python pip packages?
<zyga> morphis: you can try both
<morphis> just using bus=1 and addr=13 didn't worked
<zyga> morphis: look at my branch, I used sudo as well
<zyga> oh
<zyga> hmm
<ogra_> carif_, i thnk you can
<morphis> zyga: oh wonder
<morphis> with your changes it just seem to work
<morphis> lets wait until the device has booted
<morphis> zyga: you have another BT Usb dongle?
<morphis> zyga: or an Ubuntu phone?
<carif_> yup, that answered it, ty
<zyga> morphis: yes
<zyga> morphis: both :)
<zyga> morphis: what do you have on your mind?
<morphis> setting up a GATT service
<zyga> morphis: though the dongle I have is ancient, it's not 4.0
<morphis> ah
<zyga> morphis: my desktop has 4.0 though
<zyga> morphis: it's pretty fresh
<zyga> morphis: and I also have the phone
<morphis> that is the one used in the vm?
<zyga> morphis: (all kinds)
<zyga> morphis: no, the one in the VM is whatever my thinkpad x200 has
<zyga> morphis: BCM2045B
<zyga> morphis: though I can boot the KVM image on another machine
<carif_> lol
<zyga> morphis: so what would be the best target to try
<morphis> zyga: great
<morphis> zyga: bluez-5.34/tools/gatt-service.c is the one you need to run there
<morphis> with bluetoothd running
<pratt> QUESTION: could you go into more detail about stage-packages?  i don't understand whether you have to have them or they are helpful but optional
<ogra_> pratt, the stage dir is always there ... not always used for packages though, it is just the place wheer all bits are collected for later consumption
<zyga> morphis: it's not built by the current config, trying to build it explicitly
<morphis> zyga: http://paste.ubuntu.com/12541848/
<yashi_> QUESTION: does `snapcraft run` can run ARM instance on amd64 host?
<ogra_> not yet, no
<morphis> zyga: that is my small LE key finder
<zyga> :)
<zyga> morphis: let me try something like that
<ogra_> snapcraft also can not cross build yet, you need to run it in an arm chroot or on arm HW
<pratt> thanks!
<morphis> so, now its really time for lunch
<zyga> morphis: later on you have to tell me what's the right comand sequence
<zyga> morphis: pair vs connect
<zyga> morphis: http://pastebin.ubuntu.com/12541867/
<zyga> morphis: I had to fiddle with on/off button on the device to make it discoverable
<sergiusens> https://wiki.ubuntu.com/Snappy/Parts
<longsleep> Is there any news for building multi-arch snaps with snapcraft?
<ogra_> longsleep, not yet, nope
<yashi_> QUESTION: .snap packages are mean to be self contained, meaning there shouldn't be any dependecies like .debs.  What is the current plan to support basic libraries like libc or libz for dependecies from existing C applications?  Are we gonna have API versions/levels like Android?
<rbasak> Debian policy says "Packages must not require the existence of any files in /usr/share/doc/ in order to function [115]."
<rbasak> So perhaps it is acceptable for snappy to default to exclude that by default since it is guaranteed to not break anything.
<ogra_> rbasak, well ...
<ogra_> rbasak, debs often ship the copyright file in there ... if your snap includes deb binaries you will likely want at least the copyrigth to persist
<rbasak> I imagine that maintaining copyright and licensing information should be part of a separate process
<ogra_> why ?
<yashi_> ah, ok.  so apps should target to an lts release?
<rbasak> As debs are only once source of files being delivered, and one that happens to embed this information. What about the others?
<ogra_> if you have existing copyright files there is no need to re-write that or copy it around
<carif_> uoa question: so to clarify, I make a .snap with snapcraft and i install a .snap with snappy. 'snapcraft run' fires up a container and 'snap install' s the snap, right?
<ogra_> rbasak, well, for other projects the mechanism they actually use is used ... i.e. make install
<rbasak> Need to define some way to pull those in and present the information to the end user. When grabbing from debs grab the copyright file (only), when grabbing from other sources then use what is defined for that (or from the main yaml file or whatever). Then consolidate all of that into one place.
<ogra_> rbasak, there are no plans to "present" it
<T-mon> Hello! Is there a snapcraft part type for qmake-projects?
<ogra_> rbasak, but we need to chip it in the snap
<ogra_> *ship
<rbasak> If shipping it in the snap is how you define "present" it, then that's fine.
<rbasak> Wiki parts seem like a really neat way to make it easy for snappers to share parts. Good job to whoever came up with that :)
 * ogra_ would like to see /usr/share/doc/ contents gone btw ... since its a waste of space ... 
<ogra_> but we have to keep the copyright file there
<thibautr> Is there a list of all the project types supported by snapcraft?
<rbasak> My point is that you don't have to keep it *there*. As long as you ship it.
<ogra_> sure, but that would mean more modification
<rbasak> Forget usr/share/doc. It makes no sense to a snap consumer anyway, since they aren't seeing things on a per-package basis.
<ogra_> (in the course of deleting content from the dir it could indeed copy the copyright file someweher else)
<carif_> dholbach, mvo, sergiusens, ty for uoa tutorial
<dholbach> thanks a bunch everyone!
<yashi_> thanks!
<willcooke> thanks
<sergiusens> carif_, no problem, was a pleasure
<ogra_> thibautr, there is a doc planned (not sure if early work exists already) ... sergiusens ?
<sergiusens> thibautr, I intend to add this to snapcraft's cli, but for now all plugins are defined in /usr/share/snapcraft/plugins
<sergiusens> ogra_, yes there is a doc planned being written as we speak which will eventually go into developer.u.c
<ogra_> \o/
<sergiusens> s/as we speak/as we write and read/
<ogra_> moar docs !!
<ogra_> do we have a qmake type yet ?
<mvo> thanks, yeah, it was a pleasure!
<ogra_> (see T-mon''s question above)
<sergiusens> ogra_, I answered live about that
<ogra_> oh
 * ogra_ missed that 
<sergiusens> repeating just in case, there is no qmake type for a part but we are glad to help you write one if you feel like it :-)
<yashi_> sergiusens: about api level, is there anyway to specify which release an app is targetting to?
<ogra_> no
<ogra_> well, in the sotre there is ... but not inside the snap
<ogra_> *store
<beuno> right, and the store makes sure the right release gets the right snap
<yashi_> ogra_, beuno: i see
<yashi_> how about dynamic load module?  many code specify absolute path for dlopen, does snappy has any trick for that?
<ogra_> you would have to patch the source for that i fear
<ogra_> to read the path from the execution env
<Saviq> sergiusens, snapcraft tries to download from http://.archive.ubuntu.com here
<Saviq> where does it try to take the country bit from?
<sergiusens> Saviq, I fixed that, geoip
<sergiusens> Saviq, just need to do an interim release :-/
<Saviq> kk
<ogra_> sergiusens, btw, i copied your 0.2 around in the daily PPA for the other releases, cjwatson needed that for LP
<sergiusens> Saviq, already in trunk, will land soon in tools-proposed and makes it way to tools as soon as we go over validation; ftr bug #1499158
<ubottu> bug 1499158 in Snapcraft "geoip does not work on launchpad servers" [Critical,New] https://launchpad.net/bugs/1499158
<plars> sergiusens: ah, I was just going to ask about the _get_geoip_country_code_prefix() failure, is there a quick workaround?
<sergiusens> plars, build from trunk :-)
<plars> sergiusens: I'll re-pull thanks
<Saviq> error while executing external command kpartx -ds 15.04.img: device-mapper: remove ioctl on loop0p5 failed: Device or resource busy
<Saviq> loop deleted : /dev/loop0
<Saviq> any idea about â? this was snapcraft run, and AFAICT after that it's stuck trying to ssh in
<sergiusens> Saviq, oh, not that again :-) bug report please; also provide me your working dir
<sergiusens> Saviq, it's u-d-f failing to unmount the image; so it is either something missed closing it's file descriptor (seems to be trendy these days) or the kpartx unmount bug
<sergiusens> also mention the release please
<Saviq> sergiusens, whole working dir? there's the image in there now, too
<Saviq> wily, fwi
<Saviq> w
<sergiusens> Saviq, k; yeah I don't need curdir/pwd
 * sergiusens needs a wily instance
 * sergiusens thinks of elopio triaging Saviq's bug :-)
<Saviq> sergiusens, bug #1499376
<ubottu> bug 1499376 in snapcraft (Ubuntu) "snapcraft run stuck after device busy error" [Undecided,New] https://launchpad.net/bugs/1499376
<yashi_> ogra_: thanks :-)
<T-mon> Hello! Just a quick question...I hope! I'm using sqlite3 in my snapp and I save my db in $SNAP_APP_DATA_PATH
<T-mon> but this works only if I use security-template: unconfined
<T-mon> which is not allowed for the store
<T-mon> which template do I have to use for sql?
<T-mon> do I have to write my onw apparmor file?
<ogra_> that shouldnt be depending on the template at all if whatever uses the db is in the same snap and knows the right path
<ogra_> all your binaries should be able to read and write stuff underneath $SNAP_APP_DATA_PATH
<T-mon> yes, for the settings this works
<T-mon> my service says:  LogEngine: Opening logging database "/var/lib/apps/guh.sideload/0.1.4/guhd.log"
<ogra_> so drop the unconfined template and watch syslog/dmesg for the exact denials
<sergiusens> T-mon, as ogra_ mentions it should all just work if in the right data paths, sqlite should just work
<ogra_> unless some binary does calls outside of the snap env and seccomp blocks it or so
<Chipaca> T-mon: emphasis on should :)
<Chipaca> T-mon: logs, and we can fix it for you and/or for everyone
<ogra_> yeah
<T-mon> hmm...I'getting following error:audit: type=1326 audit(1443096021.115:672): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=1861 comm="guhd" exe="/apps/guh.sideload/0.1.4/usr/bin/guhd" sig=31 arch=40000028 syscall=207 compat=0 ip=0x7654e836 code=0x0
<T-mon>  
<sergiusens> right, but sqlite has no magic last I saw; unless whatever wrapping lib wants to do something special
<sergiusens> ah, seccomp
<ogra_> use sc-logresolve
<ogra_> that translates it a bit :)
<ogra_> (at least it lets you know what syscall=207 refers to in human speak)
<T-mon> ok, I have to rebuild the snapp, just a moment :)
<Chipaca> T-mon: sudo sc-logresolve /var/log/syslog
<Chipaca> T-mon: should do it
<ogra_> yeah
<ogra_> do you even need /var/log/syslog in that line ?
<jdstrand> mvo: hey, I know you're busy, but if you could express an opinion on the bug in https://bugs.launchpad.net/snappy/+bug/1499109 it would help my doc writing
<ubottu> Launchpad bug 1499109 in Snappy "hw-assign and oem assign are inconsistent" [Undecided,New]
<Chipaca> ogra_: if no file specified, stdin
<ogra_> ah
<Chipaca> ah
<Chipaca> no
<Chipaca> ogra_: no :)
<ogra_> heh
<jdstrand> mvo: basically, they work differently. at one point, that was by design iirc, but then a commit came in that made me think they were supposed to be aligned
<Chipaca> ogra_: If <logfile> is unspecified, use '/var/log/syslog'. If <logfile> is '-', use <stdin>.
<ogra_> yeah
<ogra_> i thinnk i ran it before without any option
<jdstrand> mvo: I guess depending on what you say, there is a third option: "Won't Fix" :)
<T-mon> audit: type=1326 audit(1443105156.359:695): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=3040 comm="guhd" exe="/apps/guh.sideload/0.1.4/usr/bin/guhd" sig=31 arch=40000028 syscall=207(fchown32) compat=0 ip=0x76592836 code=0x0
<T-mon> once I started the service with unconfined, and the log file exists
<T-mon> it worked even without the security template
<T-mon> then I deleted the log file and I got the Bad system call again
<jdstrand> T-mon: chown isn't allowed because there isn't a reliable uid to chown into
<sergiusens> well, unconfined is unconfined
<mvo> jdstrand: sure, I have a look, in a meeting right now
<jdstrand> T-mon: at some point we will provide an optional uid to snaps
<jdstrand> mvo: it isn't urgent-- just want to have the doc bits in place by eow/next week
<mvo> jdstrand: hm, " * adds a generic apparmor write-path for all devices (ie, /dev/**)" sounds wrong indeed
<T-mon> if the service creates the log file, why he has to change the ownership?
<jdstrand> mvo: well, remember, the launcher looks for that 'needle' string. if it finds it, it uses cgroups for access to /dev, otherwise it uses apparmor
<jdstrand> *only* apparmor
<jdstrand> T-mon: logically, you are right, it shouldn't have to. you'll have to look at the code to see what it is try to do
<ogra_> T-mon, does guhd have a config file where you can define a user ? perhaps set that to root
<ogra_> (if it checks for ownership before the chwon that might be enough)
<jdstrand> mvo: (so adding /dev/** to the override is correct if we want to use cgroups)
<mvo> jdstrand: yeah, I am remembering the details now
<T-mon> jdstrand: https://github.com/guh/guh/blob/master/server/logging/logengine.cpp#L44
<T-mon> ogra_: guhd is a service, I checkd the userid and it will always be started as root
<ogra_> ah, k
<jdstrand> mvo: no worries-- I am pulling all that up from deep swap trying to document it :)
<mvo> jdstrand: right, I re-read this and I think we need to go with option (2), i.e. make it consitent with the oem snap.
<jdstrand> mvo: btw, sorry for all the hw-assign bugs-- in documenting it I found a few things
<mvo> jdstrand: just the opposite, thanks a lot for finding the issues!
<jdstrand> mvo: ok, well, think about it and respond whenever
<jdstrand> I'll keep an eye out for it and adjust the doc accordingly
<elopio> sergiusens: Saviq: I think it's the same as https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1496484
<ubottu> Launchpad bug 1496484 in goget-ubuntu-touch (Ubuntu) "device-mapper: remove ioctl on loop0p5 failed: Device or resource busy" [Undecided,New]
<elopio> it happens sometimes here. Less often than last week.
<sergiusens> elopio, Saviq then I need to run u-d-f in a debug mode I have and see if the latest and greatest from snappy has a dangling fd
<sergiusens> we already had these issues
<elopio> sergiusens: Saviq: and it is also https://bugs.launchpad.net/ubuntu/+source/goget-ubuntu-touch/+bug/1473333
<ubottu> Launchpad bug 1473333 in goget-ubuntu-touch (Ubuntu) "exits with zero on error" [High,Confirmed]
<elopio> if udf exits with != 0, snapcraft run wouldn't try to ssh into the vm.
<rickspencer3> can anyone tell me where to find a list of existing plugins for snapcraft?
<T-mon> jdstrand: ok, I found out the QSqlQuery makes the "Bad system call" -> https://github.com/guh/guh/blob/master/server/logging/logengine.cpp#L240
<T-mon> this makes no sense to me :(
<clobrano> Chipaca: after pushing new changes for your review, I've to go to "resubmit proposal"?
<Chipaca> clobrano: nope
<Chipaca> clobrano: just tell me you've pushed them in case i don't see the email
<clobrano> Chipaca: so... I pushed them :D
<T-mon> rickspencer3: ls -l /usr/share/snapcraft/plugins/
<rickspencer3> thanks T-mon
<yashi_> hmm... py3version returns list of versions on wily, and that isn't expected in snapcraft
<yashi_> might be better to check the return val in Python3ProjectPlugin::python_version()?
<sergiusens> rickspencer3, /usr/share/snapcraft/plugins (I'm going to spec a cli option for this)
<sergiusens> yashi_, bug please :-)
<jdstrand> T-mon: so, to unblock yourself for development until you figure out how to fix that in your app, you can add the missing syscall to /var/lib/snappy/seccomp/profiles/<your app>
<T-mon> jdstrand: thx! though I have no idea how to create a db without a query...yet :) but I will do some experiments
<yashi_> sergiusens: bug #1499429
<ubottu> bug 1499429 in Snapcraft "snapcraft dies with "export: python3.5/dist-packages: bad variable name"" [Undecided,New] https://launchpad.net/bugs/1499429
<jdstrand> T-mon: I would imagine that code is triggering something else lower
<fgimenez> elopio, i'm executing the suite in kvm rollling edge and flashing for bbb
<elopio> fgimenez: cool. Let me know how it goes, but don't stay after your EOD. I have plenty of hours ahead of me today.
<elopio> mvo: so, we wait on your fix for the ppp order?
<mvo> elopio: I'm investigating it now
<fgimenez> elopio, mvo should snappy config work for ppp in 181? i'm getting this http://paste.ubuntu.com/12543133/
<T-mon> jdstrand: It workes now (temporary) by uncomment the fchown32 in the /var/lib/snappy/seccomp/profiles/ ...thx for the hint! I'm trying now to find out whats going on in the query.
<mvo> fgimenez: hm, it should. I just tested it (with a upgraded image though) and it worked for me
<mvo> pitti: does it make sense to have a "Before=network.target" line in a systemd unit? sorry for the basic question?
<pitti> mvo: yes, under the right circumstances
<pitti> mvo: this woudl be the right thing for e. g. firewall services, which must be started before the first serfice on the network starts
<mvo> pitti: whats the difference between networking.service and network.target? so I want to ensure that my workaround that fixes some ppp files is run before the ppp daemon gets a chance to run
<pitti> mvo: and conversely on shutdown it means that services on the network (which must have After=n.t) get stopped before stopping firewalls and the like
<pitti> mvo: networking.service is just /etc/init.d/networking, i. e. bringup of "auto" ifupdown interfaces
<pitti> mvo: it's best not to depend on that unless you know what you are doing
<fgimenez> elopio, i'm still hitting this http://paste.ubuntu.com/12543228/ only in the initrd failover test, we may need to update the partition.NextBootPartition function for that case
<pitti> mvo: (as this doesn't help you with NM or networkd)
<elopio> fgimenez: we have not landed that change, or are you using my branch?
<mvo> pitti: so for my use-case network.target is the better one?
<pitti> mvo: ah, then I figure you might want Before=network-pre.target
<mvo> pitti: aha, great
<fgimenez> elopio, i'm executing from trunk, is that fixed?
<pitti> mvo: as you don't just want to run before services on the network, but even before things like ifupdown which configure hte network
<pitti> mvo: see man systemd.special
<mvo> pitti: great
<pitti> mvo: sorry, need to leave for today, my better half just arrived
<elopio> fgimenez: no. yesterday I could reproduce this https://code.launchpad.net/~elopio/snappy/new_kernel_file_name/+merge/271901/comments/685415
<elopio> only on 15.04. Didn't have time to understand why.
<elopio> so it's not ready to land.
<elopio> fgimenez: please report your config error.
<fgimenez> elopio, it seems to be the same issue as the try mode, the mode is not set to try and systemab is not updated
<fgimenez> elopio, it happens only for the zero size initrd failover test, the test is may be doing something wrong now in that case
<fgimenez> elopio, https://bugs.launchpad.net/snappy/+bug/1499446
<ubottu> Launchpad bug 1499446 in Snappy "snappy config fails for ppp" [Undecided,New]
<elopio> fgimenez: you flashed a new 181, right?
<fgimenez> elopio, yep
<elopio> fgimenez: I just tried and it works here. I'll comment in there.
<fgimenez> elopio, let me try again
<elopio> it's weird. I'll try one more time.
<Chipaca> clobrano: you still around?
<fgimenez> elopio, yes, i still get it http://paste.ubuntu.com/12543356/
<elopio> fgimenez: I still don't get it http://paste.ubuntu.com/12543383/
<elopio> we must be doing something different in here.
<elopio> fgimenez: that's 15.04, right?
<elopio> fgimenez: your ubuntu-core says it's from the 22nd. Mine is from today http://paste.ubuntu.com/12543396/
<fgimenez> elopio, that's it, i'm on rolling :)
<elopio> let me get a rolling.
<mvo> elopio: I uploaded a new ubuntu-core-config, once that is build i nthe ppa, maybe ogra_ can trigger a new image (or I can do it after dinner) and we can test if that is sufficient
<ogra_> sure, i can
<elopio> mvo: right, thanks.
<elopio> ogra_: can you teach me what is it that you touch to get a new edge image?
<ogra_> elopio, not really, we havent gotten an accessible UI for that ready yet and manual building needs server access that requires you to be in ubuntu-cdimage
<elopio> ogra_: ok, then I'm glad I have you.
<ogra_> i have getting it into the isotracker on my TODO (on low prio though) ... then you will be able to just trigger images from there
<elopio> ogra_: the lp:snappy recipe shows this: https://launchpadlibrarian.net/218712096/upload_992086_log.txt
<elopio> could it be the reason why we have an older ubuntu-core in rolling?
<ogra_> why does it have the same old version ?
<ogra_> https://launchpad.net/~snappy-dev/+archive/ubuntu/image has 1.6ubuntu1-1+714~ubuntu15.10.1
<ogra_> so it should be in the rolling/edge image
<elopio> so many things about this that I don't yet understand.
<ogra_> elopio, what do you mean exactly by "older ubuntu-core in rolling" ?
<elopio> I don't get what's the difference between 15.04 and rolling that makes ppp config fail.
<elopio> ogra_: http://paste.ubuntu.com/12543356/
<elopio> it shows ubuntu-core #181, but from the 22nd.
<elopio> shouldn't it be one from yesterday or today?
<ogra_> elopio, not on rolling, no
<ogra_> http://system-image.ubuntu.com/ubuntu-core/rolling/edge/generic_amd64/ .... shows a timestamp from 22nd for 181
<ogra_> looks like the nightly builds didnt run since
<ogra_> sigh
<elopio> oh good. So in a new image it should just work (tm)
<ogra_> elopio, because infinity commented out the whole crontab for freeze
<elopio> now why the nightly didn't work?
<ogra_> i'll trigger one for you
<elopio> ogra_: ah.
<ogra_> kicked
<ogra_> and i enabled nightly builds again
<elopio> ogra_: please do one for 15.04 too. ubuntu-core-config is ready on the ppa.
<ogra_> elopio, there were two builds after it landed in the PPA
<ogra_> latest 15.04 should have all you need
<elopio> cooool
<mvo> elopio: just fyi, I triggered a new image for in 10min, so ~45min from now we should have something to test the ppp workaround issue you noticed
<ogra_> (funnily 15.04 was not disabled ... and my manual build from last night should have it too)
<ogra_> mvo, eeek
 * ogra_ hopes our builds dont clash mid-air now
 * elopio waits for the fireworks.
<ogra_> elopio, mvo, sigh, so my rolling/edge build failed ... more /etc/passwd trouble
<ogra_> bah and indeed the archive is frozen
<ogra_> grrr
<lool> jdstrand: ah I thought it was enough to set bus-name for simple dbus services, but it seems I need to set the apparmor and seccomp files too
<lool> jdstrand: should I copy the ones from hello-dbus, or is there some forward-compatible way of declaring just the dbus name?
<lool> tyhicks: ^
<tyhicks> lool: sorry, I'm not following - you have a service that is attempting to own a specific bus name and apparmor is denying that?
<lool> tyhicks: yes; hello-dbus example provides a .apparmor and .seccomp
<lool> tyhicks: am I supposed to copy these from hello-dbus?
<lool> tyhicks: I do declare bus-name
<lool> tyhicks: I have:
<lool> - bus-name: org.freedesktop.NetworkManager name: networkmanager-service security-template: unconfined start: bin/network-manager.wrapper
<lool> tyhicks: but that's not sufficient it seems, I still get denials
<lool> tyhicks: so I intend to add a .apparmor and .seccomp, just not sure what to base them on
<lool> the hello-dbus one seems to include a lot of copy-pasted stuff that I fear will soon be out of date
<tyhicks> lool: hrm... I don't know the hello-dbus-fwk policy off the top of my head
<lool> tyhicks: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/files/head:/hello-dbus/
<lool> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/head:/hello-dbus/package-dir-fwk/meta/svc.apparmor
<tyhicks> lool: you'd need to change line 30 to match the name that you're binding to
<lool> tyhicks: yes, got it so far, it's the rest I'm worried about
<tyhicks> lool: right, line 35 and 36 need to be changed to match the path and interface that you're receiving messages on
 * tyhicks looks further down
<lool> tyhicks: I mean the whole rest of what seems to be not specific to my dbus service
<lool> tyhicks: I'd like to say "standard policy + dbus stuff that I know about"
<jdstrand> lool, tyhicks: I'm here
<jdstrand> lool: so, bus-name sets dbus bus policy for the service on the system bus
<jdstrand> lool: an unconfined dbus service is then able to start a dbus service and listen
<lool> jdstrand: ok, that didn't work for me
<lool> jdstrand: with just bus-name that is
<jdstrand> lool: however, apps can't connect to it without framework-policy. if the service is to be confined, then you also need dbus rules in its security-policy
<lool> jdstrand: perhaps I'm doing something wrong though
<tyhicks> lool: can you paste the denial?
<jdstrand> lool: I suggest you look at both the framework-template and hello-dbus-fwk for inspiration
<lool> jdstrand: yes, I'm not that far though, right now I cant listen
<jdstrand> lool: is the service confined?
<lool> it says unconfined
<lool> I cant find the denial though
<jdstrand> there may not be one
<jdstrand> it might be you used the wrong bus-name
<jdstrand> and you have a dbus bus policy denial
<jdstrand> (ie, not security policy)
<jdstrand> lool: do you have a file in /etc/dbus-1/system.d for your service?
<lool> I'm getting:
<lool> 2015-09-24T16:51:19.422175Z NetworkManager <error> [1443113479.422051] [nm-dbus-manager.c:802] nm_dbus_manager_start_service(): Could not acquire the NetworkManager service. Error: 'Connection ":1.56" is not allowed to own the service "org.freedesktop.NetworkManager" due to security policies in the configuration file'
<lool> from the app
<lool> but nothing in dmesg
<jdstrand> lool: (also snappy service logs <snap> should give you logging info that I would think would include the bus policy)
<jdstrand> right
<lool> jdstrand: I do not get a dbus system file
<jdstrand> so your bus-name needs to be org.freedesktop.NetworkManager
<lool> yes, I have: - bus-name: org.freedesktop.NetworkManager name: networkmanager-service
<lool> in meta/package.yaml before snappy build
<lool> jdstrand: but somehow the dbus file isn't generated
<jdstrand> lool: something is wrong. I suggest uninstalling the snap and trying again. when you specify bus-name snappy is supposed to give you wide open dbus bus policy via a file in /etc/dbus-1/system.d
<lool> jdstrand: I did uninstall, find / with anything looking like it, then installed again
<lool> jdstrand: when I run sudo aa-clickhook -f, I get a warning
<lool> jdstrand: Could not parse click manifest
<jdstrand> lool: what happens if you 'click-review /path/to/snap'
<jdstrand> (and why is that still not on by default?)
<lool> when I run click-review, my CPU load rises
<lool> ;-)
<jdstrand> it is hard at work :)
<beuno> we might be mining some bitcoins in there as well
<lool> jdstrand: one of the json files under /var/lib/apparmor is empty
<lool> I need a faster laptop, click-review is still running
<jdstrand> lool: how big is this snap?
<lool> jdstrand: http://paste.ubuntu.com/
<lool> gah
<jdstrand> lool: is the empty file something from this snap?
<tyhicks> jdstrand: could this be the hyphen in the binary name issue again?
<lool> jdstrand: http://paste.ubuntu.com/12544050/
<jdstrand> tyhicks: that is what I'm thinking
<elopio> mvo: flashed #178, the ppp service doesn't start. updated to #182, reboot, the service starts. All good!
<lool> I dont have any underscore
<lool> is hyphen forbidden as well?
<jdstrand> doesn't look like that is the issue
<jdstrand> no, hyphen is fine
<jdstrand> lool: fyi, use 'architecture'
<lool> snap is 64M
<lool> round numbers are nice
<jdstrand> lool: what version of snappy are you using to generate this?
<lool> jdstrand: oh wow, that's probably it; my snapcraft is from yesterday but I see my snappy is much older
<jdstrand> lool: also, description has been required for services and binaries
<jdstrand> but yes, upgrade your snappy
<jdstrand> then come back
<jdstrand> lool: also, clean out all the empty files in /var/lib/apparmor that you mentioned
<jdstrand> (that cleaning is a snappy remove or a rm -f depending on if the snap is installed or not
<jdstrand> i)
<jdstrand> )
<lool> jdstrand: Yeah, I have a big find + rm
<lool> after snappy remove
<mvo> elopio: \o/
<mvo> elopio: thank you so much for verifying
<elopio> mvo: np, that was the easy part. I'll make a card to add a test to check that no service faild to load.
<lool> jdstrand: well I thought 1.5 from july was old
<lool> jdstrand: but it's still what's in wily; am I supposed to take 1.6 from proposed?
<jdstrand> it should be ok
<jdstrand> bus-name has been around for a while
<lool> jdstrand: then that's not it
<jdstrand> but the empty file has me concerned
<mvo> elopio: nice
<jdstrand> as in, snappy install might be bailing out early cause something went wrong
<lool> jdstrand: I had a bunch of cases where I ended up with a failed install and /apps having an app dir in it, but no files
<jdstrand> hmm
<lool> I did clean up religiously with remove+purge+find && rm -rf each time
<lool> ah I just reproduced this
<lool> jdstrand: empty file again
<jdstrand> can you give me the snap?
<jdstrand> lool: which file is empty?
<lool> jdstrand: the /var/lib/apparmor/clicks/network-managerblah.json
<lool> jdstrand: and /apps/network-manager.sideload/blah as well
<lool> in fact just /apps/network-manager.sideload got created
<lool> jdstrand: yes I can give you the snap
<jdstrand> ok
<jdstrand> well, /var/lib/apparmor/clicks/network-managerblah.json is surely empty because /apps/network-manager.sideload/blah is
<lool> jdstrand: I'll hand you the snapcraft yaml first, that's easier to upload and I have to go afk for a bit in some minutes
<jdstrand> it didn't unpack right
<lool> jdstrand: yes, that's what I thought as well
<lool> not sure why though
<jdstrand> disk space?
<jdstrand> might be easier to create a new vm
<lool> hmm it's not impossible
<lool> unpacked snap is 2xx MB, I have some 3xx MB free
<lool> that woudl be quite a stupid way to waste both our time (NB: didn't get an out of space error)
<lool> awe_, jdstrand: lp:~snappy-dev/+junk/nm-snap I'll be back in ~3h or so
<lool> it has some crude hacks still
<lool> I've just did some untested renames to drop the hyphens and such
<elopio> zyga: I've just added a card to check that no service has failed loading. Is that good enough for you?
<elopio> if you want us to add more validations, this is your moment :)
<zyga> elopio: yeah, that's a great sanity check
<ogra_> elopio, you might have services that will be started manually or via a snappy-config option or so
<zyga> elopio: no, for now that's okay, especially that TPM testing requires a hell lot of manual interaction, visits to BIOS and stuff
<ogra_> i.e. watchdog was seeded last week, it wouldnt start
<zyga> elopio: (and that is by desing)
<zyga> elopio: we'll do more validation tomorrow on select devices
<ogra_> (and shouldnt)
<zyga> ogra_: does it start now or is it still off by default?
<ogra_> zyga, ricmm said there would be a script starting it
<zyga> ogra_: for testing ,yes
<ogra_> the sysv generator doesnt work on watchdogs init script ... so it cant be started atm
<zyga> ogra_: for consumer projects, it would perhaps be good to tie it to snappy config as we go
<ogra_> sure
<ogra_> long term thats supposed to be fixed
<zyga> ogra_: do you think watchdog should become a service or can it have a config hook in the os snap?
<elopio> ogra_: we have opencryptoki.service loaded failed failed LSB: starts pkcsslotd
<ogra_> what i meant to point out is that not all installed services will necessarily start
<elopio> is that something you are working on?
<zyga> ogra_: right
<ogra_> so just doing a broad test looking at the services might not be enough
<ogra_> (due to false positives)
<rickspencer3> so, I deployed a snap with snapcraft run, but I don't see where my print statements are going, they don't seem to be in journalctl
<lool> mvo: not sure you saw there's a testsuite failure in the 1.6 wily upload: panic: can not set option description for "package name"
<lool> rickspencer3: there's a new service logs command now
<lool> hmm
<lool> awe_: so that's all I had for now; currently it fails in various ways, notably dbus, but that might be due to my vm having too little storage
<lool> awe_: I'm playing with various hacks, and the app dir is not truly kep readonly, however plugin to load and startup fails while binding to dbus
<awe_> lool, can you give me the snap, and any source code you have?  As mentioned, I've been working from the bottom up
<awe_> lool, are you statically building NM??
<lool> awe_: i"m using the debs
<awe_> and extrating them into the snap?
<awe_> extracting
<lool> awe_: yes, snapcraft does it all
<awe_> k
<awe_> so you didn't get to the point where you were re-building NM?
<awe_> to change rundir for instance?
<lool> awe_: I'm uploading the snap to http://people.dooz.org/~lool/network-manager_1.0_amd64.snap but I've got to run now; it will be done in ~10mn
<awe_> k
<lool> hmm or maybe not
 * lool switches to LTE
<awe_> do you have a branch for your networkmanager.patched?
<lool> awe_: lp:~snappy-dev/+junk/nm-snap (as above)
<lool> awe_: network-manager.patched is NetworkManager sed-ed
<lool> I knew you'd love this
<awe_> the binary?
<lool> yeah
<lool> awe_: upload complete
<awe_> cough, hack, why?
<awe_> can't rebuild it?
<awe_> ;)-
<lool> awe_: that was the quickest
<lool> sed: 10s to write, 0s to run
<awe_> and where's the sed script?
<awe_> I assume we don't want to ship that
<awe_> if so, please leave my name off
 * awe_ finishes his lunch
<zyga> lool: OMG, what did you sed?
<zyga> lool: I think you are close this not making sense as debs repackaged
<zyga> lool: "dear customer, our engineers _hand crafted_ this binary" ;)
<rayn> hello there. Um looking for apps and frameworks, like tomcat. Where are they?
<rayn> i*
<ogra_> not there yet, but you can package them ;)
<ogra_> elopio, rolling just finished building the rootfs ... should be there after the next system-image import
<ogra_> 20-30min
<Chipaca> elopio: ogra_: http://www.commitstrip.com/wp-content/uploads/2015/08/Strip-Apr%C3%A8s-le-match-650-finalenglish.jpg
<Chipaca> just for you
<ogra_> HAHA!
<sergiusens> rayn, you can develop locally with snapcraft and integrate tomcat into what you need
<rayn> sergiusens, ogra_, thanks. I figured that uot. Is there an official ubuntu repository for it?
<rayn> Where can we find all the apps that have been made?
<sergiusens> rayn, maybe start here https://developer.ubuntu.com/en/snappy/snapcraft/
<rayn> where this command searchs? "snappy search ..."
<sergiusens> rayn, querying the store I guess https://uappexplorer.com/apps?sort=relevance&type=snappy
<sergiusens> rayn, you need to run that on a snappy system (ubuntu-core)
<elopio> lol.
<rayn> sergiusens. thanks. I hava ubuntu core installed but i dont know where are stored the apps
<sergiusens> rayn, run 'snappy search' with no args
<sergiusens> rayn, or install webdm (snappy install webdm)
<sergiusens> and you can open a browser and look at them
<ogra_> elopio, both images are done
<elopio> thanks ogra_. Get some rest :)
<ogra_> havent copied to alpha yet ...
 * ogra_ finishes dinner
<ogra_> copy running ...
<rickspencer3> sergiusens, so, I'm using snappy run
<rickspencer3> what do you make of this?
<rickspencer3> 2015-09-24T19:22:40.288952Z systemd Starting service hello for package python-snap...
<rickspencer3> 2015-09-24T19:35:36.367400Z ubuntu-core-launcher starting service
<rickspencer3> ^ a 13 minute lag between systemd and ubuntu-core launcher?
<rickspencer3> it seems to be consistent
<ogra_> elopio, alpha images ready
<elopio> thanks
<zyga> lool: still there?
<sergiusens> rickspencer3, hey sorry, was on the phone and distracted; is that with your snap? And is that the output of snappy service logs [snap] ?
<lool> zyga: yup
<zyga> lool: re :)
<zyga> lool: did you see what jdstrand found?
<lool> zyga: yup, great
<zyga> lool: you were missing a framework type
<zyga> lool: but then more weirdness happens
<lool> zyga: what happens next?
<zyga> lool: and the bottom line is we need to patch n-m source to get it fixed :/
<zyga> lool: !usr (that's not a typo)
<lool> zyga: that's my sed
<zyga> lool: and some things that are not exposed as --option of any kind need to be patched
<zyga> lool: ah, I didn't know
<lool> I picked an uncommon char I could use in a pathname
<zyga> lool: did you try to do a symlink from !usr ?
<lool> zyga: exactly; !usr -> usr
<lool> instead of /usr
<zyga> does it work? jdstrand did't get it
<lool> e.g. /usr/lib/NM becomes !usr/lib/NM which because of the symlinks points at /apps/.../nm/usr/lib/NM
<lool> zyga: it does!
<zyga> lool: neat!!
 * lool just typed sudo snappy reboot
<lool> instead of sudo reboot
<zyga> lool: today you will dream of snappy ;)
<zyga> lool: we have no such luck in bluez, everything uses string concatenation in the preprocessor
<zyga> lool: so we're patching bluez
<zyga> lool: but it's not terrible, without patches it seems to work to a good degree
<zyga> lool: we also have a real policy now, not just unconfined
<zyga> lool: but your idea with the simlink now made me think :)
<lool> zyga: I'm pretty sure it would wokr with Bluez too
<lool> zyga: but there are limits
<zyga> lool: I was thinking about a kernel module that expands $SNAP_APP_PATH
<zyga> lool: based on process environment
<zyga> lool: but this is easier to get to work today ;)
<lool> zyga: the other crazy approach I did at a customer site was using LD_PRELOAD like in the early deb2snap stuff
<zyga> lool: well, I can configure for prefix /usr and do the sed as you did
<lool> that actually got us quite some way along
<lool> but it's too limiting and messy
<lool> especially with 32/64 bits libs
<zyga> lool: yeah, that's a somewhat saner bit
<lool> which happened to be the case
<zyga> lool: like fakeroot
<lool> zyga: exactly, it was the same thing
<lool> but selective fakechroot
<lool> fakeroot => just uids, pretty good; fakechroot => all pathnames, pretty fragile
<zyga> lool: a symlink handled by the kernel would work in all cases (suid apps too)
<lool> yes
<zyga> lool: I'll try to hack that next week, if time permits
<zyga> lool: /proc/snap
<zyga> lool: then --prefix=/proc/snap/ and we're "done" with relocatable apps
<lool> zyga: might be possible with some kind of overlay rootfs
<zyga> but this feel very ugly
<zyga> lool: apparently overlayfs breaks apparmour
<zyga> lool: did you hear about the /var $current symlink?
<zyga> lool: that could help in many things,
<zyga> lool: /var/$SNAP_NAME/current AFAIR
<lool> zyga: I personally would like us to avoid hardcoding absolute pathnames as much as possible
<lool> while it could become a required layout, I think it's nicer if we keep things relocatable, like on the phone for preinstalled apps
<zyga> lool: to some degree I agree but what's the difference in expanding it in one spot vs another?
<sergiusens> zyga, lool can you share the snapcraft project that breaks with c that you mentioned?
<zyga> lool: yes, I agree, though the only practical difficulity is that C tends to make this harder than languages that people use on the phone, and we have more incentive to allow existing projects (bluez) to work
<zyga> sergiusens: yes, that's the older bluez example
<zyga> sergiusens: it broke at 0.2
<zyga> sergiusens: stopped configuring entirely
<zyga> sergiusens: the same configure line works without snapcraft
<zyga> sergiusens: the addition of -I in CFLAGS seems to cause this but I did not dig deeper
<zyga> sergiusens: do you need a link?
<zyga> sergiusens: https://code.launchpad.net/~zyga/+git/snap-example-bluez5
<sergiusens> zyga, yes please
<zyga> sergiusens: https://code.launchpad.net/~zyga/+git/snap-manual-bluez5 (without snapcraft)
<zyga> sergiusens: FYI https://git.launchpad.net/~zyga/+git/snap-manual-bluez5/tree/Makefile#n68 this has nice usability
<zyga> sergiusens: if you agree I'll patch that into snapcraft too
<zyga> sergiusens: and make reinstall, saves time on VM bootstrap a _lot_ (on my older laptop)
<zyga> sergiusens: usability == redirecting qemu output
<sergiusens> sure , the qemu output is more of a, is it working thing I guess
<zyga> sergiusens: in python we could just pipe it and spin a spinner
<zyga> sergiusens: it "works" and the output can be pretty
<zyga> sergiusens: here I just log it (which is useful too)
<sergiusens> zyga, if you want to make a spinner branch I am all for it!
<lool> sergiusens: hmm I have a weird behavior with snapcraft; it looks like only the last symlink gets copied as a symlink
<zyga> sergiusens: cool, I'll be my pleasure :)
<zyga> sergiusens: I'd love if parts could start to use pkg_config sensibly
<zyga> sergiusens: perhaps we could set PKG_CONFIG_PATH?
<sergiusens> zyga, it is set
<zyga> sergiusens: it seems that it's a cheaper way to cure cross-part usage than -I / -L
<zyga> sergiusens: oh? hmmm
<sergiusens> zyga, PKG_CONFIG-PATH
<sergiusens> zyga, let me get the MP that did that
<zyga> sergiusens: maybe I used it before
<zyga> sergiusens: then it still didn't work
<sergiusens> zyga, or else the godd example wouldn't compile
<zyga> sergiusens: I can have a look at that later, today == plainbox
<sergiusens> zyga, yeah, it works since less than 4 days ago at most
<zyga> sergiusens: I'd like to iterate on bluez / nm examples later to build more things inside the snap as parts
<sergiusens> zyga, releasing the fix for Left overs? :-)
<sergiusens> zyga, if those parts use the built in plugins, it would be awesome to have them on the wiki
<zyga> sergiusens: no, spineau is handling our releases, it will be done after QA
<zyga> sergiusens: I'm adding features
<zyga> sergiusens: I will certainly try, now I'm split between the flexibility and predictability of the makefile I wrote
<zyga> sergiusens: and the urge to fix core issues I see in snapcraft today (subprocess mess, some caching bugs)
<zyga> sergiusens: also, make has a working dependency engine, it makes a lot of difference when you iterate, just make and it's fresh instantly (*when upstream didn't f*** up)
<zyga> sergiusens: whereas snapcraft really needs some idea on how to remake parts during hacking and I kept ending up doing rm -rf  equivalent
<sergiusens> zyga, right, we need to implement the 'detect' if dirty
<sergiusens> zyga, you can force
<sergiusens> zyga, snapcraft stage --force
<sergiusens> but that will walk down the pull phase too
<zyga> sergiusens: I tried building one part out of few
<zyga> sergiusens: and that didn't work either (look at the $secret snap in $secret project)
<zyga> sergiusens: so I just ended up rm -rf ing, maybe it's all fixed now, it was last week
<lool> zyga: I personally echo the stage into the file
<zyga> lool: which file?
<lool> zyga: the state file
<zyga> sergiusens: FYI, http://plainbox.readthedocs.org/en/latest/manpages/plainbox-job-units.html#job-flag-simple this will make all snapcraft tests faster
<lool> zyga: under the part
<zyga> lool: ah, I see
<sergiusens> zyga, \o/
<zyga> sergiusens: s/faster/easier/
<sergiusens> zyga, better harness, makes for faster development
<sergiusens> ;-)
<sergiusens> zyga, so it is in some way all your fault :-P
<zyga> sergiusens: hehe
<zyga> sergiusens: plainbox has come a long way, compare that simple job to this...
<zyga> http://bazaar.launchpad.net/~zyga/checkbox/tpm-hacking-patches/view/head:/providers/plainbox-provider-tpm/units/tpm.pxu#L19
<lool> root       3489  0.1  1.4 460364 14152 ?        Sl   22:53   0:00  \_ NetworkManager.patched --state-file=/var/lib/apps/network-manager/IBYLbSAATUQC/NetworkManager.state --config-dir=/apps/network-manager/IBYLbSAATUQC/etc/NetworkManager --config=/apps/network-manager/IBYLbSAATUQC/etc/NetworkManager/NetworkManager.conf --log-level=DEBUG --no-daemon
<lool> woot
<zyga> lool: cooool!
<zyga> lool: nmcli?
<zyga> lool: does it work?
<lool> not yet
<lool> I mean NM seems happy
<lool> nmcli not
<zyga> lool: right
<lool> but then I didn't open the dbus for nmcli yet
<lool> I'd like to try it without confinment first though
<lool> (amd64)ubuntu@localhost:/apps/network-manager/current$ LD_LIBRARY_PATH=$PWD/usr/lib/x86_64-linux-gnu usr/bin/nmcli general status
<lool> STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
<lool> connected  full          enabled  enabled  enabled  enabled
<lool> hmm this stuff depends on policykit, that wont be nice
<zyga> lool: uhhh
<zyga> lool: what do you think we should do about polkit?
<zyga> lool: remove it or put it into snappy itself?
<lool> I dont know yet
<lool> let's try whether it brings up eth0
<lool> there are loads of errors in the logs
<zyga> lool: careful, eth0 is how you ssh into the box ;)
<zyga> lool: how do you test btw/
<lool> I have a console on the box
<zyga> lool: KVM?
<lool> nah
<lool> ok, so denials from dhclient
<lool> but the snap is unconfined hmmm
<zyga> lool: what kind?
<lool> (amd64)ubuntu@localhost:/apps/network-manager/current$ LD_LIBRARY_PATH=$PWD/usr/lib/x86_64-linux-gnu usr/bin/nmcli general status
<lool> STATE      CONNECTIVITY  WIFI-HW  WIFI     WWAN-HW  WWAN
<lool> connected  full          enabled  enabled  enabled  enabled
<lool> [ 2679.122645] audit: type=1400 audit(1443135850.522:61): apparmor="DENIED" operation="sendmsg" info="Failed name lookup - disconnected path" error=-13 profile="/sbin/dhclient" name="run/systemd/journal/dev-log" pid=4476 comm="dhclient" requested_mask="w" denied_mask="w" fsuid=0 ouid=0
<lool> ups
<lool> tyhicks or jdstrand ^ so my service is policy-template: unconfined, but is getting this denial
<zyga> lool: I may be wrong but unconfined is not "all in", it's still restricted to some degree (more than the shell you have) but very very permissive
<lool> looks like dhclient is trying to log, and somehow apparmor doesn't like not finding who owns that file?!
<jjohansen> lool: right but the dhclient profile is the one that is failing because it doesn't have permission
<lool> jjohansen: so it's because of the /sbin/dhclient apparmor profile that we ship
<lool> jjohansen: shoudl I disable something to get it to work, or ship my own or...?
<lool> oh I already ship dhclient
<jjohansen> lool: you can add the flag attach_disconnected to the dhclient profile as a work around
<jjohansen> it will looks something like
<lool> jjohansen: where is this profile though?
<jjohansen>   /sbin/dhclient flags=(attach_disconnected) { ... }
<jjohansen> lool: probably in /etc/apparmor.d/sbin.dhclient
<lool> jjohansen: I see it's under /etc, but that's supposed to be read-only
<lool> /etc/apparmor.d/local/sbin.dhclient
<lool> /etc/apparmor.d/sbin.dhclient
<zyga> lool: at least it's not selinux
<jjohansen> lool: to test you can copy it somewhere else, and then do
<jjohansen>   sudo apparmor_parser -r edited_profile_file
<zyga> lool: it's been a decade and it's still something people turn off
<jjohansen> zyga: people turn apparmor off as well, heck they will turn off passwords and any security inconvenience that they can
<lool> jjohansen: yeah; it's just I need to fix this properly; I'd rather avoid rootfs changes and I dont want to lose the security benefits
<lool> perhaps NM launches dhclient in the wrong way
<lool> dhclient works when called from ifup
<lool> and probably works on the desktop too with the same apparmor profile
<lool> so my NM must be doing something different
<jdstrand> lool: I imagine that you'll want a child profile for dhclient in the network-manager security-policy which would avoid the binary attachment and that you could tailor to the snap's data dirs
<lool> jdstrand: yeah; that sounds good
<lool> it does sound like a lot of work too though
<lool> plus, keeping the dhclient policy in sync
<jdstrand> lool: I wouldn't get hung up on dhclient. add attach_disconnected to the file in /etc/apparmor.d to unblock yourself, then we can adjust when its time to implement security-policy for this service
<jdstrand> lool: you don't have to keep it in sync. it only has to work with your snap writable areas
<jdstrand> lool: it isn't terribly much work. see the email I CC'd you on wrt bluez
<jdstrand> ok, really heading out
<lool> do I need to run something?
<lool> probably apparmor_parser
<jdstrand> lool: yes
<jdstrand> apparmor_parser -r /etc/apparmor.d/sbin.dhclient
<jdstrand> (under sudo)
<lool> yup
<jdstrand> -r is for reload
<jdstrand> your change will survive reboots, but don't forget we have to address dhclient before people consume this
<jdstrand> :)
<jdstrand> ok, really, really gone
<lool> oh no
<lool> [ 3367.581854] audit: type=1400 audit(1443136539.036:81): apparmor="DENIED" operation="open" profile="/sbin/dhclient" name="/apps/network-manager/IBYLbSAATUQC/lib/x86_64-linux-gnu/libisccfg-export.so.90.1.0" pid=5446 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=101
<lool> blah
<lool> I think I want to use my dhclient now
 * zyga pushes a plainbox feature up
<zyga> https://code.launchpad.net/~zyga/checkbox/no-resource-limits/+merge/272319 :)
<zyga> launchpad feels slow tonight
#snappy 2015-09-25
<lool> wee, got an IP
<ricmm> \o/
<lool> ricmm: sent you a status email; some open questions for you
<ricmm> lool: yea, just skimmed through it
<lool> ricmm: if we're maintaining this, I might elect the ugly+complex but quick to deliver hacks on top of Ubuntu packages -- to avoid maintaining NM and deps twice
<ricmm> I'll reply, keep an eye out
<ricmm> lool: go sleep
<lool> haha my inbox looks like a jungle now
<lool> yeah, time for sleep
<h00sier> I'm trying to add a user in snappy. I've already added lines to /var/lib/extrausers/{password,group,gshadow}, I don't know how to make the line for shadow. It's encrypted I guess, any help?
<pitti> mvo: guten Morgen!
<pitti> mvo: I reviewed the snappy classic dimension spec
<mvo> pitti: great, thanks
<mvo> pitti: I also have a systemd question again :) so I have this snappy-workaround.service and it needs to be completed before ppp-dns.service runs. in snappy-workarounds.service I used before=ppp-dns.service but thats not strong enough, I also added "wantedby=network-pre.target" to ensure its run earlier and indeed its run earlier but ppp-dns still starts in parallel, whats the best way to express that the unit has to have exited? (or the best way
<mvo> to do what I want, namely that the workaround is applied before ppp-dns starts)?
<pitti> mvo: before= does just that
<pitti> mvo: but it only says that your unit must get *started* before the other one, not *ended*
<pitti> mvo: maybe  you are missing a Type=oneshot?
<pitti> mvo: for those, the unit only counts as "done" when all Exec= commands exited, not when they started
<mvo> pitti: this is what it looks like http://paste.ubuntu.com/12551829/
<mvo> pitti: is it the "remainafterexit"?
<pitti> mvo: oh, when does ppp-dns.service get started?
<mvo> iirc we added it to easily see the logs
<pitti> mvo: my guess is that ppp-dns.service gets started in a target much ealier than multi-user.target
<mvo> pitti: pps-dns is a old-school init script
<pitti> mvo: and thus the snappy-workaround.service isn't even taken into account
<pitti> mvo: in rcS?
<pitti> oh, I have it
<pitti> mvo: ah, rcS
<mvo> pitti: indeed it is
<pitti> mvo: ack, clear then; hang on
<mvo> pitti: thanks!
<mvo> pitti: would be nice if systemd would tell me in some way that the before= releation can not be satisfied or something :)
<pitti> mvo: old-school init.d> err, is it? I have a /lib/systemd/system/pppd-dns.service which is in multi-user, but that might be new in wily
<pitti> mvo: and indeed it being in rcS makes things unnecessarily hard :/
<mvo> pitti: uh, I'm sorry, I have that in vivid too on my snappy image
<mvo> pitti: but its also in rcS.d it seems, what happens in this case? will the native one always "win"?
<pitti> mvo: http://paste.ubuntu.com/12551864/
<pitti> mvo: yes, native always wins
<pitti> ok, then I don't know -- journal SVP?
<pitti> mvo: the above paste would be to start much earlier, in case pppd-dns already ran in rcS (aka sysinit.target)
<mvo> pitti: sure, one sec and I can give you the journal and the systemd-analiyze output
<pitti> mvo: systemd actually should tell you that, in that case you get a dependency cycle in journal and one service in the cycle doesn't start
<pitti> mvo: so, given /lib/systemd/system/pppd-dns.service your wantedby=multi-user.target shoudl be fine
<pitti> and the before=
<mvo> pitti: http://paste.ubuntu.com/12551875/ is the journal
<pitti> mvo: haha!
<pitti> mvo: ppp-dns.service
<pitti> mvo: spot the typo :)
 * mvo drops dead
<pitti> mvo: /me tosses mvo another 'd'
<mvo> *cough* thanks, I guess I owe you one (or two)
<pitti> and try to say "pppd-dns" very fast ten times
 * pitti hugs mvo
<pitti> no warning about this, as having an After=/Before= to nonexisting units is a common and legitimate use case
<pitti> but we should maybe configure --enable-typo-detection
<pitti> mvo: now that this is done, another thing: http://cdimage.ubuntu.com/ubuntu-core/vivid/daily-preinstalled/current/ is not actually a "classic" ubuntu tarball, it's snappy
<pitti> mvo: fortunately it still has an intact dpkg database, but we need to remove the /usr/local/bin/apt* stuff at lesat
<mvo> hmm
<pitti> mvo: I was just wondering what these ubuntu core tarballs actually want to be -- a deb based minimal ubuntu, or classic
<pitti> err, "or snappy"
<mvo> pitti: indeed, I think we should find a real core tarball, the snappy one removes most of /usr/share/doc for example and iirc the man-pages so its not a great fit for the classic env
<mvo> pitti: we could simply create another artifact with livecd-rootfs
<mvo> pitti: I wonder what lxd is doing to build the ubuntu image? maybe we can use that?
<pitti> mvo: I left a note and a TODO in the spec
<pitti> mvo: lxc has pre-built images available for download, indeed
<pitti> mvo: we don't have "lxc" installed to actually call the templates, but we could of coruse just hardcode the URL
<pitti> mvo: but we would then depend on something.linuxcontainers.org, not on *.ubuntu.com infrastructure
<pitti> http://images.linuxcontainers.org/images/ubuntu/vivid/amd64/default/
<mvo> pitti: yeah, lets discuss in budapest, but my plan-b would be to just create another artifact on cdimage.u.c via livecd-rootfs
<pitti> right
<pitti> mvo: I'll adjust my prototype to use a hardcoded URL to the lxc tarballs for now
<mvo> pitti: thanks!
<mvo> elopio: I'm a idiot, the snappy-workaround issue is found and I uploaded a fix, thanks to pitti, will create a new image now
 * yashi_ tring to send a fix to lp...
<yashi_> https://code.launchpad.net/~yashi/snapcraft/snapcraft
<mvo> pitti: thanks for the spec update, I just looked over it, you mostly replied to the comments, right? and the open question? the rest looks ok?
<pitti> mvo: "making frustrating typos" != "idiot", happesn to everyone!
<pitti> mvo: I also added some new comments, yes
<pitti> mvo: open q?
<mvo> pitti: indeed, thanks :) I feel a bit silly for not spotting it earlier
<mvo> pitti: the open question about were to get the tarball from
<pitti> mvo: ah, right
<mvo> great, I think that spec is in good shape then
<mvo> yashi_: nice!
<mvo> yashi_: if you click on "prose for merging" and then propose to merge it into "lp:snapcraft" it will appear on the radar of the snapcraft developers automatically :)
<pitti> mvo: meh, need to think about what to do with /etc/resolv.conf
<mvo> pitti: oh, indeed :/
<yashi_> mvo: done.  Thanks :)
<fgimenez> good morning
<mvo> hey fgimenez, good morning
<fgimenez> hi mvo i'm going to check elopio's concerns. is all set in alpha, right?
<mvo> fgimenez: yes, I found the bug why the workarounds ording was not quite correct and fixed it
<mvo> fgimenez: the image is building right now in alpha
<fgimenez> mvo, great! :) the image is ready for testing?
<fgimenez> mvo, ah ok :)
<pitti> mvo: btw, what does your workaround do?
<dholbach> good morning
<pitti> mvo: I mean, it's usually more elegant to create a /lib/systemd/system/pppd-dns.service.d/snappy.conf with an extra ExecStartPre=, or changing/deleting the ExecStart= command, or something
<pitti> mvo: then you can restart/stop pppd-dns.service and things still work correctly; you don't need to be aware of re-running the workarounds.service as well, etc.
<pitti> hey dholbach, wie gehts?
<dholbach> hey pitti - sehr gut - und dir?
<pitti> dholbach: prima, danke
<mvo> pitti: aha, nice. I will keep that in mind
<dholbach> pitti, thanks for looking at the ffe
<pitti> dholbach: no worries, that's a trivial one
<dholbach> yeah, I could imagine there's going to be another upload before release,  but it should be smaller to be reviewed
<dholbach> mvo, asac: upload snapcraft 0.2 to wily
<mvo> fgimenez: new image available, I do a quick test now
<fgimenez> mvo, thanks on it
<mvo> fgimenez: systemd analyize tells me the order is now correct
<fgimenez> mvo, trying the update from 178 now. it's still not available on alpha, right?
<mvo> fgimenez: not in alpha yet, I can do that now
<mvo> fgimenez: there should be a new amd64 alpha now based on r185
<fgimenez> mvo, thanks a lot, i'll try it now 178 -> 185 worked fine for ppp \o/ http://paste.ubuntu.com/12552242/
<mvo> fgimenez: yay!
<fictionedge> Hi everyone
<fictionedge> Can anyone tell me what's the best way to submit a few suggestions to the developers team?
<dholbach> fictionedge, if it's about snappy, the mailing list should be a good start: http://lists.ubuntu.com/mailman/listinfo/snappy-devel
<asac> dholbach: uploaded or you want me to upload :)?
<fictionedge> @dholbach it's about the general installation process for future releases
<nothal> fictionedge: No such command!
<fgimenez> mvo, 11 -> 13 worked fine too http://paste.ubuntu.com/12552292/ :)
<fgimenez> mvo, i'll run the tests against 13 now
<fictionedge> just joined the list thank you dholbach
<mvo> cool
<pitti> mvo: http://people.canonical.com/~pitti/tmp/setup-classic.sh updated for a few glitches
<pitti> mvo: resolv.conf now works OOTB, I un-snappify the core tarball, and I added a policy-rc.d
<pitti> mvo: so apt-get update/install postfix in the chroot now DTRT
<mvo> pitti: nice! postfix DTRT means the service is not started but it does get started on the next reboot, right? (just to be sure I'm on the same page)
<pitti> mvo: correct
<pitti> mvo: or when you systemctl restart classic-container
<pitti> mvo: I need to make this a bit more precise -- if you apt-get install in "machinectl login classic", it actually should start
<pitti> mvo: but I don't think we want to advertise logging into the container too much
<mvo> pitti: yeah, I would love to have a mechanism via policy-rc.d that would notify the host that it needs to do something like"machinectl login classic" to start it
<mvo> pitti: but only if that can be made robust :)
<mvo> pitti: but maybe its not feasible, not sure
<pitti> mvo: that would be in invoke-rc.d
<pitti> mvo: yeah, we could do something like that too
<pitti> maybe it's even possible to do in policy-rc.d, that would be much nicer
<mvo> probably not for now, I guess we should wait for the budapest discussion
<pitti> right, before we waste too much time on the details of this
<mvo> but it would be nice from a user experience point of view, but then we have the problem what systemctl inside the snappy classic env should show etc
<mvo> so there are more questions :)
<dholbach> asac, already uploaded
<dholbach> pitti, snapcraft is in binNEW because of a new -examples package - could you take a look?
<davidcalle> dholbach, I'm having issues with a snap, could you have a look?
<dholbach> davidcalle, what's the issue?
<davidcalle> dholbach, my "glue" bash script is calling bzr, and bzr has issues running (eg. can't find bzrlib), it's probably a path issue, I'm wondering if I'm doing things wrong in my snapcraft.yaml
<davidcalle> dholbach, http://bazaar.launchpad.net/~davidc3/+junk/snapcraft-doc-snap/view/head:/snapcraft.yaml
<davidcalle> dholbach, (the snap is pretty straightforward, go webserver + bzr imports snapcraft doc + script to convert it to html)
<dholbach> taking a look in a bit
<davidcalle> dholbach, thanks :)
<pitti> dholbach: hm, shouldn't that be in /usr/share/doc/snapcraft/examples/ ?
<dholbach> pitti, hmmm.... http://pastebin.ubuntu.com/12552504/
<pitti> dholbach: right, I just checked the deb, hence my question
<dholbach> ah ok, sorry
<dholbach> my mistake
<dholbach> I'll prepare 0.2.1
<pitti> err, /usr/share/doc/snapcraft-examples/examples I meant
<dholbach> I'm happy with whatever
<dholbach> if it needs to be /usr/share/doc/snapcraft-examples/examples that works for me
<pitti> dholbach: well, "needs to be" -> that's the standard path to put examples into
<pitti> not a biggie, but that's what /usr/share/doc/ is for
<dholbach> ok
<pitti> dh_installexamples should DTRT
<pitti> dholbach: danke!
<dholbach> yep
<dholbach> davidcalle, I'll get to it later, if that's all right - I have a few things to figure out first
<dholbach> or ask m-vo or s-ergiusens
<davidcalle> dholbach, no rush! Nothing urgent :)
<dholbach> ok, good
<JamesTait> Good morning all; happy Friday, and happy Comic Book Day! ð
<dholbach> mvo, pitti: https://code.launchpad.net/~dholbach/snapcraft/0.2.1/+merge/272362
<dholbach> brb
<mvo> timchen119: could you please try https://people.canonical.com/~mvo/tmp/ubuntu-device-flash-128mb-boot-plus-fw-dir
<timchen119> mvo, ok
 * Chipaca suddenly finds himself down a performance rabbithole and tries to get out
 * ogra_ sends a fox to speed this up 
<clobrano> LOL
<Chipaca> on the one hand, I just cut a test from 0m7.208s to 0m0.072s
<Chipaca> so I basically just made snappy.VersionCompare 100Ã faster
<Chipaca> on the *other* hand, not that many people have 10k versions of a package installed, that it would make a difference
<Chipaca> ah, no, that's with 1k versions, not 10k. Much more real-world a test case.
<mvo> Chipaca: woah!
<mvo> Chipaca: \o/
<Chipaca> mvo: and I can knock down the 100k testcase from 22 seconds to 15 seconds if i change snappy.chOrder to be a table
<Chipaca> mvo: i think i might draw the line above this one though :)
<mvo> Chipaca: I look forward to that branch
<Chipaca> mvo: it's fun, but i'm glad i got to a table quickly (because tables are ugly) :)
<Chipaca> otherwise i might've been trapped all day
 * mvo nods
<Chipaca> otoh if we were using go:generate the table is totally generate'able :)
<Chipaca> mvo: https://code.launchpad.net/~chipaca/snappy/sort-perf/+merge/272372
<Chipaca> clobrano: whenever you check whether a file exists and if it does not you then create it you are creating a race
<Chipaca> clobrano: somebody can create the file (with content) between you checking and you creating
<clobrano> Chipaca: ooh, right!
<clobrano> Chipaca: thank you :)
<Chipaca> clobrano: e.g. the write it out in file.tmp, then move it to file just after you checked and before you created
<Chipaca> clobrano: boom, you just stomped on their file
<clobrano> Chipaca: sure
<Chipaca> clobrano: note that with snappy right now that's not as possible because it has a global lock, but the snappy rest api does not
<clobrano> Chipaca: I understand, but (apart from snappy) is always something to think about :)
<Chipaca> yep
<Chipaca> clobrano: then there's the symlink considerations, and using openat instead of open, but i think we can leave those for now
<Chipaca> probably need to comb the code to grab those at some point though
<Chipaca> ah
<Chipaca> clobrano: could you add O_NOFOLLOW to the O_CREAT etc ?
<Chipaca> clobrano: that's syscall.O_NOFOLLOW
<Chipaca> not portable :-/
<clobrano> Chipaca: sure, but O_NOFOLLOW is for?
<Chipaca> clobrano: i'll answer that in a bit
<Chipaca> clobrano: meanwhile, let me ask
<Chipaca> clobrano: how far away are you from me?
 * Chipaca hides
<Chipaca> clobrano: :)
<Chipaca> clobrano: i thought of a better way of doing this thing
<clobrano> Chipaca: far away? Do you mean geographically? :D
<Chipaca> yeah, in case you wanted to throw something at me
<Chipaca> clobrano: it's that i just realised there's no reason to create the file at all at that point
<Chipaca> clobrano: unless i'm missing something?
<clobrano> Chipaca: I'd like, but I'm in Italy
<Chipaca> clobrano: just, try to read it, if you fail, move on
<Chipaca> clobrano: so you start with ârules, err := ioutil.ReadFile(udevRulesFile)â
<Chipaca> clobrano: and check err != nil && !os.IsNotExist(err)
<Chipaca> clobrano: you'll have the content of the file, or an empty slice, in rules
<Chipaca> clobrano: and that's all you need
<clobrano> Chipaca: first, sorry I didn't get at all the joke before ;D. You're talking about addUdevRule right? What if it's the first rule? The file does not exist at all
<Chipaca> yes, talking about addUdevRule
<Chipaca> clobrano: if it's the first rule, ie if the file does not exist
<Chipaca> clobrano: you're creating an empty file
<Chipaca> clobrano: and then reading that with ioutil.ReadFile
<Chipaca> clobrano: right?
<clobrano> Chipaca: uhmm, I think you're right
<Chipaca> clobrano: so ioutil.ReadFile will return an empty slice of bytes, because the file is empty
<Chipaca> clobrano: but ioutil.ReadFile will return a nil slice when it can't open the file
<Chipaca> clobrano: and appending to a nil slice, and appending to an empty slice, results in the same thing
<clobrano> Chipaca: ReadFile will return no errors?
<Chipaca> it will
<Chipaca> it will return a non-nil error
<Chipaca> but os.IsNotExist(err) will return true
<Chipaca> hence, you'd do: rules, err := ioutil.ReadFile(...)
<Chipaca> if err != nil && !os.IsNotExist(err) { return err }
<Chipaca> capisci?
 * Chipaca couldn't resist
<clobrano> Chipaca: ahahahaha
<clobrano> Chipaca: sorry, just a sec
<clobrano> Chipaca: sure I think it's fine. AtomicWrite will create the file if it doesn't exist, right?
<Chipaca> yes
<clobrano> then ok, I couldn't see any drawback
<clobrano> Chipaca: done it, test it, ready to push it (I just added a comment to the code, since that could be not immediate to understand)
<clobrano> :)
<Chipaca> L(
<Chipaca> :) i mean
<Chipaca> L( is an off-by-one :)
<Chipaca> clobrano: did you follow up the .precommit thing?
<clobrano> Chipaca: yes, I did. I still have to check something with Bazaar-explorer, since it fails to find golint, but bzr by command-line it's fine
<Chipaca> clobrano: you probably need to manipulate PATH from your bzr plugin so it finds golint
<Chipaca> clobrano: or install golint into ~/bin :)
<Chipaca> (assuming ~/bin is in your PATH, which it is by default if it exists)
<clobrano> Chipaca: yes, it should be something like that
<clobrano> I set both GOPATH and GOBIN, but explorer seems to ignore it
<clobrano> and added GOBIN to PATH
<Chipaca> clobrano: where did you do those additions, and where do you start explorer from?
<clobrano> Chipaca: that's the point. The definitions are in my bashrc, and I couldn't find the name of the explorer bin to run it from shell
<Chipaca> clobrano: dpkg -L bzr-explorer | grep /bin/
<clobrano> Chipaca: nada
<Chipaca> clobrano: dpkg -L bzr-explorer | grep .desktop | xargs grep Exec=
<clobrano> but I found the .desktop with your command! Thanks
<Chipaca> heh :) yep
<clobrano> yep ;)
<clobrano> Chipaca: I think I could open another bug :p. Bzr does not list "explorer" as basic command in its help :D
 * Chipaca gives up and installs bzr-explorer
<Chipaca> clobrano: sure it does, it's right there
<Chipaca> ah, as *basic* commands
<Chipaca> well, it's hardly basic :)
<clobrano> Chipaca: well, for a basic user, a GUI is better than a shell ;)
<clobrano> Chipaca: but ok, the command its in the full list
<clobrano> Chipaca: done. Let me know if it's fine now
<Chipaca> augh!
<clobrano> :D
<Chipaca> clobrano: commented inline
<ogra_> Chipaca, hmpf ... webdm doesnt start on my last Pi2 image
<Chipaca> ogra_: i can't even get it to build here
<ogra_> webdm ?
<Chipaca> yes
<Chipaca> i am not building raspberry pies
<Chipaca> although i do have raspberry jam
<ogra_> http://paste.ubuntu.com/12554435/
<ogra_> thats during forst boot
<ogra_> *first
<Chipaca> ogra_: and did you?
<ogra_> webdm_snappyd_0.9.service - Snappy WebDM
<ogra_>    Loaded: loaded (/etc/systemd/system/webdm_snappyd_0.9.service; enabled; vendor preset: enabled)
<ogra_>    Active: failed (Result: start-limit) since Fri 2015-09-25 13:43:14 UTC; 1min 13s ago
<ogra_>   Process: 1072 ExecStart=/usr/bin/ubuntu-core-launcher webdm webdm_snappyd_0.9 /apps/webdm/0.9/snappyd (code=exited, status=1/FAILURE)
<ogra_>  Main PID: 1072 (code=exited, status=1/FAILURE)
<ogra_> not actually informative
<ogra_> syslog has:
<ogra_> Sep 25 13:44:57 localhost ubuntu-core-launcher[1230]: Snappy: 2015/09/25 13:44:57 handlers.go:52: Initializing HTTP handlers...
<ogra_> Sep 25 13:44:57 localhost ubuntu-core-launcher[1230]: Snappy: 2015/09/25 13:44:57 handlers.go:59: decoding problem
<ogra_> thats the most recent 15.04 image btw
<ogra_> (which i thought we plan to release today :/ )
 * ogra_ wonders why nobody did hit that during testing 
<ogra_> fgimenez, do you have webdm running on your armhf and amd64 tests for the last 15.04 edge or alpha image ?
<fgimenez> ogra_ nope, i'll try to reproduce
<ogra_> seems my amd64 auto-upgraded to 186 and there i see webdm run
<ogra_> i dont have a BBB around to check if it is perhaps arm specific
<fgimenez> ogra_ then flash alpha 11 for bbb, install webdm, update should be enough?
<ogra_> fgimenez, yes
<ogra_> well, i flashed edge
<fgimenez> ogra_ ok, let me try
<ogra_> and no upgrade ... i just used u-d-f on the last edge image
<longsleep> ogra_: mhm webdm works fine in my 15.04/stable
 * longsleep did not test edge yet
<ogra_> weird
<ogra_> i did build that image with --device raspi2_armhf ... i wonder if that forces an amd64 webdm to be installed or some such
<longsleep> well id installed webdm later on the device
<longsleep> -d
<ogra_> ah, dd is done, lets see if it behaves differently without that option
<ogra_> screen -r
<ogra_> oops
<ogra_> EFOCUS :P
<ogra_> hmm, not caused by the --device option, still failing here
 * ogra_ removes and reinstalls webdm
<ogra_> nope, same issue
<longsleep> ogra_: let me try mine
<ogra_> trying with alpha 12 here now ...
 * ogra_ waits for dd
<longsleep> ogra_: webdm runs fine on my odroid
<ogra_> sigh
<longsleep> ubuntu-core   2015-09-17 5
<longsleep> webdm         2015-09-24 0.9
<ogra_> ah, but thats stable
<longsleep> yeah
<ogra_> havent gotten to that yet :)
<ogra_> sigh, so alpha doesnt work either
<Chipaca> clobrano: you need to set a commit message on the merge request
 * longsleep builds an edge image now
 * ogra_ builds stable 
<longsleep> damn .. no space left on device  - foo!
<ogra_> bah
<longsleep> too many kernel build trees :/
<ogra_> heh
<ogra_> sigh
<ogra_> stable doesnt uncompress the kernel for me :/
 * ogra_ re-tries
<jbdatko> Anyone know if the snappy image for BBB needs the SD card to run or can it run completely from the eMMC? The instructions talk about replacing the bootloader on the emmc...
<clobrano> Chipaca: what should the content be?
<Chipaca> clobrano: a short description of the changes in the branch?
<Chipaca> oh!
<Chipaca> and one more thing
<Chipaca> clobrano: make a nochange commit with --fixes lp:1497299
<Chipaca> clobrano: e.g. bzr ci -m 'fixes lp:1497299' --fixes lp:1497299 --unchanged
<Chipaca> clobrano: and push that also
<clobrano> Chipaca: ook
<zyga> morphis: hey, I'm back now
<zyga> morphis: does the security template work for you?
<zyga> morphis: I merged the documentation changes and I'm about to rebuild and see if the snap works with the template for me
<morphis> zyga: I just applied the last changes I got from jdstrand
<morphis> can report in some minutes
<zyga> morphis: ok, thanks
<morphis> zyga: but pushed the change so you can test too
 * zyga builds
<zyga> make clean; make
<zyga> I love that
<longsleep> ogra_: webdm works fine here with edge
<longsleep> ubuntu-core 2015-09-25 170     ubuntu
<longsleep> (installed via ssh though, not together with u-d-f)
<clobrano> Chipaca: done
<Chipaca> https://code.launchpad.net/~chipaca/snappy/dddddirs/+merge/272430 for great justice^Wduhr duhr
<ogra_> mvo, so any idea about the oem snap ?
 * ogra_ quickly gets some food
<Chipaca> ogra_: so, you get ErrDecode from oem.Oem() in two cases: one is a bad package.yaml
<Chipaca> ogra_: the other is an unreadable package.yaml
<Chipaca> 	yamlPath := filepath.Join("/oem", oem[0].Name(), oem[0].Version(), "meta", "package.yaml")
<Chipaca> which is rather circuitous, but there you go
<Chipaca> ogra_: so
<ogra_> http://paste.ubuntu.com/12555387/
<Chipaca> ogra_:  if the version in the yaml does not match the directory
<Chipaca> ogra_: would be one failure mode
<ogra_> how would thw dir match anything ?
<Chipaca> ogra_: that is
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ls /oem/pi2/
<ogra_> IBbBKVKXNDAQ  current
<Chipaca> eep
<Chipaca> why is it sideloaded?
<ogra_> right, cant match :)
<ogra_> because it is built using u-d-f --developer-mode
<ogra_> with the --oem option
<Chipaca> so
<ogra_> thats how we port to new devices
<Chipaca> something is out of sync
<Chipaca> umm
<Chipaca> ogra_: update snappy in webdm
<Chipaca> ogra_: because oem[0].Version() should do the right thing here, and it isn't :)
<ogra_> ??
<ogra_> snappy in webdm ?
<Chipaca> ogra_: you didn't rebuild webdm?
<ogra_> why would i
<Chipaca> ogra_: because it embeds snappy
<Chipaca> ogra_: new snappy => new webdm
<Chipaca> more or less
<ogra_> i only use u-d-f like i did the last few releases for rpi
<Chipaca> u-d-f *also* embeds snappy :)
<ogra_> and bumped the version in the pi2 snap
<Chipaca> but that's not here nor there
<ogra_> and i'm using the lastes u-d-f i think
<Chipaca> so
<Chipaca> ogra_: webdm needs to be built agains the same version of snappy as the system snappy
<Chipaca> ogra_: otherwise breakage happens
<Chipaca> (you effectively have two different snappy implementations on the system)
<ogra_> right, so we will see breakage on other systems too then
<Chipaca> yes
<Chipaca> or rather
<Chipaca> no
<ogra_> i mean, i'm not using anything special
<Chipaca> because it doesn't understand the versioning thing
<Chipaca> :)
<Chipaca> so, webdm needs attention
<ogra_> webdm hanst been rebuilt in months
<Chipaca> yeh
<Chipaca> this is not good :)
<ogra_> right
<Chipaca> ogra_: do you have vivid?
<ogra_> trusty
 * ogra_ isnt sure, probably vivid on the lappie
<Chipaca> ricmm: where did you try to build webdm (and failed)?
<Chipaca> i think it needs a vivid, but i might be wrong
<Chipaca> and it might be broken beyond that :-/
<Chipaca> ogra_: one of the reasons the rest api is important is to decouple webdm
<ogra_> ah
 * ogra_ is surprised to be the first one to actually hit an issue, these pieces must be massivel out of sync
<ogra_> and that since a while
<ogra_> i uess i could work around by pushing the 0.16 pi2 untested to the store then .... then it wouldnt be sideloaded
<Chipaca> ogra_: i thought you'd tested it with everything except webdm?
<ogra_> there is just something inside me screaming "dont upload untested, idiot !!!"
<ogra_> well, yeah
<Chipaca> ogra_: the broken bit here is webdm
<Chipaca> clobrano: congratulations, btw :)
<longsleep> ogra_: my version in /oem is just 0.3 - why is yours a hash version?
<longsleep> ls /oem/odroidc/
<longsleep> 0.3  current
<longsleep> i am using vivid to build the images with ubuntu-device-flash 0.20snappy7-0ubuntu1.2
<fgimenez> nice weekend everyone o/
<ogra_> longsleep, all sideloaded snaps get a hash version nowadays
<ogra_> so you are lucky because the snappy on the machine you called u-d-f on is old
<longsleep> ogra_: um, i think it is the latest from the ppa
<longsleep> aha - i am using snappy-dev-beta ppa - snappy-dev has newer :/
<longsleep> ogra_: switched to snappy-dev/tools and now i have 0.31 - thanks for the hint!
<ogra_> our PPAs are a mess :/
<longsleep> ogra_: so the theory is that if i now create a new image with the newer u-d-f then webdm stops working for me as well?
<ogra_> right
<ogra_> well, if you use the --oem switch pointing to a local snap
<ogra_> only sideloaded snaps get that hash version
<longsleep> ogra_: yes thats what i am doing with the odroid oem snap, verifying now
<ogra_> \o/
 * ogra_ humps Chipaca's leg 
<ogra_> WOOF !
<ogra_> i has workin webdm !!
 * Chipaca has a headache
<ogra_> so pushin the snap to the store and using that makes everything work fine
<ogra_> wow ... what a waste of my afternoon :/
<longsleep> ogra_: so webdm currently breaks for any sideloaded snaps ?
<ogra_> oem snaps, yes
<longsleep> ah only oem ok
<longsleep> good that i used an old u-d-f to create my image then :)
<ogra_> :)
<Chipaca> no, it'll break for any snap
<Chipaca> sideloaded
<ogra_> oh
<ogra_> ok
<Chipaca> the services will be confused
<ogra_> well, it will still start at least if the oem one isnt sideloaded
<Chipaca> right, so i should qualify that
<Chipaca> snappy and webdm will have different opinions of where things should go
<longsleep> ah, well that image i built with new u-d-f does not even boot :/ seems like i just got some work todo :(
<Chipaca> and will break if you mix and match
<ogra_> yeah
<Chipaca> but if you use webdm, it'll mostly work
<Chipaca> except for the bugs due to not having random versions for sideloaded apps
<Chipaca> also none of the fixes in snappy-the-binary will be used by webdm
<Chipaca> some might say this is bad :)
 * ogra_ curses
<ogra_> this rpi image starts getting on my nerves
<ricmm> ogra_: whats the matter with it
<ogra_> well, i tried to build an image from the s-i srver bits and ended up with a generic kernel ...
<ogra_> it funnily booted, i only noticed the wrong kernel after 30min testing :(
<ricmm> lol
<ricmm> should just merge into that generic then
<ricmm> if it actually booted...
<ogra_> we tried that but rickspencer3 would be really unhappy ... we needed to add a plethora of patches to make all the bits work he wants
<rickspencer3> ruroh
<rickspencer3> no pwm? no i2c, no spi?
 * ogra_ doesnt really get how he ended up with the worng device tarball now :(
<rickspencer3> what would you even do with that?
<ogra_> run owncloud or kodi :)
<rickspencer3> heh
<ogra_> ogra@nusakan:~$ grep raspi2 /srv/system-image.ubuntu.com/etc/config|tail -1
<ogra_> file_device,raspi2_armhf = http;http://people.canonical.com/~platform/snappy/raspberrypi2/device-pi2.tar.xz;name=device,monitor=http://people.canonical.com/~platform/snappy/raspberrypi2/builddid
 * ogra_ slaps forehead ...
<rickspencer3> poor ogra
<ogra_> indeed the s-i server points to an unversioned tarball
<ogra_> (i uploaded device-pi2-0.16.tar.xz)
#snappy 2015-09-26
<ZN30> hello
<ogra_> bjf, i updated the rpi doc to point to the correct commands and versions ...
<tedg> Woot! RPi images, thanks ogra_ !
<ogra_> :)
<peacememories> i'm a bit confused. i just built ubuntu-device-flash (on fedora, with sources taken from launchpad), but it doesn't seem to have the options described on the "porting" wiki page
<peacememories> i mean, yeah... i took the source from the goget-ubuntu-touch package, but i didn't find anything else
<tbr> maybe outdated documentation, certainly wouldnt' be the first time with snappy
<peacememories> but would they really remove the oem image and file output options?
<peacememories> basically what i'm trying to do is build custom core images with preinstalled software to flash onto some devices we have at work
<ogra_> ogra@styx:~/Devel/branches/wget$ apt-cache show ubuntu-device-flash|grep Depends
<ogra_> Depends: android-tools-adb, android-tools-fastboot, debsig-verify, click-ubuntu-policy, dosfstools, fakeroot, kpartx, parted, qemu-user-static, ubuntu-snappy-cli, libc6 (>= 2.6)
<ogra_> peacememories, you would have to make sure that all runtime deps  used for building core images are there too ... (and if anything is in different locations you would need to bend the paths in the source i guess)
<ogra_>  click-ubuntu-policy, dosfstools, fakeroot, kpartx, parted and ubuntu-snappy-cli in any case ... if you want to build for non x86 arches also qemu-user-static
 * ogra_ would simply use a VM or some kind of emulation to run a minimal ubuntu instead ...
<peacememories> using a vm (a container in my case) would work for me, but my problem isn't that the software doesn't work, it just doesn't recognize the options
<yashi_> peacememories: which one?
<peacememories> --oem for example
<peacememories> which, according to the wiki could be used to supply an oem snap specifying preinstalled software ect.
<peacememories> *etc
<ogra_> --oem is only allowed in developer mode
<ogra_> (well, a local oem snap that is)
<ogra_> otherwise if you specify ..oem it needs to be a valid package from the store ...
<yashi_> btw, is there a way to _search_ oem snap?
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ snappy search oem|wc -l
<ogra_> 9
<ogra_> finds 8 (plus a header line)
<yashi_> how about on a host?
<ogra_> sabdfl, are you booting your RPi with a screen attached ? (where do you see these dots, i have never seen them, but i also only watch the boot via serial console)
<sabdfl> ogra_, yes, screen andkeyboard
<ogra_> how long did you wait ?
<ogra_> cloud-init on arm can take up to 2-3min on first boot
<sabdfl> an hour or so
<ogra_> hmm
<ogra_> yashi_, https://uappexplorer.com/apps?q=oem&sort=relevance&type=snappy
<ogra_> ;)
<ogra_> sabdfl, i'll try here, just need to find a free monitor that will take a bit
<yashi_> ogra_: that's what i did and found out that your rpi isn't there
<sabdfl> thanks ogra_
<sabdfl> also, is there a preferred ppa to get the new 4.2 rpi2 kernel from?
<ogra_> sabdfl, the wily archive ;)
<sabdfl> my favourite ppa :p
<ogra_> the kernel team uploaded it last week
<ogra_> yashi_, indeed, thats weird ... i definitely see it in webdm on all my snappy installs ... probably a bug in uappexplorer (which is mainly made for phones, snaps are just a freebie based on luck :) )
<yashi_> ogra_: ;)
<peacememories> ogra_, i think i should specify that i'm trying to create images for intel NUCs, not to flash smartphones
<peacememories> so i'd need --oem and -o. how would i get into developer mode?
<ogra_> by using --developer-mode
<ogra_> and yes, it was relatively clear to me that if you ask in #snappy you want to build snappy images ;)
<peacememories> sorry^^
<peacememories> thanks for your help
<ogra_> heh, np
<ogra_> sabdfl, hmm, so i get a proper login prompt and also the normal kernel boot noise on boot ... i wonder if there is something wrong with the image
 * ogra_ pulls http://people.canonical.com/~platform/snappy/raspberrypi2/ubuntu-15.04-snappy-armhf-rpi2.img.xz to make sure he sees the right boot :)
 * yashi_ struggling to setup $GOPATH when I hack on goget-ubuntu-touch
<yashi_> u-d-f dpends on snappy, so I setup GOPATH=somehere then I also have goget-ubuntu-touch under $GOPATH
 * ogra_ twiddles thumbs while watching dd ...
<ogra_> sabdfl, ok, i verified there is everything ok with the image itself even a fresh download boots properly ... lets find out what went wrong for you ... a) did you download from http://people.canonical.com/~platform/snappy/raspberrypi2/ubuntu-15.04-snappy-armhf-rpi2.img.xz b) did you verify the md5 (or sha256/sha512) sum against the download
<ogra_> sabdfl, also, how did you write the image to the SD ... it needs to be uncompressed first and you need to write to the whole device, not a partition ... my common command is: xzcat ubuntu-15.04-snappy-armhf-rpi2.img.xz | sudo dd of=/dev/sdc bs=4M
<ogra_> (where /dev/sdc is my USB SD controller ... native SD controllers would show up as /dev/mmcblk0)
<peacememories> ogra_, sorry to bother you again but ubuntu-device-flash doesn't seem to know the developer-mode flag O.o
<ogra_> well, it definitely does for me
<ogra_> whats the error you see
<peacememories> maybe i'm misunderstanding where to get the newest version... i'm on 0.23 right now (the newest version i could find on launchpad)
<ogra_> oh
<ogra_> we're somewhere around 0.31
<peacememories> ah yes, i clicked on the wrong dropdown it seems
<peacememories> my bad
<ogra_> https://launchpad.net/ubuntu/+source/goget-ubuntu-touch
<ogra_> but --developer-mode is supported since "core" is supported iirc
<ogra_> or at least shortly after it was introduced
<peacememories> 0.31 doesn't know the flag either
<ogra_> whats the error ?
<peacememories> like i said above: "unknown flag `developer-mode'"
<ogra_> how does your command look like ?
<peacememories> oh...OOOH, i need to specify those flags _after_ the core argument... well...
<ogra_> yeah
<peacememories> *facepalms*
<ogra_> dont facepalm ... i think it took me 3 months to not mess that up all the time :)
<peacememories> thanks again =)
<ogra_> np
<peacememories> hm, creating images needs root permissions? note sure how i feel about that
<ogra_> it needs to partiton and loop mount the img
<ogra_> and uses kpartx for that
<ogra_> there is perhaps a fuse way to get around this ... not sure
<ogra_> (but that would need implementation indeed)
#snappy 2015-09-27
<sabdfl> ogra yes, i decompresses with xz -d then dd if=... of=/dev/mmcblk0 bs=1M
<sabdfl> ogra xzcat ubuntu-15.04-snappy-armhf-rpi2.img.xz | md5sum
<sabdfl> how does one get a serial interface on the rpi2? do i need a breakout board for the 40-pin headers or can i do it over usb?
<sabdfl> dc2715982039ebc63e5febc17fbae78d  -
<sabdfl> ogra: digests check out fine against the web listing
<ogra_> sabdfl, serial is by default on the outside row of the 40 pin header on pin 6, 8 and 10 (pin 1 is at the corner of the PCB near the power LED) http://www.element14.com/community/docs/DOC-73950/l/raspberry-pi-2-model-b-gpio-40-pin-block-pinout. i use a cable like http://www.amazon.de/gp/product/B00KVUSI30
<sabdfl> my GPS hats use that, unfortunately
<ogra_> (any other FTDI cable should do as well)
<sabdfl> is there a way to do TTY over USB?
<ogra_> right, then we need to disable it in /boot/uboot/config.txt
<sabdfl> on the rpi sd card?
<ogra_> yes, boot without the hat, then you can edit it
<ogra_> do you have make and modle of the hat, i bet there are instructions how to set up the config.txt
<ogra_> *model
<sabdfl> can i edit it while mounted?
<ogra_> there is indeed a way to do serial over USB ... but only from a kernel module ... (i.e. it would only provide output after boot) we were pondering to enable that by default (like the BBB has)
<ogra_> yes, indeed its a normal file on a filesystem ... you can just edit away and reboot to test the change
<tbr> you can even do kernel console on cdc-acm
<tbr> but it's a bit tricky
<ogra_> tbr, right, but not bootloader
<tbr> correct
<tbr> although
<ogra_> the question is if we could live with disabled bootloader console by default
<tbr> would need to ask Tartarus if uboot can do cdc-acm too
<sabdfl> ogra, gps hat instructions are at https://learn.adafruit.com/adafruit-ultimate-gps-hat-for-raspberry-pi/pi-setup
<sabdfl> but nothing there seems to map to system-boot partition
<tbr> would depend on the usb controller
<sabdfl> uboot.env seems to have some ttyAMA stuff
<ogra_> sabdfl, oh, it changes the cmdline ... thats a bit more tricky than config.txt because snappy assembles it from multiple vars and places
<ogra_> yeah, one sec
<ogra_> sabdfl, on the booted board run:  sudo fw_setenv mmcargs 'setenv bootargs "${args} console=tty0 root=${mmcroot}"'
<ogra_> fw_printenv is the command to show all config optios
<ogra_> (if you want tro check before and after)
<sabdfl> so boot without the hat then do this?
<ogra_> yeah
<sabdfl> on snappy?
<ogra_> right
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep console
<ogra_> mmcargs=setenv bootargs "${args} console=tty0 console=ttyAMA0 root=${mmcroot}"
<ogra_> thats the default ...
<sabdfl> ok will try that
<ogra_> ah, the board seems to also need 9600 baud
<ogra_> that might need further changes
 * ogra_ guesses we should move all console options by default to the cmdline.txt file, seems all documentation expects it there
<ogra_> sabdfl, bug 1500164 :)
<ogra_> hmm, no bot ?
<ogra_> https://bugs.launchpad.net/snappy/+bug/1500164
<ubottu> bug 1500164 in Snappy "console= cmdline options on the RPi2 should be moved from uboot.env to cmdline.txt" [Undecided,New] https://launchpad.net/bugs/1500164
<ogra_> ah
<sabdfl> ogra_ in a similar vein, we should call our new kernel "rpi2" not "rasp2"
<ogra_> well, thats something the kernel team decided
<ogra_> we'll have to talk to them
<sabdfl> there is a community guy who make a linux-image-rpi2
<sabdfl> we should sync with him and have one kernel
<ogra_> ah, i didnt know ... i'll carry that forward to ppisati ...
<sabdfl> thank you
<kivi> Woah, look who's here
<kivi> Just going to say; I'm a huge fan. Thanks for all the work you have done. :)
<sabdfl> many folks on this channel qualify for that :)
<sabdfl> ogra, i still see dots :(
<ogra_> damn
<sabdfl> it's probbly the GPS chatting away on ttyAMA and interfering with uboot
<ogra_> well, or just the wrong baud rate ....
<sabdfl> i think uboot says "press a key to interrupt" and the GPS presses a key for me :)
<ogra_> first of all, drop the two "dtparam=" lines from config.txt
<ogra_> oh
<ogra_> hmm
<ogra_> thats tricky ... the stdout setting for uboot is hardcoded, we could only override it from uboot.env which is actually loaded after the prompt
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ fw_printenv |grep stdout
<ogra_> stdout=serial,lcd
<ogra_> droppin serial from that would help for any later stuff but not for the prompt itself
<ogra_> lets see if the binary bootloader offers something to forcefully disble serial
<ogra_> i know there is a second serial port somewhere on these headers, perhaps we can force switch to that one
<ogra_> hmm, using the uart1 DT overlay makes my board hang on boot
<ogra_> oh, no, only the output :P
<ogra_> i can actually ssh in
<ogra_> sabdfl, so is there a chance to re-wire your gps hat to other pins ?
<ogra_> via the uart1 DT overlay we should be able to force the second serial port on ...
<ogra_> which can be configured for pin 32/33 instead of 14/15
<ogra_> oh, wait !
<ogra_> sabdfl, i just see we are actually loading uboot.env early enough for overriding the serial input ...
 * ogra_ tries it out 
<ogra_> sabdfl, try if: sudo fw_setenv bootdelay 0
<ogra_> helps in any way
<ogra_> that should make it not listen to key presses (or other input) during boot
<ogra_> sabdfl, did you get my last messages ... ?  "sudo fw_setenv bootdelay 0" should turn off the listening for input during boot, if your borad actually stops because the GPS sends chars that might solve it
<sabdfl> hi ogra_ i missed that message but will try it when i am in budapest :)
<ogra_> safe flight :)
<sabdfl> i hope so!
<sabdfl> should be a good week, everyone seems well prepared
<ogra_> yeah, curious what you guys bring home :)
 * ogra_ will have a joyful jaw surgery instead of enjoying hungarian beer :) 
<jdstrand> beuno: fyi, something weird is happening with the store: https://myapps.developer.ubuntu.com/dev/click-apps/3560/
<jdstrand> beuno: look at the feedback, there are two errors but its because the server traced back
<jdstrand> beuno: the app itself is showing 'Pending review' still
<beuno> jdstrand, right, the review failed and I guess it got stuck in pending review
<beuno> pindonga, matiasb, ^^
 * beuno is off to bed
<jdstrand> pindonga, matiasb (and beuno): fyi, the review failed, but not for the appropriate reasons-- ie, the scripts traced back for some weird reason (running the scripts locally, that doesn't happen)
<ogra_> beuno, if i do "snappy search oem" that doesnt find the pi2 oem snap, does the search not include types ?
<ogra_> (snappy search pi2 finds it ...)
#snappy 2016-09-26
<tenaciousmv> has anyone built snaps with private git/npm dependencies?
<mup> Bug #1595987 changed: udev denials  <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1595987>
<morphis_> mwhudson: ping
<mwhudson> morphis_: hi
<mwhudson> morphis_: sounds like you know more about wifi details than me, do you want to submit a probert pr?
<morphis_> mwhudson: I could but not real soon
<mup> PR snapd#1994 opened: snap: add `snap known --store` <Created by mvo5> <https://github.com/snapcore/snapd/pull/1994>
<morphis_> mwhudson: but I think using something like https://pypi.python.org/pypi/libnl/ to talk with the kernel would be a good thing
<mwhudson> morphis_: huh hadn't seen that one
<morphis_> mwhudson: however I think for the short term not breaking when the error occurs and requesting CONFIG_CFG80211_WEXT enabled in the kernel is a good start
<mwhudson> morphis_: i guess the patch i added is at least better than doing nothing
<morphis_> yeah
<morphis_> mwhudson: but we shouldn't close the bug with this
<mwhudson> exactly
<mwhudson> netlink is so very ... the sort of api a kernel developer would think of, i guess
<morphis_> yeah
<mwhudson>     while RTA_OK(hdr, remaining):
<mwhudson> also it's 1930 here and i'm going to try not to work every evening this week :-)
<morphis_> mwhudson: yeah, I agree with that!
<morphis_> mwhudson: just one last question
<mwhudson> heh
<morphis_> mwhudson: I am currently hitting the problem that I can't enter @ anymore in the "Profile setup" screen
<morphis_> mwhudson: this is on the edge channel
<mwhudson> morphis_: !
<morphis_> on beta it works still
<mwhudson> morphis_: it worked on an image i made today
<mwhudson> 738
<morphis_> hm
<mwhudson> on a dragonboard
<morphis_> then it must be my keyboard or so
<morphis_> this is on a pi3
<mwhudson> morphis_: over serial or usb?
<mwhudson> i know some keymap related stuff was added to the image recently
<mwhudson> but i didn't think we were doing anything with that yet
<morphis_> its over a usb keyboard plugged into the dongle
<morphis_> and having the pi on a hdmi screen
<mwhudson> yeah, that's the setup i was using
<morphis_> then it seems to be a image problem
<mup> PR snapd#1995 opened: interfaces/builtin: fix resolvconf permissions for network-manager interface <Created by morphis> <https://github.com/snapcore/snapd/pull/1995>
<morphis_> ogra_: ping
<zyga> good mornign
<zyga> *morning
<dholbach> hey hey
<didrocks> hey dholbach, zyga
<didrocks> dholbach: snap-codelabs is available FYI
<dholbach> wow wow wow
<dholbach> nice work didrocks
<dholbach> mhall119_, popey_: ^
<didrocks> dholbach: based on mhall119_ first snapcraft.yaml, but quite tweaked to make it lightweight then :)
<dholbach> well done!
<dholbach> didrocks, hum, which port does it listen on?
<didrocks> dholbach: see the snap long description :) 8123
<dholbach> ah yes, of course
<dholbach> great
<liuxg> recently, I use nodejs to compile some project, in some cases, if I add some modules, the compilation fails. I am not sure whether this is related to our nodejs plugin or not. thanks
<morphis_> pitti: I've updated https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 , can you have another look?
<pitti> morphis_: I already did some minutes ago
<pitti> morphis_: as I said, this is fine for a PoC in a PPA, but this is not a "solution"
<pitti> packaging a leaf application might have this namespacing, but if you want to provide OS components as snaps they can't have the same restrictions
<pitti> the idea was to isolate stuff, not hardcode alternate names for snap OS parts in a hundred places (plus breaking third-party stuff which we can't control)
<morphis_> pitti: there needs to be a lot more love happening but I still think if netplan is included on ubuntu core it shouldn't come with not functional support for backends
<morphis_> pitti: I totally agree with that
<morphis_> pitti: but that is what is giving today with snaps and netplan is included as a first class citizen on Ubuntu Core so it should take care about what it supports today and ask for changes those things solved
<morphis_> pitti: I see the risk that somebody doesn't know about that patch included in the ppa and then just release a new upstream release and overrides everything
<popey_> didrocks: tried to find it on my pi, and it can't find codelabs, is that because it's amd64 only?
<morphis_> ogra_, mvo: so are you guys accepting not-upstream-patches for the netplan debian package in the ppa which ends up in the OS snap? not sure how the maintenance goes here but there needs be some ensurance that those changes are not overriden by anyone trying to bring in a new release from upstream netplan
<ogra_> morphis_, wll, they need to be gone from the PPA and landed in -updates before november
<morphis_> pitti: ^^
<didrocks> popey: yeah, I didn't build armhf binary (yet)
<popey> ok
<ogra_> if you guys think thats manageable, sure, lets have it in the PPA til then... the inal release must come from -updates
<ogra_> *final
<popey> didrocks: I can build it on my pi here if you want, where's the branch?
<pitti> well, then you move it from being your responsibility to fix snaps to being my responsibility to ever get rid of this :)
<morphis_> ogra_: the thing is pitti does not agree with https://code.launchpad.net/~morphis/netplan/+git/netplan/+merge/306607 and does not want it in netplan upstream
<pitti> and it's certaily not the only place that calls nmcli, like netplan isn't the only package that expects NetworkManager.service or bluez.service or cups.service or whatnot
<ogra_> right, so the quetion is if it can be a distro patch in xenial ...
<morphis_> ogra_: so if we can't keep the netplan package in the ppa after the final release then then this needs to be considered differently
<ogra_> or if you guys find a proper solution before nov.
<pitti> yes, a distro patch in the xenial backport would be more bearable
<ogra_> we will keep it in the PPA, but th btea and stable images wont use the PPA
<pitti> although it's still completely wrong
<pitti> this has to be fixed properly anyway at some point..
<morphis_> ogra_: what do you mean by beta images?
<didrocks> popey: it's not just a question of snapcraft snap unfortunatly, you need to have a go env ready
<didrocks> popey: I guess it's quicker if I do it, one sec
<pitti> ogra_: ok, I'll start putting together a NetworkManager SRU for the netplan support patches then
<ogra_> morphis_, https://wiki.ubuntu.com/QATeam/OSSnapPromotion
<pitti> ogra_: I guess you currently have that in the PPA? (which one is that?)
<ogra_> eventually only edge will use the PPA
<ogra_> all other channels come from proposed or updatess later
<ogra_> (later = by release)
<pitti> not in https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<morphis_> ogra_: so the current beta images don't use the ppa?
<ogra_> pitti, we have "a" netplan there
<mup> PR snapd#1996 opened: daemon: add the actual ssh keys that got added to the create-user response <Created by mvo5> <https://github.com/snapcore/snapd/pull/1996>
<didrocks> popey: can I fake a snapcraft snap on some arch?
<popey> didrocks: when you say "long description" for the port number, where's that?
<pitti> ogra_: right, but netplan does not work with xenial's NM
<popey> didrocks: dunno
<ogra_> morphis_, currently they do, but we are workibng on getting all the PPA changes into -updates before release
<popey> didrocks: I just have classic on my pi, so can use it to snapcraft things, works fine
<didrocks> popey: I think nothing apart from uappexplorer exposes it
<popey> oh, okay
<didrocks> popey: hum, ok, so, I will need you :)
<didrocks> I can give you the binary
<morphis_> ogra_, pitti: good then lets keep the patch as a distro one even for -updates
<ogra_> morphis_, see the wikipage ... within the next two-three weeks wthis will be implemented
<morphis_> pitti: I know that there will be a discussion to allow snaps shipping things like "nmcli" so they end up with a prefix "network-manager."
<popey> didrocks: i installed it, and see nothing on that port
<didrocks> popey: http://localhost:8123?
<popey> yes
<didrocks> weird, did it work for you dholbach?
<ogra_> pitti, well, i guess it works with the snapped NM ...
<dholbach> didrocks, yes
<popey> ignore me didrocks
<popey> pilot error
 * didrocks ignores popey FOREVER!!! :)
<popey> \o/
<didrocks> ;)
<didrocks> popey: so, git clone that branch: https://github.com/ubuntu/codelabs
<popey> works now :)
<morphis_> ogra_: it does
<didrocks> I'll give you a binary to replace
<didrocks> phew!
<pitti> morphis_, ogra_: ah, ok; so you don't actually need these patches in xenial-updates then, it seems?
<pitti> the NM ones, I mean
<ogra_> we dont ?
<morphis_> pitti: no, for the snap we don't need the nm patches in the deb package
<ogra_> ah, right ... i guess we dont use the deb for packaging the snap
<morphis_> pitti: we're not using the deb package for the snap at all
<dz0ny_> btw, will you guys open source build server for snappys? currently it's a bit problematic building snaps for different platforms
<morphis_> dz0ny_: you can already build snaps on launchpad for any architecture
<dz0ny_> oh
<dz0ny_> didn't know
<didrocks> popey: take this binary and replace the one in the root dir with it: http://didrocks.fr/temp/codelabs
<didrocks> popey: then, you should be able to build the snap
<didrocks> (for armhf)
<dz0ny_> morphis_: care to share link
<popey> didrocks: ok
<morphis_> dz0ny_: push a branch and look for a "Create snap package" on the overview site
<morphis_> dz0ny_: like here: https://code.launchpad.net/~morphis/+junk/pi2-kernel-snap
<ogra_> dz0ny_, upload your tree (bzr or git) to launchpad ... then you can pick "create snap"
<popey> didrocks: what about "server" in that same directory, also an amd64 binary
<dz0ny_> ah thx
<didrocks> popey: silly me
<didrocks> I didn't copy the right bin
<popey> lulz
<morphis_> ogra_: so can you upload a new netplan package then to the ppa if I give you one?
 * ogra_ grins about mwhudson and cyphermox playing pingpong with bug 1621550
<mup> Bug #1621550: Snappy should detect when running in KVM, specify correct ssh connection line <Snappy:New> <subiquity (Ubuntu):Triaged by cyphermox> <https://launchpad.net/bugs/1621550>
<ogra_> morphis_, sure, who will work on getting it into update ? you or pitti ?
<ogra_> *updates
<didrocks> popey: so, the one you want is http://didrocks.fr/temp/server :)
<didrocks> I didn't recompile the other one, it's not shipped in the snap
<didrocks> (it's only to build the metadata)
<morphis_> ogra_: don't know, I just care to have it in the beta image we're doing for our customer this week at the moment :-)
<popey> :)
<morphis_> pitti: can you take the -updates one?
<ogra_> morphis_, well, i care to not lose it once we turn off the PPA :)
<morphis_> yeah
<pitti> morphis_: that's backport netplan with that PR?
<morphis_> yes
<ogra_> well, preferably get the one from the PPA into updates
<ogra_> not ure if there are other changes
<ogra_> *sure
<ogra_> (i didnt put it thre)
 * pitti creates an SRU bug
<morphis_> pitti: thanks!
<ogra_> ppisati, so i see an oops on the pi3 ... sadly only in the combo of having console=tty0 and HDMI enabld but i think it is somehow related to the wifi card
<ogra_> i wonder if it is the same thing i saw on the bbb
<ppisati> ogra_: can fill a bug with the cmdline used to provoke this?
<ogra_> i can even give you an image that expoes it ... as long as you dont plug in a wire on first boot ... but it scrolls offscreen and there is no wayx to get proper logs before the user is set up ... which need working network
<ogra_> *needs
<ogra_> the pi3 image from http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ has it ..
 * ogra_ files bug 
<pitti> morphis_: tracking in bug 1627641
<mup> Bug #1627641: Backport netplan to xenial <network-manager (Ubuntu):Fix Released> <nplan (Ubuntu):Fix Released> <network-manager (Ubuntu Xenial):Triaged by pitti> <nplan (Ubuntu Xenial):Triaged by pitti> <https://launchpad.net/bugs/1627641>
<ogra_> ppisati, bug 1627643
<mup> Bug #1627643: oops on pi3 (seemingly wlan related) <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1627643>
<morphis_> pitti: ok, are you going to create a deb package with that patch now too?
<morphis_> just that we do not do the same work twice
<pitti> morphis_: yes; we eventually want to use netplan for cloud-images etc. as well, so at some point we'll need them; and I'd rather have the integration tests actually succeed
<pitti> morphis_: (they cannot work without the NM patches)
<morphis_> pitti: ok, can you hand that package to ogra_ then so that we can include it in the ppa real soon?
<mup> Bug #1627643 opened: oops on pi3 (seemingly wlan related) <Snappy:New> <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1627643>
<pitti> morphis_: why? AFAIK snappy edge is built with -proposed enabled, so it would suffice to just have it there? (which we can do today still)
<pitti> morphis_: I suppose you just backported Read-config-from-run.patch and Read-system-connections-from-run.patch (I'm not aware of anything else that's needed, but I'll verify with nplan's test/integration.py)
<ogra_> pitti, no, we turned off proposed (it caued skews)
<ogra_> *caused
<pitti> but if you aren't going to use the NM distro package, why do you need it in the PPA then?
<ogra_> we need it on the image
<ogra_> which means in the ubuntui-core snap
<pitti> oh, nplan doesn't backport as-is, need a pep8 fallback for pycodestyle
<pitti> still confused -- if you use an NM snap, you won't need the xenial-updates NM package with the /run patches in the snappy PPA
<pitti> and if you use the distro package, then why bother with the snap and that ugly nplan patch?
<ogra_> no, i will need the xenial-updatess nplan
<pitti> oh, this was about nplan, not NM
<ogra_> regarding NM we only care about the snap ... and that nplan doesnt break it when users install it by accident i guess
<ogra_> break it -> the NM deb of xenial
<ppisati> ogra_: i guess that is a 4.4 kernel, right?
<ogra_> ppisati, whatever is recent in xenial, yeah
<ogra_> 4.4.0-1023-raspi2
<ppisati> ogra_: k
<pitti> erk, NM is stuck in xenial-proposed (v-failed), pinging Aron
<morphis_> pitti: as, those two patches are what we did
<morphis_> pitti: in edge later today is fine through -proposed but we need it in beta by the end of the week
<morphis_> pitti: if that is doable with the SRU, then I am fine, if not lets use the ppa
<pitti> morphis_: oh, please do use the PPA; I just wanted to start the process for SRUing now
<morphis_> pitti: ok, we can take the package you push to -proposed and copy it to the ppa
<pitti> morphis_: there is a NetworkManager stuck in xenial-proposed (verification-failed), so we can't get NM into -proposed today
<morphis_> ok
<morphis_> pitti: can you ping me once the package is in -proposed?
<pitti> morphis_: sure; I also subscribed you to the bug so you get updates from that too
<morphis_> awesome!
<mup> Bug #1624490 changed: Snap access to /dev/uinput <hardware> <snapd-interface> <uinput> <Snappy:New> <https://launchpad.net/bugs/1624490>
<mup> PR snapd#1997 opened: tests: added install_local function <Created by fgimenez> <https://github.com/snapcore/snapd/pull/1997>
<ogra_> morphis, http://ubunt.eu/zQa7Xs definitelly needs aethercast so you can have it fly while working ;)
<sborovkov> Hello. Anyone knows what's going on with ubuntu store? I can't submit any new snaps. getting unrecoverable error. And bunch of 503 when navigating the page.
<cjwatson> sborovkov: There was a network issue recently, but if that was it it should be recovering now.
<sborovkov> understood, thanks.
<diddledan> random thinking which I'm sure has already been considered, but I wanted to mention it anyway: gui snaps can only display text using fonts installed in the snap when it was built from what I can tell with unofficial-hexchat. would be nice to share fonts between system and snaps
<morphis_> pitti: looks like we should just update the exiting netplan package in the ppa rather than integrating recent new changes
<pstolowski> jdstrand, hey! can you have another look at https://github.com/snapcore/snapd/pull/1832 ?
<mup> PR snapd#1832: interfaces/builtin: support time and date settings via 'org.freedesktop.timedate1 <Created by stolowski> <https://github.com/snapcore/snapd/pull/1832>
<jdstrand> pstolowski: yes
<didrocks> popey: did you build the armhf snap for me to upload?
<didrocks> I wonder if I can't otherwise, cheat with snapcraft ;)
<popey> didrocks: I did, but I moved location and can't ssh to the pi now :)
<popey> damn firewalls!
<didrocks> haha! Who did this! :)
<didrocks> popey: can wait tomorrow then, no worry ;)
<popey> ta
<popey> it installed but I didnt get an open port and didn't have time to check logs before I left, will take a look later
<didrocks> oki!
<mvo> Ã¶kt
<mvo> pitti: hi! it looks like we may need sysfsutils as a snapd dependency
<mvo> pitti: and therefore make it part of main, so that we can setup bits in /sys at boot time. or is there a different way to ensure /sys values are set on boot?
<pitti> mvo: I'm sorry, do you REALLY mean sysfsutils?
<mvo> pitti: maybe, so let me start differently. we need something that can set values in /sys
<pitti> mvo: this is really not what you are looking for
<mvo> pitti: oh, ok - glad I talked to you :)
<mvo> pitti: what am I looking for?
<pitti> mvo: man sysctl.d :)
<pitti> mvo: *phew* :)
<mvo> pitti: the man page talks about /proc/sys - it seems like we need /sys however. sorry, I'm sort of the messanger here only, zyga is working on gpio bits and we need to set some bits in /sys to control the right gpio
<pitti> mvo: oh yes, that's sysctls for /proc/sys, I thought that's what you actually  meant
<pitti> mvo: otherwise you want udev rules
<mvo> pitti: aha, thanks, udev rules because /sys is too dynamic for the approvach that sysfsutils took?
<mvo> zyga: you probably find the above useful -^ :)
 * zyga looks
<pitti> mvo: no, but sysfsutils was an evolutionary dead-end
<zyga> oh, interesting, thank you pitti!
<zyga> pitti: was it related to libsys2
<pitti> mvo: it's completely useless and does not give you anything that you cannot already do with udev rules or just shell scripts, except for being racy
<pitti> mvo: and it has been abandoned like 10 years ago
<pitti> mvo: hence me being incredulous, sorry :)
<zyga> it should be removed from the archive eventually :)
<mvo> pitti: totally fine, I was earnest when I said "glad I talked to you" :)
<zyga> but I'm also glad we talked, this is much easier
<zyga> pitti: so a design question I have, perhaps: if snapd would like to generate such .conf files, should they live in /etc (which the man page reserves for the administrator) or in /run (which would require snapd to start and write them before stuff that may depend on it would)
<zyga> pitti: hold that, I just realized I skipped the most essential message about using udev rules
<zyga> pitti: so this is all irrelevant, thanks
<pitti> zyga: yeah, there's always those two last crappy rdepends which keep it alive (FSVO "live")..
<pitti> zyga: I dislike autogenerated files in /etc, as /etc should really/ideally be "settings that the admin did", not something fixed or derived
<pitti> i. e. only "primary" configuration
<pitti> zyga: so if these get derived from some other/primary config, putting them into /run is much better
<pitti> zyga: it also eases your life as then it stays an internal implementation detail which you can change at any time
<shuduo> mvo: hi, i'm trying to compile nextcloud snap target armhf on pc. then snapcraft --target-arch armhf complains "copy" plugin don't support cross compile. you have helped me on snapcraft 1.x. may i know any  solution for 2.x?
<pitti> zyga: with /etc it never goes away and you need to deal with it on upgrades
<mup> PR snapd#1998 opened: debian: re-add golang-github-gosexy-gettext-dev  <Created by mvo5> <https://github.com/snapcore/snapd/pull/1998>
<zyga> pitti: is there a nice place we could put files in /run for udev to pick up?
<pitti> zyga: /run/udev/rules.d/ ?
<zyga> pitti: thanks, I see
<pitti> zyga: but, maybe we sohuld take a step back and clarify what you want to do
<zyga> pitti: right now I'm not going to change that but it seems like something we may want to explore down the line
<pitti> zyga: i. e. which kind of sysfs attrs do you want to change, and at which point in time
<zyga> pitti: well snapd has a way to influence various bits of the kernel
<zyga> pitti: here we specifically want to export a GPIO pin to userspace
<pitti> zyga: I mean, in the simplest case snapd could just open()/write() the attributes at startup and be done with it
 * ogra_ wonders if you rather want a snippet in /etc/sysctl.d in your package 
<zyga> ogra_: no, because this is dynamic and it depends on interfaces
<ogra_> ah, that GPIO thing again
 * ogra_ remembers we talked abot it before 
<pitti> zyga: that doesn't sound like you would need to do that super-early in the boot sequence?
<zyga> pitti: currently when an interface needs to use udev rules we just write them to /etc/udev.d/snap.* and reload udev
<ogra_> but yeah, why not just write to /sys then ?
<pitti> zyga: if you need to apply that to "any future hotplugs", then yes, let snapd put udev rules into /run/udev/rules.d/
<zyga> pitti: well, before any snap apps start
<ogra_> without udev
<pitti> future hotplug events, I figure
<zyga> pitti: I don't know if GPIO is very hotpluggable
<pitti> if that's a thing, write temp udev rules, then trigger those in snapd, and let the rules take care of future events
<zyga> pitti: this is more about having a way to influence bits in sysfs
<morphis_> zyga: what is the problem with the current implementation of the GPIO iface in snapd?
<zyga> morphis_: it doesn't work across reboots, it writes to sysfs whenever you ask for a snippet
<morphis_> right
<morphis_> zyga: should we add something like InitializeIfaceConnectionOnSnapdStartup()
<morphis_> for an interface?
<zyga> morphis_: for this case we should use udev rules for that
<zyga> morphis_: everything else is persistent already
<morphis_> how would udev rules apply to to sysfs nodes for GPIO's?
<zyga> morphis_: 'echo' :)
<zyga> morphis_: udev can just run any command
<pitti> morphis_: erk, no
<morphis_> zyga: sure but you need an event, right?
<pitti> ATTR{yourattrname}="value"
<pitti> yeah, you need to "coldplug" (udevadm trigger) them after writing to apply to existing devices
<zyga> pitti: we already do that
<pitti> "udevadm trigger --subsystem-match=gpio" or something suhc
<zyga> pitti: well, we do a generic one
<ogra_> dont ... that eats resources ... limit it to the subsystem
<zyga> ogra_: we don't know this
<ogra_> :)
<zyga> ogra_: we cannot limit anything at this time
<ogra_> now you do :)
<ogra_> hmm
<sil2100> Hey! I have a newbie problem in a quick python3-app snap I'm creating
<zyga> ogra_: no, we don't know this in snapd, the udev code doesn't know what snippets are doing
<zyga> ogra_: we'd have to provide richer data
<zyga> ogra_: or parse existing data
<ogra_> but your interface does, doesnt it ?
<zyga> ogra_: no
<zyga> ogra_: interface has no way to tell
<ogra_> if i'm the gpio interface i know i want to act on gpio's ...
<zyga> ogra_: the author might but the interface API would have to be changed in a somewhat major way to convey that today
<pitti> or run it before systemd-udev-trigger.service, but then it must run really early, without many assumptions
<zyga> ogra_: it's not something that's easy to change
<zyga> ogra_: then you have to combine the  changed subsystems
<zyga> ogra_: and in the end you might save some memory/whatever or get it wrong :/
<zyga> ogra_: that's not something for this release
<didrocks> sil2100: hey, what's up with it?
<ogra_> ok ok
<ogra_> :)
<mup> PR snapcraft#828 opened: yaml xpath for errors <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/828>
<sil2100> My snap is a standard python3 plugin-based snap, it installs some modules and a python script to /usr/bin/ as expected, but... after installing the snap and trying to run it, I em getting an 'exec: <command here>: not found'
<sil2100> Even though when checking the /snap installation place, the script is in the usr/bin/ directory as expected, also the wrappers *should* set the PATH correctly
<sil2100> But still, the launcher cannot find the script
<didrocks> interestingâ¦ You should have a .wrapper script that the script in /snap/bin points to, correct?
<didrocks> this is just shell, you can open it and look at what's added to your env
<sil2100> Yes, examined the wrapper and everything seems to be ok there
<didrocks> PATH is set?
<didrocks> to your $SNAP/usr/bin ?
<sil2100> I examined all the scripts that are executed on the way and it should be all good, with PATHs being set etc. but it doesn't seem to work
<didrocks> you can try:
<didrocks> snap run --shell <your command>
<sil2100> Oh
<didrocks> you will then be dropped in a shell, with the snap parameter
<didrocks> just before the wrapper is run
<ogra_> also ... snap install hello-world ...
<didrocks> and maybe poke from there?
<sil2100> Yeah, hello-world works fine
<ogra_> then you can use helo-world.env to get info about the default vars
<sil2100> Just my snap has some issues with the paths
<ogra_> or hello-world.sh to spawn a shell inside the snap env
<sil2100> Oh, ok, thanks for the pointers, let me dig further then
<sil2100> :)
<ogra_> :)
<didrocks> I guess snap run --shell will land him in the right context for his snap, with his code nearby and such ;)
<ogra_> all that new-world stuff ... pfft :P
<morphis_> pitti: did you upload a new netplan package already somewhere?
<sil2100> didrocks: this is really strange, I checked the environment variables when in --shell and the $SNAP variable is set correctly, I also hacked inside an echo $PATH right before the exec part in the final wrapper and the PATH also seems to be set correctly
<pitti> morphis_: no, I didn't; still working on that networkd regression; but netplan itself needs no change other than adjusting the Breaks:
<morphis_> pitti: I am going to create just an updated nplan package over the one we already have in ppa to cause no big regressions
<sil2100> didrocks: and the /snap/landing-team-tools/x1/usr/bin dir has the binary as required, doing a simple PATH=/snap/landing-team-tools/x1/usr/bin:$PATH image-info (which is the command name) works in the same shell
<mup> PR snapd#1999 opened: daemon: add REST API behind `snap get` <Created by kyrofa> <https://github.com/snapcore/snapd/pull/1999>
<sil2100> Let me try removing setting the LD_LIBRARY_PATH in the wrapper script
<sil2100> hm, yeah, it seems that setting the LD_LIBRARY_PATH seems to somehow break the exec line, making it not find the binary
<pitti> morphis_: sure; as I said, go wild with the PPA for now
<morphis_> aye
<didrocks> sil2100: interestingly weird
<ogra_> asac, *sniff*
<pitti> morphis_: I just figured out the necessary networkd fix (the previous one was a red herring)
<pitti> morphis_: however, with LP (and other caonical services) being down I can't update/upload anything :(
<morphis_> pitti: yeah!
<zyga> oh, launchpad is down
<modprobe__> Trying to create a snap, but after all of my parts finish priming, snapcraft just exists saying "[Errno 21] Is a directory: '/home/dev/swv/prime/.'" (where my snapcraft.yaml is in /home/dev/swv/)
<modprobe__> I've got three different custom plugins in this snap, though. This project does not go into a snap without a fight.
<modprobe__> But none of those plugins do anything unusual except during the build step
<ogra_> slangasek, i assume you have seen my comment on bug 1627146 ?
<mup> Bug #1627146: ubuntu-image creates 'small' ext4 filesystems, which take forever to resize <Ubuntu Image:Fix Committed by vorlon> <https://launchpad.net/bugs/1627146>
<qengho> I sure wish something would warn me that my snap has a vulnerability in OpenSSL that was fixed today.
<qengho> My snap was uploaded from a recipe in Launchpad. It could fire off builders, and then email me a link to upload the builder results to Edge channel, and another to upload to Stable channel.
<qengho> I wonder how hard it would be to write a snap scanner that looked for patterns that suggest a vulnerable version of dependency. Like a virus-scanner pattern searcher.
<slangasek> ogra_: yep - sorry, didn't get it fixed over the weekend because of final beta trubs, but will get that sorted today
<ogra_> no hurry ... i run my own ubuntu-image meanwhile ...
 * slangasek nods
<ogra_> just wanted to make sure you didnt miss it
<mup> PR snapd#1963 closed: daemon, overlord, store: add ReadyToBuy API to snapd <Reviewed> <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1963>
<mup> PR snapd#1847 closed: many: discard preserved namespace after removing snap <Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1847>
<mup> PR snapcraft#829 opened: sources: fix type when calling with depth <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/829>
<mup> PR snapcraft#830 opened: python plugin: only replace proper shebangs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/830>
<mup> PR snapcraft#831 opened: 'sign-build' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/831>
<mup> Bug #1627813 opened: AppArmor denies access to /etc/ld.so.preload on armhf <Snappy:New> <https://launchpad.net/bugs/1627813>
<oparoz_> Is there an online interface for the snap store where we can find snaps? It seems each developer sees his own or we have to use snapweb which doesn't list everything
<mup> PR snapcraft#795 closed: WIP: snap-build generation and pushing support <Created by caio1982> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/795>
<kyrofa> ogra_, I'm confused. Why does this https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/ recommend downloading ubuntu classic for rpi? Isn't that supposed to be a snappy page?
<kyrofa> ogra_, it's causing questions like this: https://raspberrypi.stackexchange.com/questions/55516/snappy-ubuntu-core-lose-ethernet-connection-after-updating
<ogra_> kyrofa, because we still dont have official series 16 images ... though the betas might soon be good enough to replace that text
<ogra_> (wasnt my choice btw)
<kyrofa> ogra_, yeah I figured it wasn't your choice, just that you knew the story behind it ;)
<ogra_> it is a few months old when we had no images at all
<kyrofa> ogra_, might be handy to spell out somewhere "these are not ubuntu core images!"
<kyrofa> Right
<ogra_> well, i think such pages should slowly start pointing to the betas ... i guess with the next beta release they might be good enough (the dailies have surely a lot bugs fixed now)
<mup> PR snapcraft#830 closed: python plugin: only replace proper shebangs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/830>
<mup> PR snapd#1922 closed: tests: use apt as compatible with trusty <Reviewed> <Created by vosst> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1922>
<mup> PR snapcraft#828 closed: yaml xpath for errors <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/828>
<Marcus> Hi
<Guest8706> I just discovered Ubuntu Core, I would like to know which one is appropiate Ubuntu Core/Desktop/Server?
<Guest8706> I want to program soft real time application using boost library
<kyrofa> Guest8706, on what hardware will the program run?
<Guest8706> anyone could help me? Thank you!
<Guest8706> mini-PC
<kyrofa> Guest8706, will it be headless? Or do you need a graphical interface?
<Guest8706> industrial PC
<Guest8706> for testing and validation ghapical interface would be useful but not main requirement
<Guest8706> It would control cameras and laser, so sync is realy important
<kyrofa> Guest8706, how do you envision updating it?
<kyrofa> Guest8706, also, is this a one-off for your own use, or a product you intend on providing to others?
<Guest8706> a product, for selling to another company
<Guest8706> is a critical system, so we would not perform many updates
<Guest8706> kyrofa, what do you recommend?
<kyrofa> Guest8706, will it be connected to the internet?
<Guest8706> VPN
<kyrofa> Guest8706, what I'm really asking it, say you DO need to update it. Will it be able to retrieve the update via the internet, or will the user need to sideload it somehow?
<Guest8706> It would be installed outside and connected by fiber optic to the local network
<Guest8706> second option I guess
<kyrofa> Guest8706, and last question: you say soft real time, i.e. you don't expect a real-time kernel?
<Guest8706> real time is desirable, but I think I would think LinutRT or similar, is that ok?
<Guest8706> So I need to be able to control priorities of threads
<Guest8706> and make sure main process run smoothly
<Guest8706> but I think I dont need a RT OS
<Guest8706> One of my doubts is, Would i be able to use the same libraries? i.e boost library
<Guest8706> I mean when using Core version
<kyrofa> Guest8706, oh sure, the only thing special about ubuntu core is that you'd be required to use snaps
<kyrofa> Guest8706, are you familiar with snaps?
<Guest8706> Not at all
<kyrofa> Guest8706, they're a new packaging format that bundle their dependencies and are transactionally updated (i.e. can rollback upon failure)
<kyrofa> Guest8706, they're also strictly confined, which means they're more secure, but can also cause some challenges when creating the snap if your software it used to being able to walk all over the system
<Guest8706> So, it could be more challeging to set up the system?
<kyrofa> Guest8706, it also automatically updates (including the snap you put on there for your stuff), but if the device isn't connected to the internet that's not much of a win
<kyrofa> Guest8706, are you familiar with debian packaging?
<Guest8706> yes
<kyrofa> Guest8706, particularly considering that being able to login and have a GUI would be useful to you, you might consider simply using ubuntu desktop
<kyrofa> Guest8706, if, however, security is important, you might consider ubuntu core
<Guest8706> ok, thank you Kyrofa
<kyrofa> But without the internet, some of the ubuntu core advantages are negated
<Guest8706> security is important but the local network would be "protected" and traffic limited so I guess it would be OK
<kyrofa> Note that, if you play with the snap packaging format and like it, ubuntu server, desktop, and core can all use it
<kyrofa> (as well as various other linux distributions)
<Guest8706> ok, where could i start?
<kyrofa> Guest8706, right here: http://snapcraft.io/
<Guest8706> I can create snaps and test them on Desktop?
<kyrofa> Guest8706, indeed
<Guest8706> I have been about 10 years without using Linux, I am getting old, everything seems more difficult now, :)
<Guest8706> Thank you very much for your help.
<kyrofa> Guest8706, of course!
<mup> PR snapd#1995 closed: interfaces/builtin: fix resolvconf permissions for network-manager interface <Critical> <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1995>
<mup> PR snapd#1997 closed: tests: added install_local function <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1997>
<mup> PR snapd#1998 closed: debian: re-add golang-github-gosexy-gettext-dev  <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1998>
<mup> PR snapcraft#829 closed: sources: fix type when calling with depth <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/829>
<andywork> i am using the dump plugin to copy something into my snap; i set the source property (which must be a directory), but how do I set what files to be dumped? currently all files in that source directory is being copied into the snap
<andywork> (which I do not want)
<kyrofa> andywork, that's how the dump plugin works-- it dumps everything in the directory into the snap. If you want to blacklist things, you can use the `stage` and `snap` keywords in the YAML
<kyrofa> (or whitelist)
<sergiusens> andyrock like in the `assets` part here https://github.com/snapcore/snapcraft/blob/master/demos/gopaste/snapcraft.yaml#L20
<ogra_> kyrofa, do you know whats the reason for this horrid complexity (vs having the simple copy plugin syntax we had before)
 * ogra_ never understood what was wrong with the copy plugin or why we had to drop it
<andywork> kyrofta, sergiusens: thanks, I'll take a look
<mup> Bug #1627860 opened: run fail at missing folder /lib/modules (eg. on a virtual host) <Snappy:New> <https://launchpad.net/bugs/1627860>
<mup> PR snapcraft#810 closed: nodejs plugin: Add mechanism to run ânpm runâ commands <Created by RAOF> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/810>
<mup> PR snapd#1999 closed: daemon: add REST API behind `snap get` <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/1999>
<mup> PR snapd#1996 closed: daemon: add the actual ssh keys that got added to the create-user response <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1996>
<mup> Bug #1627893 opened: A daemon is denied to write to the home directory <Snappy:New> <https://launchpad.net/bugs/1627893>
<mup> PR snapd#2000 opened: snap, daemon, store: pass through screenshots from store <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2000>
#snappy 2016-09-27
<mup> PR snapd#1975 closed: tests: add test benchmark script <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1975>
<mup> PR snapd#1578 closed: image: add meta/gadget.yaml infrastructure <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1578>
<mup> PR snapd#1953 closed: snap, daemon, store: pass through screenshots from store <Created by robert-ancell> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1953>
<mup> PR snapd#2000 closed: snap, daemon, store: pass through screenshots from store <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2000>
<mup> PR snapcraft#832 opened: WIP LP: #1627880 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/832>
<mup> Bug #1597784 changed: "PermissionError: [Errno 13] Permission denied" executing a snap <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1597784>
<lpotter> Mirv: ping
<Mirv> lpotter: pong
<Mirv> lpotter: I commented on your MP already and merged it, thanks a lot! really happy about getting the locally built qmake into use.
<lpotter> I can help with qt-ubuntu snap. I have it building with the local qmake, but it's installing to wonky director
<lpotter> directory
<lpotter> the build plugin dont recognize $SNAP.
<Mirv> lpotter: in what sense? the current snap in the store installs to usr/lib/arch/ (libs) and usr/lib/arch/qt5 (plugins, qml)
<Mirv> ah, "NAP" :)
<lpotter> :)
<Mirv> I wonder if it's needed at all in the config or not
<lpotter> it is, as without prefix it tries to use / which is not writable to the snap
<lpotter> and I ran into an issue with libpng-dev for some reason
<lpotter> and that libicu will cause issues too
<Mirv> lpotter: I was building on yakkety. As commented on github, it's libpn12-dev on xenial. Fixed it now.
<lpotter> ok, cool
<abeato> ogra_, hi, is the pi2-kernel snap available now? ubuntu-image complains as it cannot download it, and I do not see it with "snap find"
<dholbach> good morning
<dholbach> has anyone of you dealt with node issues like the following already? what's a good way of going about them? "npm ERR! version not found: cheerio@0.20.0"
<mup> PR snapd#2001 opened: overlord/boot: switch to using assertstate.Batch <Created by pedronis> <https://github.com/snapcore/snapd/pull/2001>
<mvo> pitti: is it possible to delete the successful test of ppc64el for snapd? I think this successful test was a mistake, i.e. it happend when there was actually no test executed due to a mistake
<Son_Goku> zyga: ping: https://github.com/zyga/snapcore-fedora/pull/6
<mup> PR zyga/snapcore-fedora#6: Flesh out snapd-glib spec <Created by Conan-Kudo> <https://github.com/zyga/snapcore-fedora/pull/6>
<Son_Goku> mvo, why is snapd-xdg-open not under the io.snapcraft.* namespace?
<Son_Goku> on the bus
<Son_Goku> everything else has moved onto that namespace, so it's weird that this one still retains com.canonical.*
<pitti> mvo: how do you mean? There isn't just one pass in http://autopkgtest.ubuntu.com/packages/snapd/yakkety/ppc64el but many, and 2.13+16.10 actually did run tests
<mvo> Son_Goku: uh, thank you, that looks like an oversight
<Son_Goku> believe it or not, I actually check these things before letting zyga push them into Fedora ;)
<mvo> Son_Goku: heh :)
<mvo> pitti: sorry, I was wrong, tests did run but they were not really useful "OK: 1 passed, 2 skipped"
<mvo> pitti: now we have ~80 tests that are run, 4 fail on ppc64el, I work on skipping or making them pass (our test snaps we uploaded seem to be not fully working on ppc64el)
<mvo> Son_Goku: and sorry that I have not got back to your mail :/ life is a bit busy right now due to some looming deadlines
<Son_Goku> :(
<Son_Goku> well, I was hoping that something could be done before the October sprint, so that I would have something cool to show off, but no worries if not
<mvo> Son_Goku: thats going to be tricky but maybe we can get some quality hack time during the sprint
<Son_Goku> I hope so
<Son_Goku> I've already got that selinux policy module that I need to test to see if it resolves https://github.com/zyga/snapcore-fedora/issues/1
<pitti> mvo: so I can mark the currnet version on ppc64el as "ignore failure"
<mvo> pitti: please do, I will work on making them work again but until then it owuld be great to ignore-failure them so that they do not block the other arches
<pitti> mvo: that won't help much though, as it also regresses on both x86
<mvo> pitti: that will be fixed soon, its actually a regression from snpa-confine
<mvo> pitti: triggered by snap-confine which is used in the tests, but zyga fixed that so the next upload should fix it
<pitti> mvo: ah, good, then we can just retry those; I'll add the ppc hint then
<mup> PR snapd#2001 closed: overlord/boot: switch to using assertstate.Batch <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2001>
<mvo> pitti: thank you
<pitti> zyga: any chance to get the snap-confine SRU in xenial verified?
<pitti> (sitting there for 20 days)
<pitti> zyga: the next version has already been sitting in unapproved for a week, but is blocked by ^
<ogra_> abeato, did you pick the right channel ? (we didnt rellease to stable yet)
<abeato> ogra_, yes, I found out that was the issue in the end, thanks
<mup> PR snapd#2002 opened: tests: use new spread `debug` feature <Created by mvo5> <https://github.com/snapcore/snapd/pull/2002>
<zyga> pitti: I'll check what's going on there, thanks for telling me about it
<kalikiana> Hmm stumbled upon this in another context. Could/ do snaps take advantage of ksm (kernel page sharing) to address memory waste? https://www.kernel.org/doc/Documentation/vm/ksm.txt
<ogra_> kalikiana, yes
<ogra_> (has been discussed multiple times ... i'm not sure about the verdict though)
<kalikiana> ogra_: Ah, cool. Would there be any documentation of what features are currently being used? I wouldn't want to stir up the discussion for the nth time if it's already sorted.
<ogra_> you have to ask the core team ... mvo or niemeyer would know more
<zyga> ogra_: yes?
<ogra_> zyga, ?
<zyga> kalikiana: reading the document I see that this requires MADV_MERGEABLE
<zyga> kalikiana: so only applications explicitly doing that would benefit
<ogra_> zyga, isnt that a wrapper thing ? i.e. ubuntu-core-launcher
<zyga> kalikiana: so snaps could take advantage of this
<zyga> ogra_: no
<mup> PR snapd#1921 closed: tests: replace systemd-run with on-the-fly generation of units <Reviewed> <Created by vosst> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/1921>
<zyga> ogra_: and besides, we cannot do that for the application
<zyga> kalikiana: so I think a more balanced answer is that snapd doesn't prevent apps from using ksm
<zyga> kalikiana: so if they are written to take advantage of it, they can
<ogra_> our kernels have definitely switched it on ...
<ogra_> (at least the official ones)
<zyga> ogra_: right but applications need to use it, otherwise it does nothing
<ogra_> zyga, well, then i dont understand how al the cloud services can make use of it on behzalf of the apps that run in their containers/VMs
<ogra_> afaik they a use that on a VM level
<zyga> ogra_: with madvise(and MADV_MERGABLE)
<kalikiana> zyga: Supposedly qemu can share memory of multiple instances - I wonder how they do it in that general way
<zyga> kalikiana: ^^
<ogra_> dunno, i dont thionk all debs that are used in ubuntu clouds are patched on the fly :)
<zyga> application developers need to explicitly mark private memory pages as mergable
<zyga> probably only virtualization tools use this feature
<ogra_> afaik the sharing theer works on application level and people are surely not using modified debs
<mup> PR snapd#1994 closed: snap: add `snap known --remote` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1994>
<ogra_> so the VM must do something here that snapd/ubuntu-core-launcher should be able to do as well
<zyga> no
<zyga> ogra_: snap-confine lives for a millisecond
<zyga> ogra_: and execs an application
<zyga> ogra_: the appication must understand what is going on and actually sensibly use madvise
<zyga> ogra_: it cannot be blindly enabled
<zyga> ogra_: VMs enable that so that that they can share memory across memory-heavy virtualization but we don't pay that price and we cannot enable it in any way
<zyga> ogra_: but if there's a snap with VM inside then that snap can use this feature internally
<zyga> ogra_: so snapd is not related to ksm in any way, this is application responsibility to use
<mup> PR snapd#2003 opened: debian: adjust packaging setup for trusty/deputy systemd <Created by vosst> <https://github.com/snapcore/snapd/pull/2003>
<mup> PR snapd#2004 opened: cmd/snap: make the buy tests run again and fix the failures <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2004>
<mup> PR snapd#2005 opened: many: introduce a device-init hook, let it optionally configure device registration and the serial-request <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2005>
<mup> PR snapd#1865 closed: overlord/devicestate: POC to parametrise serial-request content/sending <Blocked> <Critical> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/1865>
<morphis_> ogra_: at which time is a new OS snap for edge build daily?
<ogra_> ogra@lillypilly:~$ crontab -l
<ogra_> 30 4 * * * /home/ogra/ubuntu-core-builds/build-ubuntu-core >>/home/ogra/ubuntu-core-builds/build.log 2>&1
<ogra_> 0,30 * * * * /home/ogra/public_html/ubuntu-core-builds/generate-core.sh >>/home/ogra/public_html/ubuntu-core-builds/generate.log 2>&1
<ogra_> ogra@lillypilly:~$
<ogra_> 4:30 UTC
<morphis_> thanks
<morphis_> ogra_: is this generate-core script available somewhere?
<ogra_> morphis_, note though that the store is buggy ... sometimes i get 404s for existing snaps ... which results in them not to have a channel and not being published
<morphis_> ok
<ogra_> sure, on people.canonical.com ;)
<ogra_> (the path is right in there )
<ogra_> thats always the latest version ... its a bit out of sync, but it is also in lp:snappy-dev/ubuntu-core
<morphis_> ogra_: ok
<ogra_> https://code.launchpad.net/~snappy-dev/ubuntu-core-snap/trunk  .... in the cron-scripts dir
<ogra_> morphis_, i brought the branch in sync now
<ogra_> there is also a README in the cron-scripts dir, describing what you need to prepare when using it yourself
<abeato> pstolowski, hi, was wondering how the kmod interface works. If I add a module to an interface, which permissions do I get? can I do modprobe on it?
<zyga> abeato: no, you get that module loaded but you cannot load it yourself
<zyga> abeato: kmod is not an interface it is a "security backend"
<zyga> abeato: interfaces can choose to use it
<abeato> zyga, so the module would get loaded when you connect to a plug that requires that, correct?
<mup> PR snapd#2006 opened: debian: merge 2.15.2ubuntu1 release <Created by mvo5> <https://github.com/snapcore/snapd/pull/2006>
<zyga> abeato: it depends on the design of the interface
<jdstrand> abeato: is there a particular use case you have in mind?
<jdstrand> zyga: good morning/afternoon zyga :)
<jdstrand> and hello abeato :)
<zyga> jdstrand: hello
<abeato> jdstrand, loading ppp modules
<abeato> jdstrand, morning :)
<zyga> jdstrand: I'm working on SRU verification, eh, I "love" our fragmented releases
<jdstrand> abeato: yep, that was the other one that I thought people would add things to immediately
<ogra_> zyga, snappy will fix that :P
<jdstrand> zyga: heh. you can spin that another way-- it is motivating to get things right before release :P
<mup> PR snapd#1979 closed: assertions: add system-user assertion <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1979>
<abeato> jdstrand, zyga just want to load ppp_generic when somebody connects to the ppp interface
<zyga> jdstrand: the problem is the release is right but now I'm in some weird partial state that is never tested
<pstolowski> abeato, yeah, as zyga says
<zyga> ogra_: it was supposed to ;)
<ogra_> :)
<zyga> ogra_: but not for snappy :-(
<zyga> abeato: that's a two-liner then
<ogra_> yeah, there was some irony in my sentence ;)
<zyga> abeato: or maybe even one liner, depending on syntax
<abeato> pstolowski, zyga so this should be just fine, isn't it?: http://paste.ubuntu.com/23242066/
<jdstrand> abeato: yeah, take a look at firewall-control. ppp will be the same. you won't need anything special
<zyga> ogra_: yeah, I know :/
<jdstrand> abeato: specify the modules you want and snapd will handle the rest on interface connect
<abeato> alright, thanks
<pstolowski> yep
<jdstrand> zyga: oh hrmm-- I was hoping the snapd autopkgtest fixes were going to be in place before snap-confine (which is why I suggested that whoever uploads snapd should upload snap-confine)
<jdstrand> oh well, there is a bug in the devel release that will get fixed
<jdstrand> that's happened on occasion :)
<jgdx> after $ sudo snap try prime and prime is removed/changed, I get into a state where I can't remove the snap because: /snap/ubuntu-system-settings/x1: not mounted
<jgdx> it make sense, but it's not known to me how to get out of that situation
<jgdx> any ideas?
<zyga> jdstrand: I'd love to know about that docker workaround
<zyga> jdstrand: I see what it does but OMG what is this doing to make the problem go away
<jdstrand> zyga: it is arguably a bug in docker. it is looking in mountinfo to find where the cgroup directory is. it finds /tmp/snap.rootfs_... and thinks it is there
<jdstrand> zyga: so we let it keep thinking that
<jdstrand> zyga: I noticed in looking at mountinfo from inside a snap that we are leaking those mount locations and also all the mounted snaps
<jdstrand> zyga: ideally we would have a clean mountinfo and we could remove the workaround
<jdstrand> zyga: docker could also update their FindCgroupMountpoint() in runc/libcontainer/cgroups/utils.go, but went with a non-patch approach for now until we decide if there is something we can do (even if it is terribly)
<jdstrand> terribly ugly
<Guest60909> nick pmp
<Guest60909> <-- sry, what an idiot
<mup> PR snapd#2007 opened: interfaces: ppp: load needed kernel module <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/2007>
<zyga> jdstrand: interesting, that explains a lot
<zyga> jdstrand: I don't think that obtaining clean mountinfo is possible though
<zyga> jdstrand: unless I'm missing something it will always contain the real data, even if we managed to unmount everything in clasic (which we cannot)
<sergiusens> zyga the important question is, are you going to target the correct mailing list for the announcement this time ;-)
<zyga> sergiusens: for what? :)
<zyga> jdstrand: as for SRU we have a more nested problem to solve, I need to talk to pitti about it
<zyga> pitti: can you perhaps help me with a little SRU problem
<sergiusens> zyga snapd, snap-confine, ubuntu-core
<sergiusens> zyga I feel like I am the only one using snapcraft-announce!
<zyga> pitti: there's snap-confine 1.0.38-0ubuntu0-something as a pending SRU, I'd like to kill that one and instead upload the one that is currently in the queue here:
<zyga> sergiusens: I agree and I really should use it
<zyga> pitti: https://launchpad.net/ubuntu/xenial/+queue?queue_state=1&queue_text=
<zyga> pitti: or perhaps even .42 from yakkety if mvo manages to release snapd today
<zyga> pitti: I starte verifying the .38 version but I realized it errnously links to bug https://bugs.launchpad.net/snap-confine/+bug/1597842
<mup> Bug #1597842: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Invalid> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1597842>
<zyga> pitti: from my POV the version under SRU currently is okay except that it doesn't fix this particular bug; we can probably either mark it as failed, remove the bug and mark it as passing elsewhere or just skip it entirely and go to .41 or .42
<zyga> pitti: I want to avoid extra delays so I'd appreciate any insight you may give me
<mup> PR snapd#2006 closed: debian: merge 2.15.2ubuntu1 release <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2006>
<mup> PR snapd#2008 opened: overlord/state: prune old empty changes <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2008>
<zyga> jdstrand: do you have a suggestion on how snap-confine could do something differently to make docker work?
<zyga> hmm
<pitti> zyga: no problem, I can cancel that SRU if you want, i. e. we remove it from -proposed; does the next upload address the same bugs also?
<zyga> pitti: yes, it's a superset
<pitti> zyga: if it doesn't fix everything, that's not a problem -- there will always be the next SRU
<zyga> pitti: (full upstream releae rather than a cherry-picked one)
<pitti> zyga: we just must pull an SRU if it regresses something that worked before
<zyga> pitti: hmm
<zyga> pitti: that's not the case here
<zyga> pitti: the fix in .38-0ubuntusomething is just partial
<zyga> pitti: there are no regressions, I just want to find a smooth way to eventually update everyone to .42
<pitti> zyga: hm, http://launchpadlibrarian.net/285662383/snap-confine_1.0.38-0ubuntu0.16.04.10_1.0.41-0ubuntu2~16.04.1.diff.gz removes a metric ton of previous changelogs -- is that a rebase error?
<pitti> ah, it's more like a backport
<pitti> zyga: well, as you wish -- verify 38 and we release it, or skip it and I review/acept .41 "over" it
<zyga> pitti: yes, I think that's more accurate
<zyga> pitti: ok, I cna finish the verification, what should I do about bug https://bugs.launchpad.net/snap-confine/+bug/1597842 then? just mark it as verification-done?
<mup> Bug #1597842: Allow access to the currently running kernel sources from /usr/src <snapd-interfaces> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <Snappy:Invalid> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1597842>
<pitti> zyga: I'd just reopen it and clear the tag after releasing the update (that auto-closes the bug)
<zyga> ok
<zyga> so I'll reopen and re-verify this with .41 that really fixes it
<pitti> zyga: ok; otherwise current SRU is good?
<zyga> pitti: let me verify the last two items
<morphis_> pitti: thanks a lot for https://launchpad.net/ubuntu/+source/nplan/0.12~16.04 !
<pitti> zyga: rihgt, please officially say "works" on some of the bugs
<zyga> jdstrand: curious, how did you debug the docker issue, I think that is pretty esoteric :)
<zyga> pitti: will do
<pitti> morphis_: yw! it needs to grind through the machinery now, and we can hopefully release it in a week
<jdstrand> zyga: since we are in our own mount namespace, I would think we could unmount other snaps to close down the info leak (so long as the unmount didn't propogate. I'm not sure how that would work for /tmp/snap.rootfs_*
<jdstrand> zyga: I found it by noticing that the docker log entry was complaining about that file not existing. I was assuming it was confused about the mount namespace and that /sys was mounted wrong, but thought I'd check out the low hanging fruit and just take docker at its word about the file it was trying to access not existing
<jdstrand> zyga: and that turned out to be the problem
<zyga> jdstrand: well, we might (extra complexity for content sharing) but why why would that matter? we'd still see the load of tmpfs entries
<jdstrand> zyga: I don't think that would complicate content sharing-- we are still mounting the target in SNAP_DATA
<sborovkov> Hello. Just updated my classic image. Now getting this: Sep 27 14:21:34 ubuntu snap[6727]: this GOARM=6 binary. Recompile using GOARM=5.
<sborovkov> This snap ran before just fine
<sborovkov> Any idea what's going on
<jdstrand> zyga: that wouldn't matter for the docker case, you are right. that would only prevent an info leak (leaking all installed snaps) via mountinfo. as it happens there are other leaks there due to accesses in /proc, but we have work items to address that in the medium term
<zyga> jdstrand: I can experiment quickly but I doubt that would change anything for docker
<zyga> jdstrand: mountinfo requires devmode, it's not readable
<jdstrand> zyga: or mount-observe
<jdstrand> zyga: I'm not saying it is a world burning problem
<zyga> jdstrand: hmm, interesting, yes
<jdstrand> just that it is a leak
<jdstrand> unfortunately due to noisy denials due to various libraries, I suspect people will specify mount-observe a lo
<jdstrand> t
<jdstrand> but, like I said, we leak things via /proc. this shouldn't distract for /media or network-namespace or really whatever else is on your plate atm. just wanted to mention it
<jdstrand> as for /tmp/snap.rootfs_*, that would be worth looking into I think (at least after a few high prioirty items are off your list), but I'm not sure what to do there
<jdstrand> zyga: ^
<ralsina> sergiusens: https://github.com/snapcore/snapcraft/pull/813 is ready for a review when you have a spare moment
<mup> PR snapcraft#813: "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <https://github.com/snapcore/snapcraft/pull/813>
<zyga> jdstrand: well, yeah, I think this is a tough problem, mouninfo will always tell the truth
<sergiusens> ralsina will do, thanks for working on this!
<jdstrand> zyga: the good news is there shouldn't be a lot of software that is parsing mountinfo for the reasons that docker is, and we have a workaround for docker (and again, it is arguably a bug in docker)
<ralsina> sergiusens: np, ping me for anything you see there.. 1st snapcraft branch so there will surely be something horrible :-)
<sergiusens> ralsina nah, all good, I am holding off moving away from docopt until this lands so you don't take a hit
<ralsina> wee, kill docopt :-)
<jdstrand> mectors: hey, did you get my email regarding bug #1627309 ?
<mup> Bug #1627309: bluetooth-control noble.js not working <Snappy:New> <https://launchpad.net/bugs/1627309>
<sborovkov>  Hello. After updating classic image I am now getting this for all of my snaps which were working before... Any ideas? : Sep 27 14:21:34 ubuntu snap[6727]: this GOARM=6 binary. Recompile using GOARM=5.
<ogra_> sborovkov, was that something cross compiled ?
 * ogra_ wonders why anything would use 5 or 6 on ubuntu ... given we only support ARMv7 
<mup> PR snapd#2009 opened: tests: add firewall-control interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2009>
<sborovkov> ogra_: no
<ogra_> so it only howed up ater a snapd upgrade ?
<sborovkov> ogra_: I compiled that snap on rpi3 on ubuntu mate. everything worked. Got latest updates. So I guess newer snapd. After that everything stopped working with those errors. And something about not supported floating architecture
<ogra_> *showed up after
<ogra_> right, looks like napd itself was built for ARMv6 without hardfloat
<ogra_> *snapd
<ogra_> mvo, zyga ^^^
<ogra_> (i dont see such issue on the allo-snap images though)
<ogra_> *all-
<sborovkov> I am pretty sure someone else had similar issue some time ago. I remember seeing this here. But don't remember when it happened or why.
<ogra_> right
<mup> Bug #1627692 opened: Error when model file is not in $HOME <Snappy:Confirmed> <Ubuntu Image:Invalid> <https://launchpad.net/bugs/1627692>
<mvo> sborovkov, ogra_: I think this is fixed with a updated snap-confine, the aux vector was not passed along and this confused go programs
<zyga> jdstrand: hmm
<zyga> er
<zyga> hmm
<zyga> jdstrand: sorry, I didn't notice your name was in the bugger
<zyga> buffer
<ogra_> mvo, ah, perhaps the snap-confine that is stuck in proposed ?
<ogra_> snapd should have a versioned dep if thats the case
<sborovkov> ah ok. So I guess I need to use proposed to make sure it works.
<zyga> sborovkov: try the ppa perhaps
<zyga> sborovkov: or build 1.0.42 from the tarball on github
<zyga> sborovkov: packaging is on git.launchpad.net/snap-confine
<mvo> ogra_: I think something else broke it, but I don't remember the details
<mvo> ogra_: hm, maybe I do
<sborovkov> zyga: what ppa should I use?
<ogra_> well, if we break everyones RPi classic install regarding snaps after we told everyone to use classic, thats a bad thing
<zyga> sborovkov: aww, I never remember, sorry
<zyga> sborovkov: can you try the package in yakkety?
<sborovkov> zyga: ok. I will try it today/tomorrow. Will tell you if that does not work. (if either of them does not work).
<zyga> sborovkov: thanks
<jdstrand> zyga: no worries
<mup> PR snapd#2010 opened: many: create auth.json for the freshly created user in `snap create-user` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2010>
<zyga> jdstrand: can I just mark https://bugs.launchpad.net/snap-confine/+bug/1584456 as verification-done based on the presence of the extra apparmor rule?
<mup> Bug #1584456: apparmor denial using ptmx char device <apparmor> <verification-needed> <Snappy Launcher:Fix Released by jdstrand> <linux (Ubuntu):Confirmed for tyhicks> <snap-confine (Ubuntu):Fix Released> <snap-confine (Ubuntu Xenial):In Progress> <https://launchpad.net/bugs/1584456>
 * ogra_ puts on an evil grin ... 
<jdstrand> zyga: yes. you can also say that 'apparmor_parser -QTK /etc/apparmor.d/usr.lib.snapd.snap-confine' returns with no errors and show that it is present in 'sudo aa-status|grep snap-confine'
<ogra_> mvo, so where is that script you said you would write if you ever had to touch meta again ? (i see you added xdelta today)
<ogra_> :)
<jdstrand> zyga: that is sufficient for these policy updates that only allow more access (ie, it can't regress with more access and you demonstrate the policy compiles and is loaded)
<jdstrand> zyga: (sufficient when there isn't a simple test case)
<jdstrand> zyga: it is nice to prove that it fixes it, but when you don't have the ability to do that, proving it doesn't regress is good enough with policy updates like this
<zyga> jdstrand: thank you :)
<ogra_> hmm, why does the PPA actually check package versions against proposed ... it tells me nplan and initramfs-tools have newer versions available ...
 * ogra_ checks the PPA setup ... 
<ogra_> no, definitely pointing to -updates ... as it should ... weird
<ogra_> cjwatson, is there a bug open for that ? ^^
 * ogra_ assumes there is ... i cant be the first one noticing that
<cjwatson> ogra_: not sure, probably, various bugs about ancestry not being ideal
<ogra_> yeah, k
<ogra_> i wont file one then
<ogra_> (even though it is a lie, it is a good warning mechanism that i need to take action before it migrates)
<ogra_> oh man ... that initramfs-tools in -proposed will make the size explode :/
<cjwatson> ogra_: Yeah, that's why it wouldn't be trivial to change.  It would probably need multiple indicators that look slightly different.
<zyga> ok, verification done
<zyga> pitti: I've verified all the other issues, I will now ask for the SRU in ubuntu-release
<ogra_> cyphermox, hmm, looking at http://launchpadlibrarian.net/286301974/initramfs-tools_0.122ubuntu8.1_0.122ubuntu8.2.diff.gz ... how do you actually make sure dhclient is in the initrd ? i dont see a hook anywhere that would copy it in
<ogra_> cydizen, oh, ignore me ... i see it in the isc-dhcp package
<ogra_> err, sorry cydizen, that was for cyphermox
<cyphermox> isc-dhcp has the hook.
<ogra_> yeah, just saw it
<cyphermox> it only adds 500k
<ogra_> thats a lot
<cyphermox> no choice.
<ogra_> (for an initrd that is only 2.5MB and has no NIC drivers in it at all :) )
<ogra_> (like ours)
<cyphermox> there isn't a choice --- there are conflicting priorities here, and IPv6 needs isc-dhcp in the initramfs to work.
<cyphermox> (that's for MAAS, but it's relevant to any network where you want to "netboot" over ipv6)
<ogra_> well, we exclude all modules from the core initrd
<ogra_> so it wont affect us at all
<ogra_> just the growth will
<cyphermox> well you can always explicitly remove the hook
<ogra_> indeed ... but ... well ... moar hacks
<cyphermox> or I suppose we can come up with an environment parameter to say "no, don't install isc-dhcp"
<cyphermox> there's only so much that can be done.
<ogra_> yeah, via initramfs.conf
<ogra_> our initrd has in general become a horrid thing ...
<ogra_> 34MB on my desktop install
<cyphermox> heh
<cyphermox> 34M is generally not a big deal
<ogra_> a few yeqars ago that would have counted as rootfs :P
<ogra_> it slows down your boot
<zyga> jdstrand: I'm wondering if we can not mount all of / as rslave
<ogra_> you need to load it from disk
<ogra_> and then wait til the kernel decompressed it (on arches where that happens)
<cyphermox> replacing klibc (which is partly why isc-dhcp comes in) is long overdue.
<zyga> jdstrand: or do some trick that would let us do make / rslave and then bind mount "vanilla" /media over
<ogra_> well, you cant actually replace klibc
<ogra_> you only start duplicating more of it with glibc tuff
<ogra_> *stuff
<cyphermox> of course you can get rid of it, most things already don't use it at all
<ogra_> well, once someone re-writes run-init you can
<ogra_> but i dont see that happen
<cyphermox> ipconfig was the biggest bit, and that's mostly replaced by isc-dhcp, unless you use ancient network boot stuff
<cjwatson> run-init could probably just be directly copied somewhere else and relinked against glibc
<cjwatson> Maybe with very minor changes
<ogra_> i thought thats not possible
<cyphermox> cjwatson: indeed.
 * ogra_ suggested that years ago and was told so
<cjwatson> I think at the time it may not have been worth it because there was a ton of other stuff
<ogra_> ah
<cjwatson> ipconfig was definitely more of an issue
<cyphermox> run-init will be last on my list once I've run through $everythingelse and made sure there weren't packages elsewhere that depend on obscure other bits of klibc
<ogra_> well, getting rid of the duplication is surely a good thing ... getting rid of it in favour of massive growth ... not so much though
<davidcalle> ogra_: hey, a quick question: I'm looking ant gadget snaps and wondering: is there another possible value than "kernel" for "device-tree-origin" in gadget.yaml?
<davidcalle> looking at*
<ogra_> looking on my desktop that was originally installed with 3.13.0, the initrd has already grown by 5MB
<ogra_> davidcalle, "gadget"
<ogra_> davidcalle, but thats the default anyway ... so we dont bother to set "device-tree-origin" in gadgets where the dtb is shipped in the gadget
<jdstrand> zyga: tyhicks had thoughts on that. I've forwarded you the info
<zyga> thank you
<davidcalle> ogra_: thanks!
<ogra_> *grown by 5MB between 3.13.0 and 4.4.0
<ogra_> davidcalle, np ...
<mup> PR snapd#2004 closed: cmd/snap: make the buy tests run again and fix the failures <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2004>
<mup> PR snapd#2011 opened: client, cmd: change buy command to match UX document <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2011>
<mup> PR snapd#2012 opened: interfaces/builtin: add missing rule to allow run-parts to execute all resolvconf scripts <Created by morphis> <https://github.com/snapcore/snapd/pull/2012>
<mup> Bug #1628193 opened: please set TMPDIR=/tmp when launching snaps <Snappy:Triaged> <https://launchpad.net/bugs/1628193>
<mup> PR snapd#2013 opened: many: finish `snap set` API <Created by kyrofa> <Conflict> <https://github.com/snapcore/snapd/pull/2013>
<zyga> tyhicks: thank you for the investigation wrt /media sharing!
<tyhicks> zyga: no problem - I hope it is helpful
 * ogra_` feels net-splitted
<ogra_> geez ... that net-splittery today is really annoying
<om26er> Hi! I am trying to create a local snap for a python script, how can I add source for my script code that is a local directory ?
<nacc> om26er: your snapcraft.yaml can copy/dump from local directoriees (source: ., iirc)
<nacc> (and as an example)
<om26er> nacc, I tried source: /my_path it didn't pick the code from there
<ogra_> also make sure to have the python plugin in use ... there is really no guarantee that the core snap has a python interpreter or a ceetain version of it
<nacc> ogra_: good point :)
<nacc> om26er: can you pastebin your snapcraft.yaml?
<om26er> nacc, http://paste.ubuntu.com/23243296/
<ogra_> i.e http://paste.ubuntu.com/23243298/ would get you the python2 interpreter (and just that) in your snap
<ogra_> ah, i see you are already using it
<ogra_> there are various issues in your snapcraft.yaml ...
<ogra_> source: /home/om26er/Desktop/source/
<ogra_> that should be a relative path from where your snapcraft.yaml lives
<ogra_> command: python3 run
<ogra_> that would only work if "run" is actually living in a dir in $PATH
<ogra_> om26er, /my_path would mean you have actually a dir in / called my_path ... try ./my_path here
<ogra_> i.e. relative to your snap dir
<nacc> ogra_: i wonder if the relative path requirement should be explicit in the help? the example does say ./..., but absolute paths don't work?
<ogra_> not sure, if $SNAP works here ... iirc there was a bug about that
<ogra_> absolute paths would be ugly since you need to include the snap name, version etc
<ogra_> they *can* work though ... if you put that data in
 * nacc might be confused, but thought absolute paths worked with the copy plugin, at least
<nacc> not important, regardless :)
<ogra_> well, the copy plugin is dead for some obscure reason
<nacc> yeah,that's why i said not important
<pmcgowan> ogra_, I need help :(
<om26er> ogra_, /my_path actually meant my local path i.e. /home/om26er/Desktop/source/
<ogra_> right, try a relative one ... starting from where your snapcraft.yaml lives
<om26er> ok
<mhall119> check it out! http://mhall119.com/2016/09/desktop-app-snap-in-300kb/
<mup> PR snapd#2015 opened: asserts: introduce AttributeConstraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/2015>
<oparoz_> Is there an interface in the works which would allow snaps to mount NFS and Samba shares?
<nhaines> Is snapweb still broken on the RPi2?  :)
<jdstrand> nessita: hey, if someone wanted to file a bug against the store's review process, but not the review tools, what project would that be against?
<pedronis> jdstrand: I think https://bugs.launchpad.net/software-center-agent
<jdstrand> pedronis:
<jdstrand> pedronis: thanks
<zyga_> tyhicks, jdstrand: https://twitter.com/zygoon/status/780858109950619649
<tyhicks> zyga_: that's quite a mount table you have there
<zyga_> tyhicks: yep, and the kernel nicely hangs when I ran 'umount -l' later on
<zyga_> tyhicks: you know that the kernel dies when the cursor stops blinking :)
<tyhicks> :)
<zyga_> tyhicks: it's late today and I was supposed to go rinding but I can easily reproduce this with a few syscalls
<zyga_> tyhicks: perhaps a bug in the kernel, looks like it is trying to rbind the same thing recursively and happily runs out of memory, I killed the process when I saw 5GB of extra memory allocated in a few seconds
<niemeyer> cjwatson: The spread snap doesn't work with qemu yet, sorry :(
<niemeyer> cjwatson: It needs to be aware of the hosts file being elsewhere.. we need to address this problem in snappy itself, making it easier for that sort of reusability to occur someohw
<cjwatson> niemeyer: aha, right, so I should just build it straight from the github repository or similar?
<niemeyer> cjwatson: We're addressing that with lxd and docker by enabling communication with the daemons, but we don't yet have good  support for reusing classic debs generically, as that's basically a deb dependency
<cjwatson> (for now)
<niemeyer> cjwatson: yeah, go get https://github.com/snapcore/spread/cmd/spread should land a bin on $GOPATH/bin
<cjwatson> all right, will give that a try later, ta
<niemeyer> cjwatson: Sorry for the trouble
<cjwatson> np
<mup> PR snapd#2013 closed: many: finish `snap set` API <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapd/pull/2013>
<nessita> jdstrand, http://bugs.launchpad.net/software-center-agent/+filebug :-)
<mup> PR snapd#2016 opened: many: rename apply-config hook to config-changing <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2016>
<kyrofa> ogra_, are you still around?
<mup> Bug #1628289 opened: snapd should depend on squashfuse (for use in containers) <lxd> <Snappy:New> <https://launchpad.net/bugs/1628289>
<mup> PR snapd#2002 closed: tests: use new spread `debug` feature <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2002>
#snappy 2016-09-28
<ahoneybun> mm if if get the tar.bz2 file what plugin do i need to use?
<ahoneybun> audacious 3.8
<mup> Bug #1628357 opened: A deamon fails with: No home directory found <Snappy:New> <https://launchpad.net/bugs/1628357>
<mup> PR snapd#2017 opened: Download deltas (but do nothing with them yet) when env var is set <Created by absoludity> <https://github.com/snapcore/snapd/pull/2017>
<dholbach> good morning
<dholbach> mhall119, nice work on the content snap blog!
<didrocks> zyga_: hey! do you know the rationale for the "grade" keyword which is mandatory now? (There has been no announcement on it if I didn't miss anything?)
<didrocks> dholbach: maybe you know? ^
<didrocks> ok, found a cryptic explanation on some design doc
<dholbach> didrocks, no, I don't
<didrocks> dholbach: I just added some changes to take into account the grade channel, also, going to change few things for --dangerous install with latest version
<dholbach> didrocks, to the codelabs or where?
<didrocks> dholbach: codelabs
<didrocks> (done)
<dholbach> didrocks, awesome - thanks
<didrocks> yw!
<mup> PR snapd#2016 closed: many: rename apply-config hook to configure <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2016>
<popey> ogra_: is the process of porting to new devices well documented? Is it as hard as porting to new phones? I have a banana pi I'd like to see ported to...
<popey> huh, turns out they've looked at this before. http://forum.banana-pi.org/t/snappy-ubuntu-core-on-banana-pi-bpi-m2/432
<dholbach> didrocks, can we try the collaboration feature for snap-codelabs?
<dholbach> I haven't seen in action yet and it might make sense in this case.
<didrocks> dholbach: hum, what do you mean by collaboration feature?
<didrocks> dholbach: I'm trying to fix the "resume" not working FYI ;)
<dholbach> didrocks, IIRC there's a few feature where you hit the "collaboration" link for a snap in myapps and can enter an email for somebody with whom you want to maintain the package together
<didrocks> dholbach: oh, that, maintaining together
<didrocks> yeah
<didrocks> let me see if I have a link for this
<didrocks> dholbach: sent
<dholbach> hah, fun - the message was in French
<dholbach> great, that was painless
<didrocks> ;)
<popey> haha, got that too
<popey> thought it was spam, being french ;)
<popey> "You have successfully been granted administrative access to snap-codelabs.didrocks." - MUhahahahah
<mup> PR snapd#2018 opened: snapstate: pass errors from ListRefresh in updateInfo <Created by mvo5> <https://github.com/snapcore/snapd/pull/2018>
<mup> PR snapd#2012 closed: interfaces/builtin: add missing rule to allow run-parts to execute all resolvconf scripts <Created by morphis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2012>
<ogra_> popey, porting is a lot easier ... but you need to build kernel, uboot and a gadget snap
<popey> ogra_: is it documented?
<ogra_> not really ... thats kind of on my TODO
<ogra_> (at least a blog post is ... )
<popey> ok
<mup> PR snapd#2007 closed: interfaces: ppp: load needed kernel module <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2007>
<ogra_> popey, oh, and it gets a lot eaier if your board is already supported by our linux-generic armhf kernel (there is a bunch o borads that are supported by default in that one
<ogra_> )
<ogra_> https://launchpadlibrarian.net/287031519/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz
<ogra_> Staging livebuild
<ogra_> Priming livebuild
<ogra_> 'utf-8' codec can't encode character '\udcc4' in position 93: surrogates not allowed
<ogra_> Traceback (most recent call last):
<ogra_>   File "/usr/share/launchpad-buildd/slavebin/buildsnap", line 191, in main
<ogra_>     builder.build()
<ogra_> cjwatson, ^^^ i that buildnaps or snapcrafts fault ?
<ogra_> *is that
<mup> PR snapd#2008 closed: overlord/state: prune old empty changes <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2008>
<ogra_> (havent seen that one before ... and i guesss it might just succeed if i re-try)
<ogra_> (since all others have succeeded)
<mup> PR snapd#2019 opened: store: retry download on 500 <Created by chipaca> <https://github.com/snapcore/snapd/pull/2019>
<mup> PR snapd#2020 opened: prevent timeout while waiting for log on systemctl status <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2020>
<cjwatson> ogra_: must be snapcraft, I think
<cjwatson> ogra_: if you look closely at the buildsnap traceback it's just reporting the non-zero exit status
<mup> PR snapd#2021 opened: releasing package snapd version 2.16 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2021>
<ogra_> well, let me just try a re-build ... i dont really see any obvious other errors and yesterdays build has worked ...
<mup> PR snapd#2020 closed: tests: prevent timeout while waiting for log on systemctl status <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2020>
 * ogra_ files bug 1628457
<mup> Bug #1628457: snapcraft fails on s390x with utf8 error <Snapcraft:New> <https://launchpad.net/bugs/1628457>
<mup> PR snapd#2021 closed: debian: releasing package snapd version 2.16 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2021>
<mup> PR snapd#2022 opened: Add links to IRC, mailing list and social media <Created by dholbach> <https://github.com/snapcore/snapd/pull/2022>
<mup> PR snapcraft#833 opened: Add links to IRC, mailing list and social media <Created by dholbach> <https://github.com/snapcore/snapcraft/pull/833>
<zyga_> didrocks: I don't know about grade, sorry
<zyga> jdstrand, tyhicks: mixed news about /media sharing, still no luck, I'm debugging and investigating
<zyga> this is somewhat frustarating as it is extremely easy to break the system
<jdstrand> :\
<zyga> my current quest is to figure out where pivot_root is giving up with EINVAL, I'm just patching the kernel
<jdstrand> zyga: you are on xenial?
<zyga> but I also seem to be missing some other things that are required to make this work, most importantly, it seems that mount points happily leak outside
<zyga> yes, I'm doing all of this on xenial
<jdstrand> zyga: but no kernel trace?
<zyga> jdstrand: ?
<jdstrand> zyga: you're kernel isn't oopsing or anything?
<zyga> jdstrand: ah, no, nothing like that happens
<zyga> jdstrand: I think that the crashes earlier can be trivially caused by what looks like recursive mount that sees itself and just continues
<zyga> jdstrand: but I also had less adventourous examples where after the test program has finished I had something I couldn't unmount
<zyga> jdstrand: or unmount -l would really detach /
<jdstrand> zyga: ok, I ask just to be sure-- in another channel there was an issue with pivot_root causing an oops if running snapd in an lxd container, and the timing of your comment was just odd. nm me
<zyga> jdstrand: oh, interesting
<zyga> jdstrand: I bet there is some new ground we are breaking here
<jdstrand> oh totally
<jdstrand> all kinds of new ground :)
<zyga> moving to a VM is actually better as native is slow/costly to recover
<jdstrand> indeed :)
<zyga> jdstrand: from what I see so far I think we need MS_UNBINDABLE at a strategic spot or everything blows up
<zyga> jdstrand: but I don't have a working demo that goes all the way to pivot_root and behaves
<zyga> jdstrand: well, investigating :)
<zyga> oh, curious
<zyga> jdstrand: pivot_root documentation really sucks, kernel sources are better
<jdstrand> kyrofa: hey, do you have an agreed to list of keys that are allowed in the hooks yaml?
<jdstrand> kyrofa: eg:
<jdstrand> hooks:
<jdstrand>   <???>:
<jdstrand>     plugs: ...
<jdstrand> kyrofa: and aiui, 'plugs' is the only thing that can be in there, but this is valid:
<jdstrand> hooks:
<jdstrand>   <???>: null
<jdstrand> kyrofa: also, if the hook key names are defined, do they map to files in meta?
<jdstrand> kyrofa: perhaps a better question is: is there up to date documentation on how hooks are supposed to work? :)
<ogra_> you just attach them to the eyelet on your computer :P
<sergiusens> ogra_ I am not sure how to fix your problem or debug it and I bet adding --debug is not going to be easy
<sergiusens> ogra_ can you use a hacked up snapcraft to run through the build?
<ogra_> sergiusens, yeah, i was waiting for you to show up here ... i guess we might need some cjwatson help
<sergiusens> ogra_ well, I recall you forked snapcraft once
<ogra_> i could do that i guess, yeah
<sergiusens> so we don't need him
<ogra_> well, i guess a debug toggle might be helpful in general ... cant be that hard to add code for this to the lp builder
<ogra_> but yeah, as a quick hack, tell me what changes you need and i'll push a debug snapcraft to the PPA temporary
<cjwatson> ogra_: the problem with that is that we have nowhere to set it in LP
<cjwatson> so it would not be a trivial stack of changes
<ogra_> ah, because it would need UI ...
<ogra_> yeah
<cjwatson> and a database change, and a model change, and passing it over the channel to the buildd
<cjwatson> so, you know, I can spend two days on all that or you can push a debug package to the PPA :)
<sergiusens> cjwatson ogra_ in all fairness I need to finish up the rework of using project owned exceptions for everything we know about and let the built-ins fly away to stdout/stderr
<ogra_> heh, ok, my imagination didnt go far enough here :)
<sergiusens> ogra_ http://paste.ubuntu.com/23246720/
<ogra_> ah, thats definitely easier than what colin described above :)
<dz0ny> not sure what rules you have for snapcraft or snapd but this could be nice publicity https://hacktoberfest.digitalocean.com/
<cjwatson> also perhaps a sensible alternative would be to allow a project to put debug: true in snapcraft.yaml?
<cjwatson> of course wouldn't be active from the very start
<sergiusens> cjwatson yeah, that is the debian/rules path; I was trying to keep those two things separate, but I guess it will be inevitable
<kgunn> kyrofa you about ?
<Elleo> has anyone run gdb on a snap inside unity8? I've managed it in unity7, but in unity8 I just get a permission denied error even when run as root
<sergiusens> ogra_ this is the branch that broke you https://github.com/snapcore/snapcraft/pull/796/files
<mup> PR snapcraft#796: Only discover dependencies once per file <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/796>
<sergiusens> ogra_ I failed to notice this got removed `fs_encoding = sys.getfilesystemencoding()`
<ogra_> geez, how can i make github not show me that "we've made soe changes" thing ... so annoying
<sergiusens> ogra_ accept the changes, let them flow and they will go :-P
<ogra_> i think i did that a few times now
 * ogra_ tries again
<oparoz> The discussion about /media earlier was to allow snaps access to /media? That would be great :)
<ogra_> sergiusens, well, it is funny that it only affects s390x ...
<sergiusens> ogra_ well, funny as it may be, I bet that is the issue and your ppa run will luckily prove it
<mup> PR snapd#1832 closed: interfaces/builtin: support time and date settings via 'org.freedesktop.timedate1 <Reviewed> <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1832>
<zyga> joc: hey, do you have a second?
<joc> zyga: sure
<zyga> joc: I need to verify something for GPIO interface
<zyga> joc: if you have hardware with GPIOs around (could be any device really, including pi) I can give you an udev rule that will export one of them to userspace
<joc> zyga: yep i have hardware can try it on
<zyga> joc: can you give me a pastebin of: udevadm info --export-db | grep -i gpio
<joc> one sec, booting it
<zyga> joc: what we want in a file, e.g. /etc/udev/rules.d/foo.rules
<ogra_> sergiusens, grrr ... snapcraft build fails in the tests
<zyga> joc: and then a correctly done RUN line :)
<kgunn> Elleo: i just saw your statement, interesting...
<zyga> joc: but I need the details from your device first
<kgunn> tedg: ^^^
<ogra_> is there some var i could set to disable them altogether ? (thats not the first time i have to hack them up)
<sergiusens> ogra_ oh right, disable them as we test the error outputs and that applied diff would set it off
<sergiusens> ogra_ tests, no, just debian/rules overrides
<Elleo> kgunn: not currently certain if the permission denied is coming from gdb itself or snap, either way it happens very early on in loading things
<kgunn> Elleo: is the snap --devmode?
<Elleo> kgunn: yeah
<kgunn> Elleo: i would suspect the general confinement of u8 itself
<kgunn> e.g. click
<joc> zyga: http://paste.ubuntu.com/23246802/
<Elleo> kgunn: interestingly I can run "snap list" in gdb, but not "snap run ubuntu-keyboard"
<kgunn> Elleo: are you on yakkety or xenial?
<Elleo> kgunn: xenial
<Elleo> kgunn: but with the overlay
<kgunn> sure
<joc> zyga: gpio 346 would be a nice one to test
<kgunn> Elleo: wonder if you need to break confinement on snappy...this is weird, but install classic on core on classic :-P
<kyrofa> kgunn, I am now
<kgunn> Elleo: https://github.com/snapcore/classic-snap
<Elleo> kgunn: I'm currently running unity8 via the unity8-desktop-session rather than the unity8 snap, wouldn't that avoid that confinement?
<kyrofa> kgunn, sorry, standup is at 0600, I wake up at 0550, and space IRC until about 0630 or so :P
<kgunn> kyrofa hey, so i wanna build a qt demo, and i have the git source link....but the actual qt .pro file is kinda buried
<kgunn> kyrofa https://github.com/qt/qtdeclarative/tree/dev/examples/quick/demos/photoviewer
<kyrofa> Hmm
<kgunn> kyrofa so wondering is there a way to point there ?
<tedg> kgunn: I'm confused at what you're pointing me at.
<kgunn> tedg: <Elleo> has anyone run gdb on a snap inside unity8? I've managed it in unity7, but in unity8 I just get a permission denied error even when run as root
<kyrofa> kgunn, did you try using the `project-files` option in the qmake plugin?
<kyrofa> jdstrand, yes indeed
<kgunn> kyrofa ....bah! thank you
<kgunn> kyrofa next time just reply rtfm :)
<kyrofa> kgunn, hahaha, not my style ;)
<ogra_> yeah, thats so un-ubuntu
<Elleo> kgunn: same result when running inside classic
<kyrofa> jdstrand, you have a good grasp of this, but this might reaffirm: https://github.com/snapcore/snapd/blob/master/docs/hooks.md
<zyga> joc: thanks, let me finish a meeting and I'll be back to this
<cjwatson> sergiusens: could you retry tests on https://github.com/snapcore/snapcraft/pull/831 ?  they should pass now (or at least get further)
<mup> PR snapcraft#831: 'sign-build' implementation <Created by cprov> <https://github.com/snapcore/snapcraft/pull/831>
<joc> k
<kyrofa> jdstrand, the hooks that are supported are maintained in the snapd code though, and the list will change. Are you adding them to the review tools?
<jdstrand> kyrofa: right now I have some basic tests for hooks in the review tools that I added yesterday. I did read that file. I was wondering if there was a list-- that doc says none are currently supported
<jdstrand> I can wait on added valid ones-- that isn't a big deal
<Elleo> kgunn: get the same thing if I try running strace on it, happens when running the ubuntu-core-launcher: http://pastebin.ubuntu.com/23246832/
<jdstrand> also, this output is less than helpful:
<kyrofa> jdstrand, there's a list of one as of now, but the PR that adds it to the doc hasn't landed yet
<jdstrand> $ snapctl
<jdstrand> error: snapctl requires SNAP_CONTEXT environment variable
<kyrofa> jdstrand, it's called `configure`
<jdstrand> and snapctl -h
<kyrofa> jdstrand, yeah, snapctl is typically used within hooks
 * jdstrand notes that he was told to use 'snapctl -h' by the aforementioned doc :)
<kyrofa> jdstrand, oh right-- snapctl -h will work in the next release
<jdstrand> kyrofa: ok, thanks. this is helpful
<kyrofa> Side effect of only maintaining docs in master, heh, sorry
<kyrofa> jdstrand, but yeah, that doc should be updated as hooks are added
<Elleo> kgunn: aha
 * kgunn waits anxiously
<Elleo> kgunn: all snaps are failing to run in unity8's terminal for me
<Elleo> kgunn: including simple things like hello-world, strace shows it trying to do some network stuff and then getting an EACCESS error
<jdstrand> Elleo, kgunn: curious if you are using the newest snapd in yakkety-proposed and the snap-confine in yakkety
<Elleo> jdstrand: I'm running xenial + stable-overlay
<jdstrand> I see, nm then
<zyga> joc: ok, back
<Elleo> kgunn: ah, and now after running hello-world successfully by sshing in, I get the permission denied error when attempting to start it
<zyga> joc: so that device three distinc GPIO chips, right?
<zyga> joc: what do you see in /sys/class/gpio?
<joc> zyga: yes three chips
<Elleo> kgunn: ah, seems to actually be /run/snapd.socket it gets the error on: http://pastebin.ubuntu.com/23246852/
<kgunn> otp but will read up in a bit
<kyrofa> Hey ogra_, got a sec?
<ogra_> kyrofa, i guess i do
<kyrofa> ogra_, saw a question on askubuntu that made me think of you: https://askubuntu.com/questions/829118/ubuntu-core-power-failure-resistance
<kyrofa> ogra_, I suspect the overall answer to the question is no, is that correct?
<ogra_> kyrofa, we redice the writes as much as we can and since we use ext4 the recovery should also work fins after a power failure
<ogra_> *fine
<ogra_> i often enough just unplug the power when testing
<ogra_> with no ill effects
<ogra_> *reduce the writes
<kyrofa> ogra_, makes sense. But in terms of the design, things are split like that for security more for increasing the lifetime, since the writable partition is still on disk. Right?
<kyrofa> The read-only bits are snaps which are still written to disk as well
<ogra_> i guess wearing out the SD really depends on the snaps you use and if they do a lot of wild write operations
<ogra_> the OS itself is very unlikely to ever wear out an SD
<ogra_> kyrofa, yes, the RO bits are written to disk on "snap refresh" ...
<kyrofa> ogra_, I dunno, I go through an SD card a year on my plug computer. I figured it was due to logging
<Elleo> kgunn: not sure if it's relevant, but when I did the initial "snap login" it forced me to do it as root, I don't know if that's resulted in something having odd permissions (although snap stuff works fine under unity7 still)
<Elleo> kgunn: well, via sudo
<ogra_> kyrofa, yeah, that can indeed be ... but we dont have swap, /tmp is a tmpfs in ram and writes on OS level only happen for the few writable bind mounts we actually have ...
<ogra_> kyrofa, the thing that will really wear it out is a snap that does a lot of writing
<ogra_> but not the OS
<ogra_> logging on its own is usually very quiet unless you start running snaps with --devmode ... then it gets super agressive
<ogra_> (which i'd really like to get rid of)
<kyrofa> ogra_, alright, thanks for the explanation! I think I have enough to answer that question now unless you want to tackle it
<ogra_> all these apparmor ALLOWED lines wil eat your SD in no time if you run a devmode snap for a while
<ogra_> no, go ahead :)
<sergiusens> ogra_ did it finish yet?
<ogra_> sergiusens, ages ago ... but the publisher is a bitch lately
<ogra_> still waiting ...
<sergiusens> ogra_ lol; ssh and grab the logs :-)
<ogra_> (disabling the tests makes the build **really* fast :) )
<ogra_> sergiusens, no, i'm still waiting for the snapcraft package to be published in the PPA
<ogra_> no logs to grab yet :)
<sergiusens> ogra_ oh, I thought you built the snap already!
<sergiusens> darn this is slow
<ogra_> yeah
<ogra_> the publisher is a pain atm
<ogra_> sergiusens, snap build started ...
<sergiusens> ogra_ \o/
<kyrofa> ogra_, does http://askubuntu.com/a/830774/261753 look reasonable?
<ogra_> kyrofa, looks fine to me
<kyrofa> ogra_, alright, thanks for the help!
<ogra_> sergiusens, https://launchpadlibrarian.net/287088900/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz
<zyga> joc: can you tell me what you see in /sys/class/gpio please
<joc> zyga: yes, what you said - three gpio chips as indicated by udev and export/unexport
<joc> zyga: no gpios have been exported yet
<mvo> dbarth: does #65 for snapweb the "WI" mean "work-in-progress" ? or work-item? or something else :) ?
<ogra_> west india problem
<zyga> joc: ok, great,
<mup> PR snapd#2023 opened: cmd/snap,configstate: rename apply-config variables to configure <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2023>
<mup> Bug #1628559 opened: Can't install more than 1 package in one command <Snappy:New> <https://launchpad.net/bugs/1628559>
<dbarth> mvo: WIP indeed; lenses playing tricks with my eyes...
<ogra_> use scopes then
<ogra_> :P
<dbarth> mvo: i'll rebase and push shortly
<mvo> dbarth: cool, thanks
<dbarth> ogra_: :)
<zyga> joc: if you 'echo 123 > /sys/class/gpio/export' does it just do what is expected?
<zyga> joc: where 123 is any number in the expected range
<joc> zyga: yep
<zyga> joc: thanks
 * zyga wonders what the udev rule trigger should be
<mup> PR snapd#2024 opened: docs: add `configure` hook to hooks list <Created by kyrofa> <https://github.com/snapcore/snapd/pull/2024>
<shuduo> ogra_: hi in recent pi3 beta image, there is no camera slot in "snap interfaces" output. is it expected?
<ogra_> shuduo, hmm, i wouldnt know who is supposed to actually provide it
<zyga> stgraber: hey, do you have a moment
<ogra_> shuduo, ounds liek you sshoudl file a bug as a starting point
<shuduo> ogra_: sure if it's a tracked issue i would file a bug
<ogra_> sergiusens, have you seen the log above ?
<ogra_> https://launchpadlibrarian.net/287088900/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz ... not really a lot more info i must say ...
<sergiusens> ogra_ yes, I wish I printed(filename) but at least I know where to look now
<ogra_> yeah
<ogra_> iirc we are using C.UTF-8 ... i wonder if thats any different on s390x than on the other arches
<sergiusens> ogra_ all the same
<sergiusens> ogra_ can I give you a quick other patch?
<ogra_> sure
<ogra_> sergiusens, btw https://bugs.launchpad.net/hplip/+bug/1498366
<ogra_> s.encode("utf-8", errors="surrogateescape")
<ogra_> seeems to be a valid workaround
<sergiusens> ogra_ right, we don't encode anything now from the new source of information; I want to try without surrogateescape, but I guess we can go full steam ahead
<sergiusens> ogra_ http://paste.ubuntu.com/23247199/
<shuduo> ogra_: if a device like pi3 neither connected to PC with USB debug cable nor connect to HDMI monitor, it will not boot up. is it expected? since i see my pi3 boot well with debug cable. but if I unplug debug cable, i can't see its ethernet get IP via nmap command.
<zyga> hmm
<ogra_> shuduo, no, thats not expected, if th device is properly set up via console-conf it should boot (and does here)
<shuduo> ogra_: sadly it is almost 100% reproducable at my side
<ogra_> weird
<shuduo> ogra_: sorry false alert. i tried few more times, i'm sure it works well. i guess i run nmap too fast after it shows connection estiblished
<ogra_> heh, yeah, arm devices demand some level of patience ;)
<ogra_> sergiusens, so the package has just finished building ... lets see if the publisher manages to publish in under 60min :P
<ogra_> zyga, niemeyer see shuduo's question above regarding the camera interface on images ... on actual images, who woud provide that slot and how would we define it ? i.e. if there is camera hardware, woud we/i have to define that interface in gadget.yaml ? would it magically show up once i plug in a USB camera etc
<oparoz> Are there plans to let Snaps mount external storage (NFS, CIFS)?
<mup> Bug #1628592 opened: no camera slot in pi2 or pi3 image <Snappy:New> <https://launchpad.net/bugs/1628592>
<ogra_> i think there was some kind of interface planned for this
<oparoz> That's missing for enterprise snaps
<ogra_> though this would bee network storage ...
<ogra_> not external torage (like USB sticks)
<ogra_> +s
<niemeyer> ogra_, shuduo: The core or the gadget snap would provide the camera slot. Not in gadget.yaml.. snap.yaml. Hot plug of USB devices is coming..
<shuduo> niemeyer: so it is not exist in amd64 core image too, right? i can see camera interface exist from "snap interfaces" on 1604 desktop.
<ogra_> because your desktop/laptop has a camera ?
<shuduo> ogra_: actually no. my camera can't be detected by 1604 desktop. :D
<stgraber> zyga: what's up?
<shuduo> niemeyer: i want to show webcam demo or face-detection demo to customer on core. may i know ETA of camera interface?
<niemeyer> shuduo: Don't we already have one?
<niemeyer> Checking
<niemeyer> We do..
<niemeyer> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/camera.go
<ogra_> niemeyer, we do but it does not seeem to show up on the imagees (though i wouldnt know hwo to enable it)
<zyga> stgraber: hey
<zyga> stgraber: I'm trying to crack a problem that you may know much more about
<ogra_> shuduo, what kind of camera are you trying to use ?
<shuduo> niemeyer, ogra_ so the question become when the camera interface show up in image. :)
<zyga> stgraber: I'd like to create a separate mount namespace in which / is a slave of the real / but /media (or some other location) is not a slave but the real thing
<ogra_> shuduo, depends on the camera ... i there is no camera on the device by default i dont think we can show the slot ...
<zyga> shuduo: it only shows up automatically on classic AFAIR
<ogra_> shuduo, if it is a USB camera it should be handled by the USB hotplug interface that niemeyer mentioned above
<niemeyer> shuduo, ogra_: You don't need to do anything.. it's already supported both in the images and in 16.04:
<niemeyer> snap interfaces | grep camera
 * zyga looks
<niemeyer> Just add a plug to the snap, and connect it after installing it
<shuduo> ogra_: normal usb camera, some model from logitech.
<ogra_> ogra@pi3:~$ snap interfaces|grep camera
<ogra_> ogra@pi3:~$
<zyga> niemeyer: camera is only implicitly defined on classic
<ogra_> we do not expose it on the images
<niemeyer> Huh
<zyga> niemeyer: and it is also reserved for core snap
<zyga> niemeyer: it smells wrong
<niemeyer> zyga: The slot being reserved is correct
<zyga> niemeyer: should be either something the gadget can add or always there
<ogra_> reserved sounds ok
<niemeyer> zyga: Should always be there..
<zyga> ay, I'll make a PR quickly
<ogra_> zyga, assuming you can aways plug a USB camera in i think it should always be there
<zyga> yes, I agree
<ogra_> zyga, then bug #1628592 is yours ;)
<mup> Bug #1628592: no camera slot in pi2 or pi3 image <Snappy:New> <https://launchpad.net/bugs/1628592>
<stgraber> zyga: so you want a given path outside the mntns to be / in the mntns but want /media to be the same and still get you any new mount under it?
<ogra_> shuduo, thanks for pointing it out !
<zyga> stgraber: yes, I tried a few prototypes with just command line tools (mount, unshare, pivot_root) and I didn't get anything sensible
<zyga> stgraber: it is surprisingly easy to blow the machine up
<shuduo> ogra_: good to know someone will take care it. go to sleep now. bye all. :)
<ogra_> bye
<mup> PR snapd#2025 opened: snap/implicit: don't restrict the camera iface to clasic <Created by zyga> <https://github.com/snapcore/snapd/pull/2025>
<sborovkov> zyga: hi. Indeed after enabling xenial proposed and upgrading that armhf issue went away. My snaps run fine again.
<zyga> done
<zyga> sborovkov: woot, that's great
<zyga> sborovkov: :)
<stgraber> zyga: hmm, so I'd expect something like 1) unshare mntns 2) bind-mount new / somewhere 3) make target rprivate 4) bind-mount /media to target/media 5) make target/media rshared 6) pivot
<zyga> stgraber: let me try that quickly
<zyga> stgraber: my gut feeling is that without unbindable mount somewhere it blows up at 2
<stgraber> zyga: the kernel won't let you add mounts cross mntns, so you need to have all your rshared bits setup before you pivot
<zyga> stgraber: right, I patched my kernel to give extra diagnostic for pivot_root error cases
<mup> PR snapcraft#834 opened: Remove the debian packaging <Created by elopio> <https://github.com/snapcore/snapcraft/pull/834>
<davmor2> how do you go about reading the description of a snap from the commandline to know if you want to install it?
<kyrofa> niemeyer, is what davmor2 is asking possible?
<ogra_> xdg-open https://uappexplorer.com/apps?q=myssnapname&sort=relevance&type=snappy_application
<ogra_> :P
<davmor2> kyrofa, niemeyer: for example I can do apt show X and it will give me the long description as well as the short snap find only seems to show the short description
<ogra_> just replace "mysnapname"
<davmor2> ogra_: yeah that is fine but if you are on core you have no browser :P
<ogra_> snap install a-browser :P
<davmor2> ogra_: hence asking about a cli version
<ogra_> i think there is no way ...
<ogra_> apart from hand crafting a store query or some such
<zyga> well, a nice CURL query probably gets you all the answers ;)
<zyga> but I don't think you want that
<ogra_> zyga, first you would need curl though
<ogra_> ogra@pi3:~$ snap find curl
<ogra_> error: no snaps found for "curl"
<ogra_> ogra@pi3:~$
<zyga> ogra_: there's a nice http snap AFAIK
<ogra_> true
<ogra_> from the almighty Chipaca
<mup> PR snapd#2026 opened: Connect fixes <Created by stolowski> <https://github.com/snapcore/snapd/pull/2026>
<zyga> stgraber: (sorry for the lag), that doesn't work quite well
<zyga> stgraber: and worst of all, after pivot_root fails I see lots of extra (stale) mounts in the main namespace
<zyga> stgraber: I'll share the script I have
<ogra_> sergiusens, core snap building
<mup> Bug #1628616 opened: Hello nextcloud claws-mail-moon127 all segfault on yakkety <Snappy:New> <https://launchpad.net/bugs/1628616>
<ogra_> https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core ... and https://code.launchpad.net/~snappy-dev/+snap/ubuntu-core/+build/5708
<sergiusens> ogra_ the NEW wait begins :-)
<ogra_> heh
<zyga> stgraber: perhaps a key qustion, when you said that step one is to unshare the mount namespace, do you consider any special sharing of / itself?
<zyga> fg
<zyga> jdstrand: some progress, not much success
<zyga> stgraber, jdstrand: http://paste.ubuntu.com/23247640/
<zyga> the good things are caused by --propagation private but this also breaks the key feature
<jdstrand> zyga: you made that comment about keeping the namespace doc up to date. I had the same thought, but then I was like "man, once the stars align and every feature works, we should never, ever, touch this again" :P
<sergiusens> ogra_ Snapping 'ubuntu-core' ...
<zyga> jdstrand: yes, I had that thought too :)
<zyga> jdstrand: I'll convert some of the docs we have into an unified format, perhaps man pages because I just love man pages and because they are installed and discoverable
<zyga> jdstrand: hey, I think I *might* have solved the problem just now
 * zyga typed "sync" three times just in case the world blows up
<jdstrand> zyga: yeah, I don't care about the format. the code is well-written and well-commented, but it is hard to really see the exact steps, so I wanted that somewhere and having close to the code (ie, somewhere in snap-confine) made a lot of sense to me
<jdstrand> s/having/have it/
<zyga> mwahaha
 * jdstrand crosses fingers
<zyga> almost :)
<zyga> I have the umount -l /old-root in the script
<zyga> that breaks the host (understandably)
<zyga> one fix after reboot
<zyga> man, umount -l / just breaks the world in very very funny ways
<zyga> rebooting
<mup> PR snapcraft#835 opened: Add the test upstream rules <Created by elopio> <https://github.com/snapcore/snapcraft/pull/835>
<zyga> but I think this already works
<zyga> modulo the umount
<zyga> I saw the event propagate
<zyga> and I saw *correct* sharing in mountinfo
<mup> PR snapd#2019 closed: store: retry download on 500 <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2019>
<zyga> man, this os one abused VM
<zyga> systemd doesn't cope that well without /
<mup> PR snapd#2023 closed: cmd/snap,configstate: rename apply-config variables to configure <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2023>
<zyga> there's some nice binfmt stuff that lets you run processes with an open fd to the executable, sstemd should perhps use that on all its esesential bits
<zyga> jdstrand: it works :)
<jdstrand> \o/
<zyga> http://paste.ubuntu.com/23247685/
<zyga> have a look, please
<zyga> I'll comment it now to explain why, IMHO, things are as they are
<ogra_> sergiusens, looks like it finished
<jdstrand> zyga: man
<jdstrand> so many layers of mounts...
<jdstrand> (thinking about this added to what we already have)
<zyga> jdstrand: more than you expected?
<jdstrand> no
<zyga> jdstrand: http://paste.ubuntu.com/23247723/
<zyga> jdstrand: with extra explanations about why I think this is required
<jdstrand> just, overall how complicated the mount namespace setup is
<zyga> jdstrand: I left my printout of shared subtrees in the attic, I'll check some of my own questions in a moment
<zyga> jdstrand: well, yes :)
<jdstrand> I'm not saying it can be simplified
<zyga> jdstrand: it's a hell of a maze
<jdstrand> just... man
<zyga> jdstrand: I cannot wait to see the windows kernel replicate this with their linux subsystem ;)
<jdstrand> lol
<zyga> tyhicks: hey, if you are around, I would love a review of the pastebin above ^^
<zyga> stgraber: ditto, this will help us a lot
<zyga> jdstrand: the pivot_root call can be used to set up /var/lib/snapd/hostfs
<zyga> jdstrand: but I need to make nvidia work in a different way before that happens
<jdstrand> hehe "infinite cycle"
<jdstrand> I now know what prompted your tweet :)
<zyga> jdstrand: gee, what is using that 5GBs of ram
<jdstrand> I thought 514000+ mounts was a bit high, even for snappy :)
<zyga> jdstrand: I killed the process, I guess that made the kernel stop in some way
<zyga> jdstrand: but it still crashed soon after :)
<jdstrand> I bet :)
<jdstrand> that's funny
<sergiusens> ogra_ I will prepare a PR
<sergiusens> ogra_ do you have a link to the logs
<zyga> jdstrand: and since having this I can see that none of the mount entries are share
<zyga> jdstrand: this is a bit worring though as this is differerent from systemd defaut
<zyga> jdstrand: so perhaps after pivot_root we should mount --make rshared / again
<zyga> (crazy)
<zyga> jdstrand: I bet some tools rely on this systemd default now
<zyga> jdstrand: e.g. systemd-nspawn or similar
<zyga> jdstrand: probably lxd as well
<jdstrand> yeah, will have to test with content interface, lxd, docker, shared mounts, etc
 * jdstrand hugs the testsuite
<tyhicks> zyga: that's pretty close to what I expected it to look like
<ogra_> sergiusens, https://launchpadlibrarian.net/287114070/buildlog_snap_ubuntu_xenial_s390x_ubuntu-core_BUILDING.txt.gz
<tyhicks> zyga: that's crazy stuff but I don't see anything unexpected/surprising in there
<zyga> tyhicks: thank you
<zyga> tyhicks: the key was the unbindable part
<zyga> tyhicks: that makes it not a new kind of fork bomb
<tyhicks> zyga: yeah, I wouldn't have figured the unbindable part out
<tyhicks> zyga: did shared-subtrees.txt point you towards using unbindable?
<zyga> tyhicks: yes
<zyga> tyhicks: I have it printed on my desk for a few days now
<tyhicks> hehe
<jdstrand> zyga: these days, I'm surprised you don't have it tacked up on your wall
<tyhicks> you should laminate it
<zyga> tyhicks: lol :)
<zyga> tyhicks: I love that it has a quiz
<zyga> tyhicks: that's like "you may have read it but now let's see if you pass the quiz" :-)
<tyhicks> zyga: wow, you really have been reading it closely in order to take the quiz :)
<zyga> thanks guys, I'll make this into a nice pull request tomorrow
<zyga> morphis: ^^ FYI
<zyga> morphis: call of the alarm :)
<mup> PR snapd#2024 closed: docs: add `configure` hook to hooks list <Created by kyrofa> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2024>
<kyrofa> jdstrand, there ^^ . Now the hooks doc has information about the only existing hook
<mup> PR snapd#2022 closed: README: add links to IRC, mailing list and social media <Created by dholbach> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2022>
<mup> PR snapd#2018 closed: snapstate: pass errors from ListRefresh in updateInfo <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2018>
<ogra_> niemeyer, it is nice that you tell me the gadget isnt any different regarding slots ... my problem is that we do not have syntax for slots *anywhere* defined in the docs ... i.e. i'd expect some "slot:" keyword that i can define in the snap.yaml of  the gadget to tell the system there is such an interface
 * ogra_ grins about jdstrand ending up on the quotes page ...
<ogra_> jdstrand, the number of mounts will go down once we ran out of major numbers for loop devices in the kernel :P
<niemeyer> ogra_: Yes, you are right.. we need doc champions to cover that aspect better at snapcraft.io
<niemeyer> slots:
<ogra_> yeah, i cant find anything aynwhere ....i looked around at the known places
<niemeyer>     camera:
<niemeyer> ogra_: That should be enough for this case
<ogra_> ah, neat, k
<niemeyer> ogra_: Plugs are also poorly documented
<ogra_> (i would have expected it in interfaces.md ... but that actually only explains how to use the snap command)
<niemeyer> ogra_: We really need some love in that area of snapcraft.io
<ogra_> yeah
<ogra_> plugs are at least mentioned in the snapcraft.yaml doc ...
<ogra_> anyway ...
 * ogra_ &
<mup> Bug #1628640 opened: Add 'snap info' command showing publisher, channel map <Snappy:New> <https://launchpad.net/bugs/1628640>
<jdstrand> ogra_: heh-- and here I was thinking the quote would be "13:03 < jdstrand> I thought 514000+ mounts was a bit high, even for snappy :)"
<mup> PR snapd#2009 closed: tests: add firewall-control interface test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2009>
<mup> PR snapd#1988 closed: interface/builtin: access system bus on screen-inhibit-control <Created by afrantzis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1988>
<davmor2> ogra_: nice looks like it might be an upgrade issue rather than an install issue so I'll have a play with that tomorrow
<mhall119> hi all, is there an electron desktop snap that I can use as an example?
<mhall119> trying to snap up Rambox,which is electon-based
<mhall119> davmor2: ^^ see what you did?
<davmor2> mhall119: hey it's not my fault you are compelled to snap all the things
<mhall119> no, it's your fault for not doing this one first, thus leaving it to me :-P
<mup> PR snapcraft#836 opened: Deal with 404 responses from the store's snap status endpoint <Created by thomir> <https://github.com/snapcore/snapcraft/pull/836>
<davmor2> mhall119: wait you were the one trialling it I'd never heard of it till you G+'d it :P
<sergiusens> mhall119 there's google play music from RAOF and atom
<sergiusens> mhall119 but saying 'electron' based is really vague, the world electron lives in has no convention
<sergiusens> cwayne or joc a review for https://github.com/snapcore/snapcraft/pull/832 from either of you would be nice
<mup> PR snapcraft#832: python plugin: only download in pull and build in build <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/832>
<cwayne> I'll take a look sergiusens thanks for the heads up
<sergiusens> cwayne this makes the plugin respect the lifecycle (to not build during the `pull` step)
<sergiusens> and makes the hacking on the offline train story for python a reality
<mhall119> can I get somebody to look into a snap that fails to install?
<mhall119> http://people.ubuntu.com/~mhall119/snaps/couchdb_2.0_amd64.snap
<mhall119> it's a daemon that systemd is failing on starting, so the install aborts
<mhall119> if I make it just a standard app, not a daemon, I can launch it manually and it works
<paul_r0b0t> hi
<mhall119> hello paul_r0b0t
<paul_r0b0t> i have deleted the stage and prime folders
<paul_r0b0t> and when i do snapcraft clean
<paul_r0b0t> it complains about some of the folders missing
<paul_r0b0t> eventually i would like to crate the stage folder again
<paul_r0b0t> with snapcraft stage
<mhall119> you should "snapcraft clean -s stage" instead of just deleting those folders
<mhall119> snapcraft remembers the last steps that finished successfully, so it doesn't have to repeat them
<paul_r0b0t> right
<mhall119> so by deleting the folders themselves, you've left it confused, it knows it finished staging and priming, but it doesn't see those folders anymore
<sergiusens> cprov where does this error come from? "Your account lacks information to sign build assertions for this snap."
<sergiusens> cprov I believe it comes from the store, but I thought we agreed that good error messages would tell me what to do
<sergiusens> cprov not blaming anyone in any case, just lost
<paul_r0b0t> ok. eventually i would to generate the stage folder again
<paul_r0b0t> ok. eventually i would like to generate the stage folder again
<cprov> sergiusens: snapcraft, sign-build, your account does not have upload perms on this snap. Needs a proper message, agreed
<sergiusens> cprov oh, the error is related to me not having registered the snap?
<sergiusens> even though the message does not mention that even :-)
<sergiusens> I will log a bug
<paul_r0b0t> but when i do snapcraft stage, it still "remembers" all the staged components
<paul_r0b0t> so it doesn't attempt to stage again
<cprov> sergiusens: yes, please, I will tackle this in a bit.
<mhall119> paul_r0b0t: try "snapcraft clean -s stage"
<mhall119> it might not like that though, since it's out of sync
<mhall119> worst case, run "snapcraft clean" to reset snapcraft back to a clean slate
<mhall119> but you'll have to do the pull and build steps again if you do
<paul_r0b0t> yes, i tried snapcraft clean
<paul_r0b0t> but complains b/c it cant find many of the folders
<mhall119> then "snapcraft stage" will get you to the point where you have a ./stage/ folder agian
<paul_r0b0t> snapcraft stage doesnt do much
<paul_r0b0t> b/c it thinks or "remembers" all the staged components
<sergiusens> cprov LP: #1628671
<mup> Bug #1628671: Assertion error message with no useful end user information <Snapcraft:New> <Software Center Agent:New> <https://launchpad.net/bugs/1628671>
<mhall119> paul_r0b0t: what folders do you still have there?
<paul_r0b0t> so it doesn't attempt to generate them again
<paul_r0b0t> mhall119: only parts
<sergiusens> cprov with a proper snap I get $ snap sign-build telegram-sergiusens_0.10.8_amd64.snap error: the required flags `--developer-id' and `--snap-id' were not specified
<mhall119> ok, parts is where it stores your state info I believe, so if you remove that you should be able to start over
<cprov> sergiusens: wow, 'snapcraft sign-build' not *snap*
<cprov> sergiusens: snap is driven by snapcraft
<sergiusens> cprov doh
<sergiusens> cprov heh, autocomplete fail :-)
<cprov> :-)
<paul_r0b0t> yeah, only catch is that i have some local code in parts that i have changed
<paul_r0b0t> so ideally i would just like to build
<paul_r0b0t> and stage
<sergiusens> cprov nice, another weird message 'Could not assert build: Snap builds are currently disabled.'
<kyrofa> paul_r0b0t, then remove everything in parts other than the `plugins` folder
<kyrofa> paul_r0b0t, then run snapcraft clean again
<sergiusens> cprov so nice, I have my assertion :-) comma, look at this
<kyrofa> paul_r0b0t, ah, you've been editing code in parts/<part>/src?
<sergiusens> paul_r0b0t you shouldn't be adding local code in parts
<paul_r0b0t> kyrofa: yes
<kyrofa> paul_r0b0t, yeah, it's not really made for that
<sergiusens> paul_r0b0t instead clone and point `source: <path-on-disk>`
<kyrofa> paul_r0b0t, but you can get up and running if you remove all the files in parts/*/state/ EXCEPT for the one named `pull`
<sergiusens> paul_r0b0t stuff in parts/<part-name> is there for discoverability not so much for changing; well quick experiments but not much else
<cprov> sergiusens: staging is enabled and I will enable production when we are happy.
<paul_r0b0t> all: yes, i understand that its not the best practice to add local code in parts
<sergiusens> cprov got it
<kyrofa> paul_r0b0t, then you can't be surprised when things break down :)
<paul_r0b0t> but it has been convenient to use snapcraft in order to setup quickly my development environment
<paul_r0b0t> not what snapcraft has beeen made for
<paul_r0b0t> i guess i can keep a backup of local parts source code
<paul_r0b0t> then remove everything in parts except 'plugins'
<paul_r0b0t> and run snapcraft clean
<kyrofa> paul_r0b0t, or do what sergiusens recommended, but yeah, that works too
<paul_r0b0t> kyrofa, sergiusens, mhall119, : thx!
<sergiusens> cprov darn, my search for a string failed I will kill that bug I logged as your branch isn't merged yet
<cprov> sergiusens: Can I amend my PR with the error messages fix or to do you prefer a new one because that is already fully tested ?
<sergiusens> cprov ammend is fine
<cprov> sergiusens: will do, thanks.
<sergiusens> cprov no need to ammend either, we can squash on merge (which will make it easier to review the delta actually)
<sergiusens> cprov also, do we have a bug for this; sorry I am super slow today
<cprov> sergiusens: no, we do not since it's a new UX feature, I will create one.
<cprov> sergiusens: new commit for you appreciation ;-)
<sergiusens> cprov that looks much nicer :-)
<cprov> sergiusens: np, sorry for letting it slip.
<cprov> it was equivalent to display "You suck!" on the terminal ;-)
<mup> PR snapd#2027 opened: asserts: support parsing the plugs stanza i.e. plug rules in snap-declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/2027>
<cwayne> sergiusens: if i push up a new snapcraft.yaml for a remote part, how long does it usually take before snapcraft update sees it
<josepht> cwayne: roughly an hour
<josepht> sergiusens: ^
<cwayne> josepht: thanks
<josepht> cwayne: np
<mup> PR snapcraft#833 closed: Add links to IRC, mailing list and social media <Created by dholbach> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/833>
<lool> ogra_: around still?
<lool> or anyone: where's the source for the gadget snaps for rpi*?
<mup> PR snapd#2015 closed: asserts: introduce AttributeConstraints <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2015>
<mup> PR snapcraft#831 closed: 'sign-build' implementation <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/831>
<cwayne> sergiusens: so i was able to build checkbox with that branch, so lgtm on that front at least :)
#snappy 2016-09-29
<mup> PR snapcraft#837 opened: kernel plugin: allow collecting the same mod deps <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/837>
<sergiusens> cwayne thanks!
<sergiusens> cwayne I hope you notice it is a smaller snap than before too ;-)
<cwayne> ooh I like that :)
<mup> PR snapcraft#838 opened: pluginhandler: take the file encoding into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/838>
<mup> PR snapcraft#839 opened: Fixing 'sign-build' integration tests <Created by cprov> <https://github.com/snapcore/snapcraft/pull/839>
<cprov> otherwise if falls apart with the static name, https://travis-ci.org/snapcore/snapcraft/builds/163606844
<zyga> o/
<mup> PR snapd#2003 closed: debian: adjust packaging for trusty/deputy systemd <Created by vosst> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2003>
<dholbach> good morning
<zyga> hey dholbach
<zyga> morphis_: hey
<zyga> morphis_: I got things to work last night
<dholbach> hey zyga
<dholbach> can somebody respond to the comment in https://plus.google.com/u/0/+DanielHolbach/posts/Xiho2rVSmEg?cfem=1?
<morphis_> zyga: wow!
<morphis_> zyga: how?
<davmor2> ogra_: so it looks like my bug from yesterday is because of upgrades so I'm going to do a bunch of testing around that today and see if I can trigger it
<deymon0077> hello
<zyga> morphis_: re
<zyga> morphis_: let me show you
<zyga> morphis_: http://paste.ubuntu.com/23250152/
<zyga> try this script please
<morphis_> zyga: what should I do when I am in the bash shell
<deymon0077> how to contact the community manager :?
<deymon0077> help me please
<zyga> morphis_: you can mount anything in /media
<zyga> morphis_: and look at /proc/self/mountimfo
<zyga> info*
<zyga> morphis_: both inside and outside of the shell
<zyga> deymon0077: hey, how can I help you?
<morphis_> zyga: wow
<morphis_> it works :-)
<zyga> morphis_: I'll make the changes to snap-confine today
<morphis_> great
<morphis_> will read through the script later
<deymon0077> I have a question: can I in the town of open courses circle to work with Linux such as Ubuntu?
<zyga> deymon0077: hmm, can you re-phrase that question?
<deymon0077> yes of course 1 minute
<deymon0077> if I could, in our city open circle work on Linux Ubuntu in particular
<deymon0077> is it possible to? or not?
<deymon0077> I am waiting for an answer to the impatient
<zyga> deymon0077: I don't see any problem with that
<zyga> deymon0077: this is not the best forum to ask about things like that
<zyga> deymon0077: I would recommend to post questions to ...
<zyga> deymon0077: https://lists.ubuntu.com/#Ubuntu+Worldwide+LoCo+Teams
<zyga> deymon0077: match the country that you are living in
<zyga> deymon0077: you can connect to the local community of ubuntu users and developers this way
<zyga> deymon0077: on that page you can also find many interesting mailing lists
<deymon0077> Thank you very much! Good luck. I will try it =)
<deymon0077> Have a nice day and all delicious cookies)
<mup> PR snapd#2005 closed: asserts,overlord,snap: add prepare-device hook for device registration <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2005>
<mup> PR snapd#2028 opened: doc: added timezone-control to interfaces doc <Created by stolowski> <https://github.com/snapcore/snapd/pull/2028>
<mup> PR snapd#1990 closed: many: allow use of the system user assertion with create-user <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/1990>
<deymon0077>  Hello, good advise Russian forum ubuntu?
<deymon0077> I'm from Ukraine
<deymon0077> or a good foreign forum
<deymon0077> tell me a good forum ubuntu
<deymon0077> ?
<zyga> deymon0077: perhaps ask in #ubuntu
<zyga> deymon0077: this channel is specific to snappy
<mup> PR snapd#2029 opened: daemon, store: switch to new store APIs in snapd <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2029>
<mup> PR snapd#2030 opened: coreconfig: nuke it. Also, ignore po/snappy.pot <Created by chipaca> <https://github.com/snapcore/snapd/pull/2030>
<mectors> when you connect a content plug and slot, is there a directory that gets mounted?
<mup> PR snapd#2017 closed: store: download deltas if explicitly enabled <Created by absoludity> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2017>
<ogra_> mectors, wait for mhall119, i think he has some experience with the content interface
<mectors> ogra, thanks
<sborovkov> zyga: I think I actually lied to you yesterday. I had dont apt upgrade and snap was working indeed. But when I did install the next version of my snap (build with the same version of snapd) I ran into the same issue again. After new revision of snap got installed it once again complains about wrong arm architecture. :(
<pstolowski> jdstrand, hello, fyi, https://github.com/snapcore/snapd/pull/2028/files & apologies for forgetting about it in the earlier PR
<mup> PR snapd#2028: doc: added timezone-control to interfaces doc <Created by stolowski> <https://github.com/snapcore/snapd/pull/2028>
<ogra_> hmm, whats up with the latest snapd ...
<ogra_> after my dragonboard auto-upgraded today i get:
<ogra_> ogra@dragon:~$ snap list
<ogra_> error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: dial unix /run/snapd.socket: connect: connection refused
<ogra_> ogra@dragon:~$
<ogra_> ogra@dragon:~$ systemctl status snapd.service
<ogra_> â snapd.service - Snappy daemon
<ogra_>    Loaded: loaded (/lib/systemd/system/snapd.service; enabled; vendor preset: enabled)
<ogra_>    Active: inactive (dead) (Result: exit-code) since Sat 2016-09-24 11:24:12 UTC; 5 days ago
<ogra_>   Process: 2106 ExecStart=/usr/lib/snapd/snapd (code=exited, status=1/FAILURE)
<ogra_>  Main PID: 2106 (code=exited, status=1/FAILURE)
<ogra_> wow, thats really badly broken
<ogra_> mvo, zyga ^^^ seems i had a failed upgrade for some reason, now my dragonboard install is in a unrecoverably state telling me snapd is to old
<ogra_> ogra@dragon:~$ cat /proc/cmdline | tr ' ' '\n'|grep snap_core
<ogra_> snap_core=ubuntu-core_425.snap
<ogra_> ogra@dragon:~$ ls -l /var/lib/snapd/snaps/ubuntu-core_*|tail -1
<ogra_> -rw------- 1 root root 64577536 Sep 26 06:17 /var/lib/snapd/snaps/ubuntu-core_745.snap
<ogra_> ogra@dragon:~$
<ogra_> Sep 24 11:24:09 dragon systemd[1]: Reached target Bluetooth.
<ogra_> Sep 24 11:24:10 dragon snapd[2007]: error: cannot downgrade: snapd is too old for the current system state (patch level 4)
<ogra_> Sep 24 11:24:10 dragon systemd[1]: snapd.service: Main process exited, code=exited, status=1/FAILURE
<ogra_> Sep 24 11:24:10 dragon systemd[1]: snapd.service: Unit entered failed state.
<ogra_> Sep 24 11:24:10 dragon systemd[1]: snapd.service: Failed with result 'exit-code'.
<ogra_> Sep 24 11:24:10 dragon systemd[1]: snapd.service: Service hold-off time over, scheduling restart.
<ogra_> Sep 24 11:24:10 dragon systemd[1]: Stopped Snappy daemon.
<ogra_> thats what i see on boot
<sergiusens> ogra_ well now you know, snapd is too old :-P
<ogra_> sergiusens, well ... i see three ubuntu-core snaps ... one seems to be the broken 745 one, the other the reliably working 738 one ... but for some reason there is also a 425 that got picked by the auto-rollback mechanism
<ogra_> (instead of rolling back to 738)
<sergiusens> ogra_ thanks for clarifying conf/modules ;-)
<ogra_> :)
<sergiusens> ogra_ surely a new feature/bug as I don't think we support that in 16 at all (use to in 15.04 through ubuntu-core config hook)
<ogra_> well, and we shouldnt ...
<ogra_> the kernel needs to auto-load whats needed ...
<ogra_> i suspect the modules.dep is wrong .... it needs to be re-generated for exactly the module set that is inside the initrd
<ogra_> before re-compressing
<sergiusens> ogra_ it should load what it needs, but what if the module takes some specific options like disable_802.11n=true (or however it was formatted)
<ogra_> ah, yeah, that would need something in th emodules.d dir ... a config file
<ogra_> *in the modules.d dir
<sergiusens> ogra_ it used to be correct as it used to work and the kernel plugin only got love from ppisati since its introduction and this bug fix now
<ogra_> errr
<ogra_> /etc/modprobe.d that is
<ogra_> i guess we need more info like a kernel log from serial during boot and such ...
<zyga> sborovkov: hmm, interesting
<ogra_> to see why it wasnt loaded
<zyga> sborovkov: can you strace both cases?
<ogra_> so back to my main prob ...
<ogra_> why do we keep three vervisions of ubuntu-core ... and why do we roll back to the obviously obsolete one
<ogra_> an end user would now have to re-flash
<ogra_> *revisions
<ogra_> i guess thats a serious blocker
<jdstrand> pstolowski: thanks!
<mup> PR snapd#2028 closed: doc: added timezone-control to interfaces doc <Created by stolowski> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<ogra_> eeek
<ogra_> ogra@dragon:~$ ls -l /var/lib/snapd/snaps/ubuntu-core_*
<ogra_> -rw------- 1 root root 57589760 Sep 29 10:20 /var/lib/snapd/snaps/ubuntu-core_425.snap
<ogra_> -rw------- 1 root root 64577536 Sep 25 08:19 /var/lib/snapd/snaps/ubuntu-core_738.snap
<ogra_> -rw------- 1 root root 64577536 Sep 26 06:17 /var/lib/snapd/snaps/ubuntu-core_745.snap
 * ogra_ notices the timestamps 
<ogra_> so obviously it didnt not roll back but *upgraded* to 425 ... which is the last stable ubuntu-core
<mup> PR snapd#2028 opened: doc: added timezone-control to interfaces doc <Created by stolowski> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<ogra_> it did that automatically !
<ogra_> smells like snapd has a bug in the channel handling here
<mup> PR snapd#2028 closed: doc: added timezone-control to interfaces doc <Created by stolowski> <Closed by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<ogra_> mvo, zyga did anything change in that regard recently ?
<ogra_> (with the new snapd)
<zyga> jdstrand: hey
<sborovkov> zyga: in an hour. Need to test my snap first. How do I strace what snapd does?
 * ogra_ wonders if we have a GA blocker tag for bugs 
<zyga> sborovkov: hmm, good question, you can probably just strace the command and coupled with -f -o you should get the full output
<jdstrand> hey zyga :)
<zyga> ogra_: I don't know really
<ogra_> zyga, well, thats pretty disastrous
<zyga> ogra_: I don't get notifications in irssi unless my name is the first one
<zyga> ogra_: note that this is under the control of the store
<mup> PR snapd#2028 opened: doc: added timezone-control to interfaces doc <Created by stolowski> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<zyga> ogra_: it's not true that revisions can be compare
<zyga> *compared
<zyga> ogra_: the most recent revision is whatever the store is claming
<zyga> claiming
 * zyga needs that coffee
<ogra_> zyga, well, the image is created with "-c edge, it should never ever pull ubuntu-core from stable
<ogra_> unless i manually tell it to
<mup> PR snapd#2028 closed: doc: added timezone-control to interfaces doc <Created by stolowski> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<ogra_> and i think thats set up inside the imge, not in the store
<ogra_> via seed.yaml or so
<zyga> ogra_: that may be a bug in the image building tool
<zyga> ogra_: but I don't know how this works either nowadays,
<zyga> ogra_: you can peek at /var/lib/snapd/state.json
<ogra_> well, that image is from last week ... it sat there without me touching it and auto-upgraded on its own for the last days
<zyga> ogra_: and check which channel you are tracking
<ogra_> i#'m actually logging in for the first time today
<ogra_> it did the auto-upgrade just fine until today it seems
<jdstrand> zyga: re irssi-- is that your intended workflow? I use irssi and get proper highlighting. (I use '{ text = "jdstrand"; nick = "yes"; word = "yes"; },' in the 'hilights' section of config). I also use something called hilightwin.pl
<jdstrand> (perhaps you are missing 'word = "yes"' for your nick)
<ogra_> hmm, interestingly the pi3 went properly to 766 on the edge channel
<zyga> jdstrand: is there a way to reload config without quitting? :)
 * zyga wishes for vim for irc 
<jdstrand> zyga: yes. /reload
 * ogra_ tickles mvo 
<jdstrand> zyga: I think you may need to do /save
<jdstrand> zyga: otherwise when you shutdown it might go away. I can't recall otoh
<mup> PR snapd#2028 opened: doc: added timezone-control to interfaces doc <Created by stolowski> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<mup> PR snapd#2028 closed: doc: added timezone-control to interfaces doc <Created by stolowski> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2028>
<jdstrand> zyga: hilightwin.pl isn't needed for this, but I find it handy. you can put it in a window and all your highlights show up there. good for seeing what to tend to first in backscroll
<ogra_> mvo, did you do any channel fiddling for ubuntu-core today in the store ?
<ogra_> which could have caused the aboev ...
<ogra_> **above
<jdstrand> mvo: hi! wondering if someone is assigned to snapd failing migration in yakkety-proposed for the last few weeks. I ask because bug #1626121, which has been fixed for a while in yakkety-proposed, keeps coming up in my circles (latest was running snapd in lxd)
<mup> Bug #1626121: strict mode snaps crash with Segmentation fault on 16.10 <Snappy Launcher:Invalid> <Snapcraft:New> <Snappy:Fix Committed by jdstrand> <snap-confine (Ubuntu):Invalid> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1626121>
<zyga> I wonder if this causes a highlight (zyga)
<zyga> hmmm
<ogra_> the zyga !
<zyga> nope :/
<zyga> let me restart
<ogra_> zyga the
<ogra_> what client ?
<jdstrand> hi zyga!
<zyga> irssi
<zyga> grr
<ogra_> hmm
<jdstrand> weird
<zyga> nope
<zyga> probably a typo
<zyga> le me google
<cjwatson> my config has "hilights = ( { text = "cjwatson"; nick = "yes"; word = "yes"; } );" and that works fine
<ogra_> sudo snap install hexchat ;)
<cjwatson> probably /hilight -nick -word zyga or some such (possibly as two separate commands)
<zyga> ogra_: one day :)
<qengho> popey: I saw your game snapping video. It's really good.
<ogra_> haha
<zyga> old habits you know
<ogra_> yeah, same here ...
<ogra_> (other way around though)
<jdstrand> zyga: it could be a typo... I wonder if maybe in another part of your 'hilights' section
<jdstrand> ogra_: new habits die fast?
<ogra_> who had the brilliant idea to call the option "hilights"
<zyga> ah
<ogra_> that screams for typos ;)
<zyga> sigh
<zyga> yes
<zyga> it does :)
<jdstrand> re hilights> I know, right?
<jdstrand> the fact that the config file is perl is nice too
<zyga> hit me!
<ogra_> hey zyga
<zyga> gaah
<zyga> screw this ...
<ogra_> all work and no play makes zyga a dull boy
<zyga> I'll get back to coding
<zyga> is there a joke about writing an IRC client because irssi has a lousy config
<jdstrand> zyga: I promise, it can be made to work :) (perhaps another time)
<cjwatson> I've generally found that the path to wisdom in irssi is to forget about writing the config file by hand and to maintain it exclusively by running commands in irssi and then /save
<cjwatson> far easier and you can test stuff on the fly
<cjwatson> and as far as I'm aware you can do everything interactively like that anyway
<jdstrand> cjwatson: that is probably very wise
<jdstrand> it is really easy to mess up your config
<zyga> hee, let's try this: snap-confine
<zyga> hmm
<jdstrand> hi zyga!
<zyga> yes
<zyga> it worked
<jdstrand> \o/
<ogra_> congrats
<zyga> now I will catch all the people talking about snap-confine
<zyga> thanks jdstrand :)
<jdstrand> that is a mixed blessing ;)
<jdstrand> zyga: you're welcome! :)
<popey> qengho: thanks!
<sborovkov> zyga: so I see ther eis a bunch of snapd services. Which one I need to run with snapd? Anything I need to pass to it? can you give me the command line. Just upgraded everything for that
<mup> Bug #1628914 opened: ubuntu-core edge image switched to stable channel unpredictably and became unusable <Snappy:New> <https://launchpad.net/bugs/1628914>
<zyga> sborovkov: it's not snapd, just run the program you care about
<zyga> sborovkov: snapd doesn't participate in that
<ogra_> mvo, niemeyer, bug #1628914 seems pretty serious ...
<mup> Bug #1628914: ubuntu-core edge image switched to stable channel unpredictably and became unusable <Snappy:New> <https://launchpad.net/bugs/1628914>
<mvo> ogra_: I promoted the ubuntu-core snaps from yesterday to beta, that was the only change I did
<ogra_> mvo, well, any idea how the above could happen ?
<mvo> jdstrand: yaketty-proposed> sort of, autopkgtest is driving me nuts, there is a failure on i386 right now but its not happening in my adt VM that I use for testing
<jdstrand> mvo: oh I hate that :(
<mvo> ogra_: let me look
<mvo> jdstrand: yeah, exactly, each adt run takes ~45min, so debugging that is a pain
<ogra_> the bug should have all info aggregated now
<mvo> jdstrand: and its *only* failing on i386 and only on the actual adt runner on LP/whatever-stack, not locally
<mvo> ogra_: can I get the uboot.bin too? or the output of fw_prrintenv?
<ogra_> sure
<ogra_> mvo, atteched on the bug
<sborovkov> zyga: well... is not that arm version issue in snapd... I can't run my app easily. It's a bit complicated as it's buildrooted.
<mvo> ogra_: so the ubuntu-core switched to "stable" which is strange
<ogra_> mvo, yeah
<ogra_> out of the blue
<mvo> ogra_: the state has it set to "channel: stable"
<mvo> ogra_: so somethng switched it, anything in history?
<ogra_> mvo, but beyond that switch ... the fact that snapd cant run when an older ubuntu-core is used is way more worrying
<ogra_> mvo, nothing ... i sideloaded kgunn's unity8-session snap and installed classic before to have wget available, thats all
<ogra_> beyond that i havent even logged in since i installed the board initially
<mvo> ogra_: in a meeting right now, but it is definitely worrying
<mvo> ogra_: channels should never switch except when the user explicitely sets it
<mvo> ogra_: could you add the "history" ?
<ogra_> mvo, right ... and i assume snapd should stay executable even if i roll back
<mvo> ogra_: that isa separate problem :/
<ogra_> mvo, which history exactly ? i added state.json
<mvo> ogra_: and a pretty big one actually
<mvo> ogra_: shell history
<ogra_> ah
<ogra_> sure
<mvo> ogra_: what commands might have caused this misbehavior
<zyga> jdstrand: hey, I need a review on a patch for snap-confine that gustavo asked me to release quickly, I will add a few spread tests for it but can you have a quickly initial look at https://github.com/snapcore/snap-confine/pull/161
<mup> PR snap-confine#161: Prefer the "core" snap is one is available <Created by zyga> <https://github.com/snapcore/snap-confine/pull/161>
<ogra_> mvo, added
<mhall119> mectors: you might need to talk to zyga about the 'write' property of the content interface, as well as ways to share snap data files between snaps
<ralsina> sergiusens: for this failure: https://travis-ci.org/snapcore/snapcraft/jobs/163709462 is that I need to add snap as a dependency, or that I am not faking enough?
<sergiusens> ralsina before going crazy, https://github.com/snapcore/snapcraft/pull/839
<mup> PR snapcraft#839: Fixing 'sign-build' integration tests <Created by cprov> <https://github.com/snapcore/snapcraft/pull/839>
<ralsina> sergiusens: phew
<ralsina> it's not that failure tho :-)
<mvo> ogra_: thank you
<ogra_> np
<sergiusens> ralsina doesn't seem related though
<sergiusens> yeah
<ralsina> I am using "snap sign" on an assertion I generate that is predictable and the integration test passes locally
<ralsina> But on staging it's not finding the snap command
<ralsina> on travis, I mean
<sergiusens> ralsina we don't install snapd for our unit tests
<ralsina> sergiusens: hmmm
<ralsina> sergiusens: ok, I can fake it
<sergiusens> ralsina yeah, that would be better; signing on unit tests can get tricky
<zyga> mectors: the write property cannot be used at this time, we should expand (and design this) the interface to allow to refer to wriable data as well as to readable data/ code
<oparoz> zyga, it should definitely be reflected in the documentation as it takes a lot of trial and errors to figure out that it doesn't work at all
<zyga> oparoz: yes, I know, there are many things that need improvements
<zyga> oparoz: if you want please improve the documentation straight away, it takes a moment to do this and we merge lots of stuff daily
<oparoz> I'm happy to submit a PR
<oparoz> Just not sure about the direction. Just remove that attribute?
<jdstrand> zyga: done
<zyga> oparoz: document what works today perhaps
<zyga> oparoz: start with someting and let's see what we get in the feedback
<zyga> jdstrand: thank you
<zyga> oh, so that's how it sounds when a kernel doesn't boot
<zyga> the beep
<zyga> man
<zyga> don't run your kernel while listening to meeting/hangout
<clobrano> Hi All, is still possible to create snaps for 15.04? If so, where could I find the correct snapcraft version?
<zyga> clobrano: I believe the answer is yes, you will need an older version of ubuntu as a base though (perhaps 15.04, I don't recall)
<clobrano> zyga: I see, thanks!
<mup> PR snapcraft#839 closed: Fixing 'sign-build' integration tests <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/839>
<mup> PR snapd#2031 opened: store: apply deltas if explicitly enabled <Created by absoludity> <https://github.com/snapcore/snapd/pull/2031>
<mup> PR snapd#2032 opened: tests: fix create-key/snap-sign test isolation <Created by cjwatson> <https://github.com/snapcore/snapd/pull/2032>
<mup> PR snapcraft#826 closed: Do not depend on Content-Length when Content-Encoding is gzip <Created by tachyons> <Closed by tachyons> <https://github.com/snapcore/snapcraft/pull/826>
<sergiusens> ogra_ so snapcraft#838 solves it for you, right?
<mup> PR snapcraft#838: pluginhandler: take the file encoding into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/838>
<mup> PR snapcraft#837 closed: kernel plugin: allow collecting the same mod deps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/837>
<ogra_> sergiusens, thats what i added to the PPA yesterday afaik
<ogra_> sergiusens, though with completely turned off tests during package build
<sergiusens> ogra_ yeah, this doesn't have the prints and has unit tests ;-)
<ogra_> then it should be fine
<sergiusens> ogra_ did you install the image onto your phone though? that is the important question
<ogra_> i'll happily tests it from -proposed once there is a package
<ogra_> i rarely install snappy images onto my phone ...
<ogra_> extremely rarely ...
<ogra_> like ... never :P
<sergiusens> ogra_ but this architecture is a good one ;-)
<ogra_> sergiusens, but that is because sabdfl has not approved to get me an s390x phone for testing purposes yet
<sergiusens> ogra_ btw, can I add you into the release process?
<ogra_> what does that involve ?
<sergiusens> ogra_ ping you to test snapcraft from xenial-proposed and just confirm it still works
<ogra_> sure
<sergiusens> great
<sergiusens> elopio ^^
<sergiusens> ogra_ you may think I do, but I actually dislike regressions as small as they are if they are not planned
<ogra_> just improve your planning skills then :)
<ogra_> - "worst thing"
<ogra_> just put that on your planing doc and be done
<mup> PR snapd#2030 closed: coreconfig: nuke it. Also, ignore po/snappy.pot <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2030>
<sergiusens> ogra_ lol; the "learn how to plan" douche card :-P
<mup> PR snapcraft#838 closed: pluginhandler: take the file encoding into account <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/838>
<ogra_> heh
<mhall119> zyga: a krita snap user is saying he can't access files on an external hard drive from inside krita, is there a ready way to give access to that (without using --devmode) or should I file a bug?
<elopio> ping pitti, I think we are ready to put the project in wendigo. Should I send you the token and secret?
<mup> PR snapd#2011 closed: client, cmd: change buy command to match UX document <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2011>
<mup> PR snapd#2029 closed: daemon, store: switch to new buy APIs in snapd <Created by pete-woods> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2029>
<mup> PR snapd#2025 closed: snap/implicit: don't restrict the camera iface to clasic <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2025>
<sabdfl> ogra_, you just have to carry it home ;)
<ogra_> i'll put it on top of the lawnmower !
<ogra_> (as cart)
<mup> PR snapd#1810 closed: interfaces/builtin: fix fcitx support in unity7 <Reviewed> <Created by chihchun> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1810>
<mup> PR snapd#2033 opened: many: move firstboot code into the snapd daemon <Created by mvo5> <https://github.com/snapcore/snapd/pull/2033>
<mup> PR snapd#2032 closed: tests: fix create-key/snap-sign test isolation <Created by cjwatson> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2032>
<mup> PR snapd#1775 closed: interfaces: add thumbnailer interface <Created by fkaleo> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/1775>
<mup> PR snapd#2034 opened: Modify the description of the content interface <Created by oparoz> <https://github.com/snapcore/snapd/pull/2034>
<mup> Bug #1628616 changed: Hello nextcloud claws-mail-moon127 all segfault on yakkety <Snappy:Confirmed> <https://launchpad.net/bugs/1628616>
<zyga> mhall119: mmm
<zyga> mhall119: I think there's no interface for now
<zyga> mhall119: or perhaps there is one
<zyga> mhall119: I think someone added it
<oparoz> We need access to mounted storage
<zyga> mhall119: there is an interface, tell them to use "removable-media" please
<zyga> oparoz: ^^ :)
<elopio> hey zyga, why don't you snap teleport? Seems cool
<zyga> elopio: it is cool, I need to look into it more to decide if it would work well as a snap today
<oparoz> zyga, does that work with NFS and CIFS mounted storage?
<zyga> oparoz: it gives you access to /media and /run/media
<zyga> oparoz: if you mount it there, yes, otherwise it won't
<oparoz> zyga, I'll try that, thanks!
<ogra_> zyga, i guess we'd want a network-storage interface anyway at some point
<ogra_> for such protocols
<ogra_> or network-filesystem
<zyga> ogra_: where do you mount network storage?
<zyga> ogra_: if the answer is "it depends" it hard to write the interface for it :)
<oparoz> zyga, can snaps mount storage?
<ogra_> either where the fstab entry defines or whereever the interface allows you to in the confined area if there is no fstab entry
<zyga> oparoz: I'm working on this, they will be able to in the next release
<zyga> oparoz: (you would not believe what is required to make this possible)
<zyga> ogra_: what happens when fstab changes?
<oparoz> ogra_, if I mount locally, then other snaps can't access my content (yet)
<zyga> ogra_: you have to reload apparmor profiles of all apps?
<oparoz> zyga, awesome news :)
<zyga> ogra_: it's complex IMHO
<ogra_> zyga, i dont think it is complex ... you can start with ignoring fstab and just allow the snap to mount a network FS in the confined area for a start
<ogra_> using the fuse interface and sshfs makes that already possible
<zyga> ogra_: that's different
<ogra_> would just be an extension of that
<zyga> ogra_: mounting is super privileged
<ogra_> network FS mounting too ?
<ogra_> i think thats pretty different
<zyga> ogra_: the removable-storage iface lets you see things that are mounted by something else
<ogra_> right
<zyga> ogra_: the new thing lets you do the mounting
<zyga> ogra_: but only in /media again
<zyga> ogra_: (or /run/media)
<ogra_> i just dont think allowing to mount network FSes inside your snap is any dangerous
<zyga> ogra_: well, mounting anything anywhere can really quickly blow your system up
<zyga> ogra_: as I've learned this and last week :)
<ogra_> if a server exports it to you you are obviously allowed to mount it ...
<zyga> anyway, have to run to a meeting
<oparoz> Does the removable-storage interface give you to everything which is in media? Like one snap creates folder there, another can access them?
<zyga> oparoz: yes, to everything in /media
<zyga> oparoz: yes, that would work
<oparoz> Awesome, thank you zyga!
<zyga> my pleasure :)
<ogra_> that sounds a bit like a cheat to the content-share interface :P
<oparoz> Indeed! :D
<oparoz> But soooo needed :)
<zyga> ogra_: thumb drives win for media sharing over network attached storage, once again :)
<ogra_> well, i just think it is a cheaply to achieve extra to allow NFS/CIFS mounting in the snap confined area
<zyga> ogra_: I'll let jdstrand tell you how that might blow up
<ogra_> the security bits have to be server side anyway ... you are just using something you have been granted access to already
<zyga> mhall119: are we doing the call today?
<zyga> mhall119: if not I can work on some coding I need to do
<mhall119> yes, one second
<mup> PR snapd#2035 opened: asserts: support parsing the slots stanza i.e. slot rules in snap-declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/2035>
<mup> PR snapd#2034 closed: Modify the description of the content interface <Reviewed> <Created by oparoz> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2034>
<mup> PR snapcraft#840 opened: Catkin plugin: build with in-snap python <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/840>
<pitti> elopio: still need to review/test/land the autopkgtest patch for supporting GitHub PR addresses; at a conference now, can we do that next Tuesday?
<elopio> pitti: yes, but I think I don't need the patch. We moved the packaging to a different branch, and I made a PR for the TEST_UPSTREAM bits, which ran okay locally.
<elopio> I can wait for you to come back, I'm in no hurry.
<pitti> elopio: ah, sure; but just driving by on IRC between talks, going to be AFK again, sorry
<mhall119> zyga: lost you
<pitti> elopio: right, let's do that when I have some time to concentrate on this
<elopio> pitti: no worries.
<zyga> mhall119: aww
<zyga> mhall119: let me reload
<elopio> I sent you an email because I thought you missed my ping. Just ignore it until next week.
<ralsina> sergiusens, elopio: except for some nitpicking from coveralls, my PR seems to have everything fixed and passing, it would be awesome if it got the re-review  today. Awesomer if it passed ;-)
<sergiusens> ralsina my mental buffer for interrupt driven review is too small for that changeset but I'll do my best :-P
<sergiusens> small and with fast timeouts
<ralsina> sergiusens: your best is the most I can ask for, dude, I know it's a large branch
<mup> PR snapcraft#832 closed: python plugin: only download in pull and build in build <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/832>
<Croepha> Hey everyone, its been a while since I did any snappy stuff, is this: http://people.canonical.com/~mvo/all-snaps/ubuntu-device-flash still state of the art for making a 16 snappy flash image?
<Croepha> nvm, i guess not, the link is dead
<kyrofa> ogra_, is ubuntu-image ready for Croepha?
<mup> PR snapd#2031 closed: store: apply deltas if explicitly enabled <Created by absoludity> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2031>
<zyga> jdstrand: got it to work, just now
<zyga> jdstrand: a few extra complications that only affect the real actual layout snaps use
<zyga> jdstrand: but nothing unexpected, just some extra requirements that pivot_root requires that need to be satisfied
<zyga> jdstrand: wow
<zyga> jdstrand: not sure why
<zyga> jdstrand: but ... mount table is so clean now :)
<jdstrand> nice!
<zyga> as a quick check
<jdstrand> zyga: would you mind pasting the mount table?
<zyga> I'll kill the lxd quirk
<zyga> nope, I'll share it in a sec
<zyga> I just want to make it ... cleaner still
<zyga> http://paste.ubuntu.com/23252159/
<zyga> now sadly, that's a bit too optimistic, there's still one bit missing there
<zyga> and I disabled the ugly LXD quirk
<zyga> oh, and I see my change broke /media too
<zyga> just pivot_root being extra picky and me being extra broad (rprivate)
<ogra_> kyrofa, not sure we have public documentation for creating and assigning assertions yet
<ogra_> beyond that, yeah
 * ogra_ vanishes
 * Croepha gets a little worried, not sure what it means to "assign assertions" or what it has to do with making a flash imaage... but moves forward confidently by grabbing the ubuntu-image source from github and trying to build via snapcraft and hoping there is some command-line documentation !
<zyga> Croepha: ?
<kyrofa> zyga, Croepha wants to build images with ubuntu-image, but isn't sure how
<kyrofa> (neither am I)
<zyga> kyrofa: -> slangasek
<kyrofa> Croepha, then slangasek is your man ;)
<Croepha> slangasek: ping?
<slangasek> hmm, am I? :)
<zyga> slangasek: or point to the next element of the list :)
<slangasek> someone had started writing up documentation on how to create the model assertion, let me see if I can lay my hands on it
<slangasek> Croepha: here's the doc I was looking for: https://docs.google.com/document/d/1cJvRnpoQyLvY6pOLFPgUxMHrFVBCDNwAlrORARBiZlU/edit
<Croepha> slangasek: requested access
<slangasek> Croepha: oh? the doc claims at the very top to be public; sorry, I guess I should have looked at actual sharing perms
<slangasek> Croepha: ah but there's also a redirect to https://github.com/CanonicalLtd/snappy-docs/pull/13
<ralsina> sergiusens: can you restart https://travis-ci.org/snapcore/snapcraft/jobs/163776334 ? It timed out on launchpad
<zyga> jdstrand: http://paste.ubuntu.com/23252266/
<Croepha> slangasek : "You need permission.  Want in? Ask the owner for access, or switch to an account with permission."
<zyga> jdstrand: lesson learne, mount -o private != mount --make-private
<zyga> jdstrand: can you see if this makes sense
<zyga> jdstrand: I'll share the code in a sec, just need to write a commit mesage
<slangasek> Croepha: yes, I guess they closed down the google doc when they moved the info into the snappy-docs repo where it belongs
<zyga> jdstrand: it's not done but feels super close now
<Croepha> slangasek: oh right, sorry, I didn't think to look at the actual github files, ok thanks! :)
<zyga> jdstrand: https://github.com/snapcore/snap-confine/commit/43e47b35a13786aa7a7aabe1a45d78febae49aa9
<zyga> jdstrand: I need to go through the whole thing and ensure docs and comments are sensible
<zyga> jdstrand: e.g. the internal strace output is stale now
<zyga> jdstrand: please look at the commit message and tell me what you think
<zyga> jdstrand: one nasty side effect of this is that there's a moment in sc_bootstrap_mount_namespace that leaks stuff if we crash
<zyga> jdstrand: it is only good if it completes all the way
<zyga> jdstrand: but this is unavoidable with MS_SHARED / now
<zyga> jdstrand: expcept for, perhaps, some guardian process that knows how to undo the mess if I something breaks
<zyga> jdstrand: but let's not go there yet
<zyga> jdstrand: and a thing to watch out for to make a bind mount that has different sharing, you need two syscalls
<zyga> jdstrand: one syscall just results in the wrong sharing
<zyga> jdstrand: I need to check my docs now
<zyga> jdstrand: but before that I need a break, a real break
<sergiusens> ralsina sure
<ralsina> sergiusens: thanks
<jdstrand> zyga: huh, snap.rootfs_* is gone in your mountinfo
<zyga> yep
<zyga> jdstrand: all gone :)
<zyga> jdstrand: see the code, tell me what you think
<zyga> jdstrand: I think I use pivot_root correctly for the first time now
<jdstrand> I was wondering if that was what cleaned it up
<zyga> jdstrand: note, not ealier, just only now
<zyga> jdstrand: I didn't try to run spread or anything (more questions to answer)
<zyga> jdstrand: I just ran shell and explored
<zyga> jdstrand: /media has the right sharing IMHO
<zyga> jdstrand: I didn't do a in-depth analysis (too tired today)
 * jdstrand nods
<zyga> jdstrand: I'm editing my copy of shared subtrees, the printout I did messed up the essential tables
<zyga> jdstrand: :) I'll give you a copy in the hague :)
<mup> PR snapd#2036 opened: daemon, store: switch to new store APIs in snapd <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2036>
<lool> ogra_: heya, would you know if we have rpi3 classic images that we maintain?
<lool> the wiki one from the community + ppa seems to have some issues
<lool> ogra_: I was hoping yakkety might have one http://cdimage.ubuntu.com/ubuntu-server/daily-preinstalled/pending/ but that's rpi2 only
<lool> slangasek: ^ perhaps you know who might possibly look after these?
<slangasek> lool: there are none currently; this is backlogged behind the ubuntu-image work, and the intent is for us to directly leverage gadget snap yaml in creating the image instead of reimplementing the image building logic in two different ways
<lool> slangasek: even for server image?
<lool> slangasek: I mean classic
<slangasek> lool: yes, because it's precisely the "how to build an image for this device" piece that is overhead which we don't want to repeat
<lool> slangasek: ok; do you have a vague idea of when we could possibly see rpi3 classic images in yakkety? or is it possible that we wont have any?
<lool> slangasek: side question, how crazy would it be to suggest adding a 16.04.N image for rpi3?  :-)
<slangasek> lool: it keeps getting pushed back in the backlog by other critical snappy work, and while people keep asking after these images no one has indicated a deadline for when they're needed.  So it's not going to be done before yakkety release, but there's no reason we can't enable it in 16.04 point release
<mup> Bug #1629081 opened: `git clone`fails with `source-type: git` nad `'source-tag: 'x.y.z` in `snapcraft.yml` <snapcraft> <Snappy:New> <https://launchpad.net/bugs/1629081>
<sergiusens> cprov ralsina so elopio is worried about lack of integration tests against real servers; isn't there a way to do the full dance in one test? snapcraft snap; snapcraft register; snapcraft push --release stable; snapcraft validate <against-self>; snapcraft gated ?
<sergiusens> cprov ralsina I guess in a new PR is ok given how big this one is
<ralsina> hmmm
<ralsina> you'd also need to create a key, and register it
<ralsina> push 2 snaps, although we could self-gate ...
<sergiusens> ralsina we have tests for keys; don't we?
<ralsina> sergiusens: yes, but this needs a real live key to work against a real store
<sergiusens> ralsina oh, no, disabled too
<sergiusens> nevermind!
<sergiusens> but I'll add it as a sprint topic
<ralsina> sergiusens: it *can* be done, looks like a bit of a hassle :-)
<ralsina> I am sure at the sprint we can do it over a beer
<ralsina> maybe 2 beers
<ralsina> and fix it for keys too
<sergiusens> I haven't been drinking lately so I might pass out after half of one
<ralsina> ok, make that a ... /me googles something very dutch
<ralsina> cheese?
<sergiusens> super excited that I will be knocked out during the long leg with just one glass of whisky :-)
<kyrofa> sergiusens, doesn't drink beer. He drinks whisky
<kyrofa> Thanks hexchat. That comma was terribly placed
<ralsina> Well, to be honest https://en.wikipedia.org/wiki/Dutch_cuisine#Alcoholic_drinks is pretty depressing :-)
<ralsina> "raisins in brandy", really, netherlands?
<kyrofa> ralsina, man, and here I was all excited
<kyrofa> And their main picture is heineken?
<ralsina> kyrofa: or Grolsch!
<kyrofa> That just _sounds_ gross
<kyrofa> Kraamanijs sounds good though
<mup> PR snapd#2010 closed: many: create auth.json for the freshly created user in `snap create-user` <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2010>
<sergiusens> ralsina http://try.docopt.org/?doc=snapcraft%0D%0A%0D%0AUsage%3A%0D%0A++snapcraft+validate+%3Csnap-name%3E+%28--keys+%3Cone%3E+%7C+%3Ctwo%3E%29&argv=validate+snap+--keys+1
<ralsina> sergiusens: turned out what we needed was snapcraft validate <thingie>... [--key=<key-name>]
<ralsina> BTW, renamed thingie to validation if that's ok with you
<sergiusens> ralsina perfect
<mup> PR snapcraft#840 closed: Catkin plugin: build with in-snap python <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/840>
<mup> PR snapcraft#841 opened: Replace SNAPCRAFT_PART_INSTALL in the part attributes <Created by josepht> <https://github.com/snapcore/snapcraft/pull/841>
<mup> PR snapd#2027 closed: asserts: support parsing the plugs stanza i.e. plug rules in snap-declarations <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2027>
<mup> PR snapcraft#842 opened: Catkin plugin: Support ROS Kinetic <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/842>
<mup> PR snapcraft#772 closed: Set GOBIN in go plugin build environment <Created by tasdomas> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/772>
<Croepha> with ubuntu-image do you have to upload your kernel snap to the store?
#snappy 2016-09-30
<mup> PR snapd#2037 opened: asserts,interfaces/builtin,overlord/assertstate: introduce base-declaration <Created by pedronis> <https://github.com/snapcore/snapd/pull/2037>
<mup> PR snapd#2038 opened: many: add email to UserState <Created by matiasb> <https://github.com/snapcore/snapd/pull/2038>
<mwhudson> uh
<mup> PR snapcraft#843 opened: Add `snapcraft history` and `snapcraft status` <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/843>
<mup> PR snapd#2039 opened: overlord/configstate: support nested configuration <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2039>
<mup> PR snapd#2038 closed: many: add email to UserState <Created by matiasb> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2038>
<mup> PR snapd#2040 opened: daemon: add support for `snap create-user --known` <Created by mvo5> <https://github.com/snapcore/snapd/pull/2040>
<dholbach> good morning
<mup> PR snapd#2041 opened: daemon: add `snap create-user --force-managed` support <Created by mvo5> <https://github.com/snapcore/snapd/pull/2041>
<mup> PR snapd#2042 opened: daemon: add users to the sysInfo data <Created by mvo5> <https://github.com/snapcore/snapd/pull/2042>
<popey> As a user of a snap, is there a planned way to get in contact with a developer, or leave a review for a broken snap?
<popey> e.g. htop is broken on the pi, but works on amd64
<mup> PR snapd#2036 closed: daemon, store: switch to new store APIs in snapd <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2036>
<ogra_> popey, htop works here, whats your issue ?
<ogra_> (pi3 that is)
<mup> PR snapd#2043 opened: store: change purchase to order and store clean up first pass <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2043>
<popey> ogra_: 2016/09/29 14:49:55.859377 cmd_run.go:179: WARNING: cannot create user data directory: cannot create "/home/popey/snap/htop/41": mkdir /home/popey/snap/htop: permission denied
<popey> failed to create user data directory. errmsg: Permission denied
<popey> when i try and run it
<ogra_> popey, thats not a htop issue .... i assume you have classic installed and ran sudo classic ?
<popey> yes
<oparoz> Hello, where do we report issues with the snap store?
<ogra_> and you installed that as your first snap ?
<popey> possibly, yes
<ogra_> well, then the sudo caused /home/popey/snap to be created root owned
<ogra_> jusz chrown -R popey /home/popey/snap
<oparoz> Is "Developer registration portal" correct?
<ogra_> there is a bug open somewhere about that
<popey> ok, thanks
<popey> \o/ fixed
<ogra_> oparoz, https://bugs.launchpad.net/software-center-agent/+filebug
<oparoz> Thanks ogra_
<ogra_> popey, bug 1620592, seems zyga is on it
<mup> Bug #1620592: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <Snappy Launcher:Triaged> <Snappy:New> <https://launchpad.net/bugs/1620592>
<mup> PR snapd#2044 opened: snap: auto-import assertions from block devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2044>
<mvo> pitti: hi, quick question - I have a udev rule in https://github.com/snapcore/snapd/pull/2044/files#diff-ae4a6795688426c8798d190872d58f89R1 that ideally triggers when a new block device is mounted. this works fine, however I noticed there is a small race, i.e. I get the udev event when the device is not fully mount (not available in /proc/self/mountinfo yet). a small wait fixes it but that is of course not ideal, do you have a suggestion how to p
<mvo> roperly fix this?
<mup> PR snapd#2044: snap: auto-import assertions from block devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2044>
<mup> PR snapd#2044 closed: snap: auto-import assertions from block devices <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2044>
 * cjwatson belatedly uploads a bzr SRU for https://bugs.launchpad.net/bzr/+bug/1606203 (though it'll need SRU team approval)
<mup> Bug #1606203: Failed to build of snappy package on Launchpad: Invalid header value 'Basic U05BUEJVSUxELTE4NzAtMTQ2OTQyNjE0ODpjOTJkYzVjOWQ0OTg0ZGE5OWZlNGY1ZjI3ODRhMWJk\nOA==' <launchpad> <snappy> <Bazaar:Fix Committed by vila> <Snapcraft:Invalid by sergiusens> <bzr (Ubuntu):Fix Released> <bzr
<mup> (Ubuntu Xenial):In Progress by cjwatson> <https://launchpad.net/bugs/1606203>
<ogra_> cjwatson, whee !
<pitti> mvo: err, udev rules do NOT trigger on mounts, at least not in general; they trigger when a device appears or goes away, or gets reformatted
<pitti> mvo: how do you mount the device?
<pitti> mvo: sorry, on a conference, 'orribly lagging on IRC
<pitti> mvo: if "snap auto-import" does the mouting by itself, don't you want to hand it the device name as an argument?
<mvo> pitti: yeah, I think that is actually what I want
<pitti> mvo: but if it doesn't, what *does* mount the device?
<pitti> mvo: do you have some kind of udisks2 and automounter?
<mvo> pitti: it seems udev+systemd makes this a bit tricky, maybe with%I and the @ thing of systemd?
<mvo> pitti: I think snapd may need to do the mounting itself (ro mounting)
<mvo> pitti: to a temp location and all that, we do not have udisks2 in the general case :/
<pitti> mvo: yes, you can start snapd.autoimport@%k.service from the udev rule
<pitti> mvo: so how does this work right now? (aside from the sleep)
<mvo> pitti: it works only on the desktop currently, next step is to add mounting if no automounter is available
<pitti> ah
<pitti> mvo: open a new unshared mount ns and mount it there, to not confuse the host system
<mvo> pitti: I guess that is also going to be tricky because I don't want to interfere with the existing automounters
<ogra_> we have autofs ... couldnt we use systemds automounter ?
<mvo> pitti: yeah, that was my thinking
<pitti> ogra_: you can, if you pin down the mount dir
<pitti> but then you can't easily have more than one at a time
<pitti> (not sure if that's a thing)
<pitti> sorry, need to go again, bbl
<mvo> pitti: thank you! I will do the %k and %I stuff and do the mounting next, thanks for your help
<mup> PR snapd#2043 closed: store: change purchase to order and store clean up first pass <Created by pete-woods> <Merged by pete-woods> <https://github.com/snapcore/snapd/pull/2043>
<mup> PR snapd#2045 opened: many: remove all traces of the /v2/buy/methods endpoint <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2045>
<mup> PR snapd#2046 opened: cmd, disconnect: abbreviated forms of disconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/2046>
<oparoz> Is it possible to namespace snaps at install time? In order to have different versions of the same snap installed
<Mirv> is there a way to provide configflags with spaces to the autotools plugin without it breaking?
<oparoz> snap install mysnap --prefix=featureX
<Mirv> if I use different lines, that works but not when same thing needs to be repeated multiple times. on the same line the space character causes error for the configure script
<Mirv> (multiple times -> non-unique elements error)
<mup> PR snapd#2044 opened: snap: auto-import assertions from block devices <Created by mvo5> <https://github.com/snapcore/snapd/pull/2044>
<popey> when packaging an (python) app which tries to write to /etc/init.d/appname, and obviously fails during snappy, what's best practice here? Patch setup.py and install into some $SNAP.. dir and patch the app not to look in global /etc?
<mvo> ogra_: so - we think about udisks2 as part of ubuntu-core, what do you think? looks like its just 300kb
<ogra_> mvo, not thrilled about adding all that stuff lately .. :((
<ogra_> mvo, why cant you use systemd's automount ?
<mvo> pitti: so while I was working on this auto-impoter I noticed that its tricky to not get in the way of existing auto-mounting, it feels like replying on udisks2 is more reliable, do you think that is an reaonable idea? add it to ubuntu-core
<mvo> ogra_: because the names are not predicatable - or am I overlooking a way ?
<mvo> ogra_: i.e. if there is a way to say "mount any block device to /media/" from systemd that would be great
<ogra_> https://www.freedesktop.org/software/systemd/man/systemd.automount.html
<ogra_> Where=
<ogra_>     Takes an absolute path of a directory of the automount point. If the automount point does not exist at time that the automount point is installed, it is created. This string must be reflected in the unit filename. (See above.) This option is mandatory.
<ogra_> so you make a udev rule that creates the unit on plugin ... with a "Where=/media/$device-label" or some such
<ogra_> and a udev rule that removes the dir on unplug
<ogra_> super simple
<abeato> jdstrand, hi, is it possible to define an apparmor rule that allows access to path "/"? it looks like http://paste.ubuntu.com/23255279/ does not work, for instnace
<mvo> ogra_: that sounds interessting, I'm slightly concerned about when teams like morphis who use udisks2 as a snap that it does not interfere here
<ogra_> mvo, my prob with udisks is that along with the diskspace you also add another constantly running daemon
<ogra_> we slowly start to grow out of embedded (though the keyboard stuff was worse here than udisks would be ...)
<ogra_> i'm not sure if there would be any interference between automounter and udisks ... thats a pitti question ... worst case we'd need some automatism that turns off the automounter stuff dynamically
<ogra_> (we could abuse interfaces here ... if a certain interface is used, turn off the global mounting support and hand it over to the in-snap udisks)
<ogra_> (or simply tell morphis to use the system level mounting :P )
<jdstrand> abeato: yes, we do that in several places. can you show me the denial?
<abeato> jdstrand, Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.95" (uid=0 pid=5079 comm="/snap/ofono/x1/usr/bin/dbus-send --system --type=m") interface="org.ofono.Manager" member="GetModems" error name="(unset)" requested_reply="0" destination="org.ofono" (uid=0 pid=5061 comm="/snap/ofono/x1/sbin/ofonod -d ")
<jdstrand> abeato: the apparmor denial from syslog
<abeato> jdstrand, [22568.513731] audit: type=1107 audit(1475242602.796:90): pid=1198 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.ofono.Manager" member="GetModems" name=":1.103" mask="receive" pid=5061 label="snap.ofono.ofono" peer_pid=5141 peer_label="snap.ofono.dbus-send"
<abeato>                 exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?'
<jdstrand> abeato: is the interface connected?
<abeato> jdstrand, yes
<jdstrand> can you paste /var/lib/snapd/apparmor/profiles/snap.ofono.ofono ?
<abeato> jdstrand, things go through with path different from "/" , like /sss
<abeato> sure
<mvo> ogra_: I poke at it some more, maybe I find a reliable way
<abeato> jdstrand, http://paste.ubuntu.com/23255346/
<ogra_> well, i think the systemd automounter should be the way to go
 * ogra_ wonders if systemd doesnt also have a keymap selection for consoles :P
<jdstrand> abeato: can you 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ofono.ofono' and try again?
<abeato> jdstrand, same error, must be in another profile
<abeato> jdstrand, is says exe="/usr/bin/dbus-daemon" ?
<jdstrand> abeato: what do you mean 'must be in another profile'?
<jdstrand> that doesn't matter
<abeato> another apparmor file
<jdstrand> label="snap.ofono.ofono"
<jdstrand> that is the profile we need to modify ^
<jdstrand> abeato: can you paste the new denial?
<abeato> jdstrand, [23082.209137] audit: type=1107 audit(1475243116.493:101): pid=1198 uid=100 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.ofono.Manager" member="GetModems" mask="send" name="org.ofono" pid=5614 label="snap.ofono.dbus-send" peer_pid=5566 peer_label="snap.ofono.ofono"
<abeato>                 exe="/usr/bin/dbus-daemon" sauid=100 hostname=? addr=? terminal=?'
<jdstrand> that is a different denial :)
<jdstrand>  label="snap.ofono.dbus-send"
<jdstrand> so now update /var/lib/snapd/apparmor/profiles/snap.ofono.dbus-send to have:
<jdstrand> dbus (send) bus=system path=/ interface=org.ofono.* peer=(name=org.ofono, label=snap.ofono.ofono),
<jdstrand> abeato: ^
<jdstrand> abeato: then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.ofono.dbus-send
<abeato> jdstrand, aha, let me modify the connected interface
<jdstrand> abeato: it is important to remember that if you change the apparmor profile on disk, to reload it with apparmor_parser -r. it is also important to remember that we mediate both sides of the connection and to keep the label and the peer_labels straight
<jdstrand> abeato: it easy to miss something unless you're used to looking at denials
<jdstrand> it's*
<abeato> jdstrand, that did the trick, thanks a lot
<abeato> jdstrand, yep, thanks for the hints :)
<jdstrand> abeato: fyi, the two rules in http://paste.ubuntu.com/23255346/ could be combined into one: dbus (receive, send) bus=system path=/{,**} interface=org.ofono.* peer=(label=###PLUG_SECURITY_TAGS###),
<jdstrand> abeato: fyi, the two rules in http://paste.ubuntu.com/23255346/ could be combined into one: dbus (receive, send) bus=system path=/{,**} interface=org.ofono.** peer=(label=###PLUG_SECURITY_TAGS###),
<jdstrand> sorry for the double paste-- the second rule is what I think you would want
<abeato> jdstrand, sure, will do that
<jdstrand> abeato: the path=/{,**} in an alternation. the interface=org.ofono.** is for org.ofono.foo.bar. if you only have org.ofono.* then org.ofono.foo matches, but org.ofono.foo.bar doesn't
<jdstrand> abeato: perhaps the ofono api doesn't need org.ofono.**, but in case it does, there you go
<abeato> don't think it needs **, but yeah
<sil2100> Hey! I just got back to debugging my simple python3 snap again
<sil2100> The problem I have is that the script does not work because I get "exec: image-info: not found" (image-info is the script name)
<sil2100> So I went into snap run --shell for the snap and started debugging
<mup> PR snapcraft#813 closed: "snapcraft validate" and "snapcraft gated" commands <Created by ralsina> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/813>
<sil2100> And the strange thing my experiments revealed: the command-image-info.wrappercommand-image-info.wrapper only works when I change the interpreter from sh to bash (uh?)
<ogra_> are you using any bashisms ?
<sil2100> No, this is just a pure python3 script
<sil2100> The part that's failing is the wrapper which is autogenerated I guess?
<ogra_> yes, it is
<sil2100> With it having the default /bin/sh, the PATH doesn't seem to be respected by the final 'exec' call
<sil2100> No idea why
<ogra_> (and it works for all other snaps without changing to bash)
<sil2100> Yeah, it completely makes no sense to me...
<sil2100> No one had any issues like that?
<ogra_> i havent heard about any
<ogra_> though i havent seen anyone call python3 directly from the apps: entry in snapcraft.yaml either
<ogra_> which IIRC you are doing
<sil2100> I'm not calling it directly per se, I just install the main part in parts: using the python3 plugin, add the image-info app with the image-info command
<sil2100> Since my setup.py installs the python3 scripts to the right bin place
<sil2100> So in theory it should all just work: scripts are in the right /usr/bin in the snap, the PATH is set to the correct values
<ogra_> show me your snapcraft.yaml again
<sil2100> But when trying to run the snap, I get exec: image-info: not found
<sil2100> http://paste.ubuntu.com/23255543/
<sil2100> Really simple yaml right now
<ogra_> and the image-info script ?
<ogra_> (the shebang mainly)
<sil2100> Well, the image-info script is "#!/usr/bin/python3" and then the rest of the script
<ogra_> right, thats wrong
<sil2100> What is failing is the command-image-info.wrapper
<sil2100> Wrong?
<sil2100> I thought it should be the command to call?
<ogra_> make it "#! /usr/bin/env python3"
<sil2100> Oh
<sil2100> hm
<ogra_> you are forcefully calling the python3 from ubuntu-core ... not the one you ship
<sil2100> Let me try that
<mup> PR snapd#2047 opened: snap: auto mount block devices and import assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2047>
<ogra_> the one you ship is in $SNAP/usr/bin/python3 ... which your env points to
<ogra_> (through the PATH)
<ogra_> though i thought the python plugin actually re-writes the shebang lines at package build
<sil2100> ogra_: yeah, it does - but it re-wrote it to something strange
<sil2100> When I examine the /snap/landing-team-tools/x1/usr/bin/image-info script, I see the interpreter being set to "<path to my workdir>/parts/landing-team-tools/install/usr/bin/python3"
<sil2100> Doesn't look like it's correct
<ogra_> yeah
<ogra_> even after you changed the line and re-built ?
<sil2100> No, didn't try that yet
<sil2100> I'm wondering if it'll help though, as currently the exec line in the wrapper is failing
<sil2100> It's not even reaching my image-info script
<sil2100> Like, at all
<ogra_> "exec: image-info: not found" reads to me like it tries to sxec image-info ...
<ogra_> but cant exec it because something inside (the interpreter) is not found
<ogra_> else i'd expect "exec: not found"
<verterok> hi, having some issues while trying to snap an app that tries to write to SNAP_COMMON. the app is unable to write there, getting: permission denied.
 * ogra_ hugs mvo for https://github.com/snapcore/snapd/pull/2047
<mup> PR snapd#2047: snap: auto mount block devices and import assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2047>
<ogra_> beautiful :)
<mvo> ogra_: yeah, all without new stuff
<ogra_> yep :D
 * ogra_ loves it
<mvo> ogra_: I'm very happy, probably need a look from pitti but I think its good
<ogra_> yeah, looks totally fine to me
<mvo> morphis: all good, looks like we don't need udisks afterall
<mvo> morphis: sorry for the noise
<ogra_> verterok, looks like either Bug 1611063 or Bug 1610149
<mup> Bug #1611063: can't mkdir SNAP_USER_COMMON directory <snapd-interface> <Snappy:Triaged> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1611063>
<mup> Bug #1610149: writing to the "common" directory needs to have sudo right <Snappy:Invalid> <https://launchpad.net/bugs/1610149>
<ogra_> verterok, for a user app/executable you need to use SNAP_USER_COMMON  ... SNAP_COMMON would be for a daemon or some sudo executed app
<verterok> ogra_: ok. I was trying to store a file accesible from this app for any user running it, not just for this user
<verterok> ogra_: but I think I can workaround this by having a file per user
<ogra_> well, or you could create some daemon script that handles the file or so
<sil2100> ogra_: hah, ok, I upgraded snapd, ubuntu-core-launcher and snapcraft and now things work
<ogra_> hah
<sil2100> Strangeness
<sil2100> ogra_: thanks for the help nevertheless! :)
<ogra_> heh
<verterok> ogra_: thanks
<ogra_> :)
<Croepha> PRO TIP: if you want ubuntu-image to use your kernel snap locally, you have to specify it with --extra-snaps in addition to setting it in the model assertion
<ogra_> yep ... that was just discussed on the meiling list recently :)
<kyrofa> I was just about to say... that sounds familiar
<ogra_> *mailing
<Croepha> huh
<Croepha> I had to dig into the snapd source to figure it out
<ogra_> niemeyer, i got poked about hibernate on snappy images recently ... that made me think ... we kind of didnt define "swap" as a partition type for gadget.yaml, i think we should add that as optional type
<kyrofa> Croepha, no! Don't look directly at it!
<Croepha> my snapd is riddled with fmt.Printfs now
<kyrofa> Hahaha
<ogra_> niemeyer, we'll indeed never used it on SD images ... but i can immagine there are plenty use-cases where people want/need it
<ogra_> *use it
<Croepha> it took me a solid 20 minutes to figure out that ubuntu-image doesn't actually do anything, and it just passes most work off to snapd
<Croepha> I
<morphis_> pitti: ping
<morphis_> cyphermox: maybe you can help too
<morphis_> pitti, cyphermox: is it correct that netplan does not restart networkd/network-manager when the last netplan configuration file was removed and this causes the current configuration not to be disabled and still being active until the next device reboot?
<oparoz> Is the apparmor issue with ld.so.preload is only created by Launchpad?
<kyrofa> oparoz, ask jdstrand
<ogra_> lool, is there any reason that snapweb is constanly running instead of using socket activation ? it eats from 10MB reserved memory (pi2) to 30MB (dragonboard) just for idling
<kyrofa> ogra_, does snapd support socket activation?
<ogra_> i guess we dont actually need it running all the time, do we ?
<ogra_> kyrofa, well, systemd does ... should only be a matter of writing the unit differently
<ogra_> having suchh processes run all the time on an IoT device seems very wasteful
<kyrofa> ogra_, sure, I'm just saying that I think that might be the reason :P
<ogra_> ah
<ogra_> k
 * ogra_ has a hard time resisting to suggest to use a three char suffix at https://github.com/snapcore/snapd/pull/2047 
<mup> PR snapd#2047: snap: auto mount block devices and import assertions <Created by mvo5> <https://github.com/snapcore/snapd/pull/2047>
<jdstrand> oparoz: I don't understand the question. if you are talking about https://bugs.launchpad.net/snappy/+bug/1627813, I need to prepare an update for that
<mup> Bug #1627813: AppArmor denies access to /etc/ld.so.preload on armhf <Snappy:Triaged by jdstrand> <https://launchpad.net/bugs/1627813>
<jdstrand> s/update/PR/
<oparoz> Thanks jdstrand. It seems to only happen with Snaps built from Launchpad, but maybe I'm wrong and that bug appeared in a snapd update pushed this week
<mup> PR snapd#2048 opened: interfaces: allow read of /etc/ld.so.preload by default for armhf on series 16 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2048>
<jdstrand> oparoz: fyi ^
<oparoz> Thanks jdstrand can this be patched live?
<jdstrand> oparoz: yes. add '/etc/ld.so.preload r,' to /var/lib/snapd/apparmor/profiles/snap.your.app, then run 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.your.app
<jdstrand> oparoz: you'll have to do that after refresh, install, install/remove, etc
<oparoz> Thanks jdstrand that will at least tell me if the other error messages I get related to Go6 are related or not :)
<oparoz> jdstrand, tht didn't work: AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.spreedme in /var/lib/snapd/apparmor/profiles/snap.spreedme at line 1: syntax error, unexpected TOK_MODE, expecting TOK_OPEN
<jdstrand> oparoz: can you paste the file in paste.ubuntu.com?
<oparoz> jdstrand, the file contains a single line: /etc/ld.so.preload r,
<oparoz> jdstrand, my bad... I overwritten it
<jdstrand> oparoz: did you delete everything out of that file or create a new one?
<jdstrand> oparoz: you can uninstall the snap then install it (back up your data if it is important)
<oparoz> jdstrand, looking at the profiles, I got it wrong. It needs to be installed for every single service and I had used the snap name
<jdstrand> oparoz: yes, sorry if I wasn't clear. that is what I meant with snap.your.app
<oparoz> jdstrand, that doesn't change anything unfortunately: https://paste.ubuntu.com/23255934/
<Croepha> so, is the current paradigm to have grub mount the kernel snap and load the kernel that way?
<Croepha> looks to be that way
<Croepha> thats pretty clever
<Croepha> lol, ive got the craziest nesting doll of loopback mounts going on right now, ive got a .img mounted, and I have a kernel snap mounted form inside it, then the initrd inside of it
<mup> PR snapd#2048 closed: interfaces: allow read of /etc/ld.so.preload by default for armhf on series 16 <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2048>
<zyga> jdstrand: was this breaking arm snaps?
<jdstrand> zyga: it was as the reporter said, 'spamming the logs'
<jdstrand> I don't think it would cause them to break outright
<jdstrand> but I guess it is possible
<zyga> jdstrand: I recall someone asking about snaps breaking on arm
<zyga> jdstrand: with some cryptic message about v6
<jdstrand> could be this. could be the 4.8 kernel
<jdstrand> zyga: oh that was different
<jdstrand> we fixed that a while ago
<zyga> jdstrand: was that auxv?
<jdstrand> that was the 'unsafe' rules
<jdstrand> yeah
<zyga> ah
<zyga> so, i spent part of the day away from home, I managed to make spread testing of snap-confine work offline
<jdstrand> oh neat :)
<zyga> I need to automate creation of the offline setup (one file left) but it should be ok
<zyga> jdstrand: I'll get to making all the small branches for everything today and tomorrow
<jdstrand> a cool next addition to spread would be running snapd in local lxd
<jdstrand> I might take a look at that at some point if others don't
<zyga> jdstrand: oh, after some of my experiments I love qemu
<zyga> jdstrand: I heard that we can now have nested apparmor, lxd just might be a target now
<zyga> jdstrand: but still, offline apt, offline snap, that's useful regardless of where that works
<jdstrand> I <3 qemu (with livirt especially)
<jdstrand> yes, if you have amd64 you should be able to do nested qemu
<mup> PR snapd#2049 opened: Allow writing DHCP lease files to /run/NetworkManager/dhcp <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2049>
<jdstrand> I mention lxd cause running the snapd and snap-confine testsuites inside of lxd shipped as a snap would be handy for local tests but also really exercise the apparmor stacking feature
<jdstrand> and be a great regression test
<zyga> hmm, I didn't think about the stacking case, that is a good point
<jdstrand> it's exciting-- all the pieces are in flight fr 16.10
<jdstrand> and once there, the SRUs will begin
<jdstrand> that is some very cutting edge stuff
<jdstrand> and it'll be great for the lxd project and snappy
<zyga> jdstrand: any chance this is all also upstream in relevant places?
<zyga> btw, the complexity of lxd running as a snap on lxd running as a snap is mind boggling
<zyga> what's the kernel mount namespace layout again?
<mup> PR snapd#2050 opened: interfaces/policy: start of interface policy checking code based on declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/2050>
<jdstrand> zyga: everywhere except the kernel. the kernel bits are still work in progross
<zyga> do you need kernel devs? :-)
<jdstrand> zyga: well, that is deep nesting and won't be supported just yet (it's planned). lxd as a snap running snapd is supported
<jdstrand> zyga: well, the kernel devs that were working on the upstreaming got put on the stacking feature
<jdstrand> zyga: tyhicks can comment on the progress and next steps
<jdstrand> tyhicks: context: stacking support and upstreaming
<oparoz_> jdstrand, that bug is killing snaps on armhf
<jdstrand> oparoz_: ack (zyga ^)
<oparoz_> It's impossible to install anything. Services all crash
<zyga> I was joking :) maybe I can re-brand myself as a junior kernel developer
<jdstrand> oparoz_: it's committed now
<oparoz_> Yeah, I saw, thanks :). I can't test if it works because app-confine doesn't seem to have a customizable apparmor profile
<tyhicks> zyga, jdstrand: the kernel changes needed for stacking are not upstream
<tyhicks> zyga, jdstrand: now that stacking is just about finished, upstreaming can commence after the bits of work left for gsettings mediation
<zyga> oparoz_: snap-confine has a profile that you can change (well, perhaps not in a presistent way but still)
<oparoz_> zyga where?
<oparoz_> Noting in the apparmor folder
<oparoz_> Couldn't find doc about it
<mup> PR snapd#2035 closed: asserts: support parsing the slots stanza i.e. slot rules in snap-declarations <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2035>
<zyga> oparoz_: anywhere, you can just load the profile
<zyga> oparoz_: look at /etc/apparmor.d/usr.lib.snapd.snap-confine
<zyga> oparoz_: you can copy/edit that anywhere
<zyga> oparoz_: and load the new version with apparmor_parser -r
<mup> PR snapd#2042 closed: daemon: add users to the sysInfo data <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2042>
<oparoz_> zyga, thanks, that eliminated that one error :) Still one left, but I don't know if it's related to the same problem
<oparoz_> zyga,
<oparoz_> Sep 30 18:21:40 ubuntu-standard snap[22880]: ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.
<oparoz_> Another file to whitelist?
<zyga> oparoz_: looks like something that jdstrand just fixed
<jdstrand> oparoz_: /usr/lib/arm-linux-gnueabihf/libarmmem.so probably doesn't exist in the core snap
<jdstrand> maybe it does. do you have apparmor denials?
<oparoz_> 20 -rw-r--r-- 1 root root 18920 Jul  8  2015 /usr/lib/arm-linux-gnueabihf/libarmmem.so
<oparoz_> No denials, just ERROR
<zyga> oparoz_: does it work in devmode?
<oparoz_> I've added it to both policies and it doesn't fix things
<jdstrand> oparoz_: what are you adding to snap-confine's policy?
<oparoz_> jdstrand, I added /etc/ld.so.preload r,
<oparoz_> and then /usr/lib/arm-linux-gnueabihf/libarmmem.so r,
<jdstrand> oparoz_: did you have denials for those?
<oparoz_> I thoght the 2nd error about libarmmem.so was relatedto the apparmor error from the previous line
<oparoz_> jdstrand, but apparently it's unrelated
<jdstrand> oparoz_: you'll see a new denial for that file if it is blocked by apparmor
<oparoz_> jdstrand, so probably not related to that
<oparoz_> zyga, doesn't load in devmode either
<oparoz_> So the logs still look like that: https://paste.ubuntu.com/23255934/
<oparoz_> Minus the apparmor error
<jdstrand> oparoz_: are you using an up to date image? (core and kernel in particular)
<oparoz_> snap refresh says so
<zyga> oparoz_: did you reload the profile?
<oparoz_> ubuntu-core     16.04.1         424  canonical  -
<jdstrand> oparoz_: cat you paste /etc/apparmor.d/usr.lib.snapd.snap-confine ?
<mup> PR snapd#1918 closed: tests: add external spread backend <Reviewed> <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/1918>
<oparoz_> jdstrand, https://paste.ubuntu.com/23256723/
<jdstrand> oparoz_: that is too old
<oparoz_> jdstrand, neither apt, nor snap are giving me anything newer
<jdstrand> oparoz_: I suggest using 'snap refresh ubuntu-core --channel=edge'
<jdstrand> I don't upload the core snaps so I don't know why you a newer stable version of the armhf core snap is not available
<jdstrand> but getting the edge core snap should resolve this
<mup> PR snapd#2045 closed: many: remove all traces of the /v2/buy/methods endpoint <Created by pete-woods> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2045>
<oparoz_> Thanks jdstrand I'm downloading now and will keep you posted
<oparoz_> jdstrand, It seems it's stuck, error: cannot refresh "ubuntu-core": snap "ubuntu-core" has changes in progress
<oparoz_> jdstrand, any way to restart?
<jdstrand> I'm not sure how to get you out of that situation. perhaps there was something wrong with it which is why it wasn't refreshing
<jdstrand> perhaps someone here can help?
<oparoz_> jdstrand, It started and I killed it and now I can't refresh...
<jdstrand> yeah, I don't know how to fix that. I think it will try again in some minutes behind the scenes
<oparoz_> OK :)
<jdstrand> your image is definitely too old and perhaps it isn't able to update. just a guess
<oparoz_> abort seemed to have solved it
<oparoz_> But I can't connect and retrieve the snap. Connection reset by peer. Weird
<Croepha> whats the service that setups networking interactively on core? how do you disable/override it?
<zyga> oparoz_: killing snapd wont change anything
<zyga> oparoz_: start with snap changes
<oparoz_> I did that and it gave me a list of errors and I used the ids
<oparoz_> It complained that there was nothing to do and then it worked
<zyga> oparoz_: you can abort changes
<oparoz_> error: cannot abort change 78 with nothing pending
<Croepha> the answer to my questions was apparently console-conf
<oparoz_> 78   Error   2016-09-30T18:40:05Z  2016-09-30T18:45:10Z  Refresh "ubuntu-core" snap from "edge" channel
<oparoz_> And this one is stuck in abort: 91   Abort   2016-09-30T18:54:26Z  -                     Refresh "ubuntu-core" snap from "edge" channel
<mup> PR snapcraft#842 closed: Catkin plugin: Support ROS Kinetic <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/842>
<kyrofa> oparoz_, more info here on what happened there: http://askubuntu.com/a/790975/261753
<oparoz_> Thanks kyrofa :)
<mup> Bug #1629423 opened: Ordering of command line arguments matters <Snappy:New> <https://launchpad.net/bugs/1629423>
<oparoz_> Rebooted and network is still flaky as hell. Impossible to download anything anymore :S
<oparoz_> What I find amazing is that older snaps still load, it's just newer ones which can't
<mup> Bug #1629425 opened: Cannot safely refresh from edge to stable with ubuntu-core <Snappy:New> <https://launchpad.net/bugs/1629425>
<oparoz_> Is there a way to download ubuntu-core edge via wget? Snapd just can't handle network connections anymore
<kyrofa> attente, ping
<attente> kyrofa: hey
<kyrofa> attente, hey, I just had a bug logged against nextcloud saying that the description within the software center is terribly unclear. They provided this screenshot: https://cloud.githubusercontent.com/assets/9272078/19003640/131490a4-8752-11e6-80f0-2d811abcf244.png
<kyrofa> attente, there more data in the store though. Does the software center not have access to that?
<kyrofa> attente, it also looks like it's grabbing the name out of the YAML or something instead of what's in the store
<attente> kyrofa: hmm... i can't even seem to find that snap via gnome-software
<kyrofa> attente, I guess specificaly I'm missing the summary
<kyrofa> attente, huh, yeah, I don't either. What's happening here?
<attente> kyrofa: can you kill gnome-software and re-run it with GNOME_SOFTWARE_SNAPPY=debug in the env?
<kyrofa> attente, huh, lots of 404s
<attente> kyrofa: yeah, that's what i'm seeing too
<kyrofa> Temporary store failure?
<attente> kyrofa: fwiw, this is from the find endpoint: http://paste.debian.net/848827/
<kyrofa> attente, huh, okay. Really just adding the summary in there would make me happy
<kyrofa> attente, is there a reason we're not showing it?
<Croepha> HAHA!
<attente> kyrofa: the extra missing data is coming from /v2/snaps/nextcloud usually? and since it's 404'ing that's why the information is so sparse?
<slangasek> ogra_: hey, so, are you planning to grab any timing of a full console-conf startup on BBB? (+strace)
<Croepha> PRO TIP #2: if you want the first-boot helper to go away in core, just touch /var/lib/console-conf/complete
<kyrofa> attente, no, the summary is in the response to the query you just pasted
<attente> kyrofa: but you said that the store is showing more information in the store
<attente> kyrofa: so i'm wondering if that's because gnome-software is getting a 404 there
<kyrofa> attente, I meant to simply say that there is information available that isn't shown in gnome-software
<kyrofa> Well, that's just not making it show up at all! Haha
<kyrofa> It must have been working a few minutes ago when the bug was logged
<kyrofa> (that screenshot was from the bug, not me personally)
<kyrofa> attente, compare the screenshot to this: http://pasteboard.co/9qPYYft9h.png
<attente> weird. is a server down or something?
<kyrofa> There it has a summary above the install, and the longer description below
<kyrofa> Good question. oparoz_ was just complaining about network issues
<kyrofa> I'm installing nextcloud... that seems to be working anyway
<oparoz_> I can't download anything via snap on armhf, works on amd64
<oparoz_> Same network, but different cable ;)
<mup> PR snapd#2049 closed: interfaces: builtin: Allow writing DHCP lease files to /run/NetworkManager/dhcp <Created by ssweeny> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2049>
<oparoz_> https://uappexplorer.com still shows decriptions, so must not be an API thing
<elopio> kyrofa: well, it starts now alright: https://gist.github.com/elopio/dffcda326f5b51feedeb09f012ac9a44
<elopio> it fails when trying to create a user though
<attente> kyrofa: ok, i see. so you'd prefer the summary go in the top line, and description to be the blurb below
<kyrofa> attente, well, the summary isn't shown at all, right? Wouldn't that be more consistent?
<attente> in the second image, there are three items, name, summary and description, but from the bug report, we show the name and description (which is displayed where the summary would ideally be)
<kyrofa> Indeed
<attente> ok, that should be a simple fix
<attente> still not sure about the 404s though :/
<kyrofa> attente, yeah me neither. But yeah, do you think that makes sense?
<attente> kyrofa: yup, makes sense to me
<oparoz_> Is the API serving snaps documented somewhere?
<attente> kyrofa: i'm not sure what to do about the jhbuild plugin stuff. do you think it's still worth looking into even though you're planning to make all plugins build in a container
<kyrofa> attente, I'm honestly not sure. I just got back onto snapcraft yesterday, still getting up to speed. Probably a better question for sergiusens
<kyrofa> oparoz_, nessita can probably help you with that. I think it's on the wiki somewhere
<oparoz_> Thanks kyrofa I'm trying to find a link I saw about creating our own app store as that may have some info
<kyrofa> attente, shall I log a bug about the summary?
<attente> kyrofa: sure
<kyrofa> attente, here? https://bugs.launchpad.net/ubuntu/+source/gnome-software
<attente> kyrofa: yup
<kyrofa> attente, bug #1629456
<mup> Bug #1629456: Summary isn't shown for snaps <gnome-software (Ubuntu):New> <https://launchpad.net/bugs/1629456>
<attente> kyrofa: thanks!
<nessita> kyrofa, hi! what do you need?
<kyrofa> nessita, where is the store API documented nowadays? oparoz_ was asking
<oparoz_> Found this: https://wiki.ubuntu.com/AppStore/Interfaces/ClickPackageIndex
<nessita> oparoz_, hi! that documentation is for the click endpoints only, is not updated to snaps
<nessita> oparoz_, what's your goal?
<oparoz_> Ah :(
<oparoz_> I want to download armhf package from an amd64 machine
<nessita> oparoz_, we don't officially provide public APIs to query the store, ideally you should use snapd to do searches and downloads
<oparoz_> There is no arch switch in snappy
<oparoz_> snapd doesn't work
<oparoz_> I only get this: error: read tcp 1.2.3.4:60014->95.172.71.39:443: read: connection reset by peer
<zyga> oparoz_: you can use snapd-glib to query snapd
<lutostag> hey all, when I try to push a snap I get "There has been a problem while analyzing the snap, check the snap and try to push again."... how can I find out what I am doing wrong?
<zyga> jdstrand: can I get a +1 on https://github.com/snapcore/snap-confine/pull/158
<mup> PR snap-confine#158: Constrain SNAP_CONFINE_DEBUG values <Created by zyga> <https://github.com/snapcore/snap-confine/pull/158>
<oparoz_> Thanks zyga, that's interesting
<zyga> jdstrand: and perhaps https://github.com/snapcore/snap-confine/pull/157
<mup> PR snap-confine#157: Add support for --version switch <Created by zyga> <https://github.com/snapcore/snap-confine/pull/157>
<jdstrand> zyga: I feel like I looked at this alreayd
<zyga> jdstrand: oh? I don't see any comments there
<jdstrand> no there aren't any
<jdstrand> maybe I started looking at it
<jdstrand> I'm looking at something else right now and have a hard stop soon
<zyga> jdstrand: I wrote a small spread test for the "prefer core" https://github.com/snapcore/snap-confine/pull/161/commits/3e4d839da5efb8e34b5a72a45445abd404d8a627
<mup> PR snap-confine#161: Prefer the "core" snap is one is available <Created by zyga> <https://github.com/snapcore/snap-confine/pull/161>
<zyga> jdstrand: ok, ignore those two
<jdstrand> I've added it to me todo
<zyga> hmm, me is silly
<jdstrand> jeez, I thought I looked at --verson too
<jdstrand> meh
<zyga> jdstrand: I'm doing a micro release with the core preference feature
<mup> PR snapcraft#843 closed: Add `snapcraft history` and `snapcraft status` <Created by maxiberta> <Closed by maxiberta> <https://github.com/snapcore/snapcraft/pull/843>
<mup> PR snapcraft#844 opened: Add `snapcraft history` <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/844>
<mup> PR snapcraft#845 opened: Add `snapcraft status` <Created by maxiberta> <https://github.com/snapcore/snapcraft/pull/845>
<lutostag> (figured it out, someone else had registered the name I tried to push to, but got it sorted)
<mup> PR snapcraft#841 closed: Replace SNAPCRAFT_PART_INSTALL in the part attributes <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/841>
<oparoz_> jdstrand, usr.lib.snapd.snap-confine is not updated when installing ubuntu-core edge and so nothing changes
<jdstrand> zyga: I gave a comment on 161 you may want to consider
<jdstrand> oparoz_: I am about to head out. does usr.lib.snapd.snap-confine contain 'unsafe' in the change_profile rules?
<zyga> jdstrand: looking
<oparoz_> jdstrand, no
<jdstrand> oparoz_: I suspect that /snap/ubuntu-core/current points to the old one
<jdstrand> oparoz_: I don't know how convenient it is for you, but you may want to reflash. perhaps others can help debug this
<oparoz_> jdstrand, it points to the dev version I just sideloaded
<jdstrand> oparoz_: what does snap list say?
<zyga> jdstrand: replied
<jdstrand> maybe the armhf core snap is out of date
<oparoz_> jdstrand, ubuntu-core     16.04.1         x1              -
<oparoz_> This is a Nextcloud Box image
<oparoz_> Which only had snapcraft installed on to try and build simpler snaps
<oparoz_> It used to work find until the preload bug and now all dnaps fail
<oparoz_> with that lib error
<oparoz_> snap-confine/xenial-updates,now 1.0.38-0ubuntu0.16.04.10 armhf
<oparoz_> snapd/xenial-updates,now 2.15.2ubuntu1 armhf
<oparoz_> I just hope it's recoverable, because lots of users won't be tech savvy
<jdstrand> oparoz_: oh, 16.04 still has 1.0.38-0ubuntu0.16.04.10. that doesn't have the necessary changes
<jdstrand> :(
<oparoz_> OK, at least now I know why :)
<jdstrand> oparoz_: I know zyga was working on landing that. I'm not sure of the status
<zyga> oparoz_: there's a good version in yakkety, xenial will get the SRU but I need to verify a dozen bugs for that and I'm also doing other things
<zyga> oparoz_: ~ next week
<oparoz_> OK, I'll just be patient and wait for updates to land
<oparoz_> Thank you guys
<sbeattie> How does one get snapcraft to include datadirs in a snap? the autotools plugin installed them into stage/SNAP/installdata, but I can't figure out how to get the stuff under there included in the snap.
<sbeattie> If I try to use the "stage" part (from http://snapcraft.io/docs/build-snaps/parts) , it looks under stage/SNAP/install/
<zyga> jdstrand: my browser froze and I think I just accidentally somehow removed your commend about /media and udisks
<zyga> jdstrand: my point on this is, perhaps, but it would make devmode vs non-devmode different
<zyga> in somewhat weird ways
<oparoz_> zyga, just to confirm that that yaketi package fixes the problem. The error about the lib is still there but it seems it was a red herring
<zyga> (well, to phrase this better, right now all you need is devmode and then you can "be udisks"
<zyga> oh the comment is back, odd
<zyga> oparoz_: intersting
<zyga> oparoz_: I'm away from home and my fleet of arm devices
<zyga> oparoz_: I will be able to look at this in early november
<oparoz_> zyga, OK. Hopefully fixed by Ubucon EU
<zyga> oparoz_: I'm sure we'll get someone with a device to debug it
<oparoz_> :)
<Innokentiy> Hello! Have some questions about using snappy for packaging an application ... Unfortunately can't find answers in tutorial and FAQ
<zyga> Innokentiy: ask away
<Innokentiy> Tnx!
<Innokentiy> I use odroid and beaglebone for about 4 years now, and recently found that Ubuntu core may be an answer to a question what Linux distribution is  the best for the IoT, so the question is: :)
<Innokentiy> naturally it is a set of php scripts ... not a real application ...
<kyrofa> Innokentiy, no matter, you can run PHP scripts. Is it not a web application, though?
<sergiusens> attente kyrofa can we take the jhbuild plugin to the sprint?
<zyga> Innokentiy: this is not a question yet
<kyrofa> sergiusens, sounds good to me
<attente> sergiusens: sure
<sbeattie> sorry, I mis-asked. the snapcraft autotools plugin is installing my snap's data into parts/SNAP/installdata rather than parts/SNAP/install (where it correctly installs the bins). How do I get snapcraft to look at the parts/SNAP/installdata dirs as well?
<Innokentiy> Something went wrong, looks like messages gone nowhere ...
<Innokentiy> So i continue ...
<zyga> Innokentiy: try again :)
<Innokentiy> Tnx zyga :)
<Innokentiy> my project is a set of php scrips, so i have one fundamental question ...
<Innokentiy> Normally, i place all folder structure to /var/www/mpsbox
<Innokentiy> and then point apache to use this folder as virtual directory
<Innokentiy> or main site folder ...
<zyga> right, here you'd want to bundle PHP and use apache (or anything else that runs php apps)
<zyga> your snap will be installed in a directory that is variable at runtime
<zyga> but you can find it because it is in environment under the $SNAP name
<Innokentiy> what should i do when i want to install with snappy?
<mup> PR snapd#2037 closed: asserts,interfaces/builtin,overlord/assertstate: introduce base-declaration <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2037>
<zyga> e.g. typically /that would be /snap/yoursnapname/123/
<Innokentiy> right
<zyga> start with a snap (use snapcraft) that can bundle apache2
<Innokentiy> and then i will pint apache to this folder
<zyga> you will need the "network-bind" plug for the application that runs apache
<zyga> the script you start can alter apache config to point it to the right place
<zyga> note that you will have to fiddle with apache first
<zyga> to make it relocatable (might be trivial, might be hard, not sure)
<zyga> then adding PHP
<zyga> then adding your app
<zyga> I think it should be doable but I'm not a php expert
<Innokentiy> thanks, and how i can define dependances?
<zyga> (where anything is doable, I mean easily)
<zyga> Innokentiy: you want to read about how snapcraft works
<Innokentiy> i need apache snmp mysql and php ...
<zyga> Innokentiy: there are no dependencies among snaps but you can easily bundle lots of things into one snap
<zyga> oh, mysql might be another thing you will neee extra time on
<zyga> I would recommend asking on the mainling list, this seems like something a lot of people can reuse
<Innokentiy> that what i missed out ... i went through tutorial
<kyrofa> Innokentiy, the nextcloud snap uses apache mysql and php as well, might be useful for reference: https://github.com/nextcloud/nextcloud-snap
<Innokentiy> but didn't get how to manage those things :(
<sbeattie> Also, is there a way to clean just a specific stage of the snapcraft process? I don't want to redo the entire build if I can avoid it.
<kyrofa> sbeattie, you can `snapcraft clean <part name>` and `snapcraft clean --step=<step>`. You can combine those, too: `snapcraft clean <part name> --step=<step>`
<Innokentiy> Thanks kyrofa will check it ...
<zyga> Innokentiy: in the end your snap will bundle apache, mysql, php and anything else you need
<Innokentiy> zyga - yes that the point, ultimately i just want to automate the installation i do now manually ...
<zyga> Innokentiy: in the end the snap will be totally self-contained
<zyga> Innokentiy: and you will have total control over versions of each bit inside
<sbeattie> kyrofa: thanks. do you have any idea how I can get snapcraft to include the files the autotools plugin installed in parts/SNAP/installdata along with the bins it installed in parts/SNAP/install ?
<Innokentiy> I really confident on make my stuff bundled as snap, as today, i getting questions mainly how to set everything up :)
<kyrofa> sbeattie, can I see your YAML?
<Innokentiy> on a device like odroid or beagle or raspberry  :)
<sbeattie> kyrofa: it's pretty dirt simple: http://paste.ubuntu.com/23257449/
<Innokentiy> kyrofa - why you decide to compile everything in snap, and not use packages available in ubuntu?
<sbeattie> I tried adding a 'source' section to part, but snapcraft looked under parts/SNAP/install/
<kyrofa> Innokentiy, this series of blog posts might be a good read, and will answer questions like that: https://kyrofa.com/posts/installing-nextcloud-can-be-a-snap
<kyrofa> sbeattie, I'm not sure what's going on there, but I suspect the way your project is handling DESTDIR is odd
<kyrofa> sbeattie, try adding `install-via: prefix` to your autotools part
<sbeattie> kyrofa: this is how it ended up installing things: http://paste.ubuntu.com/23257470/
<sbeattie> kyrofa: I'll give that a go.
<kyrofa> sbeattie, yeah it might be using ${DESTDIR}data or something dumb like that
<Innokentiy> kyrofa: Thanks! Already dive in to reading :)
<CoderEurope> o/
<CoderEurope> bbl
<mup> PR snapcraft#846 opened: Release changelog for 2.19 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/846>
<Innokentiy> Guys, thanks for help!
<ogra_> slangasek, i'll dig on the weekend
<ogra_> slangasek, thats not bbb specific ... pi2/3 also take very long
<tsimonq2>  /or
<tsimonq2> whoops
<slangasek> ogra_: ok. and they still do, after the bytecompile fix?
<ogra_> yep
<slangasek> ogra_: ok. I don't think I have any of those devices here, so strace welcome
<ogra_> slangasek, well, was there another fix ? you mentioned subiquity would be missing its .pyc files too
<slangasek> subiquity's should be insignificant, but maybe a full strace will tell us something more
<ogra_> yeah, michael also asked for setting some SNAPD_HTTP_* debug var ...
<ogra_> (i have to dig that up ... not at 1am though :) )
#snappy 2016-10-01
<mup> PR snapd#2051 opened: many: setup snapd macaroon for local users <Created by matiasb> <https://github.com/snapcore/snapd/pull/2051>
<CoderEurope> Hi OerHeks, hows holland ?
<pitti> morphis_: not restart on removing the last file> yes, that sounds correct
<mup> PR snapd#2039 closed: overlord/configstate: support nested configuration <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2039>
<mup> PR snapd#2052 opened: many: introduce snap refresh --ignore-validation <snap> to override refresh validation <Created by pedronis> <https://github.com/snapcore/snapd/pull/2052>
#snappy 2016-10-02
<stgraber> zyga, jdstrand: any ETA for the new snap-confine to hit xenial? It's the only blocker for the early version of the LXD snap. (https://myapps.developer.ubuntu.com/site_media/appmedia/2016/10/lxd-snap.jpg is what I get with yakkety's snap-confine on xenial)
<CoderEurope> Morning. Canh't be bothered going to get my hot coco from the coffee shop, today ...
<mup> PR snapd#2050 closed: interfaces/policy: start of interface policy checking code based on declarations <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2050>
<mup> PR snapd#2040 closed: daemon: add support for `snap create-user --known` <Critical> <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2040>
<mup> PR snapd#2053 opened: interfaces/policy: implement snap-id/publisher-id checks <Created by pedronis> <https://github.com/snapcore/snapd/pull/2053>
<mup> PR snapd#2054 opened: client,daemon,cmd/snap: improve create-user APIs <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2054>
<mup> PR snapd#2055 opened: interfaces/policy,overlord: check connection requests against the declaration in ifacestate <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2055>
<mup> PR snapd#2052 closed: many: introduce snap refresh --ignore-validation <snap> to override refresh validation <Critical> <Created by pedronis> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2052>
<zyga> stgraber: most likely this week, we need someone to go through and verify all the bugs
<Son_Goku> zyga: do you plan to update your snapd package in review?
<Son_Goku> and snap-confine, should I go ahead and update it to the latest release?
<Son_Goku> upstream-release-monitoring (release-monitoring.org) noticed there are new releases and has filed bugs against it requesting updates
<mwhudson> niemeyer: hi, i hope you're in bed by now :)
<niemeyer> mwhudson: I'm hoping to stop for a short while before that.. :)
<mwhudson> niemeyer: oh right, it's not actually that late for you yet. just sunday :)
<niemeyer> mwhudson: Yeah
<niemeyer> mwhudson: Anything I can help with?
<mwhudson> niemeyer: anyway, just wanted to say that console-conf doesn't use that ssh_key_count thing, so no problem there
<niemeyer> mwhudson: Ah, sweet, so the clean up should be safe
<mwhudson> i should make changes to show the fingerprints of the keys that were added but that's not a mad-rush thing
<mwhudson> niemeyer: is there anything i can do to help?
<mwhudson> i guess i can test the unattended user creation flow, at least
<niemeyer> mwhudson: I'm not aware of any urgent fixes.. our plan is to be golden by tomorrow
<niemeyer> mwhudson: So there might be something showing up still
<niemeyer> mwhudson: mvo worked a lot today, but plans to be mostly off tomorrow.. so the actual image cooking might happen on Tuesday
<niemeyer> mwhudson: If you can be a bit "on call" over the next couple of days, that'd be appreciated
<mwhudson> during work hours that's no problem at all
<mwhudson> i'll try to look in this evening too, tomorrow night is out though
<niemeyer> mwhudson: We need to have the final image in place by Wednesday, no further delays.. so we'll be stressing it a little in the upcoming days
<mwhudson> yeah
#snappy 2017-09-25
<zyga-ubuntu> o/
<sSs_> hi
<sSs_> is here the best place to ask about build.snapcraft.io?
<zyga-ubuntu> sSs_: hey
<zyga-ubuntu> sSs_: I think you should ask at forum.snapcraft.io
<zyga-ubuntu> :)
<sSs_> thanks!
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: are you at the rally?
<popey> zyga-ubuntu: he is
<mup> PR snapd#3958 opened: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
 * mwhudson waves at zyga-ubuntu
<mwhudson> sadly
<zyga-ubuntu> mwhudson: hey
<zyga-ubuntu> :-(
<zyga-ubuntu> yeah
<zyga-ubuntu> popey: say hi to him :)
<__chip__> o/
<mup> Bug #1681547 changed: Gnome3 on Ubuntu 17.04 doesn't find snap desktop files <wayland> <Snappy:Fix Released> <https://launchpad.net/bugs/1681547>
<ogra_> zyga-ubuntu, you just need http://bit.ly/2yDzMdg
<mwhudson> can someone point me to the seeding code?
<smallfoot-> Can you guys make a template for GNOME Builder that includes files to build a snap?
<zyga-ubuntu> ogra_: hehe
<zyga-ubuntu> ogra_: and someone to drive me around :)
<zyga-ubuntu> smallfoot-: that's an interesting idea
<mwhudson> also is there some way to make seeding extremely verbose?
<ogra_> zyga-ubuntu, well, thats old ... nowadays you'd have a flying drone driven by ubuntu core ;)
<zyga-ubuntu> smallfoot-: can you please post this proposal to forum.snapcraft.io so that it doesn't get lost?
<zyga-ubuntu> ogra_: wait, there's a core refresh
<zyga-ubuntu> xxxxx
<ogra_> lol
<zyga-ubuntu> ogra_: I see my dragonboard power usage spike whenever it reboots on core rebuild
<ogra_> rebuild ? you mean refresh ?
<zyga-ubuntu> well, rebuild that triggers refresh
<zyga-ubuntu> yes
<ogra_> all our default kernels boot with the performance cpufreq governor (to speed up booting) and use a script to switch to ondemand 60sec after the boot
<ogra_> theoretically you shoulld see such a spike on every boot ... not typically related to the refresh itself
<zyga-ubuntu> right, but it doesn't reboot otherwise :)
<zyga-ubuntu> it runs 24/7
<ogra_> yeah
<zyga-ubuntu> ogra_: btw, did you see my lab?
<ogra_> but it is just a coincidence
<ogra_> i saw the pics from a while ago
<ogra_> are there new ones ?
<smallfoot-> zyga-ubuntu, I don't have any forum account on snapcraft.io
<zyga-ubuntu> no, nothing new. I plan to add 4 more boards but I have no time to set them up
<zyga-ubuntu> I need a small rack to keep this tidy
<ogra_> well, now that you are idling at home and everyone esle is in NYC you should have some time ;)
<zyga-ubuntu> ogra_: I'm not at home today
<zyga-ubuntu> ogra_: but I can ssh home :)
<ogra_> heh
<zyga-ubuntu> ogra_: I mainly don't have a rack
<zyga-ubuntu> ogra_: I had some errands to do in the morning, taxes and VAT paperwork
<ogra_> home is where the authorized_keys is !
<zyga-ubuntu> ogra_: hahaha :)
<zyga-ubuntu> yeah
<ogra_> i would love to give you my 2x1x1m server cabinet ... but i guess delivery would be really expensive
<ogra_> (trying to get rid of it since ages)
<zyga-ubuntu> hmmm
<zyga-ubuntu> how heavy is it?
<zyga-ubuntu> I have space for that
<zyga-ubuntu> but I'd rather have small desk rack as I have separate office network and no wiring to where I could keep the rack
<zyga-ubuntu> (the big rack)
<ogra_> its a big metal cabinet with glass front and back doors probably somewhere between 50-100kg
<zyga-ubuntu> nice, why do you want to let go of it?
<ogra_> because even 20 of the boards i work with nowadays fit on a shelf ...
<ogra_> it just takes space, i dont really have any big 19" server HW in use anymore
<mwhudson> pedronis: are you looking at irc? :)
<zyga-ubuntu> ogra_: can you send me a pic sometime (telegram is fine)
<ogra_> yeah, remind me next week when i'm home
<zyga-ubuntu> thank you!
<smallfoot-> Why does 'snapcraft init' put the yaml file in snap/ instead of build-aux/snap/ ?
<smallfoot-> Now it pollutes the root, instead of be like build-aux/snap/ and build-aux/meson/
<mup> PR snapd#3957 closed: cmd,dirs: treat "liri" the same way as "arch" <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3957>
<kyrofa> jdstrand, I assume you're at the rally?
<mup> PR snapd#3959 opened: hooks: rename refresh to after-refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/3959>
<mup> PR snapd#3956 closed: snap-confine: bind mount /usr/lib/snapd relative to snap-confine <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3956>
<cachio> pstolowski, https://paste.ubuntu.com/25615089/
<kyrofa> zyga-ubuntu, are you here?
<kyrofa> (on IRC, I mean)
<nacc> sergiusens: is the env stuff from c#1 in LP: #1600035 done? A comment from ~1 year ago says "we are also going to allow..." without any date
<mup> Bug #1600035: no way to differentiate between build-time and run-time env vars in plugins <Snapcraft:Triaged by kyrofa> <https://launchpad.net/bugs/1600035>
<nacc> kyrofa: or maybe you kow (about environment: / build-environment: in the yaml). That would I think basically drop my custom wrappers and plugin altogether
<kyrofa> nacc, environment is there, yeah, should get rid of a lot of wrappers
<kyrofa> nacc, build-env, I don't think so
<kyrofa> nacc, environment is a key on each app you declare
<kyrofa> (like plugs)
<kyrofa> There _might_ be a global one... I can't remember
<zyga-ubuntu> kyrofa: hey
<zyga-ubuntu> kyrofa: yes
<nacc> kyrofa: oh ok, it's not here: https://snapcraft.io/docs/build-snaps/syntax
<kyrofa> Hey zyga-ubuntu! I see the kernel-module-control interface... any chance you could give me a quick synopsis of what that does?
<nacc> kyrofa: that's still better than what I have, so that's fine :)
<zyga-ubuntu> kyrofa: yes, sure
<kyrofa> nacc, hmm, indeed. This will help: https://stackoverflow.com/questions/42991501/snapcraft-custom-ld-library-path
<zyga-ubuntu> kyrofa: that interface allows the snap to insert/remove kernel modules
<kyrofa> nacc, would you mind logging a bug for the missing docs, please? Against snapcraft
<zyga-ubuntu> kyrofa: by itself, not with snapd acting at the middle man
<zyga-ubuntu> kyrofa: so you can modprobe essentially
<kyrofa> zyga-ubuntu, modules contained within an app snap?
<zyga-ubuntu> kyrofa: tip: snap interface kernel-module-contorl
<mup> PR snapd#3960 opened: travis: switch to container based test runs <Created by mvo5> <https://github.com/snapcore/snapd/pull/3960>
<zyga-ubuntu> kyrofa: well, any, you can wget modules or stuff
<kyrofa> zyga-ubuntu, dude, awesome. Is that privileged?
<zyga-ubuntu> kyrofa: it's just the permission to perform the kernel operation
<zyga-ubuntu> kyrofa: totally
<zyga-ubuntu> kyrofa: it requires an assertion to connect
<zyga-ubuntu> kyrofa: canonical-livepatch uses it
<nacc> kyrofa: yep will do after a mtg
 * zyga-ubuntu will EOD soon
<zyga-ubuntu> any last calls from the Ubuntu rally?
<zyga-ubuntu> mvo: what is the motivation for https://github.com/snapcore/snapd/pull/3960/files ?
<mup> PR #3960: travis: switch to container based test runs <Created by mvo5> <https://github.com/snapcore/snapd/pull/3960>
<zyga-ubuntu> mvo: is it just faster
<mvo> zyga-ubuntu: correct
<mvo> zyga-ubuntu: also more "machines" available
<mvo> zyga-ubuntu: its a bit of an experiment right now
<zyga-ubuntu> aha, thank you for the explanation
<zyga-ubuntu> hehe, "machines" :-)
<mvo> zyga-ubuntu: your welcome, we are currently trying to find out if this is true
<mvo> zyga-ubuntu: right now there is quite a bit of lack between pushing a PR and the first time travis asssigns a worker
<zyga-ubuntu> yep
<zyga-ubuntu> "lag" I assume
<zyga-ubuntu> we're using the KVM based machines and those just cost them more
 * zyga-ubuntu EODs
<zyga-ubuntu> have a great rally everyone!
<nacc> sergiusens: what is the 'correct "program loader"'? and how is that determined?
<jdstrand> kyrofa: yep, I'm here. zyga asked too if you see him
<mup> PR snapd#3959 closed: hooks: rename refresh to after-refresh <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3959>
<ogra_> ppisati, http://paste.ubuntu.com/25615430/ is the attempt to fix AlbertA and bschaefer's SD corruption ...
<apol> sergiusens: https://paste.kde.org/prox9diqs
<sergiusens> stgraber mind parsing what that means ^... this is on arch
<stgraber> apol: you need the linux-userns kernel
<stgraber> apol: the default Arch kernel doesn't have user namespaces so only privileged containers can be used until you switch to the linux-userns kernel
<stgraber> apol: you can create privileged containers with -c security.privileged=true
<apol> right...
<apol> I'll try with  -c security.privileged=true
<nacc> sergiusens: is there black voodoo going on that allows generated wrappers (in classic snaps) to have #!/bin/sh in them?
<kwmonroe> is it possible to mount a rw slot (write: $SNAP_DATA) from a ro plug (target: $SNAP/foo)? with core 16-2.27.6, i get permission denied: http://paste.ubuntu.com/25615637/
<sergiusens> nacc check snapcraft.internal.meta, but we don't generate wrappers for classic
<nacc> ... sure you do :)
<nacc> http://paste.ubuntu.com/25615968/
<nacc> I don't konw *why* you do
<nacc> http://paste.ubuntu.com/25615970/
<sergiusens> nacc to allow you to specify `command: some-command -w $SNAP_USER_DATA`
<sergiusens> nacc so, environment variables
<nacc> sergiusens: right, so you *do* make wrappers :)
<sergiusens> nacc yeah, we do; that dropped my mind
<sergiusens> but...
<nacc> sergiusens: yep, i imagine it's some voodoo so that /bin/sh isn't used from the host FS
<sergiusens> nacc your thoughts on  https://github.com/snapcore/snapcraft/pull/1420 would be appreciated
<mup> PR snapcraft#1420: add new "no-wrapper" property to apps <Created by mvo5> <https://github.com/snapcore/snapcraft/pull/1420>
<nacc> sergiusens: i'll take a look :)
<sergiusens> nacc for classic the voodoo is incomplete though, we would need to change it to `#!/snap/core/current/bin/sh`
<nacc> sergiusens: i know little of the internals, but can give feedback
<nacc> sergiusens: yep, that's what i'm havig to do in my scripts, or they segfault :)
<sergiusens> nacc if you want to create a PR with that fix to use the correctly shebanged sh in the wrapper I would appreciate that ;-)
<sergiusens> if not I'll take care of it
<nacc> sergiusens: heh, i'll put it on my backlog :)
<sergiusens> nacc if you can't get to it, just tell me and I'll take care of it
<nacc> sergiusens: it's probably not going to bubble to the top of my queue anytime soon, so it's probably better for you to do
<cachio> mvo, when you have a minute https://github.com/snapcore/spread-cron/pull/46
<mup> PR spread-cron#46: Add configure files as part of the sync <Created by sergiocazzolato> <https://github.com/snapcore/spread-cron/pull/46>
<mvo> cachio: sure, coming in a minute
<ppisati> ogra_: http://people.canonical.com/~ppisati/linux-image-4.4.0-1075-raspi2_4.4.0-1075.83~ograsdquirks_armhf.deb
 * ogra_ hugs ppisati ... 
<mup> PR snapd#3961 opened: git: make the .gitingore file a bit more targeted <Created by mvo5> <https://github.com/snapcore/snapd/pull/3961>
<jdstrand> nessita: hi! I just noticed that https://dashboard.snapcraft.io/dev/snaps/6058/rev/661/ is 'stuck'. the automated review passed, but it didn't get approved and there are a bunch of revisions after it pending review
<jdstrand> nessita: (and it's showing up in https://dashboard.snapcraft.io/dev/snaps/reviewer/ubuntu/)
<roadmr> jdstrand: hm, similar to what just happened with hugo, which I just unblocked
<roadmr> jdstrand: ah! 6058 *is* hugo :)
<roadmr> jdstrand: 661 is now ready to release? so is 662...
<roadmr> jdstrand: revision 620 was pending resolution, so all subsequent uploads got held. I unblocked 620 and the queue is being processed...
<roadmr> almost there, there are 714 revisions, it's up to 702 and working
<roadmr> elopio1, jdstrand : all outstanding hugo uploads are reviewed, passed and ready to release
<ogra_> pstolowski, i need the output of: grep . /sys/class/mmc_host/mmc0/mmc0:*/* 2>/dev/null
<pstolowski> ogra_, http://pastebin.ubuntu.com/25616270/
<ogra_> perfect !
<navyguns> I was trying the tutorial found at snapcraft.io and followed it exactly but keep getting this error when running the snapcraft command: "Issues while validating snapcraft.yaml: found character '\t' that cannot start any token on line 14 of snap/snapcraft.yaml". I cannot find the "\t" character anywhere in the .yaml file. Anyone else run into this issue?
<nacc> navyguns: it's a tab character
<navyguns> Thanks. I'll check.
<nacc> navyguns: my guess would be mixing tabs and spaces, possibly?
<navyguns> Yes, that was it. Now i'm getting  a "mapping here on line 2" which contains Version: '2.10"
<navyguns> Well, got rid of those errors.  Executing snapcraft now produces a bunch of python3 code errors and then quits. Running on Mint 18.2 Cinnamon.
<elopio1> thank you. I've notified them in the bug. And thanks jdstrand for looking at it too.
<nacc> navyguns: 'code errors'? Can you pastebin the command and output?
<willdeberry> quit
<navyguns> https://pastebin.com/WprAeU7Q
<nacc> navyguns: it would appear that mint's snapcraft doesn't work?
<nacc> navyguns: dunno, that error implies no subclass is being used
<navyguns> Thanks for looking. I'm going to have to deal with it later. Work calls.
<kwmonroe> heyo jdstrand: i can't figure out a hook that i can call to setup a content plug subdirectory early enough to beat the interface auto-connect.  does such a thing exist?  (install, prepare-plug-foo don't seem to work).  when you get some time, can you advise on https://bugs.launchpad.net/snapd/+bug/1719370
<mup> Bug #1719370: snaps with content plug fail to install with auto-connect <snapd:New> <https://launchpad.net/bugs/1719370>
<kwmonroe> i have a couple workarounds:  1) install the plug snap first, then the slot snap, or 2) work out something using the home interface.  ideally though, i'd like to keep these bits in a $SNAP_x directory vs every users' $HOME.
<mup> PR snapd#3961 closed: git: make the .gitingore file a bit more targeted <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3961>
<mup> PR snapd#3962 opened: tests: Increase SNAPD_CONFIGURE_HOOK_TIMEOUT to 3 minutes to install real snaps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3962>
<gouchi> hi
<gouchi> to use https://build.snapcraft.io
<gouchi> the snapcraft.yaml needs to be in the root or snap directory only ?
<gouchi> it can't look other directory ?
<nacc> gouchi: where else would you like it to live? snap sources often have toplevel snap/
<gouchi> some software may organize their source differently with sub directory
<gouchi> for instance pkg/deb, pkg/rpm , pkg/snap ...
<gouchi> not necessarily in snap/
<gouchi> it will be great if you can specify custom path to snapcraft.yaml for the building process
<kwmonroe> +1 gouchi.. fwiw, i'm writing snaps for apache bigtop which keeps their packaging bits in ./pkgs/src/[deb|rpm].  my workaround for now is to maintain intermediate repos for use by the snap builders (1 snap per repo, each with ./snap/snapcraft.yaml).  i plan to manually sync those with upstream periodically, but if the builders supported a user-specified snapcraft.yaml location, that'd be awesome!
<nacc> gouchi: it depends, i guess
<nacc> as kwmonroe said, it's trivial to create just a basically empty repo with snap/ inn it
<nacc> that fetches the 'upstream' source via git
<nacc> (in the yaml)
<gouchi> yes
<nacc> kwmonroe: why do you need to sync yours with upstream?
<nacc> kwmonroe: that is, why isn't the upstream a part in your yaml
<kwmonroe> nacc: the upstream is a part of my yaml (https://github.com/juju-solutions/snap-hadoop/blob/master/snap/snapcraft.yaml#L100) just like you said -- fetching upstream in one of my parts.  but since bigtop houses rpm and deb control files, it'd be nice to stick ./snap up there too.
<kwmonroe> to clarify, the nice part would be if a snap builder (snapcraft or lp) would let me specify the snapcraft.yaml location in the repo when i register it to build.
<nacc> kwmonroe: oh i see, so they could do some testing? and for the latter, so you don't need the intermediary
<kwmonroe> yup
<nacc> (and for the former, to match their other stuff)
<nacc> got it
<kwmonroe> fwiw nacc, projects like bigtop house 30ish other projects (https://github.com/apache/bigtop/tree/master/bigtop-packages/src/deb), so if i wanted to have a snap for each of those, i'd be maintaining 30is intermediate repos.
<nacc> kwmonroe: true enough
<mup> PR snapcraft#1570 opened: Don't fail over empty or faulty lines <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1570>
<mup> PR snapcraft#1571 opened: Make sure we don't try to include an empty set <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1571>
<apol> kyrofa: https://github.com/snapcore/snapcraft/pull/1571 https://github.com/snapcore/snapcraft/pull/1570
<mup> PR snapcraft#1571: Make sure we don't try to include an empty set <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1571>
<mup> PR snapcraft#1570: Don't fail over empty or faulty lines <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1570>
<mup> PR snapd#3963 opened: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<sergiusens> flexiondotorg `export SNAPCRAFT_CONTAINER_BUILDS=1`
<apol> sergiusens: thanks
<mup> PR snapcraft#1572 opened: catkin plugin: allow ROS_MASTER_URI change <Created by cratliff> <https://github.com/snapcore/snapcraft/pull/1572>
#snappy 2017-09-26
<mup> PR snapd#3964 opened: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <https://github.com/snapcore/snapd/pull/3964>
<zyga-ubuntu> o/
<mup> Bug #1717900 opened: Confined snap fail for user with homedir in /var/lib <Snappy:Triaged> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1717900>
<mup> PR snapd#3965 opened: interfaces/mount: add support for parsing x-snapd-{mode,user,group}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965>
<kalikiana> \o
<kyrofa> Hey ogra_, think you might have any free time today to sit down with Chris to talk about gadget snaps?
<ogra_> sure
<ogra_> kyrofa, any time you like
<kyrofa> ogra_, wonderful, thank you, I'll ping you :)
<kyrofa> lool, you around?
<kyrofa> lool, question about your dnsmasq snap
<zyga-ubuntu> hey kyrofa
<zyga-ubuntu> how's the event?
<kyrofa> zyga-ubuntu, going quite well. Nice to just sit down with these folks and get their stuff working
<zyga-ubuntu> kyrofa: what are you working on there?
<apol> https://pastebin.com/neAd9iPU
 * zyga-ubuntu wonders why removing unused code makes tests fail
<zyga-ubuntu> it must have been _slightly_ used :/
<zyga-ubuntu> ah wait, master is broken!?
<zyga-ubuntu> or artful is broken
<Son_Goku> everything is broken, zyga-ubuntu
<kyrofa> zyga-ubuntu, got a few roboticists here working on snapcraft updates and snapping their stuff
<zyga-ubuntu> kyrofa: sounds great, tweet a few pics, that stuff is very interesting to people
<mup> PR snapd#3966 opened: cmd/snap-seccomp,osutil: make user/group lookup functions public <Created by zyga> <https://github.com/snapcore/snapd/pull/3966>
<morphis> davidcalle: is there any target date when docs.ubuntu.com will be refreshed?
<davidcalle> morphis: afaict, there is a deployment outage since sep 21st, I'm running one now, will ping you when I know more
<morphis> davidcalle: ok, thanks
<__chip__> zyga-ubuntu: how's things?
<zyga-ubuntu> __chip__: hey
<zyga-ubuntu> __chip__: climbing out of the rm -rf hole but making progress
<__chip__> zyga-ubuntu: sergiusens could use some pointers, i hear
<zyga-ubuntu> __chip__: about?
<__chip__> zyga-ubuntu: climbing out of the rm -rf hole
<__chip__> zyga-ubuntu: although in his case i think it's a "do git clone in the wrong place" hole
<__chip__> or git reset?
<__chip__> i dunno
<__chip__> it sounded nasty so i didn't listen, just in case he wanted me to fix it
<cratliff> @ogra_   Hey,  would you be available to look at making a gadget snap with me?
<nothal> cratliff: No such command!
<zyga-ubuntu> __chip__: I killed my data last week
<cratliff> ogra_
<ogra_> cratliff, sure, where are you ?
<cratliff> ogra_  I'm in the snapcraft room on the conference floor, but it is a little full in here if me coming to you works.
<ogra_> ah, i'll come down in 20-0min then (need to finish a test )
<ogra_> *20-30
<ogra_> and i wanted to see the snapcraft room anyway
<cratliff> ogra_ thanks, cya then.
<nacc> sergiusens: i found another case of plugins on classic not dtrt -- the python pluginn invokes /usr/bin/env in the rewrite: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/python.py#L370
<ogra_> (if it is to full we can go to the ballroom or some such ... )
<nacc> sergiusens: the whole code needs to be audited for that, IMO
<nacc> *if* one tries to modify LD_LIBRARY_PATH and that wrapper gets invoked, you get segfaults when mismatchinng host and classic snap distribution :)
<nacc> and no built-in way to avoid it
<nacc> for a classic app, does snapd setup LD_LIBRARY_PATH for the app? To refer to the core snap? Can I assume that in my own environment (so I can say prepend my snap's library paths)?
<ogra_> bschaefer, i cant get the card to misbehave :/ so i guess i'll need the one where you are actually seeing the breakage ... were you using it on pi2 or pi3 ?
<bschaefer> ogra_, raspi3
<ogra_> yeah, thats what i'm trying it on
<bschaefer> yeah i got the things installed i need so you can get this one if you want, ive not had the issue
<bschaefer> since ive manually mounted the overlay.tar
<bschaefer> or ... w/e it was
<bschaefer> but yeah umm you can take this one as well and i can use that one
<bschaefer> ogra_, what room are you in?
<ogra_> bschaefer, at the end of the same corridor you are
<mup> PR snapd#3967 opened: release: release snapd 2.28 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3967>
<jamesh> nacc: IIRC, snapcraft will set flags to try and link using -rpath to point at the core snap
<jamesh> rather than setting LD_LIBRARY_PATH for you
<jamesh> depending on your app's build system, that might not take effect though
<ogra_> cratliff, sorry, will still take a bit up here ... i'm in 1419 though in case you want to come upstairs
<nacc> jamesh: ok, so in theory, do I need to specify LD_LIBRARY_PATH for *classic* snaps to force my app to use only my snap's libs and the core snap's libs?
<cratliff> ogra_, no problem.  Does after lunch work well?
<nacc> jamesh: specifically, since a 16.04-built classic snap with a 16 core could run on artful, it's *really* important not to use libs from the host.
<jamesh> nacc: if your project's build system respects the LDFLAGS environment variable,  it should end up with an rpath that will search common paths in both itself and the core snap
<nacc> jamesh: ok, let me try that
<jdstrand> kyrofa: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5
<mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1598309>
<jamesh> nacc: try running "objdump -x /path/to/my/exe | grep RPATH"
<nacc> jamesh: i have had to do stuff in my own wrappers so far, because I will get thinngs like man in my snap not finding the custom-built /usr/lib/man-db in my snap
<nacc> jamesh: will do
<jamesh> nacc: that should show up paths that will be searched before the default library locations
<jamesh> if it doesn't show anything, then you might need to alter your project build system to make use of LDFLAGS
<nacc> jamesh: are you sure what you describe is true for classic snaps?
<ogra_> cratliff, sure
<ogra_> popey, moop moop
<jamesh> nacc: yes.  You can see the logic in Snapcraft's build_env() function at /usr/lib/python3/dist-packages/snapcraft/internal/project_loader/_env.py
<ogra_> popey, oh ... unmoop ...
<popey> wat wat
<nacc> jamesh: ok, man for instance is installed via stage-packages
<nacc> in any case, i'll try it
<nacc> jamesh: i'm really curious if this is tested with builds on xenial run on artful?
<jamesh> nacc: if the executable isn't being built under control of snapcraft (as would be the case if you're pulling executables from the Ubuntu archive), then you wouldn't see the rpath
<jamesh> nacc: it would be up to you to handle it
<jamesh> either by trying to patch in an rpath, or use a wrapper shell script that configures LD_LIBRARY_PATH instead
<jamesh> patchelf can add an rpath to an existing binary, but sometimes fails
<nacc> jamesh: ok, so there are two cases, got it
<jamesh> (it isn't always possible to modify an already linked executable)
<nacc> well, fwiw, (jamesh is gone), the python3 generated in the classic snap by using the pythonn plugin also does nont have any RPATH set
<nacc> core snap's ldd references a host path
<nacc> (/bin/sh)
<nacc> err, /bin/bash
<davidcalle> morphis: it will be deployed at some point in the next hours (https://docs.staging.ubuntu.com/core/en/stacks/network/index) , IS is looking into it.
 * nacc is super-confused, the bash in the core snap also has no rpath
<nacc> so was jamesh wrong earlier?
<nacc> and if i try to run binaries from the core snap restricting LD_LIBRARY_PATH i get segfaults (Probably implies I'm being too strict)
<ogra_> nacc, snaps do a pivot_root when running ... how do you check ?
<ogra_> nacc, http://paste.ubuntu.com/25621829/
<nacc> ogra_: classic snaps too?
<ogra_> nacc, thats a zyga-ubuntu question
<nacc> ogra_: ok
<nacc> zyga-ubuntu: --^ :)
<nacc> i assume they *don't* otherwise they couldn't use the host at all
<nacc> but if they don't, none of the core snap makes much sense
<nacc> debugging all of this has really not been fun, and makes me thinks classic snaps on artful may just be sort of broken (even if they happen to work some of the time)
<nacc> ogra_: your paste makes total sense on core and with confined snaps (to me)
<ogra_> they could use the host if they pivot and then bind-mount half the host ;)
<nacc> i hope that isn't how it's done :)
<nacc> but it might be, true
<nacc> and i guess snapd has privilege to do that before running the app
<nacc> ogra_: but i still don't see any actual use of rpath in the core snap's binaries
<ogra_> (which they do via /var/lib/snapd/hostfs/ i think)
<ogra_> well, the core snap is built from debs ... iirc rpath isnt allowed in debs
<nacc> ogra_: ok, so maybe there is snapd voodoo for that on classic, for core snap binaries
<nacc> the problem is, I have almost no way of knowing if that is true :)
<ogra_> https://wiki.debian.org/RpathIssue
<ogra_> "While there's no policy dictating the accepted use of RPATH, it's been a general consensus that RPATH use is discouraged, given the interactions between the above reasons and Debian's way of dealing with libraries and package dependencies. "
<pstolowski> jdstrand, hey, what conf room are you in?
<zyga-ubuntu> pstolowski: hey
<zyga-ubuntu> pstolowski: how's the event?
<pstolowski> zyga-ubuntu, it's good!
<ogra_> mvo, https://github.com/snapcore/snapd/pull/2105
<mup> PR #2105: snapstate: only import defaults from gadget on install <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2105>
<ogra_> mvo, https://github.com/CanonicalLtd/ubuntu-image/pull/72
<mup> PR CanonicalLtd/ubuntu-image#72: Make sure <unpack>/image/etc gets into the system-data directory <Created by warsaw> <Merged by warsaw> <https://github.com/CanonicalLtd/ubuntu-image/pull/72>
<nacc> is it possible that while building a snap, one part (e.g., mine that builds xz-utils) gets staged/built, and then a subsequent part that depends on it (dpkg), sees the xz binary in stage, but rpath hasn't been modified on it yet, so it, at runtime, tries to load core libs, instead of libs from my snap?
<kyrofa> nacc, rpath hasn't been modified one... what? xz?
<kyrofa> s/one/on/
<nacc> kyrofa: yeah, on the staged xz
<nacc> i'm wondering about the order here
<nacc> http://paste.ubuntu.com/25622009/
<nacc> is the error dpkg's autopoint is spitting out
<kyrofa> nacc, the first bit makes total sense: if part A builds "after" part B, part B will be staged before A is built
<nacc> which feels like a mismatch between the just built xz and the libs being loaded
<kyrofa> Ah, this sounds like an LD_LIBRARY_PATH ordering issue
 * __chip__ might be having too much fun right now
<mup> PR snapd#3968 opened: daemon: use client.Snap instead of map[string]interface{} for snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/3968>
<nacc> kyrofa: maybe? i'm not setting it at all
<nacc> kyrofa: this is during the build
<kyrofa> nacc, yeah but snapcraft does. Checking...
<nacc> kyrofa: yeah :)
<kyrofa> nacc, this is a classic snap, I assume?
<nacc> kyrofa: so i can confirm the core snap's liblzma is XZ_5.0 while my built one is XZ_5.2
<nacc> kyrofa: yep
<davidcalle> morphis: It's live
<nacc> kyrofa: would i need to write my own plugin in the short-term?
<kyrofa> nacc, I suspect something odd is happening in snapcraft itself, particularly in snapcraft/internal/project_loader/_env.py
<kyrofa> Could the LDFLAGS be going wrong there?
<nacc> kyrofa: it could be (although i don't know how to debug that) -- but also, how is it finding my just built xz? I don't see PATH manipulation there
<kyrofa> nacc, look at runtime_env there
<nacc> kyrofa: but that's for runninng binaries, not building them?
<nacc> or is the xz now a runtime
<nacc> kyrofa: bbiab
<kyrofa> nacc, yeah the name is perhaps a bit misleading: it still gets evaluated for the build env
<kyrofa> sgclark, SNAPCRAFT_CONTAINER_BUILDS=1 snapcraft
<sgclark> thanks!
<ogra_> pstolowski, https://docs.ubuntu.com/core/en/reference/interfaces/index
<kyrofa> Hey ogra_ any idea why we're using /etc/profile to add /snap/bin to the path? Is there no way to do it without a login shell?
<__chip__> kyrofa: hey, what's that about /etc/profile and login shells?
<ogra_> kyrofa, the only other way is /etc/environment and that can only be changed for new installs ...
<__chip__> well, there is environment.d
<ogra_> kyrofa, we could surely talk to foundations (hey slangasek ) about adding /snap/bin to /etc/environment in new artful installs by default as we do since a while on ubuntu core images
<ogra_> __chip__, is that finally landed ?
<kyrofa> ogra_, yeah it's odd to have different behavior depending on how you're logging in, e.g. we have someone here trying to package mosh
<ogra_> (i only know thats a lennart plan but havent heard anyone implemented it yet in a stable distro)
<ogra_> kyrofa, if you're logging in it should always work
<__chip__> ogra_: I don't think we've got it yet, no, definitely not in x
<kyrofa> ogra_, over ssh
<kyrofa> mosh doesn't run a login shell, so you have to give it an absolute path to the mosh server
<__chip__> kyrofa: fun fact: fedora (and rhel?) load profile.d from non-login shells as well
<ogra_> kyrofa, if you're logging in it should always work (and surely does with ssh ... ) if you do *not* log in ssh will strip your path
<ogra_> kyrofa, but thats an ssh thing ...
<ogra_> kyrofa, anyway ... what needs to happen to have it globally is to add it to /etc/environment ... and by poloicy we do not touch it on installed systems
<__chip__> kyrofa: why doesn't mosh run a login shell?
<ogra_> *policy
<ogra_> kyrofa, the issue is that when using snapd on other distros we can not control /etc/environment (unless they have environment.d support as __chip__ pointed out) ... so there profile.d is the only way
<kyrofa> ogra_, this is what needs to work in order for e.g. mosh to work: https://pastebin.ubuntu.com/25622245/
<kyrofa> __chip__, no clue
<kyrofa> __chip__, https://github.com/mobile-shell/mosh/issues/182
<kyrofa> __chip__, not a mosh user myself
<kyrofa> More of an SSH+screen guy
<jdstrand> pstolowski: 1413
<pstolowski> jdstrand, k, will be there in a few minutes
<ogra_> kyrofa, well, the only way currently is to make mosh use 'ssh sh -l -c "<command>"' instead of 'ssh "<command>"'  ... there is also elopio's bug 1659719 that explains it
<mup> Bug #1659719: ssh can't call a binary from a snap without the full path <isv> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1659719>
<kyrofa> ogra_, how is that fix-committed for snappy?
<kyrofa> Or is that just ubuntu core, and it should also apply to snapd?
<mup> PR snapcraft#1570 closed: Don't fail over empty or faulty lines <Created by aleixpol> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1570>
<mup> PR snapcraft#1571 closed: Make sure we don't try to include an empty set <bug> <Created by aleixpol> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1571>
<kyrofa> jdstrand, your alsa workaround got us further, but now we're getting a denial on /dev/snd/controlC0. snappy-debug suggests the alsa plug, but we're already using it
<__chip__> niemeyer: https://forum.snapcraft.io/t/2268 <- let me know if that seems reasonable, you
<mup> PR snapd#3969 opened: hooks: rename refresh hook to post-refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/3969>
<pstolowski> mvo, ^
<mvo> pstolowski: hm? could you please paste it again?
<pstolowski> mvo, sorry, sure - https://github.com/snapcore/snapd/pull/3969
<mup> PR #3969: hooks: rename refresh hook to post-refresh <Created by stolowski> <https://github.com/snapcore/snapd/pull/3969>
<mvo> pstolowski: ta
<pstolowski> i hope the branch name is accurate ;P
<nacc> kyrofa: i'm here now
<kyrofa> cratliff, https://forum.snapcraft.io/t/expose-a-more-consistent-subset-of-systemds-service-directives
<nacc> kyrofa: did you have any furhter thoughts? this is a relatively big blocker for me right now
<nacc> kyrofa: i'm going to try reordering my build
<nacc> we don't really care about usinng the new xz in dpkg's build, I do't think
<ogra_> compression is overrated anyway :P
<nacc> heh
<nacc> well, SOVERSION'd compression ;)
<ogra_> kyrofa, the bugy is fix comitted for Ubuntu Core (Snappy) and livecd-rootfs, snapd had at a similar time the fix in profile.d (which was the only sane thing we could do from a cross distro perspective)
<ogra_> (sorry, only just noticed you answered above)
<kyrofa> cratliff, https://forum.snapcraft.io/t/service-ordering
<nacc> kyrofa: cool, i think orderign (after adding some deps), is letting dpkg build
<nacc> kyrofa: but it does imply a snapcraft bug if the ordering breaks the build inn a non-obvious way
<kyrofa> nacc, yes I'd say so
<nacc> kyrofa: i'll add it to my backlog of bugs to file :)
<mup> PR snapcraft#1573 opened: WIP project_loader: parse YAML without processing it <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1573>
<nacc> kyrofa: any ideas? http://paste.ubuntu.com/25623175/
<nacc> kyrofa: that's pygit2 from a part using the python snap
<kyrofa> nacc, are you using python from the archive?
<nacc> kyrofa: yes
<mup> Bug #1719747 opened: Fedora 26 LXD container: cannot load apparmor profile <Snappy:New> <https://launchpad.net/bugs/1719747>
<kyrofa> nacc, sergiusens will know more, but I seem to remember an issue with that, e.g. it's hard-coded to the wrong libc or something. We had to build our own Python in snapcraft to get around it
#snappy 2017-09-27
<nacc> kyrofa: ... ok
<nacc> sergiusens: if you can confirm, i can do it
<nacc> kyrofa: thannks, i see it in the snapcraft yaml and also saw it earlier with conjure-up. Will try that!
<nacc> kyrofa: ok, now i'm confused, if i build my own python != ubuntu python (e.g., 3.6 instead of 3.5 in xenial), how do i ensure the parts that depend on it use that python? it seems like it's usinng the packaged python3 to build the modules
<lool-> kyrofa: shoot!
<lool-> kyrofa: I'm on the west coast for the week, not watching IRC much though
<mup> PR snapd#3967 closed: release: release snapd 2.28 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3967>
<mup> PR snapd#3969 closed: hooks: rename refresh hook to post-refresh <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3969>
<mup> PR snapd#3968 closed: daemon: use client.Snap instead of map[string]interface{} for snaps <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3968>
<mup> PR snapd#3962 closed: tests: Increase SNAPD_CONFIGURE_HOOK_TIMEOUT to 3 minutes to install real snaps <Created by sergiocazzolato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3962>
<mup> PR snapd#3960 closed: travis: switch to container based test runs <Created by mvo5> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3960>
 * zyga-ubuntu -> breakfast
 * zyga-ubuntu bisects snap-seccomp regression
<zyga-ubuntu> doko: hey
<zyga-ubuntu> doko: not sure if you are at the rally or at home
<zyga-ubuntu> doko: I ran into something that I don't understand and I think you could shed some light on it
<zyga-ubuntu> doko: I summarized the problem here: https://forum.snapcraft.io/t/snap-seccomp-fails-tests-on-artful-is-it/2263/4?u=zyga
<zyga-ubuntu> doko: a small test program doesn't compile
<zyga-ubuntu> doko: and fails with the following error
<zyga-ubuntu> /usr/include/stdlib.h:25:10: fatal error: bits/libc-header-start.h: Nie ma takiego pliku ani katalogu
<zyga-ubuntu> (no such file or directory, sorry about that last fragment)
 * zyga-ubuntu moves to another task, not sure how to do this 
<mup> PR snapd#3970 opened: interfaces/mount,cmd/snap-update-ns: move change code <Created by zyga> <https://github.com/snapcore/snapd/pull/3970>
<zyga-ubuntu> man, this is a lonely week here
<Neeraj> "Issues while validating snapcraft.yaml: Additional properties are not allowed ('grade', 'confinement' were unexpected)" in snap classic
<Neeraj> can anybody help
<zyga-ubuntu> Neeraj: hey
<zyga-ubuntu> Neeraj: drop grade, I think it's not used anymore
<zyga-ubuntu> Neeraj: what was the value of "confinement"?
<Neeraj> confinement is "strict"
<zyga-ubuntu> Neeraj: not sure what the latter part of the message is about
<zyga-ubuntu> try again and tell me what you get
<Neeraj> Issues while validating snapcraft.yaml: Additional properties are not allowed ('confinement' was unexpected)
<Neeraj> is it ok to drop confinement
<Neeraj> (classic)admin@GTXQB02:~/TSE$ snapcraft Issues while validating snapcraft.yaml: Additional properties are not allowed ('confinement' was unexpected)
<Neeraj> I am in classic mode
<zyga-ubuntu> Neeraj: what do you mean you are in classic mode?
<Neeraj> --beta --devmode classic
<zyga-ubuntu> Neeraj: do you mean that the snap you've installed is in that mode and that somehow affects how it validates in snapcraft?
<Neeraj> yes
<Neeraj> zyga-ubuntu : is you are correct
<Neeraj> zyga-ubuntu: snapcraft executes only in classic mode
<zyga-ubuntu> Neeraj: hmm, I doubt that how snapcraft is installed affects how it validates other snaps
<zyga-ubuntu> Neeraj: in any case, I'm not a snapcraft developer, please ask when US wakes up :/ I don't know what the problem might be
<zyga-ubuntu> Neeraj: if you pastebin the snapcraft.yaml and open a forum thread it will be easier to get an answer in other timezones
<mup> PR snapd#3971 opened: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <https://github.com/snapcore/snapd/pull/3971>
<kalikiana_> o/
 * zyga-ubuntu -> break
<Son_Goku> >_>
<__chip__> zyga-ubuntu: good morning sah
<jdstrand> sergiusens: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1598309/comments/5
<mup> Bug #1598309: The aplay command doesn't work <snapd-interface> <xenial> <snapd (Ubuntu):Fix Released by jdstrand> <https://launchpad.net/bugs/1598309>
<jdstrand> sergiusens: fyi, two people in this room hit this issue and were annoyed by it, in fact, considering classic confinement
<Chipaca> zyga-ubuntu: o/?
<jdstrand> sergiusens: https://forum.snapcraft.io/t/snap-and-executable-stacks/1812
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> Chipaca: how are things?
<zyga-ubuntu> jdstrand: hello
<apol> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1719928
<mup> Bug #1719928: snapcraft update won't fetch from SNAPCRAFT_PARTS_URI  <Snapcraft:New> <https://launchpad.net/bugs/1719928>
<mup> PR snapd#3972 opened: repo: sanitize plugs and slots early in ReadInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/3972>
<jamesh> zyga-ubuntu: hi.  Thanks for the review of my user-mounts PR.  There were a few change suggestions (moving code to snap-update-ns, persisting mount namespaces, etc).  Want to discuss?
<zyga-ubuntu> jamesh: hi
<zyga-ubuntu> jamesh: yes!
<zyga-ubuntu> jamesh: I think mvo was trying to set up a hangout
<zyga-ubuntu> jamesh: can you guys get together and join, say, the daily standup HO?
<jamesh> zyga-ubuntu: mvo said he didn't necessarily need to be in the hangout.  Let me find some place quiet
<zyga-ubuntu> aha, that's fine
<zyga-ubuntu> I'm ready as you are, just give me the word
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3973
<mup> PR #3973: cmd/snap-confine: put processes into freezer hierarchy <Created by zyga> <https://github.com/snapcore/snapd/pull/3973>
<mup> PR snapd#3973 opened: cmd/snap-confine: put processes into freezer hierarchy <Created by zyga> <https://github.com/snapcore/snapd/pull/3973>
<apol> kalikiana_: http://www.proli.net/2017/05/23/kdevelop-runtimes-docker-and-flatpak-integration/
<mup> PR snapd#3974 opened: Recognise Solus as a classic Linux distribution <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3974>
<zyga-ubuntu> ikey: thank you!
<ikey> np bud
<ikey> more to come probably
<ikey> we need snapd/polkit for the solus SC to work
<ikey> so im taking us to git which means making git support solus :P
<ikey> i considered changing the conditional to if distro == ubuntu but then i remembered everyone mangles their os-release/lsb_release for branding ..
<zyga-ubuntu> "taking us to git" ?
<ikey> taking solus snapd package to git in unstable
<ikey> vs released pkg
<ikey> so that i can get SC working
<Son_Goku> zyga-ubuntu: this check really needs to be reworked
<ikey> Son_Goku, it would break ubuntu derivatives that rebrand
<ikey> and others
<ikey> i had the same thought
<ikey> but i dont see it as viable
<ikey> which is why its "explicitly not ubuntu" vs "is ubuntu"
<Son_Goku> ikey: well, if we check for ID and ID_LIKE for particular values to enable ubuntu-ish behavior
<ikey> assuming derivs arent derping that already
<Son_Goku> then default to not enabling ubuntu-ish behavior, it's more likely to work properly
<ikey> and im not aware of many using ID_LIKE
<ikey> tbh
<Son_Goku> most derivatives of the major distributions use ID_LIKE
<ikey> yknow what'd simplify it all together?
<Son_Goku> for example, even RHEL identifies as "like Fedora"
<ikey> if the snapd package in the repos contains a file saying a reexec is OK
<Son_Goku> ikey: runtime detection? :)
<ikey> so its determined at packaging level
<ikey> and all derivs implicitly use it
<ikey> unless they repackage
<Son_Goku> ikey: in Fedora, I do that for re-exec
<Son_Goku> that's the /etc/sysconfig/snapd
<Son_Goku> because otherwise derivatives are busted
<ikey> stateless it! :P
<ikey> lol
<Son_Goku> well, I was talking to mvo earlier about making it so snapd didn't depend on environment variables to do this
<Son_Goku> and instead read a config file in /etc/ and in /usr/share
 * ikey likey
<Son_Goku> (with /etc/ overriding /usr/share values, obviously)
<ikey> :D
<Son_Goku> well, this scheme is something we've been moving to as a whole in Fedora
<ikey> ah good
<Son_Goku> it's why we don't recommend doing dumb things like using environmentfiles
<ikey> heh
<Son_Goku> but the Go community explicitly recommends controlling by environment files
<ikey> and then systemd was like hey - lets reinvent pam_env xD
<Son_Goku> well, at least the pam_env works with packager -> override by admin model
<ikey> mm
<Son_Goku> err, the systemd version
<Son_Goku> the pam_env doesn't
<ikey> ya no that ones bork
<Son_Goku> everything lives in bloody /etc
<Son_Goku> my ideal is that /etc/ would be drained of things shipped by packages
<ikey> yeo
<ikey> *yep
<ikey> i think we need to align all distros on the new wheres though
<ikey> in clr and solus we went for /usr/share/defaults for renamespaced config fallbacks
<ikey> and if sensible, /usr/share/$pkg
<ikey> like pulseaudio
<Son_Goku> ikey: I was starting to use /usr/share/$pkg/sysconfig
<ikey> ew
<ikey> its not config :p
<Son_Goku> well, it is
<ikey> its default stuff lol
<ikey> (oh we also use /usr/share/xdg/* )
<Son_Goku> well, the idea is that /etc/sysconfig would override /usr/share/*/sysconfig
<ikey> plus having a single namespace is nicer for tooling
<ikey> /usr/share/defaults/*
<Son_Goku> though if I could have my way, I'd flip it to /usr/share/sysconfig and /etc/sysconfig as the override
<ikey> yeah
<ikey> easier for autotools too tbh
<Son_Goku> yeah
<Son_Goku> the reason I didn't call it defaults is because in many cases, applications don't support partial overrides
<ikey> shpose
<Son_Goku> and that the whole config files have to be overridden
<ikey> a lot of our stateless patches end up being something like:
<ikey> const char *cfg = NULL;
<ikey> if (access(SYSTEM_CONFIG, F_OK) == 0) {
<ikey>     cfg = SYSTEM_CONFIG;
<ikey> } else {
<ikey>     cfg = VENDOR_CONFIG;
<ikey> }
<ikey> In a nut shell ^
<Son_Goku> right
<Son_Goku> and that does make sense
<ikey> older applications are harder to do merges on
<Son_Goku> and that's pretty much why I went with sysconfig as the directory name
<ikey> yeah
<Son_Goku> IMO, it's more obvious to people what it means
<ikey> reason i disagree with the name is because the relation to SYSCONFDIR
<Son_Goku> ah
<ikey> When there is the mental separation of sys vs vendor
<Son_Goku> I didn't think of that
<ikey> or rather, os / data
<Son_Goku> right
<ikey> + config
<ikey> its a tough one for sure but id love for us all to go the same path
<ikey> whatever that path is
<ikey> and then start prodding all the relevant projects to follow
<Son_Goku> so another thought I had was /usr/share/vendorcfg
<Son_Goku> and /etc/sysconfig for the admin version
<Son_Goku> but I didn't like that so much because it's not as obvious for the mental map
<ikey> as long as the package upstreams are onboard with the possibility of their vendorcfg being replaced by us
<ikey> which is the issue i guess
<ikey> we're the vendors they're the upstreams
<Son_Goku> yeah
<Son_Goku> well, the idea is that /etc/sysconfig is where users make their own configs
<ikey> right
<ikey> local sysadmin
<Son_Goku> and /usr/share/vendorcfg is where the packages ship them
<ikey> (you can see why we ended up with 'defaults' eh? :P)
<Son_Goku> yeah
<ikey> tbh its almost like "fallback" is the more appropriate term
<Son_Goku> I threw away that name almost immediately because the implications that the name has
<ikey> just sounds lame
<ikey> yer
<Son_Goku> naming things is hard :)
<ikey> oh dont i know it
 * ikey is the author of such wonders as 'Dave2' and 'libthingamabob'
<kalikiana_> https://bugs.launchpad.net/snapcraft/+bug/1590599
<mup> Bug #1590599: snapcraft prerequites are slow to resolve <eco-team> <Snapcraft:Fix Released by sergiusens> <https://launchpad.net/bugs/1590599>
 * ikey looks at related snapcraft pull and hugs ypkg
<kalikiana_> ikey: thinking of adding a snapcraft backend for ypkg? :-D
<nacc> kyrofa: sorry to bother, but did you see my last messages from yesterday? how do I ensure that if I have a python3 part (e.g., for 3.6.2, while xenial has 3.5.x), that the subsequent parts use that python? (otherwise, there doesn't seem to be any modules installed by the subsequent part for 3.6)
<ogra_> davidcalle, hrm .. all the links at the bottom of https://docs.ubuntu.com/core/en/reference/gadget#examples-of-production-ready-gagdet-snaps are wrong ...
<davidcalle> ogra_: ok, what are the more recent ones?
<ogra_> davidcalle, they are on GH ... i'd open a PR but that page doesnt seem to be in https://github.com/CanonicalLtd/ubuntu-core-docs/tree/master/en/guides/build-device
<ogra_> boo
<ogra_> because i'm in the wrong dir :P
<davidcalle> ogra_: https://github.com/CanonicalLtd/ubuntu-core-docs/blob/master/en/reference/gadget.md
<davidcalle> :D
<ogra_> yeah, got it
<ikey> kalikiana_, probably could
<ikey> emit .snap's easily enough
<ikey> id leave it until i have a solus base snap though
<nacc> stokachu: --^ you might have a comment on my earlier point. As I thinkn you also have 3.6.2 in your snap as a part
<nacc> also, why does `snapcraft pull` build stuff.
<apol> SNAPCRAFT_PARTS_URI=http://metadata.neon.kde.org/snap/parts.yaml
<apol> git://anongit.neon.kde.org/applications/kate.git
<nacc> kyrofa: fwiw, if the 'fix' is to build python in a classic snap, that should be a hard requirement (it seems like this is 'known')?
<nacc> sergiusens: --^
<Chipaca> augh, no zyga now :-(
<Chipaca> niemeyer: https://github.com/snapcore/snapd/pull/3964/files#diff-784fe30c70e6724012b7d456d65d97acL152
<mup> PR #3964: many: implement our own ANSI-escape-using progress indicator <Created by chipaca> <https://github.com/snapcore/snapd/pull/3964>
<Chipaca> niemeyer: :-D but also :-D
<ogra_> davidcalle, https://github.com/CanonicalLtd/ubuntu-core-docs/pull/37
<mup> PR CanonicalLtd/ubuntu-core-docs#37: point to proper repos for gadget examples <Created by ogra1> <https://github.com/CanonicalLtd/ubuntu-core-docs/pull/37>
<davidcalle> ogra_: merged, thanks
<ogra_> <3
<mup> PR snapd#3975 opened: snap-confine: Only attempt to copy/mount NVIDIA libs when NVIDIA is used <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3975>
<Son_Goku> kalikiana_: https://gitlab.com/Conan_Kudo/snapcore-mkrpmtree & https://gitlab.com/Conan_Kudo/snapcore-mkrpmtree/pipelines/12211338
<Son_Goku> :D
<nacc> kyrofa: nm on the how to use the staged python, PEBKAC
<apol> kalikiana_: https://bugs.launchpad.net/snapcraft/+bug/1719951
<mup> Bug #1719951: SNAPCRAFT_PARTS_URI doesn't work with cleanbuild <Snapcraft:New> <https://launchpad.net/bugs/1719951>
<ondra> ogra_ ping
<mup> PR snapd#3976 opened: snap-confine: Support biarch Linux distribution confinement <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3976>
<mup> PR snapd#3977 opened: interfaces: Enhance full-confinement support for biarch distributions <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3977>
<magicaltrout> alright folks, how do i request a 2 track snap repo?
<mup> PR snapd#3978 opened: cmd: Correctly name the "Ubuntu" and "Arch" NVIDIA methods <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3978>
<ogra_> ondra, moop
<mvo> jdstrand: if you could have a quick look at https://github.com/snapcore/snapd/pull/3979 that would be great
<mup> PR #3979: snap-confine: update apparmor rules for fedora based base snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3979>
<mup> PR snapd#3979 opened: snap-confine: update apparmor rules for fedora based base snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/3979>
<ikey> looks like 3979 is covered by my PR
<ikey> more completely
<ikey> conflicts at least. :p
<ikey> (3976)
<zyga-ubuntu> Chipaca: hey
<zyga-ubuntu> how's stuff in NYC?
<Chipaca> zyga-ubuntu: hi!
<Chipaca> zyga-ubuntu: not bad
<zyga-ubuntu> I saw your PR, neat stuff
<Chipaca> zyga-ubuntu: i pinged you yesterday and then was busy when you got back to me
<zyga-ubuntu> oh, what about?
<Chipaca> yes, i'm addressing your review now, thank you
<zyga-ubuntu> :-)
<zyga-ubuntu> travis is a bit slow today
<Chipaca> zyga-ubuntu: I'm geting a "cannot perform operation: mount --bind yadda/yadda/etc/alternatives: permission denied"
<Chipaca> zyga-ubuntu: so I thought maybe you'd know what i broke :)
<Chipaca> zyga-ubuntu: (my base does have etc/alternatives)
<zyga-ubuntu> Chipaca: yes, it's a non-generalized rules
<zyga-ubuntu> *rule
<zyga-ubuntu> Chipaca: can you show me the real denial (dmesg | grep DENIED)
<zyga-ubuntu> Chipaca: I thought we fixed that, if not I can correct quickly if you confirm
<Chipaca> zyga-ubuntu: PM
<zyga-ubuntu> Chipaca: I had a productive day today so there's a few things up there but I'd like one thing merged
<zyga-ubuntu> ack
<zyga-ubuntu> https://github.com/snapcore/snapd/pull/3966
<mup> PR #3966: cmd/snap-seccomp,osutil: make user/group lookup functions public <Created by zyga> <https://github.com/snapcore/snapd/pull/3966>
<zyga-ubuntu> I'd love to land this so that I can iterate
<zyga-ubuntu> Chipaca: I'll get some tea and propose a PR for that
<ogra_> a PR for tea ... mmmm
<roadmr> jdstrand: hey, tools r934 are in production now.
<nacc> is there a 'best practices' for testing snaps as-installed?
<mup> PR snapd#3980 opened: snap-confine: Ensure lib64 biarch directory is respected <Created by ikeydoherty> <https://github.com/snapcore/snapd/pull/3980>
<kyrofa> nacc, not really, since it depends on what the snap is
<kyrofa> nacc, for a webapp, I like running a capybara suite against it
<nacc> kyrofa: e.g., we have dep8 that understands (from the src) how to run tests. It feels like we should have something, perhaps onnly for classic snaps, that allows a pivot to the classic and run a test suite
<nacc> *to the classic snap
<kyrofa> nacc, that might make sense to do as the part is being built, but perhaps less sense once the snap is assembled, as things might be completely reorganized and contain _several_ parts
<nacc> kyrofa: yeah that's possibly true
<nacc> i guess i also think there are some apps taht are being built, and the expectation is some behavior on them, e.g., asserted with unit tests. It would make sense to make it 'easy' to test in the snap as-installed, that the behavior is what you want
<kyrofa> nacc, and I'm not sure how much sense it makes on a whole. For example, consider the Nextcloud snap. I'm not really interested in running MySQL's test suite, or Apache's
<nacc> sure
<kyrofa> But I sure want to test that the whole thing works in concert
<kyrofa> Which is a different set of tests
<nacc> but let's say you want to know that mysql accepts your statements, via a unit test.
<nacc> yeah, I think we're actaully saying the same thing :)
<kyrofa> But I can't even communicate with mysql from outside the snap. If mysql's unit tests don't pass I have other problems
<kyrofa> You need some sort of higher-level acceptance tests
<nacc> in classic you could, right?
<nacc> i'm referring to classic in my case
<nacc> i agree with confined snaps it's not easy to solve
<nacc> or it's too snap-specific
<kyrofa> nacc, so you're thinking you would bundle some sort of tests in the final snap?
<nacc> yeah
<nacc> that is intended to run in the same env as the sanp
<nacc> and runs the tests in that env
<kyrofa> nacc, that doesn't bloat the snap?
<nacc> classic snaps are *really* easy to break
<nacc> :)
<kyrofa> Hahaha
<nacc> with mixed hosts
<nacc> (mixed = not all the same host OS)
<kyrofa> nacc, so sort of a "am I sane" app
<nacc> yeah, exactly
<nacc> it's like a self-check
<nacc> i guess that's what i can do
<kyrofa> <snap>.selftest
<nacc> i have the tests in my source
<nacc> yep
<nacc> kyrofa: thanks! that's a godo idea
<kyrofa> nacc, seems reasonable!
<nacc> rbasak: --^
<kyrofa> nacc, I'm not sure I'd call it general guidance, but if that seems doable for your snap I think it seems nice a nice idea
<kyrofa> Uh. seems like a nice... you get the idea
<kyrofa> So braindead :P
<nacc> kyrofa: yeah, it might not be generally useful. I think classic snaps need it more than confined. classic's runtime is far less well-defined
<kyrofa> nacc, are you at the rally, by the way?
<nacc> kyrofa: unfortunately not
<kyrofa> nacc, agreed
<kyrofa> nacc, darn, would have liked to meet
<nacc> i'd be in the snappy room yelling otherwise :)
<kyrofa> Ha!
<ikey> im having issues with snap-update-ns from snapd git
<ikey> snap-update-ns failed with code 1: No such file or directory
<ikey> leaving note more as a reminder to myself tomorrow to bring it up
<Son_Goku> zyga-ubuntu: https://bugs.launchpad.net/snappy/+bug/1719747
<mup> Bug #1719747: Fedora 26 LXD container: cannot load apparmor profile <Snappy:New> <https://launchpad.net/bugs/1719747>
<mup> PR snapd#3960 opened: travis: switch to container based test runs <Created by mvo5> <https://github.com/snapcore/snapd/pull/3960>
<jdstrand> roadmr: oh! yay :)
<jdstrand> oSoMoN: ^ (14:36 < roadmr> jdstrand: hey, tools r934 are in production now.)
<jdstrand> roadmr: thank you :)
<jdstrand> oSoMoN: that has the chromium fix
<roadmr> jdstrand: np! we did an unrelated rollout but the tools update piggybacked on it :)
<jdstrand> music to my ears :)
<jdstrand> I <3 piggybacking
<oSoMoN> jdstrand, yeah I noticed, my latest build went through without the need for a manual review, thanks!
<roadmr> whee :)
<jdstrand> ogra_: fyi, the issue with avahi is that ond ra uploaded the snap ahead of the feature that allows it to work. aka, update to 2.28 and it works fine
<jdstrand> ogra_: I'm letting Til know now
<mup> PR snapd#3979 closed: snap-confine: update apparmor rules for fedora based base snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3979>
<ikey> ow. my PR up in flames. :P
<mup> PR snapd#3981 opened: release: 2.28.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3981>
<mcphail> ikey: +1 for including "whereby" in a pr
#snappy 2017-09-28
<ekkis> I want to package a github project for Ubuntu.  someone said I should check out snap.  it looks great but does the user have to have snap installed to run a snap package?
<ekkis> is it like docker?
<nacc> ekkis: snapd is the runer, it's installed on ubuntu by default, and available for many distributions
<ekkis> I noticed that.  so cool
<zyga-ubuntu> o/
<mup> PR snapd#3982 opened: tests/main: use rm -f in case file isn't there <Created by zyga> <https://github.com/snapcore/snapd/pull/3982>
 * zyga-ubuntu ponders background tasks in spread jobs 
<mup> PR snapd#3982 closed: tests/main: use rm -f in case file isn't there <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3982>
<mup> PR snapd#3981 closed: release: 2.28.1 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3981>
<kissiel> hey folks! Is there a reason for being so restrictive in how config keys can be named?
<kissiel> https://github.com/snapcore/snapd/blob/master/overlord/configstate/config/helpers.go#L34
<kissiel> no underscores, no uppercases allowed :(
<Chipaca> kissiel: if you'd like that loosened, I'd suggest you create a forum topic about it -- the team's sprinting this week so not all eyes are on irc (and not at the usual times)
 * Chipaca hugs zyga-ubuntu because the "all" isn't true
<kissiel> Chipaca: roger that
<zyga-ubuntu> kissiel: also easier to be strict now and less so later :)
<zyga-ubuntu> jjohansen: hello
<jjohansen> hey zyga-ubuntu
<zyga-ubuntu> jjohansen: hey, I wanted to check how is the upstreaming effort
<jjohansen> zyga-ubuntu: everything but unix socket (dbus needs these) rules made it into 4.14
<zyga-ubuntu> how big is the delta from 4.14 then?
<jjohansen> 4.15 is a wip, but I bet you can guess what the goal is
<zyga-ubuntu> jjohansen: and is it likely that 4.15 will contain it all?
<jjohansen> zyga-ubuntu: http://paste.ubuntu.com/25632831/
<jjohansen> zyga-ubuntu: that is the goal
<zyga-ubuntu> that's very nice! thank you for the update
<zyga-ubuntu> jjohansen: do you have the patches for 4.15 in broken down form?
<zyga-ubuntu> jjohansen: I was wondering if those might be easier to apply for 4.14-based distributions
<jjohansen> zyga-ubuntu: the final 4.15 patches no, the patches ubuntu is carrying that can be dropped on top of 4.14 yes
<jjohansen> zyga-ubuntu: be warned though we are about to drop the LSM stacking patches on top of ubuntu, these aren't apparmor persay though they touch it
<zyga-ubuntu> jjohansen: is that a substantial pathc?
<zyga-ubuntu> and is it upstreamed?
<jjohansen> zyga-ubuntu: yeah LSM stacking is pretty substantial, we aren't taking all of it just 22 patches, no it isn't upstream yet, we are trying to help get it upstream
<zyga-ubuntu> understood
<jjohansen> it opens some fun possibilities
<zyga-ubuntu> should we expect any impact on apparmor in general?
<jjohansen> no
<zyga-ubuntu> is there any docs on what those patches allow/do/expose to userspace?
<jjohansen> zyga-ubuntu: you asked about the patch ubuntu is carrying for unix socket mediation, its 1 patch diff stat http://paste.ubuntu.com/25632887/
<jjohansen> zyga-ubuntu: the only documentation atm is in the patches and upstream ml
<jjohansen> we will certainly have to put a little something together so people can experiment with it
<zyga-ubuntu> is the goal there to be able to put selinux and apparmor under each other?
<jjohansen> zyga-ubuntu: yes, I have been playing with that this week, we hope to do an lxd demo (on a patched fedora kernel) with fedora running selinux and running and ubuntu container and running a confined snap in the container
<jjohansen> I don't think we will do a confined snap directly on fedora this week because there is some tooling work to do
<zyga-ubuntu> jjohansen: understood, that is indeed very exciting, cannot wait to see that :)
 * zyga-ubuntu -> lunch
<diddledan> something is wrong with my mir-kiosk attempt :-(
<diddledan> Sep 26 20:32:07 localhost mir-kiosk.mir-kiosk[1138]: /snap/mir-kiosk/35/bin/run-miral: line 68:  1639 Floating point exception${SNAP}/usr/bin/${bin_to_run} --vt 1 --arw-file --file /run/mir_socket
<diddledan> it emits that when I try to launch my client
<diddledan> this is on a raspberry pi
<diddledan> the code and snap are at https://code.launchpad.net/~diddledan/+git/netconsole-reader if you want to investigate with me
<zyga-ubuntu> re
<cachio> pstolowski, https://paste.ubuntu.com/25633274/
<mup> PR snapd#3980 closed: snap-confine: Ensure lib64 biarch directory is respected <Created by ikeydoherty> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3980>
<diddledan> aah, maybe this is a problem: Loading module: 'libubuntu_application_api_desktop_mirclient.so.3.0.0' <-- that file doesn't exist in my snap
<diddledan> nope, waasn't that
<apol> hey, anybody knows if it's possible for different people to access a dashboard.snapcraft.io? in KDE we need different people to see the status and upload things, but sharing the credentials doesn't feel right
<cachio> pstolowski, sudo screen /dev/ttyUSB0 115200
<cachio> pstolowski, https://www.adafruit.com/product/954
<cachio> https://www.modmypi.com/image/cache/data/rpi-products/gpio/debug/USB-to-TTL-Serial-Cable-Debug-Console-Cable-for-Raspberry-Pi-3-800x609.jpg
<pstolowski> cachio, http://pastebin.ubuntu.com/25633478/
<zyga-ubuntu> ikey: hey, I heard you had some issues with snap-update-ns
<ogra_> pedronis, where are you hiding ? need to pick your brain about the branded store stuff if you have some time (or just point me to docs how to include it in a gadget)
<kyrofa> elopio, https://askubuntu.com/questions/816886/how-do-run-an-arm-lxd-container-on-my-intel-host
<mup> PR snapcraft#1552 closed: tests: replace the first batch of demo tests with snapd integration tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1552>
<mup> PR snapcraft#1561 closed: rust plugin: record the Cargo.lock file <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1561>
<mup> PR snapcraft#1574 opened: Add Dotnet plugin and a sample snap for integration test <Created by rakeshsinghranchi> <https://github.com/snapcore/snapcraft/pull/1574>
<ogra_> hmm ... do we have any way that enables me to obtain my own store ID from the commandline ?
<ogra_> (assuming i used snap login before)
<ppisati_> sergiusens: what's the $SNAPCRAFT_PART_* variable that points to the src dir?
<apol> sergiusens: https://community.kde.org/Neon/Snap#Snapd_Problems
<nacc> apol: the 4. there is a huge issue
<nacc> apol: and it's worse, you *can't* debug them host/server-side
<nacc> apol: afaict, as you need to debug within the same env as the snap
<apol> yes, we were looking into this one with sergio
<mup> PR snapd#3983 opened: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3983>
<sergiusens> ppisati_ we have none, do you need one?
<sergiusens> ppisati_ in general it is not needed
<ppisati_> sergiusens: well, here's my problem: i have to build a kernel, and all i get is a tarball containing both the kernel src code and the .config file, and i don't know how express something like 'kconfigfile: $SNAPCRAFT_PART_SRC/.config'
<zyga-ubuntu> flexiondotorg: hey, any luck with arch, 2.28.1 is coming up
<nacc> ppisati_: well, i mean, the kernel build system doesn't fit in any of the plugins, right? so wouldn't you have your own plugin?
<nacc> ppisati_: or is this a gadget sap?
<nacc> *snap
<flexiondotorg> zyga-ubuntu: No reply so far
<zyga-ubuntu> flexiondotorg: thank you
<mup> PR snapd#3984 opened: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3984>
 * zyga-ubuntu goes to the doctor with his son,
<zyga-ubuntu> I'll EOD but return to finish and apply feedback on https://github.com/snapcore/snapd/pull/3966#discussion_r141665125
<mup> PR #3966: cmd/snap-seccomp,osutil: make user/group lookup functions public <Created by zyga> <https://github.com/snapcore/snapd/pull/3966>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#58 closed: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#58 opened: use `snapctl internal configure-core` to configure core <Created by mvo5> <https://github.com/snapcore/core/pull/58>
<mup> PR snapd#3835 closed: packaging: bring down the delta between 14.04 and 16.04 <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3835>
<mup> PR snapd#3985 opened: cmd/snap-repair:  set user agent for snap-repair http requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/3985>
<pstolowski_> Son_Goku, go get -u github.com/nsf/gocode
<sergiusens> apol https://forum.snapcraft.io/t/custom-environment-variables-for-parts/1639/10
<mup> PR snapcraft#1575 opened: added git for '{version: git}' usage <Created by jdxcode> <https://github.com/snapcore/snapcraft/pull/1575>
 * ikey missed zyga, derp
<ikey> mk, thought, the polkit stuff in snapd git should be quite trivial to backport to older snapd right?
<ogra_> pedronis, poke
<ogra_> (or anyone else really ...):
<kyrofa> ogra_, anyone? What's up?
<ogra_> if i have a gpg key thats not yet registered to the store ... can i rm ~/.snap/gnupg/* without killing my setup ?
<ogra_> (snap keys lists it ... and snapcraft keys lists it with "not registered")
<kyrofa> What is your setup if you haven't registered it? Doesn't that imply that you haven't used it at all?
<ogra_> yes, i havent used it ... only tested "create-key"
<ogra_> and didnt call "register-key"
<mup> Bug #1720216 opened: docs.ubuntu.com has "Phone Docs" <docs> <Snappy:New> <https://launchpad.net/bugs/1720216>
<youngc> If I want to install UC16 on system that does not have an image created for - where do I get the base image for UC16
<mup> Bug #1720216 changed: docs.ubuntu.com has "Phone Docs" <docs> <Snappy:Invalid> <https://launchpad.net/bugs/1720216>
<mup> PR snapd#3986 opened: wrappers: fail install if exec-line cannot be re-writen <Created by mvo5> <https://github.com/snapcore/snapd/pull/3986>
<mup> PR snapd#3987 opened: packaging/fedora: Add Fedora 26, 27, and Rawhide symlinks <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/3987>
<pstolowski_> Son_Goku, gofmt -w -s <file>
<ogra_> cprov, do you ahev any clue about gpg keys ? i created a key ages ago on my desktop using snapcraft create-key and register-key ... now ... when using snapcraft login on my laptop i'd actually expect to find this registered key with either snapcraft list-keys or snap keys ... but both are emppty
<ogra_> s/ahev/have/
<__chip__> ogra_: PING
<ogra_> __chip__, P.O.N.G !
<__chip__> ogra_: I have here a disgruntled swiss person that has been looking for you
<ogra_> i'm in the snapcraft room
<__chip__> ogra_: are you going to stay there for any length of time?
<ogra_> yeah
<ogra_> they have the more comfortable chairs
<__chip__> ACK
<__chip__> ogra_: message delivered
<__chip__> ogra_: thank you
<ogra_> good
<mup> PR snapd#3985 closed: cmd/snap-repair:  set user agent for snap-repair http requests <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3985>
<sergiusens> elopio mind reviewing https://github.com/snapcore/snapcraft/pull/1568 ?
<mup> PR snapcraft#1568: lxd: don't re-inject the same snaps <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1568>
<sergiusens> popey that should solve your issue ^
<mup> Issue snapcraft#1475 closed: rust plugin recording <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1475>
<mup> PR snapcraft#1562 closed: Record rust versions <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1562>
<mup> PR snapcraft#1575 closed: added git for '{version: git}' usage <Created by jdxcode> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1575>
<cprov> ogra_: you may check your remote/pukeys with that previous surl command and `| jq '.account_keys'`, but your private keys should be on your disk (or gone if `snapcraft keys` is not able to detect them)
<ogra_> cprov, meanwhile pedronis was here and handed me a curl command :)
<cprov> ogra_: not sure how it would solve your lost keys, but fine ;-)
<ogra_> well, he gave me the direct curl call to check if a key is on the server
<mup> PR snapcraft#1515 closed:  tests: use a fake pip, instead of mocking everything <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1515>
<mup> PR snapcraft#1576 opened: docker: add the environment variable to setup core <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1576>
#snappy 2017-09-29
<mup> PR snapd#3941 closed: overlord/snapstate: prefer a smaller corner case for doing the wrong thing <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3941>
<mup> PR snapd#3987 closed: packaging/fedora: Add Fedora 26, 27, and Rawhide symlinks <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3987>
<mup> PR snapd#3974 closed: Recognise Solus as a classic Linux distribution <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3974>
<mup> PR snapd#3975 closed: snap-confine: Only attempt to copy/mount NVIDIA libs when NVIDIA is used <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3975>
<mup> PR snapd#3988 opened: Added note in HACKING file  <Created by rmescandon> <https://github.com/snapcore/snapd/pull/3988>
<mup> PR snapcraft#1577 opened: lxd: don't inject local snaps on a different arch <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1577>
<mup> PR snapd#3977 closed: interfaces: Enhance full-confinement support for biarch distributions <Created by ikeydoherty> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3977>
<mup> PR snapd#3989 opened: client, daemon: rest api to configure store api <Created by atomatt> <https://github.com/snapcore/snapd/pull/3989>
<mup> PR snapd#3990 opened: cli: configure/revert store <Created by atomatt> <https://github.com/snapcore/snapd/pull/3990>
<ogra_> cachio, https://code.launchpad.net/~snappy-dev/core-snap/trunk
<ogra_> cachio, lp-build-core and the README for it are in the cron-scripts subdir
<kyrofa> nessita, are you in IRC?
<nessita> kyrofa, I am!
<coreycb> hi all, is there a way to find out who registered the gnocchi snap name? i'm getting a store upload failure for it.
<kyrofa> coreycb, are you sure it's registered, or simply reserved?
<ogra_> cachio, so ignore the above branch, the right one is  https://github.com/snapcore/core/tree/master/cron-scripts
<coreycb> kyrofa: i'm not sure
<kyrofa> nessita, you guys have worked out snap renames to be an easier process, is that right?
<kyrofa> coreycb, one moment
<kyrofa> nessita, if I rename snap A to B, what happens to those who have A installed?
<kyrofa> coreycb, there's no gnocchi in any channel, so I suspect it's simply reserved. Although it's possible that someone has registered it and uploaded nothing
<coreycb> kyrofa: ok, thanks for checking. is there a way to see who registered it?
<kyrofa> coreycb, not other than talking to the store folks
<kyrofa> coreycb, if something had been published you could use `snap info`, but without that, it's only available to the store
<coreycb> kyrofa: alrighty thanks
<jdstrand> zyga-ubuntu: hey, we've been missing each other. I saw your requests for review on 3963 and 3973. I haven't had time to do an in depth review of either, but on my list for next week
<zyga-ubuntu> jdstrand: hey
<zyga-ubuntu> jdstrand: thank you, I understand you are busy this week
<zyga-ubuntu> jdstrand: I hope you had a chance to discuss user mount namespaces
<zyga-ubuntu> jdstrand: and other aspects that will help to implement various features next week
<zyga-ubuntu> jdstrand: thank you for the note :)
<jdstrand> zyga-ubuntu: we did a bit, yes. I think jhenstridge is going to continue on the current path for his PoC, then see discuss with us the end (blackboxed) result and how that would impact the layouts feature. iterate on that and then when happy with the end result, discuss the correct implementation for him to take, then he'll make a proper PR
<zyga-ubuntu> jdstrand: thank you for sharing that, I was wondering what's the likely outcome of the current PR
<nessita> kyrofa, we have no support for snap renames
<nessita> kyrofa, what we can offer easily is snap owner transfer
<kyrofa> nessita, huh, maybe it was owner transfer
<kyrofa> Ah, yeah
<kyrofa> nessita, I'm getting old :(
<nessita> kyrofa, yeah :-)
<nessita> we both!
<kyrofa> Hahaha
<kyrofa> nessita, ignore me then!
<nessita> ack!
<kyrofa> Thanks for your time :)
 * zyga-ubuntu supper
<__chip__> cjwatson: jdstrand: bug report filed. And it's a prime number.
<__chip__> the omen is clear
<mup> PR snapcraft#1578 opened: project_loader: quote more environment variable values <Created by malept> <https://github.com/snapcore/snapcraft/pull/1578>
<apol> kyrofa: ping?
<kyrofa> cratliff, https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201
<cachio> mvo, https://paste.ubuntu.com/25640466/
<apol> kyrofa: https://github.com/snapcore/snapcraft/pull/1579
<mup> PR snapcraft#1579: Make it possible to use the cmake ninja generator <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1579>
<kyrofa> apol, awesome, thank you!
<mup> PR snapcraft#1579 opened: Make it possible to use the cmake ninja generator <Created by aleixpol> <https://github.com/snapcore/snapcraft/pull/1579>
<kalikiana_> \o
<kyrofa> ogra_, I'm super confused by your response to https://forum.snapcraft.io/t/bug-with-cleaning-snap-data-in-home-dirs-proposed-solution/1201/12 :P
<kyrofa> ogra_, each core updates moves the content forward?
<ogra_> kyrofa, well, my /root dir at home started that thread
<ogra_> and an update of core should definitely migrate data forward
<ogra_> as well as a removal of core should remove the data alongside
<ogra_> so if you have 120 core subdirs there, only the last three should actually have content
<ogra_> the rest are just leftover empty dirs
<ogra_> if thats not the case we have a more serious bug
<kyrofa> ogra_, definitely not the case
<ogra_> bug then
<ogra_> raise that on the forum thread too please
<kyrofa> ogra_, done
<ogra_> yep, seen :D
<kyrofa> ogra_, so to be clear: you're saying every time core updates, it tries to clean those dirs for all snaps?
<ogra_> kyrofa, no, there should always be only three installs of any snap ... if core updates that means a new core gets installed, data gets migrated forward and the oldest snap gets removed ... on removal the dirs should be cleared
<kyrofa> ogra_, note that I'm not talking about core, but a ROS app snap
<ogra_> kyrofa, /root is a bit special here but i'm told by the guys sitting to my left that there is a PR that fixes this
<kyrofa> ogra_, SNAP_USER_DATA is fine as long as it's /home/. But /root/ is broken
<kyrofa> Yes indeed, exactly
<ogra_> right, it shouldnt matter what snap it is
<kyrofa> Yes, /home-based SNAP_USER_DATA is fine
<ogra_> well, /root will be treated the same
<ogra_> existing data will be migrated forward to the newer subdir, the oldest sudbdir (current - 3) should be removed
<ogra_> so that you only ever have 3 dirs there and the latest always has the latest set of content
<kyrofa> ogra_, it SHOULD be ;)
<mup> PR snapd#3986 closed: wrappers: fail install if exec-line cannot be re-writen <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3986>
<mup> PR snapd#3991 opened:  wrappers: fail install if exec-line cannot be re-write <Created by mvo5> <https://github.com/snapcore/snapd/pull/3991>
<ogra_> kyrofa, right, the PR will fix that ... as soon as the guys next to me are done with pushing the blame for not revieweing back and forth :P
<nacc> lol
 * nacc can picture it
<mup> PR snapd#3992 opened: asserts: add cross-checking for snap-build <Created by pedronis> <https://github.com/snapcore/snapd/pull/3992>
<apol> anyone konws what's the status of this bug? https://bugs.launchpad.net/snappy/+bug/1588192
<mup> Bug #1588192: GL interfaces seem wedged for Krita on nvidia <patch> <Snappy:In Progress> <nvidia-graphics-drivers-304 (Ubuntu):In Progress by albertomilone> <nvidia-graphics-drivers-340 (Ubuntu):Won't Fix by albertomilone> <nvidia-graphics-drivers-361 (Ubuntu):Won't Fix by albertomilone>
<mup> <nvidia-graphics-drivers-304 (Ubuntu Xenial):In Progress by albertomilone> <nvidia-graphics-drivers-340 (Ubuntu Xenial):Won't Fix by albertomilone> <nvidia-graphics-drivers-361 (Ubuntu Xenial):Won't Fix by albertomilone> <https://launchpad.net/bugs/1588192>
<mup> PR snapd#3983 closed: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3983>
<mup> PR snapd#3993 opened: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <https://github.com/snapcore/snapd/pull/3993>
<mup> PR snapd#3994 opened: tests: fix revert test when a new core image is on current channel <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3994>
<mup> PR snapd#3922 closed: snapstate: deal with snap user data in the /root/ directory <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3922>
<mup> PR snapcraft#1580 opened: cli: setup gitignore when working from git directory at init <Created by msis> <https://github.com/snapcore/snapcraft/pull/1580>
<nacc> given the perspective that cleanbuild is the 'only' safe way to ensure proper development of a snap, it feels like it should take options like other tools do (preserve build env on failure), only do stage, only build some specific part, etc.
<nacc> is that on the roadmap?
<nacc> sergiusens: --^
#snappy 2017-09-30
<mup> PR snapd#3995 opened: snap: support "command: foo $ENV_STRING" <Created by mvo5> <https://github.com/snapcore/snapd/pull/3995>
<mup> PR snapd#3935 closed: cmd/snap-repair: implement the repair run loop <Created by pedronis> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3935>
<sergiusens> nacc it is
<sergiusens> well, it is sort of already there, it is a different mode of operation
<diddledan> not sure where the problem lies, but on 17.10 icons for installed desktop snaps aren't appearing in the dash
<mup> PR snapcraft#1576 closed: docker: add the environment variable to setup core <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1576>
#snappy 2017-10-01
<om26er> So apparently build.snapcraft chickens out for me. When I try to add a repo, the 'Add' button keeps spinning forever and nothing happens.
#snappy 2018-09-24
<mup> PR snapd#5851 closed: tests: don't fail interfaces-bluez test if bluez is already installed <Created by plars> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5851>
<mborzecki> morning
<mvo> mborzecki: hey, good morning
<mborzecki> mvo: hey hey, how was your trip back?
<mvo> mborzecki: hey, it was mostly good, one train was super delayed but fortunately I found  an alternative so no harm done
<mborzecki> mvo: nice
<mvo> mborzecki: and you? had a good trip as well?
<mborzecki> mvo: yup, no hiccups, though i got home around midnight
<mvo> mborzecki: nice
<mup> PR snapd#5847 closed: overlord/snapstate: improve cleaup in mount-snap handler <Parallel installs> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5847>
<mup> PR snapd#5809 closed: tests: using single sh snap in interface tests <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5809>
<mborzecki> 40 PRs, not bad
<mup> PR snapd#5855 opened: tests: cleanup copy/paste dup in interfaces-network-setup-control <Simple> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5855>
<mup> PR snapd#5855 closed: tests: cleanup copy/paste dup in interfaces-network-setup-control <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5855>
<pstolowski> mornings
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<mup> PR snapd#5672 closed: tests: make nfs test available for more systems <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5672>
<mborzecki> mvo: have you seen this? https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/30
<mvo> mborzecki: no, let me see
<mvo> mborzecki: hm, that is a complication indeed
<mvo> mborzecki: do we considered it metered if GUESSS is set? or only if we know for sure?
<mborzecki> mvo: yes, it's both NM_METERED_YES and NM_METERED_GUESS_YES
<mborzecki> mvo: YES is only set if it was explicitly marked by the user, otherwise it's GUESS_YES
<mvo> mborzecki: aha, I see
<mborzecki> mvo: the idea of defaulting to refresh.metered=hold only on classic devices is actually quite appealing
<mvo> mborzecki: yeah, it looks like thats the best way out of this mess
<mborzecki> mvo: in the notes from friday niemeyer mentioned more strings for refresh.metered, do you recall any examples?
<mvo> mborzecki: I think there was a slight misunderstanding in that there was this notation that the old config option was a yes/no boolean
<mvo> mborzecki: but it was not iirc, it is already "" or hold
<mvo> mborzecki: iirc that were the bits we talked about
<mborzecki> mvo: ah, ok, well it's kind of 2 state now to be fair :)
<mvo> mborzecki: yeah, its boolean :) but also using mostly sensible names (not just yes/no)
 * pstolowski does the expensify. yuck
<mvo> zyga: quick question - when you did the flock to mount you mentioned that systemd did timeout on boot when the mounts are serialized. how many snaps did you had installed when trying this?
<mborzecki> mvo: left a note under #5792
<mup> PR #5792: [RFC] {config,snap}state: add new refresh.metered=force option and flip default <Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5792>
<mvo> mborzecki: ta
<Chipaca> moin moin
<Chipaca> mborzecki: wrt metered, how's it looking?
<Chipaca> reading the feedback from field, it sounds like we might want an 'auto' setting that only looks at _yes (and not _guess_yes)
<mborzecki> Chipaca: hey, some updates in the forum topic, https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/30
<Chipaca> yeap, was just reading that
<mborzecki> Chipaca: well, _yes is half solution for desktop users
<Chipaca> mborzecki: yes, otoh they're much more able to tweak it than devices out there
<mborzecki> Chipaca: we could tweak the nm wrapper to return whether the result is a guess or not and use that to pick proper default for desktop/device scenario
<zyga> Hey hey. I just want to say Iâm off today.
<Chipaca> zyga: are you sure? because you don't _look_ off
<Chipaca> mborzecki: it's looking like we'll need something like that t make erryone happy
<mborzecki> Chipaca: that and 'refresh.metered=force', you could mark the connection as metered for some other application but would stiill want snap updates
<Chipaca> mborzecki: 'force' was the 'ignore metered', right? and what was 'assume metered'?
<mvo> zyga: thanks! enjoy your time off
<zyga> Chipaca: yeah, servicing my laptop now
<zyga> See you later :-)
<Chipaca> zyga: boot your mac sometime
<mborzecki> Chipaca: there wasn't, there's 'hold' which covers yes && guess_yes, and default '' which was like ignore-metered
<Chipaca> zyga: ah you already have, thanks :-D
<Chipaca> â¦ wait no it's dead
<Chipaca> drat
<Chipaca> mborzecki: we need to map out scenarios
<Chipaca> mborzecki: i think
<kyrofa> Chipaca, buy your own mac! popey might be able to help as well
<popey> wat wat
<Chipaca> kyrofa: I possess one of AFAIK 2 canonical-owned macs!
<Chipaca> kyrofa: alas it's too old to be useful at this point
<popey> I have a macbook air if needed
<kyrofa> Chipaca, yeah I have one of the first intel ones, I know what you mean
<Chipaca> popey: good to know in case something urgent comes up; zyga has a lab I can ssh into for a bunch of different things and his mac is just one of 'em, and I thought I'd test https://github.com/sergiusens/homebrew-snapcraft on it ahead of Sergio, but it's not urgent at all
<popey> kk.
<Chipaca> I tested it using linuxbrew, which is probably good enough for now :-)
<popey> Chipaca: i know you love terminals. Did you know on a bare tty, the tickmark next to a verified snap is a green diamond?
<Chipaca> popey: yes
<popey> ok
<Chipaca> popey: I thought that wasn't too bad
<Chipaca> popey: I'm open to being wrong though
<popey> I haven't investigated the alternatives. I expect you're right.
<Chipaca> popey: add --unicode=never to see if it'd be better with "linux terminals don't do unicode"
<popey> a green asterisk
<popey> I am honestly not sure which I prefer.
<zyga> Chipaca: Iâll boot it in 30 min
<popey> wonder what it would look like on this bad boy... https://www.ebay.co.uk/itm/WANG-Computer-WANG-Terminal-Model-2246-Computer-IBM-XT-AT-DEC-SPERRY/113221449456
<popey> so tempted
<zyga> Returning home from apple support shop
<Chipaca> popey: eww, AZERTY
<ogra> diamonds are forever, stay with it !
<mup> PR snapd#5823 closed: snapcraft.yaml: add workaround for LP:#1791871 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5823>
<Chipaca> popey: also: it'd be cheaper, easier and more reliable to take a too-old-to-be-useful laptop and use it to boot linux as a dumb serial terminal
<Chipaca> popey: OTOH, not as cool
<Chipaca> and this wasn't ever about cheap, easy, nor reliable :-)
<popey> May I point you at my ThinkPad X61S running Ubuntu Core :D
<popeycore> That's me! :D
<Chipaca> popeycore: you can point all you want, but my virtual reality irc headset isn't working to see where you're pointing at
<Chipaca> mvo: can we refresh go-flags, or was ppc bocking that?
<mvo> Chipaca: lets try it
<mvo> Chipaca: if it needs an updated sys/unix we are in trouble
<Chipaca> mvo: some nice fixes landed over the weekend
<Chipaca> mvo: if you look at 'man snap', and search for '^ *info', you'll see a bug
<Chipaca> that's fixed :-)
<Chipaca> mvo: it does not depend on sys/unix
<Chipaca> its unit tests no longer work with 1.6, alas, but that's another issue
<Chipaca> (easy to distro-patch a fix if needed)
<Chipaca> (and what we currently use has the same issue afaik)
<mvo> Chipaca: "easy" ;)
<mvo> Chipaca: but yeah
<Chipaca> souper easy
<Chipaca> :-)
<mvo> Chipaca: it will be a small pain for the debian downstream
<Chipaca> mvo: are they still on 1.6?
<Chipaca> 1.7 works
<mvo> Chipaca: oh, right, sorry
<mvo> Chipaca: of course not
<Chipaca> phew
<mvo> Chipaca: so hopefully no problem for anyone except us
<mvo> Chipaca: and we don't run the unit tests of it so â¦
<Chipaca> hehe
<Chipaca> mvo: if we vendor it, we're fine
<mvo> Chipaca: yeah, we do
<mborzecki> Chipaca: mvo: how does this sound? https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/32
<Chipaca> mborzecki: terrible, awful, it's the worst thing to ever be put up on the internet, and it's all the wrong colour
<mborzecki> hahaha
<Chipaca> mborzecki: maybe I should click the link
<mborzecki> anyone using discord under KDE?
<zyga> Chipaca: re
<zyga> Chipaca: do you need access now?
<popey> mborzecki: i am
<Chipaca> zyga: I could use it, i dont need it
<zyga> Chipaca: try now
<zyga> it should be up
 * zyga just rented the house for TV production on Wednesday 
<Chipaca> zyga: computer says yes
<zyga> whee
<zyga> Chipaca: FYI today is the day when a new macOS is available, you can try now and then later when I upgrade
<Chipaca> zyga: didn't you have homebrew installed?
<zyga> Chipaca: I think the next OS doesn't leave any old apps behind so you can reasonably expect everyone to be using this version soon
<zyga> Chipaca: no, I didn't
<zyga> Chipaca: want me to install it?
<zyga> Chipaca: I have go installed
<Chipaca> zyga: I should be able to do it myself without sudo even
<zyga> but not homebrew
<zyga> Chipaca: cool, let me know if you need anything
<Chipaca> zyga: hmm, it's asking me for sudo to do thinks in /usr/local. It seems doing it in my home needs more options. Which would you rather I do?
<zyga> Chipaca: just use sudo
<zyga> I gave you access
 * zyga hugs and trusts Chipaca with his main computer :)
 * Chipaca accepts the hug, and trusts the brew people for this
<mborzecki> damn, desktop files are a mess
<zyga> Chipaca: there's an update to command line tools for Xcode (aka the toolchain)
<zyga> Chipaca: shall I ignore that for the duration of your experiments?
<Chipaca> zyga: yes please
<zyga> ok
<Chipaca> zyga: now you have more go than before!
<niemeyer> Hellos o/
<pstolowski> hey niemeyer!
<Chipaca> zyga: done
<Chipaca> zyga: what's the difference between today's update and before? so I can write "tested with _____"
<mvo> niemeyer: hey! how are you? good trip back?
<zyga> Chipaca: today is macOS high sierra
<zyga> Chipaca: tomorrow is macOS Mojave
<zyga> hey mvo, niemeyer
 * zyga is off b
<niemeyer> mvo: Yeah, that was surprisingly easy :)
<zyga> but apparently terrible at it :)
<niemeyer> Was lucky enough to get out of the plane and straight into the bus
<zyga> though I really want to take a nap, sleeping with two kids and a dog in one bed is ... not perfect
<niemeyer> I was home in no time
<zyga> niemeyer: nice change, right? :)
<niemeyer> zyga: 8)
<mvo> niemeyer: nice!
<Chipaca> currently "snap interface"'s help says "List snap interfaces" and "snap interfaces"' help says "List interfaces in the system"
<Chipaca> would "Show details of snap interfaces" and "List interface slots and plugs in the system" be better and more accurate?
<Chipaca> niemeyer: zyga: ^
<niemeyer> Chipaca: +1
<niemeyer> Chipaca: First one should probably be singular
<niemeyer> ... of snap interface
<Chipaca> niemeyer: if you just do "snap interface" it lists them all though
<zyga> yeah, that's a nice change
<niemeyer> Chipaca: while the second should be plural
<niemeyer> List interfaces ...
<zyga> Chipaca: all instantiated and connected
<niemeyer> Ah, no.. slots and plugs
<zyga> aaah
 * zyga runs and tries to be off
<Chipaca> zyga: which were you adding to there
<niemeyer> Chipaca: Ah, interesting
<Chipaca> niemeyer: Â¯\_(ã)_/Â¯
<Chipaca> trying to make it less interesting :-)
<niemeyer> Chipaca: +1 either way :)
<Chipaca> "List interfaces' slots and plugs" works too
<Chipaca> but then we get the dreaded "plural possessive" discussion
<Chipaca> :-)
<Chipaca> I blame degville
<mup> PR snapcraft#2289 opened: local source: only filter out snapcraft artifacts <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2289>
<mup> PR snapd#5856 opened: cmd/snap: tame the help zoo <Created by chipaca> <https://github.com/snapcore/snapd/pull/5856>
<Chipaca> niemeyer: can you make it so I can request a review from degville? (currently I can't)
<niemeyer> Hmm, I guess he's not in the org yet
<degville> I  am looking through though - how about `List slots and plugs for all interfaces' as an alternative?
<Chipaca> degville: if you could say so on the PR, then we can keep tabs on it all
<degville> Chipaca: will do.
<Chipaca> degville: thanks
<Chipaca> I expect "Admin" to be contentious, just didn't find anything better and thought it best to just push it and see
<niemeyer> Chipaca: Done
<niemeyer> degville: You should have received an invite
<degville> niemeyer: got it, thanks.
<mvo> Chipaca: I reworked 5717 a bit with gustavos input in mind, would be great if you could have another look to see if looks sane. it will unblock two more PRs
 * Chipaca is afk, punching trees
<Chipaca> j/k. Looking.
<mvo> ta
<Chipaca> mvo: q: why can't one do GET things in degraded mode?
<mvo> Chipaca: I was simply conservative, happy to allow that
<Chipaca> mvo: I'd just make it degraded -> nothing but GET
<Chipaca> mvo: but I don't know if there are exceptions that would warrant the flag
<Chipaca> I don't _think_ so :-)
<Chipaca> by definition, GET should not be writing state
<mvo> Chipaca: lets say YAGNI and I will just allow get and we add the flag again when we need it?
<Chipaca> and we never have bugs
<Chipaca> so, \o/
<Chipaca> mvo: sgtm!
<Chipaca> mvo: less flags -> less code -> less bugs
<Chipaca> huzzah
<mvo> !!!
 * mvo goes and makes it so
<mup> PR snapd#5857 opened: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
 * Chipaca ~> lunch break
<mborzecki> off to pick up the kids
<mborzecki> Chipaca: can you check what's the value of XDG_CURRENT_DESKTOP in your env?
<Chipaca> mborzecki: my EAAS costs are 2Â¢ per request, and .5Â¢ per byte response
<mborzecki> Chipaca: EAAS - env as a service? :)
<Chipaca> mborzecki: your request was: $XDG_CURRENT_DESKTOP
<Chipaca> mborzecki: your response is: "Unity"
<mborzecki> Chipaca: ooh, that's 16.04?
<Chipaca> mborzecki: you account is now overdrawn by 2.3Â¢
<Chipaca> I think there's a bug in my accounting software
<Chipaca> mborzecki: yes :-)
<mborzecki> Chipaca: i'm sure i can expense it to canonical :D
<Chipaca> mborzecki: why?
<Chipaca> how did you get from "Unity" to "16.04"?
<mborzecki> Chipaca: i figured it would be GNOME on 18.04
<mborzecki> mvo: are you on 18.04 by any chance?
<Chipaca> mborzecki: I have that on my tablet downstairs, I think (haven't turned it on in a couple of months now)
<Chipaca> grmbl grmbl kernel broke the touchscreen grmbl
<mborzecki> Chipaca: pieces of autostart handling look at XDG_CURRENT_DESKTOP when deciding if the app should be started, I wonder if GNOME specific settings should be applied under unity too
<Chipaca> mborzecki: making that desktop-dependent will probably confuse app devs more than not
<Chipaca> unless they're _wanting_ it to not autostart on non-gnome (or bicerveza)
<mborzecki> Chipaca: discord sets X-GNOME-Autostart-enabled atm, don't know what they set for unity though
<Chipaca> installing discord...
<Chipaca> mborzecki: in what file do they set that?
<Chipaca> mborzecki: the option to autostart defaults to enabled, and grep finds no X-GNOME-Autostart
<Chipaca> mborzecki: but I also find no desktop file under ~/snap/discord
<Chipaca> so â¦ dunno what I'm looking for
<mvo> mborzecki: I'm on 18.04 - yes
<Chipaca> mborzecki: haha, I disabled it, and it created the file
<Son_Goku> mvo, zyga, so I'm currently working on compilation failures with snapd on el7
<Chipaca> mborzecki: so it looks like they have a bug :-)
<Son_Goku> seems like there's a bad interaction with partial static linking now :(
<Chipaca> mborzecki: and they do create the file, with X-GNOME-Autostart-enabled=false in it
<Chipaca> Son_Goku: nobody uses e17 anyway
<Son_Goku> Chipaca: hah definitely no one uses e17
<Son_Goku> at least, I hope not
<Chipaca> (I seriously read that the first time and did a double-take)
<Son_Goku> :D
<Son_Goku> mvo, as you're aware, parts of snapd's go code is statically linked to support bases properly
<Son_Goku> so I'm trying to figure out how things are blowing up
<mup> PR snapd#5854 closed: interfaces/docker-support: add rules to read apparmor macros <Created by anonymouse64> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/5854>
<Chipaca> popey: discord snap has a bug, fwiw, want a irc rantoid, or a github issue?
<popey> pull request pls :D
<popey> https://github.com/snapcrafters/discord
<popey> issue is fine
<mborzecki> Chipaca: yeah, the file is dropped only when you tigger the radio button :/
<Chipaca> popey: https://github.com/snapcrafters/discord/issues/46 fwiw
<popey> <3
<mborzecki> popey: would you like a PR with autostart desktop file support too? :)
<popey> PR's are always welcome :)
<popey> Also, I have a bug for you guys :)
<popey> snap install something --edge, then replace it with snap install ./something --dangerous
<popey> snap list says x1 edge, as if I am tracking edge, even though I am now on a local install
<mup> PR snapcraft#2290 opened: pluginhandler: update build should overwrite organize <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2290>
<Chipaca> popey: not sure that's a bug, exactly
<Chipaca> popey: snap install ./something --dangerous  and tehn  snap switch --edge something  works
<popey> surely if i install something locally, I should stop tracking the store?
<Chipaca> popey: you can then do 'snap amend'
<Chipaca> niemeyer: I could hear _something_ in the background, but thought it was just aggressive audio compression
<niemeyer> Chipaca: Cool, so not enough to be a nuisance
<Chipaca> popey: er, i meant 'snap refresh --amend'
<Chipaca> niemeyer: unless you're degville
<Chipaca> :-D
<Chipaca> niemeyer: what do you think? should "snap install ./something" when you already have 'something' installed break the 'tracking' relationship?
<Chipaca> actually
<niemeyer> Chipaca: Isn't that the case already?
<Chipaca> maybe 'snap install --dangerous' should refuse to work if you have an installed something
<Chipaca> yeah, that sounds like what should happen
<Chipaca> niemeyer: nope, you can have a local snap tracking the store
<Chipaca> niemeyer: ("snap switch" works on local snaps)
<niemeyer> Chipaca: That's a bit awkward..
<Chipaca> niemeyer: you then can use "snap refresh --amend"
<niemeyer> Chipaca: I don't think it should work, and my memories are that it didn't
<niemeyer> Chipaca: Ah, okay, so it won't refresh until that takes place?
<Chipaca> refreshes are blocked, yes
<niemeyer> Cool, ok
<Chipaca> it's a bit weird
<Chipaca> but in any case, we probably want to block the asserted -> unasserted install
<Chipaca> unasserted -> unasserted is fine, used for dev all the time
<Chipaca> unasserted -> asserted also fine i think
<Chipaca> asserted -> unasserted, you're trying to do something you shouldn't
<Chipaca> (otoh you did say --dangerous)
<Chipaca> Â¯\_(ã)_/Â¯ dunno, send help
 * Chipaca goes to the gym
<niemeyer> Chipaca: Yeah, not sure.. we need to think about the actual issues on these cases
<Chipaca> thinking is hard
 * Chipaca aborted the gym trip, gets back to work
<niemeyer> Chipaca: gym is harder? :P
<Chipaca> niemeyer: it's going to be rough :-) but nah, i just missed my window
<stokachu> i had ot make adjustments in how we built conjure-up, now juju/jujud aren't being included in the snap
<stokachu> https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml
<stokachu> so not sure what im missing here now
<stokachu> this is came about b/c we're now forced to move our snap specific wrapper scripts outside of snap dir
<stokachu> sergiusens, ^
<sergiusens> stokachu: did I not propose a PR?
<stokachu> sergiusens, nah
<sergiusens> I just landed now, so I think I will ask kyrofa to look at your repo
<stokachu> ok thanks
<stokachu> cory_fu, with charmtools had to do something similar wrt the snap/wrappers die
<stokachu> dir*
<stokachu> kyrofa, the workaround i have in there for the wrapper scripts work now, but juju/jujud isn't being included in the snap anymore
<stokachu> would like to not have to use the workaround with snapcraftctl prime though
<cory_fu> stokachu: I think the reason juju's not being included is that you don't call `snapcraftctl build` at the top of the override-build section
<stokachu> ah
<stokachu> cory_fu, good catch
<stokachu> rebuilding now to see
<cory_fu> stokachu, kyrofa, sergiusens: I would really like to know of a better way to manage the wrappers, because having to use override sections is messy
<cory_fu> Originally tried to use dump plugin parts but could never get the paths to work out correctly
<cory_fu> It was particularly frustrating because the pwd seemed to change depending on whether an override section was present or not
<stokachu> snapstore seems down too, Store upload failed: ('Connection aborted.', gaierror(-3, 'Temporary failure in name resolution'))
<stokachu> that's from launchpad
<cjwatson> no, that's a SUPER WEIRD problem on one of the Launchpad script servers, not a store problem
<kyrofa> cory_fu, stokachu, why not create a new part for the wrappers instead of trying to do it from an unrelated part?
<kyrofa> Hard-coding paths like that isn't stable
<cory_fu> kyrofa: Tried that originally and couldn't get it to work.
<stokachu> that's what we had originally
<cory_fu> kyrofa: First issue we hit was the change from things not being allowed in the snap directory anymore.  Even once we moved it out of there, though, for charm-tools at least, I couldn't get it to include the file in the built snap properly.
<stokachu> cjwatson, ah ok
<stokachu> cjwatson, it looks like it was uploaded?
<stokachu> im getting a different error now
<stokachu> binary_sha3_384: A file with this exact same content has already been uploaded
<cjwatson> stokachu: Yeah, unfortunately some errors aren't currently retryable sensibly (we have a plan but it's not implemented yet), so in this situation you have to rebuild
<stokachu> cjwatson, ok cool, np
<cjwatson> And the worker in question hasn't been restarted, so there's a 1/3 failure chance
<cjwatson> It is really very mysterious
<stokachu> :D
<kyrofa> cory_fu, which file exactly seems to not make it?
<cory_fu> kyrofa: For charm-tools, there's one wrapper in https://github.com/juju/charm-tools/tree/master/helpers/snap-wrappers and I was trying to get it into bin/wrappers/
<cory_fu> Seems like it should be pretty straightforward, but I tried for a long time to get it to work
<kyrofa> cory_fu, hoo boy is this a hefty snap. I'll make a PR shortly
<cory_fu> kyrofa: Thanks!
<kyrofa> cory_fu, https://github.com/juju/charm-tools/pull/449
<mup> PR juju/charm-tools#449: snapcraft.yaml: add new part for wrappers <Created by kyrofa> <https://github.com/juju/charm-tools/pull/449>
<ogra> you call that a hefty snap ? you havent seen the gimp snap yet, have you ? :)
<kyrofa> ogra, not in size, in build time
<kyrofa> ogra, but yes I'll admit: I haven't messed with the gimp snap
<ogra> oh, seems popey or diddledan have cleaned it up ... last time i looked the snapcraft.yal had 1800 lines !
<ogra> *yaml
<diddledan> yeah, moving to core18 allowed a LOT of dependency trimming
<cory_fu> kyrofa: So that's going to hit the the issue that originally started all of this, which was the dump plugin failing with a "part modified" error.  We worked around this at first by adding "source-type: git" but then that had path issues or something.  I know there was a snapcraft fix for that, but I don't know if it's available on the LP builders now?
<ogra> yeah, it was a bit like a novel before
<ogra> missing chapters though
<kyrofa> cory_fu, you got "part modified" because you were using the snap dir
<cory_fu> kyrofa: Oooh
<diddledan> I believe reading it in it's entirety would have opened up a portal to hell
<ogra> lol
<ogra> necronomicon.yaml
<kyrofa> cory_fu, snapcraft makes the assumption that it owns the snap/ dir (we'll ignore the fact that this assumption wasn't at all well-communicated). It writes caches into it, and so on. Then if you say `source: snap/` it picks up the changes it wrote itself as source changes
<cory_fu> kyrofa: Hrm.  But we originally got the "part modified" error on the versions part, which is why we have the source-type in it still
<diddledan> halloween just around the corner, too ;-p
<ogra> heh
<cory_fu> kyrofa: And that doesn't touch the snap dir
<diddledan> I really don't get why folk want to put random stuff in ./snap/
<ogra> yeah, i' also always surprised
<ogra> *i'm
<cory_fu> kyrofa: Although, maybe I'm confusing multiple bugs, because there was also this: https://github.com/juju/charm-tools/pull/445
<mup> PR juju/charm-tools#445: Fix version causing build signature issues <Created by johnsca> <Merged by johnsca> <https://github.com/juju/charm-tools/pull/445>
<kyrofa> cory_fu, certain git commands can update the timestamp of the .git directory as well, which can trigger that behavior
<diddledan> looking at you, vscode!
<kyrofa> Yeah vscode does it, intellij does it, and git describe does it, I think
<diddledan> I "fixed" the alsa remote part by specifying a source even though I'm using `plugin: nil`
<cory_fu> kyrofa: Yeah, we did originally have "source: snap/" in the versions part, so that's what it was
<kyrofa> Ah, yeah there you go
<cory_fu> kyrofa: Would you mind terribly also removing the source-type line from the versions part in your PR?
<kyrofa> cory_fu, we're trying to make that a little more friendly, but if you want to be absolutely safe just leave the snap dir alone except for stuff that is supposed to go in there (hooks, plugins, snapcraft.yaml, desktop files, etc.)
<kyrofa> Sure
<cory_fu> kyrofa: That makes perfect sense.
<kyrofa> cory_fu, want me to squash?
<cory_fu> kyrofa: I'll squash when I merge it.
<cory_fu> kyrofa: But either wya
<kyrofa> Done
<kyrofa> Alright, it's 2030 here, I'm off. Have a good rest of the day, folks!
<cory_fu> kyrofa: Have a good evening.  o/
<cory_fu> I just noticed that the previous build of the charm snap failed to to release and I have no idea why.  I don't see anything in the log: https://launchpadlibrarian.net/389460316/buildlog_snap_ubuntu_xenial_amd64_681cc7a9b635a1e50b11af9067b472ad-xenial_BUILDING.txt.gz
<popey> " Store upload failed: [Errno 12] Cannot allocate memory "
<popey> one for w_grant or c_jwatson
<cory_fu> popey: Thanks.  It looks like the latest build released fine
<joelkraehemann> hi all
<joelkraehemann> https://snapcraft.io/nongnu-gsequencer/listing
<joelkraehemann> ^^ I am new to snapcraft
<joelkraehemann> how does the review process complete?
<joelkraehemann> Error: The provided video url does not match any of the currently supported services.
#snappy 2018-09-25
<mborzecki> morning
<zyga> good morning
<zyga> o/ mvo
<zyga> how are you feeling?
<mvo> zyga: good morning! much better, thank you
<mborzecki> zyga: mvo: hey
<zyga> hmm
<zyga> on cosmic snaps seem to be broken?
<zyga> zyga@fyke:~$ canonical-livepatch
<zyga> 2018/09/25 08:19:08 error executing : open /var/snap/canonical-livepatch/42/livepatchd.err: permission denied
<mvo> mborzecki: hey
<mvo> zyga: all snaps?
<zyga> ah, no it's just. a bug in canonical-livepatch
<mvo> zyga: this sounds like its time for 18.10 in CI now that we are in beta freeze
<mvo> zyga: aha, just c-l ok
<zyga> canonical-livepatch uses wrong permission for status file https://www.irccloud.com/pastebin/asnxhatD/
 * zyga wonders where to report bug on canonical-livepatch
<zyga> ok, bug reported
<mup> PR snapd#5858 opened: Skip unsupported architectures for fedora-base-smoke test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5858>
<zyga> mvo: review on https://github.com/snapcore/snapd/pull/5845
<mup> PR #5845: interface: add new dotfiles interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/5845>
<zyga> brb, too cold, need more clothing
<zyga> re
<mvo> zyga: cool, thank you, I have a look
<pstolowski> mornings
<mborzecki> pstolowski: heya
<mup> PR snapd#5832 closed: [RFC] overlord/{snapstate,assertstate}: parallel instances and refresh validation <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5832>
<zyga> hey pawel
<kyrofa> zyga, those chilly mornings are the best
<zyga> kyrofa: best to get ill? :-)
<zyga> or are you serious
<zyga> my hands are freezing
<kyrofa> Hahaha, I'm serious, I love it when it's cold and I need to bundle up all cozy
<zyga> kyrofa: do you type with your gloves on or do you just have warm hands anyway?
<zyga> kyrofa: it's not freezing yet
<zyga> it just feels like proper autumn already
<kyrofa> zyga, yeah not gonna lie, it's probably 60-something here and I'm working outside
<kyrofa> So not the same situation :P
<pstolowski> kyrofa: hey! how is the place?
<zyga> 6C in the morning (42F)
<zyga> kyrofa: tonight we will have 3C
<pstolowski> kyrofa: also, unusual to see you online that early ;)
<kyrofa> pstolowski, man, I couldn't ask for better. It's so quiet, and I have this courtyard to myself
<kyrofa> pstolowski, haha, yeah I'm not used to you guys being around either!
<zyga> kyrofa: beware of the squirrels ;)
<zyga> mborzecki: partial review on 5857
<zyga> I'll make warm tea and be back for more
<kyrofa> zyga, there are some massive bees here, that's about all I've noticed so far
<zyga> kyrofa: bees or wasps?
<mborzecki> zyga: thanks
<zyga> kyrofa: as in, do you get genuinely larger bees?
<zyga> kyrofa: or is "bee" a word for anything bee-like
 * zyga loves bees
<kyrofa> I'd say they are bees, but they may completely different. They're like half the size of my fist, and black
<kyrofa> But they're fat like a bee
<zyga> kyrofa: did I tell you I want to have bee hives?
<zyga> !!!!
<zyga> that's some bee :D
<kyrofa> I'm too busy flailing them away from me to look very closely
<mborzecki> bumblebees?
<zyga> if you can snatch a photo I would love to see those
<kyrofa> mborzecki, it's a little bigger than that, and black
<kyrofa> zyga, haha, I'll try, they tend to come out when it gets warmer
<kyrofa> zyga, actually I've always been curious about bee hives as well. Do you have room for them?
<pstolowski> kyrofa: i envy you!
<zyga> kyrofa: no, but I would like to buy some land
<zyga> kyrofa: and get properly trained to handle bees
<zyga> kyrofa: my dad and granddad had honeybees :)
<zyga> kyrofa: supposedly the best moment to start learning about them is early summer, the season ends in august and then pretty much nothing happens
<zyga> kyrofa: I subscribed to a periodical about bees; so far I know very little though
<mup> PR snapd#5858 closed: Skip unsupported architectures for fedora-base-smoke test <Simple> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5858>
<mvo> zyga: thanks for your review on the dotfiles interface  - the missing check for "." is intentional -  I was thinking we could use this for non dotfiles as well at least potentially. if something neeeds access to a specific non-dotfile in home we could use the interfaces to give it without giving the full home away
<zyga> hmmm, I would give the interface a different name then
<zyga> like file-access or folder-access?
<zyga> or user-data-access
<zyga> actually
<zyga> eyah
<zyga> user data access feels like the right name
<zyga> but I'll defer to the naming overlords ;-)
<mvo> zyga: my thinking exactly :)
 * mborzecki wonders what happens if one has networkd and NM managing different interfaces and competing for the default route
<mvo> mborzecki: good question, when NM is in charge it will setup the default routes just with different metrics
<mborzecki> mvo: yeah, would you need to manually tweak those or are the deafults non conflicting? i see the default route is using 600 here, but no clue whether that's dhcpclient's or nm's doing
<mvo> mborzecki: I have 100 for eth and 600 for wlan but my two interfaces are both managed via NM :/
<mborzecki> iirc a default 1000 if you add it by hand right?
<mvo> mborzecki: just tried with "route" and got metric:0
<mborzecki> hmm
<mborzecki> well, i guess if one has a device which uses both netword and NM you craft the setup carefully enough so that it does what your requirements say
<Chipaca> mvo: mborzecki: should I mention classic devices?
<mvo> zyga: quick brainstorm: should the dotfiles interface infere if its a file or dir from the trailing "/" ? i.e. .foo is a file and .foo/ is a dir? or too magic?
<mvo> zyga: this way I can get rid of the files/dirs attr and just use paths or something
<zyga> mvo: I strongly think this is too magic
<mvo> zyga: ok
<zyga> So either allow both or make it explicit
<mvo> zyga: in this case the validation needs to reject "foo/" for files
<mvo> zyga: but allow "foo/" for dirs
<zyga> Yes
<zyga> Well
<zyga> You kind of do clean on it already
<zyga> So either allow trailing / on dirs
<mvo> zyga: I do but you pointed out it might be confusing to disallow "foo/" on a dir
<zyga> Or always reject it and add it internally like you do now
<zyga> Right
<zyga> Because the reason for that is unclear IMO
<mvo> zyga: I will look into it but my gut feeling is to reject it because the alternative is more code
<zyga> We routinely refer to directories with /
<zyga> Ok
<zyga> As long as it is documented
<zyga> Files and directories explicitly have
<zyga> one more advantage
<zyga> If somebody uses a symlink it is not going to work
<zyga> But perhaps rightfully so
<mvo> zyga: yeah, I think thats ok, symlinks & apparmor are tricky
<mup> PR snapcraft#2291 opened: meta: put environment into runner instead of app wrapper <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2291>
<mup> PR snapcraft#2292 opened: sources: properly handle pull failures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2292>
<mup> PR snapd#5825 closed: tests: add snap install hook with base: core18 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5825>
<mvo> niemeyer: when you have a moment, a high level review of 5717 would be great. I reworked it based on your input and it will auto-retry to get out of degraded mode now
<mvo> niemeyer: this will unblock two more PRs :)
<niemeyer> mvo: Heya, looking
<mvo> niemeyer: also 5583 (without snaps stop and wait for socket) would be great but that might be more work :/
<mvo> niemeyer: (but I also addressed your input there)
<mvo> niemeyer: thanks!
<zyga> brb
<niemeyer> mvo: Sent a couple of notes on the first one
<niemeyer> mvo: Second one reviewed
<niemeyer> mvo, zyga, everyone: I'm taking the afternoon off today to recharge batteries a bit
<Chipaca> niemeyer: I was just thinking of doing the same
<Chipaca> finding it hard(er) to concentrate
<zyga> niemeyer: yeah, I needed that yesterday
<zyga> niemeyer: enjoy the remains of autumn :)
<mup> PR snapd#5859 opened: many: introduce facts, export experimental features as facts <Created by zyga> <https://github.com/snapcore/snapd/pull/5859>
<ogra> ppisati, poke ...
<Chipaca> mborzecki: yesterday I saw code of yours where you took a string like "a:b::c:d" and return []string{"a", "b", "c", "d"}; where was that?
<ppisati> ogra: poke back
<ogra> ppisati, would you be able to include the bvc4 libs in the pi2-kernel initrd ?
<ogra> *vc4
<mborzecki> Chipaca: #5857?
<mup> PR #5857: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
<ogra> ppisati, https://paste.ubuntu.com/p/v4qCGjTNrz/ would be the list
<ogra> ppisati, that makes psplash work even with the vc4-kms-v3d overlay (else it only work with vc4-fkms-v3d, but that is completely unaccelerated)
<ogra> when using vc4-kms-v3d /dev/fb0 is only created by the vc4 module ... while vc4-fkms-v3d gives you a kernel /dev/fb0 but without any acceleration
<ogra> so to have fb0 in the initrd i'd need the modules available there (and i doubt we should compile vc4 into the kernel since many headless use casess wont want it)
<ppisati> ogra: xenial or bionic? i guess both
<ogra> ppisati, yeah., likely both, i have only worked with xeinal yet though
<ppisati> ogra: if you open me an LP with the list of modules to include, i'll start working on it
<ogra> \o/
 * ogra hugs ppisati 
<ogra> ppisati, hmm, LP just against linux-raspi2 ? (since i want it in the snap)#
<ppisati> ogra: yep
<ogra> on it
<mborzecki> Chipaca: thanks for the tip
<ogra> ppisati, Bug #1794279
<mup> Bug #1794279: please include vc4 modules in pi2-kernel snap initrd <linux-raspi2 (Ubuntu):New> <https://launchpad.net/bugs/1794279>
<Chipaca> mborzecki: note you  can get megabytes into the environment before it starts to fall apart
<Chipaca> I seem to recall that 8MB in an env block was enough for execve to fail, but that might be old (32 bits?), i haven't tested the limits in this way in ages
<Chipaca> you can easily creae an env var that'll make bash crawl: FOO=$(yes)
<zyga> some of those used to be limited to ~~~ 32KB but that was long ago
<Chipaca> (killall yes when you get bored; then 'echo "$FOO"' to be more bored
<zyga> AFAIK there's no limit now
<Chipaca> zyga: xargs --show-limits thinks still thinks there is a limit
<Chipaca> ~2MB?
<Chipaca> but that's mostly for execve (which applies in this case, but the other is fun)
<ppisati> ogra: ack
<mborzecki> zyga: i wonder, when doing mount mappings for parallel installs under /var/snap/<snap>, would people expect this to have shared propagation
<Chipaca> mborzecki: note also there's bytes.FieldsFunc which would save you the conversion (but then you want a []string, so Â¯\_(ã)_/Â¯
<Chipaca> )
 * Chipaca ~> lunch, and then probably nothing but probably guitar playing and maybe minecraft with the boys and dog walking and some more guitar and early bed
<zyga> mborzecki: shared propagation is actually established as a default by snapd, we only get slave propagation though, right (because snap-confine)
<Chipaca> but, hey, maybe some irc too. ttfn.
<zyga> mborzecki: btw, I found a bug in propagation setting, something I need to investigate and fix ASAP
<zyga> mborzecki: I have a test that shows htis
<zyga> *this
<zyga> mborzecki: we can sync after standup
<mborzecki> zyga: i've extended fuse-support spread test a bit and obviously the mount point is only under the mapped hierarchy, now we've said (have we?) that _foo will be mapped under snap name, but i guess we did not promise anything about propagating mounts
<zyga> yeah
<zyga> I think that is the same bug
<mborzecki> ok, let's talk after standup
<zyga> mborzecki: https://github.com/zyga/broken-layout-migration
<zyga> mborzecki: that shows this and one more issue found last week
<mup> PR snapd#5860 opened: interfaces/houtplug: helpers and struct updates <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5860>
<sil2100> mvo: hey! Today I quickly sat down to finally see what's up with my raspi3 when running core18 on it, since I wasn't able to reproduce your original problem (the one with the invalid netplan config)
<sil2100> mvo: I wasn't able to reproduce it as console-conf was segfaulting
<sil2100> mvo: I did some debugging and ugh, it's segfaulting on probert when trying to probe for wifi
<sil2100> With the wifi module unloaded console-conf and probert all work fine
<sil2100> mvo: so apparently my raspi3 is suffering from probably the same (or very similar) issue as the dragonboard
<sil2100> mvo: so generally I'll poke mwhudson that probert seems to segfault on two different boards, I guess on two different architectures as well
<mvo> sil2100: yeah, that sounds a lot like the segfault we had on the dragon
<mvo> sil2100: did you push a debug build of probert into the image ppa?
<mborzecki> zyga: pstolowski: standup?
<joelkraehemann> hi all
<joelkraehemann> https://snapcraft.io/nongnu-gsequencer/listing
<joelkraehemann> ^^ please, do the review.
<ogra> mvo, sil2100, note that we had the same issue with core16, caused by netplan (not probert) forcefully un/reloading the wlan drivers when probing
<ogra> mvo, sil2100 there was a blacklist in netplan to avoid unloading most sdio based wlan drivers due to exactly that reason ... perhaps thats gone in 18.04 ?
<mborzecki> zyga: snappy-devel?
<zyga> mborzecki: actually, can we postpone for a sec, I need to see the stuff that my daughter asked about
<mborzecki> zyga: ok
<sil2100> ogra: oh! Good to know! I'll investigate that after lunch
<ogra> sil2100, here is an example bug (there were three or four like this) https://bugs.launchpad.net/netplan/+bug/1741910
<mup> Bug #1741910: ath6kl_sdio does not support unbinding <verification-done-xenial> <netplan:Fix Released by cyphermox> <nplan (Ubuntu):Fix Released> <nplan (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1741910>
<ogra> that black/whitelist was extremely ugly, i can imagine that cyphermox tried to replace it with some more intelligent code (which has perhaps bugs)
<zyga> mvo: no c18 meeting?
<mvo> zyga: we can have one if you want
<mvo> zyga: but I think its fine to skip given that gustavo and samuele are not around
<zyga> yeah
<zyga> let's skip
<mborzecki> 2018-09-25 13:32:01 Cannot allocate google:arch-linux-64: cannot allocate new Google server google:arch-linux-64 (sep251328-278432): cannot find ready marker in console output for google:arch-linux-64 (sep251328-278432)
<mborzecki> cachio: have you seen something like this ^^
<cachio> mborzecki, when did you get that?
<cachio> 45 minutes ago?
<mborzecki> cachio: yes
<cachio> could you please try again?
<mborzecki> ok
<cachio> otherwise I'll revert last image which I manually updated today
<cachio> mborzecki, seems to be failling in many branches
<cachio> I'll revert it
<mborzecki> ok
<mborzecki> cachio: can you debug what's wrong with the image?
<cachio> mborzecki, yes
<cachio> I'm on that
<cachio> this is already deprecated
<cachio> so arch should be up again
<cachio> mborzecki, https://paste.ubuntu.com/p/XD87JBKzxs/
<cachio> have you seen that?
<cachio> zyga, ~
<zyga> nope
<sil2100> ogra: I doubt that's it as it's segfaulting earlier, but who knows - thanks for the context o/
<ogra> sil2100, good luck anyway :)
<diddledan> random thought for the day: make snaps able to tell APT/DPKG that they "supply" the same as a debian package - the specific example I came across that would benefit me personally, a deb package depends on docker-ce deb package but I had the docker snap installed so it refused to install this other package because it thought I didn't already have docker-ce
<diddledan> obviously that only benefits debian-based distributions so we'd need an abstraction to allow the same function on rpm or other distros
<mup> PR snapd#5811 closed: tests: add test that runs snapctl with a core18 snap <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5811>
 * zyga returns for evening work
<halfbit> hi, so it seems like all of the snappy desktop applications on my system tend to hang/crash
<halfbit> like I get a window for libreoffice, but nothing is drawn in it, I can't close it, and I can't start a new one
<halfbit> same thing with the spotify snap
<zyga> halfbit: hello, that's unfortunate, sorry about that - can you tell me more about your system (output of "snap version" helps)
<halfbit> this is on a fresh install of ubuntu 18.04
<halfbit>  tburdick@jupiter î° ~ î° snap version                     î² â î² 8627 î² 11:31:33
<halfbit> snap    2.35
<halfbit> snapd   2.35
<halfbit> series  16
<halfbit> ubuntu  18.04
<halfbit> kernel  4.15.0-34-generic
<zyga> what does snap changes say?
<zyga> "snap changes"
<halfbit> error: no changes found
<zyga> hmm, ok
<zyga> what happens when you run "snap run spotify" from command line?
<halfbit> I re-installed spotify with the deb which works perfectly, let me try with libreoffice
<zyga> ok
<halfbit> ok now I'm confused
<halfbit> yeah its just working now
<halfbit> of course
<halfbit> infuriating
<zyga> perhaps it was the one-time setup that some apps are doing?
<halfbit> I have no idea
<halfbit> but its beyond frustrating to go from a working system to something where I'm mucking around with this :(
<zyga> if you want you can "snap install spotify" and see if that starts
<halfbit> yeah it started spotify and its working
<mup> PR snapcraft#2292 closed: sources: properly handle pull failures <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2292>
<halfbit> well I guess its good for now
<halfbit> I'll be back if it stops working again
<zyga> good luck
<mup> PR snapd#5717 closed: snapd: go into degraded mode when the selftest fails <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5717>
<diddledan> https://github.com/auchenberg/volkswagen
 * ogra hopes thats not a diesel
<diddledan> :-) that repo is full of win
<mup> PR snapcraft#2293 opened: build providers: use the new snapcraft: remote for multipass <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2293>
<mup> PR snapcraft#2294 opened: snap: workaround the dirty tree <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2294>
<mup> PR snapd#5861 opened: cmd/libsnap: add functions for handling facts <Created by zyga> <https://github.com/snapcore/snapd/pull/5861>
<mup> PR snapd#5862 opened: cmd: fix C formatting <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5862>
<mup> PR snapcraft#2295 opened: tests: use SNAPCRAFT_PACKAGE_TYPE everywhere <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2295>
#snappy 2018-09-26
<mborzecki> morning
<zyga> Good morning
<zyga> Cold night
<mborzecki> zyga: yeah, and hoar frost everywhere :/
<mborzecki> hm guess the store is offline atm
<mborzecki> hope it's not as bad as it sounds
<sparkiegeek> mborzecki: yeah, the store is offline right now, and we're working to get it back online
<sparkiegeek> as always, status.snapcraft.io
<mborzecki> sparkiegeek: yeah, read the note about hardware failure, ouch
<zyga> good luck sparkiegeek
<sparkiegeek> zyga: thanks!
<zyga> mborzecki: I sent some patches about facts API yesterday
<mborzecki> zyga: ack, i'm looking at libsnap-confine-private parts PR
<zyga> thanks!
<zyga> hey mvo
<mvo> zyga: hey, good morning
<pstolowski> morning!
<mborzecki> pstolowski: mvo: hey
<mvo> hey pstolowski and mborzecki
<mborzecki> silly question, but how do you revert a revert?
<pstolowski> mborzecki: refresh?
<mborzecki> pstolowski: that would poke the store which is currently down :)
<sparkiegeek> mborzecki: we're now stumbling back to life; trying to fend off the advances from all the snapds in the world :)
 * zyga does reviews
<zyga> mborzecki: you can refresh to a revision you have
<zyga> I think that is even offline
<zyga> pstolowski: doing hot plug helpers now
<pstolowski> zyga: awesome, thanks!
<kyrofa> Dang, store is dooown
<pstolowski> uh indeed
<wgrant> Store read operations are on their way back up
<mup> PR snapcraft#2296 opened: part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2296>
<wgrant> Just will be sluggish for a while as all the snapds retry.
<wgrant> Write operations are a while off yet
<kyrofa> wgrant, that's alright, read ops will get my tests passing again
<kyrofa> wgrant, sounds like you had a fun night
<kyrofa> Er. Day. Never can tell with you
<kyrofa> :P
<wgrant> For once something actually went wrong during my day
<wgrant> I think it's the first time I've ever woken someone up rather than being woken up
<kyrofa> Oh how lovely that must have been!
 * sparkiegeek is now a full pot of tea in to his woken-from-slumber
<zyga> kyrofa: woah, you're up early
<kyrofa> zyga, I'm in spain for a week
<zyga> ....
<zyga> zyga.eyesfulloftears
<zyga> have fun :)
<zyga> in BCN?
<kyrofa> zyga, a bit outside of madrid, a village called manzanares el real. I think I may come back next year with the family for a few months. I love this place
<kyrofa> zyga, roscon is in madrid this weekend, so it didn't make sense for me to fly over the atlantic multiple times
<zyga> woah, even smaller than the town I was in
<zyga> lovely :)
<kyrofa> zyga, yeah I was specifically looking for that
<sparkiegeek> specifically looking to find where zyga was?
<sparkiegeek> zyga: I think you might have a stalker
<kyrofa> Yes. Don't be jealous
<zyga> that's all right, I love kyrofa :)
<kyrofa> Yeah, see?
<kyrofa> Back at you zyga
<kyrofa> No I just wanted to experience small town spain, grocery shopping, actually living here for a little while. It's been lovely
<zyga> kyrofa: careful
<zyga> the next thing you say is "oh my god, how many years has it been already?" - except you say that in Spanish to your little Spanish speaking kids :D
<zyga> (but then it's all right because it's the best place to live)
<kyrofa> Hahahaha
<kyrofa> zyga, yeah if we come here for-- I dunno, three months-- maybe my spanish will flourish
<zyga> kyrofa: when I stayed for 6 years I was only planning on ... max ... 6 months
<kyrofa> Ha!
<kyrofa> zyga, explain something to me though, I feel rude asking anyone here
<kyrofa> Let me upload a picture first to help my question
<Chipaca> ruh-roh
<zyga> haha :-)
<zyga> right?
<mup> PR snapcraft#2297 opened: [legacy] part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2297>
<kyrofa> zyga, alright, got it. This town is small, quiet, and seemingly perfectly safe. Kids out on the street, etc. However, I swear every property resembles this one: https://pasteboard.co/HFEc6pt.jpg
<zyga> hmmm
<zyga> as in $$$ or as in fort knox?
<kyrofa> Everyone's yard is behind a serious wall with a gate
<zyga> not sure if that's the same reason
<kyrofa> Nah, not all the properties look quite as nice
<zyga> on costa brava there were lots of multi-million apartments and houses
<zyga> for rich sport stars, actors and business men
<zyga> typically behind a tall fence
<zyga> so maybe that's that
<zyga> just real madrid
<zyga> but I don't know for sure
<zyga> just ask though
<zyga> I'm sure all the locals know
<zyga> ask in a grocery store
<kyrofa> I dunno, I need to take a pic of the neighborhood I'm in. It really just feels architectural, but there must be some interesting history behind it
<Chipaca> kyrofa: one thing to note is that Spain forgot how to make houses
<Chipaca> kyrofa: during franco, everything was apartments
<zyga> kyrofa: do you speak Spanish?
 * zyga realised his earlier question about $$$ _or_ Fort Knox was a bit silly
<kyrofa> zyga, I speak enough spanish to explain that I don't speak it
<zyga> haha
<zyga> well, I hope you do better than I did
<zyga> yeah, I'd really just ask
<zyga> then translate the answer back
<zyga> (tip: kids help)
<zyga> hmm, new Vmware !
<zyga> shiny goodies
<pstolowski> zyga: looking forward to a deal/sale (black friday maybe), let me know if you spot any
<Trevinho> sergiusens: hey, but snapcraft changed the default pwd when at build stage?
<zyga> pstolowski: yeah, same here
<zyga> workstation 15 feels like the bigger win now
<zyga> highdpi fixes and what not
<zyga> fusion 11 is just "keep on rolling" from what it seems
<zyga> but I haven't played with either
<zyga> pstolowski: I _barely_ missed the free month update :/
<zyga> I got workstation 14 recently
<zyga> er
<pstolowski> zyga: ouch...
<zyga> not barely missed but barely got :/
<zyga> (ie. no update)
<zyga> very solid product still
<zyga> pstolowski: typically Vmware desktop products are 25-30% off nearly all year
<zyga> with peak around Black Friday
<wgrant> Store read APIs should be stable now
<zyga> thank you wgrant! must have been a busy morning
<zyga> pstolowski: so my best advice is to just wait
<kyrofa> Trevinho, what do you mean?
<pstolowski> zyga: yep. the standard price doesn't justify moving away from virtualbox for me, to steep
<pstolowski> *too
<zyga> pstolowski: yeah, that's understandable
<zyga> pstolowski: once you buy it once you can refresh it every few releases
<zyga> you can get the lower cost update to 15 from all the way back to 12
<zyga> pstolowski: you can also buy it without VAT
<zyga> so that's a nice change
<mvo> zyga: do you remember the kernel selftest? we have a bit of a challenge to make it work with our testsuite
<zyga> yes
<zyga> oh? tell me more please
<mvo> zyga: when enabling snapd will go into read-only mode on trusty
<mvo> zyga: until we reboot
<zyga> mmm, yeah
<mvo> zyga: we can not reboot in prepare
<mborzecki> zyga: if vmware products are 25-30% off all year, why don't they just drop the price? :)
<mvo> zyga: but we do install some snaps in prepare
<mvo> zyga: so its a bit of a catch-22
<zyga> mborzecki: marketing, magic
<mvo> zyga: :/
<zyga> mvo: can we just make the 14.04 machine prepared with the right kernel?
<mvo> zyga: also "funny" because while we need a newer kernel apparently things worked just fine with the stock 14.04 for most of our tests
<zyga> mvo: or is that unreasonable for testing?
<mvo> zyga: yeah, I think we need to do that
<zyga> stock 14.04 kernel doesn't work at all
<mvo> zyga: its slightly annoying for people who want to run local spread tests
<zyga> are you sure?
<mvo> zyga: it does not?
<zyga> I'm pretty sure not much works on 3.10 there
<mvo> zyga: let me dive deeper, so far I only looked at logs, let me login
<zyga> last time I tried apparmor was not playing
<zyga> and you would get issues on any operation
<zyga> maybe mounting worked but not much more
<zyga> mvo: also complex, maybe we should allow re-exec at least
<zyga> but ... not sure
<zyga> k
<mvo> zyga: looking now
<mvo> zyga: maybe our version check is just busted
<mvo> zyga: anyway, another fun morning puzzle
<sergiusens> Trevinho: when in pull, to changes to the part's source, when in build to the part's build dir, when in stage to the stage dir and when in prime to the prime dir. It has always been like this since introducing the override- directive
<Trevinho> sergiusens: weird since the tdesktop stopped building for some weeks now as it wasn't find a file it was before in build (with a cp)
<sergiusens> Trevinho can I see the snapcraft.yaml?
<sergiusens> And how did it break?
<Trevinho> sergiusens: failing here https://github.com/telegramdesktop/tdesktop/blob/dev/snap/snapcraft.yaml#L97
<Trevinho> sergiusens: log with some more debugging https://launchpadlibrarian.net/390331135/buildlog_snap_ubuntu_xenial_amd64_tdesktop_BUILDING.txt.gz
<Trevinho> (for sure it has always been building)
<Trevinho> but I'm fixing the path, it's indeed better to point to the actual src, but...
<Trevinho> just curious if something changed
<zyga> mborzecki: updated https://github.com/snapcore/snapd/pull/5805
<mup> PR #5805: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <https://github.com/snapcore/snapd/pull/5805>
<kyrofa> Trevinho, are you sure there's a snap/gui? https://github.com/telegramdesktop/tdesktop/tree/dev/snap
<sergiusens> Trevinho your problem lies two lines above.. That relative path worked through an implementation detail
<kyrofa> Oh, you make it
<kyrofa> Blech
<Trevinho> yeah, that's why I whished for years to do a SNAPCRAFT_PART_SOURCE env :)
<Trevinho> but too in hurry to do a pr for it
<mborzecki> zyga: lgtm, thanks!
<mvo> zyga: ok, fun - the kernel test is busted, debugging now
<mvo> zyga: so all good, much less of an issue than I expected
<kyrofa> Trevinho, SNAPCRAFT_PART_SRC is a thing, but it wouldn't help you in this case, the snap/ dir isn't considered part of the src
<Trevinho> yeah sure, but to pull from lib/xdg/*
<Trevinho> sergiusens: another thing i wanted to ask, is there something going on for some caching of parts? As in the past I was trying to use travis cache for parts which didn't change, and would be nice to have a mode where snapcraft tries to reuse the parts if they're updates, otherwise it auto-cleans and pull/build/stage the ones which need to. As right  now it gives an error message about what to do, but having something that forces it to clean...
<zyga> mvo: oh, version compare wrong?
<mvo> zyga: yeah, kernel version is "4.4.0-112-generic" - two "-" are illegal
<zyga> oh
<mvo> zyga: anyway, fix is easy
<zyga> this upsets the compare logic?
<mvo> zyga: yeah, its using the debian version compare rules
<mvo> zyga: which give "-" a strict meaning
<mvo> zyga: but no worries, fix is simple
<niemeyer> Mornings
<zyga> hey hey
<zyga> feeling better?
<mvo> niemeyer: good morning!
<mvo> niemeyer: oh, I missed that you felt unwell? a cold as well? it seems to be going around :(
<pstolowski> niemeyer: o/
<kyrofa> Trevinho, not completely clear what you're asking, but perhaps you'd be interested in the "lifecycle" section of these release notes? https://github.com/snapcore/snapcraft/releases/tag/2.43
<zyga> brb, getting more warm tea
<Trevinho> kyrofa: oh, yes, that's the one!
<Trevinho> kyrofa: that works also when doing `snapcraft prime <part>` and then if some dep on that needs cleanup does it?
 * zyga shivers
<kyrofa> Trevinho, yes, but it's not magic. It will catch changes made to the files for local parts, but not remote parts. It will clean/re-run steps that you change (e.g. if you alter override-build it knows build needs to run again)
<kyrofa> It's also pretty new, we're still tweaking it, but would love for you to give it some mileage
<mvo> zyga: I updated 5768, it needs a second review but that should be trivial :)
<zyga> ack, I'll look in a sec
<mvo> zyga: thanks and no rush, still need to wait for tests
<niemeyer> mvo: Sorry, missed your question
<niemeyer> mvo: No, I just felt a bit brainwashed after last week :)
<zyga> mborzecki: updated, thanks
<zyga> mvo: looking now
<zyga> mvo: whee,
<zyga> something for 2.36?
<zyga> unexpected benefit from having macOS tests in travis
<zyga> no stupid log by default
<zyga> (the one that is super slow to load)
<zyga> jdstrand: hey, could you please look at 5395 again?
<mborzecki> if a configure hook fiddles with socket serviec files, is there a way to have snapctl trigger systemd reload?
<zyga> fiddle?
<mborzecki> zyga: yes, say i have socket activated serice and i change the port it listens on
<zyga> how can you do that?
<mborzecki> zyga: sed -e with socket unit file? i guess it onl works here becase i have no apparmor to stop me
<zyga> yeah.
<zyga> exactly that
<mborzecki> but yeah, say i have socket activated service and want to change something there, there is no way to do that, is there?
<zyga> that's correct
<mup> PR snapd#5863 opened: overlord/ifacestate: add hotplug slots with implicit slots <Hotplug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5863>
<pstolowski> niemeyer: would be great to land the oldest hotplug PRs that need your re-review when you've a moment. stacking up these hotplug PRs is becoming painful
<om26er> when is https://dashboard.snapcraft.io/ supposed to get back up ?
<zyga> https://status.snapcraft.io/
<zyga> it doesn't say
<wgrant> No ETA at present, but we're working on it.
<niemeyer> pstolowski: Ack
<pstolowski> niemeyer: sorry for pushing, let me know when i become annoying ;}
<niemeyer> pstolowski: No worries, thanks for pinging
<pstolowski> zyga: we don't use glib in snap confine, only in its tests right?
<zyga> pstolowski: correct
<pstolowski> zyga: allright then :). for a moment i was wondering why did you implement key=val parser if glib has one; makes sense, thanks
<zyga> yeah :-)
<zyga> brb
<mborzecki> hmm tests/main/login failing? i guess the store is not fully up yet
<zyga> yeah
<pedronis> the developer bits are still down, and login touches those
 * zyga dives into propagation settings
<Chipaca> mvo: Q: should I just bump the revno of go-flags in vendor?
<Chipaca> or however that particular dance went :-)
<Chipaca> bah, maybe when the store is happy again :)
<mvo> Chipaca: please do and we just try it
<pstolowski> zyga: commented on 5861
<zyga> looking
<Chipaca> mvo: looks like something big breaks; need to dig
<Chipaca> mvo: $ snap help
<Chipaca> error: unknown command "help", see 'snap help'
<Chipaca> :-)
<zyga> pstolowski: replied to all, updating
<mup> PR snapcraft#2298 opened: requirements.txt: pin click to v6.7 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2298>
<ogra> apparmor="DENIED" operation="open" profile="snap.pi-kiosk.hook.prepare-device" name="/etc/writable/hostname" pid=1942 comm="prepare-device" requested_mask="wc" denied_mask="wc" fsuid=0 ouid=0
<Chipaca> mborzecki: FWIW, https://standards.freedesktop.org/menu-spec/latest/ar01s03.html says Environments (OnlyShowIn and NotShowIn) are case-sensitive, and https://specifications.freedesktop.org/desktop-entry-spec/latest/ar01s03.html says case is significant "everywhere in the file"
<ogra> jdstrand, is hostname_control missing write permission to /etc/writable/hostname ? (i have a gadget that tries to set the hostanme in prepare-device but even thgouh the interface is connected i get the above error)
<mborzecki> Chipaca: hmm menu spec
<Chipaca> mborzecki: that's where OnlyShowIn and NotShowIn are defined (the second is the desktop spec)
<Chipaca> second link*
<cachio> mvo, hey
<cachio> yesterday I saw this with the lxd snap https://paste.ubuntu.com/p/XD87JBKzxs/
<cachio> if I install/remove lxd snap in beta or stable many times it works properly
<cachio> but when I install/remove it with core snap in one channel and then refresh to another channel and install/remove lxd snap it fails removing
<cachio> mvo, and it can't be installed anymore
<Chipaca> git bisect is awesome sauce
<pstolowski|lunch> heading for lunch and also need to take my daughter to the dentist for a small but urgent correction of her braces. hope to make it back for standup
<jdstrand> zyga: ok
<zyga> pstolowski|lunch: ttyl
<zyga> jdstrand: thanks!
<mup> PR snapcraft#2299 opened: [legacy] requirements.txt: pin click to v6 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2299>
<kyrofa> Chipaca, git bisect is one of the best git features
<kyrofa> Especially when it points to someone ELSE's commit
<Chipaca> well, in this case I think it points to something that worked for us by accident, but it might indeed be a bug
<Chipaca> I need to dig a little more
<Chipaca> (the fix if it's on our end is very simple)
 * zyga feels like he has fever :/
<zyga> I need to put a heater in this room
<sergiusens> mvo: hey there, question for you, is core18 production ready to use as a base?
<kyrofa> niemeyer, any chance you've done anything about enabling nested kvm on gce for spread?
<niemeyer> kyrofa: No, haven't touched htat
<kyrofa> niemeyer, we're to the point where we could use it
<kyrofa> niemeyer, and when I say "could use" I mean "kinda need"
<mup> PR snapd#5680 closed: [RFC] hotplug: handling of simple add/remove scenario <Blocked> <Hotplug> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/5680>
<mup> PR snapd#5864 opened: make sure hostnamectl can be used on core too <Created by ogra1> <https://github.com/snapcore/snapd/pull/5864>
<mvo> sergiusens: in a meeting, I will get back to you
<niemeyer> kyrofa: I don't recall where the conversation stands.. do we have a PR already?
<kyrofa> niemeyer, you just need to enable it on gce, it's not spread-specific
<niemeyer> kyrofa: Where?
<kyrofa> niemeyer, https://cloud.google.com/compute/docs/instances/enable-nested-virtualization-vm-instances
<zyga> niemeyer, mvo: I'll skip standup
<zyga> I feel so-so
<zyga> but the real reason is that there's a 20+ movie crew in my house
<zyga> shooting an episode of some police para-documentary now
<pedronis> heh
<zyga> so...
<zyga> yeah
<zyga> things that happen when you live with parents ;-)
<pstolowski> zyga: whaat?
<zyga> there's fake police
<zyga> and fake gangster
<zyga> and fake hostage
<zyga> and lights and lots of staff
<zyga> and people with makeup
<tomwardill> did you take a wrong turn on the way home from the sprint... are you actually in LA?
<zyga> and I learned that my dog can bark
<ogra> call the real police ... tell them the fake ones hold you back from attenting an important meeting !!!
<zyga> he was so stressed about all the people he started barking at them
<niemeyer> kyrofa: "You can enable nested virtualization using the API or gcloud component. To enable nested virtualization, you must create a custom image with a special license key that enables VMX in the L1 or host VM instance and then use that image on an instance that meets the restrictions for nested virtualization. The license key does not incur additional charges."
<zyga> (normally he doesn't because his jaw was damaged)
<niemeyer> kyrofa: I suggest working with cachio on that
<zyga> anyway
<ogra> zyga, do we hav to call you zygmunt kardashian soon ?
<zyga> "action"
<zyga> they are shooting now
<zyga> well
<zyga> the film
<zyga> no shots in the scene
<sparkiegeek> ogra: we didn't, but now we do.
<ogra> haha
<ogra> he'll be rich and famous soon ... and give us all his makeup tips !
<zyga> tomwardill: in autocratic Poland, movie shoots you ;-)
<kyrofa> niemeyer, alright. cachio are you around?
<sparkiegeek> ogra: as long as we can skip the semi-nude photos on Instagram, I'm not sure the world is ready for zygdashian
<zyga> sparkiegeek: my ass is ready for the photo op
<zyga> \o/
<zyga> and here I was thinking that getting fever would mean the day is bad
<ogra> uhh ooh ... there can be mind-pics that cant be unseen !!!
<sparkiegeek> http://www.eyebleach.me/
<cwayne> Well that's enough internet for today
<niemeyer> kyrofa: You (or someone) will need to understand how those images are really different
<zyga> I can also not leave my room now as the door is blocked by their filming equipment
<niemeyer> kyrofa: As apparently the magic is in the image contnet, not in the project
<Chipaca> sparkiegeek: I don't think zyga needs to skimp on clothes to break the internet
<kyrofa> ogra, zyga this is all it takes: https://www.youtube.com/watch?v=35mQ29Cj-og
<zyga> Chipaca: right? have you seen my patches? :-)
<niemeyer> zyga: Ack.. I suggest actually taking the day off if you're not feeling well
<zyga> niemeyer: I plan to, as soon as those ... people leave
<zyga> and I can actually go upstairs
<niemeyer> zyga: Otherwise it's neither here not there and the recovery doesn't work so well
<zyga> I need to type more quietly
<ogra> kyrofa, lol !
<zyga> they are shooting right next to my keyboard
 * zyga breaks
<zyga> the re-takes are fun to watch
<mup> PR snapcraft#2294 closed: snap: workaround the dirty tree <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2294>
<zyga> kyrofa: once you know how those magic images work I'd love to know
<kyrofa> zyga, haha, I know zero about gce so hopefully cachio does
<zyga> kyrofa: (in Yoda's voice) but you will (be)
<zyga> ;-)
<zyga> ok quiet now
<kyrofa> authentic spanish chorizo... ah. Almost as good as mine
<Chipaca> kyrofa: tell them the one from a town over is better
<Chipaca> kyrofa: that'll go down well
<kyrofa> Hahaha
<zyga> my daughter will have a surprise once she returns home
<zyga> police, cameras, tons of people
<sparkiegeek> that won't be intimidating
<zyga> I'll tell her that *next* time she needs to do homework!
<zyga> login test fails
<zyga> another take
<kyrofa> zyga, convince them to put fake blood on you and lay on the floor for when she walks in. Too much?
<zyga> kyrofa: you'll be a great parent
<zyga> ;D
<kyrofa> zyga, I dunno, how old is she... maybe she'll be happy?
<kyrofa> :P
<zyga> 10
<kyrofa> Ah, not old enough
<zyga> "whee, someone killed daddy"
<zyga> :D
 * zyga must stop laughing 
<Chipaca> yeah, it'd have to be on the dog, not the zyga, for it to be bad at that age
<sergiusens> you should a will right next to you when you do that
<kyrofa> Hahahaha
<zyga> I hear handcuffs
<zyga> and fighting
<kyrofa> "I leave everything to my son"
<zyga> (it's a scene where a guy tries to feel the cops)
<Chipaca> don't forget to add "but please leave the lab running for Chipaca" to your will
<zyga> hahahaha
<zyga> :D
<zyga> I meant to say flee
<zyga> gee, spell checkers are so awkward sometimes
<sparkiegeek> who will clear your browser history?
<kyrofa> zyga, you're missing an opportunity to get famous. Ask them "does your show have anything to do with the cyber?"
<zyga> sparkiegeek: I personally trained my dog
<zyga> sparkiegeek: he will eat the computer
<zyga> kyrofa: your show would be so much easier to do with snaps
<zyga> ;-)
<ogra> that did need training ??
<zyga> another take
<sparkiegeek> last I checked the hollywood snap was broken though :(
<tomwardill> volunteering to lend my dog to anyone that needs anything eating
<tomwardill> he's got lots of experience
<sparkiegeek> tomwardill: did you leave him in the server room this morning?
<zyga> ha! busted
<zyga> don't pee on the primary replica
<sparkiegeek> $ hollywood
<sparkiegeek> Illegal instruction (core dumped)
<sparkiegeek>  
<sparkiegeek> yeah, still b0rked
<sparkiegeek> kirkland: ^ can haz fix please
<zyga> sparkiegeek: which cpu do you have?
<sparkiegeek> zyga: core I7
<tomwardill> sparkiegeek: there would be a lot more mess to clean up if I'd done that
<sparkiegeek> zyga: I reported this to dustin ages ago, but then he quit :)
<wgrant> That's about six generations of CPU :P
<wgrant> Which microarch?
<wgrant> Er nine generations I guess
<sparkiegeek> wgrant: well, I'm 90% sure it would fail on all of them; go ahead, try it!
<sparkiegeek> Intel(R) Core(TM) i7-4790K CPU @ 4.00GHz
<sparkiegeek> for the record
 * tomwardill can't install it due to 503
<zyga> sparkiegeek: which gen?
<zyga> sparkiegeek: I can try
<tomwardill> 4790 is haswell refresh
<tomwardill> 4th gen, iirc
<zyga> 5 was Broadwell, yeah
<zyga> 6 is skylake
<sparkiegeek> https://ark.intel.com/products/80807
<zyga> I think they will be shooting more scenes in the basement now
<zyga> so I _may_ just go to bed
<zyga> it crashes on Skylake here
<zyga> so boo
<zyga> (another take)
<sparkiegeek> yeah, it's a bug in the snap :)
 * zyga looks at the tests/main/login test
<sergiusens> sparkiegeek: zyga hollywood might be broken because it never got to experience the magic of magic of patchelf in a rebuild
<zyga> yeah, it crashes in ld.so
 * sergiusens is failing to write down all the words that flow through his head
 * zyga hugs sergiusens 
<zyga> don't worry
<sergiusens> zyga: it is using plain old python from the archive and is classic, but unpatched
<sergiusens> binary patched that is
 * zyga nods
<zyga> wgrant: store auth is still down
<zyga> is that part of dashboard.s.io?
<wgrant> yes
<wgrant> Well partially
<wgrant> User auth is
<zyga> error: cannot get snap access permission from store: store server returned
<zyga>        status 503 (see 'snap help login')
<zyga> right
<zyga> ok
<sergiusens> zyga: today is a day to reflect and maybe write docs ð
<mvo> sergiusens: core18 should be fine, its a foundations team question now actually :)
<mborzecki> niemeyer: can you take a look at https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/39 ? that's snap refresh on metered connections, seems like core devices may be a bit of a problem becuse some end up using systemd-networkd and NM is oblivious to interfaces that are not managed by it
<Chipaca> https://github.com/jessevdk/go-flags/issues/275 in case anyone was interested
<niemeyer> mborzecki: asked a question there
<om26er> popey: ping
<popey> om26er: pong
<om26er> popey: there is a new update of Android Studio available since Monday but it hasn't hit the snap store, when do snaps auto build ?
<popey> ah yes.
<popey> 1) when someone with access to build.snapcraft.io logs in and presses the "Manually build" button
<popey> 2) Whenever the git repo snapcrafts/android-studio changes
<popey> i put a build trigger file in every snapcrafters repo
<om26er> ah, I though it checked everyday if a new update is available or something
<popey> if anyone creates a PR against that with a date in it, it'll trigger *travis* to test build, which will make sure it builds okay, and if we merge, then build.snapcraft.io will build it
<popey> sadly not
<om26er> popey: so we need to do a manual build now
<popey> ok, wanna do a PR against .build-trigger?
<popey> you can do that yourself and travis will start work pretty quickly
<om26er> popey: is a PR required ?
<om26er> the changes will be automatically pulled
<popey> a pr will ensure everyone can see what's going on and it will be recorded as a change rather than ninja a file
<popey> i dont mind doing it now if you're busy
<om26er> popey: I am not busy but I thought that will actually kill the purpose of auto build
<om26er> https://github.com/snapcrafters/android-studio/blob/master/snap/snapcraft.yaml#L32
<popey> Well, there are two things we're doing here
<popey> 1) build on each commit, so we can test it builds okay before we hit the store
<popey> 2) build once committed so we get a build in edge
<popey> travis does #1, build.snapcraft.io does #2
<popey> s/commit/pr/
<popey> daily builds (I believe) only happen for projects where it's source for the part is a git repo, not a deb or some other dumped package
<om26er> popey: https://github.com/snapcrafters/android-studio/pull/35 does it look fine ?
<mup> PR snapcrafters/android-studio#35: Release Android Studio 3.2 <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/35>
<popey> well it worked, travis is on it :)
<sparkiegeek> popey: correct on limitations of daily builds
<popey> thanks sparkiegeek :)
<mvo> I wonder if we should set the login test to manual until the store is fully back
<mvo> this would allow us to land stuff again
 * cachio lunch
<sparkiegeek> mvo: gimme 5m to update statuses everywhere, we're basically back
<mvo> sparkiegeek: yay
<ijohnson> popey: since y'all are discussing this, is there anyway to setup LP/B.S.I to run tests against a snap that is built through a trigger? It seems like the only solution is to set up the tests externally on something like Travis as you have done
<popey> ijohnson: hiya. The only thing we have discussed recently was some automated testing that cwayne is setting up :)
 * popey bats that over the wall
<ijohnson> I see, thanks for confirming
<popey> om26er: I understand your frustration, I'd like everything autobuilding all the time too :)
<popey> om26er: I worked around this with a shell script which checks out projects, ninjas the date into .build-trigger and pushes, which forces a build
<popey> when we get security updates I run that script against 50 or so snaps and it goes "wheeeee" building them all :)
<tomwardill> please tell me the output is literally 'wheeee'
<tomwardill> because do want
<om26er> popey: I might write a bot that: 1. checks every day if a new version of Android Studio is available 2. If available, creates a pull request and notifies us through email or sends a push notification to my desktop to look at the PR.
<om26er> that way we can ensure our software is always the latest.
<popey> tomwardill: actually it prints an emoji "shrug" because it triggers a build and doesn't really know if it worked or not :)
<tomwardill> popey: that'll do :)
<wgrant> ijohnson: It seems like the sort of feature that snapcraft itself might want to have
<wgrant> Rather than LP defining an LP-specific interface for testing a snap
<diddledan> snapd translations: where are they? https://forum.snapcraft.io/t/weird-error-message-whenever-i-run-the-snap-command/6418/6
<diddledan> mvo: you appear to have access to those
<ijohnson> wgrant: agreed having a way to specify tests to run inside a snapcraft.yaml that are run as part of snapcraft building a snap would be nice
<sparkiegeek> diddledan: replied on the thread, but https://translations.launchpad.net/snappy/trunk for completeness
<diddledan> aha, thankyou :-)
<mvo> diddledan: I think I do, let me look
<mup> PR snapcraft#2298 closed: requirements.txt: pin click to v6 <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2298>
<mup> PR snapcraft#2299 closed: [legacy] requirements.txt: pin click to v6 <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2299>
<jdstrand> niemeyer: hi! I'm looking at https://forum.snapcraft.io/t/interfaces/6154. Is there a way (like there was in the old github wiki) to have links for each particular interface? eg, https://forum.snapcraft.io/t/interfaces/6154#dbus or https://forum.snapcraft.io/t/interfaces/6154#desktop
<niemeyer> jdstrand: I think each interface (or small groups of interfaces) should be its own document
<niemeyer> jdstrand: So that we can go deep into them, without creating a never-ending document which is very tiresome
<Chipaca> sparkiegeek: diddledan: but I think that's not the right one
<Chipaca> sparkiegeek: diddledan: the Dutch translation is empty, there
<sparkiegeek> Chipaca: oh? *shrug*
<niemeyer> jdstrand: The main interface page would be just a very shallow summary of what the interfaces do, linking into the detailed doc
<sparkiegeek> Chipaca: probably findable from there though?
<Chipaca> probably, but I'm bad at it
<niemeyer> (CC degville)
<mvo> diddledan: do you know what language that is?
<niemeyer> jdstrand: That was my thinking around the issue at least
<niemeyer> jdstrand: Still needs to pass through the real world test
<sparkiegeek> looks ~dutch to me
<Chipaca> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1773174
<Chipaca> sigh
<mup> Bug #1773174: Dutch lowercase translation warnings <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1773174>
<jdstrand> niemeyer: is there a format for the name of the topic you'd like to see? eg, https://forum.snapcraft.io/t/dbus-interface/... ?
<niemeyer> jdstrand: Yeah, I think we already have a couple there
<niemeyer> jdstrand: Content interface?
<mvo> sparkiegeek: yeah, I had the same hunch but it seems its mostly untranslated inhttps://translations.launchpad.net/snappy/trunk/+pots/snappy/nl/+translate
<jdstrand> that is one
<jdstrand> https://forum.snapcraft.io/t/the-content-interface/1074
<Chipaca> mvo: it reads like dutch to me. Could be afrikaans.
<jdstrand> that has 'the-' prefixed
<Chipaca> mvo: but that's also untranslated there
<Chipaca> so the translations are coming from somewhere else
<Chipaca> we had this same issue before
<Chipaca> where the .no translations had the same issue
<Chipaca> and it took me a while to find them...
<Chipaca> i should've taken notes
<popey> om26er: https://travis-ci.com/snapcrafters/android-studio/builds/86015873
<popey> 3.2.0.26 - look good?
<Chipaca> https://translations.launchpad.net/ubuntu/cosmic/+source/snapd/+pots/snappy/nl/+translate
<Chipaca> mvo: diddledan: sparkiegeek: ^^
<mvo> Chipaca: ta
<sparkiegeek> Chipaca: right, was about to go look at cosmic :)
<diddledan> aha, well found
<diddledan> number 169 for the first message
<mvo> Chipaca: actually I'm not sure we should enforce this rule on translations about the upper/lower
<Chipaca> mvo: why?
<mvo> Chipaca: I mean, we basicly have no idea about what rules these langugaes have (at least I don't have any)
<sparkiegeek> case doesn't mean the same thing in all languages?
<mvo> yeah, exactly
<Chipaca> mvo: i'm going to call a bridge-crossed-if-and-when thing
<Chipaca> I know some languages uppercase more than English does
<jdstrand> niemeyer: thinking of brand store snap decls, they would like links out to descriptions. it probably makes sense for me to do that
<Chipaca> I don't know of a language that has cases that uppercases less
<mvo> german certainly does :)
<mvo> I mean, uppercase a lot more
<Chipaca> yep
<diddledan> and 143 for the other
<Chipaca> and this is 'uppercase because it's the start of a sentence', so I'd expect it to be pretty universal
<jdstrand> niemeyer: do you want 'the-dbus-interface' or 'dbus-interface'? or something else less likely for someone to accidentally squat?
<jdstrand> eg, snapd-interfaces-dbus
<niemeyer> jdstrand: It has to read nicely.. the URL comes from the topic title
<niemeyer> jdstrand: Squat is also a non-issue in the forum.. we can always rename
<diddledan> mvo, Chipaca, sparkiegeek : I can make the change now I've found them if you'd like me to?
<sparkiegeek> diddledan: are you fluent in Dutch?
<jdstrand> niemeyer: The <name> interface?
<Chipaca> diddledan: go for it
<diddledan> no, it'll only be swapping the case of the first letter :-p
<niemeyer> jdstrand: Yeah, or "The <concept> interfaces" in some cases
<om26er> popey: so whats the next step for https://github.com/snapcrafters/android-studio/pull/35 ?
<Chipaca> I'm not fluent, and the little bit I had has rusted to heck
<mup> PR snapcrafters/android-studio#35: Release Android Studio 3.2 <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/35>
<om26er> Do we just merge it ?
<sparkiegeek> Chipaca, diddledan: I think this needs notes for TRANSLATORS so that it can be found before run-time in snapd
<mvo> Chipaca: ok, I checked wikipedia and it says that all european languages capitalize the first word
<Chipaca> sparkiegeek: it should have a TRANSLATORS note already (if not, I'll add it)
<niemeyer> jdstrand: But we should sync with degville to see what's his take on the whole sisue
<mvo> diddledan: please make the change
<diddledan> roger that
<sparkiegeek> Chipaca: https://translations.launchpad.net/ubuntu/cosmic/+source/snapd/+pots/snappy/nl/143/+translate it does not
<jdstrand> niemeyer: degville, can you comment? this is somehting I'd like to have done in the next few weeks
<sparkiegeek> at least, not one that LP understands, and it got others :)
<Chipaca> sparkiegeek: remind me, what was the original english?
<mvo> Chipaca: so I think we are good until these !europeans come and complain :)
<sparkiegeek> Chipaca: it's there :)
<jdstrand> err, that was for degville only
<diddledan> done
<jdstrand> niemeyer: the concept idea is fine. is there one otoh that you would like to see as a concept?
<Chipaca> mvo: from the code: // note IsLower != !IsUpper for runes with no upper/lower.
<jdstrand> or more than one
<Chipaca> mvo: so we're covered for a bunch of 'em already :-)
<degville> niemeyer, jdstrand: I'm just getting to that part of the docs. We can definitely update the interfaces asap.
<diddledan> says it'll be held for review by someone who knows what they're doing :-p
<mvo> Chipaca: yay, must have been a smart guy writing this code ;)
<Chipaca> nah, i know that person, i think they just have moments of lucidity and then it's all chaos all the time
<mvo> thanks diddledan, lets hope this review will happen quickly, if not I guess we need to poke people (i.e. write to the translations team)
<mvo> Chipaca: heh
 * mvo hugs Chipaca 
<Chipaca> mvo: as I said in the forum, i'm glad we changed it from a panic :-)
 * diddledan prepares a feather quill for the handwritten note to the translations team
<Chipaca> mvo: also FWIW this has been going on for Dutch people since at least https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1773174
<mup> Bug #1773174: Dutch lowercase translation warnings <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1773174>
<Chipaca> diddledan: in esperanto, right?
<diddledan> yeah, it's quite a while for them to have been suffering with it - I guess most folk just ignored it
<jdstrand> degville: we've not met. I'm Jamie and I work on interfaces a bit and have written a lot of the text in that page
<jdstrand> degville: that started as a wiki page in the github wiki and was migrated over
<niemeyer> jdstrand: Not sure of a specific one.. I just half-expect some interfaces to be too simple and boring, which might be good candidates for some small aggregation
<jdstrand> (I didn't do the migration)
<jdstrand> niemeyer: ack
<niemeyer> jdstrand: You've probably half-met last week :)
<mvo> Chipaca: hm, thats month :/ oh well
<Chipaca> mvo: yeh
<jdstrand> degville: are you working on documentation? are you saying this change niemeyer and I discussed is something you would do or you're happy if it happens by someone else sooner
<mvo> Chipaca: makes me wonder if we should sync the translations into our git tree, this way we could trivially analyze them
<Chipaca> mvo: translations thinks it's syncing them somewhere
<diddledan> Chipaca: shall I assign the bug #1773174 about the dutch translations to you and mark it as in progress?
<mup> Bug #1773174: Dutch lowercase translation warnings <amd64> <apport-bug> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1773174>
 * jdstrand looks in canonical directory and sees that debis a Technical Writer (great!)
<Chipaca> but I dunno :-)
<Chipaca> mvo: I'd like to get them synced, then other distros could get them easier?
<mvo> Chipaca: yeah, the upstream translations but those are the distro translations that are not quite right
<mvo> Chipaca: yeah, that makes a lot of sense
<Chipaca> sigh
<Chipaca> anyway, I'll add all those TRANSLATOR notes
<Chipaca> there's a bunch of 'em :-(
<diddledan> joy
<diddledan> documentation. who'd bother?! :-p
<mvo> diddledan: the url above had "cosmic" in it, the bugreport is about "bionic", so we may need to update it in two place :/ would you be so kind?
<diddledan> okie dokie, I'll go do that
<popey> om26er: I merge it, it builds, success
<om26er> ð
<mvo> diddledan: thank you!
<mvo> sparkiegeek: do you happen to know who can approve po/pot in LP these days? we have a pending https://translations.launchpad.net/snapd/trunk/+imports?field.filter_status=all&field.filter_extension=pot
<mvo> sparkiegeek: and a bunch of pos
<mvo> sparkiegeek: aiui we could enable translation sharing
<sparkiegeek> mvo: I do not
<mvo> sparkiegeek: ok, thanks, I will try to find something in the LP help
<sparkiegeek> mvo: I assume it's https://translations.launchpad.net/+groups/ubuntu-translators ? but just a guess
<mvo> Chipaca: ^- I think with the above (approved translations in LP for snapd upstream) we could enable translation syncs
<diddledan> mvo: it looks like they automatically got the suggestions Chipaca and I already added
<diddledan> there aren't any translations for xenial or trusty (the list is empty)
<mvo> diddledan: great, thanks for double checking
<diddledan> oh wow, that pending pot is old
<diddledan> back from april?
<mvo> niemeyer: hey, do you have access to https://translations.launchpad.net/snapd/trunk/+imports?field.filter_status=all&field.filter_extension=all and can click on "approve" on the "needs review" link? it seems I can't but you own the snapd project on LP so you may
<niemeyer> mvo: Grayed out here as well: https://usercontent.irccloud-cdn.com/file/D9bETlXs/image.png
<mvo> niemeyer: thank you
<diddledan> oh dear. who stole the permission bits?! :-p
<mvo> niemeyer: I will ask the store for help
<mvo> diddledan: heh :)
<niemeyer> mvo: We need to decide on the kernel names.. I think the idea of using tracks + limiting tracks displayed depending on what the model says sounds interesting.
<niemeyer> mvo: Do we have any new concerns around this, or should we just go ahead?
<diddledan> I vote Wilma for one name!
<diddledan> what do you mean you want sensible suggestions??
<diddledan> pfft
<mvo> niemeyer: I think this is good, lets do it
<niemeyer> mvo: Cool, replied
<Chipaca> diddledan: all (or nearly all) the positional arguments had the right TRANSLATORS note, but none (or nearly none) of the options did :-(
<mup> PR snapd#5865 opened: cmd/snap: add a bunch of TRANSLATORS notes (and a little more i18n) <Created by chipaca> <https://github.com/snapcore/snapd/pull/5865>
<Chipaca> mvo: diddledan: ^
<diddledan> reviewed :-)
 * diddledan requested changes because I'm bossy :-p
 * Chipaca deletes the branch and goes off in a huff, takes up farming
<diddledan> haha. now _that_ is a quality ragequit
<Chipaca> heh
<Chipaca> I had a client actually do that, once
<Chipaca> still paid his bills, so that was alright, but still
<diddledan> yikes
<roadmr> a colleague quit his job as a support engineer to take up organic farming, far up north - so he pretty much only works from May to September now
<Chipaca> also a friend, a dutch web dev, went off to become a farmer in Jujuy
<Chipaca> which was a bit extreme, but he seems a lot happier these days Â¯\_(ã)_/Â¯
<Chipaca> roadmr: see, support people I can understand ragequitting the world
<diddledan> jujuy? is that the month that we do deployments from the commandline? :-p
<Chipaca> diddledan: https://goo.gl/maps/9jAp64cfVh52
<roadmr> reminds me of the "I'd rather shovel pig sh*t" in https://www.youtube.com/watch?v=b2F-DItXtZs
<diddledan> aha, a placee
<diddledan> I figured it was a mistype of "July" :-p
<diddledan> I love the emphasis that the tts puts on "web scale"
<popey> om26er: released to stable,beta! Thanks!
<popey> (I tested it first) :D
<om26er> popey: Thanks a lot.
<om26er> popey: did you release to beta to help people transition to latest ?
<popey> om26er: ah force of habit. For all the other snapcrafters ones the script detects the version in the beta channel to decide when to build the next release
<mvo> Chipaca: nice, thank you!
<mup> PR snapd#5768 closed: selftest: actually run the kernel version selftest <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5768>
<mvo> mborzecki: just fyi (for tomorrow), I updated 5771 with your suggestion
<Saviq> hmm what's this about Â«Connect docker:home to core:home (connection denied by slot rule of interface "home")Â»?
<Saviq> I wanted to give snapped docker access to my home folder to share volumes with, but snapd denies that connectionÂ¿?
<Chipaca> Saviq: how did you get that error?
<Saviq> Chipaca: `snap connect docker:home`
<Chipaca> Saviq: does the snap list the home interface?
<Saviq> https://pastebin.ubuntu.com/p/ShTwKGh5bS/
<Chipaca> Saviq: the home interface auto-connects
<Saviq> well, yeah, but it's not connected...
<Chipaca> that is weird
<Saviq> -                          docker:home
<Saviq> and:
<Saviq> î° snap connect docker:home
<Saviq> error: cannot perform the following tasks:
<Saviq> - Connect docker:home to core:home (connection denied by slot rule of interface "home")
<Chipaca> ah
<Chipaca> Saviq: I'm not sure exactly, so I'd defer to zyga for details
<Chipaca> Saviq: but
<Chipaca> Saviq: that snap defines its _own_ home
<Chipaca> Saviq: it defines docker:home, as opposed to core:home
<ijohnson> Saviq: what channel are you on with the docker snap?
<Chipaca> Saviq: I'm not at all sure that works the way it's meant to work
<Chipaca> Saviq: (i might even have it all wrong -- this is a use i've never seen before)
<ijohnson> I imagine this is from https://forum.snapcraft.io/t/auto-connection-for-home-interface-for-docker-snap/7502
<ijohnson> I had pushed a revert that undoes the read:all for the docker snap until I can get it approved by the store
<ijohnson> Saviq: yes I think I had pushed a revert to edge but hadn't put it on beta yet, I am releasing that now. Sorry for the confusion
<Saviq> ijohnson: right, I'm on beta
<Saviq> so probably just hit that then
<ijohnson> Yes I think so
<Saviq> ijohnson: is there a way to avoid `sudo` for all the docker commands?
<ijohnson> If you add your user to the docker group, then you shouldn't have to use sudo with docker
<Saviq> right, but need to create that group manually
<ijohnson> Yes
<Saviq> ack thanks!
<ijohnson> The reason I was adding the read:all to the home plug was so that if you didn't want to create the docker group and add yourself to it and still use sudo docker, then you could at least build files outside of root's $HOME
<ijohnson> But apparently this needs store approval, which I didn't realize (it connected fine locally)
#snappy 2018-09-27
<mup> PR snapcraft#2291 closed: meta: put environment into runner instead of app wrapper <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2291>
<mborzecki> morning
<zyga> o/
<zyga> Iâm feeling somewhat better.
<luk3yx> Hello
<zyga> Hey
<zyga> The store is fully operational again, great!
<mborzecki> zyga: hey
<mup> PR snapd#5805 closed: cmd/snap-update-ns: enforce trespassing checks <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5805>
 * zyga is happy to land that
<mup> PR snapd#5864 closed: make sure hostnamectl can be used on core too <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5864>
<mup> PR snapd#5857 closed: userd: extend the list of supported XDG Desktop properties when autostarting user applications <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5857>
<mup> PR snapd#5840 closed: interfaces/apparmor, interfaces/builtin: tweaks for parallel snap installs <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5840>
<mvo> 5571 should be an easy win (just needs a second review)
<mborzecki> mvo: 5571 appears to be merged, did you mean another pr?
<mborzecki> 5771 maybe?
<mvo> mborzecki: yes, sorry
<mvo> clearly more tea is needed :)
<pstolowski> Morning
<mup> PR snapd#5771 closed: selftest: add test to ensure selftest.checks is up-to-date  <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5771>
<zyga> mvo: trespassing fix is merged, shall I propose a PR to take layouts out of beta?
<zyga> mvo: full disclaimer, I'm investigating a bug that is related to propagation settings
<zyga> so perhaps not yet but then again, it would help a lot of people with simple layouts already
<mvo> zyga: let do it
<mvo> zyga: and we can wait with the merge until you finished your investigation
<zyga> ok
<mvo> zyga: but this way spread can run etc
<mborzecki> nice to see the diff in #5596 so short, nearly all i had in the integration branch is now in
<mup> PR #5596: [WIP] Parallel installs integration <Blocked> <Parallel installs> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5596>
<mvo> mborzecki: hm, this looks like the integration PR juts contains some more tests, so time to merge those too?
<mborzecki> mvo: i'll push those separately along with couple enhancements to other tests
<mvo> mborzecki: cool
<mborzecki> but first coffee
<mup> PR snapcraft#2300 opened: [WIP] plugins: remove implicit source <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2300>
<mup> PR snapd#5866 opened: tests: remove unneeded cleanup from layout tests <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5866>
<mup> PR snapd#5867 opened: many: enable layouts by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5867>
<zyga> mvo: ^ done
<mvo> zyga: ta
<mvo> zyga: hm, curious, why switching the default instead of juts removing the option entirely?
<mvo> zyga: I mean, whats the use-case, someone who feels uncomfortable with layout should still be able to disable them?
<luk3yx> If I make my snap private, will existing users continue getting updates?
<luk3yx> And can people still install it by snap name?
<luk3yx> (I want a semi-private snap so people download the "official" snap instead)
<kyrofa> zyga, mvo do you guys have any thoughts on this? https://forum.snapcraft.io/t/snaps-are-broken-in-bionic-lxd-container/7339
<mup> PR snapd#5868 opened: tests/main/snap-env: extend to cover parallel installations of snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5868>
<mvo> kyrofa: can you please try the switch core to "edge"?
<mvo> kyrofa: we fixed this recently but its not in beta yet, hopefully by EOD though
<kyrofa> mvo, will do, thanks
<zyga> re
<zyga> kyrofa: replied
<ackk> hi, I'm getting the following error running snapcraft: ImportError: /snap/snapcraft/2022/lib/python3.5/site-packages/nacl/_sodium.abi3.so: undefined symbol: crypto_pwhash_argon2id_opslimit_moderate
<zyga> kyrofa: or how your new neighbours might have said if they spoke broken Spanish like I do: yo ha aÃ±adido una respuesta
<kyrofa> akk interesting, we've started getting that as well
<kyrofa> But it doesn't seem consistent-- you?
<zyga> Chipaca: heey
<zyga> around?
<Chipaca> zyga: (y)
<kyrofa> Urgh... why can't I cancel spread...
<zyga> Chipaca: I'd like to add a tweak to yams loader for snap.yaml to indicate an error if "layouts" (plural) is used over the singular correct form
<zyga> Chipaca: I was thinking of a simple new entry to deserialise with the different name
<zyga> Chipaca: but if you have a better idea I'm all ears
<Chipaca> kyrofa: you can, it just takes a bit
<Chipaca> kyrofa: it delays because it shuts down the remotes, which can take a while to respond
<Chipaca> kyrofa: you can also ctrl-backslash, and then use the .spread* to clean up
<Chipaca> zyga: I wonder if there's a way to throw an error on anything unparsed
<zyga> Chipaca: mmm, that may be future-proof nasty
<zyga> I'd rather not
<kyrofa> Chipaca, ah, ctrl-backslash will do it!
<Chipaca> kyrofa: usually you can then tell spread itself to clean up using e.g. spread -reuse-pid=<the appropriate number from inspecting .spread*> -discard
<Chipaca> kyrofa: spread itself will also tell you what the right argument for -reuse-pid is in its log, if it's still in your scrollback
<Chipaca> zyga: good point
<kyrofa> Chipaca, just --reuse --discard seems to work
<zyga> Chipaca: but we could _warn_ about it
<zyga> (wink wink)
<Chipaca> zyga: if only we had something like that
<zyga> right
 * Chipaca gets back to writing stuff on the forum
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/5869
<mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
<mup> PR snapd#5869 opened: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
<Chipaca> zyga: what about: TypeLouts errorCatcher
<Chipaca> zyga: and then, type errorCatcher struct{}
<zyga> errorCatcher?
<zyga> ah
<Chipaca> zyga: and then, func (errorCatcher) UnmarshalYAML(...)
<zyga> and fail on deserialise?
<zyga> :D
<zyga> yeah
<zyga> ++
<zyga> I'll do that, great idea
<zyga> but...
<zyga> how to tweak the error message then?
<Chipaca> hmmmm
<zyga> no < > to specialise
<zyga> still
<zyga> I could use a generic type
<Chipaca> zyga: make it a layoutsErrorCatcher for now, we can worry about making it generic later
<zyga> and subtype it
<zyga> yes
<zyga> +1
<zyga> Chipaca: actually, we can use the struct tags for that
<Chipaca> zyga: we can?
<Chipaca> zyga: i thought that'd be visible one step up
<zyga> Chipaca: TypoLayouts errorCatcher `yaml:"layouts,omitempty",hint:"yada yada"`
<zyga> something like that?
<Chipaca> zyga: does the errorCatcher deserialiser "see" that hint?
<zyga> not sure yte
<zyga> looking at this part now
<pedronis> #5833 needs a 2nd review
<mup> PR #5833: asserts,interfaces/policy: add support for on-store/on-brand/on-model plug/slot rule constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5833>
<jamesh> If errorCatcher is implementing yaml.Marshaler, I doubt it would have access to the tag
<zyga> yeah, that's what I see so far
<zyga> I'm still looking for _a_ way
<jamesh> it'd have a pointer to the struct member passed as the receiver, but no way of knowing that it is a member of the struct
<jamesh> making the struct itself implement yaml.Marshaler on the other hand might do the trick
<zyga> but then we're back to square one with explicit checking per-field like I do nwo
<zyga> *now
<zyga> it _feels_ like schema
<mup> PR snapd#5813 closed: image: warn on missing default-providers <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5813>
<zyga> so maybe the simple fix I did now is OK before we have schema support
<Chipaca> niemeyer: mvo: how much do we still care about old local revisions? I'm talking about local revisions from before we went negative for local
<Chipaca> that is, revisions above 100000
<Chipaca> we have tests for them, but I suspect we don't really support them any more outside of those tests
<mup> PR snapd#5870 opened: tests/main/parallel-install-services: add spread test for snaps with services <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5870>
<niemeyer> Chipaca: My only concern is people using these after installing an old image
<zyga> Chipaca: I abandon this idea now,
<Chipaca> niemeyer: ack
 * zyga -> coffee and snack
<Chipaca> mvo: what should I tag warnings as? 2.36?
<mvo> Chipaca: yes
<mvo> Chipaca: what is missing there?
<mvo> Chipaca: I kind of hope to do 2.36 later today
<Chipaca> mvo: https://forum.snapcraft.io/t/warnings/7599
<Chipaca> mvo: that :-)
<Chipaca> degville: https://forum.snapcraft.io/t/warnings/7599
<Chipaca> degville: let me know if you can't edit that and want to
<Chipaca> (i know you want to :-p)
<zyga> Chipaca: how do you feel about adding a warning that warnings are added to everyone refreshing from old snapd? :)
<zyga> (and then we remove it in the next release)
<Chipaca> zyga: before answering I need to know how many other bad ideas you've had today
<zyga> Chipaca: ... I need to re-think the idea to get up in the morning
<Chipaca> zyga: I liked at the sprint where you'd announce "this is bad idea #N++"
<zyga> :D
 * zyga is now being honest
<Chipaca> zyga: my main problem with your idea here is that it'd be the _only_ warning the user'd see
<zyga> oh
<zyga> in that case it'd be futile
<Chipaca> zyga: because warnings are there, but nothing uses them as yet
<Chipaca> that's 2.37 material
<zyga> any low hanging fruit?
<zyga> in that case I'd postpone the idea to 2.37
<Chipaca> zyga: egrep -ir '(todo|xxx).*warn'
<Chipaca> zyga: and, my secondary problem with your idea is that if we need to do that, then we failed to make them obvious and discoverable and subtle and non-intrusive
<zyga> warning: your snapd has updated to x.yz, featuring new functionality and bug fixes
<zyga> but that's not a warning
<Chipaca> zyga: and it'll train the user to ignore them
<zyga> mmm, perhaps but that would be a nice touch
<Chipaca> so, yeah, -1
<zyga> "snapd is getting better while you are to looking"
<pedronis> please rate snapd
<zyga> mmm, those are way more annoying
<mup> PR snapd#5871 opened: snapstate: only report errors if there is an actual error  <Created by mvo5> <https://github.com/snapcore/snapd/pull/5871>
<zyga> because they are like beggars asking for a coin, here it's more of a "what's new"
<pedronis> anyway lots of our users will not see warnings unless gnome-software learns about them
<zyga> yeah, that's true
<zyga> it'd be more welcome if any app could do it
<zyga> well, back to propagation
<pedronis> the app can do it inside themselves
<zyga> yeah but if all apps could do it in a standardised way through gnome-software it would be nice
<pedronis> maybe, maybe not
<pedronis> everything already wants to speak to me
<Chipaca> pedronis: that's because you're famous
<mup> PR snapd#5872 opened: tests/main/parallel-install-local: rename from *-sideload, extend to run snaps <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5872>
<zyga> today Alice in wonderland would have to agree to a privacy policy, EULA and limited warranty before falling down the rabbit hole
<diddledan> she wouldn't read them thoroughly, though, or at all, and therefore be violated without her knowing
<mup> PR snapd#5866 closed: tests: remove unneeded cleanup from layout tests <Simple> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5866>
<zyga> thanks!
<mup> PR snapd#5873 opened: tests/main/parallel-install-store: run installed snap <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5873>
<joc> is there any particular reason why core18 edge hasnt seen an update for about 3 weeks now?
<diddledan> joc: is there a problem with what's there now?
<joc> was hoping for at least a build with ping back as per https://forum.snapcraft.io/t/core18-included-binaries/7191/14
<zyga> joc: yes
<zyga> joc: it's because when it is stable we cannot break it
<zyga> so that decision was postponed
<zyga> joc: I _believe_ this is now the decision of the foundation team though
<zyga> mvo: ^
<joc> zyga: makes sense for stable channel but was looking at edge
<zyga> oh, I missed that, sorry
<zyga> in that case I don't know
<joc> maybe the transfer to foundations is the reason for the hiatus
<mup> Bug #1771793 changed: Interface for hardware temperature monitoring <Snappy:Invalid> <https://launchpad.net/bugs/1771793>
<diddledan> mup is slow, I changed that bug 4 minutes ago! :-p
<mup> Bug #4: Importing finished po doesn't change progressbar <iso-testing> <lp-translations> <Launchpad itself:Fix Released by carlos> <Ubuntu:Invalid> <https://launchpad.net/bugs/4>
<diddledan> haha
<diddledan> silly bot
<zyga> when the machines rebel mup will remember you said that ;)
<diddledan> I, for one, welcome our shiny metal overlords
<diddledan> https://memegenerator.net/img/instances/27465850/kiss-my-shiny-metal-ass.jpg
<zyga> https://imgflip.com/i/2iu79t
<diddledan> nice!
<Son_Goku> haha
<Son_Goku> ah bender and morpheus
<mborzecki> cachio has set up centos images, 2018-09-27 12:47:06 Sending project content to google:centos-7-64 (sep271046-416264)...
<mvo> joc: ping is back but the core18 snap is held up in manual review because of this, sil2100 is working on fixing this AIUI
<ackk> hi, question about the nodejs plugin: shouldn't it run "yarn install" (with node-package-manager: yarn) automatically during the build phase?
<diddledan> ackk: I don't think yarn support works right now
<ackk> diddledan, looking at https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/nodejs.py#L178 it seems it does
<ackk> diddledan, I mean by setting node-package-manager to yarn I do get yarn installed, but it doesn't really install stuff from the yarn.lock file automatically
<diddledan> yes, that's what I'm referring to. it's broken.
<ackk> ah, I see
<ackk> diddledan, fwiw https://paste.ubuntu.com/p/tYJPk9bt6K/ worked for me
<kyrofa> diddledan, akk can one of you please log a bug about that?
<ackk> diddledan, maybe you have a bit more context for the bug ^ ?
<diddledan> I haven't really dug into it. I meant to, but then forgot :-)
<diddledan> https://bugs.launchpad.net/snapcraft/+bug/1794727
<mup> Bug #1794727: node plugin doesn't run yarn install during build <Snapcraft:New> <https://launchpad.net/bugs/1794727>
<rbasak> snapcraft edge channel broken? beta works. edge failure: https://paste.ubuntu.com/p/GW4gWH4nrC/
<rbasak> kyrofa, sergiusens: ^
<rbasak> edge 2022; beta 1871
<diddledan> rbasak: kyrofa is working on it
<kyrofa> rbasak, thank you for letting us know, very nice to have folks testing edge :)
<kyrofa> All over it
<rbasak> Great, thanks :)
<mborzecki> Chipaca: warnings aren't pushed by anything yet, are they?
 * zyga needs to take the dog for a walk
<diddledan> zyga: going dogging, eh? ;-p
<diddledan> I really should take myself for a walk occasionally ;-D
<diddledan> <-- lazy
<Chipaca> mborzecki: correct; sudo http snapd:///v2/debug action=add-warning message="hello world"
<jdstrand> mborzecki: hi! fyi, was looking at pt 5594 and noticed something. see https://github.com/snapcore/snapd/pull/5594/files#r220886654
<mup> PR #5594: snap/snapenv: add snap instance specific variables <Parallel installs> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5594>
<mborzecki> jdstrand: looking
<jdstrand> # bind mount *not* used here (see 'parallel installs', above)
<mborzecki> jdstrand: this was fixed later on in https://github.com/snapcore/snapd/pull/5735 which came as a result of discussion in #5713 (parallel installs mount mappings)
<jdstrand> owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/                  r,
<mup> PR #5735: snap/snapenv: drop some instance specific variables, use instance-specific ones for user locations <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5735>
<mup> PR #5713: many: mount namespace mapping for parallel installs of snaps <Parallel installs> <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5713>
<jdstrand> owner @{HOME}/snap/@{SNAP_INSTANCE_NAME}/**                mrkix,
<mborzecki> jdstrand: so $HOME is instance specific path now, same as $SNAP_USER_DATA
<jdstrand> ok, I see that in that pr. thanks!
<mborzecki> jdstrand: thank you for being so thorough
<jdstrand> mborzecki: it sounds like there isn't anything left for me with this feature?
<mborzecki> jdstrand: not at the moment, i'll ping you if i end up doing any tweaks to the interfaces
<jdstrand> mborzecki: ok, thanks! I bet you're pretty happy to see this coming to a close :)
<mborzecki> jdstrand: and thanks for the reviews again :)
<jdstrand> np :)
<mborzecki> Chipaca: aargh, need http unix sockets extension
<Chipaca> mborzecki: snap install http dude
<mborzecki> publisher: John Lenton (chipaca), nice!
<Chipaca> :-)
<Chipaca> mborzecki: that's why it understands snapd:/// at all :-)
<Chipaca> mborzecki: also how it's able to use snapd-control :D
<mborzecki> Chipaca: yay, works now
<ogra> pedronis, is it normal that i dont get a snap id here ? https://paste.ubuntu.com/p/ZNcjS2P53M/
<mborzecki> Chipaca: any plan on where do we start springking warnings first?
<Chipaca> mborzecki: also relevant, there's a unshow-all-warnings debug action
<ogra> (i'm trying to pre-connect some interfaces from gadget.yaml but if the system doesnt see an id i can not really do that)
<Chipaca> mborzecki: egrep -ir '(todo|xxx).*warn'
<Chipaca> mvo: how're you feeling about dotfiles for 2.36?
<zyga> diddledan: adopting a dog helped with my step count average :)
<diddledan> :-)
<ogra> hmm
<ogra> Process '/usr/bin/unshare -m /usr/bin/snap auto-import --mount=/dev/sda1' failed with exit code 1
<ogra> is there any chance to find out *why* it actually failed ?
<ogra> i can manually mount the device (and it properly carries an auto-import.assertion file)
<ogra> journalctl sadly does only print that one line ... and snap changes doesnt mention it either
<ogra> (it is a vfat formatted usb stick)
<Chipaca> ogra: dmesg might have more info
<ogra> doesnt
<Chipaca> ogra: that command is run via an udev rule
<ogra> manually running the program helps a bit (tells me the user already exists, which is indeed true because i manually created it after the import failed)
<Chipaca> ogra: snapd-autoimport.rules (or 66-snapd-autoimport.rules)
<ogra> Chright, might help to connect stderr to stdout here
<ogra> Chipaca, ^^
<ogra> haha
 * Chright ~> lunch-making
<mborzecki> off to pick up the kids
<Chipaca> niemeyer: do you want to review #5856, or should I merge it? (it has two +1s already)
<mup> PR #5856: cmd/snap: tame the help zoo <Created by chipaca> <https://github.com/snapcore/snapd/pull/5856>
 * Chipaca ~> really lunch
<ogra> is there a valid way to find the name of the model from a hook without using snapd-control ?
<niemeyer> Chipaca: If it follows what we discussed, +1
<mup> PR snapd#5874 opened: Adding missing permission to create /run/wpa_supplicant directory <Created by kubiko> <https://github.com/snapcore/snapd/pull/5874>
<mup> PR snapd#5875 opened: Avahi interface update <Created by kubiko> <https://github.com/snapcore/snapd/pull/5875>
<Chipaca> niemeyer: there's a change, with a new Admin section that has version, warnings, okay, and get, set and wait (meaning the old Config section went away)
<niemeyer> Chipaca: Hmm
<niemeyer> Chipaca: Sounds a bit awkward at first sight
<niemeyer> Chipaca: The whole of "snap foo" is admin
<pedronis> ogra: looks like is locally installed
<niemeyer> Chipaca: and get/set/wait seem unrelated to the rest
<pedronis> in which case I think that's the current behavior
<ogra> pedronis, indeed it is, i'm trying to develop as bunch of default connections for the interfaces
<ogra> (trying to test them before uploading indeed)
<ogra> ah, thats pretty unfortunate
<pedronis> ogra: we don't print a snap id for local snaps (even if there's a corresponding store one)
<ogra> i thought it would still pull the id from the store
<pedronis> that output is actually a bit confusing
<ogra> well, it results in the connections to not happening
<pedronis> yes, connections are only for store snaps
<pedronis> given they are snap id based
<ogra> yeah, thats a bit bad for developing ...
<ogra> would be nice if we could use some kind of fake id or some such ... i imaging other developers also would like to test their changes before pushing them to the store
<ogra> *imagine
<Chipaca> niemeyer: thing is, what we discussed didn't include warnings, so those need adding somewhere; i tried to iterate on this at the sprint but we were never not busy with other stuff :-)
<Chipaca> niemeyer: so I thought the second best thing would be to iterate in a PR
<niemeyer> Chipaca: Sure, and that's what we're doing here too I guess..
<pedronis> ogra: you can always push first as private snap
<Chipaca> niemeyer: dunno, I'm having lunch, not iterating
<pedronis> ubuntu-image gets annoying but possible
<ogra> pedronis, sure, i can also push just to edge and leave it there but preferably i'd like to test locally first
<niemeyer> Chipaca: Well, you're iterating on lunch.. agile style? :)
<ogra> anyway, i'll get around ... but it would be great to improve in that area
<Chipaca> niemeyer: not enough beer for this to be XP, so maybe it's scrum?
<mvo> Chipaca: dotfiles> I want it in but we can pull it into ~pre2 or ~rc1. it also need a proper name
<Chipaca> I think dotfiles is fine
<mvo> Chipaca: even better, less churn :)
<diddledan> has anyone tried calling a classic snap command from a process that is itself also a classic snap? does it work?
<mvo> Chipaca: I think it needs an ack from jamie, I addressed a bunch of things but I'm not sure if its all to his satisfaction
<diddledan> as in crossing the boundary between two classic snaps
<Chipaca> mvo: there's even a quora article about dotfiles
<Chipaca> mvo: I'm not sure if that's an argument for or against, but it's there
<mborzecki> re
<pedronis> mvo: are you thinking of cutting 2.36 ?
<mvo> pedronis: I was thinking after the meeting - anything pending on your side that should be in that is not milestoned?
<pedronis> mvo: yes, 4 PRs,  they should get to reviewable today or early tomorrow
<mvo> pedronis: ok
<mvo> pedronis: is it about the brand store work?
<pedronis> mvo: yes
 * mvo nods
 * zyga tries to join the standup ...
<popey> This is a fun error message...
<niemeyer> I'll be a couple of minutes late
<popey> https://www.irccloud.com/pastebin/0ofGh1tb/
<popey> (kodi isn't even installed)
<popey> Maybe it should say "snap "kodi" isn't installed" or something?
<popey> (you can easily reproduce this with "snap connect foo:bar"
<popey> )
<zyga> popey: I'll fix that, thanks!
<popey> np
<ogra> geez, just install kodi
<popey> kodi 18.0b2-Leia installed
<popey> ok!
<ogra> :D
<ogra> we have a leia snap ?!?!?
<popey> *I* do
<ogra> for armhf by chance ?
<diddledan> ok. the problem I'm encountering is specific to vscode then - it cannot launch the dotnet sdk cli which is in a separate classic snap - I've tried to do a reduced testcase but couldn't get that to fail, so something is screwey with the vscode snap
<popey> ogra: not yet
<diddledan> silly thing, though, is that using the inbuilt command line in vscode can launch the sdk cli
<ogra> popey, well, once you do ... i'd be a happy tester
<popey> bet you will
<ogra> UbuntuCoreElec !!!
<mup> PR snapcraft#2295 closed: tests: use SNAPCRAFT_PACKAGE_TYPE everywhere <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2295>
<mup> PR snapcraft#2296 closed: part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2296>
<mup> PR snapcraft#2297 closed: [legacy] part grammar processor: lazily capture attributes from plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2297>
<mup> PR snapd#5862 closed: cmd: fix C formatting <Simple> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5862>
<mup> PR snapcraft#2301 opened: tests: move most tests to spread and reorder travis.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2301>
<Chipaca> degville: I did the change in 'snap whoami' fwiw (as well as the new Other (miscelanea) category)
<degville> Chipaca: thanks! Sad I can no longer use my printer though.
<Chipaca> degville: just pipe it to "lp" and it'll work
<degville> ahaha!
<Chipaca> degville: I don't know if the unicode characters will work though, it might set it to banner mode and print you out of a home
<mvo> sil2100: who in foundations might know about translations ? I wonder who can approvehttps://translations.launchpad.net/snapd/trunk/+imports
<mvo> sil2100: https://translations.launchpad.net/snapd/trunk/+imports
<mvo> sil2100: someone with special powers needs to approve this one and I'm trying to find who that someone is :)
<Chipaca> degville: AIUI Miscellanea was a countable miscellany. Ignoring the typo, did I get that wrong?
<Chipaca> that is, they're synonyms, but miscellanea are countable and miscellany might not be
<Chipaca> but, maybe it's archaic
<Chipaca> :) you tell me
<diddledan> mvo: https://upload.wikimedia.org/wikipedia/en/thumb/e/eb/SupermanRoss.png/250px-SupermanRoss.png
<mvo> diddledan: I'm looking for that dude!
<diddledan> all the powers
<mvo> diddledan: in the old days it was dpm or danilo but I don't know about the present days :/
<sil2100> mvo: this is the part of translations that I have no power over! I think Gunnar is responsible for this now
<mvo> I will just pester random people until I find out more
<sil2100> mvo: let me poke him through e-mail, he'll at least know
<mvo> sil2100: nevermind
<mvo> sil2100: I got some help now from colin and hopefully thats enough I will keep in mind that gunnar is the guy
<mvo> sil2100: thanks!
<mup> PR snapd#5876 opened: selftest: rename selftest.Run() to sanity.Check() <Created by mvo5> <https://github.com/snapcore/snapd/pull/5876>
<Chipaca> mvo: do we do tarballs of releases on github?
<Chipaca> waaait, is this something github does automagically
 * Chipaca prods it
<zyga> Chipaca: yes we do
<zyga> we produce three dedicated tarballs
<Chipaca> yep, https://github.com/snapcore/snapd/releases
<Chipaca> looking at that now
<Chipaca> zyga: i can haz darwin in lab?
<zyga> mmm
<zyga> sure
<Chipaca> zyga: taw
<Chipaca> zyga: I can't even get to the lab, right now
<Chipaca> not sure why
<zyga> Chipaca: I turned it off (fan noise)
<zyga> Chipaca: note, it's updated to Mojave and home-brew is out
<zyga> so you need to re-do it
<Chipaca> ok
<zyga> when I looked at brew it suggested that I don't use sudo though
<zyga> so maybe something new?
<Chipaca> zyga: not use sudo, and instead what?
<zyga> brew
<zyga> I mean
<zyga> whatever you need :)
<mvo> Chipaca: why do you ask?
<Chipaca> mvo: because our brew formula currently is only a head formula, and I'd like to make it do releases instead
<Chipaca> so you can 'brew install snap' (as opposed to the current 'brew install --HEAD snap')
<Chipaca> s/as opposed/in addition/
<mvo> Chipaca: aha, nice
<diddledan> is that a brew formula for linuxbrew or homebrew (macOS) or both? if it's targeting homebrew in some way, how's that work??!
<Chipaca> diddledan: both
<Chipaca> although the linuxbrew one is incidental, the objective is homebrew
<Chipaca> diddledan: snap, the command, works on darwin
<Chipaca> diddledan: snapd does not
<sergiusens> diddledan: the same way it works for snapcraft on mac
<sergiusens> oh, ic, the how does that work is related to snapd
<diddledan> I figured snap would be useless without a snapd to control
<sergiusens> diddledan: we want the snap command avail since it is what holds the license field validation logic
<Chipaca> diddledan: the only thing stopping snapd from working via remote control is nasty humans
<Chipaca> (i.e., auth)
<diddledan> bah. filthy scum
<Chipaca> ikr
<Chipaca> zyga: your network is slow today :-(
<zyga> oh?
<zyga> not me
<zyga> maybe $family or weather
<Chipaca> zyga: taking *minutes* to download the go 1.11 bottle
<Chipaca> :)
<diddledan> try changing the tyres
<zyga> bad mirror?
<zyga> where are you fetching from?
<zyga> I see almost no traffic
<ogra> probably there is a detour sign outside your viallge
<ogra> *village
<Chipaca> dang, 2.35.2 did not build on darwin yet.
<Chipaca> mvo: how is the .vendor. tarball built? i'd like to test it with master
<Chipaca> that is, i need a tarball for a stable brew build, but the latest snapd_2.35.2.vendor.tar.xz doesn't cut it :-)
<mup> PR snapcraft#2290 closed: pluginhandler: update build should overwrite organize <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2290>
<Chipaca> mvo: also: can we make those tarballs come pre-generated? ie without needing mkversion etc?
<kyrofa> sergiusens, yeah, pip is doing something weird here
<kyrofa> pip install pymacaroons==0.9.2 actually does the right thing
<kyrofa> But using the requirements.txt seems to be getting 0.9.0
<kyrofa> It's interesting because pip freeze shows 0.9.2, then I actually look at it and its __init__ shows 0.9.0
<pedronis> fun, if I add an empty TearDownTest to one of the suites in snapstate some unrelated tests fail :/
<zyga> Chipaca: look at release-tools
<zyga> Chipaca: there's a script for it
 * Chipaca looks around for a Neal
<mup> PR snapcraft#2280 closed: Use the better snapcraft.io/account URL <Created by evandandrea> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2280>
<zyga> Pharaoh_Atem: ^
 * Pharaoh_Atem pops in
<Pharaoh_Atem> what?
<zyga> Chipaca: ^
 * zyga runs
<Chipaca> heh
<Chipaca> Pharaoh_Atem: hola
<Pharaoh_Atem> aloha!
<Pharaoh_Atem> I'm confused, what's going on here?
<Chipaca> Pharaoh_Atem: is the tarball (as in https://github.com/snapcore/snapd/releases) used as part of the rpm build at any point?
<Pharaoh_Atem> yes
<Chipaca> Pharaoh_Atem: do you need to hoop through jumps to get the version?
<Pharaoh_Atem> nope, I set the version in the spec, and propagate it down to everything
<Chipaca> Pharaoh_Atem: I mean, the mkversion.sh script
<Chipaca> Pharaoh_Atem: you don't use it /  do things differently?
<Pharaoh_Atem> I use it
<Pharaoh_Atem> ./mkversion.sh %version-%release
<Pharaoh_Atem> that's in the spec file for every snapd package derived from my packaging
<Chipaca> ahhh
<Chipaca> fair enough
<Chipaca> Pharaoh_Atem: ok
<Chipaca> Pharaoh_Atem: thanks
<Pharaoh_Atem> no problem
<Chipaca> I might just do that on darwin as well, then
<Chipaca> if I can figure out the equivalent in brewish
<Pharaoh_Atem> https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd.spec#_403-404
<Pharaoh_Atem> brew has a version variable
<Chipaca> I was going to do a bunch of work to make mkversion itself figure it out but this is easier
<Chipaca> Pharaoh_Atem: and a revision! :-)
<Pharaoh_Atem> hold on, I did this recently when I packaged rpm for homebrew
<Chipaca> ooohh
<Chipaca> Pharaoh_Atem: https://formulae.brew.sh/formula/rpm ?
<Pharaoh_Atem> yeah
<Pharaoh_Atem> I rewrote that formula
<Pharaoh_Atem> I think #{VERSION} is defined?
<Chipaca> ah
<Pharaoh_Atem> I know it does some introspecting from the tarball name
<Chipaca> lowercase, at  least, works
<Chipaca> ie #{version}
<Pharaoh_Atem> cool
<Chipaca> yep
<Pharaoh_Atem> yeah, ruby is weird
<Chipaca> thanks!
<Pharaoh_Atem> no problem ;)
<ogra> niemeyer, mvo, zyga https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603 any thoughts here would be appreciated
<Pharaoh_Atem> most things tend to behave like rpm spec files :D
<Pharaoh_Atem> ogra: shit
<Pharaoh_Atem> that explains the bugs I'm getting in Fedora
<Pharaoh_Atem> our nsswitch.conf is getting blown away and breaking things
<zyga> ogra: hmm
<zyga> ogra: yeah, tough choice
<zyga> maybe it should be writable?
<zyga> and snap might manage that somehow
<Pharaoh_Atem> https://bugzilla.redhat.com/show_bug.cgi?id=1596753
<Pharaoh_Atem> zyga, ogra ^
<zyga> Pharaoh_Atem: we should not be mounting anything on the host
<zyga> unless the code is broken
<zyga> but then all hell would break lose
<Pharaoh_Atem> maybe it is, just not on Ubuntu :(
<zyga> we test it on fedora dozens of times a day
<Pharaoh_Atem> this is not the only file that we're having problems with caused by snapd
<ogra> Pharaoh_Atem, heh
<zyga> Pharaoh_Atem: can you see weird mounts on your snap running system?
<zyga> if not then we are not doing that (or you are not using any snaps)
<Pharaoh_Atem> zyga: I'll check in a bit, when I can get to my snap dev environment
<zyga> ok
<Pharaoh_Atem> I've removed snapd and snaps from my main workstation because it kept breaking things
<zyga>  /o\
<Pharaoh_Atem> I had no choice, I can't have a broken workstation at work
<Pharaoh_Atem> I had snapd on here for a while to play around with base snaps and building fedora based layered snaps
<ogra> Pharaoh_Atem, i'D appreciate a comment on the thread indeed :)
<Pharaoh_Atem> ogra: commented: https://forum.snapcraft.io/t/no-mdns-support-in-snaps-should-core-have-a-modified-nsswitch-conf/7603/2
<Pharaoh_Atem> zyga, ogra, the really challenging problem is that I have no idea what is causing this
<Pharaoh_Atem> the best I can guess is that something is doing a read+writeback and because we can't operate in strict confinement, it actually hits the filesystem and breaks things
<ogra> Pharaoh_Atem, thanks !
<mvo> Chipaca: I will merge 5865 now but if my question inline is valid please do a followup (if not even better :)
<Chipaca> what was 5865?
 * Chipaca looks
<mvo> Chipaca: the translation comments
<Chipaca> mvo: aww
<Chipaca> mvo: 5856 was the one i wanted in :-)
<mup> PR snapd#5865 closed: cmd/snap: add a bunch of TRANSLATORS notes (and a little more i18n) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5865>
<Chipaca> so close
<Chipaca> mvo: :-) tahnks
<mvo> Chipaca: heh, the --help one has a +1 from me already
<Chipaca> mvo: grah, you're right about them not being the same
<Chipaca> drat it
<mvo> Chipaca: but if degville gives a +1 too â¦
<mvo> Chipaca: no worries
<mvo> Chipaca: just do a followup and all is good
<Chipaca> okk
<mvo> Chipaca: ta!
<mvo> Chipaca: uh and 5856 has a conflict now :/
<Chipaca> mvo: tests for 5856 haven't started yet, otherwise it's gtg imo
<Chipaca> of _course_ it does
<Chipaca> :-)
<mvo> Chipaca: the help one only had a single +1 so far, no? /me double checks
<mvo> Chipaca: aha, silly me, two +1, one from degville  earlier. so yeah, ready once tests are happy :)
<degville> :)
<Chipaca> and conflcits
<Chipaca> mvo: how easy is it for you to build a fake tarball (like the ones in https://github.com/snapcore/snapd/releases)?
<mup> PR snapd#5873 closed: tests/main/parallel-install-store: run installed snap <Parallel installs> <Simple> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5873>
<Chipaca> mvo: I tried doing it starting from dpkg-buildpackage of the git checkout and got into trouble :-)
<mvo> Chipaca: the release ones? trivial: "gbp buildpackage -S" and ./release-tools/repack-tarball ../build-area/*.tar.xz
<mvo> Chipaca: do you want one?
<Chipaca> mvo: of ~master, I could use one to test brew stable build, yes
<Chipaca> mvo: I can point it at any url (and then switch it back to github when that's done)
<Chipaca> mvo: OTOH, I can also wait for the actual tarball
<Chipaca> it's not going to land before that
<mvo> Chipaca: building one for you now
<mvo> Chipaca: try http://people.canonical.com/~mvo/.chipaca/
<Chipaca> mvo: <3
 * zyga is starving
<Chipaca> woooooo, that worked :-D
<Chipaca> mvo: thanks again
<mup> PR snapcraft#2040 closed: lifecycle: always prime dependencies <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2040>
<mvo> Chipaca: \o/ great to hear that it works :)
<rbasak> kyrofa: on the subject of testing edge, I'm looking to land a git-ubuntu regression fix and our CI is failing because our CI is using snapcraft from edge. I'm reluctant to switch it to use beta because then I wouldn't be testing edge, which is useful :)
<rbasak> Not sure what I want exactly. I thought I'd mention the situation.
<kyrofa> rbasak, yeah, tough situation. I think we've figured out the fix, if it helps
<mup> PR snapd#5856 closed: cmd/snap: tame the help zoo <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5856>
<Chipaca> mvo: weee
<mvo> Chipaca: !!!
 * mvo hugs Chipaca 
<Chipaca> and go-flags master is working again :-D
<mvo> zyga: 5870 looks like you almost gave a +1
<Chipaca> some of our tests broke because now it's better :-)
<mvo> Chipaca: haha
<Chipaca> one of the fixes was that before it left space for all options, even if some of them were hidden
<mvo> Chipaca: the update will be a small burden on debian as they will also need to update the package
<Chipaca> you can see that in 'snap help prefer' for ex
<mvo> Chipaca: cool, thanks for fixing this!
<Chipaca> this assumes all the tests are ok, now, of course :-)
<Chipaca> grmbl
<mup> PR snapd#5583 closed: cmd/snapd,daemon,overlord: without snaps, stop and wait for socket <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5583>
<Chipaca> zyga: i'm done with the lab, thanks
<mup> PR snapcraft#2302 opened: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2302>
<mup> PR snapcraft#2303 opened: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2303>
<zyga> mvo: looking at 5870
<Chipaca> so, we were using a bug in go-flags :-(
<Chipaca> sad trombone
<zyga> Chipaca: oh?
<zyga> Chipaca: cool, what did you find?
<Chipaca> we use PassAfterNonOption
<Chipaca> but only really use it in 'snap run'
<zyga> Chipaca: is it the time when we roll our own?
<Chipaca> nah
<zyga> or do we have a way to fix it
<Chipaca> bah, I think this is fixable
<Chipaca> in a few ways
<Chipaca> but the basic thing is: PassAfterNonOption means "be strict POSIXly"
<Chipaca> there was a bug in go-flags where it didn't actually do its job
<Chipaca> so you could have "snap install foo --classic" mean the same as "snap install --classic foo"
<Chipaca> which is explicitly not what PassAfterNonOption should do: with PassAfterNonOption, the first --classic is no longer an option
<Chipaca> it's an argument, and is passed to the command's Execute as such
<Chipaca> but of course we want "snap run http --help" to have that help reach http
<Chipaca> so
<Chipaca> easy fix: require everybody using snap run directly to do "snap run -- http --help
<Chipaca> "
<Chipaca> hacky fix: peek at os.Args, and rewrite it to add a -- for 'snap run'
<Chipaca> the first one is trivial, only really affects tests on our end
<Chipaca> snapped apps continue to work, because we'd add the -- ourselves
<Chipaca> only people we'd be breaking are those that use 'snap run' with arguments
<Chipaca> but â¦ that's probably some people
<Chipaca> so, leaning towards the hacky don't-break-people one
<sergiusens> Chipaca: the joys of wanting to mix strict arg parsing with friendly arg parsing :-)
<zyga> Chipaca: still hear?
<zyga> here
<Chipaca> yes
<zyga> I have a branch with the Mk** helpers moved
<zyga> it's a bit big
<zyga> wanna see?
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/5877 I opened for RFC
<mup> PR #5877: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
<mup> PR snapd#5877 opened: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
<Chipaca> zyga: hmmm
<Chipaca> zyga: are you all hyped up, or are you wrapping up your day?
<zyga> more of a task switching
<zyga> this was a distraction today
<zyga> I'm working on something more involved
<zyga> also upset about MBP - still not fixed
<zyga> and apparently service people broke the screen /o\
<zyga> at this rate I'll get crumbs next week
<zyga> iCrumbs
<zyga> it was such a nice machine
<Chipaca> zyga: official service?
<zyga> not real apple but authorised services
<zyga> I'm sure they will fix it
<zyga> (or just give me a brand new unit)
<zyga> but ... what the hell happened
<zyga> maybe I should just not think more about it
<zyga> and just wait patiently
<zyga> and not get more gray
<zyga> next time I'll open it in the store
<zyga> and just ask for a different unit
<zyga> and let them turn gr{a,e}y
<zyga> which is it?
<zyga> anyway
<Chipaca> zyga: depends on where you're standing when you say it
<Chipaca> anyway, it's 19:40, I need to make dinner
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/5877 landing would make me happy
<mup> PR #5877: cmd/snap-update-ns,osutil: move helpers to osutil <Created by zyga> <https://github.com/snapcore/snapd/pull/5877>
<zyga> and I can then go and rest
<zyga> you're right, EOD time
<Chipaca> and instead I'm knee deep in making our thing work with the new go-flags
<Chipaca> zyga: I'll look at that last one after dinner, k?
<zyga> er
<zyga> no no wrong branch
<zyga> but sure
<Chipaca> well, leave the one you want me to look at
<Chipaca> if it's too big, i'll punt
<zyga> meant https://github.com/snapcore/snapd/pull/5869
<mup> PR #5869: snap: detect layouts vs layout in snap.yaml <Simple> <Created by zyga> <https://github.com/snapcore/snapd/pull/5869>
<Chipaca> otherwise i'll sleep at 3am again
<zyga> :-)
<Chipaca> ttfn
<zyga> ttyl
<JohK> hi
<JohK> how do I get snap apps to work when my home is symlinked to a different drive?
<gQuigs> is there something obvious I'm doing wrong here: https://pastebin.ubuntu.com/p/jgMBPYSYBz/   following workaround from forum - https://forum.snapcraft.io/t/importerror-no-module-named-six/1002/3
<JohK> I get similar errors to what users report when their home is on a nfs mount
<JohK> i.e. for pycharm or spotify
<ogra> JohK, stop using a symlink and use a bind mount instead
<zyga> JohK: hey, as ogra said you must use a bind mount instead
<zyga> or just mount your home directory to /home/$LOGNAME
<JohK> I use this setup for 15 years...
<JohK> ogra: Really? I use this setup for 15 years...
<JohK> ogra: why is not having a symlink a requirement for snap to work?
<JohK> well I guess Im not using snapd then, thx
<zyga> because symlinks and real directories are not the same, have fun with your setup for the next 15 years
<mup> PR snapd#5878 opened: overlord/ifacestate: make sure to pass in the Model assertion when enforcing policies <Created by pedronis> <https://github.com/snapcore/snapd/pull/5878>
<Chipaca> zyga: chill
<Chipaca> zyga: you there?
<zyga> yes
<Chipaca> zyga: comment on your pr
<Chipaca> zyga: and a suggestion coming up in diff form
<zyga> on 5877?
<Chipaca> zyga: https://pastebin.ubuntu.com/p/V2NbGY6GPp/
<Chipaca> 5869
<zyga> ah
<zyga> did you see what the error looks like if you try that?
<Chipaca> zyga: yes
<zyga> it's less sublime, talking about unmarshaling and such
<zyga> AFAIR, it was less pretty than now
<Chipaca> 1 sec
<Chipaca> $ snap pack . ..
<Chipaca> error: cannot pack ".": cannot parse snap.yaml: cannot use "layouts" (plural), please use singular "layout" instead
<zyga> we _can_ parse snap.yaml
<zyga> we just don't like what we found
<zyga> and without the extra change?
<Chipaca> zyga: without which extra change?
<zyga> I mean, without your suggestion
<Chipaca> zyga: it's in the comment: error: cannot pack ".": cannot use "layouts" (plural), please use singular "layout" instead
<zyga> hmm
<Chipaca> quite
<Chipaca> and this is with pack, where you know at least that you're building this
<zyga> I was thinking about making a error type and returning it instead
<zyga> and tweaking the error reception in the client
<Chipaca> imagine getting Â«cannot install "foo": cannot use "layouts"Â»
<zyga> but I think it's too late for that today, I was about to hit the bed
<zyga> but I'll try both tomorrow
<Chipaca> zyga: ?
<zyga> and see if the error looks nice in all cases (I was thinking of "snap try" mostly)
<Chipaca> zyga: there is no client/server for 'snap pack'
<zyga> you can make a snap with older version and install it
<zyga> that's what I meant, sorry for not being clear
<zyga> I'll continue tomorrow :)
<Chipaca> ok
<Chipaca> zyga: g'night
<Chipaca> i'm off as well
<mup> PR snapd#5879 opened: vendor, cmd/snap: refactor to accommodate the new less buggy go-flags <Created by chipaca> <https://github.com/snapcore/snapd/pull/5879>
<sergiusens> stgraber: hey there, everytime my lxd snap updates (just did recently) my container(s) die(s); from what I recollect this should not be the case so wondering if there is a way to monitor what is going on
<stgraber> sergiusens: what channel?
<stgraber> sergiusens: journalctl -u snap.lxd.daemon -u 500
<sergiusens> stgraber: latest/stable is where I saw it just now
<sergiusens> stgraber: exit with 137
<sergiusens> stgraber: for context https://pastebin.ubuntu.com/p/8qc6VHhNsW/
<stgraber> sergiusens: "dmesg" output?
<sergiusens> stgraber: maybe this https://pastebin.ubuntu.com/p/wH2WCMFjsD/ ?
<sergiusens> stgraber: I can hand over the full output if you want too
<stgraber> sergiusens: nah, unrelated, full output please
<stgraber> sergiusens: also, the journalctl didn't show you anything more than what you pasted? that was way shorted than 500 lines
<sergiusens> there's more in the journal, I'll send over
<sergiusens> stgraber: full journal https://pastebin.canonical.com/p/39DRDZBXtm/
<sergiusens> to any other person, sorry for the private link, but I haven't checked if this leaks any sensitive data ð
<stgraber> sergiusens: full dmesg?
<stgraber> sergiusens: ah and "snap version" too please?
<sergiusens> stgraber: https://pastebin.canonical.com/p/CMxrySp2cB/
<sergiusens> stgraber: http://paste.ubuntu.com/p/Q3Y5mjjj54/
<stgraber> sergiusens: "snap changes" output?
<sergiusens> stgraber: I think you want this specific change http://paste.ubuntu.com/p/mRqcZrcPyv/
<sergiusens> an autorefresh change that is
<sergiusens> hmm, let me see if I can get those out in english client side
<sergiusens> meh, no
<sergiusens> """Detener los servicios del snap "lxd"""" translates to """Stopping services from the snap "lxd""""
<stgraber> oh, that's actually very interesting
<stgraber> well, maybe not
<stgraber> can you show me cat /proc/$(pgrep daemon.start)/environ | tr '\0' '\n'?
<sergiusens> right, it doesn't say exactly if it will ignore the stop or not after going in
<stgraber> well, no, it not being in english is the interesting part :)
<stgraber> because we parse that in our stop code
<stgraber> but the environment of the stop code should be such that it's in english
<sergiusens> stgraber: my locale at installation time is spanish https://pastebin.canonical.com/p/zsw3RDXCtP/
<stgraber> crap, I didn't expect systemd to respect it :)
<sergiusens> this is why we don't do translations for these things :-P
<stgraber> sergiusens: LANG=C.UTF-8 snap changes
<sergiusens> stgraber: tried that already :-)
<sergiusens> stgraber: so it means the changes are generated by snapd, they are also ephemeral, so I suppose that restarting snapd will kill the changes
<stgraber> snapd stores them as a string in the user's language?
<sergiusens> I am not sure about that, I hope not; but I do suppose that snapd returns output to the snap command already in the set lang
<stgraber> oh, so the daemon is returning translated strings then, great...
<sergiusens> yes, it seems so
<sergiusens> it wouldn't be that bad if the client could tell it the language it wanted those strings in
<sergiusens> but alas, that does not seem to be the case
<stgraber> do you know if there's some new way for us to figure out if we're dealing with a unit restart due to refresh vs unit restart due to host shutdown?
<sergiusens> stgraber: given the timestamps, this is certainly a refresh; change 19 which I pasted is from auto-refresh
<sergiusens> I was actually doing something else when I saw the container go away
<stgraber> sergiusens: yeah, I'm sure that's the problem, I'm just looking for ways to fix it which don't involve me hardcoding strings for every language we may get back from snapd :)
<stgraber> sergiusens: curl --unix-socket /run/snapd.socket snapd/v2/snaps/lxd -s | jq .result.status
<stgraber> sergiusens: is this in english?
<sergiusens> fwiw https://forum.snapcraft.io/t/snap-snapd-language/7607
<sergiusens> stgraber: yes, that is in English
<sergiusens> returned "active"
<stgraber> sergiusens: unfortunately that won't quite be enough as it won't tell me if the snap is being removed, poking at the /changes API instead now
<sergiusens> ok, I will have to commute back home right now, but I can get back to this in a bit, just leave me anything required to check
<stgraber> sergiusens: curl --unix-socket /run/snapd.socket snapd/v2/changes?select=all\&for=lxd -s | jq -r ".result | .[] | .kind"
<stgraber> I think that will be our way out of this problem, much more reliable than parsing snap changes
<stgraber> sergiusens: wrote a new query tool that pokes the API directly, building a new snap with that, will test tomorrow (in Europe now, so a bit late here)
#snappy 2018-09-28
<zyga> o/
<pstolowski> mornings
<zyga> Hey PaweÅ
<zyga> Quite a quiet
<zyga> Morning :-)
<zyga> Making coffee, I somehow could not wake normally
<pedronis> seems there's a new gccgo version in bionic and we are hitting a bug that is fixed only in newer dh-golang
<pedronis> gccgo tests have started failing on 18.04
<pedronis> mmh
<zyga> pedronis: oh, do you have a bug reference?
<zyga> shall we disable 18.04 for the weekend so that we can keep pushing things?
<pedronis> we get this:  https://paste.ubuntu.com/p/GVvz4qq4hY/
<pedronis> there's a debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907263
<zyga> pedronis: perhaps we can pin the previous version of the package if it is still in the archive
<zyga> thank you, looking
<pedronis> that mentions dh-golang 1.35 to have the fix,  but bionic has still only 1.34
<zyga> or we can add a ppa with dh-golang 1.35 perhaps
<wgrant> Have you reported the critical SRU regression?
<pedronis> not yet
<pedronis> it took me a while to understand it was not new code
<pedronis> but new package
<pedronis> version
<wgrant> doko: ^^
<joelkraehemann> hi all
<joelkraehemann> Do all snap packages need manual review or is it only because the warning showing?
<zyga> joelkraehemann: hello, what warning is that?
<zyga> joelkraehemann: normally snap package do not require a manual review
<joelkraehemann> zyga: great to know. I was using experimental layouts but for now I pass the environment variable $AGS_SNAP_PATH
<joelkraehemann> ... and no more layouts
<zyga> joelkraehemann: yeah that _may_ trigger a manual review for now, I'm trying to get that to be enabled by default
<joelkraehemann> what do you think, when is it enabled by default?
<zyga> I'd like to do that for the 2.36 release
<zyga> there's a PR for that
<zyga> some people are going to be off today so I don't know if it will land yet
<zyga> probably monday
<joelkraehemann> nice
<zyga> pedronis, wgrant: so shall we file a bug for this and wait?
<wgrant> zyga: File a bug, tag it with regression-update, and ping the uploader and/or release team on IRC
<wgrant> s/release/SRU/
<zyga> kk
<wgrant> https://wiki.ubuntu.com/StableReleaseUpdates#Regressions
<zyga> thank you!
<Chipaca> moin moin
<Chipaca> mwhudson: o/
<zyga> pedronis: so gccgo is the faulty package?
 * zyga tries to phrase the bug report
<Chipaca> mwhudson: if we have 1.10 in 16.04 etc, that still wouldn't pull gccgo equivalent in, right?
<pedronis> zyga: https://bugs.launchpad.net/ubuntu/+source/dh-golang/+bug/1794936
<mup> Bug #1794936: new gccgo version update ()  is triggering dh-golang bug <dh-golang (Ubuntu):New> <gcc-defaults (Ubuntu):New> <https://launchpad.net/bugs/1794936>
<zyga> ah, thanks,
<mborzecki> morning
<pedronis> zyga: it's not a bug on gccgo but things will fail with dh-golang unless we also get a new dh-golang
<zyga> pedronis, wgrant: I added the regression-update tag to your bug
<mborzecki> starting later than usual, had to run an errand
<Chipaca> mwhudson: maybe I should ask this question on the bug
<pedronis> zyga: I tried to mention both packages, but gcc packages are a maze, not sure I picked the right one
<zyga> yeah, I was lost at gcc-defaults, dh-golang is easier
<wgrant> Retargeted at gcc-8
<wgrant> Which was the SRU that broke things
<Chipaca> pedronis: should we skip  gccgo tests on 18.04 until this is sorted?
<mup> PR snapd#5868 closed: tests/main/snap-env: extend to cover parallel installations of snaps <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5868>
<mup> PR snapd#5872 closed: tests/main/parallel-install-local: rename from *-sideload, extend to run snaps <Parallel installs> <Simple> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5872>
<pedronis> Chipaca: I suppose
<mborzecki> zyga: can you take a look at https://github.com/snapcore/snapd/pull/5870 ?
<mup> PR #5870: tests/main/parallel-install-services: add spread test for snaps with services <Parallel installs> <Simple> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5870>
<pedronis> is michael off today?
<zyga> pedronis: I think so
<zyga> mborzecki: yes
<zyga> pedronis: I've asked him in private
<zyga> pedronis: confirmed
<pedronis> Chipaca: a 2nd review of #5824 would be appreciated
<mup> PR #5824: fetch the device store assertion together and in the context of interpreting snap-declarations <Created by pedronis> <https://github.com/snapcore/snapd/pull/5824>
<mborzecki> zyga: thanks!
<ogra> ppisati, your kernel patch works great !
<mup> PR snapd#5880 opened: interfaces/repo: two helper methods for houtplug <Created by stolowski> <https://github.com/snapcore/snapd/pull/5880>
<Chipaca> pedronis: should the assertion fetchers get a context at some point?
<Chipaca> to be cancelable i mean
<pedronis> maybe, at some point
<Chipaca> pedronis: maybe as part of the move to bulk
<Chipaca> tbh this code with functions getting functions that get passed functions is not super easy to follow :-)
<pedronis> Chipaca: we have a bigger problem, in this sense that we fetch assertions from sync places
<mup> PR snapd#5870 closed: tests/main/parallel-install-services: add spread test for snaps with services <Parallel installs> <Simple> <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5870>
<pedronis> (for good reasons but it will not end well at some point)
<Chipaca> mhmm
<Chipaca> not that I'd spotted it, but yes it sounds like trouble
<pedronis> it's totally preexistent
<pedronis> and it's a potential issues with hundreds of snaps
 * Chipaca hopes popey isn't listening
<popey> *ears prick up*
<pedronis> anyway we really have a problem that is either sync  or changes
<pedronis> we don't have an inbetween to do things
<popey> what's up?
<Chipaca> popey: talking about things that can't ever happen, ever ever
<Chipaca> popey: unless somebody had hundreds of snaps
<popey> alan@hal:~$ snap list | wc -l
<popey> 234
<Chipaca> pedronis: which sync things do this?
<popey> Who would do such a thing?
<pedronis> Chipaca: snap refresh
<Chipaca> popey: IKR
<Chipaca> pedronis: ah, it does it as part of pre-changes work?
<pedronis> yes
<pedronis> since forever
<Chipaca> shouldn't be too hard to move it into a change then
<pedronis> it is
<Chipaca> he says, like an idiot
 * Chipaca grins
<pedronis> remember why we moved pre-flight checks out of changes
<pedronis> it would undo that
<Chipaca> TBH, I don't remember why, but I'm sure it's a good reason
<Chipaca> (and I can re-remember it by reading, probably)
<Chipaca> anyway, this isn't landing PRs
<pedronis> to be fair it was specifically about downloads
<pedronis> so maybe there's a why
<pedronis> but is not a simple change
<pedronis> s/why/way/
<ogra> hmm ... does the prepare_device hook of a gadget snap only run at the end after all snaps have been processed ? ... when i set a hostname from that hook and have avahi installed, the name resolution only works after a reboot
<pedronis> ogra: it was not defined exactly
<ogra> ah
<pedronis> it might have been changed recently tough
<pedronis> I need to go look
<ogra> should the install hook run earlier ?
<pedronis> which install hook?
<pedronis> of the gadget
<pedronis> ?
<ogra> yeah
<ogra> i see the gadget beinmg processed before the app snaps
<pedronis> yes
<ogra> so perhaps thats the better choice
<ogra> ok
<pedronis> it's core kernel gadget apps
<pedronis> that is well defined
<ogra> somehow the name tricked me that prepare_device runs before anything else :)
<ogra> will use install then
<pedronis> ogra: with 2.35 or so  prepare-device is strictly after seeding
<ogra> yeah, that explains the behaviour
<pedronis> Chipaca: zyga: do you remember whether we have anywhere bash code that make choices based on comparing snapd version in the spread tests?
 * zyga thinks
<zyga> apart from debian control scripts I don't think we do
<Chipaca> pedronis: we have tests that fail if the version is not what's expected, but I don't think that's what you mean
<pedronis> I would like to do something in upgrade/basic only if the old snapd is newer than 2.35
<Chipaca> it actually might be the prepare bit of the test tbf
<pedronis> but writing might be a pain
<pedronis> the issue really affects only debian in practical terms (the relevant change is actually older than 2.35)
<Chipaca> pedronis: i thought we had a compare-versions in there but can't find it
<pedronis> thought the same
<pedronis> but not clear how to write portably except with python or something
<pedronis> (we can't assume dpkg anymore)
<Chipaca> pedronis: 'snap version --greater-than "$otherversion"'?
<Chipaca> maybe python is easier :-)
<pedronis> by definition the old snap will not have that
<pedronis> anyway I might just do something blunter
<pedronis> Chipaca: thx for the review
<Chipaca> np
<mup> PR snapd#5881 opened: tests: disable gccgo tests on 18.04 for now, until dh-golang vs gccgo are fixed <Created by pedronis> <https://github.com/snapcore/snapd/pull/5881>
<pedronis> Chipaca: zyga: ^
<zyga> ack
<Chipaca> pedronis: Error executing google:ubuntu-16.04-64:tests/main/interfaces-accounts-service
<Chipaca> Error: GDBus.Error:org.freedesktop.DBus.Error.InvalidArgs: Type of message, '(ssssa{ss})', does not match expected type '(sssa{sv}a{ss})'
<pstolowski> Chipaca: looks like the elusive error we see very sporadically on spread tests
<Chipaca> mhmm
<Chipaca> pstolowski: go away you're sick
<pstolowski> (i saw it a couple of times over last few months)
<zyga> travis is slooow
<Chipaca> wow, I hadn't realise we were doing ~1k commits per release
<Chipaca> sounds like a lot
<pstolowski> zyga: commented on #5867
<mup> PR #5867: many: enable layouts by default <Created by zyga> <https://github.com/snapcore/snapd/pull/5867>
 * Chipaca takes a break
<zyga> pstolowski: thanks
 * zyga -> walk
<doko> snappy is using golang?
<zyga> doko: yes
<doko> zyga: please ask mwhudson about that
<Chipaca> doko: about what?
<mup> PR snapd#5881 closed: tests: disable gccgo tests on 18.04 for now, until dh-golang vs gccgo is fixed <Created by pedronis> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5881>
<Chipaca> woohoo
 * Chipaca merges master
<pstolowski> yess
<Chipaca> travis now experiencing stampeding herd of snapd PRs
<ogra> pedronis, (not sure you are the right person, but i'll ask anyway) is there a way for me to obtain the model name from a hook in the gadget (i would like to set the default hostanme to the model name on frst boot) ... without having snapd-control ?
<ogra> (would "snapctl known model" work without extra interface ?)
<mup> PR snapcraft#2302 closed: requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2302>
<mup> PR snapcraft#2303 closed: [legacy] requirements.txt: stop using pymacaroons-pynacl <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2303>
<pedronis> ogra: not atm
<pedronis> there are some argument that we could have snapctl ack and snapctl known at least for gadgets but they are not there atm
<ogra> hmm, ok
<ogra> thats sad ... since it means i'll need one gadget per image type
<ogra> thanks anyway !
<stgraber> sergiusens: so in theory we have the new logic in place in both edge and stable snaps now, the next upgrade will still be bad for you (because it's running the old stop logic) but hopefully you'll be good after that
<sergiusens> stgraber: nice, can I see the PR that implements this? Just for curiosity
<sergiusens> I am glad I raised it then too
<stgraber> sergiusens: https://github.com/lxc/lxd-pkg-snap/commit/82950207244f445ad9c59ab22967ab20c002bd25
<pstolowski> hmmm, snapcraft tells me this: The linker version '2.23' used by the base 'core' is incompatible with files in this snap:
<pstolowski> kyrofa: hey, any idea ^? i'm not doing anything with bases in the snap i'm building. snapcraft installed from snap, i presume it's the base of the snapcraft?
<sergiusens> stgraber: looks much more robust
<sergiusens> pstolowski: it means you are probably not building on 16.04
<mup> PR snapd#5882 opened: many:  support and consider store friend-stores when checking device scope constraints <Created by pedronis> <https://github.com/snapcore/snapd/pull/5882>
<stgraber> sergiusens: yep and the type field really shouldn't be translated :)
<pstolowski> sergiusens: indeed, i'm on 18.04
<jdstrand> popey, Wimpress: hi! can one of you comment on https://forum.snapcraft.io/t/requesting-approval-for-goreleasers-classic-snap/6571/9?
<zyga> jdstrand: hey
<zyga> jdstrand: gentle ping for https://github.com/snapcore/snapd/pull/5395
<mup> PR #5395: interfaces: generalize writable mimic profile <Created by zyga> <https://github.com/snapcore/snapd/pull/5395>
<jdstrand> zyga: I know, sorry
<zyga> sure, I understand
<zyga> Chipaca: standup?
<Chipaca> omw
<sergiusens> jdstrand: I commented
<sergiusens> jdstrand: fwiw, it was elopio and myself who were involved in that
<mup> PR snapd#5824 closed: many: fetch the device store assertion together and in the context of interpreting snap-declarations <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5824>
<jdstrand> sergiusens: ah, thanks :)
<jdstrand> Wimpress, popey: sergiusens responded to https://forum.snapcraft.io/t/requesting-approval-for-goreleasers-classic-snap/6571/12, but can one of you vet the publisher?
<popey> done
<kenvandine> zyga: found a snapd bug in the cosmic live session https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1794953
<mup> Bug #1794953: GNOME Calculator snap has wrong theme in live session <rls-cc-tracking> <gnome-calculator (Ubuntu):Invalid by ken-vandine> <snapd (Ubuntu):New> <gnome-calculator (Ubuntu Cosmic):Invalid by ken-vandine> <snapd (Ubuntu Cosmic):New> <https://launchpad.net/bugs/1794953>
<kenvandine> zyga: permission denied errors mounting the content interface
<Chipaca> https://pastebin.ubuntu.com/p/nYmtwkYWXp/ :-D
<Chipaca> niemeyer: new category, or should I put them into "other"? ^
 * niemeyer look
<niemeyer> s
<Chipaca> we still have space for a few more categories, fwiw
<zyga> kenvandine: hey
<niemeyer> Chipaca: That seems to fit nicely into a "Snapshots" one
<Chipaca> yerp
<niemeyer> Chipaca: Nice tests, btw
<zyga> kenvandine: interesting, can you add the apparmor denials please?
<Chipaca> niemeyer: :)
<kenvandine> sure
<zyga> I need coffee, brb
<mup> PR snapd#5833 closed: asserts,interfaces/policy: add support for on-store/on-brand/on-model plug/slot rule constraints <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5833>
<kenvandine> zyga: added to the bug
<kenvandine> zyga of particular interest is the content interface for gnome-3-26-1604 must be mounting just fine
<kenvandine> it's only gtk-common-themes
<zyga> re!
<zyga> man
<zyga> I put the powdered coffee beans into the mug
<zyga> Sep 28 14:08:52 ubuntu kernel: [ 68.310240] audit: type=1400 audit(1538143732.840:235): apparmor="DENIED" operation="open" profile="snap-update-ns.gnome-calculator" name="/upper/snap/" pid=6535 comm="3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<zyga> that's the thing
<zyga> well, I can look at that next week
<kenvandine> zyga: thanks, that bug is a cosmic release blocker
<kenvandine> zyga: just FYI
<zyga> yeah, no pressure ;)
<zyga> it's not an LTS, right? ;-)
<kenvandine> lol
<kenvandine> willcooke: ^^ FYI zyga's on the case
<willcooke> thanks chaps
<zyga> I assigned it to myself
<zyga> well
<zyga> kenvandine: while I have you
<zyga> do you have the session open?
<kenvandine> yes
<zyga> can you poke at one file please
<zyga> let me give you the details
<zyga> can you go to /var/lib/snapd/apparmor/snap-confine
<zyga> and tell me what you have there
<zyga> there _should_ be a file called "overlay-root" there
<kenvandine> yes
<zyga> kenvandine: can you also share /proc/self/mountinfo from the live session
<zyga> and if the file is there, pastebin the file please
<kenvandine> http://paste.ubuntu.com/p/PhsbzsCzZ8/
<kenvandine> zyga: and just to confirm, there is just one file in snap-confine, overlay-root
<zyga> hmmm
<zyga> that's very cool
<zyga> but ...
<zyga> something new in the kernel apparently
<zyga> what's in the overlay-root file?
<zyga> look at the mount table you pasted
<zyga> the Wally is /cow
<zyga> where's Wally?
<zyga> is there a /cow directory?
<kenvandine> overlay-root has "/upper/{,**/}" r,
<kenvandine> there is no /cow
<zyga> 29 1 0:24 / / rw,relatime shared:1 - overlay /cow rw,lowerdir=//filesystem.squashfs,upperdir=/cow/upper,workdir=/cow/work
<zyga> !
<zyga> right?
<zyga> so what's /cow?
<zyga> I mooost know
<kenvandine> no idea :)
<zyga> a sample denial is:
<zyga> Sep 28 14:08:52 ubuntu kernel: [ 68.309885] audit: type=1400 audit(1538143732.840:232): apparmor="DENIED" operation="open" profile="snap-update-ns.gnome-calculator" name="/upper/snap/" pid=6535 comm="3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra> it makes milk usually :P
<zyga> but the pattern you pasted should cover that
<ogra> (shake it and you have cream !)
<kenvandine> :)
<zyga> kenvandine: can you look at /var/lib/snapd/apparmor/profiles and look for /upper there?
<kenvandine> zyga: and the mount for gnome-3-26-1604 is working fine
<zyga> in the snap-update-ns.gnome-calculator profile?
<zyga> jdstrand: ^ FYI, not sure if you know about any changes to overlayfs between 18.04 and 18.10
<zyga> kenvandine: please collect all those log files in the bug report
<kenvandine> zyga: there is no occurrences of upper in the profile
<zyga> maybe as files for easier access
<zyga> oh!
<zyga> you mean that snap-update-ns.gnome-calculator has no /upper in it?
<kenvandine> right
<jdstrand> zyga: I do not. this is on the livecd?
<zyga> yep
<kenvandine> zyga: yes, live session
<zyga> kenvandine: that's the bug perhaps
<kenvandine> works fine installed
<jdstrand> well, someone needs to adjust the policy for that. it me, it will be a little while, but someone can submit a pr and I'd look at it
<zyga> kenvandine: please add the file you looked at to the bug report
<jdstrand> s/it me/if me/
<zyga> jdstrand: not sure if there's something to adjust yet
<zyga> it looks more magic than before
<Chipaca> niemeyer: should I add SnapID to snapshots before, together with, or after landing the commands?
<zyga> jdstrand: anyway, I just wanted to check if you were aware of any changes to overlayfs
<zyga> kenvandine: I'll break for dinner now, ok?
<kenvandine> zyga: ok
<kenvandine> i'll attach stuff to the bug
<Chipaca> niemeyer: there's already an after-landing tasklet of blocking epochs, and restoring configs, both of which aren't done
<Chipaca> could be part of that
<niemeyer> Chipaca: Sounds fine either way.. as long as we don't release in the wild before the disk format is stable
<niemeyer> Chipaca: We can add an experimental flag for that, if necessary
<Chipaca> niemeyer: I can mark the PR blocked and just not land it until the followup is ready as well
<Chipaca> mmm
<Chipaca> dunno
<Chipaca> niemeyer: I'll do something sensible. Thanks.
<niemeyer> Chipaca: Thanks for that :)
 * Chipaca takes a break
<ogra> ogra@localhost:~$ snap interfaces
<ogra> error: no interfaces found
<ogra> GRRRRRR !!!!
<Chipaca> ogra: eh, you didn't need them anyway
 * Chipaca really tries to take that break now
<ogra> Chipaca, well, you guys make setting a hostname from a gadget hook really really hard ... i switched from prepare_device to the install hook of the gadget (because prepare_device only runs after the device hads been prepared which makes it completely useless for that case) ... and that got me into that state
<ogra> seems snapd simply stopped seeding the system completely now
<ogra> ogra@localhost:~$ snap list
<ogra> No snaps are installed yet. Try 'snap install hello-world'.
<ogra> :(
<pedronis> what does snap changes says?  and snap tasks for the ones there
<ogra> ogra@localhost:~$ snap changes
<ogra> ID   Status  Spawn               Ready               Summary
<ogra> 1    Error   today at 14:52 UTC  today at 14:54 UTC  Initialize system state
<ogra> 2    Error   today at 14:53 UTC  today at 14:53 UTC  Initialize device
<ogra> 3    Error   today at 15:01 UTC  today at 15:02 UTC  Initialize system state
<ogra> 4    Error   today at 15:01 UTC  today at 15:02 UTC  Initialize device
<ogra> 5    Error   today at 15:09 UTC  today at 15:10 UTC  Initialize system state
<ogra> Error   today at 15:08 UTC  today at 15:09 UTC  Run install hook of "pi-kiosk" snap if present
<ogra> pedronis, that install hook calls "/usr/bin/hostnamectl set-hostname ..." the gadget.yaml has the right connect statement and the snapcraft.yaml allows the hostname-control plug for the install hook
<pedronis> ?
<pedronis> connect is called later
<ogra> ugh
<pedronis> you really need an auto-connect for that
<pedronis> connections doesn't make a lot of sense for those kind of interfaces
<ogra> any chance the configure hook would be late enough ?
<zyga> re
<ogra> i really just need to set a hostname before avahi comes up for the first time
<pedronis> I would need to check but unlikely
<ogra> sigh
<pedronis> we set up connections after everything else
<pedronis> anyway they are not a good fit for this
<ogra> we're making this really hard
<pedronis> this is really more a auto-connect case
<pedronis> which would work
<ogra> yeah, but i dont really want to wait for someone to set up autoconnect for the gadget ...
<Chipaca> ogra: the avahi service could wait, couldn't it?
<ogra> Chipaca, how ? (without me modifying the avahi snap)
<Chipaca> ah
<Chipaca> picky, picky
<ogra> i'm trying to exercise a customer usse case here of simply creating an appliance image from mostly exissting snaps
<Chipaca> right
<Chipaca> and having the gadget set the hostname does sound reasonable
<ogra> yeah
<ogra> well, and it works from prepare_device ... but thats too late to work with avahi ... there will be client images that will try to auto-conect to that server appliance
<Chipaca> maybe the bug is that we start things before prepare device is done?
<ogra> right, i wouldnt expect prepare_device to be run as last thing after all apps have been processed
<ogra> doesnt really sound like "prepare" anymore
<ogra> rather like "postprocess"
<Chipaca> OTOH, one of the things that we start might be network manager
<Chipaca> without which prepare-device wouldn't
<Chipaca> it's worms all the way down i tell you
 * Chipaca runs off to some place with less worms
 * Chipaca sends beer
<ogra> heh, well ... all in all trying to build a simple appliance makes me hop from one roadblock to another atm
<ogra> the worst thing is that i do not get a snap id for sideloaded gadgets so even to test if something works i have to do a full turnaround through the store
<ogra> ... even for one line changes
 * ogra moves back to the prepare_device hook and adds reboot interface support to it ... 
<ogra> i'll just force a reboot after setting the hostname ... even though thats the worst UX i can imagine
<ogra> (not to mention that the firt boot on a pi3 takes 15-20 min just for sseeding the snaps)
<ogra> *first
<ogra> oh ... wait
<ogra> pedronis, on a device with an unofficial (non canonical) image, is the prepare_device hook called over and over ? i.e. would the above get me a reboot loop ?
<pedronis> ogra: yes, the prepare-device hook can be called multiple times
<ogra> oh my
<ogra> so no way out for me unless i add gross hacks ... which is exactly what i didnt want for this specific image :(
<ogra> sad ...
<pedronis> ogra: the doc says as much,  https://forum.snapcraft.io/t/the-gadget-snap/696
<pedronis> see the first paras of prepare-device hook
<ogra> yeah, i remember reading that somewhere
<ogra> ah, well, i can work around that in the hook i guess
<ogra> oh sigh ... so the shutdown interface only allows dbus connecttions ... not calling the reboot command directly
<pedronis> ogra: why do you need to reboot?
<ogra> pedronis, i need avahi restarted after the hostname has been set
<pedronis> reboot is a big hammer to restart avahi
<pedronis> sounds more like you need to restart avahi
<ogra> since i dont have snapd-control (and dont want it) to restart avahi from the gadget hook, thats the other option
<ogra> hahahaha
<pedronis> that doesn't make a lot of sense to me
<ogra> yes, "just restarting avahi" or "setting the hostname before avahi starts" would be the right things
<pedronis> I mean it's not a reasonable practice, to reboot to restart one thing
<ogra> but the current design doesnt allow either
<pedronis> if your gadget as the right auto-connect it would work
<pedronis> there was an idea to make connections in gadget.yaml more like auto connect
<pedronis> but it was punted
<ogra> yes, but only via requesting that from the store
<ogra> imagine i'm a developer that evaluates core for his company
<ogra> this is the role  i'm currently trying to play
<pedronis> I understand but also unclear that setting hostname is so relevant
<ogra> exercising the existing stuff we have
<pedronis> anyway it seems you should make a case in the forum to make connections in gadget more like auto-connections
<pedronis> the part that was punted there is deciding what was the limit of that
<pedronis> general auto-connect behavior was deemed too much
<ogra> the thing i'm building is a two image system ... one server applance that runs a digital signage tool and a bunch of leaf systems running from a second image that will find their sever via an mdns request
<pedronis> also you could probably use an interface hooks
<pedronis> maybe
<pedronis> that runs once the interface you need is *connected*
<pedronis> bit strange but better than rebooting I suppose
<ogra> the expectation is that you just shove in pre-flashed SD cards into a bunch of RPi's and have your store running the ads ... with a web mgmt UI on the server system
<ogra> so both images should set up themselves fully automatic
<ogra> and sadly avahi on the server side is a must
<pedronis> can't you invoke the equivalent of avahi-set-host-name
<pedronis> through avahi-control?
<ogra> hmm... and build an additional snap just for that ?
<pedronis> ?
<pedronis> from the gadget
<pedronis> as I said you can probably use interface hooks to run things from the gadget
<pedronis> once you have the interfaces you need
<pedronis> from connections
<ogra> hmm
<pedronis> if I understand how they should work
<pedronis> they = interface hooks
<ogra> the prob is: i dont think avahi-set-hostname is persistent ...
<pedronis> you do both
<pedronis> set the hostname through systemd
<pedronis> but also for avahi
<pedronis> so you don't have to restart the latter
<pedronis> or at least that's the idea
<ogra> well, thinking of it a -config snap that runs a service might not be the worst idea anyway ... and leaving all of this out of the gadget
<ogra> i might find more things i want to set and i would really like to re-use the gadget for the client images too
<ogra> (and setting hostanmes on the client image isnt needed at all)
<ogra> i'll tinker with that
 * zyga iterates on interesting mount issues 
<zyga> next week I'll split 50% for mount bugs and for new features
<zyga> not to starve either
<zyga> but no more distractions
 * zyga dives into 3.10 kernel
<ogra> pedronis, FYI: i actually found that i can use a default setting from gadget.yaml for the avahi snap to set the hostname in parallel (this is only for the first boot anyway and a reboot wouldnt have been that bad given seeding the 4 app snaps the image ships already takes 15-20 min, so a reboot only adds a minute in max) ... but i guess in general thats an area for improvement
<mup> PR snapd#5883 opened: tests,cmd/snap-update-ns: add test showing mount update bug <Created by zyga> <https://github.com/snapcore/snapd/pull/5883>
<jdstrand> zyga: approved 5395
<zyga> jdstrand: awesome, thank you :)
<zyga> jdstrand: I'm exploring a pair of bugs highlighted by that PR above
<zyga> but I think I'm on it and it's all good :)
<mup> PR snapd#5395 closed: interfaces: generalize writable mimic profile <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5395>
 * zyga is super happy and grateful!
<mup> PR snapd#5884 opened: overlord/snapshotstate: store the SnapID in snapshot, block restore if changed <Created by chipaca> <https://github.com/snapcore/snapd/pull/5884>
 * Chipaca ~> dinner
<zyga> enjoy Chipaca :)
<mup> PR snapd#5885 opened: Adding DPDK interface for DPDK Snap <Created by wililupy> <https://github.com/snapcore/snapd/pull/5885>
<smoser> have other people seen slow download times for snaps ?
<smoser> in some testing we have, the 'snap install lxd' which is the first snap so it gets the core snap sometimes took 15 minutes or more to download.
<smoser> where the link was not the problem
<smoser> i realize the fastly cdn is where the data comes from, but i would expect higher speeds than we're consistently seeing.
<zyga> smoser: no idea
<Chipaca> smoser: that is very slow. Can we set debugging to see where it's getting the things from?
<smoser> Chipaca: well, it doesnt always happen. but last night when it did it was from fastly. i think the ip was in 104. or 103. range
<smoser> thats from memory though
<smoser> ranges at https://api.fastly.com/public-ip-list
<smoser> http://paste.ubuntu.com/p/vCMMCvK3ZZ/
<smoser> som emory was wrong.
<smoser> 151.101194.217
<Chipaca> smoser: I don't know if that's enough to know enough
<smoser> what else would you want ?
<smoser> other than my uplink being saturated at that point.
<Chipaca> smoser: if you can set, in the environment where this happens, SNAPD_DEBUG=1 and SNAPD_DEBUG_HTTP=3 (e.g. as in https://forum.snapcraft.io/t/http-response-503-when-installing-anbox/6823/4) and then, when it happens, you can access the snapd logs (as in journalctl -u snapd), that would help
<smoser> but i was anot aware of other issues at that time.
<smoser> i think its pretty clear that it was just downloading stuff slowly.
<smoser> what other explanation could you have?
<smoser> uless snapd is debug showing route information (mtr like output)
<Chipaca> smoser: was it slow because you were getting RST packets thrown at you by a hostile ISP? Because you were getting network timeouts? Because you connected to the wrong fastly? Because the store was in distress? I don't know
<smoser> but what information would snapd debug bring to the table ?
<Chipaca> smoser: if the download was being retried, there'd be a log line for each retry / continuation
<smoser> i dont think it would likely give you any of those things.
<smoser> it wasnt being retried
<Chipaca> smoser: it also logs what fastly it downloads from
<smoser> i provided the ip of the fastly there.
<Chipaca> oh, I thought that was your ip
<smoser> bah. i typod' it. but 151.101.194.217
<smoser> nice
<smoser> i hit the same IP as ejfinneran did there.
<Chipaca> smoser: and where was the server located?
<Chipaca> or what was its ip :)
<Chipaca> i mean, the one you were running snapd on
<smoser> here. in detroit area
<Chipaca> from where I stand that sounds close enough to scottsdale to be reasonable
<Chipaca> noise][: is there anybody with bandwith to check on a slow download thing?
<Chipaca> noise][: i know people are running ragged right now
<smoser> maybe reasonable... but i'd surely expect a CDN to have an east coast and west coast US mirror
<smoser> and for arizona to hit the west coast
<smoser> and detroit to be east
<smoser> if there were not others in the mix
<smoser> :)
<Chipaca> smoser: bah, i used a geolocator that seems broken (I give it  151.101.194.217 and it rewrites it to 50.63.136.217 for whatever reason)
<noise][> Chipaca: I'd guess not on a friday afternoon after a crazy week :)
<noise][> ID'ing the IP and having snapd logs is a good start
<noise][> and then traceroutes/mtr to the IP helps too
<noise][> often the case is just some issue between user's network and the CDN PoP
<Chipaca> noise][: thanks
<noise][> smoser: feel free to file a snapstore bug with as many details as you can, but these tend to be hard to repro w/o a machine in the same location
<smoser> of course
<smoser> we did seem to be having some pain yesterday , both on our jenkins and local systems
<Chipaca> smoser: for the record, yes it should be a lot quicker than that
<smoser> but... having not collected debug information it is all in the realm of non-useful information
<Chipaca> I get better download speeds on my ADSL :-)
<smoser> Chipaca: fastly does seem to want to send me to mirrors on the west coast
<Chipaca> smoser: detroit isn't that far west, is it
<smoser> ~600 miles to new york city. ~2500 to san fran
<smoser> but i  dont knwo where they have data centers
<Chipaca> https://www.fastly.com/network-map says they probably have something closer
<smoser> oh well
<mup> PR snapcraft#2301 closed: tests: move most tests to spread and reorder travis.yaml <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2301>
<mup> PR snapcraft#2304 opened: project loader: remove remote parts support for bases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2304>
<k1412> Hello everyone, I'm just beginning with Snapd. I wanted use a custom netns configuration but I not understand how I must use that with network-control. Have someone a little expain about that ? Thanks.
#snappy 2018-09-29
<k1412> Hello, I have a little question. How do we configure network-control for an existing snapd application. I don't find a complete tutorial about it.
<mup> PR snapd#5886 opened: [testing] [pre-rfc] [wip] split spread in travis <Created by chipaca> <https://github.com/snapcore/snapd/pull/5886>
<zyga> k1412: hey,
<zyga> k1412: just add a network-control slot to your snapcraft.yaml file
<zyga> then connect it
<zyga> it grants numerous permissions to setup networking
<k1412> Hello zyga, it work also if we installed it with snap install anbox --devmode --beta ? Because in this case I not know where is the yaml file exactly
<zyga> k1412: what are you trying to do exactly?
<zyga> are you making a new snap
<zyga> or changing an existing snap?
<k1412> Changing an existing one, I want launch it isolate in a defined network namespace
<k1412> zyga: normaly I launch my application with ip netns exec but for snapd it fail with an error so I saw he info about network-control
<zyga> mmm
<zyga> you can repack a snap but I would not recommend to do that
<k1412> zyga: it look a little compicate when I hear that ^^, maybe the error message can help to understand the issue ?
<zyga> k1412: snapd doesn't use network namespaces
<zyga> so you should be able to just wrap the whole thing with a new network namespace
<zyga> and run any snap this way
<k1412> zyga: this is the error I have when I try to run my snap with ip netns
<k1412> cannot execute snap-update-ns: Permission denied
<k1412> snap-update-ns failed with code 1: File exists
<zyga> do you have any apparmor denials in syslog/journald?
<k1412> I use debian so I think there is maybe a default configuration (this is the command I use for launch it sudo ip netns exec protected sudo -u $USER snap run anbox)
<zyga> what is 'protected'?
<zyga> and what are you trying to achieve?
<zyga> anbox snap is just an installer last time I checked
<zyga> it requires some thighs that may or may not work on Debian (I don't know)
<k1412> protected is my network namespace I created before, I want be sure that anbox only use the interface that I allow to use (example  no connection, vpn, lan network)
<k1412> zyga: the normal launch (snap run anbox) is working
<zyga> Mmm. I see
<zyga> TBH not sure why it fails
<k1412> zyga: no issue, i will try to have some answers from firejail too because they have a snapd profile but it look failling too (https://privatebin.net/?299984217221dd99#Iv9/L1Q49cU41it7bVeo2zjRIqKt9mAHD3JO7/SKy00=)
<zyga> Frankly unless you want to jump into kernel and snapd confining snapd is not an easy task
<zyga> Perhaps run it in a VM
<zyga> If you want to investigate what is going on at that level then all the power to you
<zyga> Just want to say it is severely complicated.
<k1412> I'm not good enough to going so far away ^^ maybe a complete chroot with firejail would be more easy
<zyga> I doubt it
<zyga> Firejail is just another level of apparmor and seccomp
<zyga> So more complexity and kernel interaction
<zyga> And snap changes profiles
<zyga> So unless firejail stacks (and that is a super new feature in apparmor itself) you may effectively NOP
<zyga> Firejail wonât confine snap apps
<zyga> (Again, just a theory)
<k1412> I will try it to see, it would be a lot of fun ^^ (that is assuming that snapd can work in something like a chroot, I'm already not sure about it)
<zyga> Well, snapd talks to systemd
<zyga> And to the kernel
<zyga> Iâm unsure your actions make sense in trying to prevent snapd from affecting your system
<k1412> It's more that if it can work in a chroot (like another system) I just need to pass my complete chroot to my network namespace (but that is many theory) I will begin to just try to run snap from a chroot and see what happen
<zyga> Snapd can get out of a chroot
<zyga> Choot is not effective confinement
<k1412> zyga: Ah ? there is a way to test it (in same time so I can try it a little)
<zyga> k1412: test what specifically?
<k1412> zyga: to exit a chroot with snap
<zyga> k1412: all of those things have complex interactions; it seems you are trying to harden your installation of snapd; to effectively measure if the hardening makes any changes you'd have to know how snapd operates and how the kernel features it uses and (+chroot + fire jail) interact with each other; then you could try to mount an attack to see if the contraption works
<zyga> k1412: snap-confine does this
<zyga> I don't think this is sensible confinement
<zyga> because it deals with sandboxing of apps snapd is not a typical service that can be sandboxed easily
<zyga> the permissions snapd _can_ grant applications are equivalent of sandbox escape in some cases
<zyga> so it's really meaningless to chroot it
<k1412> I see, to be honnest i just try to find a way to affect it to a network namespace I want but without rebuilding a snap. Maybe you have reason it's maybe more easy to run it in virtualbox and assign virtualbox to a network namespace
<zyga> I don't know why it failed for you in the most straightforward case
<zyga> I'd look at debugging that
<zyga> strace ip setns
<zyga> see what happens
<k1412> zyga: it look complaining about the uid that is not 0 and think that sudo is maybe with suid or without root rights (it's maybe related when i do sudo -u the second time)
<zyga> it == ip setns?
<k1412> zyga: snap i can copy paste the log of strace but it's in french, i'm not sure it will help
<zyga> I think I'm too tired to debug that
<k1412> No issue thanks for giving me some tracks that can help
<erio> :O
<erio> damn
<erio> https://github.com/search?q=depends-on-alsa&type=Code
<erio> https://www.google.com/search?q=%22depends-on-alsa%3A%22+%22snapcraft.yaml%22&oq=%22depends-on-alsa%3A%22+%22snapcraft.yaml%22&aqs=chrome..69i57.10368j0j1&sourceid=chrome&ie=UTF-8
<erio> anyone here?
<erio> :O
<erio> :o
<erio> ?
<mup> PR snapd#5887 opened: tests: moving core-snap-refresh-on-core test from main to nested suite <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5887>
<erio> could someone explain me wth is stage and wth is prime ?
<erio> the definition in the docs is just awful
<erio> anyone online?
<erio> anyone online?
#snappy 2018-09-30
<mup> PR snapd#5886 closed: [testing] [pre-rfc] [wip] split spread in travis <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/5886>
<mup> PR snapd#5888 opened: testing <Created by chipaca> <https://github.com/snapcore/snapd/pull/5888>
<mup> PR snapd#5889 opened: make run-checks --static pass again w/shellcheck installed <Created by chipaca> <https://github.com/snapcore/snapd/pull/5889>
<mup> PR snapcraft#2305 opened: [legacy] pluginhandler: update build should overwrite organize (#2290) <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2305>
<erio> hey
<erio> can I use a specific git branch as source ?
<mup> PR snapd#5890 opened: overlord/snapshotstate: small refactor of internal helpers <Created by chipaca> <https://github.com/snapcore/snapd/pull/5890>
<mup> PR snapd#5891 opened: snap: give Epoch a CanRead helper <Created by chipaca> <https://github.com/snapcore/snapd/pull/5891>
#snappy 2019-09-23
<mborzecki> morning
<mborzecki> mvo: morning :)
<mvo> hey mborzecki
<mvo> mborzecki: how is life this morning?
<mborzecki> mvo: cold :P 5C outside
<mvo> mborzecki: woah, thats cold indeed. we have ~15 here but it will change!
<mborzecki> mvo: how was your train ride?
<mvo> mborzecki: all went well, all trains on time
<mvo> mborzecki: which is not the default anymore sadly. so it was a pleasant surprise
<mvo> mborzecki: also it was the last train so any major delay would have left me stranded in the middle of nowhere :) so I was a little bit nervous
<mborzecki> mvo: nice :) our trip to cdg from the hotel and the flight were smooth too
<mborzecki> mvo: although saturday was apparently rather chaotic in paris
<mvo> mborzecki: yeah, I read in the news there was a lot of protesting going on
<mborzecki> mvo: our snapd snap has an 'unset' license in the store https://snapcraft.io/snapd
<mup> PR snapd#7493 opened: snapcraft: set license to GPL-3.0 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7493>
<mvo> mborzecki: uh, lets me try to fix the license
<mborzecki> mvo: opened a PR with an update in snapcraft.yaml ^^^
<mvo> mborzecki: nice!
<mborzecki> mvo: but maybe the store page needs an edit too
<mvo> mborzecki: I have a look now
<mvo> mborzecki: I updated the store page now
<mborzecki> mvo: great, thanks!
<mvo> mborzecki: not visible in snap info (yet?) though - so maybe the authoritative one is  the snapcraft
<zyga> hey guys
<zyga> eating breakfast
<mborzecki> zyga: hey
<zyga> did usual school run
<zyga> so need a moment to get to office shape
<mborzecki> mvo: https://paste.ubuntu.com/p/4tjyHvcn2S/ looks like it's still unset
<mvo> hey zyga
<mvo> mborzecki: yeah, confusing
<zyga> everything ok?
<zyga> any fires?
<mborzecki> zyga: some confusion about the license of snapd snap, which apaprently is unset, opened #7493 to address that
<mup> PR #7493: snapcraft: set license to GPL-3.0 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7493>
<zyga> :D
<mborzecki> fwiw, do the review tools complain if license is not specified in the snap?
<zyga> mborzecki: I think now
<zyga> not
<zyga> why is license only as a passthrough?
<mborzecki> zyga: idk
<zyga> how do you guys feel today?
<mborzecki> and it's red :/
<zyga> yeah :C
<zyga> what was the failure?
<mborzecki> zyga: centos, systemctl daemon-reload
<mvo> zyga: feeling a bit sleepy
<zyga> mvo: same here
<zyga> mvo: I got up at 6 AM
<zyga> but cannot stop going to bed before midnigth
<zyga> er
<zyga> after
<zyga> https://github.com/snapcore/snapd/pull/7488 is green
<mup> PR #7488: docs: Update README.md <Created by degville> <https://github.com/snapcore/snapd/pull/7488>
<zyga> mvo: did you guys see  https://github.com/snapcore/snapd/pull/7488?
<mup> PR snapd#7409 closed: interfaces/wayland: allow a confined server running in a user session to work with Qt, GTK3 & SDL2 clients <Created by AlanGriffiths> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7409>
<zyga> mvo: policy idea: prioritize contributions from outside of the team above new features from the team
<zyga> mvo: prioritize fixes over new features
<mvo> zyga: yes, I thnk that is a good idea
<zyga> it would improve our interactions with other teams
<zyga> and could eventually outpace our own contributions
<mborzecki> https://github.com/snapcore/snapd/pull/7490 this one needs a review
<mup> PR #7490: interfaces/app-launch: support confined snaps launching other snaps <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7490>
<mvo> does anyone know whats up with centos-7 ? I see a lot of errors from systemctl reload
<mborzecki> mvo: we tried to investigate this a bit last week, so far i could not reproduce this running the whole suite
<mvo> mborzecki: strange - thanks!
<mborzecki> hmmm https://github.com/poettering/systemd/commit/1f37d342f3a32da5ce52123a5afb3498800097e9
<mvo> mborzecki: this guy again ;)
<zyga> mborzecki: I'm doing one now
<zyga> mvo: note the super nice github issue integration
<zyga> one line in a commit is enough to cross-reference everything
<mborzecki> https://bugzilla.redhat.com/show_bug.cgi?id=1378449
<mborzecki> hah, got a shell :P though it failed for different reason, but i can see systemctl daemon-reload times out
<mborzecki> https://paste.ubuntu.com/p/MtVJ7j76gc/
<mborzecki> zyga: mvo: ^^
<zyga> mborzecki: do you know how long it had to run?
<zyga> is it a busy vm? slow generator (or deadlocked generator?)
<zyga> or something else?
<mvo> mborzecki: nice! but does that mean we need the backported fix from systemd?
<mvo> mborzecki: also, why does it start to fail now, it used to work, no?
<mborzecki> hmmm systemctl times out all the time
<mborzecki> i see systemd got updated during our test run, there's a yum transaction that pulled in 219-67.el7_7.1.x86_64
<mborzecki> the command is: yum y install golang >= 1.9 systemd autoconf automake libtool gcc gettext gnupg pkgconfig(glib-2.0) pkgconfig(libcap) pkgconfig(libseccomp) pkgconfig(libselinux) pkgconfig(libudev) pkgconfig(systemd) pkgconfig(udev) xfsprogs-devel glibc-static valgrind /usr/bin/rst2man selinux-policy selinux-policy-devel
<mborzecki> so it's part of our test setup
<zyga> mborzecki: reviewed https://github.com/snapcore/snapd/pull/7490#pullrequestreview-291590702
<mup> PR #7490: interfaces/app-launch: support confined snaps launching other snaps <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7490>
<zyga> brb, shower
<zyga> mvo: do you mind if we cancel the 1-2-1 today?
<zyga> I'm super sleepy and my plan for the day is to go through reviews and bug triage
<zyga> we can do one later during the week if you feel like we need one
<zyga> mborzecki: can you review https://github.com/snapcore/snapd/pull/7484 later today?
<zyga> mborzecki: I don't want to distract you from centos issue
<mup> PR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
<mborzecki> zyga: ok, will do
<zyga> thanks
<mup> PR snapd#7479 closed: tests: skip centos when running interfaces-openvswitch for nigthly suite <Simple ð> <Created by sergiocazzolato> <Closed by zyga> <https://github.com/snapcore/snapd/pull/7479>
<mborzecki> Sep 23 07:22:49 sep230656-524345 systemd[1]: Caught <ABRT>, dumped core as pid 22180.
<mborzecki> Sep 23 07:22:49 sep230656-524345 systemd[1]: Freezing execution.
<mborzecki> Sep 23 07:23:06 sep230656-524345 sshd[19296]: Connection reset by 222.186.175.147 port 7036 [preauth]
<mborzecki> Sep 23 07:23:14 sep230656-524345 dbus[475]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
<mborzecki> mvo: zyga ^
<zyga> ooo
<zyga> abort?
<mborzecki> mhm
<zyga> grep systemd
<mborzecki> no coredumps listed by coredumpctl
<zyga> bugs are fun
<mborzecki> zyga: the log https://paste.ubuntu.com/p/ynVRcCTBPN/ it goes south after ABRT
<zyga> I wonder what "freezing execution" is
<zyga> I mean, systemd just aborted, what does it freeze
<mborzecki> duh, wonder where the coredumps are
<mborzecki> normally they'd end up in the journal, but perhaps we cleaned up the journal?
<mvo> zyga: I think it freezes because pid-1 canont die or the kernel is very unhappy
<zyga> hmmm
<zyga> mborzecki: is that really what happened? this is a log from the journal after all
<mborzecki> zyga: that's all there is
<mborzecki> zyga: wonder whether there's some 7.7 related problem, it only started a coulpe of days ago
<mborzecki> zyga: and yum install pulls in a partial update from 7.7 actually
<Chipaca> moin moin
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/7475#pullrequestreview-291621672 needs fixing
<zyga> hello chipaca
<mup> PR #7475: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
<zyga> now small break for warm tea, I'm cold today :|
<Chipaca> zyga, mvo, if you were me, and wanted to give a golang-related talk, what would you talk about?
<mvo> Chipaca: depends a bit on the audience - if its more beginners the export_test.go / package / package_test pattern is a nice one maybe ? I find it super useful but it seems to be not *that* common knowledge
<Chipaca> is that called black-box testing?
<Chipaca> white-box testing?
 * Chipaca calls it orange-box testing to be onbrand
<mvo> Chipaca: uh, thats a good question - I would go with black-box
<mvo> Chipaca: *but* I'm sure there are people with different opinions
<mvo> Chipaca: I would call it "api-surface-based-testing" or something
<Chipaca> :-)
<zyga> Chipaca: the language that defied the trend, retrospective from medium sized codebase written in go
<Chipaca> zyga: what trend? :-)
<zyga> Go went back to a simpler language
<zyga> Language complexity seems to grow almost uniformly otherwise
<Chipaca> hmm, i'll leave that one to you :-)
<Chipaca> zyga: the directory still thinks you're in palamÃ³s
<Chipaca> zyga: what city are you in / close to?
<Chipaca> er, maybe i should ask in private :-p
 * mborzecki going through systemd core dumps
<Chipaca> mborzecki: weren't you taking today off?
<mborzecki> Chipaca: nope, i'm swapping on 3.10
<Chipaca> mborzecki: what happens on 3.10?
<mborzecki> Chipaca: /me gets a day off :P
<Chipaca> mborzecki: :-)
<Chipaca> zyga: mborzecki: pstolowski: there's three GDGs in Poland AFAICT, go talk about golang / spread / snapd / etc
<Chipaca> wait, no, just two
<zyga> GDGs?
<Chipaca> silly map confused me :-) (but kaliningrad might be fun to visit)
<Chipaca> zyga: https://devfest.withgoogle.com/
<mborzecki> iirc they loosened some visa rules if you travel to kaliningrad from PL
<mborzecki> zyga: mvo: so ABRT comes from glibc apparently, let me post the backtrace
<Chipaca> sadly there isn't one in CÃ³rdoba for Sergio to go to, otherwise he'd kill it
<mborzecki> zyga: there's a GDG in wroclaw on 15.11 and one in warsaw in dec
<zyga> yeah, I was looking at the one in Dec
<mborzecki> zyga: mvo: https://bugs.centos.org/view.php?id=16441
<mborzecki> it'd be great to try with a 7.7 image or just clean upgrade 7.6 to 7.7
<zyga> mborzecki: memory corruption?
<mborzecki> mhm
<zyga> it seems that _int_free is the entry point to glibc
<zyga> and ealier it was cg_enumerate_subgroups
<zyga> well :/
<zyga> mborzecki: btw, what is that bug tracker
<zyga> it's not bugzilla
<zyga> is it?
<zyga> I like the fields it offers
<mborzecki> mantis?
<zyga> oh, is that mantis?
<zyga> wow
<zyga> that still exists
<zyga> it was my first ever bug tracker like 20 years ago
<mborzecki> ok, putting that core dump aside, back to some useful work
<mup> PR snapd#7493 closed: snapcraft: set license to GPL-3.0 <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7493>
<om26er> who to ping for auto-connection requests in the absence of roadmr ?
<om26er> context: https://forum.snapcraft.io/t/auto-connection-request-for-deskconnd/13364 -- I am the upstream of both the provider and the peer snap.
<mvo> mborzecki: the centos question sounds like something for sergio?
<mborzecki> mvo: yes, we're apparently using the official centos images in gcp, still waiting for 7.7 to be uploaded there
<mborzecki> mvo: discussed taht with sergio in paris, but will ping him when he's back online
<zyga> om26er: hmm, good question, I don't know
 * Chipaca takes a break
<Chipaca> om26er: doesn't that fall under the usual process for auto-connections?
<Chipaca> or, actually, isnt' that automatic
 * Chipaca should check
 * Chipaca needs to take a break
<zyga> break for tea and more reviews
<om26er> @chipaca while I am the upstream for both snaps, they come from different organizations, hence it didnt work automatically
<mborzecki> zyga: updated #7475
<mup> PR #7475: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
<mborzecki> ok, on to the review of 7484
<zyga> thank you, I'll look soon
<mborzecki> mvo: thanks for pushing the spread test to https://github.com/snapcore/spread/pull/85 !
<mup> PR spread#85: spread/client: workaround bash 4.3 subshell errexit issues <Created by bboozzoo> <https://github.com/snapcore/spread/pull/85>
<mvo> mborzecki: my pleasure - was looking at bit a spread this morning, could fully test locally though, so I hope it works ok
<zyga> mborzecki: +1
<Chipaca> hm, travis having a bad hair^Wnetwork day?
<ijohnson> morning folks, perhaps Travis should also get a swap day too :-/
<zyga> haha
<zyga> I was thinking that just a second ago :D
<zyga> looking at why the branches I review are red
<zyga> does anyone know what this is about?
<zyga> error: Get https://api.snapcraft.io/api/v1/snaps/download/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_7396.snap: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "Let's Encrypt Authority X3")
<zyga> 1008
<zyga> are we hitting some odd redirect, or something or the sort, that breaks ssl?
<mborzecki> zyga: left some comments under #7484
<mup> PR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
<zyga> mborzecki: I noticed, thank you so much!
<mborzecki> zyga: tbh found the documentation of io.Reader somewhat vague
<zyga> yeah, it's an interface after all :)
<mborzecki> and the case of Read() returning <n>, io.EOF is quite fun to handle
<zyga> I'll look at the error handling, I agree it's pretty complex
<Chipaca> mborzecki: when does it return n, eof?
<Chipaca> mborzecki: i mean, reading what?
<Chipaca> os.File says it's 0, eof on eof
<mborzecki> Chipaca: right, but we're passing io.Reader around
<Chipaca> fair
<mborzecki> Chipaca: i mean, the func is called StreamsEqual() so it does make sense to use io.Reader in there
<Chipaca> totes
<mborzecki> though that comes with some luggage :/
<mborzecki> mvo: installed snapd from edge, it's showing GPL-3.0 correctly now https://paste.ubuntu.com/p/65D3S6KqKr/
<mvo> mborzecki: nice, thanks
<Chipaca> mborzecki: so
<Chipaca> mborzecki: why not take an io.Reader and wrap it into a osutil.readerButAlwaysZeroWhenError ?
<Chipaca> mborzecki: wouldn't that keep the code calling Read simpler?
<mborzecki> Chipaca: perhaps, wonder if it's worth it, more code to test
<Chipaca> mborzecki: depends how complex the code without it is
<Chipaca> Â¯\_(ã)_/Â¯
<mborzecki> off to pick up the kids
<om26er> is roadmr on vacation ?
<Chipaca> om26er: quite likely
<om26er> Chipaca in his absence, do you know who to contact regarding store requests ?
<om26er> I don't want to bug Jamie for everything ;-)
<Chipaca> om26er: which request is it?
<Chipaca> om26er: the one from this morning?
<Chipaca> about content interface autoconnection between snaps of different publishers?
<om26er> Chipaca yes, that and two others (a total of three auto-connection requests)
<Chipaca> om26er: did you read the process for requesting auto-connection?
<om26er> I have read, yes. But I have had the process fastened in the past and this is something I wanted sooner because its for a project that I have to show at Ubucon in few weeks
<Chipaca> om26er: I'd be entirely unsurprised if today were a bad day for this
<Chipaca> om26er: a lot of people take the day after a sprint off
<om26er> aha, its the "swap day" day ;-)
<Chipaca> yus
 * om26er used to have two swap days after Canonical events due to two weekends consumed as a result of very long flights
<Chipaca> om26er: ssh, don't tell cachio, he'll get ideas
 * diddledan whistles nonchalantly: https://usercontent.irccloud-cdn.com/file/gXAW7XVu/image.png
<diddledan> the full output: https://usercontent.irccloud-cdn.com/file/TgRSHRNQ/image.png
<diddledan> start your rippers!
 * Chipaca is already ripped
<mup> PR snapd#7488 closed: docs: Update README.md <Created by degville> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7488>
 * zyga lunch and walk
<mvo> Chipaca: thanks for merging this. are we back to green tests?
<Chipaca> mvo: looked like it!
<Chipaca> brb, need to get two birthday cakes into the oven
<mup> PR snapd#7495 opened: [RFC] tests: add gh action for static checks <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7495>
#snappy 2019-09-24
<mup> PR snapd#7496 opened: tests: move "centos-7" to unstable systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/7496>
<mborzecki> morning
<mborzecki> mvo: hi, can you take a look at https://github.com/snapcore/snapd/pull/7475 ?
<mup> PR #7475: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
<mvo> mborzecki: sure
<mvo> mborzecki: I pushed a PR to move centos-7 to unstable
<mvo> mborzecki: if we do it we need to add a trello card too to re-enable it when we can
<mborzecki> mvo: saw that and approved :) thank you!
<mborzecki> mvo: we're not the only ones observing this problem: https://bugs.centos.org/view.php?id=16441#c35202
<mvo> mborzecki: nice
<mvo> mborzecki: if its between ystemd-219-67.el7_7.1 -> systemd-219-67.el7)  it should be easy to debug hopefully
<mborzecki> mvo: well, they just import the latest source dump from rhel in a single commit https://git.centos.org/rpms/systemd/c/9ab0c50975feeee399ced5d356cc79b9c1a9ce69?branch=c7 :/
<mvo> mborzecki: uh, ok
<mvo> mborzecki: still, "just" 15ish patches, should be easy to bisect
<mvo> mborzecki: for them, not for us :)
<mborzecki> mhm
<mborzecki> mvo: centos 8 should be coming out today :)
<zyga> hey guys
<zyga> small update, I'm going to take the swap day today
<mborzecki> zyga: hey
<zyga> lucy has a fever and I think I'm getting one too
<mvo> hey zyga
<mvo> zyga: uh, get well!
<zyga> I'll talk to Gosia and get back to you soon
<mvo> zyga: ok - quick Q did we get an update on the not-quite rebooting pi :/ ?
<zyga> mvo: we only know fractions, it doesn't die all the time, the journalctl --list-boots showed it booting up several times a day (though we don't know if timestamps are true), I have a journal to go through and AFAIK it's still on older version of core18 and snapd
<zyga> mvo: about fsck, there's some more information on https://forum.snapcraft.io/t/core18-shortcoming-missing-fsck-vfat-for-boot-fat-partition/13276
<zyga> mvo: at this point I'd like to clone the entire pi (I have the same model available now)
<zyga> rogpeppe: ^^^ could you consider cloning the SD card of your pi for analysis? If so we can craft a script that will DD the card out while briefly re-mounting / to ro
<rogpeppe> zyga: sure, np
 * mvo hugs rogpeppe 
<mvo> zyga, rogpeppe THANK YOU so much
<zyga> mvo: I'll craft the script and share it with rogpeppe, testing it on my devices locally
<zyga> mvo: depending on how I feel today that may be my "swap day"
<rogpeppe> zyga: it might take a while to fetch it though, as it's behind a crappy net connection
<zyga> rogpeppe: I'll make sure to include compression :)
<rogpeppe> zyga: good plan. xz probably isn't worth it though, given the h/w :)
<mvo> zyga: thanks, yeah, if you feel unwell, take time off :)
<mup> PR snapd#7464 closed: snapstate: add missing tests for checkGadgetOrKernel <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7464>
<mborzecki> mvo: i'm looking into why snap-run test sometimes works or gets stuck on arch, and it's really weird
<mborzecki> mvo: /usr/lib/snapd/snap-exec test-snapd-tools.echo hello appears to be stuck
<mborzecki> mvo:  can't connect strace/perf trace nor gdb, /proc/<pid>/status shows it's stuck in D state
<mborzecki> mvo: afaik it's uninterruptible sleep on the kernel side
<mvo> mborzecki: uh, so its a real issue? probably just manifests itself when we attach strace?
<mborzecki> mvo: probably, wodnering if i can tigger kernel side task dump without bringing down the whole system
<mvo> mborzecki: IDK, sry :/
<mvo> mborzecki: different topic, there was  a "snap run --explain" mockup during the sprint. was this a gdoc and if so, do you have the link?
<mborzecki> mvo: i think zyga added it in the sprint notes
<mborzecki> mvo: https://paste.ubuntu.com/p/8nVzj8Sqfq/ kernel dump of blocked tasks, only strace and snap-exec, and have a bunch of those
<mvo> mborzecki: right, what I see there is less detailed than what I remember seeing on the screen. *but* I was in some different meeting so I may be wrong
<mborzecki> mvo: notice how snap exec with pid 245937 is stuck in do_execve.../load_elf_binary
<mvo> mborzecki: interessting flush_old_exec seems to be a bit of a pattern
<pstolowski> morning!
<zyga> mvo: it was in the sprint notes
<zyga> mvo: you probably remember the "EX:" prefix
<zyga> mvo: it was later removed after review
<zyga> mvo: it starts on page 19
<mborzecki> pstolowski: hey
<mborzecki> zyga: look at the kernel task dump i pasted above ^^
<mborzecki> mvo: so i tried bind mounting /bin/true from the host over snap-exec in the core snap, and wasn't able to reproduuce this anymore, similarly no luch when i bind mounted true from the core snap
<zyga> mborzecki: I'm out of sync, can you refresh my memory please
<mborzecki> zyga: on arch, when running snap run --strace it'd sometimes get stuck, similarly snap run --trace-exec would not list snap-exec in theoutput
<mborzecki> zyga: so i tried running the same command as we use in tests in a loop, and was able to see it getting stuck, apparently, in the process tree, snap-exec ends up in D state
<zyga> D as in IOWAIT
<mborzecki> yeah
<mvo> zyga: aha, thanks, thats fine. I was wondering where the EX went to :)
<zyga> mvo: it was removed during the review
<mvo> zyga: thats fine, thanks for the explaination
<mborzecki> https://lore.kernel.org/patchwork/patch/719314/
<mborzecki> strace lockup when tracing exec in go
<mborzecki> heh, and tracing that trivial Go program gets stuck
 * pstolowski quick errand, bbiab
<Chipaca> mborzecki: that's why the recommended strace has a bunch of exceptions
<Chipaca> mborzecki: the "-e !select,pselect6,_newselect,clock_gettime,sigaltstack,gettid,gettimeofday,nanosleep" thing is not just laziness :-)
<mborzecki> Chipaca: strace -f -e execve gets stuck too
<Chipaca> poor strace
<mup> PR snapd#7497 opened: tests: listing test, make accepted snapd/core versions consistent <Created by pedronis> <https://github.com/snapcore/snapd/pull/7497>
<mvo> mborzecki: nice, it even has a kernel patch - except its from 2016 :/
<mborzecki> mvo: yeah, i'll just skip the strace related parts of the test on arch, no need to break the whole spread run
<mvo> mborzecki: did the patch got applied and we just happen to hit a new issue?
<mborzecki> mvo: afaik, the patch was not applied
<mborzecki> mvo: and don't really feel like debugging this any further is useful :/
<mvo> mborzecki: yeah, thats fine. I wonder if we could point our kernel people to the diff
<mvo> I mean, if its really fixing the problem might be worthwhile to upstream it
<mvo> mborzecki: our strace is only working because we do a bunch of !excludes
<mvo> mborzecki: but not high priority I guess, but given that arch is usually ahead a bit we might seen it soon on ubuntu too :/
<mborzecki> mvo: unless it's magically patched, reading the lkml thread, there's some confusion about which change fixed or masked the problem, so the issue is probably more complex than it seems
<mvo> mborzecki: ok, I did not read the full thread so yeah, lets ignore it for now :(
<pedronis> mvo: (repeating in case, I got disconnected) well if it's in the end is a kernel problem and it hits ubuntu we would need to involve the kernel team
<mborzecki> pedronis: eoan is on 5.3?
<mup> PR snapd#7498 opened: tests/main/snap-run: disable strace test cases on Arch <Simple ð> <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7498>
<mvo> pedronis: yes
<mborzecki> i'll do a quick run and check if it hapens on eoan too, if so i'll file a bug in PL
<mborzecki> LP
<mborzecki> in the meantime, 7498 should help with the failures
<mup> PR snapd#7496 closed: tests: move "centos-7" to unstable systems <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7496>
<mborzecki> pedronis: mvo: there's no going to be pre2.1 right? :D
<mvo> mborzecki: unlikely - Samuele says NO :)
<mborzecki> haha ok
<mup> PR snapd#7475 closed: sandbox/cgroup, usersession/userd: move cgroup related helper to a dedicated package <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7475>
<Chipaca> pedronis: your input would be appreciated on https://forum.snapcraft.io/t/feature-request-extend-length-of-version-string/13335?u=chipaca
<pedronis> Chipaca: I put in my queue, there's no easy answer though
<pedronis> mvo: still red travis ?
<mborzecki> pedronis: try merging master, the pr moving centos to unstable has landed
<Chipaca> woo, parliament woo
 * Chipaca watching the news
<Chipaca> I think I need a drink, that was intense
 * Chipaca gets a glass of water
<zyga> Chipaca: what happened?
 * zyga checks the guardian
<popey> Prorogation ruled unlawful, it never happened
<Chipaca> zyga: 11 judges, unanimously, told the gov'mnt to stuff it
<zyga> holly smokes
<Chipaca> ikr
<zyga> well, it's like adding anti-matter to a fire
<zyga> it's helping to put it out, in a way
<Chipaca> looks like a GE or a 2nd ref, with odds heavily on a GE
<mborzecki> mvo: good news (?), strace gets stuck on eoan too
<Chipaca> mborzecki: https://media.giphy.com/media/3o7abA4a0QCXtSxGN2/giphy.mp4
<mborzecki> haha :P
<mvo> mborzecki: oh no
<mvo> mborzecki: or yes
<mborzecki> mvo:  filed https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1845180
<mup> Bug #1845180: strace deadlock when tracing a trivial Go program <linux (Ubuntu):New> <https://launchpad.net/bugs/1845180>
<ogra> ppisati, here is one for you ... https://forum.snapcraft.io/t/watchdog-soft-lockup/13375
<ogra> (has an lp bug at the end)
<mborzecki> hmm https://media.ccc.de/v/ASG2019-145-distributing-freedesktop-sdk-applications-to-flatpak-snapd-and-docker
<mborzecki> isn't that they guy who posted about freedesktop base snap in the forums?
<Chipaca> sergiusens: is having the manifest the default in snapcraft now, or does it need a flag?
<popey> yes
<Chipaca> ogra: I took <thing> and did <three things that are all impossible to do with thing>, and now <event that has no causal connection to the thing>! fix it!
 * Chipaca stops forum'ing
<ogra> Chipaca, haha
<pstolowski> Saviq: woah @multipass on mac :). also, seems to be running fine alongside vmware fusion
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
<mup> PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
<mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7416, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447,
<mup> snapd#7454, snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
<mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7416, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447,
<mup> snapd#7454, snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
<mup> PR snapd#7416 closed: seed/seedwriter: start of Writer and internal policy16/tree16 <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7416>
<mup> PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
<mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
<mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
<mup> PR # closed: snapcraft#2229, snapcraft#2239, snapcraft#2413, snapcraft#2518, snapcraft#2544, snapcraft#2658, snapcraft#2672, snapcraft#2673, snapcraft#2677, snapcraft#2678, snapcraft#2696, snapcraft#2697, snapcraft#2699, snapcraft#2707, snapcraft#2709, snapcraft#2710, snapcraft#2727, snapcraft#2729
<mup> PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
<mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
<mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
<mup> PR pc-amd64-gadget#10 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR core#83 closed: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR # closed: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
<mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
<mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
<mup> PR pc-amd64-gadget#10 closed: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/10>
<mup> PR # opened: snapcraft#2229, snapcraft#2239, snapcraft#2413, snapcraft#2518, snapcraft#2544, snapcraft#2658, snapcraft#2672, snapcraft#2673, snapcraft#2677, snapcraft#2678, snapcraft#2696, snapcraft#2697, snapcraft#2699, snapcraft#2707, snapcraft#2709, snapcraft#2710, snapcraft#2727, snapcraft#2729
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37, core-build#48, core-build#51
<mup> PR # opened: snapd#5822, snapd#6108, snapd#6174, snapd#6258, snapd#6436, snapd#6666, snapd#6708, snapd#7079, snapd#7092, snapd#7129, snapd#7146, snapd#7166, snapd#7168, snapd#7193, snapd#7197, snapd#7205, snapd#7222, snapd#7228, snapd#7233, snapd#7238, snapd#7256, snapd#7261, snapd#7266,
<mup> snapd#7277, snapd#7286, snapd#7302, snapd#7320, snapd#7348, snapd#7355, snapd#7366, snapd#7367, snapd#7377, snapd#7402, snapd#7414, snapd#7417, snapd#7421, snapd#7424, snapd#7430, snapd#7431, snapd#7434, snapd#7436, snapd#7437, snapd#7438, snapd#7441, snapd#7443, snapd#7445, snapd#7447, snapd#7454,
<mup> snapd#7456, snapd#7462, snapd#7467, snapd#7468, snapd#7469, snapd#7470, snapd#7484, snapd#7486, snapd#7490, snapd#7495, snapd#7497, snapd#7498
<mup> PR pc-amd64-gadget#11 opened: Add mmx64.efi (MokManager) to support mokutil <Created by tsunghanliu> <https://github.com/snapcore/pc-amd64-gadget/pull/11>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<ogra> mupping ...
<Chipaca> mvo, pedronis, what was the conclusion WRT rebasing? is it now the Right Way?
<pedronis> Chipaca: I don't think there was a conclusion
<pedronis> tbh
<mvo> Chipaca: I though we agreed to try the "merge-with-rebase" from GH?
<mvo> pedronis: -^
<mvo> i.e. the automatic on click option ?
<Chipaca> so, no force-pushing, but merge-with-rebase
<Chipaca> ?
<Chipaca> sgtm fwiw
<pedronis> do we know what happens when it doesn't work?
<pedronis> I expect it will not always work
<Chipaca> pedronis: I'd expect github to block it if it doesn't work
<Chipaca> but I don't know why a merge would work and a rebase-then-merge wouldn't
<pedronis> Chipaca: I'm just not sure what happens to the tweaks you need a merge to make the merge work along the way
<pedronis> do they get turned into extra commits? do they make the thing fail again?
<Chipaca> not sure i understood your question
<Chipaca> seem to have too many merges in it
<pedronis> Chipaca: usually you fix conflicts and that fix goes into the merge commit
<pedronis> Chipaca: I mean from experience rebase don't always work locally, so not sure why they would work on merge
<pedronis> I mean work without intervention
<pedronis> I'm sure I will learn soon enough
<Chipaca> pedronis: https://github.com/isaacs/github/issues/1143
<Chipaca> fwiw
<Chipaca> i'm going to have lunch and stick my head in a jar of git sand, like a git ostrich of some sort
<pedronis> Chipaca: mvo: anyway my point is that we'll see but when it will not work we will decide what to do
<pedronis> mvo: #7434 should be ready for review
<mup> PR #7434: seed/seedwriter:  implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
<pedronis> mvo: also notice that "rebase and merge" says not enabled for this repository
<mup> PR snapd#7499 opened: many: move AppArmor probing code under sandbox/apparmor <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7499>
<mborzecki> zyga: ^^ something for you
<zyga> thx
<mborzecki> zyga: release/selinux*.go are mostly stubs now since we have the sandbox/selinux package, so they are next in line to be dropped
<zyga> reviewed
<ijohnson> morning folks
<ijohnson> pedronis, Chipaca (and others) where should I put my unit tests for SetTaskSnapSetup? the function is defined in handlers.go, but it's not clear which handlers_*_test.go I should put my tests in
<ijohnson> I could create a new "generic" handlers_test.go for this function which isn't specific to any kind of handler
<ijohnson> this is my update to #7430 btw
<mup> PR #7430: overlord/snapstate: set snap-setup-task for first task in change <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7430>
<pedronis> ijohnson: that seems ok
<ijohnson> pedronis: handlers_test.go seems okay?
<pedronis> yes
<ijohnson> ack, thanks
<pedronis> mvo: so I looked a bit, I'm not sure how switching to rebase will help, it will make the commits contiguous but not anchored, we would need to work hard on the quality of the messages of our single commits for it to make sense
<pedronis> or allow rebases on PRs
<ijohnson> ok, #7430 is ready for re-review Chipaca and pedronis if y'all could review that would be great
<mup> PR #7430: overlord/snapstate: set snap-setup-task for first task in change <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7430>
<ijohnson> pedronis, what do you mean the commits wouldn't be anchored? do you mean you can't find the PR a commit was merged in?
<pedronis> ijohnson: where would a overall description fit in that case?
<pedronis> I'm not even sure how to make a changelog in that mode (maybe I'm missing something)
<ijohnson> ah you mean rebase when you merge to master
<ijohnson> yes agreed there's nowhere to describe the overall "here's what all these commits did" when you rebase instead of doing a merge commit I suppose
<pedronis> yea, so I don't see how it can fit our current style of PRs
<pedronis> there's probably something we could do to our PRs
<pedronis> to make it fit
<pedronis> but I think it would involve allowing some rebase in them
<Chipaca> i fear for the rebase approach we'd have to move to rebasing everywhere, to keep things tidy
<Chipaca> or do the squash thing
<pedronis> Chipaca: I still think that either squash or merge would fit our approach better
<pedronis> but still seems like we would need a bot to do either
<pedronis> because we are not very good at driving either
<pedronis> on average
<pedronis> anyway I don't think we have a conclusion here
<ijohnson> I would be +1 to squashing and/or having a bot do the squash and/or regular merge to keep things consistent
<ijohnson> there may already be github bot plugins to do this, the multipass team uses https://github.com/apps/bors
<Chipaca> in view of recent developments, I'm wary of saying we give a bot commit
<Chipaca> :)
<mup> PR snapd#7497 closed: tests: listing test, make accepted snapd/core versions consistent <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7497>
<ijohnson> fair :-)
<mvo> pedronis: just read backlog and indeed, that seems like we have no solution yet :/
<mvo> Chipaca: yeah, I don't like the bot idea
<mborzecki> store throwing 503?
<Chipaca> mborzecki: pr'aps; line is stopped over there
<ijohnson> Chipaca: cool if I make a couple suggestions to your welcome.md gdoc thing?
<ijohnson> (not edits, just suggestions)
<ijohnson> I can also wait til you're done if you're still working on it
<Chipaca> ijohnson: go for it
<ijohnson> ack
<Chipaca> mvo: in the bug triage policy, could you make the links say what they're to? (you can have the link text be different than the link target)
<Chipaca> mvo: click the link, then the pencil, and you get to change things
<Chipaca> mvo: or highlight text, ctrl+k â set a target
<Chipaca> mvo: fwiw i did it for the last link which was easier to guess at :)
<mvo> Chipaca: updated
<ijohnson> anyone see a kill-timeout from a spread reboot request before like this ? https://pastebin.ubuntu.com/p/sGDkb43zrx/
<mup> PR snapd#7498 closed: tests/main/snap-run: disable strace test cases on Arch <Simple ð> <Test Robustness> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7498>
 * cachio lunch
<mup> PR snapd#7500 opened: api,timings: report duration via Doing column for ensure/startup <Created by stolowski> <https://github.com/snapcore/snapd/pull/7500>
<pstolowski> pedronis: ^ was actually simple, but i got slightly confused initially
<pedronis> pstolowski: +1 with small comment
<pstolowski> pedronis: for the auto-connect & mark-seeded order issue, it's because we don't sort tasks in snap debug timings, it's whatever order change.Tasks() reported. will fix
<pstolowski> pedronis: ty
<Chipaca> huh
<Chipaca> https://travis-ci.org/snapcore/snapd/jobs/589008368#L6315 â huh
<ogra> https://www.youtube.com/watch?v=j08nLrO_T84
<Chipaca> in what case would snap-run --trace-exec print info about snap-exec and not snap-confine?
<zyga> Chipaca: IIRC there is that raw thing
<zyga> For strace
<Chipaca> zyga: ?
<zyga> But perhaps I misremember or misunderstand
<Chipaca> zyga: https://api.travis-ci.org/v3/job/589008368/log.txt
<Chipaca> zyga: look for 'error executing'
<Chipaca> zyga: it's looking at the output of 'snap run --trace-exec'
<zyga> snap run âstrace=raw
<zyga> Mmmmm
<Chipaca> and it's a wee urd
<zyga> I didnât remember that one
<zyga> I wonât be able to look from the phone now. Iâll make some tea and open the laptop again but this will take some time
<zyga> Tomorrow ish
<pedronis> pstolowski: ah, so Tasks is in creation order, I suppose here we want start times order?
<pstolowski> pedronis: yes. fwtw 'snap changes' orders them by spawn time, perhaps we should be consistent with that
<pstolowski> so yeah
<pedronis> pstolowski: spawn time is not start time
<pedronis> to be clear
<pedronis> indeed snap changes tends also to be confusing from this POV
<pstolowski> ah ok
<pedronis> pstolowski: basically with spawn times all dynamically created tasks ends up after the static ones
<pedronis> because spawn time is when NewTask happens
<pstolowski> pedronis: indeed
<pedronis> but in timings we have actualy start times, no?
<Chipaca> zyga: no worries, the log isn't going away (i think?)
<pedronis> pstolowski: we might need to think a bit though because sorting by start time is not useful for things that are parallel (usually different lanes)
<pstolowski> pedronis: snap debug timings hits v2/changes/<id>, i think we just need to sort those on the client side
<pedronis> pstolowski: we don't return lanes anywhere atm
<pedronis> (it's kind of an internal detail)
<pedronis> we don't return start time (vs spawn time) anywhere either atm
<Chipaca> pedronis: wrt lanes we might want to start returning them
<Chipaca> emphasis on might
<Chipaca> pedronis: it's unclear whether we can build a good multi-progress bar without them, and we want to do that
<pedronis> Chipaca: mmh, I see
<Chipaca> pedronis: (because when a snap pulls in another snap, currently the UX sucks)
<pedronis> we need a bit to think that through
<Chipaca> explicitly installing multiple snaps also sucks, but less :)
<pedronis> anyway here we might just return something extra in the debug endpoints
<pedronis> for pstolowski stuff
<Chipaca> k k
<Chipaca> it's not like we have a timeline for the other thing :)
<pedronis> pstolowski: so my thinking was to sort by (min(lanes), start-time, task id), except lane 0 might need to be treated specially
<pstolowski> pedronis: sounds good. i need to digest this and continue tomorrow morning
<pedronis> np, need/want to step away from keyboard as well
 * Chipaca EODs
<mup> PR snapd#7501 opened: interfaces/kubernetes-support: allow use of /run/flannel <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7501>
<mup> PR snapd#7502 opened: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7502>
<jdstrand> degville: hey, I'd like to document system-usernames. I was thinking inserting it in some strategic location in the forum and linking out to a separate topic. I thought the name of the linked to topic would be 'system-usernames'. thoughts on this name and also where to link from?
<degville> jdstrand: I think to start with, the top-level system-username doc might be best linked to from one of the snapcraft.yaml pages (https://snapcraft.io/docs/snapcraft-format). But it also sounds like it may become important enough to have it's own top-level page - maybe mirroring something like your original `Multiple users' post under the docs category. But we can obviously change all this easily. Otherwise, I
<degville> think the name is good - thanks for doing this!
<jdstrand> degville: I'll create https://forum.snapcraft.io/s/system-usernames in the forum under the 'doc' category, then come up with a blurb to insert into a snapcraft.yaml page and circle back to you. sound ok?
<degville> jdstrand: perfect, thank you!
 * cachio afk
<om26er> roadmr Hi! Can you take a look at https://forum.snapcraft.io/t/auto-connection-request-for-deskconnd/13364 ? I am the maintainer of both snaps albeit from two different orgs
<roadmr> O_o
<roadmr> om26er: em suuuure but cross-publisher auto-connects are tricky :/
<om26er> ^ that applies to https://forum.snapcraft.io/t/auto-connection-request-for-piconn/13368 and https://forum.snapcraft.io/t/auto-connection-request-for-deskconn/13367 as well :-)
<om26er> roadmr tricket as in "conflict of interest" ?
<om26er> *tricky
<roadmr> om26er: no, as in it needs somewhat complex assertion wrangling
<roadmr> om26er: if they come from the same publisher, it's easier
<roadmr> om26er: interest-wise, as long as both publishers are OK with it (and you're both in this case) it should be OK
<om26er> hmm the provider comes from a snap that I publish for my employer and the peer snaps are my personal projects
<om26er> roadmr need your eyes on the two other similar requests as well ^
<roadmr> om26er: sure, I'll have a look in a bit - but I can't really action them unilaterally, need eyes from other reviewers
<roadmr> but at least it'll get the ball rolling :) thanks for your patience
<om26er> roadmr indeed, thanks for looking into this, I hope Jamie will get around to reviewing that soon as well ;-)
<roadmr> indeed
<mup> PR snapd#7266 closed:  recovery: update run mode variable name <Created by cmatsuoka> <Merged by cmatsuoka> <https://github.com/snapcore/snapd/pull/7266>
<mup> PR snapd#7503 opened: tests: restart the journald service while preparing the test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7503>
 * cachio EOD
 * ijohnson relocates to coffee shop
<Chipaca> mwhudson: out of curiosity, how hard would it be to snap older go versions? https://www.reddit.com/r/golang/comments/d8rrd6/install_really_old_golang_versions/
<mwhudson> where did he go
#snappy 2019-09-25
<mup> PR snapd#7504 opened: tests/cmd/debug_state: make the test output TZ independent <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7504>
<mborzecki> morning
<mvo> good morning mborzecki
<mborzecki> mvo: hey
<mborzecki> hmm google:ubuntu-18.04-64:tests/main/mount-ns:inherit failing, looks like the expected mountinfo content needs and update, but why doesn't it fail always
<mvo> mborzecki: meh, that sounds like a zyga question
<mup> PR snapd#7500 closed: api,timings: report duration via Doing column for ensure/startup <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7500>
<mup> PR snapd#7501 closed: interfaces/kubernetes-support: allow use of /run/flannel <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7501>
<mup> PR snapd#7502 closed: interfaces/kubernetes-support: allow use of /run/flannel - 2.42 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7502>
<mup> PR snapd#7505 opened: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7505>
<mborzecki> mvo: zyga: this should fix the problem ^^
<mup> PR snapd#7504 closed: tests/cmd/debug_state: make the test output TZ independent <Simple ð> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7504>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> duh gorename being silly and going through the whole of GOPATH
<zyga> hey ho
<zyga> sorry for starting late
<zyga> I'm feeling so so still
<mup> PR snapd#7506 opened: devicestate: add support for gadget->gadget remodel <Created by mvo5> <https://github.com/snapcore/snapd/pull/7506>
<mvo> pstolowski, zyga hey and good morning!
<mvo> zyga: no worries, get well
<pedronis> mvo: hi, I put some questions in 7506
<pedronis> mvo: it would be good if either mborzecki or you did something about #7166
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<mborzecki> pedronis: i keep working on that
<mvo> thanks pedronis
<mvo> pedronis: I can scope down 7506 to only allow track switching for now maybe?
<mvo> pedronis: but I guess the question remains the same
<mvo> pedronis: we need a check to ensure the volumes are compatible, right?
<pedronis> yes
<pedronis> anyway I doubt it's a small task, it sounds really more mborzecki material once he is done with other stuff
<mvo> pedronis: yeah, that should be ok
<pedronis> John will pick up #7377
<mup> PR #7377: patch: add an overlord patch that normalizes channel in state <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7377>
<mvo> pedronis: great!
<pedronis> as I discussed with him yesterday
<mup> PR snapd#7505 closed: tests/lib/lxd-snapfuse: restore mount changes introduced by LXD <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7505>
<pedronis> mvo: I need to think a bit more about #7348, I'm not happy with the regression in some cases, I'm not happy with the complexity of the clean solution either
<mup> PR #7348: snapstate,store: check assumes early before downloading the snap <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>
<mvo> pedronis: fair enough, we can just close it if you feel it hurts more than it helps
<pedronis> mvo: no, maybe there is just cheap way out, but I really need to focus on some other things, we can try to rediscuss it in the next days
<mvo> pedronis: ok
<pedronis> mvo: #7434 is ready for review
<mup> PR #7434: seed/seedwriter:  implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
<mvo> pedronis: thanks, looking
<pstolowski> pedronis: hey, https://github.com/snapcore/snapd/pull/7468 is referencing itself in the comment (wrong PR #)
<mup> PR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
<pedronis> pstolowski: ah, anyway we probably want to wait for them to land one by one
<pedronis> I haven't pushed the big one through all the way
<pedronis> because too much rebase complexity all over
<pstolowski> ack, yes i can imagine
<pstolowski> pedronis: what would be the next to review after 7434?
<pedronis> pstolowski: I think it's actually #7441
<mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
<pstolowski> pedronis: btw did you force-pushed 7434 a moment ago? i was reviewing it and at some point github told me to refresh, but there was just 1 commit
<pedronis> pstolowski: yes, I added some test lines
<pedronis> where there was a ...
<pstolowski> pedronis: ok. it's a bit confusing when something like this happens ;)
<pedronis> I didn't know somebody was already reviewing it
<pedronis> pstolowski: anyway I added exactly lines at the very end: https://github.com/snapcore/snapd/pull/7434/files#diff-81b90abba270c6b3849a0191b406c81bR719
<mup> PR #7434: seed/seedwriter: implement WriteMeta and tree16 corresponding code <Created by pedronis> <https://github.com/snapcore/snapd/pull/7434>
<pedronis> there was a // check snap-revision  // ...  there
<pstolowski> thanks
<pstolowski> pedronis: btw all the //XXX: channel stuff is waiting for John's changes?
<pedronis> pstolowski: no, I added to the description now, it is taken care in a follow up just about channel
<pstolowski> ok
<pedronis> though I expect later changes again because of some decisions about UC20 models
<pedronis> pstolowski: it's done in #7467
<mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<pedronis> pstolowski: related to the // ... I'm sure I forgot some small todos here and there, I'm trying to address them when I merge master into things when the prereq lands
<pedronis> but big things are taken are along the sequence
<pedronis> as I mentioned I do have code that makes image.go tests pass again, that's something I'm trying to finish today
<pedronis> pstolowski: we do use just a for assertion here and there, is not the only place there
<pedronis> I mean across the codebase
<pstolowski> pedronis: ok, fair enough
<mborzecki> pedronis:  pushed an update to #7166
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<pedronis> mborzecki: thx, queued to look at
<mborzecki> pedronis: great, thank you!
<pedronis> mborzecki: are you going to work on the issue with invalid old gadgets that was discussed yesterday?
<mborzecki> pedronis: yup, i'm working on it right now
<pedronis> thx
<pedronis> pstolowski: right now it seems you are commenting on some code that exists already like that in image.go
<pedronis> not saying that it might not get more confusing now that is getting lifted
<pedronis> and might need more comments
<pedronis> but a bit of context maybe is useful
<pedronis> pstolowski: I put a link to the original code in the response to one of your comments
<pstolowski> pedronis: hmm, maybe... it's the inherent problem of stacked PRs :( (not your fault by any means)
<pstolowski> easy to get lost
<Chipaca> pedronis: in #6958 we implemented download via snapd as a POST. I asked why it wasn't a GET, we discussed it in the standup, and apparently it needed to be POST â¦ but we didn't write down why, and now I don't remember
<mup> PR #6958: Added api endpoint for downloading snaps <Created by glower> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6958>
<Chipaca> pedronis: do you?
<pedronis> Chipaca: we might want to send alternative auth bits or http proxy config at some point it
<pedronis> it would get unwieldy as GET params
<Chipaca> fair
<Chipaca> mvo: ^^^
<pedronis> pstolowski: also maybe you are re-reviewing code?  the only new code in that PR is https://github.com/snapcore/snapd/pull/7441/commits/ab5e4c151488cc399946a42ce413752c9a1651bd
<mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
<pedronis> pstolowski: btw fwiw I fixed the chaining ref in 7468, it's based on #7467
<mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<Chipaca> if y'all are hungering for something to review, #7320 is sitting there
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<pedronis> Chipaca: I queued it, I skimmed it, it seems to need a couple of tweaks
<zyga> mvo: I'll get some meds and work on triaging
<zyga> mvo: I worked with roger in the morning, I have some updates on that, save them to the doc
<pedronis> mvo: this is interesting: https://forum.snapcraft.io/t/first-boot-doesnt-recover-if-system-restarts-while-snapd-is-starting/13392
 * mvo is in a meeting right now
<zyga> pedronis: we discovered that yesterday
<pstolowski> Chipaca: my only reservation wrt #7320 is what i described in general comment, the fact that snap run will be affected. not sure if this is going to be an issue in practice
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<mvo> pedronis: just read backlog (meeting is over) - yes, thats serious and needs fixing :/
 * pstolowski lunch and school run
<mup> PR snapd#7507 opened: gadget: do not fail the update when old gadget snap is missing bare content <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7507>
<zyga> mvo, pedronis: I updated the forum and created a detailed bug report
<pedronis> zyga: I commented there, what's the right solution is not super clear to me
<pedronis> we need to discuss further
<zyga> pedronis: sure, I only gave a suggestion how this might be addressed but I agree it's something to design more closely as this is a very critical element
<cachio> mvo, hey
<cachio> yesterday I was researching a bit an error on the rpi
<cachio> for core 18 tests
<cachio> I see that for arm devices the file /boot/grub/grubenv does not exist
<cachio> and for amd64 and i386 it exists
<cachio> do you know the reason?
<ogra> arm doesnt use grub
<ogra> instead you should have /boot/ubot
<ogra> */boot/uboot
<cachio> ogra, I have it
<cachio> right
<ogra> (and everything in snapd should take that into account=
<ogra> )
<cachio> so how should I get the env vars?
<cachio> should we compile fw_printenv right?
<ogra> on core16 you had the fw_printenv tool pre-installed, but i think mvo decided to drop it in core18 so there is no way except from serial console directly in the bootloader shell
<cachio> ogra, ah, ok
<ogra> while you can indeed compile it, there is more to it, as you need a config file in /etc that points to the right addresses the uboot.env lives
<ogra> we had some setup in core16
<cachio> well in this case I'll have to skip this test for arm devices until we define an alternative path for it
<cachio> thanks ogra
<cachio> for the explanation
<ogra> (and it is massively annoying that fw_printenv/setenv are gone ... since customers need to hack bootloader configs directly in the uboot shell now .... quite a time waster to do all these reboots)
<cachio> ogra, indeed
 * Chipaca wanders off in search of sustenance
<pedronis> cachio: mvo: sounds we might have to consider bringing it back, either in core or snapd
<ogra> +1 !!
<zyga> pedronis: snap debug boot-env {set,get,unset} ?
<zyga> pedronis: so that snapd code for working with environment is exercised
<mup> PR snapd#7508 opened: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7508>
<pedronis> zyga: maybe
<zyga> perhaps even as direct in snap thing
<zyga> so that it can be used at all times
<zyga> but not sure about that
<pedronis> no, that seems strange
<zyga> yeah, it's better to do it "for real" via snapd
<ogra> well, for development/porting it is super helpful to have some access from userspace ... wether thats via fw_* or via snap set/get surely doesnt matter ... but having *some* access again would be really helpful
<zyga> yeah, I think that's key
<pedronis> zyga: I missed what you meant
<zyga> pedronis: that _a_ tool is available
<pedronis> no, I though with direct, you meant snap boot-env, snap debug boot-env
<pedronis> not about skipping snapd
<zyga> ah, sorry, I meant snap <something not top level> boot-env
<pedronis> either it's an area that will be in flux soon
<pedronis> so a bit hard to start on this now
<zyga> yeah
 * zyga lunches
<Chipaca> ogra: in https://forum.snapcraft.io/t/partition-layout-for-snappy/656/47
<Chipaca> ogra: i know most of the words, but not in the order you're using them :-p
<Chipaca> ogra: so, what would be a good title for the new topic that started tehre today?
<Chipaca> ogra: so I can split it out as it doesn't seem to be related to the previous one
<zyga> Chipaca: consider looking at (wishlist to support another systemd service unit property useful for forking daemons) https://bugs.launchpad.net/snapd/+bug/1822337
<mup> Bug #1822337: Support for setting PIDFile for "forking" daemons <snapd:Triaged> <https://launchpad.net/bugs/1822337>
<Chipaca> mmm, forks
<Chipaca> zyga: I'd call that a papercut
<Chipaca> zyga: is that what you're asking me?
<zyga> if that's sensible in your eyes let's tag it and move on
<Chipaca> zyga: yeap
<Chipaca> zyga: once we have ~5 papercuts we can start thinking of keeping it to that number (i.e. doing some of them ourselves in our copious free time)
<zyga> Chipaca: at the 8th day of the week
<Chipaca> zyga: and yes I pulled that number out of ... thin air
<zyga> ;)
<Chipaca> osvaldo
<zyga> Chipaca: could I also ask you to look at https://bugs.launchpad.net/snapd/+bug/1823768 -- it was reported almost half a year ago and perhaps was fixed since
<mup> Bug #1823768: snap refresh failure during task: Consider re-refresh of snap: snap has "refresh-snap" change in progress <snapd:Triaged by chipaca> <https://launchpad.net/bugs/1823768>
<zyga> you're assigned to it as well
<zyga> I've triaged it so I'll leave the rest to you, if you want to update the status please do so
<Chipaca> zyga: that one has not been fixed afaik
<pedronis> Chipaca: I might have fixed it in my remodel work
<Chipaca> pedronis: was about to ask
<pedronis> but we never reproduced it
<Chipaca> pedronis: but even when it was reported it wasn't clear how to repro
<Chipaca> yeah
<pedronis> to be precise I found a place that was buggy in my remodel work and fixed it
<pedronis> I don't know of any other place
<pedronis> but might exist
<pedronis> the place was in the alias handling code
<pedronis> for an update
<pedronis> mborzecki: #7166 is failing the static tests
<mborzecki> duh
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<mborzecki> let me see
<zyga> kenvandine: is snap-store bug tracker on lauchpad?
<zyga> kenvandine: can you please reassign this bug as appropriate https://bugs.launchpad.net/snapd/+bug/1824166
<mborzecki> pedronis: interesting, looks like that naked return been there since 04.2018
<mup> Bug #1824166: Any snaps without --classic don't have access to the internet on Deepin. <snapd:Invalid> <https://launchpad.net/bugs/1824166>
<mup> PR snapd#7503 closed: tests: restart the journald service while preparing the test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7503>
<zyga> hmmm, launchpad timeouts are somewhat common
<mborzecki> meh, the default config for nakedret used by golangci-lint is to complain if the func is above 30 lines of code, while vanilla nakedred does that for 5+ lines of code
<ogra> Chipaca, hmmm which bits exactly do you want to split out ?
<pedronis> mborzecki: what changed? anyway 5+ seems a bit too conservative but no strong opinion there
<mborzecki> pedronis: i've added some code to the function that nakedret flagged, and it's just above the default threshold of 5 lines when it start to complain
<ogra> Chipaca, note that i only pointed to a howto from mvo to install to internal MMC ...
<pedronis> mborzecki: let me look at that function and form an opinion :)
<mborzecki> haha
<mborzecki> btw. forgot to mention that when we discussed the tooling we use, i'm using https://github.com/golangci/golangci-lint locally to check the code before pushing out
<zyga> Chipaca: https://bugs.launchpad.net/snapd/+bug/1826064 is something you may be interested in as a hobby interest :)
<mup> Bug #1826064: snap command outputs unicode in publisher name even when locale is ascii <cdo-qa> <foundations-engine> <snapd:Confirmed> <https://launchpad.net/bugs/1826064>
<Chipaca> zyga: ikr
<Chipaca> ogra: from shubham's question today down
<ogra> Chipaca, well, it is 50% about what i linked to (how to install to internal MMC) and 50% related to ondra's stuff regarding fastboot hackery
<ogra> so i dont think it is in the wrong place
<pedronis> mborzecki: we could bump the default to -l 10 , 30 seems a bit much to me
<Chipaca> ogra: ah, fair enough
<pedronis> though
<ogra> Chipaca, i.e. you can use tw ways to get stuff to internal MMC ... one is to simply godd the image to the internal device from an SD booted system ... the orther is to jump through a million of hoops and make your image a multi-partition one tat fastboot accepts
<pedronis> mborzecki: a bit your call what you want to do there, either bump or fix
<ogra> (in case your board has fastboot support in the ROM/first-stage-bootloader)
 * ogra notes his typing sucks today :(
<mborzecki> pedronis: already pushed a fix to use named arguments with return
<zyga> popey: could I ask you to look at https://bugs.launchpad.net/snapd/+bug/1826470 -- it seems that brave works but only from the command line for some reason, perhaps it's a papercut in the desktop file
<pedronis> mborzecki: ok
<mup> Bug #1826470: Can't launch brave from dock <snapd:Confirmed> <https://launchpad.net/bugs/1826470>
<mborzecki> wow, our standup notes are *long* :P
<pstolowski> mborzecki: we need a second document with only a highlights of the first one ;)
<mborzecki> pstolowski: should employ some ML to distill the most important bits
<cmatsuoka> I'm trying to keep it with a civilized level of detail
<zyga> mborzecki: Machine Learning? :D
<mborzecki> zyga: yup
<zyga> I try to use a sub-points for details
<zyga> and main points for highlights
<zyga> this way you can just briefly read the report without needing to deduce what's detail and what's overview
<cmatsuoka> after a few months we can feed it to a markov chain of sorts and have an entirely new set of activities
<kenvandine> zyga: snap-store is strict, so not sure what I can do from within the confined snap to fix dns resolution
<kenvandine> zyga: looks like something isn't properly exposed in the sandbox
<zyga> kenvandine: perhaps the issue is fixed now
<zyga> kenvandine: it was classic earlier if I recall correctly
<kenvandine> It was briefly published to edge as classic
<kenvandine> only for a couple days though, about 18 months ago
<kenvandine> this bug report is only a few months old
<kenvandine> i think the reporter is saying classic snaps work and strict snaps do not
<kenvandine> vscode can access network, firefox can not
<zyga> ah, perhaps I misread the bug
<zyga> can you add this to the bug, I'll look at it on the next pass
<kenvandine> that is in the bug :)
<kenvandine> he explains that firefox can't access the network but vscode can.
<kenvandine> and he explains that vscode is classic and hints that is why it works
<kenvandine> i'll comment on the bug though
<ijohnson> zyga: quit triaging bugs, it's my day today!
<zyga> ijohnson: I know it's not my day, I kind of missed the schedule because I was partially off yesterday and didn't realize it's Wednesday
<Chipaca> kenvandine: zyga: which bug is this?
 * ijohnson accepts zyga's apology in exchange for more polish sweets at next sprint
<zyga> ijohnson: I'll send you the menu ;)
<Chipaca> kenvandine: zyga: please don't say kali
<ijohnson> :-)
<zyga> 2fa
<kenvandine> Chipaca: bug 1824166
<kenvandine> it's Deepin
<mup> Bug #1824166: Any snaps without --classic don't have access to the internet on Deepin. <snapd:Invalid> <https://launchpad.net/bugs/1824166>
<kenvandine> I moved it out of invalid until it gets looked at again
<Chipaca> kenvandine: deepin has some kind of issue somewhere
<Chipaca> kenvandine: snaps that need network, or x, don't work right
<Chipaca> or maybe x is just kali?
<Chipaca> kenvandine: https://forum.snapcraft.io/t/deepin-debian-9-snaps-have-no-internet-connection/11295/7?u=chipaca
<Chipaca> ah, kali was the weird "homes are in /" thing
 * Chipaca gets them confused
<kenvandine> zyga: ok, the theory is confirmed by that forum post.
<zyga> pedronis: can you please enqueue looking at this bug report, it has an observation that may be relevant for your core 20 model design work: https://bugs.launchpad.net/snapd/+bug/1834688
<mup> Bug #1834688: connections stanza in gadget.yaml requires snap id <snapd:Confirmed> <https://launchpad.net/bugs/1834688>
<cachio> mvo, I could reproduce the error running the interfaces-many-core-provided using a vm
<cachio> here
<cachio> I need to re run to start printing more information
<cachio> debug information
<cachio> what I saw is that the cpu went to 170% and then it didn't accepted any connection anymore
<cachio> accept
<mvo> cachio: cool, thank you!
 * zyga breaks for coffee
<zyga> mvo: snapd will have 0 new bugs today :)
<zyga> mvo: the next pass will need to look at snappy
<zyga> mvo: and finally at gardening all open bugs
<mvo> zyga: \o/
<zyga> not sure who's interested in seeding today but...
<zyga> https://bugs.launchpad.net/snapd/+bug/1835795 is something that might impact design of the command that creates the seed structure
<mup> Bug #1835795: seeding a snap with higher assumes than deb pkg of snapd on classic fails <snapd:Confirmed> <https://launchpad.net/bugs/1835795>
<zyga> ping pedronis for architectural consideration, I think you can just read the 1st comment on the bug for a brief summary
<zyga> I think https://bugs.launchpad.net/snapd/+bug/1835805 is something jdstrand should add to his queue for some ideas on how we could design enough changes to unblock using classic snaps like compilers from other classic snaps, like developer IDEs
<pedronis> zyga: I fear it's medium
<mup> Bug #1835805: strict snap run from classic snap can't write to filesystem <snapd:Triaged> <https://launchpad.net/bugs/1835805>
<zyga> pedronis: please reassign the priority as you see fit
<ijohnson> zyga: yay for triaging my bugs
<zyga> ijohnson: thank you for filing nice bugs :)
<ijohnson> oh actually that most recent one about strict snap from classic snap is on the forum somewhere, let me update that one too
<pedronis> zyga: made a comment as well, I don't think it's a seeding time validation problem
<zyga> pedronis: do you think and older snapd should be able to interpret a seed with assumes that it cannot itself satisfying by properly staging the re-execution step?
<pedronis> zyga: that's even a different problem
<pedronis> we are talking assumes here
<pedronis> we haven't really changed the seed format in a long while
<zyga> that's true
<zyga> that's a separate issue
<pedronis> at some it becomes a "it hurts then don't do it" sort of situation
<pedronis> assumes are bound to change quicker than sruing so I understand the concern
<zyga> pedronis: indeed
<pedronis> my point is mostly I don't think we need an unrealistically general solution
<zyga> pedronis: I think as long as snapd can reexec it could be handled with proper logic in snapd itself
<pedronis> still feels medium to me
<zyga> sure, I think that as we do this more often (now) we will get a broader shared understanding of each priority
<ijohnson> pedronis, mvo: I'm now blocked waiting on reviews for my snapstate PR's, should I work on reviews today or move on to fixing the socket/timer stuff we discussed in Paris?
<pedronis> ijohnson: you can do a bit reviewing, I'll try to get to some of your PRs today myself
<ijohnson> ack, thanks!
<mup> PR snapd#7509 opened: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
<pstolowski> pedronis: re debug timings & start-time (what we discussed yesterday). it's slightly annoying: we have start times in timings for some tasks, but it's not guaranteed. some handlers may not implement timings, also sometimes timings are not stored (>5ms threshold). but we still report all tasks of the change (just doing/undoing time, with no nested timing details). so, we can use start-time if available, but otherwise
<pstolowski> need to fall back to something else. not sure if it makes sense, may be confusing.
<pedronis> pstolowski: it will be confusing
<mup> PR snapd#7510 opened: daemon: make /v2/download take snapDownloadOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7510>
<mup> PR snapd#7286 closed: tests: use images:ubuntu/ in lxd tests <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7286>
<pstolowski> pedronis: so i think we need to stick to timestamps already available on Tasks. ReadyTime() ?
<pedronis> pstolowski: no, we need to step back a bit and consider our options
<mup> PR snapd#7447 closed: snapstate: do not allow removal of the snapd snap <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7447>
<roadmr> but I want to use core without snapd ð¤
<Chipaca> roadmr: ?
<roadmr> j/k Chipaca ð
<ijohnson> roadmr: there's an experimental option in edge that I think you can use now if you wanted to be serious
<roadmr> ijohnson: not really, I mean, how would I even install stuff on a snapd-less core system...
<ijohnson> you'd use the snapd snap and not the core snap!
<mup> PR snapd#7506 closed: devicestate: add support for gadget->gadget remodel <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7506>
<mup> PR snapd#7377 closed: patch: add an overlord patch that normalizes channel in state <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7377>
<mup> PR snapd#7495 closed: [RFC] tests: add gh action for static checks <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7495>
<diddledan> don't you need the snapd snap installed to be able to install the snapd snap?
<diddledan> bootstrapping is hard
<ijohnson> no first you install the "snap your fingers to turn the lights on" thing from night at the museum, then you snap your fingers and install the snapd snap
<diddledan> doesn't snapping your fingers make 50% of all living things disappear?
 * ijohnson stops snapping fingers
<mup> PR snapcraft#2729 closed: snaps: if snap is installed, don't check is_valid() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2729>
<pedronis> pstolowski: one option is to return the actual info about what waits for what and do a topological sort (in the client), generally in a lane tasks are sequential so ready time is probably as good as start time. so sortint (min(lanes), ready time) seems ok, except we need to think what to do about lane 0 tasks
<pedronis> if we go that way
<pedronis> pstolowski: I have a meeting now, do you want to have a chat in ~45 mins or tomorrow?
<pstolowski> pedronis: later today works for me
<pedronis> pstolowski: ok, I'll ping you
<pstolowski> pedronis: thanks!
<cachio> mvo, when it gets stuck I see this https://paste.ubuntu.com/p/CNb5P2Kf7K/
<cachio> mvo, the problem seems to be with the focker-support interface
<zyga> focker-support?
<zyga> did we add a new interface? ;-)
<diddledan> damn those fockers
<zyga> cachio: can you look at journal  please? anything interesting there
<cachio> zyga, no I can't
<cachio> the machine is dead
<cachio> I'll run again
<cachio> and print the journal
<zyga> diddledan: those fockers were meserszmits
<zyga> cachio: interesting
<zyga> cachio: is it responding to ping?
<cachio> perhaps doing that I can get nicer information
<zyga> cachio: ping is a good way to check if the kernel is up
<zyga> cachio: but userspace is bonkers
<zyga> cachio: please try that the next time if you can
<zyga> cachio: keep pinging the machine
 * diddledan spits some fire
<cachio> zyga, sure
<cachio> I'll make another round
<zyga> cachio: once ping stops working it's a good indicator that the kernel went belly up
<zyga> cachio: how do you reproduce this issue roughly?
<diddledan> or you tripped over the cable
<zyga> I don't want to jump into it
<zyga> but I'm curious for tomorrow
<zyga>    33 root      20   0       0      0      0 S  66.0  0.0   0:09.06 kswapd0
<cachio> zyga, spread2 -repeat 10 -show-output external:ubuntu-core-16-64:tests/main/interfaces-many-core-provided
<zyga> this feels like OMG MEMORY
<zyga> KiB Swap:        0 total,        0 free,        0 used.    15462 avail Mem
<zyga> and in fact, we have no swap
<diddledan> who needs swap?!
<cachio> with core 16 image from beta
<zyga> cachio: can I ask you to run another command in a separate connection
<cachio> zyga, yes
<zyga> cachio: run slabtop
<zyga> in case it is memory
<cachio> zyga, sure
<zyga> cachio: external, is the target a physical machine?
<zyga> cachio: or kvm?
<cachio> kvm
<cachio> running in my laptop
<zyga> cachio: perhaps log in as root
<zyga> cachio: on the console
<zyga> (if you have one)
<cachio> yes
<cachio> I do that
<ogra> wiggle the cable !!
<cachio> zyga, running
<cachio> zyga, I am having lunch and then I'll show you the output
<zyga> thanks
<cachio> zyga, to you
<zyga> I may be away but I'll happily look tomorrow
<cachio> zyga, sure
<cachio> I'll continue researching this one
<cachio> zyga, thanks for the support
<zyga> I'm very curious to see what this will uncover
<pedronis> pstolowski: my meeting was quicker than usual, let me know when you can chat
 * cachio lunch
<zyga> mvo: hey, a quick question about https://bugs.launchpad.net/snapd/+bug/1840375 -- is it the case that we can now pass --extrausers to groupdel?
<mup> Bug #1840375: groupdel doesn't support extrausers <verification-needed> <verification-needed-bionic> <verification-needed-disco> <verification-needed-xenial> <snapd:Triaged by mvo> <shadow (Ubuntu):Fix Released by mvo> <shadow (Ubuntu Xenial):Fix Committed> <shadow (Ubuntu Bionic):Fix Committed>
<mup> <shadow (Ubuntu Disco):Fix Committed> <https://launchpad.net/bugs/1840375>
<pstolowski> pedronis: ok, i'm ready
<pedronis> pstolowski: going to the standup
<ogra> zyga, looks like the SRU isnt finished
<ogra> (so you could ... but only in "eoan core")
<zyga> ah, I didn't notice the "green" is fix commited
<zyga> oh well
<mvo> zyga: yes, iirc I added this to groupdel, let me double check
<mvo> zyga: https://launchpad.net/ubuntu/+source/shadow/1:4.2-3.1ubuntu5.5
<zyga> mvo: so is the bug fix committed now?
<zyga> mvo: actually, can you just update the bug as you see fit
<mvo> zyga: its in -proposed
<mvo> zyga: in a meeting
<zyga> sure
<mup> PR snapcraft#2730 opened: tests: update rust-toolchain test so it pulls from beta <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2730>
 * ijohnson takes a break
<mup> Bug #1606539 changed: handle errors from `snap create-user` gracefully <snapd:Triaged> <https://launchpad.net/bugs/1606539>
<mup> Bug #1609864 changed: Enable a command to be run on machine shutdown <cpc> <snapd:Triaged> <https://launchpad.net/bugs/1609864>
<mup> Bug #1633141 changed: gadget.yaml should specify disk/volume image sizing behavior <snapd:Triaged by maciek-borzecki> <Ubuntu Image:New> <https://launchpad.net/bugs/1633141>
<pedronis> mvo: I made a suggestion in #7348 , let me know what you think when you get to it
<mup> PR #7348: snapstate,store: check assumes early before downloading the snap <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7348>
<mup> Bug #1620592 changed: if your first installed snap contains a binary needing sudo ~/snap is created with root.root ownership <snapd:Triaged> <https://launchpad.net/bugs/1620592>
<mup> Bug #1621666 changed: It is possible to install the classic snap in a classic system <classic> <snapd:Confirmed> <https://launchpad.net/bugs/1621666>
<Chipaca> who works on microk8s?
<Chipaca> popey: do you know, offhand?
<ogra> Chipaca, there is an upstream bug for the issue linked inside the topic
<ogra> upstream sent him over to the forum
<popey> https://github.com/ubuntu/microk8s/graphs/contributors
<Chipaca> ah ok
<Chipaca> popey, ogra, thanks
<ogra> and there is no logical reason that this happens at all !!
<popey> logic... lulz
<ogra> neither is it reproducable
<ogra> (i mean not reproducable for any of us but fully reproducable for that user)
<mvo> pedronis: thank you, I check it out
 * Chipaca puts on his running shoes
 * zyga EODs
<pedronis> Chipaca: I did a pass on #7320
<mup> PR #7320: snap/pack, cmd_pack: 'snap pack --check-skeleton' checks interfaces <Needs Samuele review> <Created by chipaca> <https://github.com/snapcore/snapd/pull/7320>
<Chipaca> pedronis: thank you
<ogra> oh, wow ... another missing symlink issue !
<Chipaca> internet is needed to catch the etherbunny
<Chipaca> I'm soft-EODing and going for a run
<Chipaca> should be back in under an hour to poke at this a bit more
<ogra> well, i bet the reinstall will just fix it
<popey> of the snap or the whole machine?
<popey> also "fix" :)
<ogra> of snapd
<popey> refreshing core or installing the snapd should trigger that?
<ogra> well, he said core was pre-installed
<popey> no, i mean, refreshing rather than uninstall/reinstall
<ogra> my guess is something went wrong with initial seeding or so
<ogra> ah
<popey> plusible
<popey> could we add some checks at startup, that if a snap is marked installed, it must have a current directory?
<ogra> well, john already asked him to purge/reinstall ... i guess it is to late to check if refresh would have helped
<Chipaca> yeah, seed.yaml busted is a safe bet
<Chipaca> hopefully we can find the image and get it fixed
<Chipaca> anyway! run run run run
 * Chipaca disappears in a cloud of sweat
 * ogra sprays some deodorant around
<cachio> slabtop : https://paste.ubuntu.com/p/NTS4DCWKmG/
<cachio> zyga,
<mup> PR snapcraft#2730 closed: tests: update rust-toolchain test so it pulls from beta <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2730>
<mup> Issue classic-snap#33 opened: It is possible to install the classic snap in a classic system <Created by anonymouse64> <https://github.com/snapcore/classic-snap/issue/33>
<mup> PR snapd#7511 opened: tests: when the backend is external skip the loop waiting for snap version <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7511>
<cachio> zyga, I updated the standup doc with the details about the issue
<cachio> zyga, the problem is related to memory
<cachio> see you
<mup> Bug #1626082 changed: Fedora 24 install fail with snapd 2.14 <snapd:Fix Released> <https://launchpad.net/bugs/1626082>
<mup> Bug #1627860 changed: run fail at missing folder /lib/modules (eg. on a virtual host) <snapd:Fix Released> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1627860>
<mup> Bug #1639798 changed: enable gpio interface for rpi2/3 (and other boards if suited) <gadget> <Snappy:Fix Released> <https://launchpad.net/bugs/1639798>
<mup> Bug #1639952 changed: When running in unity8 desktop snap, snap application icons aren't found in app scope <personal> <Canonical System Image:Fix Committed by pat-mcgowan> <Snapcraft:Confirmed> <snapd:New> <ubuntu-app-launch (Ubuntu):Fix Released> <https://launchpad.net/bugs/1639952>
<mup> Bug #1649399 changed: 'daemon: dbus' is incomplete <snap-docs> <snapd:New> <https://launchpad.net/bugs/1649399>
<mup> Bug #1655834 changed: Support factory reset <snapd:In Progress> <https://launchpad.net/bugs/1655834>
<mup> Bug #1630976 changed: Incomplete home directory mapping <snapd:Confirmed> <https://launchpad.net/bugs/1630976>
<mup> Bug #1625817 changed: Document snap prepare-image options <snapd:Fix Released> <https://launchpad.net/bugs/1625817>
<mup> Bug #1635101 changed: /snap/bin is not added to path for "sudo su" <snapd:Confirmed> <https://launchpad.net/bugs/1635101>
<mup> Bug #1637934 changed: update install hook documentation <snapd:New> <https://launchpad.net/bugs/1637934>
<mup> PR snapd#7512 opened: Misc updates for strict k8s <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7512>
<mup> PR snapd#7513 opened: interfaces/docker-support,kubernetes-support: misc updates for strict k8s - 2.42 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/7513>
 * cachio EOD
<mup> PR snapcraft#2731 opened: meta: take no command-chain being prepended into account <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2731>
<mup> PR snapcraft#2727 closed: storeapi: use the channels attribute in push <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2727>
#snappy 2019-09-26
<mup> PR snapd#7512 closed: interfaces/docker-support,kubernetes-support: misc updates for strict k8s <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7512>
<mup> PR snapd#7513 closed: interfaces/docker-support,kubernetes-support: misc updates for strict k8s - 2.42 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7513>
<mborzecki> morning
<mup> PR snapd#7514 opened: cmd: add `snap debug bootvars` that dumps the current bootvars <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7514>
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> mvo: should we allow dumping of all bootvars too?
<mborzecki> mvo: since we've taken away all the tools to inspect them
<mvo> mborzecki: we don't have an interface in our bootloaders to say "give-me-all"
<mvo> mborzecki: plus uboot will have a whole lot of unrelated stuff
<mvo> mborzecki: but yeah, it could be useful but I am not sure how to do it?
<mborzecki> mvo: i see, teh Bootloader interface would need to be extended
<mborzecki> mvo: otoh, we build a map of all bootarg=value anyway, at least for grub and uboot
<mvo> mborzecki: yeah and its a bit unclear how this would apply to e.g. lk
<mborzecki> mvo: i suppose for lk it'd be ok to return just snap_*, reboot_reason and bootimg_file_name, there does not seem to be a genereic environment mechanism like uboot has
<mvo> mborzecki: right
<mborzecki> mvo: can you take a look at #7509? i still need to address the panics in the tests, we have helpers for packing snap files in the test but the test data is incomplet witht he checks i added
<mup> PR #7509: gadget, snap/pack: perform extended validation of gadget metadata and contents <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7509>
<mvo> mborzecki: sure
<mborzecki> mvo: thanks!
<mvo> mborzecki: is the test failing for silly reasons in that pr, i.e. does it just need a restart?
<mvo> mborzecki: I had some green runs this morning :)
<mborzecki> mvo: it's failing bc of the PR, i need to push one more fix there
<mvo> mborzecki: ok
<mborzecki> mvo: the checks have failed in #7514, something about a cmd/snap-seccomp/s.c in the tree
<mup> PR #7514: cmd: add `snap debug bootvars` that dumps the current bootvars <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7514>
<mvo> mborzecki: oh, woah
<mvo> mborzecki: I did not touch this, let me look at the failure
<mvo> mborzecki: this test failure is bizare
<mvo> mborzecki: looks like 7166 can almost land (just two small comments from samuele). thanks again for picking this one up!
<pstolowski> morning
<mvo> hey pstolowski
<mborzecki> mvo: yup will address those soonish
<mborzecki> pstolowski: hey
<mup> PR snapd#7515 opened: daemon: return "snapname_rev.snap" style when using /v2/download <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/7515>
<mvo> thanks for your review pedronis \o/
<zyga> Hey guys. I will file today off, if feel much worse than yesterday.
<zyga> Time to really get better
<mvo> zyga: uh, get some rest
<pstolowski> hi, get well zyga!
<pedronis> mvo: hi, made some initial comments asking for changes also in #7510
<mup> PR #7510: daemon: make /v2/download take snapDownloadOptions <Created by mvo5> <https://github.com/snapcore/snapd/pull/7510>
<mvo> pedronis: thanks
<pedronis> zyga: get well!
<mup> PR snapd#7434 closed: seed/seedwriter: implement WriteMeta and tree16 corresponding code <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7434>
<pedronis> #7441 and #7467 are ready for review
<mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
<mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<pedronis> mvo: couple more comment in 7514, I missed the Bootvars the first time around
<mvo> pedronis: thanks, fixing that now as well
<mborzecki> mvo:  are you planning to pick bootvars into 2.42?
<mvo> mborzecki: not really, why?
<pedronis> mvo: is John swapping today?
<mborzecki> mvo: #7508 is tagged for 2.42, wondering whether to land it now or wait for bootvars to land first, 7508 get updated and have both cherry-picked to 2.42
<mup> PR #7508: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7508>
<mvo> pedronis: let me check, iirc no but I could be wrong
<mvo> mborzecki: yeah, should be ok to skip on 2.42 as long as we fix master
<mborzecki> mvo:  ok, landing 2.42 then
<mborzecki> duh, landing 7508
<mvo> mborzecki: heh, ok
<mvo> mborzecki: I was worried for a moment
<mvo> pedronis: nothing in the calendar
<mvo> pedronis: maybe just a bit late?
<mup> PR snapd#7508 closed: tests: skip the ubuntu-core-upgrade on arm devices on core18 <Simple ð> <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7508>
<mborzecki> mvo: on that note, can you cherry-pick bb963563d0a8a1ad406a512c539072ca24ba8336 from that PR into 2.42 ?
<mvo> mborzecki: sure thing
<popey> zyga: friend of mine noticed snaps seem a broken on 19.10 - and found this bug https://bugs.launchpad.net/snappy/+bug/1656340  - any ideas?
<mup> Bug #1656340: XDG_RUNTIME_DIR is not created on app startup <bionic> <cosmic> <eco-team> <xenial> <Snappy:Triaged by zyga> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1656340>
<Chipaca> stgraber: is running nested snapped lxds supported? asking because #1777017 so either there are more steps needed, or we're doing something wrong
<mup> Bug #1777017: snap install lxd doesn't work within a container <AppArmor:Invalid> <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1777017>
<mup> Bug #1622336 changed: [DOC] snappy on KVM recommends cmd line that warns about RAW devices <Snappy:Fix Released> <https://launchpad.net/bugs/1622336>
<mup> Bug #1621769 changed: impossible to create a model assertion compatible with both snapd 2.13 and 2.14 <Snappy:Won't Fix by mvo> <https://launchpad.net/bugs/1621769>
<mup> PR snapd#7516 opened: daemon: allow /v2/assertions/{assertType} to query store <Created by mvo5> <https://github.com/snapcore/snapd/pull/7516>
<Chipaca> pedronis: #1662534 is interesting, passphrases can't end in whitespace because of how we use gpg
<mup> Bug #1662534: snap create-key misses space at end of passphrase <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662534>
<Chipaca> or because gpg :-)
<mborzecki> wow, whitespace in passwords
<pedronis> Chipaca: sounds strange, I don't think we are in charge of the i/o there
<pedronis> but maybe I'm missing something
<Chipaca> pedronis: as I say there, gpg strips whitespace from the batch mode thing
<Chipaca> it's documented under "unattended gpg key generation" in the info pages
<pedronis> Chipaca: ok, sounds low to me
<Chipaca> totes :-)
<Chipaca> but it's the sort of thing that can have you lose a lot of time if you don't know about it
<Chipaca> and as we are in control of _reading_ the passphrase, maybe we could warn?
<pedronis> sounds still low
<pedronis> Chipaca: are you asking me if you should had a warning today
<pedronis> ?
<pedronis> s/had/add/
<Chipaca> pedronis: no
<Chipaca> i agree it's low
<Chipaca> i'd say the low thing is to warn / block a passphrase we know is not going to work
<Chipaca> somehow fixing it so it works would be a "nah" :)
<pedronis> that can be even medium
<pedronis> Chipaca: I'm just a bit missing what input you need from me right now?
<Chipaca> pedronis: nothing, just sharing an obscure bit of info
<Chipaca> otherwise it's just me that knows this :)
<Chipaca> me and launchpad
<pedronis> ok, maybe I will retain it, or not :)
<Chipaca> heh
<Chipaca> i forget not everybody's brain is a sponge for stupid trivia
<Chipaca> pstolowski: https://paste.ubuntu.com/p/qy4Y3mgm2h/
<Chipaca> pstolowski: you're probably the most comfortable in that bit of code (configstate), care to look and see if that panic could still happen today?
<pstolowski> Chipaca: ah, you got me nervous for a second, it is a very old bug isn't it?
<Chipaca> pstolowski: yes :-)
<pstolowski> Chipaca: bug# for more context? i'll check it
<Chipaca> pstolowski: #1670501
<mup> Bug #1670501: invalid memory address or nil pointer dereference in transaction.go <snapd (Ubuntu):New> <https://launchpad.net/bugs/1670501>
<pstolowski> Chipaca: ty
<Chipaca> pstolowski: if you answer, start by apologising for us being bad at bugs
<Chipaca> please :-)
<pstolowski> Chipaca: i'll be very humble
<cjwatson> white space> TIL
<Chipaca> zyga: #1681068 is all yours
<mup> Bug #1681068: Unable to use content interface with read-write source paths bind mounted over read-only targets <snapd (Ubuntu):New> <https://launchpad.net/bugs/1681068>
<Chipaca> zyga: and #1681099 i guess
<mup> Bug #1681099: Bind mounting is not performed when a directory created in a config hook is used with the content interface <snapd (Ubuntu):New> <https://launchpad.net/bugs/1681099>
<Chipaca> pstolowski: another one, looks to be the same thing: #1699768
<mup> Bug #1699768: "snap set" causes snapd crash <snapd:Fix Released by stolowski> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):New> <https://launchpad.net/bugs/1699768>
<pedronis> Chipaca: zygmunt is off sick today
 * Chipaca assigns all the bugs to him
<pstolowski> Chipaca: thanks, i'll double check and mark as dupe if needed
<mup> PR snapd#7514 closed: cmd: add `snap debug boot-vars` that dumps the current bootvars <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7514>
<mup> PR snapd#7517 opened: run-checks: allow overriding gofmt binary, show gofmt diff <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7517>
<mup> PR snapd#7499 closed: many: move AppArmor probing code under sandbox/apparmor <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7499>
<mup> PR snapcraft#2731 closed: meta: take no command-chain being prepended into account <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2731>
<stgraber> Chipaca: that user is attempting to run a nested container without having set security.nesting to true, so that's not going to work
<Chipaca> stgraber: is that something we can detect to point them in the right direction?
<stgraber> Chipaca: not particularly easily as for security reasons one normally cannot inspect their own apparmor policy
<Chipaca> stgraber: thank you (for the explanation, and the update on the bug)
<pstolowski> hmm anyone having issues with github not offering just pushed branch for a PR?
<pstolowski> nvm, it suddenly decided to show them.. must have been a temporary hiccup
<Chipaca> yeah github was broken for a bit
<mup> PR snapd#7518 opened: cmd/snap: sort tasks in snap debug timings output <Created by stolowski> <https://github.com/snapcore/snapd/pull/7518>
<mup> PR snapd#7519 opened: tests: use `snap debug boot-vars` in "ubuntu-core-upgrade" test <Created by mvo5> <https://github.com/snapcore/snapd/pull/7519>
<Chipaca> huh, getting "this meeting has been updated to use Hangouts Meet" from the standup
<pstolowski> Chipaca: same
<degville> ^ me too!
<Chipaca> and the organizer is probably mvo :-|
<mborzecki> duh
<ijohnson> it had to happen sooner or later
<mvo> Chipaca: meh
<mborzecki> am i the only one there?
<ijohnson> hangouts actually died
<Chipaca> so, let's just use https://meet.google.com/rne-gzqm-kgg?authuser=1&pli=1
<mborzecki> hmmm, that's different link than i have
<Chipaca> mborzecki: you have a link?
<mvo> Chipaca: I updated the inviite
<mborzecki> Chipaca: typed in snappy-devel like i always did
<Chipaca> cachio: https://meet.google.com/agi-vdpd-myw?authuser=1
<mup> PR snapd#7511 closed: tests: when the backend is external skip the loop waiting for snap version <Created by sergiocazzolato> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7511>
<mvo> 7515 needs a second review
<Chipaca> mborzecki: which is the one that i need to review?
<mborzecki> Chipaca: https://github.com/snapcore/snapd/pull/7166
<mup> PR #7166: client: add doTimeout to http.Client{Timeout} <Created by mvo5> <https://github.com/snapcore/snapd/pull/7166>
<mborzecki> much fun when the schedule is crossing the month boundary and the current day is on the other month
<Chipaca> mborzecki: let's talk about ISO week numbers
<mborzecki> hahah
<Chipaca> just not today
<mvo> Chipaca: if you want to get something fun to start reviews with, pick 7515
<mvo> Chipaca: shouldn't be more than 5min of work
<Chipaca> mvo: my bias detector just exploded in a cloud of sparks
<Chipaca> mvo: *but* i had that one open already so eh
<mborzecki> and gnome-shell spamming the logs every second, wtf
<Chipaca> mborzecki: but it has all this information you need to know about!
<mborzecki> Chipaca: repeated every second :/
<mborzecki> obviously there's no way to have journald drop those messages, now i can enjoy all of my journal history filled with that crap
<mup> PR snapd#7515 closed: daemon: return "snapname_rev.snap" style when using /v2/download <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7515>
<mup> PR snapd#7348 closed: snapstate,store: check assumes early before downloading the snap <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7348>
<asymptotically> hi all, i am trying to install microk8s via snap and it explodes while trying to make some certificates, here is the log: http://paste.debian.net/1102701/
<asymptotically> i have tried the stable and edge channels but both fail, and now i'm not sure what else to try
<asymptotically> and sorry if this is the wrong place. i couldn't find a channel for microk8s and guessed that this would be the next best place :)
<Chipaca> asymptotically: whoa, that's not good
<Chipaca> kjackal: is that something you know about? ^^
<asymptotically> whoops, forgot to add that i am using snap 2.41 on debian 10
<ogra> asymptotically, did you try --stable instaed of --edge ?
<ogra> typically the edge channel is for active development
<kjackal> reading
<asymptotically> yeah, it gets the same error :( - i had a quick search through github issues and google, but it doesn't seem like anything similar has been reported (or my google-fu is weak)
<kjackal> asymptotically: can you try --channel=1.15/stable?
<kjackal> 187471
<kjackal> sorry
<asymptotically> thanks kjackal, seems like 1.15 installs and runs fine
<kjackal> I hope these library issues will go away when we go to strict confinement
<asymptotically> should i just report this as a bug on the microk8s issue page? or would it be a problem with my system
<kjackal> asymptotically: can you please open an issue at: https://github.com/ubuntu/microk8s/issues
<kjackal> asymptotically: I need to try it out
<asymptotically> https://github.com/ubuntu/microk8s/issues/679
<kjackal> great thank you
<ogra> jdstrand, did you forget about my "/sys/firmware/devicetree/base/soc/ranges" and "/sys/firmware/devicetree/base/system/linux,revision" addition to hardware-observe, or am i just to impatient (just making your it didnt get forgotten)
<jdstrand> ogra: not forgotten, just not done yet
<jdstrand> (it is in trello with other updates that are accumulating)
<ogra> ah, ok ... if there is a trello card i dont need to nag ... sorry then :)
<jdstrand> ogra: I added you to it
<ogra> thanks !
<cwayne> Now ogras gonna write a nagbot that comments on a Trello card every hour :p
<ogra> haha
<ogra> automation FTW !!!
<cwayne> We literally have a nagbot for open MPs
<ogra> roadmr, yo ... i tried to register a snap with "core-*" in the name today and got a "this name is reserved" ... after dropping the prefix (and calling my snap just ldap-server which is rather a bit too generic ... ) it worked fine ... do we have a global catchall thigie for anything prefixed with "core" ?
<roadmr> ogra: we do ;)
<ogra> ouch, k
<roadmr> ogra: if you really want core-whatevs we can grant it, you just need to request the name
 * ogra makes a mental note for next time
<roadmr> (well if you really want it and have a good justification for it :) I want many things but...
<ogra> yeah, i was to lazy for buerocracy :P
<roadmr> askocracy works better :)
<ogra> hahaha
<ogra> anyway, its ldap-server for now ... if i get people using it oout of context i'll probably have to rename
<cwayne> I prefer ircocracy
<ogra> but i expect people to complain then
<Chipaca> hmm, i should probably have breakfast
 * Chipaca goes
<joedborg> hey all, could anyone let me know how to remove interfaces with the network-control plug (if possible)?
<joedborg> `ip link delete` doesn't seem to work
<pedronis> #7441 needs a second review (it's very small)
<mup> PR #7441: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/7441>
<pstolowski> pedronis: done
<pedronis> pstolowski: thank you
<mup> PR snapd#7441 closed: asserts,seed/seedwriter: follow snap type sorting in the model assertion snap listings <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7441>
<pstolowski> fun fact, new spread test in my branch was failing on 14.04 on journalctl match, because without "-a" flag journalctl would cut off one of the critical log lines
<pstolowski> pedronis: which of your PRs is next?
<pedronis> #7467
<mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<pstolowski> k
<mup> PR snapd#7520 opened: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7520>
<mup> PR snapd#7517 closed: run-checks: allow overriding gofmt binary, show gofmt diff <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/7517>
<Chipaca> joedborg: why doesn't it work?
<ogra> or better "how" doesnt it work (whats the error ?)
<joedborg> Chipaca ogra
<joedborg> so the issue is that it doesn't appear to be deleting the interfaces, not thowing any errors
<ogra> did you monitor journalctl ?
<ogra> i cant imagine it just quietly fails
<pedronis> Chipaca: I asked for a review for https://github.com/snapcore/snapd/pull/7467 mostly because with default track/channel normalisation that code will need some care again, it has +2 though so I'm going to land it, you can look at it anyway
<mup> PR #7467: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<Chipaca> pedronis: ta
<mup> PR snapd#7467 closed: seed/seedwriter: resolve channels using channel.Resolve* for snaps <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7467>
<pedronis> mvo: pstolowski: I rebased the next one #7468 , this one is a bit more substantial given it add support for local snaps
<mup> PR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
<pstolowski> ty
<mvo> pedronis: looking
<Chipaca> pedronis: given snap.MountFile(foo, 5) gives us "/path/to/foo_5.snap", what would be a good name for something that returned just foo_5.snap given those args?
<pedronis> Chipaca: we have also a lot of code that does filepath.Base(info.MountFile()) fwiw
<Chipaca> it's a silly thing but i'm itching to do this; we've got %s_%s.snap in two different non-test places, and filepath.Base(snap.MountFile(...)) in something like 12
<Chipaca> pedronis: quite
<pedronis> Chipaca: my worry here is that the surface of these things is already quite big
<pedronis> the next person will likely do "%s_%s.snap" again
<Chipaca> not for the first time i wish go had some sort of a path interface that would hide this sort of stuff :-)
<Chipaca> pedronis: yeah
<Chipaca> it's already hard to figure out what you need, there
<Chipaca> fair point
<pedronis> Chipaca: which is the other place doing %s_%s.snap, I'm not finding it
<pedronis> I just see one in info
<pedronis> .go
<Chipaca> hmm, didn't m vo just add one?
<mvo> cyphermox: hey, I'm curious about the status of the netplan.io SRU. when do you think it will hit xenial-updates? mostly wondering because we prepare a new core stable release currently and it would be great if this fix would be part of it (cc ijohnson)
<pstolowski> cachio: have you seen ijohnson's question to #7520?
<mup> PR #7520: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7520>
<cyphermox> mvo: gah, I wish I could tell you better news but tbh it slipped my mind -- the SRU was uploaded to the unapproved queue but never reviewed
<cyphermox> mvo: I'll try to get that in -proposed today and then we can see what we can do about this
<cyphermox> mvo: ETA for your stable release?
<Chipaca> pedronis: looks like i broke something in the latest policy change :-) i'm digging into that
<mvo> cyphermox: in a meeting right now will get back to you. rough eta is early next week so probably a bit too early for you
<pedronis> Chipaca: as in spread test break but not unit tests?
<Chipaca> pedronis: yeap
<Chipaca> pedronis: broke google:ubuntu-core-16-64:tests/main/ubuntu-core-upgrade
<Chipaca> can't remove core:x3 despite it being not current and not in use
<pedronis> ok
<pedronis> seems we are missing unit tests then
<Chipaca> yeap :-)
<ogra> is there any particular reason why on many systems snap version doesn't list the kernel version ?
<ogra> it feels like every second/third time i ask someone on the forum to provide snap version i get no kernel line returned
<Chipaca> ogra: people remove it because they consider it sensitive information
<Chipaca> ogra: or, maybe it's too old?
<Chipaca> ogra: but it has been there since forever
<ogra> yes, i know
<ogra> it just feels like it is missing more often recently
<Chipaca> ogra: since 2.23 at least
<Chipaca> ogra: but this is 2.21 :-/
<ogra> yeah
<ogra> since he cant install core he has the deb version
<pstolowski> yay, #7355 finally green \o/
<mup> PR #7355: interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
<Chipaca> ogra: looks like no squashfs supportfs
<Chipaca> ffs
<ijohnson> pstolowski: yay do you need a review on that ?
<ogra> Chipaca, yep, like all pixelbooks/chromebooks
<ogra> seems there are more and more users of these devices though :(
<ogra> and the archive all these debian VMs use doesnt have squashfuse either
<mvo> cyphermox: meeting over. just read backlog. thanks for the update, would be great to have it in -proposed soon(ish). I will ponder a bit over this, we *might* upload it to our image ppa to get it even if its not in -updates yet but that would be a bit of a last-resort kind of thing
<mvo> cyphermox: please keep me updated on this one (and I will poke you again gently early next week :)
<pstolowski> ijohnson: yes please, thanks!
<ijohnson> ack will do today, probably after your EOD
 * Chipaca adds 220V to mvo's stick-of-poking
 * ijohnson adds US compatible 120V inverter on top
 * mvo hugs Chipaca and his enchanted +5 stick-of-management
<Chipaca> mvo: you forgot *glowing*
<cachio> pstolowski, answered
<cachio> was in a meeting
<cachio> thanks for the heads up
 * cachio out to get kids from school
<cachio> I'll be back in 20
<pstolowski> cachio: ty. fwtw i just had green run of spread on one of my PRs
<cachio> pstolowski, the error is not happenning in 100% of the runs but is still happening
<cachio> perhaps we need to wait today
<cachio> does it makes sense?
<jdstrand> zyga: hey, afaics, opensuse still has 2.39.1. I can never remember, it doesn't reexec, correct?
<ijohnson> jdstrand: zyga is off sick today
<jdstrand> zyga: nm. feel better
<Chipaca> siiigh
<Chipaca> i'm going to go for a run, maybe everything will be better when i get back
<jdstrand> does anyone remember if opensuse reexecs?
<ijohnson> cachio: yes that makes sense, I'll check in with you before EOD to see if opensuse repos are still not working
<ogra> Chipaca, like ... bojo the clown stepped down ?
<jdstrand> fedora is still on 2.39.2
<jdstrand> I know it doesn't reexec
<Chipaca> jdstrand: https://github.com/snapcore/snapd/blob/master/cmd/cmd_linux.go#L69
<stgraber> yeah, suse & fedora is what's holding LXD on core16
<stgraber> (we need 2.40 for the fix of base handling)
<jdstrand> Chipaca: I thought manjaro reexec'd...
 * jdstrand shrugs
<jdstrand> Chipaca: thanks :)
 * jdstrand is curious about when audio-playback will be everywhere
<jdstrand> Wimpress, popey: hey, do you have an in with electron? could you poke someone on https://github.com/electron-userland/electron-builder/issues/4234?
<jdstrand> kenvandine: would you mind looking at https://github.com/ubuntu/snapcraft-desktop-helpers/pull/197 ?
<mup> PR ubuntu/snapcraft-desktop-helpers#197: snapcraft.yaml: add audio-playback for audio <Created by jdstrand> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/197>
<jdstrand> Chipaca: btw, thanks for https://forum.snapcraft.io/t/show-interfaces-of-snap-before-installation/13252/3
<jdstrand> Chipaca: that is quite handy for the time being
<Chipaca> jdstrand: note for really old snaps it won't work (they'll have an empty snap-yaml)
<Chipaca> but, yeah
<jdstrand> Chipaca: it was a nice advertisement for the 'http' snap as well ;)
<jdstrand> Chipaca: cunning
<Chipaca> jdstrand: that's probably the only big caveat (the other is to note that it is per revision and the code i posted just grabs the first one)
<Chipaca> jdstrand: nah, regular http (via apt install httpie) can do that as well; if I plug the http snap it's using snapd:///... :-p
<Chipaca> but yes :-D
<roadmr> jdstrand: review-tools  20190924-2239UTC is now in production \o/
<ijohnson> pstolowski, any idea why systemd.Stop uses s.systemctl("stop",...) but everything else seems to use s.systemctl("--root",s.rootDir,...) ?
<ijohnson> should stop (and also start I guess) use the --root opt as well
<pstolowski> ijohnson: let me check the code.. i probably touched this long time ago is that right?
<ijohnson> pstolowski: well not sure if you touched this particular bit of code, but I think you had to do the same thing for snapctl stop , etc.
<ijohnson> just not sure if there's ever a reason we need to _not_ use --root when we talk to systemctl
<ijohnson> seems like we should always use --root
<pstolowski> ijohnson: i definately touched services wrt snapctl, yes, was long time ago
<om26er> Did I report the bug at the correct place https://bugs.launchpad.net/snapd/+bug/1845533 ? Or should that be reported for the distro package ?
<mup> Bug #1845533: snap info gets confused if there is a directory of the same name <snapd:New> <https://launchpad.net/bugs/1845533>
<pstolowski> ijohnson: yes i agree it looks suspicious, should probably be consistent, i'm not sure if there is a reason for that
<pstolowski> probably an omission
<pstolowski> eod for me
<pstolowski> o/
<ijohnson> ack, thanks pstolowski
<om26er> Is snapcraft autobuild trigger broken ? I made a code change to the master of a project that has autobuilds enabled but it didn't trigger even after 15 minutes, I now triggered the build manually.
<kenvandine> jdstrand, done
<pedronis> Chipaca: I think you fixed this recently https://launchpad.net/bugs/1845533 ?
<mup> Bug #1845533: snap info gets confused if there is a directory of the same name <snapd:New> <https://launchpad.net/bugs/1845533>
<jdstrand> kenvandine: thanks!
<cwayne> kenvandine: yo, your jobs should be fixed and running now
<kenvandine> cwayne: thanks
<Chipaca> pedronis: yep, fixed in master
<Chipaca> pedronis: actually, no
<Chipaca> pedronis: the bug that's fixed in master is a different one
<Chipaca> pedronis: the one in that report is not a bug at all
<Chipaca> "when I do snap info to a directory that isn't a snap, snap info gets confused: it says the directory isn't a snap!"
<Chipaca> er...
<Chipaca> ...what's the bug again?
<Chipaca> om26er: ^^ that's you i'm talking about :-)
<om26er> Chipaca you only need to run snap info for a snap that is not installed currently and have a directory of that name created
<om26er> cd ~; mkdir slow-snap; snap info slow-snap
<Chipaca> om26er: is 'slow-snap' a snap that exists
<om26er> slow-snap is a snap that I publish but you will get the complain that `error: no snap found for "slow-snap/"`
<om26er> Chipaca, yes it exists and you can repeat that issue with any snap that is currently not installed
<Chipaca> holy regressions batman
<Chipaca> when did this break
<Chipaca> om26er: thank you. I need to figure out what's going on. I'll update the bug with this information.
<om26er> great, you are welcome :-)
<om26er> Shall I change the bug to confirmed ?
<om26er> jdstrand this got rejected in a funny way (after first getting manual approval) https://dashboard.snapcraft.io/snaps/deskconnd/revisions/49/
<om26er> context: https://forum.snapcraft.io/t/auto-connection-request-for-deskconnd/13364
<Chipaca> hmmmmmmmmm
<Chipaca> om26er: could you confirm for me please that if you 'snap refresh core --beta' (or --edge), such that 'snap version' tells you you are on 2.42 pre, then the issue goes away?
<Chipaca> i think i might have fixed this without meaning to :-)
 * Chipaca will still create a PR with a test for this
<om26er> I assume you meant core18 instead
<Chipaca> you assume wrong :-)
<om26er> hah, ok, core it is then
<Chipaca> om26er: unless you have the 'snapd' snap, in which case that is the one to refresh
<Chipaca> but you'd have to turn that on with an experimental flag afaik
<Chipaca> so probably not
<Chipaca> (i think the change to it not being experimental is in .42)
<om26er> Chipaca yes, seems to be fixed with core from beta channel
<Chipaca> huzzah
<Chipaca> om26er: that's going out to candidate and then stable as soon as a couple of integration ducks get in line, hopefully it's not inconveniencing you too much until then
<om26er> yeah, its a v.small issue, compared to others that my softwares are facing right now ;-)
 * Chipaca hugs om26er 
 * om26er hugs Chipaca back
<om26er> its been a while since my last IRC hug
<om26er> roadmr are you around ? I am kind of blocked as all my snaps got auto-rejected (piconn, deskconn and deskconnd) :-)
<roadmr> om26er: omg that's horrible :(
<roadmr> om26er: let's have a look
<om26er> ```declaration malformed (unknown constraint key 'plug-publisher-id') declaration-snap-v2_valid_plugs (content, allow-auto-connection_plug-publisher-id)```
<roadmr> right - it was jdstrand who wrangled those declarations
<roadmr> let's see if I can figure out what the issue is
<roadmr> remember I said cross-publisher autoconnects were tricky? :)
<om26er> roadmr indeed, you said that ;-)
<roadmr> om26er: I think we'll need jdstrand to have a look - I can't spot anything wrong :/ he should be around in a bit
<om26er> roadmr no problem, thanks for looking into it. I'll be on for a while so I hope I'll catch Jamie then
<roadmr> sure; I see you posted on the forum so worst case, he'll see that later
<jdstrand> om26er, roadmr: looking
<jdstrand> I know the problem
<om26er> I guess that's a good thing ?
<jdstrand> yes
<jdstrand> gimme a sec
<jdstrand> om26er: ok r49 is fixed. let me fix the other revisions and snaps
<om26er> wohoo! you are a life saver
<jdstrand> roadmr: there was a typo in the wiki (https://wiki.canonical.com/AppStore/Reviews?action=diff&rev2=247&rev1=246)
<jdstrand> (that's an internal url, sorry)
<roadmr> jdstrand: oh! let's see!
<roadmr> jdstrand: I checked that but I guess if the typo was on the *reference* document I was never going to spot that :)
<roadmr> ah, that makes sense :) thanks
<jdstrand> om26er: ok, deskconnd is done. let me adjust the others
<jdstrand> om26er: deskconn fixed and r133 approved
<jdstrand> om26er: piconn fixed and r4 approved
<om26er> jdstrand is it normal that auto-connection no longer works ?
<jdstrand> om26er: gpiod fixed (nothing to approve, but next upload will auto-approve)
<jdstrand> om26er: the bug in the snap decl would've caused that
<jdstrand> om26er: with what I just fixed, it should work
<jdstrand> om26er: sorry for the hiccup. these snap declarations can be rather delicate
<jdstrand> om26er: please test to verify it is working as expected
<om26er> jdstrand my snaps are not auto connecting to crossbar snap now
<om26er> to reporduce `snap install crossbar --edge; snap install deskconnd --edge`
 * jdstrand is looking
<jdstrand> om26er: there is an interplay here since you are wanting two different content slots auto-connected from two different publishers while the snap is providing a content interface itself
<jdstrand> gimme a sec
<om26er> yeah, here is the outlook
<om26er> crossbar: provides runtime environmentdeskconnd: connects to crossbar, provides its own unix domain socket as welldeskconn: connects to crossbar and uses unix domain socket provided by deskconndpicon: connects to crossbar and uses unix domain socket provided by deskconnd
<jdstrand> om26er: I'm going to be fiddling with the snap declaration for deskconnd for a minute. if you get emails, don't worry about it
<om26er> jdstrand sure, no problem
<om26er> sorry for those pastes above, I am a little too used to Slack and didn't realize, IRC doesn't support much formatting
<jdstrand> oh
<jdstrand> om26er: slots:
<jdstrand>   runtime-dir:
<jdstrand>     content: executables
<mup> Bug #1845555 opened: snap refresh leaves behind old .mount files in /etc/systemd/system/ <Snappy:New> <https://launchpad.net/bugs/1845555>
<jdstrand> om26er: 'executables' is what is needed, not 'runtime-dir'
<jdstrand> om26er: did you change that? I didn't notice it before
<om26er> no, didn't change that, its been like that from the beginning
<jdstrand> om26er: ok, adjusting
<jdstrand> crossbar:runtime-dir                       deskconnd:crossbar-runtime-dir
<jdstrand> let me adjust the others
<Chipaca> could somebody on 18.04 check the 'wallstreet' snap (and deb) and confirm whether it works there?
<jdstrand> om26er: should be fixed: https://paste.ubuntu.com/p/zPqQ4cvz6P/
<jdstrand> om26er: I adjusted piconn and gpiod too, but didn't test as they are armhf
<om26er> jdstrand thank you, I tested deskconnd and deskconn they work great now. Will test piconn on the raspberry Pi
<jdstrand> om26er: cool, you're welcome and sorry it wasn't a totally smooth experience. the docs are updated for next time
<jdstrand> Chipaca: I happened to be ssh'd into a bionic vm, so snap installed wallstreet (eek, --classic!) and it just hangs
<Chipaca> jdstrand: does it then OOM?
<jdstrand> I don't know what it is supposed to do, but it seems that probably isn't it
<Chipaca> jdstrand: https://mobile.twitter.com/DustinKirkland/status/1177311322813403147
<jdstrand> jeez, first --classic, now twitter?
<jdstrand> :)
<Chipaca> not sure why that needs classic TBcmfH
<jdstrand> Chipaca: the deb does things that look like the tweet
 * jdstrand removes that and tries the snap again
<jdstrand> ok, the snap continues to not do anything
<jdstrand> it doesn't seem to be leaking memory
<Chipaca> thank you
<Chipaca> I wonder if that can be strictly confined
<Chipaca> I don't see why not
<Chipaca> I mean, it ships tmux
<jdstrand> it seems to be using screen and/or tmux
<Chipaca> but that's not necessarily classic, right?
<jdstrand> so, 'no'
<jdstrand> it is classic
<Chipaca> jdstrand: right, but it has tmux inside of itself
<jdstrand> I mean, it must today be classic
<Chipaca> jdstrand: and uses them to run things from itself
<jdstrand> yes but tmux does stuff that the sandbox disallows
<Chipaca> jdstrand: that works, surely?
<Chipaca> ahh
<Chipaca> ohhh
<jdstrand> you cannot run tumx in a snap
<Chipaca> booooh tmux boooooh
<jdstrand> or screen
<om26er> jdstrand tested on the pi, things are fixed. Thank you again :)
<jdstrand> there are setuid/setgid bits and other things
<jdstrand> om26er: woohoo! :)
 * om26er has a small home automation project that has UbuntuCore18 running and controls GPIO pins on the RPi for a few months
<jdstrand> om26er: neat :)
<jdstrand> Chipaca: super terse notes detailing my recent exploration of a 'tmux-support' interface: https://paste.ubuntu.com/p/Rnf6Pfz85y/
<Chipaca> jdstrand: :-(
<jdstrand> Chipaca: I time-boxed it and found that there were a number of issues with the terminal in that env that would have to be debugged
<jdstrand> Chipaca: I was able to get some stuff going though. if I looked really hard at 'script' and learned some pty/tty fu, maybe...
<Chipaca> :)
 * jdstrand maintains that screen and/or tmux should be in the core snap (which doesn't help wallstreet one bit)
<Chipaca> jdstrand: i thought we'd agreed on that already?
<mup> Bug #1845555 changed: snap refresh leaves behind old .mount files in /etc/systemd/system/ <snapd:Invalid> <https://launchpad.net/bugs/1845555>
<jdstrand> Chipaca: I thought the 'agreement' was 'no' :P
<jdstrand> if it was 'yes', then yay!
<Chipaca> it wouldn't be the first time i got those two words mixed up
<Chipaca> pedronis will know more
<Chipaca> i'll try to bug him about it
<jdstrand> cool, thanks :)
<jdstrand> oh I left wallstreet running this whole time. still no OOM
 * jdstrand kills it and tears down the vm
<Chipaca> jdstrand: you commie you
<Chipaca> tearing down wallstreet
 * roadmr is now known as GordonGekko
<Chipaca> roadmr: i expect you to update your profile picture accordingly
<jdstrand> hehe
 * roadmr visits gravatar.com
<roadmr> https://bit.ly/1KwjXmW <- whatcha think about this? not sure about the suspenders
<Chipaca> roadmr: https://www.mirror.co.uk/news/uk-news/boris-johnson-vs-gordon-gekko-2860801
<roadmr> oh hahaha what
<Chipaca> roadmr: also https://wallstreet.fandom.com/wiki/Gordon_Gekko?file=Gordon_Gekko.jpg
<Chipaca> anyway, i'm out of here
<Chipaca> ð
<roadmr> o/ enjoy
 * roadmr scored 9/10 in the quiz \o/
<jdstrand> roadmr: thanks for pushing 20190924-2239UTC :)
<jdstrand> joedborg: fyi, ^ has the override you need for your snap to pass automated review
<joedborg> ah awesome, thanks jdstrand roadmr
<joedborg> I'm just removing all the unnecessary layout rules and I'll push again
<roadmr> ð
<jdstrand> joedborg: yep, cool :)
<mup> PR snapd#7521 opened: [RFC] many: use --root as first arg to systemctl everywhere <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7521>
<joedborg> roadmr: jdstrand: managed to clear out alot of the layout https://github.com/charmed-kubernetes/snap-kubernetes-worker/commit/0d9548f866ae5114c64e99f039640553d60d804a
<roadmr> \o/
<joedborg> the snap is uploading rn
<joedborg> roadmr jdstrand rev 2 pushed
<jdstrand> joedborg: that's excellent!
<jdstrand> joedborg: I see it passed automated review too :)
<joedborg> jdstrand: yeah :D
<joedborg> Just need Snapcraft io to work now so I can schedule automated builds
<mup> PR snapcraft#2732 opened: project: use os.sched_getaffinity instead of multiprocessing.cpu_count <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2732>
<mup> PR snapcraft#2733 opened: cmake plugin: support disable-parallel option <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2733>
<mup> PR snapd#7522 opened: httputil: set user agent for CONNECT <Created by chipaca> <https://github.com/snapcore/snapd/pull/7522>
#snappy 2019-09-27
<mup> PR snapcraft#2733 closed: cmake plugin: support disable-parallel option <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2733>
<mborzecki> morning
<zyga> hey
<zyga> I'm sick but I will try to get some work done today
<zyga> no promises, it's a day off
<pstolowski> mornings
<mborzecki> zyga: pstolowski: hey
<zyga> hey :)
<mborzecki> zyga: why don't you type in /quit in your irc client ;)
<zyga> I hate being sick
<zyga> mborzecki, that's a good question
<mborzecki> :P
<mborzecki> heh :P
<zyga> well, that was interesting
<pedronis> pstolowski: 2.41+ has the unset option support ? or was it 2.40+ ?
<pedronis> degville: pstolowski: I'm adding some mention of how unsetting work to https://forum.snapcraft.io/t/system-options/87 as well
<pstolowski> pedronis: 2.41
<pedronis> pstolowski: thx, it's what I used, were there bugs with it and system that we fixed only in 2.42 ?
<pstolowski> pedronis: and thanks for updating the forum; nb i announced it before here https://forum.snapcraft.io/t/configuration-of-snaps-new-commands-for-unsetting/13118 and updated the docs (links in the annoncement)
<pedronis> pstolowski: yes, I saw the new docs, but somebody at some asked in the system options how to unset them
<pedronis> and we had some example at the top of how to set/get, so just added unset and ! there too
<pedronis> anyway degville is free to tweak/remove if he deems it annoying
<pstolowski> pedronis: yes, there was a bugfix for system i made on 11th Sep (so not in 2.41), but it was minor - you could unset unknown (unsupported) options and it wouldn't complain, whereas snap set errors out in such cases
<pedronis> ok, thx
<ogra> pedronis, moaning ... :) ... i assume there are no plans to turn Ubuntu Core into multi-user systems ? .... https://forum.snapcraft.io/t/passwd-command-error-in-app-snap/13408/7
<degville> pedronis: thanks for letting me know about the updates! I'll take a look.
<pedronis> degville: unrelated, did you see this: https://forum.snapcraft.io/t/is-snapd-forward-compatible-with-new-app-interfaces/10498/4
<degville> pedronis: ah, thanks. I'll update the snap.yaml reference.
<Chipaca> moin moin
<zyga> degville: do you know who maintains https://ubuntu.com/download/iot/kvm ?
<ogra> zyga, at the very bottom there is a "report a bug on this site" (most right option)
<zyga> thanks!
<pedronis> Chipaca: hi,  could you pin this from jdstrand for some reasonable time: https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/13418
<Chipaca> pedronis: how much is reasonable time?
<Chipaca> a month?
<Chipaca> six?
<Chipaca> 3 years, like the first crusade?
<mup> Bug #1626986 changed: snapd should allow snaps to define systemd unit alias names <snapd:Triaged> <https://launchpad.net/bugs/1626986>
<mup> Bug #1627218 changed: snap refresh does not pull the latest betas <snapd:Incomplete> <https://launchpad.net/bugs/1627218>
 * ogra hugs Chipaca .... i was really a bit lost with that passwd thread
<pedronis> Chipaca: 3 weeks
<Chipaca> pedronis: pinning until oct 21, ie the first monday after 3 weeks
<pedronis> thx
<mup> Bug #1627643 changed: oops on pi3 (seemingly wlan related) <Snappy:Invalid> <linux-raspi2 (Ubuntu):Fix Committed by p-pisati> <https://launchpad.net/bugs/1627643>
<Chipaca> pedronis: there's also "banner" topics which are even more prominent, fwiw
<Chipaca> there can only be one banner topic, there can be multiple pinned ones
<Chipaca> currently there are two globally-pinned topics; the other is the "welcome!" one
<pedronis> Chipaca: ok, pinning seems fine though
<Chipaca> pedronis: the policy PR always uses current for boot.InUse, which is wrong :-| need to change the api, probably
<Chipaca> explicit revision needed or sth
<degville> zyga: probably the web design team (sorry for the delay, I'm actually on a swap day and I've biked over to the cinema).
<Chipaca> pedronis: ok, advice needed: currently (in the PR) CanRemove takes a boolean 'all'. What's actually needed is *either* that boolean, *or* the index into Sequence (or the revision meant to be removed, but the index makes it unnecessary to return a lookup error). I could: 1. add a parameter, 2. change the boolean to an index, -1 meaning all; 3. change the boolean to a *Revision, nil meaning all; 4. ad-hoc opts struct that would need validating and thus
<Chipaca> add an error return. Leaning to (2) myself.
<Chipaca> 5. somehting else i didn't think of :)
<pedronis> Chipaca: variation on 2? pass a revision with unset meaning all?
<pedronis> well really 2+3
<Chipaca> pedronis: and add an error return / change it from returning bool to error, nil==ok (gives us error message) (feels like big api change, maybe squash the error and do the error return later)
<Chipaca> yes this is stream-of-conciousness irc
<pedronis> Chipaca: remember it's used in exactly one place
<Chipaca> unset meaning all sgtm fwiw
<pedronis> so I would add the error now
<Chipaca> pedronis: we have a TODO to report *why* you can't remove, so I'd change it to return an error with the why while I'm at it
<Chipaca> instead of the bool i mean
<pedronis> ok
<Chipaca> ok! on it
<Chipaca> pedronis: is CanRemove still the right name for something that returns error?
<mborzecki> hmm yum command line argument parsing seems broken
<pedronis> Chipaca: we tend to use Check for those situations but I'm not sure we are super consistent, maybe grep ?
<pedronis> I mean Check*
<Chipaca> yah, will do
<mborzecki> centos guys have pushed a systemd build that potentially fixes the issue we've been seeing, but passing --enablerepo=fasttrack in our pkgdb.sh seems to behave rather funny
<Chipaca> sigh, need to tweak the api of boot.InUse :-)
<Chipaca> more coffee first
<mup> Bug #1632508 changed: Get a way to differentiate uninstall/shutdown from snap update in stop script <libvirt> <lxd> <openstack> <snapd:Triaged> <https://launchpad.net/bugs/1632508>
<mup> Bug #1633111 changed: Missing API documentation for /v2/snaps/[name] POST <snapd:New> <https://launchpad.net/bugs/1633111>
<zyga> Chipaca: is the REST api documented on the forum?
<Chipaca> zyga: no, the wiki
<zyga> Chipaca: the github wiki?
<zyga> ah, I see it at https://github.com/snapcore/snapd/wiki/REST-API
<Chipaca> zyga: and, it's always out of date :-|
<Chipaca> but, it's a good place to start
<Chipaca> zyga: why?
<zyga> Chipaca: when spread churns I'm looking at bugs https://bugs.launchpad.net/snapd/+bug/1633111
<mup> Bug #1633111: Missing API documentation for /v2/snaps/[name] POST <snapd:Fix Released> <https://launchpad.net/bugs/1633111>
<mup> Bug #1635011 changed: /v2/changes/ is not documented in rest.md <snapd:Fix Released> <https://launchpad.net/bugs/1635011>
<mup> PR snapd#7523 opened: sandbox/selinux: move SELinux related bits from 'release' to 'sandbox/selinux' <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7523>
<mborzecki> zyga: ^^^
<zyga> mborzecki: ack
<mup> Bug #1647139 changed: CalledProcessError: Command '['/usr/bin/sudo', '/usr/sbin/chroot', '/home/buildd/build-SNAPBUILD-12520/chroot-autobuild', 'linux64', '/bin/sh', '-c', 'cd /build/qucs-spice && env LANG=C.UTF-8 https_proxy=http://snap-proxy.launchpad.net:3128
<mup> http_proxy=http://snap-proxy.launchpad.net:3128 SNAPCRAFT_LOCAL_SOURCES=1 snapcraft pull']' returned non-zero exit status 1 <build> <lp> <Snapcraft:Incomplete> <https://launchpad.net/bugs/1647139>
<zyga> mborzecki: +1
<mborzecki> zyga: seccomp is the last bit that's still under release
<mborzecki> not for long though :)
<mup> Bug #1697770 changed: can't run juju from snap: "Too many levels of symbolic links" <snapd:Won't Fix> <https://launchpad.net/bugs/1697770>
<mup> Bug #1740130 changed: Use XDG set profile folders <Snappy:Invalid> <https://launchpad.net/bugs/1740130>
<pedronis> Chipaca: can help with those questions you sent in the PR? notice that gadget doesn't apper in any boot env stuff, so not sure how in use would help
<Chipaca> pedronis: d'oh. ok, for gadget. What about kernel?
<Chipaca> pedronis: we're checking both
<mup> PR snapd#7524 opened: tests: add unit test for gadget defaults with a multiline string <Created by stolowski> <https://github.com/snapcore/snapd/pull/7524>
<pedronis> Chipaca: both, what both?
<pedronis> or which both?
<Chipaca> pedronis: boot.InUse and model.Kernel
<pedronis> that sounds ok
<Chipaca> pedronis: isn't it redundant?
<pedronis> doesn't InUse need a revision?
<Chipaca> pedronis: yes
<pedronis> so what if it's all
<Chipaca> pedronis: (although i've modded it locally to take unset to mean 'any'
<Chipaca> hmmm
<Chipaca> maybe i've overcomplicated things then :-)
<pedronis> yes
<pedronis> likely
<Chipaca> :-)
<pedronis> if all,  check model,  if revision check in use
<pedronis> something like that?
<Chipaca> yeah, i'll make that explicit
<Chipaca> just so i don't forget again
<pedronis> core, boot base and kernel should have similar rules
<pedronis> (except core has rules for classic too)
<pedronis> pstolowski: I updated #7468 and answered sthe comments
<mup> PR #7468: seed/seedwriter: support local snaps <Created by pedronis> <https://github.com/snapcore/snapd/pull/7468>
<pstolowski> ty
<zyga> ah
<zyga> I learned something about mount namespaces just now
<zyga> man that stuff is tricky
<zyga> it's just super tricky
<zyga> on the upside this is invaluable to fixing bugs
<zyga> details shortly, let me write them down
<mup> PR snapd#7522 closed: httputil: set user agent for CONNECT <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/7522>
<mborzecki> anyone with power to cherry-pick and push to 2.42?
<zyga> 2.42 the branc?
<zyga> anyone
<zyga> the release? it's an SRU
<zyga> I must misunderstand your question
<mborzecki> zyga: hm afaik direct git push to the repo only works for mvo
<zyga> oh, that's new then
<zyga> I guess you can propose a PR instead
<zyga> just target 2.42
<mborzecki> mhm, opening right now
<pstolowski> yeah, why not PR?
<mborzecki> pstolowski: bc we don't need to run spread then
<pstolowski> mborzecki: bad bad ;)
<zyga> naughty :)
<mup> PR snapd#7525 opened: tests: disable {contacts,calendar}-service tests on Arch Linux (2.42) <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/7525>
<Chipaca> pedronis: so... https://github.com/snapcore/snapd/blob/master/overlord/snapstate/snapstate_test.go#L11132
<Chipaca> pedronis: i just broke that test :-|
<Chipaca> granted it passed by accident before, but it feels like an actual case we want to work
<Chipaca> that is: current boot kernel is not (no longer) the model kernel, you shouldn't be able to 'snap remove' it yet
<Chipaca> actually could be no longer or not yet, either way
<pedronis> Chipaca: sorry, how did it work before and how doesn't anymore?
<Chipaca> pedronis: as per above, i no longer call boot.InUse if the revision is unset
<Chipaca> pedronis: it worked up to this point because i'd use snapst.Current as the revision for InUse
<Chipaca> pedronis: sounds like i do need to tweak boot.InUse to check any when unset (could be in a separate pr)
<pedronis> Chipaca: I'm not sure that test make sense
<Chipaca> that would make life easier :-)
<mup> Bug #1845636 opened: connect-plug-i2c hook failing <Snappy:New> <https://launchpad.net/bugs/1845636>
<pedronis> if there is a kernel-to-be in a remodel conflicts should prevent to remove it, toward the end of the remodel it becomes in use (at which point checking for any on the other side doesn't) and at the very end we atomically switch the model
<pedronis> the current kernel  is still the one from the model except inside the remodel itself
<pedronis> until the remodel is done
<pedronis> at some earlier point as I said it stops to be in use
<mup> PR snapd#7526 opened: cmd/snap-confine: allow digits in hook names <Bug> <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/7526>
<pedronis> Chipaca: we let you remove by revision only non-current revisions no?
<mup> Bug #1845636 changed: connect-plug-i2c hook failing <snapd:In Progress by zyga> <https://launchpad.net/bugs/1845636>
<Chipaca> pedronis: correct
<pedronis> Chipaca: it might be that we need to turn that description I just made into a set of CanRemove tests
<pedronis> or really Remove tests
<pedronis> that show you can remove what you expect at various points of the switching
<Chipaca> with a remodel going on you mean?
<pedronis> well doesn't mean to be a real one
<pedronis> but to simulate something close enough
<pedronis> afaict the test you pointed at doesn't correspond to a possible state
<pedronis> (unless bugs)
<mup> Bug #1638988 changed: Cannot run spread hello world on all-snaps image <snapd:Triaged> <https://launchpad.net/bugs/1638988>
<Chipaca> zyga: don't we have an interface for lxc?
<zyga> Chipaca: not one that would allow you to run lxc-the-command-line-tool
<zyga> Chipaca: that's a general property btw
<Chipaca> zyga: even if you shipped it?
<Chipaca> zyga: just lxc, not lxd
<mup> Bug #1638796 changed: mir clients that use cpu renderable surfaces don't work under confinement <snapd:New> <https://launchpad.net/bugs/1638796>
<zyga> Chipaca: if you shipped it it might work but that's not what the bug is about
<Chipaca> zyga: i've got my spread-snap-contributor hat on
<zyga> Chipaca: casual combination of tools shipped as snaps is not supported
<zyga> Chipaca: when that combination is packaged as a snap
<zyga> Chipaca: if we expand spread to talk to lxc/d directly it's something to consider but I think that's not high priority
<mup> PR snapd#7527 opened: interfaces/input: support confined snaps accessing keyboard and mouse directly <Created by AlanGriffiths> <https://github.com/snapcore/snapd/pull/7527>
<Chipaca> zyga: i don't understand what you mean there
<Chipaca> zyga: spread has an lxd backend
<Chipaca> we already expect it to talk to it
<zyga> Chipaca: yes but that backend just invokes lxc as a new process
<zyga> Chipaca: if we agree on that, that's exactly what is not supported in snapd
<Chipaca> zyga: right, so if we ship lxc in the spread snap, that should work if we get the interface
<zyga> Chipaca: yes, that's correct
<Chipaca> zyga: sounds like an easy win, i'll see if i find time to do it
<zyga> Chipaca: if you want to, sure. I was just triaging old bugs as I wait for spread runs
<zyga> Chipaca: IMO we should explore how not changing the spread snap to ship lxc could be supported
<zyga> Chipaca: it's a more complex problem though
<zyga> Chipaca: involving lots of variables like API stability of the cli, passing resources, observing children termination, etc
<zyga> Chipaca: it would, however, allow us to handle this generally
 * zyga looks at the next PR
<zyga> Chipaca: IMO osutil.StreamsEqual is buggy
<Chipaca> zyga: oh? do tell
<zyga> Chipaca: it uses ReadAtLeast with a buffer size of 16K
<zyga> ah, sorry
<zyga> just scrolled down to see the error handling :E
<Chipaca> zyga: you mean the one that comes right after the six-line comment explaining the situation?
<zyga> yeah, I was scrolling down and reached the pair of ReadAtLeast
<zyga> and got curious about the buffer size
<zyga> anyway, go have lunch, sorry for the noise
<Chipaca> ð
<mup> PR snapd#7528 opened: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <https://github.com/snapcore/snapd/pull/7528>
<pedronis> not quite simple but not too big ^
<pedronis> something sergiusens pointed out
<mup> PR snapd#7521 closed: [RFC] many: use --root as first arg to systemctl everywhere <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/7521>
<zyga> pedronis: I will skip the standup, conflict
<pedronis> zyga: I will also be in the conflict
<zyga> ok :)
<pedronis> Chipaca will drive the standup today
<sergiusens> Chipaca: wrt spread lxd, if you ship the lxc binary and your lxd backend is a non local remote, you don't need any interface
<sergiusens> Chipaca: heh, using local would only require being able to talk to the socket
<mup> PR snapcraft#2732 closed: project: use os.sched_getaffinity instead of multiprocessing.cpu_count <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2732>
<zyga> jdstrand: can you please enqueue https://github.com/snapcore/snapd/pull/7421
<mup> PR #7421: cmd/snap-confine: unmount /writable from snap view <Created by zyga> <https://github.com/snapcore/snapd/pull/7421>
<zyga> jdstrand: you reviewed that before, v2 is simpler and should be good-to-go
<pedronis> zyga: I think he is swapping today
<zyga> pedronis: yeah, I was just checking since he's away on IRC
<zyga> that's fine
<zyga> I'll ask next week
<cwayne> kenvandine: ok so the fix did indeed seem to work, let us know if you run into any more issues (or whenever you want us to add new snaps :D)
<mup> PR snapd#7526 closed: cmd/snap-confine: allow digits in hook names <Bug> <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7526>
<zyga> Chipaca: hey
<zyga> Chipaca: I have a question about osutil/cmp_test.go
<zyga> Chipaca: can you please look at TestCmp there
<zyga> Chipaca: the buffer size is fixed but the payload (file size) varies
<zyga> Chipaca: am I reading that right?
<pstolowski> pedronis: i think failures on #7528 are real, tests/main/base-invalid-type needs updating
<mup> PR #7528: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <https://github.com/snapcore/snapd/pull/7528>
<pedronis> pstolowski: quite possible
<pedronis> but somebody just restarted it
<pedronis> (not me)
<pedronis> so I cannot look
<pedronis> or I'm very confused
<Chipaca> zyga: yes
<zyga> Chipaca: thanks
<zyga> I'm almost done with that PR
<zyga> I removed my implemenetation
<zyga> added one extra check into yours
<zyga> and kept the set of tests
<pstolowski> pedronis: hmm not me
<pedronis> zyga: I moved the 'snap run --explain' notes to the forum: https://forum.snapcraft.io/t/snap-run-explain/13427
<zyga> pedronis: nice, thank you
<pstolowski> pedronis: the status is still visible: https://api.travis-ci.org/v3/job/590391360/log.txt
<ijohnson> pedronis, pstolowski: not me either
<pedronis> I was just confused by travis
<pedronis> I see the problem now
<pedronis> Chipaca: can CanRemove PR be reviewed again? or still WIP? (would not happen today)
<zyga> pedronis: can I give it a stab at implementing a super-simple version of that over weekend? I'm going to stay at home sick anyway
<zyga> pedronis: or would you rather give it to someone else
<mup> PR snapd#7520 closed: tests: moving opensuse to unstable due to catastrofic issue on the repo <Created by sergiocazzolato> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7520>
<pedronis> zyga: how far are we from wrapping up robustness?
<zyga> pedronis: I need some jamie time for the reviews, probably a day or so
<zyga> pedronis: it is that and app awareness next week
<zyga> pedronis: I think I can do new stuff now
<pedronis> zyga: you could start to sketch --explain but might likely have to give it to somebody else to finish depending
<zyga> ok
<pedronis> it's lower priority than the other things on your plate
<pedronis> basically
<zyga> pedronis: ack
<pstolowski> zyga: what's the plan re https://github.com/snapcore/snapd/pull/6174 ?
<mup> PR #6174: many: add snap debug refresh-catalogs <Created by zyga> <https://github.com/snapcore/snapd/pull/6174>
<zyga> pstolowski: I'll fix it up next week
<zyga> or perhaps today if I finish the pass over other PRs
<zyga> pstolowski: needs some deconflicting/rebasing
<pstolowski> ok, thanks
<pstolowski> pedronis: btw my #7355 is redy for reviews again
<Chipaca> pedronis: I recentl pushed to the canRemove pr, i think it's good to go but i thought so yesterday and then spread failed :-)
<mup> PR #7355: interfaces/apparmor: load multiple profiles in a single batch <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/7355>
 * zyga -> lunch
<pedronis> Chipaca: ok
<pedronis> pstolowski: thanks, probably will look at it on Monday at this point
 * ijohnson will miss TGIF, still in middle of reviewing 7355
<pstolowski> ijohnson: take a break ;)
<pstolowski> ijohnson: btw appreciate it!
<Chipaca> pedronis: i just spotted a bug i think
<Chipaca> pedronis: :-( i'll comment on it in case you get to review it before i fix it
<Chipaca> at the very list it points to a missing test
<Chipaca> least*
<Chipaca> oh dear me
 * Chipaca takes a break
<Chipaca> ahem. For real now.
<pedronis> pstolowski: I did this: https://github.com/snapcore/snapd/pull/7469/commits/700ce5a5d816c37901e686fd689f586b40dbc2e5 in the next PR
<mup> PR #7469: seed/seedwriter,snap/naming: support classic models  <Created by pedronis> <https://github.com/snapcore/snapd/pull/7469>
<zyga> ondra: offtopic
<zyga> ondra: I have a thing I wanted to show you
<zyga> ondra: I wrote it earlier this week, perhaps it could be something useful to your team
<zyga> ondra: check this out please https://gist.github.com/zyga/2210f334115645a0014e1ecce22a944c
<zyga> ondra: it's a tool for extracting SD card image off a running system
<zyga> ondra: and streaming it to a nearby computer
<zyga> ondra: there's some "pre-preparation" step that's missing in the script itself (dd if=/dev/zero of=zero bs=4M; rm zero;) but we can consider polishing the script some more
<pstolowski> pedronis: ty!
<zyga> ondra: it works on core18, can easily work on core16 (I didn't try) and most importantly, on windows / linux / mac on the receiving end
<zyga> ondra: so anyone can easily capture an image and send it for analysis
<zyga> ondra: on windows just double-click on the script and continue (install python first)
<zyga> ondra: on other systems it's more generic
<ondra> zyga that looks interesting!
<ondra> nice one
<zyga> ondra: I have some more ideas to make it robust but I wanted to share a quick prototype with an user that needed it
<zyga> Chipaca: I changed some code you wrote in https://github.com/snapcore/snapd/pull/7484 -- perhaps you could do a review over cmp.go there
<mup> PR #7484: osutil: generalize SyncDir with FileState interface <Created by zyga> <https://github.com/snapcore/snapd/pull/7484>
<zyga> ondra: if you end up using it and give it a life please tell me :)
<ondra> zyga we might use that as we go closer to production and need to debug special cases
<Chipaca> zyga: I might take a peek over the weekend
<Chipaca> right now, it's beer o'clock
<Chipaca> meaning it's go-get-the-supermarket-stuff o'clock, first
<Chipaca> put-the-pizza-in-the-oven o'clock
<Chipaca> that kinda stuff
<Chipaca> have a great weekend y'awl
<Chipaca> ijohnson: you too, when your time comes
<Chipaca> :)
<Chipaca> ð
<mup> PR snapd#7528 closed: overlord/snapstate: have more context in the errors about prerequisites <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/7528>
<mup> PR snapd#7529 opened: seed/seedwriter: cleanups and small left over todos <Created by pedronis> <https://github.com/snapcore/snapd/pull/7529>
<zyga> pedronis: I was about to look at 7529 but I think I am too tired today
<mup> Bug #1639984 changed: Granting incorrect access in the shutdown interface in snapd <snapd:Triaged> <https://launchpad.net/bugs/1639984>
<mup> Bug #1640281 changed: Conflict - Telemetry project, Snap, uses snapd and snapctl <snapd:Triaged> <https://launchpad.net/bugs/1640281>
<mup> Bug #1641752 changed: request for snap interface that expose userspace device APIs <snapd:Confirmed> <https://launchpad.net/bugs/1641752>
 * zyga stops triaging bugs and EODs
<zyga> it's 8PM anyway ...
<zyga> ttyl, enjoy your weekends everyone
<mup> Bug #1640114 changed: configure hook output not accessible <snapd:Confirmed> <https://launchpad.net/bugs/1640114>
<ijohnson> bye zyga, hope you feel better
<zyga> ijohnson: thank you :)
<pedronis> zyga: that one is simple in itself but is at the end of a long chain
<joedborg> afternoon all, i'm still having trouble debugging my configure hook - is there anyway I can see the output of the hook (snapd seems to swallow -x and echos etc)
<joedborg> and  it's not shown in the snapd journal
<ijohnson> joedborg: unfortunately no, not unless your configure hook exits with exit code 1
<ijohnson> but if it always does that, then you can't install the snap
<joedborg> ijohnson: can i run it within a snap shell? `sudo snap run --shell`
<joedborg> ijohnson: ah yes, looks like i can :)
<ijohnson> yes you should be able to
<joedborg> ijohnson: is there any plan to be able to float errors / feedback from hooks?  if not, I might raise an LP
<ijohnson> no not really, hooks aren't really meant for that kind of thing, but feel free to file an LP bug
<ijohnson> joedborg: actually what you're looking for are snap warnings, see https://forum.snapcraft.io/t/warnings/7599
<joedborg> ijohnson: that looks promising, but i need more immediate feedback for validating of `snap set`
<joedborg> ijohnson: i guess the set-health is the best way
<ijohnson> joedborg: well if you are validating snap set, couldn't you just exit1 if it's wrong?
<ijohnson> then the user sees the output
<joedborg> ijohnson: yeah, i've got with `set-health` as it's more about getting 2 required configs set (as well as validating).  i have noticed that there's no record of `blocked` message in `snap warnings`
#snappy 2019-09-28
<mup> PR snapd#7424 closed: fixme: move snapfrompid into osutils <Created by ardaguclu> <Closed by ardaguclu> <https://github.com/snapcore/snapd/pull/7424>
