[01:04] store is not working right now. Web https://myapps.developer.ubuntu.com, "snap install" and "ubuntu-image" cannot work. [02:26] it's back now. === chihchun_afk is now known as chihchun [07:50] bonjello [07:59] PR snapcraft#902 opened: Snap revision prune [08:01] good morning [08:27] good morning [09:20] what is a desktop app for snappy [09:20] snapplets? [09:20] snapple [09:20] ok thanks [09:29] Bug #1641150 changed: snap hooks are not run with environment similar to apps: PATH, LD_LIBRARY_PATH [09:38] crazyoldworld: what do you mean? [09:44] zyga, if I had to guess I would say he's asking how to call an application distributed as a .snap [09:44] which is a "snap" I guess [11:34] PR snapd#2271 opened: snap: add support for classic confinement [12:21] mwhudson: :( still looping here on todays build [12:27] I'm having trouble installing and running a system service in Classic mode on a Ubuntu Core. I've changed /usr/sbin/policy-rc.d to allow the service to start by returning 104. But invoke-rc.d complains the service file doesn't exist. I checked, and it does exist in /lib/systemd/system. Any idea why I'm having problems? [12:36] Bug #1641590 opened: snap --help outline text === ben_r_ is now known as ben_r [13:11] PR snapcraft#896 closed: indicators: work with Content-Encoding set [13:23] PR snapcraft#903 opened: store: download without login [13:35] dholbach: hey, do you remember that project that helped desktop snaps to run? [13:35] dholbach: stuff like setting up gdk and themes? [13:38] zyga: you mean https://github.com/ubuntu/snapcraft-desktop-helpers ? [13:38] didrocks davidcalle is there anything to do with LP: #1618021 [13:38] ? [13:38] Bug #1618021: tour: cannot re-install hello-world-service without devmode [13:39] ssweeny: yes, thank you! [13:39] np [13:39] zyga, yes, that's the one :) [13:40] sergiusens: I guess davidcalle needs to reupdate the text to include --dangerous now [13:40] didrocks: sergiusens: looking, but sounds likely, yes [14:50] ok so I really must be missing something obvious about organize/filesets [14:51] context is that there are a number of files in the release tarball that I'm snapping that are not installed by the python plugin [14:51] https://github.com/openstack-snaps/snap-glance [14:52] I basically need to push etc/*.conf|ini|json etc/glance/ [15:05] jamespage until I get the scriptlets for parts in place you will need to grab the source twice and use `dump` in one of them [15:05] `organize` and `filesets` apply to the installed assets not the sources. [15:05] sergiusens, ok glad I had not missed something [15:06] ogranize is like a dpkg-divert but both assets being valid [15:06] err, I mean, the diverted asset being valid [15:07] jamespage we have this same problem here https://github.com/snapcore/snapcraft/blob/master/demos/gopaste/snapcraft.yaml [15:07] hello everyone! [15:09] I have a question: my snapcraft maven plugin runs "mvn package" and pick up for the snap always the target/${app-name}.jar. Instead I want to wrap in the final snap a different jar executable [15:10] that is created in the root directory [15:13] sergiusens: any clue on the maven plugin? ^ (I never looked at it, only know about some hardcoded target paths). IIRC, you wanted some real world user experience [15:19] Bug #1641631 opened: Raspberry Pi images do not support boot from USB [15:25] sergiusens, ok I see got that working now [15:25] https://github.com/openstack-snaps/snap-glance/blob/master/snapcraft.yaml [15:26] sergiusens, one more question if I may - is there a nice easy way to extract something from the upstream release tarball/source to set as the version number? [15:26] pbr is quite good at generating versions based on tags [15:26] and I think that gets baked into the release and snapshot tarballs [15:31] roadmr (cc, nessita): fyi, https://myapps.developer.ubuntu.com/dev/click-apps/5779/rev/373/ gives a 504 when clicking 'approve'. going back to the page seems to indicate it worked (ie, it is approved) [15:31] roadmr (cc nessita): all of those should be approved, but there are only 4 left so I don't want to remove any more test cases [15:32] jdstrand, checking [15:32] roadmr: (for some wider context, see the plugs/slots thread I responded to today) [15:32] * roadmr bumps into nessita while checking :D [15:32] roadmr, I leave it to you, this sounds related to the approved interfaces/ [15:32] ? [15:32] jdstrand: btw, I see it has a nice payload; I'll deploy the stuff to auto-approve based on that this week [15:33] nessita: does it? do we have an oops? [15:33] roadmr: ah great! :) [15:33] roadmr, well, the package that is failing is the one with specific interfaces efined [15:33] (is the first one I see) [15:33] nessita: the payload passing shouldn't cause a timeout, I'd suspect it's more related to number of published packages. But let's see [15:34] roadmr, there are oopses for the soft timeout [15:34] nessita: my reference to plugs/slots was not meant to indicate a problem there (/me has no insight on that) only that things are going to manual review cause plugs/slots being given to review tools hasn't landed yet [15:38] nessita: check the query count, https://oops.canonical.com/oops/?oopsid=OOPS-4c9cb191528bbc05f12c48a2abcaa764 we're running some queries over 300 times, this number matches the # of uploaded lxc snaps, so I suspect just some n+1 issue. Doesn't look related to the approved interfaces payload as IIRC we never iterate over all uploads for that [15:39] yeah [15:41] jamespage you can do it the other way around, $SNAPCRAFT_PROJECT_VERSION can be used in your `source` entry [15:42] sergiusens, oh neat [15:42] sergiusens, are there any conventions around use of numbers/codenames etc? [15:44] for versions? not really, mostly up to you [15:44] great [15:46] roadmr, any verdict? [15:47] nessita: there are 3 queries we run once for each upload of the snap, I need to track down where those come from and see if I can optimize them... [15:48] roadmr, reindexing that package does not work either [15:49] roadmr, so something broke regarding prefetching tables [15:49] nessita: oh was that already using prefetching? [15:49] roadmr, yes, "a lot" :-) [17:39] installing snap with --force-dangerous on a new system but complaining that --force-dangerous is an unknown flag now [17:40] try --dangerous [17:40] cwayne, tried that too, same result [17:42] i tired without either and no errors like I had before without that flat, maybe an update has relaxed something in the security model for use of that flag? [17:45] --dangerous is set by default if your snap also uses --devmode IIRC [17:48] yup, it does use devmode [17:48] i guess the added --dangerous was in an update since i had to use both before [17:48] not sure why it doesn't recognize the flag at all anymore though [17:49] yeah, that was a bit of a mess, but fixed for the image release two weeks ago [17:50] jdstrand: hello, the --plugs/--slots thing is now enabled in production in the store. Let me know if you have any questions about how it works or you find any bugs or problems [17:50] jdstrand: (it's controlled via a waffle flag so it's easy to disable if it gives trouble) [17:50] roadmr: oh, that was quick. thanks! :) [17:51] jdstrand: haha yes :) we were just pending a deployment, I tested everything late last week [18:22] PR snapd#2246 closed: debian: add version 2.17 to changelog [18:34] roadmr: will you handle the lxd approvals or shall I (I don't want to remove the 504 test cases) [18:40] PR snapd#2272 opened: debian: add 2.17.1 to changelog [19:06] PR snapcraft#866 closed: Login with option to agree to terms of service and human friendly errors [19:13] davmor2: :( [19:13] mwhudson: see the email I sent out seems to only be on configured networks [19:14] davmor2: ugh looks like i didn't upload the fix to the ppa :) [19:14] s/:)/:(/ [19:15] mwhudson: that's not gonna help then ;) So look again tomorrow then right? [19:16] davmor2: yea [19:16] davmor2: well, assuming my fix is right :) [19:38] hey #snappies! Do I understand correctly that anybody can now upload snappy packages without any kind of approval? [19:40] sea-gull_: anyone can upload a snap, but not all snaps can be uploaded by anyone [19:44] Hi all [19:45] jdstrand: I think the reason for the 504s is clear, I guess it's ok if you handle those approvals [19:45] sorry I am a noob can somebody please tell me what I have to enter to login to the ubuntu snappy store and install webdm [19:46] roadmr: ok, thanks [19:49] mcphail: so who or how it's determined what can the given man upload? [19:49] exit [19:49] for instance, I use latest git, and I would like to have it as a snap [19:49] what should I do to get or make it? [19:58] sea-gull_ I wrote this on using snapcraft to get stuff onto the store if you want to check out http://blog.sergiusens.org/posts/Making-your-snaps-available-to-the-store-using-snapcraft/ [20:01] sergiusens: thanks, looks useful [20:04] sea-gull_ for more polished documentation, snapcraft.io is your go-to site ;-) [20:08] yep, I've skimmed through it already === chihchun is now known as chihchun_afk [20:31] bladernr`: heyo [20:31] ahoneybun, howdy [20:31] let me open up the email on the desktop here and take a look [20:32] Oh sure... no rush, by the way, it's a pet project. [20:33] it was for me as well [20:34] bladernr`: this is my current yaml file for it: http://pastebin.ubuntu.com/23477247/ [20:34] I've recently restarted my effort to make it [20:36] so desktop/gtk3 or anything is deprecated [20:36] how do I write it? [20:36] without the " / ? [20:36] PR snapd#2267 closed: debian: add 2.17.1 to changelog [20:36] PR snapd#2272 closed: debian: add 2.17.1 to changelog [20:38] I just changed the desktop/qt5 to desktop/gtk3 === King_InuYasha is now known as Son_Goku [21:16] Son_Goku: ping [21:17] zyga: Son_Goku: If we get snapd and snap-confine in to the CentOS repo you were planning on, what versions of CentOS would that be available on? [21:17] CentOS 7 only [21:17] ok, is there any possibility of getting it in 6.6? [21:45] ahoneybun, so I've tried both by just staging the package from Ubuntu and your way, by pulling/compiling from source and both times I end up now with this [21:45] http://pastebin.ubuntu.com/23477531/ [21:46] problem seems to be that the launcher (pithos) is still looking in /share, not $SNAP/share [21:47] the configure.in file in the source has config options to specify the datadir and rootdatadir, so I wonder if there's a way to pass config options to snapcraft to force it to look in /snap/pithos/current/ [21:47] I don't understand how snapcraft prepends $SNAP in the environment though... [21:48] but I don't have time to work on it anymore today, maybe later tonight or tomorrow or later this week. [21:51] mhall119, if it didn't require systemd, sure [21:53] what does CentOS 6 use, sysv or upstart? [21:59] mhall119: upstart surely? [22:07] was working through a --force-dangerous or --dangerous issue earlier today, I removed it and the snap can install...the first time only [22:07] every time after that the flag is required but rejected on the first install of a snap [22:07] is there better syntax than that to install a newer version? [22:08] PR snapd#2273 opened: interfaces: add avahi-observe (LP: #1639967) [22:10] SuperJonotron: can you paste the entire terminal output of you doing the install? [22:11] SuperJonotron: also, what version of snapd package do you have, and what distro are you on? [22:11] mhall119: I doubt that but let's get it into fedora first [22:11] popey, 2.14.2~16.04+ppa215-1 [22:12] mhall119: checking one thing [22:13] mhall119: I cannot say now, in any case it's a thing beyond the horizon today [22:14] SuperJonotron: what version of ubuntu you on? [22:14] popeye, command "sudo snap install snap*.snap --devmode", error: error: cannot find signatures with metadata for snap "snapname.snap", adding the flag --force-dangerous works [22:14] but will fail if it's the first installation of the snap [22:14] popey, 16.04 [22:15] right, I'd expect you to have to add --dangerous (or --force-dangerous in older versions of snapd) [22:15] 2.16 is the current version of snapd, so you probably need to "sudo apt dist-upgrade" your machine [22:25] popey, thanks, i might just right into an installer script to try both to handle older versions [22:46] Bug #1641752 opened: request for snap interface that expose userspace device APIs [23:40] jdstrand: hey, thanks for the fix for libappindicator... [23:43] jdstrand: as for the setprocess policy, I've there's the process-control plug, but it has to be manually enabled... I guess UI will be there for handling such cases in the future... However, I was wondering wether it would be the case to make setpriorty to be allowed for snaps that want to control the child process with higher nice values... [23:44] for example there are some tools for doing video rendering that reduce the priority of the child process (typically mencoder or ffmpeg)... That is a policy that I don't think would need any particular privilege. [23:52] Bug #1641758 opened: Allow to call setpriority on child processes when priority is lower than default [23:58] Trevinho: yes, that will be coming soon (setpriority with nice values of greater than 0) [23:59] Trevinho: hmm, but only on the current process. if for children, you are going to need process-control I think [23:59] jdstrand: cool, I've opened a bug... I didn't find anything about that, so... [23:59] jdstrand: mhmh, I see, but.. Why isn't that safe? [23:59] if it's all inside snap... [23:59] it would be safe