[00:07] PR snapcraft#968 opened: sources: refactor subversion source into module [00:13] PR snapcraft#969 opened: sources: refactor tar source into module [00:16] PR snapcraft#970 opened: sources: refactor zip source into module [00:34] PR snapd#2274 closed: interfaces: use sysd.{Disable,Stop} instead of sysd.DisableNow() [00:58] PR snapd#2345 closed: many: tweak devmode and jailmode capitalisation [01:27] pedronis: thanks [01:58] PR snapcraft#962 closed: sources: refactor bazaar source into module === JanC is now known as Guest9817 === JanC_ is now known as JanC [03:25] PR snapcraft#963 closed: sources: refactor deb source into module [04:57] Is this the best place to ask a snappy playpen question? [05:01] PR snapcraft#971 opened: Fix integration tests in armhf [06:55] PR snapd#2472 closed: tests: update custom core snap with the freshly build snap-confine [07:06] PR snapd#2459 closed: interfaces/builtin: add iio interface [07:07] PR snapd#2452 closed: interfaces/builtin: fix pulseaudio apparmor rules [07:27] PR snapd#2474 opened: Revert "interfaces: add new boot-config interface" === shuduo-afk is now known as shuduo [07:52] hey hey === chihchun_afk is now known as chihchun [08:27] sliff [08:57] PR snapd#2468 closed: tests: add debug output to see why autopkgtests are failing === pbek_ is now known as pbek === hikiko is now known as hikiko|off [09:55] PR snapd#2475 opened: tests: nested image testing [10:17] Bug #1649837 opened: Can remove required-snaps [10:18] PR snapd#2450 closed: interfaces: support network namespaces via 'ip netns' in network-control (LP: #1624675) [10:20] Bug #1649839 opened: unknown snap and snapd version when image created via ubuntu-image [10:23] Bug #1649840 opened: unknown keys in model assertion are silently ignored [10:37] PR snapd#2438 closed: release: 2.18.1 === chihchun is now known as chihchun_afk [10:52] PR snapd#2476 opened: overlord/snapstate: fixing the placement/grouping of some functions [11:11] PR snapcraft#961 closed: sources: refactor local source into module === chihchun_afk is now known as chihchun [11:42] Bug #1488887 changed: porting documentation needs adjustment for new uboot.env setup [11:45] Bug #1595581 changed: Snappy meta guide issues [11:48] Bug #1611639 changed: docs/package-names.md is out of sync with the rest of the project [11:51] Bug #1637093 changed: docs/config.md needs an update [12:03] PR snapd#2476 closed: overlord/snapstate: fixing the placement/grouping of some functions [12:18] ogra_ ping [12:18] ondra, yo [12:19] ogra_ hey, are we hosting uboot somewhere or we are using https://github.com/hallor/u-boot directly with our patch on top? [12:19] ondra, nope ... [12:19] ogra_ ha, nope to which part? :P [12:20] ogra_ say I want to compile u-boot for pi3 myself, where do I get code? [12:20] ondra, from upstream and then you add the patch from the gadget tree [12:20] ogra_ and upstream is where? [12:20] i just noticed we are missing said patch for the dragonboard in our tree [12:21] ondra, denx.de [12:21] upstream uboot [12:21] for dragonboard we indeed used the above tree (since it has never been submitted upstream) [12:21] http://paste.ubuntu.com/23628425/ is the patch [12:22] the pi's and beaglebone just use the upstream tree [12:23] ogra_ cool [12:23] ogra_ yeah I have here dragonboard, and was not sure if we use same tree there or not [12:23] ogra_ so http://git.denx.de/ + patch from gadget for pi3 it is [12:24] we might be a commit behind or so on the db ... (the binary worked and we had no bugs so it wasnt further updated) [12:24] ondra, yeah [12:25] ogra_ thank you mister :) [12:25] np :) === jamiebennett changed the topic of #snappy to: Package any app for any Linux desktop, server, cloud or device. Read how on http://www.snapcraft.io | File a bug: https://bugs.launchpad.net/snappy/+filebug, join the snapcraft discussion https://rocket.ubuntu.com/channel/snapcraft [13:41] ogra_, I think https://bugs.launchpad.net/snappy/+bug/1620559 is fix released; can you confirm? [13:41] Bug #1620559: /etc/resolv.conf is empty on snappy

=== chihchun is now known as chihchun_afk [13:53] PR snapcraft#972 opened: Add a checklist in the pull request template [14:15] jdstrand: ping [14:18] PR snapd#2477 opened: interfaces/builtin/repowerd: First cut at repowerd interface [14:23] PR snapcraft#964 closed: sources: refactor git source into module [14:23] niemeyer: hi! [14:27] niemeyer: if you are asking about James' feedback, I incorporated GetConnectionCredentials and responded to the other comments [14:27] niemeyer: (James' comments in https://github.com/snapcore/snapd/pull/1613 that is) [14:27] PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) [14:34] question on ubuntu core: is there a way to run "lsusb" in bash? -bash: lsusb: command not found [14:38] jdstrand: Hey [14:38] jdstrand: Yeah, James feedback [14:38] jdstrand: What do you think of making "path" explicit? [14:38] jdstrand: Any reason not to? [14:40] niemeyer: I'd prefer not to keep adding to this. it has been lingering for so long. I mean, I can, but there is so much more that is needed for supporting complex services [14:41] niemeyer: he as asking for multiple paths and interfaces pur well-known name as well. we don't even have session services yet [14:41] pur? [14:42] per* [14:42] niemeyer: not sure if you read my response [14:42] (in the PR to James) [14:48] Chipaca, bug updated ... [14:49] (thanks for the pointer) [14:49] ogra_, incompletely fix released \o/ [14:49] :-) [14:49] haha [14:49] Bug #1620559 changed: /etc/resolv.conf is empty on snappy

[14:53] hello folks, is there a version of snapd that works on trusty? even if it's from a PPA, that would fit my needs [14:54] tvoss, ^^^^ [14:57] jdstrand: I didn't.. will get back in this after lunch [15:00] roadmr: yup, let me hand you instructions [15:00] tvoss: great, thanks! (yes, perfectly happy to read up existing material) [15:03] Issue snapd#2478 opened: Just testing [15:04] niemeyer: ok, note I have an appt in 45 minutes for a couple of hours and then will be back [15:22] ogra_: how are you testing your BBB image? [15:22] elfgoh, i install it on an SD, install htop to test snap interfaces and install the classic snap to test the classic functionallity usually [15:23] I see. So you test on an actual device? [15:23] yes [15:23] If I wanna do it as a vm or something, instead of a physical device is it possible? [15:24] not sure, does qemu support booting a plain img file ? [15:24] iirc you need to have kernel and initrd separate for qemu system mode [15:24] which would break [15:25] (snappy kind of relies on the partitioning and certain files in certain places ... and it needs to interact with the bootloader) [15:25] I see [15:25] if you can use qemu for BBB arches like kvm that would work, but only then [15:26] (i.e. just point to the img file and have that boot) [15:27] So if I use KVM, it will work? Even though the host OS will not be arm? [15:27] i dont think so ... kvm cant boot arm images afaik [15:27] (though perhaps i'm not up to date) [15:29] i meant above is "if you can use qemu *like* kvm" ... which meant just pointing to the img ... but i dont think thats possible) [15:31] ogra_, I think you are probably right [15:31] ogra_, then in the development of snaps for BBB, i am guessing it is best to build it on the BBB itself, instead of on say a linux vm running amd64? [15:32] you can use a qemu-user-static chroot or an lxd container i suppose ... [15:33] i.e. not a full BBB emulation ... but only the armhf userspace [15:34] note that wont work for everything (i.e. i dont think you can compile mono apps) but for most [15:40] PR snapd#2479 opened: many: implement snap unalias using snapstate.Unalias [15:46] jdstrand: Read your response.. I'm concerned with ignoring jamesh's feedback on it [15:47] @jdstrand Yes, we want to unblock people to use that interface, and yes it's fine to implement the solution partially and evolve it over time.. but jamesh's feedback points out precisely that there may be cases for those very applications that are not being correctly handled, and I don't see the path forward yet [15:47] niemeyer: No such command! [15:49] jdstrand: He points out that the same interface may be published under several different well known names, and he also points out that GetProperty is in a separate interface.. we didn't discuss any of those cases yet [15:50] GetProperty is a pretty concerning problem, for example, because it lives in its own separate interface.. how can we confine it properly? [16:01] PR snapd#2480 opened: many: prepare landing on trusty [16:02] Bug #1649934 opened: USB Auto-mount for assertion import fails [16:02] PR snapd#2481 opened: osutil: fix unit tests to pass on OS X [16:06] Issue snapd#2478 closed: Just testing [16:19] PR snapd#2481 closed: osutil: fix unit tests to pass on OS X [16:23] PR snapcraft#965 closed: sources: refactor mercurial source into module [16:31] PR snapd#2482 opened: store: retry auth-related requests [16:41] PR snapd#2483 opened: store: use mocked retry strategy to make store tests faster [16:49] Issue snapd#2484 opened: Support removing all unused revisions [16:53] Bug #1555217 changed: snappy leaks loop devices [18:17] PR snapcraft#973 opened: Check the license agreement on Travis [18:17] PR snapcraft#974 opened: Updated maven plugin to use get_build_properties() [18:17] PR snapcraft#975 opened: Updated the gradle.py plugin to use the get_build_properties() method instead of modifying the schema [18:38] niemeyer: did you see my response for Properties.Get()? it is covered for GNOME and KDE apps which this iteration is trying to unblock [18:38] elopio, hmpf, not sure what you wanted to fool me with in rocket ... but it showed me that i cant log in at all anymore to rocket.ubuntu.com [18:38] : [18:38] :( [18:38] niemeyer: also, GNOME and KDE apps don't do the different interfaces, they use consistent interfaces that work with this PR [18:40] niemeyer: he is wanting a super-general interface that can work with any service. that isn't this PR. this PR is GNOME and KDE leaf-style applications [C[C[C[C[C[C[C[C[C [18:41] niemeyer: there is going to need to be considerable investigation, thought and design to try to support services generally. some services will work with just this, and that's fine, but we don't even support session services or dbus policy, etc, etc so blocking this PR to support services that won't work anyway seems odd [18:42] s/dbus policy/dbus bus policy generally/ [18:42] PR snapd#2479 closed: many: implement snap unalias using snapstate.Unalias [18:45] jdstrand: My concern is not even understanding what James is talking about.. I hear you saying we don't need to support everything, but when I see James saying we won't support the very thing he's working on, I get concerned we don't even understand which tradeoffs we're making [18:45] niemeyer: I'm concerned about scope creep for this PR. This will allow GNOME and KDE leaf-style applications to be able to be in stable. it is intended to also have them integrate into the desktop session and to have different leaf-style applications to talk to each other via snap connections. that's it. it lays the groundwork for services in general, but doesn't attempt to implement that yet [18:46] niemeyer: he is not trying to snap a GNOME application [18:46] niemeyer: he is trying to write a dbus session service [18:46] niemeyer: we don't support that in at least two other ways beyond this PR [18:47] this PR works for Properties.Get() for leaf-style applications. He did not notice the rule I mentioned covered his concern [18:47] I don't get that distinction.. gnome applications are just software like any other.. they can use dbus as they see fit [18:48] niemeyer: in addition, he is not blocked on this. he can write an interface for storage service just like everyone else has for bluez, network-manager, locationd, etc [18:48] niemeyer: gnome and kde applications use toolkit libraries that use dbus in a very specific way [18:48] niemeyer: eg, GApplication [18:49] this is why no GNOME application works today. GApplication binds to the well-known name [18:49] Do you know what James means when he talks about multiple well known names? [18:49] the toolkit takes that well-known name and actually creates dbus paths and interfaces very regularly [18:49] precisely in the way that this PR addresses [18:49] niemeyer: he was saying several things [18:50] I'm asking about one specific thing [18:51] niemeyer: 1. a single well-known name, eg, org.foo might have interfaces for org.foo and org.bar. 2. a single well-known name like org.foo might use different paths, like /org/foo and /org/bar and 3. a single service might bind to multiple well-known names [18:51] niemeyer: this PR handles '3' [18:51] '1' and '2' it does not. and we specifically decided before that it should not in *this* iteration [18:52] a future iteration would consider these other use cases and we would design for that [18:52] this PR is written in a manner that we can build upon for the future use cases [18:53] How do we handle 1 in the future? That'd what James was talking about [18:53] add 'interface' attribute [18:54] When referring to multiple well known names [18:54] and '2' is add 'path' attribute [18:54] Doesnt work.. interface is something else [18:54] ok, 'dbus-interface' [18:54] What is name then? [18:54] interface is an overloaded term [18:54] I thought that was interface [18:55] it means one thing in dbus and another in snappy [18:55] Yes, we're talking about dbus [18:56] What is the name attribute referring to? I thought it was the dbus interface name? [18:56] PR snapcraft#966 closed: sources: refactor rpm source into module [18:56] niemeyer: in dbus, you have a well-known name for a service (org.foo). that service may offer any number of dbus interfaces (eg, org.fo.bar, org.foo.baz, org.norf) and then dbus also has a path [18:56] niemeyer: the 'name' attribute is the well-known dbus connection name [18:56] org.gnome.Logs [18:56] org.gnome.Rhythmbox [18:57] GNOME and KDE toolkits are very regular with how the well-known name corresponds to dbus interface and dbus paths [18:58] which is why this PR does what it is doing now [18:58] what we are doing now would be the defaults we would always offer I imagine, and then additional attributes for 'dbus-interface' or 'dbus-path' would add additional security policy [18:58] So do we support any interface on the well known name? [19:00] we did discuss this before, but, look at https://github.com/snapcore/snapd/pull/1613/files#diff-715ebbcbcd440b44a1e536f154ca6138R149 [19:00] PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) [19:01] we allow a connected snap to introspect our dbus api [19:01] we allow a connected snap to use any dbus interface and any dbus path if they are connecting to the well-known name [19:02] if they are using a non-well-known name, we allow connecting to any dbus path if the dbus interface is regular according to our well-known name [19:02] Okay, that sounds reasonable [19:02] Thanks for the long explanation [19:02] if they are using a non-well-known name, we allow connecting with any dbus interface if the dbus path is regular accoriding to our well-known name [19:03] Happy to go forward with it [19:03] \o/ [19:03] Is the PR blocked on anything else at this point? [19:04] niemeyer: no. tyhicks reviewed the security policy. pedronis reviewed the code. I incorporated all applicable feedback from everywhere [19:04] So let's get it in [19:04] thanks! [19:04] Thank you! [19:06] niemeyer: so with that, I plan to work with the personal folks on designing their interfaces (eg, storage framework) and will be reviewing tvoss' work for session services and will be thinking about how all of this relates to this interface, improvements we can make to this interface, etc and when I have coherent thoughts on it, will present phase ii, phase iii, etc, etc iterations to you [19:13] morphis__: looking at your homeassitant reply, it's not really necessary to have the snapcraft.yaml in the root [19:13] https://github.com/blockstack/blockstack-core/pull/264/files#diff-a4a8be59175f107f2ba1ce86da0c8286R28 [19:13] PR blockstack/blockstack-core#264: Add the packaging metadata to build the blockstack-core snap [19:14] it looks better, that's true. And sometimes using the relative path might cause a mess. But it should work. [19:15] niemeyer: ok, I reviewed the testsuite issues-- all are unrelated to this PR (I left a comment). I also captured the tail end of the above IRC discussion in a comment so people understand what is allowed by the policy [19:17] niemeyer: since your previous 'requested changes' is still in effect, I'll leave this to you to pres the merge button? [19:17] press* [19:19] elopio: interesting [19:20] PR snapd#2485 opened: overlord: apply auto-aliases information from the snap-declaration on install or refresh [19:38] * ahoneybun slides some money to someone who can snap this: https://github.com/wereturtle/ghostwriter [19:41] ahoneybun, did you run into problems with it? [19:41] kyrofa: tbh I've not even tried [19:42] I've only gotten 1 snap to work [19:44] well half work as it needed flash for some content [20:04] my network problems are gone, lesson learned: KEEP AWAY FROM NETGEAR [20:05] kissiel, yikes, was it compromised? [20:06] not that bad; 9/10 snap commands timed out [20:06] reason being bad DNS via ipv6 handling [20:06] and causing a mess/timeouts [20:09] kissiel, if it makes you feel better, I think my asus is dying on me, too [20:10] kyrofa: which one is it, cause from today on I got two :D [20:10] kissiel, RT-N66U, but it's pretty old nowadays [20:10] kissiel, and it might also be my modem. Or ISP :P [20:11] Tough to debug problems like that [20:11] kyrofa: oh man; oh yeah [20:12] kyrofa: my wget -4 apps.ubuntu.com took 0.2s, while without `-4` it took 15s+ [20:31] jdstrand: if a snap uses the removable-media interface, where will the snap environment see that media? [20:38] mhall119: /media on classic. an all snaps system with udisks2 snap installed, /run/media [20:39] jdstrand: thanks, does it only make it visible when you try to access it? [20:41] mhall119: I'm not sure I understand the question. lsdir on / is blocked and /media is blocked without removable-media, so snaps can't see anything in there until snap connect. there is nothing special about the interface other than allowing access to the directory [20:42] jdstrand: I snap-connected krita to removable-media, but the open dialog didn't show /media/ until I entered it manually, and then it wouldn't show /media/mhall/ until I undered that manually too, etc [20:42] trying to determine if this is a snapd thing, or a krita thing [20:44] mhall119: you will definitely have to enter /media/. tab complete and things won't work and you can't navigate from say /home/mhall, /home, /, /media, cause all those directories are not readable [20:44] mhall119: let me check the exact rule for under /media [20:45] mhall119: right, cause mounts are done in /media//, you have to also enter /media/mhall/. after that you can tab complete and go to /media/mhall/subdir/subdir/... via the file dialog [20:46] these are the rules: [20:46] # Mount points could be in /run/media//* or /media//* [20:46] /{,run/}media/*/ r, [20:46] /{,run/}media/*/** rw, [20:46] that's kind of hard to discover, is there any way we can make this better? [20:48] mhall119: the security policy is correct. snaps shouldn't be able to lsdir() all over the place. it can be improved, but it should be at the toolkit level. eg, the file dialog should not be run in-process, it should be out-of-process, like with content-hub [20:48] mhall119: that way the application doesn' [20:49] t have to care about snappy. the user drives the interaction, and the out of process trusted helper mediates the access [20:49] there is a bug on this and that is what was outlined [20:49] jdstrand: ideally yes, and that's likely to come in the future, but doesn't help yet [20:49] strangly, the open dialog can see /home and /snap when I point it to / [20:50] that is indeed strage [20:53] I mean, we *could* allow '/home/ r, / r, /media/ r,'. that would allow enumerating users. It wouldn't be the worst thing, especially on classic [20:54] there is a problematic directory though: ~/snap/. I was expressly asked to not allow lsdir access to it cause that would allow snaps to enumerate installed apps [20:54] and because HOME is set to /home/user/snap/$SNAP/$REVISION/, apps start down there. there is a bug on that too [20:55] (so, /home/user/snap/$SNAP/$REVISION is fine, /home/user/snap/$SNAP is fine, /home/user/snap is not, /home/user is fine with 'home', then get to /home, etc [20:56] ) [21:05] PR snapcraft#976 opened: demos: do not force arch for the tomcat demo [21:10] Hello. I'm trying to use Ubuntu Core for the first time on a Raspberry Pi 3. First boot it needs config, so I setup the Wifi but it will not connect. It times out. I tried 3 different wifi networks available to me (one of which is less than 4 meters away). Any thoughts? [21:10] ogra_, ^^ if you're still around [21:11] knight__, you need to do the initial setup wired ... later you can ssh into the board and re run "sudo console-conf" to disable wired and enable wireless [21:12] (there is a bug with the pi33 driver on first boot setup, but it works fine later) [21:12] **pi3 === datajerk is now known as datajerk_ [21:19] ogra_ why hasn't the bug been fixed? Is it a hardware issue? Or is there a problem with the kernel? [21:20] its a driver issue, fix is in the works but not there [21:20] gotcha, ok thanks. Is there a way to preconfigure Ubuntu Core? I'm very Ubuntu familiar, but this is first time I'm using core. [21:20] For example, let's say I am building a custom firmware. [21:23] there is a way through loading an assertion file from USB on first boot, but i dont know exacctly how or where thats documented, sorry === datajerk_ is now known as datajerk [21:38] ogra_ but isn't the purpose of Ubuntu Core to be the basis of custom IoT firmwares? [21:38] yes [21:38]