[01:28] PR snapd#1486 closed: interfaces: add wireless-control === mup_ is now known as mup [03:21] has anyone successfully done a ubuntu phone snap app? I am having a little problem in creating a qmake snap app for 16.04. my code is at https://github.com/liu-xiao-guo/snaptest thanks [03:48] when I am trying to snap a qmake application, I get the error like http://paste.ubuntu.com/19046504/. My source code is at https://github.com/liu-xiao-guo/rssreader_snap. what could be the problem for it? thanks === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [06:51] hey hey [07:05] mwhudson: hey, can I ask you to update snap-confine to 1.0.36 [07:05] mwhudson: or alternatively, review a patch that I make === chihchun is now known as chihchun_afk [07:05] * zyga needs to refresh his git-buildpackage skills === chihchun_afk is now known as chihchun [07:49] lo; does Snap require any AppArmor stuff that is not in the upstream kernel? Just wondering, because LWN.net wrote "[…] In particular, most distributions lack Ubuntu's patched version of AppArmor […]" http://lwn.net/Articles/691372/ [07:52] good morning [07:53] knurd: yes, that's accurate [07:53] knurd: we've developed many new features for apparmor and not all of them are upstream yet [07:53] knurd: the security and kernel teams at Canonical are working on upstreaming all the patches [07:54] zyga: k, thx for the clarification [08:01] zyga: sure [08:05] zyga: the ./configure arguments have changed yet again? [08:06] zyga: and it's /usr/bin/snap-confine now, not /usr/lib/snapd/snap-confine? [08:12] zyga: can you provide me a changelog too? the differences between 1.0.35 and 1.0.36 seem almost entirely trivial? [08:13] mwhudson: no, they shoulnd't have [08:14] mwhudson: sure, .36 fixed apparmor confinement, .34 and .35 were unconfined by accident [08:14] (confinement of snap-confine itself) [08:14] mwhudson: I will spend some time this week to discard debian/ from upstream repository entirely [08:14] mwhudson: so that there's no confusion [08:14] mwhudson: but I will only do that after I'm ready with spread tests for debian [08:15] zyga: maybe send me a patch for the debian directory then? [08:15] mwhudson: for the current tree on alioth? [08:15] zyga: one second [08:16] zyga: for the tree as of now (i.e. a410e5e) [08:16] * mwhudson brb [08:16] mwhudson: thanks, I'll do that today === ant_ is now known as Guest70775 [08:24] zyga: do it in an hour if you want it uploaded before my tomorrow morning :) [08:26] Bug #1600713 opened: snapd.boot-ok.service always failed after booting [08:29] zyga: Do you happen to know what the status of snappy is on the Raspberry Pi 2? [08:35] Bug #1600719 opened: The camera interface only grants access to /dev/video0 [09:11] PR snapd#1492 closed: overlord/auth: add Device/SetDevice to persist device identity in state === ant_ is now known as Guest33019 [09:18] PR snapcraft#570 closed: Add https_proxy support to maven plugin [09:33] PR snapd#1522 opened: Introduce a simple key-value store for user-specific data [09:33] mwhudson: ah, sorry, I got stuck in suse bits, it's not urgent, it can wait till tomorrow [09:34] nhaines: hey [09:35] nhaines: all all-snap devices are still in progress, we're adding things required to make them work reliably, they will only be relased when it is sensible to do so (e.g. you can update reliably) - you can run snappy on those devices earlier (now) but this is not the final version [09:36] hello [09:37] I've written my first snap and I was wondering what's the next steps until I upload it to playpen.. is there any tutorial somewhere? (thanks) [09:38] hikiko: hi, are you familiar with Git? [09:38] well a little bit tsimonq2 [09:38] I know the basics: checkout, push, commit... [09:39] hikiko: let me walk you through it here [09:39] hikiko: git clone https://github.com/ubuntu/snappy-playpen.git [09:39] thanks tsimonq2 :) [09:40] hikiko: no problem :) [09:40] hikiko: after that: cd snappy-playpen === dholbach_ is now known as dholbach [09:41] hikiko: then: cp -rsnap-template/ YOUR-SNAP-NAME/ [09:41] whoops [09:41] hikiko: then: cp -r snap-template/ YOUR-SNAP-NAME/ [09:42] hikiko: then customize the snapcraft.yaml file and the README.md to your liking [09:43] hikiko: after that, open the README.md in the main snappy-playpen directory [09:43] hikiko: where you see the other snaps, copy/paste an entry and customize it to fit your snap [09:44] hikiko: when you are done with all of that, do: git add YOUR-SNAP-NAME/ README.md [09:44] zyga: yes, but if I run snappy on those devices, I can't run any current snaps, and anything I learn about setting up, administering, and developing for those systems will be completely obsolete. [09:44] hikiko: then: git commit -am "Added (SNAP NAME) snap" [09:45] hikiko: I'll pause and wait for you to catch up :) [09:45] So since we were promised all-snap systems in May, and now it's halfway through July, I'm curious if there are any newer estimates on that. [09:45] tsimonq2, I am reading you :) [09:45] hikiko: now it gets a little complicated [09:46] hikiko: then, go to the following URL: https://github.com/ubuntu/snappy-playpen [09:46] nhaines: you can run all current snaps [09:46] nhaines: only device specific things can still change (e.g. how the kernel and gadget snaps are defined) [09:46] hikiko: sign into your GitHub account, then click the fork button at the top [09:47] zyga: I can run (for instance) the NextCloud snap on a Raspberry Pi 2 running snappy Ubuntu 15.04? [09:47] nhaines: no, only with the not-yet-released snappy 16.04 [09:47] tsimonq2, I have a personal github account should I create another one using canonical's email? [09:47] zyga: yes so that's what I'm saying. [09:48] or it's fine to use the personal? [09:48] hikiko: wait, do you have an @canonical.com email address? [09:48] yes tsimonq2 [09:48] hikiko: you can add that email to GitHub if you wish [09:49] hikiko: or you can create another account [09:49] zyga: we went from "It'll probably be 6 weeks because we want this to be reliable" to... now it's 10 weeks with no updates. And I'm okay with that--I want stable, too. But I have an RPi2 sitting here doing nothing. :) [09:49] hikiko: your choice :) [09:49] nhaines: there are updates every day but you know how things are with scheduling [09:49] ok! [09:50] hikiko: go to https://github.com/settings/emails and add an email address, then you should be all set with that email address! "_ [09:50] *:) [09:50] zyga: I don't mean "no updates" as in "nobody's working on it." I'm certain everyone is. I mean "no updates" as in "things are obviously taking longer but no one's talking about it on the mailing list anymore." :) [09:50] ah [09:50] I agree on that [09:51] At least you can install a classic 16.04 system to an RPi2 and run snaps that way, which is not a bad consequence of how awesome it is that snapd made it into Ubuntu 16.04 classic, which did I mention is super awesome? :) [09:51] done tsimonq2 :) [09:52] And frankly, way more useful to me in general. But I still want to do RPi2 stuffs. :) [09:52] hikiko: when you have created the fork, run the following: git remote add fork https://github.com/YOUR_USERNAME/snappy-playpen [09:52] hikiko: then git push fork master [09:53] hikiko: after that, go to https://github.com/ubuntu/snappy-playpen and you should then be able to create a pull request [09:53] hikiko: after you create the pull request, someone will comment [09:54] hikiko: you then work with them until you get it merged [09:55] hikiko: then there you go! :) [09:55] thanks *a lot* tsimonq2 :) I am going to follow the steps! [09:55] great hikiko, I follow the PRs, I hope to see yours soon :) [09:56] * tsimonq2 creates PR to fix the lack of documentation explaining this :P [11:28] Hello! I'm using the telegram snap and it's mildly annoying having to copy the images I want to send to a buddy into the sandbox [11:28] is there a way to change the scope of the sandbox? === chihchun is now known as chihchun_afk === hikiko is now known as hikiko|ln [11:42] brunch875: no, that's something the snap author would have to do, in addition we know about this restriction but integrting a better solution is still some time away [11:43] aww [11:56] PR snapd#1340 closed: many: introduce a tool to sign assertions === hikiko|ln is now known as hikiko [13:36] PR snapd#1489 closed: snap: ensure unknown arguments to `snap run` are ignored [13:43] PR snapcraft#643 closed: Release debian/changelog for 2.12.1 [13:49] sergiusens, OK. let me check my email. thanks === chihchun_afk is now known as chihchun [13:55] PR snapd#1523 opened: asserts: fix minor doc comment typo [14:01] sergiusens, I think the question I asked is different from one I asked in the mailinglist. I have made it working and I used the one in your blog by using the desktop_launch. My final working one is at https://github.com/liu-xiao-guo/snaptest_working/blob/master/snapcraft.yaml. The not working one is at https://github.com/liu-xiao-guo/snaptest/blob/master/snapcraft.yaml. It gave me the error http://paste.ubuntu.com/19078940/. I do not know whether this is a [14:01] bug or not. thanks [14:04] sergiusens, I do not know why it gives error if I set the package name and the app name the same. I have to make them different to make it working. [14:06] liuxg so `command: desktop-launch snaptest` does not work? [14:07] sergiusens, no in fact, it does not generate the .snap file. I gives me the error like http://paste.ubuntu.com/19078940/. In the snapcraft.yaml file at https://github.com/liu-xiao-guo/snaptest/blob/master/snapcraft.yaml, I define the package name and the app name the same. I have to change the app name to make it compile for me. [14:09] sergiusens, this snapcraft.yaml at https://github.com/liu-xiao-guo/snaptest_working/blob/master/snapcraft.yaml gives me the correct .snap file, and it invokes the app for me [14:09] liuxg ok, log a bug so we can triage and determine if it is a bug or not (as I don't have time right now) [14:11] sergiusens, sure, thanks. so, this is the link for filing a bug https://bugs.launchpad.net/snapcraft/+filebug, right? [14:11] liuxg that is correct [14:11] sergiusens, thanks. I will do that. [14:13] PR snapd#1524 opened: classic: remove (most of) "classic" mode, this is implemented as a snap now [14:18] sergiusens, I have filed a bug at https://bugs.launchpad.net/snapcraft/+bug/1601834 thanks [14:18] Bug #1601834: Error "[Errno 21] Is a directory" when building a snap package for a qmake project [14:25] Making a new snap an having trouble with the build binaries getting added. I think I need to specify INSTALL_ROOT during the make install, but I don't see a way to specify that. What are the "Common plugin keywords"? [14:29] INSTALL_ROOT=$(DESTDIR) [14:29] ? [14:30] (at least in the make plugin) [14:32] ogra_: possibly. I was using autotools [14:33] let me look at the make plugin again [14:43] ogra_: so looking at the make plugin, how do I specify flags for 'configure' then other flags for 'make install'? [14:44] dunno, i always do it in the makefile itself [14:46] I suppose that makes sense, but now I need to patch upstream somehow [14:46] Does snapcraft have some variant of debian/patches ? [14:50] tgm4883: not at the moment, you'd likely need to create your own custom plugin [14:51] tgm4883, not within plugins i think ... (i work around that by using the make plugin and just call the patch command from the makefile usually) [14:51] https://github.com/ogra1/packageproxy is an example [14:51] sergiusens, do you know when you're going to land 2.12.1? :) [14:51] oh, it's already landed, just still in SRU [14:52] hmm, ok [14:52] dholbach, it suffers from test anxiety :) [14:53] Let me ask a different question. The DESTDIR. Does the snap application know about this directory or does it still think it's in /usr/share [14:54] well, if you use --prefix=./ it will thinnk ./share ;) [14:54] just trying to figure if it would make sense to try --prefix=${DESTDIR) === chihchun is now known as chihchun_afk [15:00] willcooke: in case you've made some changes and haven't commited them to github, I took your mythtv snap initial work and played with it this weekend. It seems to compile file, although doesn't install fine yet. [15:00] tgm4883, hey! Yeah, I got it to build and then got busy with other things. [15:01] tgm4883, I was toying with the idea of building a separate frontend and backend snap - but I know that's not really a supported thing [15:01] I think there was one build dep missing from the github repo for xinerama, other than that it seems to build [15:02] Did you get it to install properly? [15:02] tgm4883, didnt try tbh [15:02] ok [15:02] that's what I was working on ^ but it sounds like I'll need to create a plugin [15:03] As for separate backend/frontend, mythbuntu's always supported that. [15:04] Still working through the snap documentation, which I see there is a way to autostart snaps. Need to figure out if that's configurable by the user though [15:05] if so, I don't see why we wouldn't just have 1 'mythtv' snap. I don't believe the extra backend vs frontend code would be that much === chihchun_afk is now known as chihchun [15:06] oki, so if the b/e isnt set to autostart then you just have a box with both installed but only firing up the f/e? [15:06] yep [15:07] neat [15:07] ideally, we'd just ship both as different internal binaries and have the user say "snap autostart mythtv.mythbackend", not sure if that is possible [15:07] i dont think it is [15:08] until "snappy config" comes back at least [15:08] but you can work around that ... [15:08] ogra_: I need that to happen for 18.04 then :) [15:08] (you can not actually modify the systemd units, snapd generates them at install time) [15:09] what yxou can do is to have your start script that the sytzemd unit calls check for a flag on disk and fail gracefully [15:09] tgm4883: all services are auto-started [15:09] and have a script "mythtv.toggle-autostart" [15:09] which sets the flag [15:10] ogra_: ah, that might work [15:10] zyga: when you say services, are you talking about all the exposed binaries in a snap? [15:10] all services [15:10] (I might have to go back and look at the documentation as I might be forgetting stuff) [15:10] you can have either apps or services [15:12] (an app with "daemon:" property magically becomes a service) [15:12] ok that makes sense [15:13] so we'd have a mythtv.mythbackend service that checks for a file on disk (eg. /etc/mythtv/backendstart ) and if it exists, call the actual mythbackend binary [15:13] well ... $SNAP_DATA/backendstart [15:14] (/etc isnt visible to your snap) [15:14] (and if it was, it would be readonly) [15:14] ogra_: where "$SNAP_DATA" is disk space that is writable for the snap? [15:14] yeah [15:14] ok cool. I haven't gotten to that part of the documentation yet [15:14] $SNAP is readonly, $SNAP_DATA is rw for services etc ... $SNAP_USER_DATA is rw for user apps [15:15] So the flip side of this is the frontend, which is a graphical application. Could this be autostarted in the same way [15:15] tgm4883: no, all "background applications", aka apps that have a daemon field [15:16] Could it be handled the same way that non-snap applications are currently autostarted? (Via ~/.autostart or whatever) [15:16] if you would auto-start it it would run as root ... [15:17] i dont think we have actual autostart support for desktop apps yet [15:17] ok [15:17] (sounds like a good wishluist bug to file ;) ) [15:18] https://launchpad.net/snappy ? [15:19] yep (that used to be in the topic ... but our managers didnt manage to put it back when changing it ... /ma glares at olli| and jamiebennett :) ) [15:22] bug filed [15:23] Bug #1601859 opened: Need a way to autostart applications (not services) [15:26] PR snapd#1525 opened: tests: mount-observe interface spread test === chihchun is now known as chihchun_afk [15:58] elopio: sergiusens: looks like there was an unfortunate timeout during the "autopkgtest snaps" run on my PR :( [15:58] really hoped this one was going to be a good one [16:29] hi guys, I'm packaging (still) PostgreSQL and one of the problems that I'm currently facing is basically this error message when I'm trying to run initdb: [16:29] initdb: invalid locale settings; check LANG and LC_* environment variables [16:29] I tried to export LANG= in my wrapper script but that didn't help [16:30] what is LANG= in the sandbox? or is there one at all by default? [16:30] I installed this package in --devmode [16:41] joc_ as in something a retry would fix? [16:43] sergiusens: maybe, looked to have happened after the mosquitto demo was being built/tested, thing leo already kicked it off again though [16:43] s/thing/think/ [16:44] PR snapd#1523 closed: asserts: fix minor doc comment typo [16:53] joc_ ah, good [16:55] sergiusens: finished already?! [16:55] there was definitely something wrong with last run then - it was taking hours [18:34] elopio kyrofa and josepht what's up? [18:34] o/ [18:35] sergiusens: All good here. kyrofa is moving. [18:35] elopio right, thanks for the reminder [18:35] and I joined the standup early :-P just got a notification for it :-P [18:35] I assumed that :D [18:36] * sergiusens gets some coffee started in the meantime [18:45] PR snapd#1521 closed: many: removed authenticator, store gets a user instead [18:50] PR snapd#1526 opened: Interfaces: Builtin: add pluggable storage interface [19:07] hi all, i have aquestion. is ubuntu core snappy available for raspberry pi 3 ? i can't seem to find any info over it [19:26] hi, what is 'apg-get upgrade' equivalent on snappy? [19:27] both snap refresh === DanChapman is now known as DanChapman__ === DanChapman_ is now known as DanChapman [19:52] PR snapd#1527 opened: overlord/state,overlord/ifacestate: define basic infrastructure for and then setting up serialising of interface mgr tasks [19:56] sergiusens: there's no such command on my snappy. (ubuntu-core/15.04/stable; armhf) [20:47] There's no 'snap find' command on my snappy. How to get it? [22:05] zyga didn't send me a patch [22:12] maybe it's just been a couple of days and it got lost in inboxes, but could I get eyes on https://github.com/snapcore/snapcraft/pull/619 please? [22:12] PR snapcraft#619: Add source-checksum option [22:35] sergiusens: any thoughts on https://bugs.launchpad.net/snapcraft/+bug/1599709 ? [22:35] Bug #1599709: organize feature deletes destination folder, is surprising