[01:05] hola! how to install snapd on centos-7 ? [01:06] elopio do we have a bug for register [01:07] numa, you don't yet [01:08] zyga didn't enable EL7 in his Copr: https://copr.fedorainfracloud.org/coprs/zyga/snapcore/ [01:08] Son_Goku: womp womp... thanks :) [01:09] sergiusens: we have one for upload without register. That's what I was trying to say in the standup. I'll file a new one. [01:36] elopio to late, but feel free to make it bug sru friendly [01:56] im having an issue running the snapcraft tour. I installed the hello snap i created but the "hello" command is not available. I get command not found in zsh and in bash it suggests I install hello or hello-traditional [01:56] im running xenial [02:00] ddellav: hello. What if you run /snap/bin/hello ? [02:00] elopio i get: failed to create user data directory. errmsg: Permission denied [02:00] should i use sudo? [02:02] ddellav: no, you shouldn't. Maybe, your user directory is not in /home ? [02:02] elopio pwd = /home/david/snapcraft-tour/00-SNAPCRAFT/01-easy-start [02:03] ddellav: so, maybe your home is encrypted ? [02:04] elopio hmm, i may have selected that when I first installed months ago but right now it's in use so it's not currently encrypted or doesn't that matter [02:05] ddellav: I'm asking those questions because those are the two bugs open that print your error. The encrypted home is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1592696 [02:05] Launchpad bug 1592696 in ubuntu-core-launcher (Ubuntu) "snaps dont work with encrypted home: failed to create user data directory. errmsg: Permission denied" [Undecided,Fix released] [02:06] Hmm. I have ecryptfs home. [02:06] ddellav: can you check your /var/log/syslog to confirm that? [02:07] elopio yes i see in the bug report there's a workaround for apparmor [02:07] and this is in my syslog: Jun 21 22:00:22 loki kernel: [ 1626.709398] audit: type=1400 audit(1466560822.050:49): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/.ecryptfs/david/.Private/" pid=17745 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000 [02:07] ddellav: the bug says fix released, so maybe first try to upgrade before applying the workaround [02:07] elopio i actually just installed snap and snapcraft less than an hour ago [02:07] so perhaps it's not published yet [02:08] or maybe i need to modify my repos [02:08] ddellav: the bug is not in snapd, it's in ubuntu-core-launcher. So there's still a chance that you have an old one. Or it hasn't been published. Or the bug is still open :) [02:09] elopio gotcha, well thanks for the direction, at least i know im not crazy now :) [02:11] ddellav: np. Welcome to the snappy world. Please let us know if you have any other problems. [02:11] will do [02:12] ddellav: If you're feeling brave, you can work around it pretty easily and not wait for the release that fixes it for everyone. [02:12] qengho yea, im messing with the apparmor stuff now heh [02:12] i might just disable it entirely if this doesn't work [02:17] ddellav: In /etc/apparmor.d/usr.bin.ubuntu-core-launcher, near "@{HOME}/snap/{,*/,*/*/} rw,", add a new line "/home/.ecryptfs/david/.Private rw," and then "apparmor_parser -r /etc/..." to reload it. [02:17] It's not the Right Way, but it will get you to a place you can play. [02:22] qengho for some reason that didn't work but i just copied and pasted the apparmor changes from the bug report and that seemed to do it [02:22] and now i get: Hello, world! [02:22] woot [02:29] now I have to figure out why it wont run when i just to use the command [02:29] i guess somewhere along the line my path wasn't updated or something [02:34] Hrm. I have a snap with a service that has been installed many times. Runs well. Just installed on new 2.0.9 armhf machine. There is no systemd "service" for it. $ systemctl |grep tor-middle-relay.*service #shows nothing on new machine [02:36] elopio: you said you would look at my PR again? [02:36] ddellav: On snapd install, log-in profile is updated, so no visible until next shell init. Try "bash -l". [02:36] qengho yea, no dice :( [02:37] ddellav: Try ". /etc/profile" [02:37] i dont see any modifications to .profile or .bashrc so maybe it failed because of the apparmor problem [02:37] ddellav: it would never touch personal files. :) [02:38] qengho . /etc/profile works but it puts me into a prompt with only a $ [02:39] ddellav: What shell do you use? $ echo $SHELL [02:39] qengho zsh [02:39] ddellav: you alien! [02:40] lol [02:40] i tried it with bash too and it didn't work. When i did bash -l it still didn't include the path [02:41] this is obviously a config issue on my side. I must not be including the system wide config somehow [02:41] ddellav: $ grep PATH= ~/.??* [02:42] ah ha [02:42] that was it [02:42] the .zshrc was not including the existing $PATH [02:43] eh, now i've got a bunch of duplicated directories in my $PATH [02:43] * ddellav sighs [02:44] ok, i did away with setting the path in zsh altogether [02:44] thanks qengho for getting me squared away [02:44] Welcome! [02:57] (Incidentally, I found my problem is same as LP: #1584456) [02:57] Launchpad bug 1584456 in Snappy "apparmor denial using ptmx char device" [Undecided,Confirmed] https://launchpad.net/bugs/1584456 [02:57] i may be asking this too quickly, im still going through the tour and learning but it looks like snaps have built-in plugs for things like make, node, python, etc. Is there any way to add plugins? For something like composer perhaps? [02:58] ddellav: A plugin is only for building things. And you can add your own, yes, in parts/plugins/x-ddellavsomething.py [02:59] qengho yes, i want to try to build a snap package for a project i run which is currently using composer so it would be awesome to package that together as a composer install is an annoying process [02:59] requiring a curl bang [02:59] I don't know "composer". [02:59] it's npm for php [02:59] tld? [03:00] tla. Ugh. [03:00] sorry, node package manager [03:00] composer is a package manager for php apps [03:00] similar to pip as well. instead of requirements.txt you have a composer.json [03:01] ddellav: okay. Sure. Beware that it might not make sense, unless it's installing packages inside its $SNAP_DATA dir. Snap programs can't write just anywhere. [03:02] qengho i think it will work as intended but we shall see [03:02] :) [03:02] eventually I want to try to get snaps working for openstack packages as well [03:02] though that will be a much larger job lol === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:33] zyga: FYI snap-confine 1.0.33-1 has been uploaded to the Debian NEW queue now (will at some point show up at https://ftp-master.debian.org/new.html); Vcs-Git moved to git://anonscm.debian.org/collab-maint/snap-confine.git [07:05] slangasek: \o/ thank you [07:05] slangasek: did you do the dpkg-vendor thing you mentioned? [07:05] mvo: ^^ FYI [07:08] zyga: in what way are we using a different configuration? just curious [07:09] i have a .snap file, any know how to install it? [07:11] hamiltino: sudo snap install ./path/to/that/snap [07:11] mvo: debian doesn't have all the confinement bits enabled [07:12] mvo: but snap-confine unlike snapd does a compile-time decision [07:12] mvo: slangasek propsed using dpkg-vendor to configure snap-confine differently on ubuntu [07:13] i get: cannot read snap file: cannot open snap: unknown header: "!\ndebian-binar [07:13] hamiltino: that's a snap from 15.04 [07:13] hamiltino: that snap won't run on 16.04 system, you have to rebuild it [07:15] dholbach: good morning [07:20] can a 16.04 snap work on a 15.04 system? [07:20] hamiltino: no [07:21] hamiltino: you would have to rebuild it from source [07:21] hamiltino: the format changed significantly [07:30] hey zyga [08:33] mvo: could you take a minute to test my Mutt snap please? [08:44] tsimonq2: I get http://paste.ubuntu.com/17686195/ at the end - i woder if a fakeroot somewhere is missing [08:46] tsimonq2: i.e. I think "chmod 2755 /tmp/mutt/parts/mutt/install/bin/mutt_dotlock" needs to be run via fakeroot, maybe its fine to run the entire build with fakeroot even [08:48] mvo: what's fakeroot? :) [08:50] tsimonq2: its a clever program that makes build systems believe they are running as root :) [08:51] tsimonq2: "apt show fakeroot" has some more info [08:51] tsimonq2: ha! fakeroot snapcraft makes it work [08:52] tsimonq2: and it works, how neat! [08:53] tsimonq2: hm, almost [08:55] 03:51:24 AM < mvo> tsimonq2: ha! fakeroot snapcraft makes it work [08:55] 03:52:15 AM < mvo> tsimonq2: and it works, how neat! [08:55] 03:53:47 AM < mvo> tsimonq2: hm, almost [08:55] whoops [08:55] * tsimonq2 kicks his terminal [08:56] tsimonq2: it does work [08:56] tsimonq2: it is just a bit confused because ubuntu-core-launcher changes HOME [08:56] Qterminal has this nice "Paste selection" function that is really awesome, except in IRC :P [08:56] anyways [08:57] tsimonq2: so yeah, run `fakeroot snapcraft` and its there :) [08:57] tyhicks`, jdstrand: https://bugs.launchpad.net/ubuntu-core-launcher/+bug/1595092 [08:57] Launchpad bug 1595092 in Snappy Launcher "rpmlint complains about POS36-C" [Critical,New] [08:58] mvo: so I should leave a note that snapping it should be done with fakeroot? [09:00] I think you need to change the build system to have it running under fakeroot [09:00] or you will never be able to get it build under builders [09:00] for instance [09:01] so, I think it's something about have "make" replaced with "fakeroot make" and adding a build-packages: [fakeroot] [09:04] didrocks: so I might just write a custom plugin that just takes the autotools plugin and puts fakeroot in front of make and make install, that might work [09:04] right? [09:06] tsimonq2: yeah, if you can inherit from the autotools plugin, and even, maybe patch is to make is more generic so that your custom plugin is just a 3 or so lines… :) [09:07] :) [09:11] tsimonq2: yeah === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [10:18] didrocks, hi! [10:18] didrocks, I saw your e-mail on the snapcraft ML quoting https://lists.ubuntu.com/archives/snapcraft/2016-June/000235.html [10:18] didrocks, so the Ubuntu store will support devmode-snaps? [10:19] ePierre: yes [10:20] indeed [10:20] zyga, didrocks but isn't devmode... well, for developers/testers only? :D [10:20] be aware about the restriction on the stable channel [10:20] and people will have some warnings if installing devmode snaps from another channel [10:21] this will help you to distribute to testers :) [10:21] didrocks, ok I see! Thanks [10:21] yw ;) === cpaelzer is now known as cpaelzer_lunch === hikiko is now known as hikiko|ln [10:49] didrocks, should I be able to write to $SNAP_DATA if I run bash in my launcher script instead of the actual application binary? [10:51] e.g. qt5-launch bash [10:51] $ touch $SNAP_DATA/hello [10:52] willcooke: pretty sure SNAP_DATA is only writable by root [10:52] joc_, that ties in with what I'm seeing, thanks [10:54] yep, only root can write to it === cpaelzer_lunch is now known as cpaelzer [10:58] willcooke, you want $SNAP_USER_DATA [10:59] got it [10:59] also use /bin/sh ... there is no guarantee that bash will stay in the core snap [10:59] ack [11:01] zyga: it was a CDN issue! === iahmad_ is now known as iahmad === hikiko|ln is now known as hikiko [11:46] hi [11:46] hey [11:46] any update on https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860 ? [11:46] Launchpad bug 1570860 in snapd (Ubuntu) "Love2D needs udev access" [Medium,Triaged] [11:47] To make some test I can try to edit snapd interface rules ? [11:49] https://github.com/snapcore/snapd/tree/master/interfaces/builtin in here ? [11:54] * zyga looks [11:54] gouchi: you can help, for sure :) [11:55] what is the actual device that is being accessed? [11:55] is that a GPU or some other thing? === ara is now known as Guest21851 [11:59] zyga: same as /run/udev/data/cXX so related to gamepad and joystick [12:00] zyga: I'm pretty sure that was an active decision (setgroups). I'll let tyhicks` comment cause I think he and sarnold reviewed that code [12:01] qengho: you mentioned bug #1584456 as your problem. Can you sync with tyhicks` when he comes online (he was looking at that) [12:01] bug 1584456 in Snappy "apparmor denial using ptmx char device" [Undecided,Confirmed] https://launchpad.net/bugs/1584456 [12:01] hmm, wasnt the /dev/shm fix in snapd 2.0.9 ? [12:02] * ogra_ still sees it with the package from proposed [12:02] what fix are you referring to? [12:02] jdstrand: thanks [12:02] jdstrand, chromium based apps need it [12:02] jdstrand: please keep this in the bug report there, it will be referenced by other packaging systems [12:03] i thought there was a fix in the works for it [12:03] ogra_: not for chrome [12:03] to treat it like /tmp [12:03] not for chrome [12:03] hmm, k [12:03] there was a fix that allows snaps to have access to stuff in /run/shm [12:03] olli__, pinging again for putting back the bug links into the topic :) [12:04] but chrome needs to modify its path to do that [12:04] right, but i only have a binary for the app [12:04] or someone needs to write the preload library that is in the bug [12:04] olli__: hence the 'not for chrome' :) [12:04] and by default all chromium wrapped apps use /dev/shm/.XXXXX [12:05] I've talked to upstream. there is a bug on this. there is a plan if upstream doesn't change. I don't think anyone is assigned to that bug [12:05] jdstrand, well, the app is based on chromium, not chrome ... [12:05] same difference [12:05] (i dont have the source for the wrapper bit thoough) [12:05] ok [12:06] there appears to not be consensus if snapcraft should own that library or snapd. so no one is working on it. iirc, zyga has some poc code [12:06] * jdstrand is just reporting the issue and is not working on that [12:06] yeah [12:06] mvo: hi, are you in charge of snapd 2.0.10 release? I ask cause I think it is very important that mpris interface is in 2.0.10 [12:09] jdstrand: I can wait for this to land [12:09] jdstrand: 2.0.9 is not in updates yet, I am chasing this right now [12:11] zyga: do you have a moment to talk about your mpris comment? [12:13] pindonga (cc noise][1): hey, can you sync r680 to the store for home autoapprove? (fyi niemeyer1) [12:14] morphis, nessita: hey-- I see a bunch of bluez packages in the store. 4 from 20 days ago and 2 from 5 months ago. nessita since you are up on this issue, would you mind handling the store review? [12:15] jdstrand, the bluez package was moved from a private store to the public store, maybe that's why is showing now? [12:17] nessita: that's my guess, but I'd rather not guess in the review and let someone close to the issue have a look :) [12:18] nessita: unless you tell me its fine, then I'll just push approve [12:19] jdstrand, let me check [12:22] jdstrand, nessita: the ones from 20 days ago should be the current ones [12:22] jdstrand, nessita: but maybe we should drop those and let me redo the upload process to get everything into a sane state [12:22] jdstrand: yes [12:23] jdstrand: let's talk about mpris [12:23] morphis, I was going to ask, the failures i was seeing from the review process do not seem harmless [12:23] jdstrand: we can also talk about the shm thing next [12:23] jdstrand: I'd like someone to own that thing [12:24] morphis, if you confirm [12:24] reserved interface 'bluez' for vetted applications only security-snap-v2_plug_safe (client, bluez) [12:24] attente_: hey, where are the patches required for gnome-software to install snaps? [12:24] morphis, is OK I can approve those [12:24] nessita: that's fine. it came from Canonical [12:24] nessita: let me have a quick look [12:25] zyga: I left a comment in the mpris PR for you [12:25] jdstrand, right, so your doubt was mainly about those appearing now (all the sudden) [12:25] nessita: yes [12:26] jdstrand, nessita: https://myapps.developer.ubuntu.com/dev/click-apps/3595/rev/9/ should be the latest one [12:27] zyga: it's on this branch at git.gnome.org: https://git.gnome.org/browse/gnome-software?h=wip/ubuntu-xenial [12:28] nessita: just one quick thing, can I migrate a snap in the store to another channel? [12:28] attente_: is that heading upstream? [12:29] morphis, yes, just click the "Edit" link next to the channels line in a revision details page [12:29] nessita: ok, done [12:30] morphis, so we should approve revision 9 and reject 3 to 8? [12:30] nessita: for bluez, yes [12:30] on it [12:30] jdstrand: if you could have a look at https://github.com/snapcore/snap-confine/pull/43 that would be great! part of the new content-sharing work [12:31] mvo: my plan was to move to content sharing after mpris. mpris is almost done. does that work for you? iirc, both of these are for 2.0.10/// [12:31] nessita: and for network-manager it is https://myapps.developer.ubuntu.com/dev/click-apps/3592/rev/10/ [12:32] mvo: oh, actually, I think tyhicks` may want to look at that particular PR. iirc, he had some thoughts on parsing mountpoints [12:32] jdstrand: we've used his idea (glibc parser) [12:33] jdstrand: FYI: https://bugzilla.opensuse.org/show_bug.cgi?id=986050 [12:33] bugzilla.opensuse.org bug 986050 in Audits "AUDIT-0: snappy: snap-confine setuid root" [Normal,New] [12:33] jdstrand: that bug is about auditing snap-confine so that it can be setuid root [12:33] * jdstrand nods [12:34] zyga: did you see my comment in the mpris PR? [12:34] jdstrand: no, let me refresh [12:34] zyga: also, the continuous integration test is failing for something unrelated to the PR AFAICS [12:34] morphis, this is the final mapping https://myapps.developer.ubuntu.com/dev/click-apps/3595/configurations/ [12:35] zyga: i don't think robert proposed it yet, but i assume it'll apply upstream [12:35] attente_: is robert going to work on that? [12:35] jdstrand, so bluez is no handled. For network-manager, I'm unsure about approving https://myapps.developer.ubuntu.com/dev/click-apps/3592/rev/10/ [12:35] a couple of unknown interfaces there [12:36] jdstrand: ok, let's talk about mpris now; my reasoning was that since unity provides one of the mpris elements (the controller) it would gain an implicit slot so that players could auto-connect to it (on classic) [12:37] nessita: i can do the nm review. there might be a tooling issue [12:37] jdstrand: the actual sides are somewhat arbitrary IMHO (unless I'm missing something) and it could be either a plug or a slot equally well [12:37] jdstrand: for the slot it would be easier to support since the code in snap/implicit.go only adds implicit slots today [12:37] nessita: now I see what I did, we have to publish rev 5-8 for bluez too, those are the other architectures [12:37] jdstrand: but if you feel strongly about it I could extend it to handle implicit plugs as well [12:38] zyga: my mental map is that a slot provides something for things to use. flipping it in this manner is confusing to me. also, I allow, on classic, for unconfined to control the player [12:38] I think it sounds weird to connect to a remote [12:38] I think a remote connects to a player [12:39] morphis, ok, let me see if I can approve the one I already rejected ;-) [12:39] jdstrand: you assume people know what mpris is :) [12:39] jdstrand: for me it is the thing in the top-right corner, in the sound menu [12:39] nessita: :-) [12:39] I read the spec-- I picked the sides that seemed to best work with it [12:39] jdstrand: while I simplify, I doubt many people know what that stands for and which side is which [12:39] jdstrand: but users will be used to connecting plugs to slots on the classic core snap [12:40] jdstrand: again, this is all a "feeling" observation, I'm fine with it being a plug too, it just needs more work [12:40] zyga: note that vlc doesn't show up in indicator sound at this time. also note, that people don't have to do anything on classic for it to work. on classic, I add rules that let's unconfined connect [12:40] actually, I may need to adjust where I do that now that we are talking about it [12:40] jdstrand: hmm [12:41] jdstrand: I think it should still be a connection, let me check what you wrote there again [12:41] morphis, does this look OK? https://myapps.developer.ubuntu.com/dev/click-apps/3595/configurations/ [12:41] jdstrand: (so that when you disconnect it shouldn't be possible to control) [12:42] zyga: I think this is the main point-- how to let unconfined control the player [12:42] nessita: checking [12:42] zyga: in my mind, unconfined should be able to control it without a connection (it is unconfined) [12:42] jdstrand: hmmm [12:42] jdstrand: I think this is not intuitive though perhaps this is just my pov [12:42] zyga: this is not about giving vlc something, it is about giving something else access to vlc [12:43] jdstrand: it would be more interesting if we had two snaps here [12:43] jdstrand: (controller and player) [12:43] the player side just screams slot to me [12:43] zyga: I implemented that locally [12:43] mpris-client is a controller [12:43] jdstrand: so dbus-wise, the player is a dbus service that stuff talks to [12:43] zyga: yes [12:43] like bluez [12:44] like location-service [12:44] jdstrand: still, with this I would expect to have control over which controller can actually talk to my player [12:44] therefore, it seemed naturally a slot [12:44] zyga: you do :) [12:44] jdstrand: but perhaps this is a gray area [12:44] jdstrand: (including unconifned unity) [12:44] snap connect mpris-client:mpris vls:mpris [12:44] that is the point [12:44] jdstrand: but I cannot disconnect the classic one [12:44] nessita: hm, rev 8, 7, 6, 5 should be published for all channels [12:45] if we want to put unconfined into that limitation [12:45] I would argue we do not [12:45] on classic we let snaps talk to unconfined. no reason we can't let unconfined talk to snaps on classic [12:46] jdstrand: why cannot that be explicit rather than implicit? [12:46] it could be. I just don't think that is particularly useful [12:46] jdstrand: btw, can a single player be sensibly controlled by many controllers? [12:47] zyga: I don't see why not. It is just hitting dbus API [12:47] play/pause [12:47] ff [12:47] rew [12:47] it is simple [12:47] jdstrand: ok [12:47] jdstrand: so we don't need a plug on the core snap [12:48] zyga: I'll put this another way. let me move the classic code to a permanent plug for now, with comment saying we may revisit this in the future? [12:48] jdstrand: as there's no connection really [12:48] we do on the core snap [12:48] we need a controller snap [12:48] hmm [12:48] * zyga is tired, sorry let me re-read the code [12:48] jdstrand: if there's a plug we have to patch snapd to create the plug [12:48] jdstrand: currently it only creates slots [12:49] zyga: note that as written, the unconfined OnClassic bit is in the wrong place. I am describing here that it should be in permanent plug conditionally OnClassic [12:49] zyga: on core, this operates exactly like bluez [12:49] zyga: if a player that slots mpris is not installed, nothing to connect to [12:51] zyga: it just happens that it operates very similarly on classic. there is no implicit slot. a remote must control a player. the only difference is that what I'm proposing is that on classic we allow unconfined to control the player snap unconditionally [12:51] zyga: as implemented, we do not handle a snap that is a remote to control an unconfined player. that could be a future improvement [12:52] morphis, you can edit that yourself [12:52] jdstrand: ah, ok [12:52] nessita: without republishing? let me check .. [12:52] * zyga reads the diff carefully [12:54] morphis, when you change the channels the update propagates automatically to the index [12:54] nessita: I see, thanks [12:54] np [12:55] meh, I said I need to move mprisConnectedSlotAppArmorClassic to connected plug earlier here. I meant conditionally add it to mprisPermanentSlotAppArmor [12:55] nessita: did you approve network-manager too? [12:55] zyga: ^ [12:55] morphis, jamie is with that one [12:56] nessita: aye! [12:56] o/ [12:56] morphis: there are a number of weird errors with nm. not sure if that is a review tools bug or something else. [12:57] nessita: if we assume that those are review tools bugs, nm would be ok to approve? (ie, you've confirmed this is just a normal review and not something to treat special?) [12:57] * zyga goes to a meeting [12:57] jdstrand: let's continue this soon [12:57] zyga: let me move mprisConnectedSlotAppArmorClassic while you are in the meeting [12:58] OK [12:58] Thank you [12:58] then you can see what I actually mean [12:58] jdstrand, hum, no, I haven't confirmed anything other than I moved the existing nm from a private store to the ubuntu store [12:58] jdstrand: what exactly? [12:58] jdstrand, let me run the review tools again, with the latest version [12:59] nessita: that is the bit I'm talking about. that move is all correct, right? === olli__ is now known as olli [12:59] nessita: ah, if you run the review tools again, it might look better [12:59] yeah, let me try [13:00] jdstrand, just ran it for revision 10, using [13:00] 678 click-reviewers-tools version [13:00] the same 3 failures [13:00] jdstrand, the move from one store to the other is as correct as I can possibly make it :-) [13:01] nessita: all I need answered is that the move worked right and it is in the right spot [13:01] ok, cool [13:01] then I'll look at that in a moment === kyrofa_ is now known as kyrofa [13:02] jdstrand, the move worked right and is in the right spot. Thank you! [13:09] morphis: ok, this is what you have: [13:09] apps: [13:09] networkmanager: [13:10] slots: [13:10] - service [13:10] slots: [13:10] service: network-manager [13:10] morphis: (and you do something similar for plugs) [13:10] jhodapp: yeah, whats wrong with that? [13:10] morphis: based on the specification, that should be: [13:10] slots: [13:11] service: [13:11] interface: network-manager [13:11] unless the code has evolved beyond the spec [13:11] jdstrand: service: network-manager is the short form of this which snapcraft allows you [13:12] why do we have so many short forms... [13:12] morphis: I'm curious why you chose this format over: [13:12] apps: [13:12] networkmanager: [13:12] slots: [ network-manager ] [13:12] and skip the toplevel slots and plugs [13:13] because that would then not give the user any hint of what he connects [13:13] with this he knows he connects "service" to "nmcli" [13:15] zyga: can you confirm that the top-level plugs and slots declaration here is valid: http://paste.ubuntu.com/17695654/ [13:15] morphis: the other bit is: lib64/ld-linux-x86-64.so.2, usr/lib/systemd/system/network-online.target.wants/NetworkManager-wait-online.service lint-snap-v2_external_symlinks [13:16] morphis: those are going to dangle and may indicate a problem with the snap [13:16] zyga: nm, I see it now in the spec [13:17] morphis: I'll fix the tools for that abbreviated format [13:18] almost done with the meeting [13:26] zyga: ok, refresh and you can more easily see what I'm talking about [13:34] jdstrand: I have a MP for that one to fix, can we upload with or should I push the fix first? === iahmad_ is now known as iahmad [13:41] morphis: if it is in progress, I'll just approve for now and you can fix in your next upload [13:42] morphis: can you request a manual review? [13:42] kyrofa the ros test fails consistently now :-/ [13:42] sergiusens, what the heck... [13:43] elopio, have you managed to make any progress in downloading that stuff? [13:43] kyrofa I say consistently in a 2 out of 2 test, I am not lying but my population is too small for it to be meaningful ;-) [13:44] sergiusens, hahaha [13:44] kyrofa is this the error you see http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/1153/testReport/junit/demos_tests.test_ros/ROSTestCase/test_ros/ [13:44] kyrofa that comes out of this btw https://github.com/ubuntu-core/snapcraft/pull/574 which cannot be related :-P [13:45] sergiusens, yeah that's it [13:45] ROS, you sadden me [13:46] sergiusens, I'll investigate as soon as elopio is able to pull stuff off of it. Tests pass locally, manual tests pass on the jenkins machines... something must be going on in the test infrastructure somewhere [13:46] kyrofa I bet we just run out of RAM [13:46] jdstrand: will do [13:46] sergiusens, that's an interesting theory. What makes you say that? [13:47] sergiusens, it doesn't look like an enomem, it looks like a garbled file [13:47] kyrofa it only happens sometimes, it is either RAM or load; running out of files to create is another one; not sure how performant these machines are. But I've seen many random errors happen when RAM gets low [13:48] kyrofa you know how people do those malloc checks, right? ;-) [13:48] sergiusens, heh, fair point [13:48] sergiusens, admittedly the only time I did was for ubuntu core launcher :P [13:55] jdstrand: requested for rev 8, 9 and 10 [13:58] davidcalle, mhall119, popey: I started work on https://github.com/ubuntu/snappy-playpen/wiki/Examples - what do you generally think? more detail? better overview of chapters? (I'll add much more content to it...) [14:00] nessita: fyi, I approved the nm snaps, but there was a server error for each of r8, r9 and r10. Eg, for r8: OOPS ID: OOPS-26f562e1911f49328a44c89c8924d65c [14:01] Sentry ID: 9c66fdb409bf4131985225e707017749 [14:01]