| mup | PR snapcraft#968 opened: sources: refactor subversion source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/968> | 00:07 |
|---|---|---|
| mup | PR snapcraft#969 opened: sources: refactor tar source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/969> | 00:13 |
| mup | PR snapcraft#970 opened: sources: refactor zip source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/970> | 00:16 |
| mup | PR snapd#2274 closed: interfaces: use sysd.{Disable,Stop} instead of sysd.DisableNow() <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2274> | 00:34 |
| mup | PR snapd#2345 closed: many: tweak devmode and jailmode capitalisation <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2345> | 00:58 |
| barry | pedronis: thanks | 01:27 |
| mup | PR snapcraft#962 closed: sources: refactor bazaar source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/962> | 01:58 |
| === JanC is now known as Guest9817 | ||
| === JanC_ is now known as JanC | ||
| mup | PR snapcraft#963 closed: sources: refactor deb source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/963> | 03:25 |
| luk3yx | Is this the best place to ask a snappy playpen question? | 04:57 |
| mup | PR snapcraft#971 opened: Fix integration tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/971> | 05:01 |
| mup | PR snapd#2472 closed: tests: update custom core snap with the freshly build snap-confine <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2472> | 06:55 |
| mup | PR snapd#2459 closed: interfaces/builtin: add iio interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2459> | 07:06 |
| mup | PR snapd#2452 closed: interfaces/builtin: fix pulseaudio apparmor rules <Created by bergotorino> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2452> | 07:07 |
| mup | PR snapd#2474 opened: Revert "interfaces: add new boot-config interface" <Created by mvo5> <https://github.com/snapcore/snapd/pull/2474> | 07:27 |
| === shuduo-afk is now known as shuduo | ||
| dholbach | hey hey | 07:52 |
| === chihchun_afk is now known as chihchun | ||
| kalikiana_ | sliff | 08:27 |
| mup | PR snapd#2468 closed: tests: add debug output to see why autopkgtests are failing <Blocked> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2468> | 08:57 |
| === pbek_ is now known as pbek | ||
| === hikiko is now known as hikiko|off | ||
| mup | PR snapd#2475 opened: tests: nested image testing <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2475> | 09:55 |
| mup | Bug #1649837 opened: Can remove required-snaps <Snappy:New> <https://launchpad.net/bugs/1649837> | 10:17 |
| mup | PR snapd#2450 closed: interfaces: support network namespaces via 'ip netns' in network-control (LP: #1624675) <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2450> | 10:18 |
| mup | Bug #1649839 opened: unknown snap and snapd version when image created via ubuntu-image <Snappy:New> <https://launchpad.net/bugs/1649839> | 10:20 |
| mup | Bug #1649840 opened: unknown keys in model assertion are silently ignored <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1649840> | 10:23 |
| mup | PR snapd#2438 closed: release: 2.18.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2438> | 10:37 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2476 opened: overlord/snapstate: fixing the placement/grouping of some functions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2476> | 10:52 |
| mup | PR snapcraft#961 closed: sources: refactor local source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/961> | 11:11 |
| === chihchun_afk is now known as chihchun | ||
| mup | Bug #1488887 changed: porting documentation needs adjustment for new uboot.env setup <snap-docs> <Snappy:Invalid by ogra> <https://launchpad.net/bugs/1488887> | 11:42 |
| mup | Bug #1595581 changed: Snappy meta guide issues <snap-docs> <Ubuntu Developer Portal:Fix Released> <Snappy:Invalid> <https://launchpad.net/bugs/1595581> | 11:45 |
| mup | Bug #1611639 changed: docs/package-names.md is out of sync with the rest of the project <snap-docs> <Snappy:Invalid> <https://launchpad.net/bugs/1611639> | 11:48 |
| mup | Bug #1637093 changed: docs/config.md needs an update <snap-docs> <Snappy:Invalid> <https://launchpad.net/bugs/1637093> | 11:51 |
| mup | PR snapd#2476 closed: overlord/snapstate: fixing the placement/grouping of some functions <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2476> | 12:03 |
| ondra | ogra_ ping | 12:18 |
| ogra_ | ondra, yo | 12:18 |
| ondra | 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 |
| ogra_ | ondra, nope ... | 12:19 |
| ondra | ogra_ ha, nope to which part? :P | 12:19 |
| ondra | ogra_ say I want to compile u-boot for pi3 myself, where do I get code? | 12:20 |
| ogra_ | ondra, from upstream and then you add the patch from the gadget tree | 12:20 |
| ondra | ogra_ and upstream is where? | 12:20 |
| ogra_ | i just noticed we are missing said patch for the dragonboard in our tree | 12:20 |
| ogra_ | ondra, denx.de | 12:21 |
| ogra_ | upstream uboot | 12:21 |
| ogra_ | for dragonboard we indeed used the above tree (since it has never been submitted upstream) | 12:21 |
| ogra_ | http://paste.ubuntu.com/23628425/ is the patch | 12:21 |
| ogra_ | the pi's and beaglebone just use the upstream tree | 12:22 |
| ondra | ogra_ cool | 12:23 |
| ondra | ogra_ yeah I have here dragonboard, and was not sure if we use same tree there or not | 12:23 |
| ondra | ogra_ so http://git.denx.de/ + patch from gadget for pi3 it is | 12:23 |
| ogra_ | 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 |
| ogra_ | ondra, yeah | 12:24 |
| ondra | ogra_ thank you mister :) | 12:25 |
| ogra_ | np :) | 12:25 |
| === 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 | ||
| Chipaca | ogra_, I think https://bugs.launchpad.net/snappy/+bug/1620559 is fix released; can you confirm? | 13:41 |
| mup | Bug #1620559: /etc/resolv.conf is empty on snappy <hw-specific> <verification-done> <Snappy:New> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Released by pitti> <https://launchpad.net/bugs/1620559> | 13:41 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapcraft#972 opened: Add a checklist in the pull request template <Created by elopio> <https://github.com/snapcore/snapcraft/pull/972> | 13:53 |
| niemeyer | jdstrand: ping | 14:15 |
| mup | PR snapd#2477 opened: interfaces/builtin/repowerd: First cut at repowerd interface <Created by afrantzis> <https://github.com/snapcore/snapd/pull/2477> | 14:18 |
| mup | PR snapcraft#964 closed: sources: refactor git source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/964> | 14:23 |
| jdstrand | niemeyer: hi! | 14:23 |
| jdstrand | niemeyer: if you are asking about James' feedback, I incorporated GetConnectionCredentials and responded to the other comments | 14:27 |
| jdstrand | niemeyer: (James' comments in https://github.com/snapcore/snapd/pull/1613 that is) | 14:27 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 14:27 |
| r2geo | question on ubuntu core: is there a way to run "lsusb" in bash? -bash: lsusb: command not found | 14:34 |
| niemeyer | jdstrand: Hey | 14:38 |
| niemeyer | jdstrand: Yeah, James feedback | 14:38 |
| niemeyer | jdstrand: What do you think of making "path" explicit? | 14:38 |
| niemeyer | jdstrand: Any reason not to? | 14:38 |
| jdstrand | 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:40 |
| jdstrand | 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 |
| jdstrand | pur? | 14:41 |
| jdstrand | per* | 14:42 |
| jdstrand | niemeyer: not sure if you read my response | 14:42 |
| jdstrand | (in the PR to James) | 14:42 |
| ogra_ | Chipaca, bug updated ... | 14:48 |
| ogra_ | (thanks for the pointer) | 14:49 |
| Chipaca | ogra_, incompletely fix released \o/ | 14:49 |
| Chipaca | :-) | 14:49 |
| ogra_ | haha | 14:49 |
| mup | Bug #1620559 changed: /etc/resolv.conf is empty on snappy <hw-specific> <verification-done> <Snappy:Fix Released> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Fix Released by pitti> <https://launchpad.net/bugs/1620559> | 14:49 |
| roadmr | 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:53 |
| ogra_ | tvoss, ^^^^ | 14:54 |
| niemeyer | jdstrand: I didn't.. will get back in this after lunch | 14:57 |
| tvoss | roadmr: yup, let me hand you instructions | 15:00 |
| roadmr | tvoss: great, thanks! (yes, perfectly happy to read up existing material) | 15:00 |
| mup | Issue snapd#2478 opened: Just testing <Created by zyga> <https://github.com/snapcore/snapd/issue/2478> | 15:03 |
| jdstrand | niemeyer: ok, note I have an appt in 45 minutes for a couple of hours and then will be back | 15:04 |
| elfgoh | ogra_: how are you testing your BBB image? | 15:22 |
| ogra_ | 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:22 |
| elfgoh | I see. So you test on an actual device? | 15:23 |
| ogra_ | yes | 15:23 |
| elfgoh | If I wanna do it as a vm or something, instead of a physical device is it possible? | 15:23 |
| ogra_ | not sure, does qemu support booting a plain img file ? | 15:24 |
| ogra_ | iirc you need to have kernel and initrd separate for qemu system mode | 15:24 |
| ogra_ | which would break | 15:24 |
| ogra_ | (snappy kind of relies on the partitioning and certain files in certain places ... and it needs to interact with the bootloader) | 15:25 |
| elfgoh | I see | 15:25 |
| ogra_ | if you can use qemu for BBB arches like kvm that would work, but only then | 15:25 |
| ogra_ | (i.e. just point to the img file and have that boot) | 15:26 |
| elfgoh | So if I use KVM, it will work? Even though the host OS will not be arm? | 15:27 |
| ogra_ | i dont think so ... kvm cant boot arm images afaik | 15:27 |
| ogra_ | (though perhaps i'm not up to date) | 15:27 |
| ogra_ | 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:29 |
| elfgoh | ogra_, I think you are probably right | 15:31 |
| elfgoh | 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:31 |
| ogra_ | you can use a qemu-user-static chroot or an lxd container i suppose ... | 15:32 |
| ogra_ | i.e. not a full BBB emulation ... but only the armhf userspace | 15:33 |
| ogra_ | note that wont work for everything (i.e. i dont think you can compile mono apps) but for most | 15:34 |
| mup | PR snapd#2479 opened: many: implement snap unalias using snapstate.Unalias <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2479> | 15:40 |
| niemeyer | jdstrand: Read your response.. I'm concerned with ignoring jamesh's feedback on it | 15:46 |
| niemeyer | @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 |
| nothal | niemeyer: No such command! | 15:47 |
| niemeyer | 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:49 |
| niemeyer | GetProperty is a pretty concerning problem, for example, because it lives in its own separate interface.. how can we confine it properly? | 15:50 |
| mup | PR snapd#2480 opened: many: prepare landing on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/2480> | 16:01 |
| mup | Bug #1649934 opened: USB Auto-mount for assertion import fails <Snappy:New> <https://launchpad.net/bugs/1649934> | 16:02 |
| mup | PR snapd#2481 opened: osutil: fix unit tests to pass on OS X <Created by zyga> <https://github.com/snapcore/snapd/pull/2481> | 16:02 |
| mup | Issue snapd#2478 closed: Just testing <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/issue/2478> | 16:06 |
| mup | PR snapd#2481 closed: osutil: fix unit tests to pass on OS X <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2481> | 16:19 |
| mup | PR snapcraft#965 closed: sources: refactor mercurial source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/965> | 16:23 |
| mup | PR snapd#2482 opened: store: retry auth-related requests <Created by stolowski> <https://github.com/snapcore/snapd/pull/2482> | 16:31 |
| mup | PR snapd#2483 opened: store: use mocked retry strategy to make store tests faster <Created by stolowski> <https://github.com/snapcore/snapd/pull/2483> | 16:41 |
| mup | Issue snapd#2484 opened: Support removing all unused revisions <Created by niemeyer> <https://github.com/snapcore/snapd/issue/2484> | 16:49 |
| mup | Bug #1555217 changed: snappy leaks loop devices <snapd:Unknown> <https://launchpad.net/bugs/1555217> | 16:53 |
| mup | PR snapcraft#973 opened: Check the license agreement on Travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/973> | 18:17 |
| mup | PR snapcraft#974 opened: Updated maven plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/974> | 18:17 |
| mup | PR snapcraft#975 opened: Updated the gradle.py plugin to use the get_build_properties() method instead of modifying the schema <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/975> | 18:17 |
| jdstrand | 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 |
| ogra_ | 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 |
| ogra_ | : | 18:38 |
| ogra_ | :( | 18:38 |
| jdstrand | niemeyer: also, GNOME and KDE apps don't do the different interfaces, they use consistent interfaces that work with this PR | 18:38 |
| jdstrand | 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:40 |
| jdstrand | 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:41 |
| jdstrand | s/dbus policy/dbus bus policy generally/ | 18:42 |
| mup | PR snapd#2479 closed: many: implement snap unalias using snapstate.Unalias <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2479> | 18:42 |
| niemeyer | 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 |
| jdstrand | 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:45 |
| jdstrand | niemeyer: he is not trying to snap a GNOME application | 18:46 |
| jdstrand | niemeyer: he is trying to write a dbus session service | 18:46 |
| jdstrand | niemeyer: we don't support that in at least two other ways beyond this PR | 18:46 |
| jdstrand | this PR works for Properties.Get() for leaf-style applications. He did not notice the rule I mentioned covered his concern | 18:47 |
| niemeyer | I don't get that distinction.. gnome applications are just software like any other.. they can use dbus as they see fit | 18:47 |
| jdstrand | 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 |
| jdstrand | niemeyer: gnome and kde applications use toolkit libraries that use dbus in a very specific way | 18:48 |
| jdstrand | niemeyer: eg, GApplication | 18:48 |
| jdstrand | this is why no GNOME application works today. GApplication binds to the well-known name | 18:49 |
| niemeyer | Do you know what James means when he talks about multiple well known names? | 18:49 |
| jdstrand | the toolkit takes that well-known name and actually creates dbus paths and interfaces very regularly | 18:49 |
| jdstrand | precisely in the way that this PR addresses | 18:49 |
| jdstrand | niemeyer: he was saying several things | 18:49 |
| niemeyer | I'm asking about one specific thing | 18:50 |
| jdstrand | 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 |
| jdstrand | niemeyer: this PR handles '3' | 18:51 |
| jdstrand | '1' and '2' it does not. and we specifically decided before that it should not in *this* iteration | 18:51 |
| jdstrand | a future iteration would consider these other use cases and we would design for that | 18:52 |
| jdstrand | this PR is written in a manner that we can build upon for the future use cases | 18:52 |
| niemeyer | How do we handle 1 in the future? That'd what James was talking about | 18:53 |
| jdstrand | add 'interface' attribute | 18:53 |
| niemeyer | When referring to multiple well known names | 18:54 |
| jdstrand | and '2' is add 'path' attribute | 18:54 |
| niemeyer | Doesnt work.. interface is something else | 18:54 |
| jdstrand | ok, 'dbus-interface' | 18:54 |
| niemeyer | What is name then? | 18:54 |
| jdstrand | interface is an overloaded term | 18:54 |
| niemeyer | I thought that was interface | 18:54 |
| jdstrand | it means one thing in dbus and another in snappy | 18:55 |
| niemeyer | Yes, we're talking about dbus | 18:55 |
| niemeyer | What is the name attribute referring to? I thought it was the dbus interface name? | 18:56 |
| mup | PR snapcraft#966 closed: sources: refactor rpm source into module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/966> | 18:56 |
| jdstrand | 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 |
| jdstrand | niemeyer: the 'name' attribute is the well-known dbus connection name | 18:56 |
| jdstrand | org.gnome.Logs | 18:56 |
| jdstrand | org.gnome.Rhythmbox | 18:56 |
| jdstrand | GNOME and KDE toolkits are very regular with how the well-known name corresponds to dbus interface and dbus paths | 18:57 |
| jdstrand | which is why this PR does what it is doing now | 18:58 |
| jdstrand | 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 |
| niemeyer | So do we support any interface on the well known name? | 18:58 |
| jdstrand | we did discuss this before, but, look at https://github.com/snapcore/snapd/pull/1613/files#diff-715ebbcbcd440b44a1e536f154ca6138R149 | 19:00 |
| mup | PR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613> | 19:00 |
| jdstrand | we allow a connected snap to introspect our dbus api | 19:01 |
| jdstrand | we allow a connected snap to use any dbus interface and any dbus path if they are connecting to the well-known name | 19:01 |
| jdstrand | 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 |
| niemeyer | Okay, that sounds reasonable | 19:02 |
| niemeyer | Thanks for the long explanation | 19:02 |
| jdstrand | 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:02 |
| niemeyer | Happy to go forward with it | 19:03 |
| jdstrand | \o/ | 19:03 |
| niemeyer | Is the PR blocked on anything else at this point? | 19:03 |
| jdstrand | niemeyer: no. tyhicks reviewed the security policy. pedronis reviewed the code. I incorporated all applicable feedback from everywhere | 19:04 |
| niemeyer | So let's get it in | 19:04 |
| jdstrand | thanks! | 19:04 |
| niemeyer | Thank you! | 19:04 |
| jdstrand | 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:06 |
| elopio | morphis__: looking at your homeassitant reply, it's not really necessary to have the snapcraft.yaml in the root | 19:13 |
| elopio | https://github.com/blockstack/blockstack-core/pull/264/files#diff-a4a8be59175f107f2ba1ce86da0c8286R28 | 19:13 |
| mup | PR blockstack/blockstack-core#264: Add the packaging metadata to build the blockstack-core snap <Created by elopio> <https://github.com/blockstack/blockstack-core/pull/264> | 19:13 |
| elopio | it looks better, that's true. And sometimes using the relative path might cause a mess. But it should work. | 19:14 |
| jdstrand | 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:15 |
| jdstrand | niemeyer: since your previous 'requested changes' is still in effect, I'll leave this to you to pres the merge button? | 19:17 |
| jdstrand | press* | 19:17 |
| morphis__ | elopio: interesting | 19:19 |
| mup | PR snapd#2485 opened: overlord: apply auto-aliases information from the snap-declaration on install or refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/2485> | 19:20 |
| * ahoneybun slides some money to someone who can snap this: https://github.com/wereturtle/ghostwriter | 19:38 | |
| kyrofa | ahoneybun, did you run into problems with it? | 19:41 |
| ahoneybun | kyrofa: tbh I've not even tried | 19:41 |
| ahoneybun | I've only gotten 1 snap to work | 19:42 |
| ahoneybun | well half work as it needed flash for some content | 19:44 |
| kissiel | my network problems are gone, lesson learned: KEEP AWAY FROM NETGEAR | 20:04 |
| kyrofa | kissiel, yikes, was it compromised? | 20:05 |
| kissiel | not that bad; 9/10 snap commands timed out | 20:06 |
| kissiel | reason being bad DNS via ipv6 handling | 20:06 |
| kissiel | and causing a mess/timeouts | 20:06 |
| kyrofa | kissiel, if it makes you feel better, I think my asus is dying on me, too | 20:09 |
| kissiel | kyrofa: which one is it, cause from today on I got two :D | 20:10 |
| kyrofa | kissiel, RT-N66U, but it's pretty old nowadays | 20:10 |
| kyrofa | kissiel, and it might also be my modem. Or ISP :P | 20:10 |
| kyrofa | Tough to debug problems like that | 20:11 |
| kissiel | kyrofa: oh man; oh yeah | 20:11 |
| kissiel | kyrofa: my wget -4 apps.ubuntu.com took 0.2s, while without `-4` it took 15s+ | 20:12 |
| mhall119 | jdstrand: if a snap uses the removable-media interface, where will the snap environment see that media? | 20:31 |
| jdstrand | mhall119: /media on classic. an all snaps system with udisks2 snap installed, /run/media | 20:38 |
| mhall119 | jdstrand: thanks, does it only make it visible when you try to access it? | 20:39 |
| jdstrand | 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:41 |
| mhall119 | 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 |
| mhall119 | trying to determine if this is a snapd thing, or a krita thing | 20:42 |
| jdstrand | 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 |
| jdstrand | mhall119: let me check the exact rule for under /media | 20:44 |
| jdstrand | mhall119: right, cause mounts are done in /media/<user>/, 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:45 |
| jdstrand | these are the rules: | 20:46 |
| jdstrand | # Mount points could be in /run/media/<user>/* or /media/<user>/* | 20:46 |
| jdstrand | /{,run/}media/*/ r, | 20:46 |
| jdstrand | /{,run/}media/*/** rw, | 20:46 |
| mhall119 | that's kind of hard to discover, is there any way we can make this better? | 20:46 |
| jdstrand | 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 |
| jdstrand | mhall119: that way the application doesn' | 20:48 |
| jdstrand | t have to care about snappy. the user drives the interaction, and the out of process trusted helper mediates the access | 20:49 |
| jdstrand | there is a bug on this and that is what was outlined | 20:49 |
| mhall119 | jdstrand: ideally yes, and that's likely to come in the future, but doesn't help yet | 20:49 |
| mhall119 | strangly, the open dialog can see /home and /snap when I point it to / | 20:49 |
| jdstrand | that is indeed strage | 20:50 |
| jdstrand | 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:53 |
| jdstrand | 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 |
| jdstrand | and because HOME is set to /home/user/snap/$SNAP/$REVISION/, apps start down there. there is a bug on that too | 20:54 |
| jdstrand | (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:55 |
| jdstrand | ) | 20:56 |
| mup | PR snapcraft#976 opened: demos: do not force arch for the tomcat demo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/976> | 21:05 |
| knight__ | 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 |
| kyrofa | ogra_, ^^ if you're still around | 21:10 |
| ogra_ | 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:11 |
| ogra_ | (there is a bug with the pi33 driver on first boot setup, but it works fine later) | 21:12 |
| ogra_ | **pi3 | 21:12 |
| === datajerk is now known as datajerk_ | ||
| knight__ | ogra_ why hasn't the bug been fixed? Is it a hardware issue? Or is there a problem with the kernel? | 21:19 |
| ogra_ | its a driver issue, fix is in the works but not there | 21:20 |
| knight__ | 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 |
| knight__ | For example, let's say I am building a custom firmware. | 21:20 |
| ogra_ | 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 | 21:23 |
| === datajerk_ is now known as datajerk | ||
| knight__ | ogra_ but isn't the purpose of Ubuntu Core to be the basis of custom IoT firmwares? | 21:38 |
| ogra_ | yes | 21:38 |
| knight__ | So how are people customizing Ubuntu Core to be self-contained custom firmwares for their devices? | 21:38 |
| ogra_ | they rll their own images based on a custom gadget snap | 21:39 |
| knight__ | Oh I see. So not using the "intro" image | 21:39 |
| knight__ | The image available on the Ubuntu Core page is really just to get running a vanilla core on a preferred supported device easy. Not as the start for a custom build. | 21:40 |
| knight__ | Is that right? | 21:40 |
| ogra_ | right, the gadget can ship default configs and such ... an when you build your own image using ubuntu-image you can easily add additional snap packages to get extra features | 21:40 |
| knight__ | Ahh beautiful, ok. | 21:40 |
| ogra_ | well, to get a custom build you would start from there | 21:40 |
| ogra_ | install the official core image, add your additional snaps and configure them etc | 21:40 |
| ogra_ | also for many applications the official image is sufficient ... | 21:41 |
| knight__ | Are you aware of any native support for creating things like restore partitions and custom firmware updates? | 21:41 |
| ogra_ | i.e. the nextcloud box ... | 21:41 |
| ogra_ | you dont really need a local user for it ... you create and manage the nextcloud users via the nextcloud UI | 21:41 |
| knight__ | Such as if two pins on the RPI3 GPIO are activated (button held down), can initiate a rollback to "stock" on the restore image | 21:41 |
| ogra_ | (same would go for a kodi image, you wouldnt really need any users on it to watvh TV) | 21:42 |
| ogra_ | such fanc stuff is further down the roadmap ... but yeah, things like recovery mode and factory reset are on the roadmap | 21:42 |
| ogra_ | **fancy | 21:43 |
| knight__ | oh nice | 21:44 |
| knight__ | so not avail yet, but on the roadmap | 21:44 |
| ogra_ | yep | 21:46 |
| ogra_ | there is also a so called "model creator" planned, that should make it trivial to build your own custom images | 21:47 |
| knight__ | oh wild | 21:49 |
| knight__ | ok, all that right there just made me excited for Core | 21:49 |
| knight__ | so, can i skip setting up wired networking altogether, then re-run console-conf on first boot? or must it establish a wired connection no matter what? | 21:49 |
| knight__ | Seems like there's no way to skip networking. | 21:50 |
| ogra_ | well, since you need an ubuntu SSO account to create the local user from ... network is kind of needed | 21:54 |
| ogra_ | (core grabs your ssh key from the SSO account and sets up a local ssh key login for you) | 21:55 |
| knight__ | Ahh right | 21:58 |
| knight__ | OK. | 21:58 |
| knight__ | Bummer, I don't have screen near network drop. | 21:58 |
| ogra_ | serial console is enabled by default in case that helps ... | 22:00 |
| ogra_ | (for console-conf) | 22:00 |
| mup | PR snapd#2486 opened: tests: fix tests on 17.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/2486> | 22:07 |
| === petevg is now known as petevg_afk | ||
| mup | PR snapd#2487 opened: overlord/snapstate: implement snapstate.ResetAlias <Created by pedronis> <https://github.com/snapcore/snapd/pull/2487> | 22:11 |
| * ogra_ goes afk | 22:13 | |
| knight__ | ogra_ ... does that mean you don't have to get network up and logged in first? | 22:20 |
| mup | PR snapcraft#967 closed: sources: refactor script source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/967> | 22:41 |
| === jkridner|pd is now known as jkridner | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!