[00:28] <mup> PR snapcraft#1140 opened: catkin plugin: support building with an underlay <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1140>
[00:58] <mup> PR snapd#2853 closed: cmd: autoconf for RHEL <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2853>
[01:11] <mup> PR snapd#2854 opened: Fix error message using GET /v2/users as non-root <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2854>
[01:47] <sparkin> hi
[06:37] <mup> PR snapd#2854 closed: Fix error message using GET /v2/users as non-root <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2854>
[07:02] <mup> PR snapd#2855 opened: add intel realsense udev rules into camera interface <Created by swem> <https://github.com/snapcore/snapd/pull/2855>
[07:09] <mup> PR snapd#2840 closed: unity7: support missing signals and methods for status icons <Created by 3v1n0> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2840>
[07:10] <mup> PR snapd#2832 closed: interfaces/builtin: add network-setup-control which allows rw access to netplan <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2832>
[07:20] <mup> PR snapd#2856 opened: debian: add "Recommends: squashfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/2856>
[07:58] <mup> PR snapd#2857 opened: Add /boot/uboot/config.txt read/write/lock support to core-support <Created by mvo5> <https://github.com/snapcore/snapd/pull/2857>
[09:31] <mup> PR snapd#2830 closed: allow core_support interface to modify /etc/default/swapfile <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2830>
[09:31] <mup> PR snapd#2858 opened: Add missing newline character to end of deprecated command warnings <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2858>
[10:22] <mup> PR snapd#2851 closed: tests: failover test for rc.local crash <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2851>
[10:29] <ogra_> sergiusens_, hey ...
[11:06] <mup> PR snapd#2856 closed: debian: add "Recommends: squashfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2856>
[11:36] <sergiusens> ogra_: hey
[12:04] <mup> PR snapd#2859 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <https://github.com/snapcore/snapd/pull/2859>
[12:05] <mup> PR snapd#2859 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2859>
[12:06] <mup> PR snapd#2860 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2860>
[12:15] <ogra_> sergiusens, i'm struggling with an old problem ...
[12:16] <ogra_> sergiusens, namely with bug #1611439
[12:16] <mup> Bug #1611439: snapcraft should be able to autofill the version field based on some property of the build and/or stage files. <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1611439>
[12:17] <ogra_> sergiusens, we need to somehow start using the snapd version string in the core snap version field
[12:18] <ogra_> i tried sed'ing snapcraft.yaml during build on LP but that doesnt work, same goes for putting my own meta/snap.yaml in place ... would it be possible to allow the latter ?
[12:18] <mup> PR snapd#2859 opened: [WIP] overlord: switching to explicit targets for enabled/auto aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2859>
[12:18] <ogra_> or simply have snapcraft read an env var that gets set during the build and use that for the version ?
[12:18] <ogra_> SNAPCRAFT_VERSION_OVERRIDE ... or some such ...
[12:19] <ogra_> iirc the snap.yaml is generated, so it should be possible to inject something there i think
[12:20] <ogra_> sadly i cant manage that from the outside of the build, since the person building is free to use any PPA for the core builds ... which means i dont actually know what the final snapd version will be (and it is used that way by a few teams)
[12:20] <ogra_> and indeed launchpad doesnt allow me to do the build in steps either so that i could skip prime
[12:22] <mup> PR snapd#2570 closed: snap: add contact: line in `snap info` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2570>
[12:27] <mup> PR snapd#2861 opened: [WIP] interface hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2861>
[12:31] <pstolowski> mardy, hey, the next PR for interface hooks ^ in case you want to keep an eye on it. not yet fully ready for review, but close
[12:32] <mardy> pstolowski: thanks!
[12:33] <pstolowski> alecu, ^
[12:40] <alecu> pstolowski: amazing!
[12:52] <mup> PR snapd#2791 closed: store: use xdelta3 from core if available and not on the regular system <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2791>
[12:52] <sergiusens> ogra_: you can go all the way to `snapcraft prime` and them replace `prime/meta/snap.yaml` or sed it and then `snapcraft snap prime`
[12:53] <ogra_> sergiusens, how ... i'm building on launchpad
[12:53] <sergiusens> ogra_: I don't mind doing this over envvars though and not promote it `SNAPCRAFT_PROJECT_VERSION=2.21 snapcraft`
[12:54] <sergiusens> ogra_: but how will you get launchpad to use it?
[12:54] <ogra_> sergiusens, hmm, but i dont know the version before i call snapcraft
[12:54] <sergiusens> ogra_: is this related to my comment on version on the list?
[12:54] <ogra_> yeah, kind of
[12:54] <ogra_> we discussed it in the standup and the outcopme was that version: should be the snapd version inside the core snap
[12:55] <ogra_> so we can tie features to stable snapd versions in the docs
[12:55] <mup> PR snapd#2862 opened: cmd/snap, store: change error messages to reflect latest UX doc <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2862>
[12:55] <sergiusens> ogra_: I don't know how to solve this from a snapcraft PoV, we are peeling an onion to get the version, then putting the layers back on top and applying that to the meta data
[12:55] <sergiusens> ogra_: wouldn't it be better to have a special feature for this on launchpad?
[12:56] <ogra_> sergiusens, well, you could check for a pre-existing snap.yaml and in that case not generate one
[12:56] <sergiusens> ogra_: if you are going to go throught the trouble of creating a snap.yaml why not just set the version?
[12:57] <ogra_> sergiusens, how ? the version is already seeded when snapcraft reads snapcraft.yaml at the beginning of the build
[12:57] <sergiusens> ogra_: ok, I see. so I can compromise on "existence of file in project root .snapcraft_project_version"
[12:57] <ogra_> sergiusens, i only know the version i need later ... during the build
[12:58] <ogra_> sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there)
[12:59] <ogra_> that way i could just copy a snap.yaml in place during the build or generate it from the makefile
[13:04] <sergiusens> ogra_: had a crash and we aren't chatting on rocket, will need to repeat from what last I said ;-)
[13:04] <ogra_> sergiusens, but i'd be fine with .snapcraft_project_version as well indeed ... if you prefer that
 sergiusens, i only know the version i need later ... during the build
 sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there)
 that way i could just copy a snap.yaml in place during the build or generate it from the makefile
[13:05] <ogra_> but as i said, .snapcraft_project_version would indeed work as well for my case
[13:05] <ogra_> as long as prime reads it :)
[13:06] <sergiusens> ogra_: I'd rather not go the route and just overload the version
[13:06] <ogra_> fine with me then
[13:09] <ogra_> sergiusens, should i re-open the old bug ?
[13:09] <ogra_> (i am on rocket btw, we can move there if that helps)
[13:16] <Son_Goku> sergiusens: yo
[13:16] <Son_Goku> how's it going?
[13:18] <sergiusens> ogra_: read topic ;-)
[13:18]  * sergiusens finally has a reason to say that
[13:18] <Son_Goku> phooey
[13:18] <Son_Goku> snapcraft discussion isn't on IRC anymore? :(
[13:19] <ogra_> well, like snapd development hasnt been on IRC in a long time
[13:19] <Son_Goku> that's even worse
[13:19] <sergiusens> Son_Goku: good good
[13:19] <Son_Goku> sergiusens: :)
[13:23] <sergiusens> Son_Goku: you?
[13:23] <Son_Goku> sergiusens: I'm okay these days
[13:24] <Son_Goku> life stuff making things annoying, as always :)
[13:25] <sergiusens_> Son_Goku: great, I'll be working on repo stuff tomorrow or even this evening if time allows for it btw, will ping you for a review (probably straight on github)
[13:25] <Son_Goku> awesome
[13:25] <Son_Goku> looking forward to it
[13:48] <caiortp> Hi folks! I'm embedded developer and I have some question about the snappy
[13:49] <caiortp> I saw that it's possible to create a private snappy store...
[13:51] <caiortp> There's some tool (like resin.io / openstack ) to manage the snappys instances installed in each board?
[13:51] <caiortp> tks
[13:51] <caiortp> ;)
[14:46] <tommy_> hello
[14:47] <Guest12115> do you know if it is possible to install snapd on a Wheezy Debian ?
[14:48] <ogra_> Guest12115, https://github.com/snapcore/snapd/wiki/Distributions
[14:48] <Guest12115> i did it but it doesnt work
[14:48] <Guest12115> it cant recognize snapd
[14:49] <Guest12115> do you know the source ?
[14:49] <ogra_> what do you mean by "recognize" ?
[14:49] <Guest12115> paquet not found
[14:50] <ogra_> ah, right, wheezy is 7.0 ... afaik snapd only works in testing and unstable
[14:51] <ogra_> and there is is the the archive
[14:52] <ogra_> i doubt you can make it run on anything older
[14:58] <Guest12115> humm ok
[14:58] <Guest12115> thanks
[14:59] <Guest12115> have a nice day
[14:59] <Guest12115> i will dig a little
[15:20] <niemeyer> jdstrand: ping
[15:24] <mup> PR snapd#2863 opened: cmd/snap-confine: ensure that hotfs is root owned <Created by zyga> <https://github.com/snapcore/snapd/pull/2863>
[15:25] <mup> PR snapd#2858 closed: Add missing newline character to end of deprecated command warnings <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2858>
[15:27] <jdstrand> niemeyer: hey
[15:28] <niemeyer> jdstrand: Heya
[15:28] <niemeyer> jdstrand: Do you have a moment to meet with pedronis and myself?
[15:28] <jdstrand> niemeyer: actually, not atm. I have an appt in a few minutes. I can do it in ~3.5 hours
[15:29] <niemeyer> That sounds late for pedronis
[15:29] <pedronis> it's doable but slightly late
[15:29] <jdstrand> first thing tomorrow would be fine with me
[15:29] <niemeyer> Ok, let's do it tomorrow then
[15:29] <jdstrand> whichever you decide is fine with me
[15:29] <jdstrand> ok
[15:30] <jdstrand> my morning is open, so ping me at 14:00 or later when you want to meet
[15:30] <jdstrand> 14:00 UTC
[15:33] <ahayzen> didrocks, hey, to be able to properly test my change to the desktop-helpers, is there a way i can tell snapcraft to use a local version of the part rather than the cloud version?
[15:34] <didrocks> ahayzen: sure, you can cp the part from snapcraft.yaml you are interested in
[15:34] <didrocks> and change source:
[15:35] <ahayzen> didrocks, ah i see thanks :-)
[15:35] <didrocks> ahayzen: yw! easiest way to test AFAIK :)
[15:42] <flexiondotorg> ogra_ We discussed snapd-xdg-open the other day.
[15:42] <flexiondotorg> I have concerns.
[15:42] <ogra_> tell me
[15:42] <flexiondotorg> We talked about it need SRU to Trusty, which "fixes" a problem for Ubuntu.
[15:42] <flexiondotorg> But snapd-xdg-open isn't in Debian 9, or other distros.
[15:43] <flexiondotorg> Meaning the cross-distro story is broken.
[15:43] <flexiondotorg> Particular for snaps such as Spotify and Skype for Linux Alpha.
[15:44] <ogra_> flexiondotorg, well, talk to the snapd team, perhaps we can include it in the snapd package itself
[15:44] <flexiondotorg> niemeyer It that possible?  ^
[15:44] <flexiondotorg> ogra_ Thanks.
[15:45] <flexiondotorg> jdstrand Your thoughts on the above?
[15:45] <ogra_> thats the only idea i have beyond ... well ... pushing it into the other distros as well
[15:45] <flexiondotorg> Would need switch action for Debian 9.
[15:46] <flexiondotorg> mvo Is that still a possibility at this late stage?
[15:46] <niemeyer> flexiondotorg, ogra_: We have better plans for that
[15:46] <jdstrand> flexiondotorg: I agree it would have to be part of snapd
[15:46] <flexiondotorg> That is reassuring.
[15:46] <ogra_> after all the package only contains a single binary and a dbus service file
[15:46]  * jdstrand hasn't heard the better plans
[15:47] <flexiondotorg> niemeyer Is there a bug to track those plans?
[15:47] <niemeyer> jdstrand: You probably have, but it wasn't super high profile
[15:47] <niemeyer> flexiondotorg: Probably, can't remember as we haven't touched that conversation in a few weeks
[15:48]  * jdstrand -> appt
[15:48] <niemeyer> flexiondotorg: The idea is simple: instead of using dbus, we'll use snapctl
[15:48] <flexiondotorg> niemeyer Thanks.
[15:48] <flexiondotorg> OK, I'll go hunting. If I don't turn up an existing bug I'll raise a new one.
[15:49] <ogra_> after all you only want to forward a url to xdg-open ...
[15:50]  * ogra_ thinks there already way to much plumbing around it today, an overhaul will be healthy
[15:50] <niemeyer> ogra_: I don't think we're even using the real xdg-open today
[15:51] <niemeyer> It just looks like it
[15:51] <ogra_> well, the final call goes to xdg-open (at least it should)
[15:51] <ogra_> because that knows what to do with specific urls
[15:51] <niemeyer> I don't think it does, and I don't think it necessarily should either
[15:51] <ogra_> well, it needs to use the mimetypes to identify the right app to fire up for a certain handler
[15:52] <ogra_> you dont want to duplicated this on our side
[15:52] <ogra_> but i have never looked at the code of snapd-xdg-open so you ar probably right :)
[15:52] <niemeyer> Yeah, it doesn't really.. it uses g_app_info_launch_default_for_uri
[15:53] <niemeyer> ogra_: We're not duplicating code.. and we're chosing *which code* we're not duplicating. ;)
[15:53] <ogra_> heh
[15:54] <niemeyer> s/heh/Good idea Gustavo!/
[15:54] <ogra_> oh, it just uses glib, i see
[15:54]  * ogra_ just looked at the code for the first time
[15:54] <niemeyer> Either way, this is the status quo
[15:54] <ogra_> yeah
[15:54] <niemeyer> We most probably won't be using glib in the new implementation because we don't want more dependencies
[15:55] <ogra_> yeah
[15:55] <niemeyer> (it will be inside snapd itself)
[15:55] <niemeyer> I'd rather not use the mess of xdg-open.. but we'll see
[15:55] <ogra_> i'd just let xdg-open do its job and hand over the url from snapd
[15:55] <ogra_> simply because then it isnt our job to take care after the handoff
[15:56] <ogra_> heh, now i scared seb
[15:56] <niemeyer> We'll not implement tool-picking ourselves for sure.. but I'd prefer something cleaner if it exists
[15:56] <niemeyer> We'll see
[15:57]  * ogra_ would love if we could get rid of the ugly bits in the core snap ... more than caring about the handoff actually 
[15:59] <Cynerva_> any advice or best practices for passing args to a daemon that needs them?
[15:59] <Cynerva_> right now we're using a single "args" config, e.g. `snap set kube-apiserver args='--etcd-servers 10.123.123.14'`
[16:00] <ogra_> i'd use a wrapper script ...
[16:00] <Cynerva_> and a wrapper script that passes them into the daemon
[16:00] <ogra_> yeah, that sounds like an okayish approach
[16:02] <Cynerva_> okay, cool :) do you think it'd be better for us to break up the config?
[16:03] <ogra_> well, snap set doesnt really tell your config hook which the arg was, so in the end you will re-generate the whole config anyway
[16:04] <ogra_> s/arg/key/ actually
[16:07] <Cynerva_> ah sorry, i mean more from an usability perspective, i guess
[16:07] <Cynerva_> like instead of "args", we could have configs for "etcd-servers", "kubeconfig", etc -- all the flags that our daemon takes
[16:07] <ogra_> yeah, i'd do that long term
[16:08] <ogra_> and split it into categories so you can "yaml'ify" it later
[16:09] <Cynerva_> okay great. Thanks ogra_!
[16:09] <ogra_> :)
[16:11] <niemeyer> jdstrand: Comment fixed and improved: https://github.com/snapcore/snapd/pull/2604#issuecomment-280045941
[16:11] <mup> PR snapd#2604: interfaces: add classic-support interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2604>
[16:12] <mup> PR snapd#2864 opened: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2864>
[16:13] <mup> PR snapd#2604 closed: interfaces: add classic-support interface <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2604>
[16:21] <mup> PR snapd#2865 opened: image,cmd/snap: refactoring and initial envvar support to use stores needing auth <Created by pedronis> <https://github.com/snapcore/snapd/pull/2865>
[16:46] <mup> Bug #1665029 opened: snapweb needs a link for device when store selected <Snappy:New> <https://launchpad.net/bugs/1665029>
[16:46] <EEight> popey: bad news for me, my game is still not listed in Ubuntu Software. It is listed if installed via snap install, but it is not the idea, I want to have exposure from the store.
[17:16] <mup> PR snapd#2852 closed: cmd/libsnap: add privilege elevation helpers <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2852>
[17:21] <kyrofa> Hey barry, what is the recommended way to use ubuntu-image? From the snap, or from the deb?
[17:26] <ogra_> kyrofa, from the deb it depends on your host machine (for xenial you need the PPA with a newer ext4 lib) ... i'D go for the snasp from edge
[17:27] <ogra_> *snap
[17:27] <ogra_> *for the deb
[17:27] <kyrofa> Ah, good to know, thanks ogra_
[17:29] <elopio> jdstrand: zyga is asking for you in rocket chat.
[17:29] <elopio> he has "technical reasons" :)
[17:35] <alex-abreu> kyrofa, ping
[17:35] <kyrofa> alex-abreu, hey there! In standup right now but I'll be available in a minute. What's up?
[17:36] <alex-abreu> kyrofa, np I can wait, just a few questions around configure hooks ... the usual
[17:40] <alex-abreu> kyrofa, when a snap is getting installed, the configure hook is run before any daemon that the snap could host is started?
[17:43] <kyrofa> alex-abreu, no, the configure hook is run _after_ the daemons are fired up
[17:46] <kyrofa> alex-abreu, it's why bug #1661126 was logged
[17:46] <mup> Bug #1661126: Add One-shot Install/Uninstall Hook <feature> <hook> <install> <request> <snapd:Confirmed> <https://launchpad.net/bugs/1661126>
[17:52] <alex-abreu> kyrofa, yes ! ... so in general is there an easy mechanism to e.g. do a systemctl reload when a snap configuration is updated or infor the snap of a conf change?
[17:52] <alex-abreu> kyrofa, thx for the bug # ...
[18:08] <barry> kyrofa: really, it's entirely up to you.  consume it how you like. :)  one thing to keep in mind is that the snap version (currently) has some minor limitations, e.g. you can't put your model or extra snaps in /tmp and you can't output your images to /tmp.  other than that there shouldn't be much visible difference
[18:10] <kyrofa> alex-abreu, the method I use personally is to set the daemons up to restart always
[18:10] <kyrofa> alex-abreu, and then my scripts just kill the services in question (since systemctl is off limits)
[18:10] <kyrofa> alex-abreu, then systemd brings them back u
[18:10] <kyrofa> p
[18:12] <kyrofa> barry, ah, good to know, thank you
[18:12] <alex-abreu> kyrofa, this crossed my mind but sounded too "scary", ... :)
[18:12] <alex-abreu> kyrofa, do you have a snap example for that?
[18:12] <kyrofa> alex-abreu, definitely
[18:13] <kyrofa> alex-abreu, remember though that every daemon is different. This is for apache, which has a script that wraps it and utilizes a pid file, so I could just ask it to stop: https://github.com/nextcloud/nextcloud-snap/blob/master/src/https/utilities/https-utilities#L138
[18:14] <kyrofa> alex-abreu, but that could just as easily have been a kill -15
[18:17] <mup> PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions <Created by zyga> <https://github.com/snapcore/snapd/pull/2866>
[18:19] <alex-abreu> kyrofa, totally, thx
[18:24] <kyrofa> alex-abreu, I find it actually works pretty well. It would be pretty awesome if we could call systemctl for in-snap daemons though
[18:24] <alex-abreu> kyrofa, definitely ... is there a bug # for that? or a strong not to be able to ?
[18:25] <kyrofa> alex-abreu, I suspect there are technical issues with that, but jdstrand could answer better. Or morphis, I think he ran into it recently
[18:27] <kyrofa> By the way, jdstrand did you see my responses to https://github.com/snapcore/snapd/pull/2837 ?
[18:27] <mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
[18:31] <kyrofa> alex-abreu, to answer your question, I don't know of a bug for that
[18:40] <mup> PR snapd#2859 closed: [WIP] overlord: switching to explicit targets for enabled/auto aliases <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2859>
[18:40] <mup> PR snapd#2860 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2860>
[18:42] <mup> PR snapcraft#1141 opened: Use the existing code to find origin's snapcraft.yaml <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1141>
[18:44] <kyrofa> pmcgowan, you pinged me a while back about nextcloud not working on the dragon board. I'm sorry it took so long, but I finally got around to testing this myself, and at least the latest revision works fine. Have you tried recently?
[18:45] <pmcgowan> kyrofa, I haven't tried lately, I recall it was just a memory usage issue
[18:45] <kyrofa> pmcgowan, yeah I wouldn't be surprised
[18:46] <pmcgowan> kyrofa, did you run from stable or other channel
[18:47] <kyrofa> pmcgowan, stable, yeah. I think some efficiency gains landed in nextcloud v11
[18:48] <pmcgowan> ok will give it a try
[18:49] <kyrofa> pmcgowan, no rush, I just have the dragon up now so I can experiment if you run into issues
[18:53] <jdstrand> kyrofa: re https://github.com/snapcore/snapd/pull/2837, but haven't had a chance to circle back yet. hopefully today
[18:53] <mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
[18:53] <mariogrip> jdstrand: Hi, I pushed a snap to the store, but it seem to be stuck on "Revision waiting for review of a previous upload." even though the review of the previous upload is done
[18:54] <kyrofa> jdstrand, of course, no problem
[18:57] <pmcgowan> hmm kyrofa interesting you cannot refresh a disabled snap
[18:57] <kyrofa> pmcgowan, ah, I never tried. But that kinda makes sense... it's disabled
[18:57] <jdstrand> mariogrip: what is the link?
[18:57] <pmcgowan> kinda, but thats cause it doesnt run correctly
[18:57] <kyrofa> pmcgowan, hahaha
[18:57] <kyrofa> pmcgowan, good point
[18:58] <mariogrip> jdstrand: https://myapps.developer.ubuntu.com/dev/click-apps/6986/
[18:58] <pmcgowan> kyrofa, so I would remove and install instead
[18:58] <kyrofa> pmcgowan, or enable and refresh
[18:58] <pmcgowan> yeah, but then it sucks up my memory and my other snaps dont work :)
[18:59] <kyrofa> Yeah, remove/install might be a better path
[18:59] <kyrofa> pmcgowan, that might explain why it's working alright here-- I don't have any other snaps installed
[18:59] <jdstrand> mariogrip: I'm not sure how it got to that state... can you request a manual review and then I can reject it and the next one will get reviewed
[18:59] <pmcgowan> kyrofa, reminds me of a recent thread on not having snaps start right after install
[18:59] <mariogrip> jdstrand: It might be because i uploaded a new one before the review was done
[19:00] <mariogrip> jdstrand: but could you reject rev2 so it uses 3rev insted
[19:02] <mariogrip> jdstrand: manual review requested
[19:04] <jdstrand> nessita: fyi, https://myapps.developer.ubuntu.com/dev/click-apps/6986/rev/2/ seems stuck in 'Task state is unknown.'
[19:04] <jdstrand> nessita: mariogrip requested that it be rejected so rev3 may be auto-reviewed
[19:04] <nessita> jdstrand, hi, let me check
[19:05] <nessita> jdstrand, can you reload?
[19:05] <nessita> I see it failed
[19:05] <mariogrip> jdstrand: it says "Manual review pending" for me
[19:06] <jdstrand> nessita: ok, it isn't stuck. it took quite a while to get there. sorry for the noise
[19:06] <nessita> :-)
[19:06] <jdstrand> mariogrip: ok, rev2 rejected
[19:06] <mariogrip> jdstrand: Thanks :)
[19:22] <mup> PR snapd#2867 opened: screen-inhibit-control: add methods for delaying screensavers <Created by 3v1n0> <https://github.com/snapcore/snapd/pull/2867>
[19:25] <jdstrand> alex-abreu: we can't call systemctl from snaps without patching systemd. systemd isn't diesigned to be isolated and the snap requires a ton of privileges
[19:26] <jdstrand> systemctl isn't designed to isolate calls to applications that is
[19:26] <jdstrand> it could be made to do so. better would be to update snapctl so snapd could call ystemctl on the snap's behalf
[19:27] <alex-abreu> jdstrand, thx for the update, ... makes sense yes, something like a systemctl facility or expanding systctl could be very handy
[19:27] <alex-abreu> snapsctl I mean
[19:27] <kyrofa> jdstrand, agreed, we've tried to isolate snapd and snapd from knowing they're running on systemd anyway
[19:27] <kyrofa> snapd and snaps*
[19:27]  * jdstrand nods
[19:27] <kyrofa> So snapctl seems the best solution
[19:28] <jdstrand> yeah
[19:28] <kyrofa> jdstrand, from a technical standpoint though, can apparmor not parse cli args to a binary?
[19:45] <lutostag> any ideas what I'm hitting with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102 ?
[19:45] <mup> Bug #1665102: Snap refresh not working <snapd (Ubuntu):New> <https://launchpad.net/bugs/1665102>
[19:59] <sethj> wasn't there a bug report about being required to sign in to install a snap?
[20:13] <EEight> i poked popey directly, but if anyone knows about exposing a snap application in the ubuntu software (16.04 only) let me know, my app is not listed.
[20:13] <EEight> I think that only .debs will be listed there? Am I wrong?
[20:15] <nacc> isn't ubuntu software centre deprecated? gnome software seems to find sanps
[20:15] <nacc> EEight: what's your snap called?
[20:15] <kyrofa> EEight, I'm still not completely clear: does your snap not show up at ALL in xenial's software center, or just not in the correct categories?
[20:15] <kyrofa> nacc, I assume that's what EEight means
[20:15] <nacc> kyrofa: i always have to double-check in #ubuntu :)
[20:16] <kyrofa> nacc, fair enough!
[20:16] <EEight> nacc: bayam
[20:16] <nacc> EEight: is it french?
[20:16] <EEight> should be in Games / Kids
[20:17] <EEight> bilangual
[20:17] <nacc> my gnome software found a bayam snap
[20:17] <nacc> (on 16.10)
[20:17] <kyrofa> EEight, indeed, same here (on xenial)
[20:17] <EEight> yes, but I don't want people to search for it, I want the exposition of the categories
[20:17] <kyrofa> EEight, then you need to be clear with your problem!
[20:18] <EEight> my bad!
[20:18] <kyrofa> EEight, you said "my app is not listed [in ubuntu software]" which isn't the case
[20:18] <nacc> note that i don't see bayam under games/all eitehr
[20:19] <EEight> what is the process behind this, is there real people reviewing the snap submission?
[20:20] <kyrofa> EEight, not unless your snap requires manual review
[20:20] <kyrofa> EEight, I expect this is a limitation right now, of either the store or snapd
[20:20] <kyrofa> (or both)
[20:20] <kyrofa> EEight, I suggest logging a bug
[20:20] <nacc> yeah, it seems like snaps don't hav ea "Category" field set (visibly at least)
[20:21] <kyrofa> nacc, they kinda do, on the store side
[20:21] <kyrofa> nacc, but I don't think anything consumes that
[20:21] <nacc> kyrofa: right, i meant on the client side, sorry
[20:21] <nacc> kyrofa: whereas debs do show one visibly
[20:21] <kyrofa> nacc, indeed
[20:21] <nacc> yeah, seems like just an oversight (I assume the field would have to be found somewhat differently between debs and snaps)
[20:22] <kyrofa> Agreed
[20:23] <kyrofa> EEight, specifically, I suggest logging a bug against gnome software, since that's where the issue is surfacing. It'll get triaged and also-applied from there: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+filebug
[20:23] <kyrofa> EEight, again, be specific. Say that your snap shows up, but not in the categories you've requested
[20:24] <EEight> but the category from the .desktop file or from the myapps.developer.ubuntu ?
[20:24] <kyrofa> EEight, good question. I expect from myapps, since the desktop file is hidden away in the snap at that poit
[20:24] <kyrofa> point*
[20:24] <EEight> Then the myapps. should be updated to reflect all the categories...
[20:25] <kyrofa> EEight, heh, one problem at a time
[20:25] <kyrofa> EEight, plus I'm not certain that's the case, anyway
[20:29] <EEight> Well the myapps.dev website is in french here (cannot change the language). The field html name is department_id... and it should have a category (Games) and a sub-category (Kids). But like you said, one thing at a time.
[20:39] <EEight> Did my best: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1665126
[20:39] <mup> Bug #1665126: snap not listed in categories <snap> <gnome-software (Ubuntu):New> <https://launchpad.net/bugs/1665126>
[20:49] <kyrofa> EEight, looks great, thank you. I tweaked the description ever so slightly, but nice job
[21:40] <cjwatson> elopio: yeah, I need to finish fixing yakkety/zesty snap builds on LP
[21:41] <cjwatson> I see you ran headfirst into that
[21:48] <mup> PR snapcraft#1142 opened: Asset Tracking - Store versions of stage-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1142>
[23:14] <mwhudson_> hm
[23:14] <mwhudson_> ogra_: around?
[23:14] <mwhudson_> running /var/lib/classic/enable.sh in an unpacked core snap makes snapd think it's a classic system
[23:15] <mwhudson_> which is a pain
[23:20] <mwhudson_> oh it's because it overwrites lsb-release i think
[23:21] <kyrofa> mwhudson_, classic mode needs to act like classic ubuntu (regarding lsb-release) or various tools break
[23:21] <mwhudson_> ah hm
[23:21] <mwhudson_> what i am actually trying to do is make a core snap with an upgraded console-conf in it
[23:22] <kyrofa> mwhudson_, snapcraft, catkin, etc.
[23:22] <kyrofa> Ah
[23:22] <mwhudson_> maybe there is a better way to do this these days
[23:22] <mwhudson_> i guess i can just build my own core snap from scratch but ehh
[23:23] <mwhudson_> actually i think i can just unpack the new debs
[23:24] <mwhudson_> in this case
[23:24] <mwhudson_> but that won't work in full generality
[23:31] <mup> PR snapd#2868 opened: Don't return null result for async responses <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2868>
[23:42] <ogra_> mwhudson_, why the heck would you ever run that script ?
[23:42] <ogra_> mwhudson_, that script is the backend for the classic snap ...
[23:42] <ogra_> nothing you should run by hand :)
[23:43] <ogra_> snap install --devmode --edge classic; sudo classic ....
[23:43] <Guest32650> bah
[23:43] <ogra_> then you use the script  the right way
[23:45] <mwhudson_> ogra_: ok
[23:45] <ogra_> mwhudson_, to change the core snap itself, you should use unsquash it ... unpack your deb in the squashfs-root dir that created and then snapcraft snap squashfs-root ... then you can sideload it
[23:45] <mwhudson_> ogra_: yeah, that's what i did
[23:46] <ogra_> but do that on a PC ...
[23:46] <mwhudson_> i guess it hardly matters that the dpkg database is wrong...
[23:46] <mwhudson_> ogra_: no fear, i am not in the "snappy == iot" brigade :-)
[23:46] <ogra_> the dpkg database is gone
[23:47] <ogra_> we rip it out :)