[00:28] PR snapcraft#1140 opened: catkin plugin: support building with an underlay === tgm4883_ is now known as tgm4883 [00:58] PR snapd#2853 closed: cmd: autoconf for RHEL [01:11] PR snapd#2854 opened: Fix error message using GET /v2/users as non-root [01:47] hi === markusfluer1 is now known as markusfluer === durksauce_ is now known as durksauce === petevg_ is now known as petevg === arosales_ is now known as arosales === andyrock_ is now known as andyrock === victorbjelkholm_ is now known as victorbjelkholm === nottrobin_ is now known as nottrobin === ulkesh_ is now known as ulkesh === chihchun_afk is now known as chihchun [06:37] PR snapd#2854 closed: Fix error message using GET /v2/users as non-root [07:02] PR snapd#2855 opened: add intel realsense udev rules into camera interface [07:09] PR snapd#2840 closed: unity7: support missing signals and methods for status icons [07:10] PR snapd#2832 closed: interfaces/builtin: add network-setup-control which allows rw access to netplan [07:20] PR snapd#2856 opened: debian: add "Recommends: squashfuse" [07:58] PR snapd#2857 opened: Add /boot/uboot/config.txt read/write/lock support to core-support === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [09:31] PR snapd#2830 closed: allow core_support interface to modify /etc/default/swapfile [09:31] PR snapd#2858 opened: Add missing newline character to end of deprecated command warnings === caribou_ is now known as caribou [10:22] PR snapd#2851 closed: tests: failover test for rc.local crash [10:29] sergiusens_, hey ... [11:06] PR snapd#2856 closed: debian: add "Recommends: squashfuse" === chihchun is now known as chihchun_afk === sergiusens_ is now known as sergiusens [11:36] ogra_: hey [12:04] PR snapd#2859 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets [12:05] PR snapd#2859 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets [12:06] PR snapd#2860 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets [12:15] sergiusens, i'm struggling with an old problem ... [12:16] sergiusens, namely with bug #1611439 [12:16] Bug #1611439: snapcraft should be able to autofill the version field based on some property of the build and/or stage files. [12:17] sergiusens, we need to somehow start using the snapd version string in the core snap version field [12:18] 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] PR snapd#2859 opened: [WIP] overlord: switching to explicit targets for enabled/auto aliases [12:18] or simply have snapcraft read an env var that gets set during the build and use that for the version ? [12:18] SNAPCRAFT_VERSION_OVERRIDE ... or some such ... [12:19] iirc the snap.yaml is generated, so it should be possible to inject something there i think [12:20] 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] and indeed launchpad doesnt allow me to do the build in steps either so that i could skip prime [12:22] PR snapd#2570 closed: snap: add contact: line in `snap info` [12:27] PR snapd#2861 opened: [WIP] interface hooks: expose attrs to the interface API, snapctl enhancements (step #4) [12:31] 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] pstolowski: thanks! [12:33] alecu, ^ [12:40] pstolowski: amazing! === chihchun_afk is now known as chihchun === coreycb` is now known as coreycb [12:52] PR snapd#2791 closed: store: use xdelta3 from core if available and not on the regular system [12:52] 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] sergiusens, how ... i'm building on launchpad [12:53] ogra_: I don't mind doing this over envvars though and not promote it `SNAPCRAFT_PROJECT_VERSION=2.21 snapcraft` [12:54] ogra_: but how will you get launchpad to use it? [12:54] sergiusens, hmm, but i dont know the version before i call snapcraft [12:54] ogra_: is this related to my comment on version on the list? [12:54] yeah, kind of [12:54] we discussed it in the standup and the outcopme was that version: should be the snapd version inside the core snap [12:55] so we can tie features to stable snapd versions in the docs [12:55] PR snapd#2862 opened: cmd/snap, store: change error messages to reflect latest UX doc [12:55] 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] ogra_: wouldn't it be better to have a special feature for this on launchpad? [12:56] sergiusens, well, you could check for a pre-existing snap.yaml and in that case not generate one [12:56] ogra_: if you are going to go throught the trouble of creating a snap.yaml why not just set the version? [12:57] sergiusens, how ? the version is already seeded when snapcraft reads snapcraft.yaml at the beginning of the build [12:57] ogra_: ok, I see. so I can compromise on "existence of file in project root .snapcraft_project_version" [12:57] sergiusens, i only know the version i need later ... during the build [12:58] sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there) [12:59] that way i could just copy a snap.yaml in place during the build or generate it from the makefile === alan_g is now known as alan_g|lunch [13:04] ogra_: had a crash and we aren't chatting on rocket, will need to repeat from what last I said ;-) [13:04] sergiusens, but i'd be fine with .snapcraft_project_version as well indeed ... if you prefer that [13:05] sergiusens, i only know the version i need later ... during the build [13:05] sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there) [13:05] that way i could just copy a snap.yaml in place during the build or generate it from the makefile [13:05] but as i said, .snapcraft_project_version would indeed work as well for my case [13:05] as long as prime reads it :) [13:06] ogra_: I'd rather not go the route and just overload the version [13:06] fine with me then [13:09] sergiusens, should i re-open the old bug ? [13:09] (i am on rocket btw, we can move there if that helps) [13:16] sergiusens: yo [13:16] how's it going? [13:18] ogra_: read topic ;-) [13:18] * sergiusens finally has a reason to say that [13:18] phooey [13:18] snapcraft discussion isn't on IRC anymore? :( [13:19] well, like snapd development hasnt been on IRC in a long time [13:19] that's even worse [13:19] Son_Goku: good good [13:19] sergiusens: :) [13:23] Son_Goku: you? [13:23] sergiusens: I'm okay these days [13:24] life stuff making things annoying, as always :) [13:25] 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] awesome [13:25] looking forward to it === alan_g|lunch is now known as alan_g [13:48] Hi folks! I'm embedded developer and I have some question about the snappy [13:49] I saw that it's possible to create a private snappy store... [13:51] There's some tool (like resin.io / openstack ) to manage the snappys instances installed in each board? [13:51] tks [13:51] ;) [14:46] hello === tommy_ is now known as Guest12115 [14:47] do you know if it is possible to install snapd on a Wheezy Debian ? === matteo` is now known as matteo === matteo is now known as Guest52378 [14:48] Guest12115, https://github.com/snapcore/snapd/wiki/Distributions [14:48] i did it but it doesnt work [14:48] it cant recognize snapd [14:49] do you know the source ? [14:49] what do you mean by "recognize" ? [14:49] paquet not found [14:50] ah, right, wheezy is 7.0 ... afaik snapd only works in testing and unstable [14:51] and there is is the the archive [14:52] i doubt you can make it run on anything older [14:58] humm ok [14:58] thanks [14:59] have a nice day [14:59] i will dig a little [15:20] jdstrand: ping [15:24] PR snapd#2863 opened: cmd/snap-confine: ensure that hotfs is root owned [15:25] PR snapd#2858 closed: Add missing newline character to end of deprecated command warnings [15:27] niemeyer: hey [15:28] jdstrand: Heya [15:28] jdstrand: Do you have a moment to meet with pedronis and myself? [15:28] niemeyer: actually, not atm. I have an appt in a few minutes. I can do it in ~3.5 hours [15:29] That sounds late for pedronis [15:29] it's doable but slightly late [15:29] first thing tomorrow would be fine with me [15:29] Ok, let's do it tomorrow then [15:29] whichever you decide is fine with me [15:29] ok [15:30] my morning is open, so ping me at 14:00 or later when you want to meet [15:30] 14:00 UTC [15:33] 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] ahayzen: sure, you can cp the part from snapcraft.yaml you are interested in [15:34] and change source: [15:35] didrocks, ah i see thanks :-) [15:35] ahayzen: yw! easiest way to test AFAIK :) [15:42] ogra_ We discussed snapd-xdg-open the other day. [15:42] I have concerns. [15:42] tell me [15:42] We talked about it need SRU to Trusty, which "fixes" a problem for Ubuntu. [15:42] But snapd-xdg-open isn't in Debian 9, or other distros. [15:43] Meaning the cross-distro story is broken. [15:43] Particular for snaps such as Spotify and Skype for Linux Alpha. [15:44] flexiondotorg, well, talk to the snapd team, perhaps we can include it in the snapd package itself [15:44] niemeyer It that possible? ^ [15:44] ogra_ Thanks. [15:45] jdstrand Your thoughts on the above? [15:45] thats the only idea i have beyond ... well ... pushing it into the other distros as well [15:45] Would need switch action for Debian 9. [15:46] mvo Is that still a possibility at this late stage? [15:46] flexiondotorg, ogra_: We have better plans for that [15:46] flexiondotorg: I agree it would have to be part of snapd [15:46] That is reassuring. [15:46] 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] niemeyer Is there a bug to track those plans? [15:47] jdstrand: You probably have, but it wasn't super high profile [15:47] flexiondotorg: Probably, can't remember as we haven't touched that conversation in a few weeks [15:48] * jdstrand -> appt [15:48] flexiondotorg: The idea is simple: instead of using dbus, we'll use snapctl [15:48] niemeyer Thanks. [15:48] OK, I'll go hunting. If I don't turn up an existing bug I'll raise a new one. [15:49] 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] ogra_: I don't think we're even using the real xdg-open today [15:51] It just looks like it [15:51] well, the final call goes to xdg-open (at least it should) [15:51] because that knows what to do with specific urls [15:51] I don't think it does, and I don't think it necessarily should either [15:51] well, it needs to use the mimetypes to identify the right app to fire up for a certain handler [15:52] you dont want to duplicated this on our side [15:52] but i have never looked at the code of snapd-xdg-open so you ar probably right :) [15:52] Yeah, it doesn't really.. it uses g_app_info_launch_default_for_uri [15:53] ogra_: We're not duplicating code.. and we're chosing *which code* we're not duplicating. ;) [15:53] heh [15:54] s/heh/Good idea Gustavo!/ [15:54] oh, it just uses glib, i see [15:54] * ogra_ just looked at the code for the first time [15:54] Either way, this is the status quo [15:54] yeah [15:54] We most probably won't be using glib in the new implementation because we don't want more dependencies [15:55] yeah [15:55] (it will be inside snapd itself) [15:55] I'd rather not use the mess of xdg-open.. but we'll see [15:55] i'd just let xdg-open do its job and hand over the url from snapd [15:55] simply because then it isnt our job to take care after the handoff [15:56] heh, now i scared seb [15:56] We'll not implement tool-picking ourselves for sure.. but I'd prefer something cleaner if it exists [15:56] 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] any advice or best practices for passing args to a daemon that needs them? [15:59] right now we're using a single "args" config, e.g. `snap set kube-apiserver args='--etcd-servers 10.123.123.14'` [16:00] i'd use a wrapper script ... [16:00] and a wrapper script that passes them into the daemon [16:00] yeah, that sounds like an okayish approach [16:02] okay, cool :) do you think it'd be better for us to break up the config? [16:03] 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] s/arg/key/ actually [16:07] ah sorry, i mean more from an usability perspective, i guess [16:07] like instead of "args", we could have configs for "etcd-servers", "kubeconfig", etc -- all the flags that our daemon takes [16:07] yeah, i'd do that long term [16:08] and split it into categories so you can "yaml'ify" it later [16:09] okay great. Thanks ogra_! [16:09] :) [16:11] jdstrand: Comment fixed and improved: https://github.com/snapcore/snapd/pull/2604#issuecomment-280045941 [16:11] PR snapd#2604: interfaces: add classic-support interface [16:12] PR snapd#2864 opened: interfaces: API additions for interface hooks [16:13] PR snapd#2604 closed: interfaces: add classic-support interface [16:21] PR snapd#2865 opened: image,cmd/snap: refactoring and initial envvar support to use stores needing auth [16:46] Bug #1665029 opened: snapweb needs a link for device when store selected [16:46] 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. === JanC_ is now known as JanC === chihchun is now known as chihchun_afk [17:16] PR snapd#2852 closed: cmd/libsnap: add privilege elevation helpers [17:21] Hey barry, what is the recommended way to use ubuntu-image? From the snap, or from the deb? [17:26] 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] *snap [17:27] *for the deb [17:27] Ah, good to know, thanks ogra_ [17:29] jdstrand: zyga is asking for you in rocket chat. [17:29] he has "technical reasons" :) [17:35] kyrofa, ping [17:35] alex-abreu, hey there! In standup right now but I'll be available in a minute. What's up? [17:36] kyrofa, np I can wait, just a few questions around configure hooks ... the usual [17:40] kyrofa, when a snap is getting installed, the configure hook is run before any daemon that the snap could host is started? [17:43] alex-abreu, no, the configure hook is run _after_ the daemons are fired up [17:46] alex-abreu, it's why bug #1661126 was logged [17:46] Bug #1661126: Add One-shot Install/Uninstall Hook [17:52] 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] kyrofa, thx for the bug # ... [18:08] 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] alex-abreu, the method I use personally is to set the daemons up to restart always [18:10] alex-abreu, and then my scripts just kill the services in question (since systemctl is off limits) [18:10] alex-abreu, then systemd brings them back u [18:10] p [18:12] barry, ah, good to know, thank you [18:12] kyrofa, this crossed my mind but sounded too "scary", ... :) [18:12] kyrofa, do you have a snap example for that? [18:12] alex-abreu, definitely [18:13] 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] alex-abreu, but that could just as easily have been a kill -15 [18:17] PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions [18:19] kyrofa, totally, thx [18:24] 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] kyrofa, definitely ... is there a bug # for that? or a strong not to be able to ? [18:25] 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] By the way, jdstrand did you see my responses to https://github.com/snapcore/snapd/pull/2837 ? [18:27] PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs [18:31] alex-abreu, to answer your question, I don't know of a bug for that [18:40] PR snapd#2859 closed: [WIP] overlord: switching to explicit targets for enabled/auto aliases [18:40] PR snapd#2860 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets [18:42] PR snapcraft#1141 opened: Use the existing code to find origin's snapcraft.yaml [18:44] 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] kyrofa, I haven't tried lately, I recall it was just a memory usage issue [18:45] pmcgowan, yeah I wouldn't be surprised [18:46] kyrofa, did you run from stable or other channel [18:47] pmcgowan, stable, yeah. I think some efficiency gains landed in nextcloud v11 [18:48] ok will give it a try === jdstrand_ is now known as jdstrand [18:49] pmcgowan, no rush, I just have the dragon up now so I can experiment if you run into issues [18:53] kyrofa: re https://github.com/snapcore/snapd/pull/2837, but haven't had a chance to circle back yet. hopefully today [18:53] PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs [18:53] 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] jdstrand, of course, no problem [18:57] hmm kyrofa interesting you cannot refresh a disabled snap [18:57] pmcgowan, ah, I never tried. But that kinda makes sense... it's disabled [18:57] mariogrip: what is the link? [18:57] kinda, but thats cause it doesnt run correctly [18:57] pmcgowan, hahaha [18:57] pmcgowan, good point [18:58] jdstrand: https://myapps.developer.ubuntu.com/dev/click-apps/6986/ [18:58] kyrofa, so I would remove and install instead [18:58] pmcgowan, or enable and refresh [18:58] yeah, but then it sucks up my memory and my other snaps dont work :) [18:59] Yeah, remove/install might be a better path [18:59] pmcgowan, that might explain why it's working alright here-- I don't have any other snaps installed [18:59] 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] kyrofa, reminds me of a recent thread on not having snaps start right after install [18:59] jdstrand: It might be because i uploaded a new one before the review was done [19:00] jdstrand: but could you reject rev2 so it uses 3rev insted [19:02] jdstrand: manual review requested [19:04] nessita: fyi, https://myapps.developer.ubuntu.com/dev/click-apps/6986/rev/2/ seems stuck in 'Task state is unknown.' [19:04] nessita: mariogrip requested that it be rejected so rev3 may be auto-reviewed [19:04] jdstrand, hi, let me check [19:05] jdstrand, can you reload? [19:05] I see it failed [19:05] jdstrand: it says "Manual review pending" for me [19:06] nessita: ok, it isn't stuck. it took quite a while to get there. sorry for the noise [19:06] :-) [19:06] mariogrip: ok, rev2 rejected [19:06] jdstrand: Thanks :) [19:22] PR snapd#2867 opened: screen-inhibit-control: add methods for delaying screensavers [19:25] 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] systemctl isn't designed to isolate calls to applications that is [19:26] 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] jdstrand, thx for the update, ... makes sense yes, something like a systemctl facility or expanding systctl could be very handy [19:27] snapsctl I mean [19:27] jdstrand, agreed, we've tried to isolate snapd and snapd from knowing they're running on systemd anyway [19:27] snapd and snaps* [19:27] * jdstrand nods [19:27] So snapctl seems the best solution [19:28] yeah [19:28] jdstrand, from a technical standpoint though, can apparmor not parse cli args to a binary? [19:45] any ideas what I'm hitting with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102 ? [19:45] Bug #1665102: Snap refresh not working [19:59] wasn't there a bug report about being required to sign in to install a snap? [20:13] 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] I think that only .debs will be listed there? Am I wrong? [20:15] isn't ubuntu software centre deprecated? gnome software seems to find sanps [20:15] EEight: what's your snap called? [20:15] 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] nacc, I assume that's what EEight means [20:15] kyrofa: i always have to double-check in #ubuntu :) [20:16] nacc, fair enough! [20:16] nacc: bayam [20:16] EEight: is it french? [20:16] should be in Games / Kids [20:17] bilangual [20:17] my gnome software found a bayam snap [20:17] (on 16.10) [20:17]