mupPR snapcraft#968 opened: sources: refactor subversion source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/968>00:07
mupPR snapcraft#969 opened: sources: refactor tar source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/969>00:13
mupPR snapcraft#970 opened: sources: refactor zip source into module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/970>00:16
mupPR 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
mupPR snapd#2345 closed: many: tweak devmode and jailmode capitalisation <Created by zyga> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2345>00:58
barrypedronis: thanks01:27
mupPR 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
mupPR snapcraft#963 closed: sources: refactor deb source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/963>03:25
luk3yxIs this the best place to ask a snappy playpen question?04:57
mupPR snapcraft#971 opened: Fix integration tests in armhf <Created by elopio> <https://github.com/snapcore/snapcraft/pull/971>05:01
mupPR 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
mupPR snapd#2459 closed: interfaces/builtin: add iio interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2459>07:06
mupPR snapd#2452 closed: interfaces/builtin: fix pulseaudio apparmor rules <Created by bergotorino> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2452>07:07
mupPR 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
dholbachhey hey07:52
=== chihchun_afk is now known as chihchun
mupPR 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
mupPR snapd#2475 opened: tests: nested image testing <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2475>09:55
mupBug #1649837 opened: Can remove required-snaps <Snappy:New> <https://launchpad.net/bugs/1649837>10:17
mupPR 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
mupBug #1649839 opened: unknown snap and snapd version when image created via ubuntu-image <Snappy:New> <https://launchpad.net/bugs/1649839>10:20
mupBug #1649840 opened: unknown keys in model assertion are silently ignored <Snappy:New> <Ubuntu Image:New> <https://launchpad.net/bugs/1649840>10:23
mupPR 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
mupPR snapd#2476 opened: overlord/snapstate: fixing the placement/grouping of some functions <Created by pedronis> <https://github.com/snapcore/snapd/pull/2476>10:52
mupPR 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
mupBug #1488887 changed: porting documentation needs adjustment for new uboot.env setup <snap-docs> <Snappy:Invalid by ogra> <https://launchpad.net/bugs/1488887>11:42
mupBug #1595581 changed: Snappy meta guide issues <snap-docs> <Ubuntu Developer Portal:Fix Released> <Snappy:Invalid> <https://launchpad.net/bugs/1595581>11:45
mupBug #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
mupBug #1637093 changed: docs/config.md needs an update <snap-docs> <Snappy:Invalid> <https://launchpad.net/bugs/1637093>11:51
mupPR 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
ondraogra_ ping12:18
ogra_ondra, yo12:18
ondraogra_ 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
ondraogra_ ha, nope to which part? :P12:19
ondraogra_ 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 tree12:20
ondraogra_ and upstream is where?12:20
ogra_i just noticed we are missing said patch for the dragonboard in our tree12:20
ogra_ondra, denx.de12:21
ogra_upstream uboot12: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 patch12:21
ogra_the pi's and beaglebone just use the upstream tree12:22
ondraogra_ cool12:23
ondraogra_ yeah I have here dragonboard, and was not sure if we use same tree there or not12:23
ondraogra_ so http://git.denx.de/ + patch from gadget for pi3 it is12: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, yeah12:24
ondraogra_ 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
Chipacaogra_, I think https://bugs.launchpad.net/snappy/+bug/1620559 is fix released; can you confirm?13:41
mupBug #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
mupPR snapcraft#972 opened: Add a checklist in the pull request template <Created by elopio> <https://github.com/snapcore/snapcraft/pull/972>13:53
niemeyerjdstrand: ping14:15
mupPR snapd#2477 opened: interfaces/builtin/repowerd: First cut at repowerd interface <Created by afrantzis> <https://github.com/snapcore/snapd/pull/2477>14:18
mupPR snapcraft#964 closed: sources: refactor git source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/964>14:23
jdstrandniemeyer: hi!14:23
jdstrandniemeyer: if you are asking about James' feedback, I incorporated GetConnectionCredentials and responded to the other comments14:27
jdstrandniemeyer: (James' comments in https://github.com/snapcore/snapd/pull/1613 that is)14:27
mupPR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>14:27
r2geoquestion on ubuntu core: is there a way to run "lsusb" in bash? -bash: lsusb: command not found14:34
niemeyerjdstrand: Hey14:38
niemeyerjdstrand: Yeah, James feedback14:38
niemeyerjdstrand: What do you think of making "path" explicit?14:38
niemeyerjdstrand: Any reason not to?14:38
jdstrandniemeyer: 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 services14:40
jdstrandniemeyer: he as asking for multiple paths and interfaces pur well-known name as well. we don't even have session services yet14:41
jdstrandniemeyer: not sure if you read my response14:42
jdstrand(in the PR to James)14:42
ogra_Chipaca, bug updated ...14:48
ogra_(thanks for the pointer)14:49
Chipacaogra_, incompletely fix released \o/14:49
mupBug #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
roadmrhello folks, is there a version of snapd that works on trusty? even if it's from a PPA, that would fit my needs14:53
ogra_tvoss, ^^^^14:54
niemeyerjdstrand: I didn't.. will get back in this after lunch14:57
tvossroadmr: yup, let me hand you instructions15:00
roadmrtvoss: great, thanks! (yes, perfectly happy to read up existing material)15:00
mupIssue snapd#2478 opened: Just testing <Created by zyga> <https://github.com/snapcore/snapd/issue/2478>15:03
jdstrandniemeyer: ok, note I have an appt in 45 minutes for a couple of hours and then will be back15:04
elfgohogra_: 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 usually15:22
elfgohI see. So you test on an actual device?15:23
elfgohIf 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 mode15:24
ogra_which would break15: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
elfgohI see15:25
ogra_if you can use qemu for BBB arches like kvm that would work, but only then15:25
ogra_(i.e. just point to the img file and have that boot)15:26
elfgohSo 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 afaik15: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
elfgohogra_, I think you are probably right15:31
elfgohogra_, 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 userspace15:33
ogra_note that wont work for everything (i.e. i dont think you can compile mono apps) but for most15:34
mupPR snapd#2479 opened: many: implement snap unalias using snapstate.Unalias <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2479>15:40
niemeyerjdstrand: Read your response.. I'm concerned with ignoring jamesh's feedback on it15: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 yet15:47
nothalniemeyer: No such command!15:47
niemeyerjdstrand: 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 yet15:49
niemeyerGetProperty is a pretty concerning problem, for example, because it lives in its own separate interface.. how can we confine it properly?15:50
mupPR snapd#2480 opened: many: prepare landing on trusty <Created by vosst> <https://github.com/snapcore/snapd/pull/2480>16:01
mupBug #1649934 opened: USB Auto-mount for assertion import fails <Snappy:New> <https://launchpad.net/bugs/1649934>16:02
mupPR snapd#2481 opened: osutil: fix unit tests to pass on OS X <Created by zyga> <https://github.com/snapcore/snapd/pull/2481>16:02
mupIssue snapd#2478 closed: Just testing <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/issue/2478>16:06
mupPR 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
mupPR snapcraft#965 closed: sources: refactor mercurial source into module <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/965>16:23
mupPR snapd#2482 opened: store: retry auth-related requests <Created by stolowski> <https://github.com/snapcore/snapd/pull/2482>16:31
mupPR 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
mupIssue snapd#2484 opened: Support removing all unused revisions <Created by niemeyer> <https://github.com/snapcore/snapd/issue/2484>16:49
mupBug #1555217 changed: snappy leaks loop devices <snapd:Unknown> <https://launchpad.net/bugs/1555217>16:53
mupPR snapcraft#973 opened: Check the license agreement on Travis <Created by elopio> <https://github.com/snapcore/snapcraft/pull/973>18:17
mupPR snapcraft#974 opened: Updated maven plugin to use get_build_properties() <Created by ZenHarbinger> <https://github.com/snapcore/snapcraft/pull/974>18:17
mupPR 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
jdstrandniemeyer: did you see my response for Properties.Get()? it is covered for GNOME and KDE apps which this iteration is trying to unblock18: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.com18:38
jdstrandniemeyer: also, GNOME and KDE apps don't do the different interfaces, they use consistent interfaces that work with this PR18:38
jdstrandniemeyer: 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[C18:40
jdstrandniemeyer: 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 odd18:41
jdstrands/dbus policy/dbus bus policy generally/18:42
mupPR 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
niemeyerjdstrand: 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 making18:45
jdstrandniemeyer: 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 yet18:45
jdstrandniemeyer: he is not trying to snap a GNOME application18:46
jdstrandniemeyer: he is trying to write a dbus session service18:46
jdstrandniemeyer: we don't support that in at least two other ways beyond this PR18:46
jdstrandthis PR works for Properties.Get() for leaf-style applications. He did not notice the rule I mentioned covered his concern18:47
niemeyerI don't get that distinction.. gnome applications are just software like any other.. they can use dbus as they see fit18:47
jdstrandniemeyer: 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, etc18:48
jdstrandniemeyer: gnome and kde applications use toolkit libraries that use dbus in a very specific way18:48
jdstrandniemeyer: eg, GApplication18:48
jdstrandthis is why no GNOME application works today. GApplication binds to the well-known name18:49
niemeyerDo you know what James means when he talks about multiple well known names?18:49
jdstrandthe toolkit takes that well-known name and actually creates dbus paths and interfaces very regularly18:49
jdstrandprecisely in the way that this PR addresses18:49
jdstrandniemeyer: he was saying several things18:49
niemeyerI'm asking about one specific thing18:50
jdstrandniemeyer: 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 names18:51
jdstrandniemeyer: this PR handles '3'18:51
jdstrand'1' and '2' it does not. and we specifically decided before that it should not in *this* iteration18:51
jdstranda future iteration would consider these other use cases and we would design for that18:52
jdstrandthis PR is written in a manner that we can build upon for the future use cases18:52
niemeyerHow do we handle 1 in the future? That'd what James was talking about18:53
jdstrandadd 'interface' attribute18:53
niemeyerWhen referring to multiple well known names18:54
jdstrandand '2' is add 'path' attribute18:54
niemeyerDoesnt work.. interface is something else18:54
jdstrandok, 'dbus-interface'18:54
niemeyerWhat is name then?18:54
jdstrandinterface is an overloaded term18:54
niemeyerI thought that was interface18:54
jdstrandit means one thing in dbus and another in snappy18:55
niemeyerYes, we're talking about dbus18:55
niemeyerWhat is the name attribute referring to? I thought it was the dbus interface name?18:56
mupPR snapcraft#966 closed: sources: refactor rpm source into module <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/966>18:56
jdstrandniemeyer: 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 path18:56
jdstrandniemeyer: the 'name' attribute is the well-known dbus connection name18:56
jdstrandGNOME and KDE toolkits are very regular with how the well-known name corresponds to dbus interface and dbus paths18:57
jdstrandwhich is why this PR does what it is doing now18:58
jdstrandwhat 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 policy18:58
niemeyerSo do we support any interface on the well known name?18:58
jdstrandwe did discuss this before, but, look at https://github.com/snapcore/snapd/pull/1613/files#diff-715ebbcbcd440b44a1e536f154ca6138R14919:00
mupPR snapd#1613: interfaces/builtin: add dbus interface (LP: #1590679) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/1613>19:00
jdstrandwe allow a connected snap to introspect our dbus api19:01
jdstrandwe allow a connected snap to use any dbus interface and any dbus path if they are connecting to the well-known name19:01
jdstrandif 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 name19:02
niemeyerOkay, that sounds reasonable19:02
niemeyerThanks for the long explanation19:02
jdstrandif 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 name19:02
niemeyerHappy to go forward with it19:03
niemeyerIs the PR blocked on anything else at this point?19:03
jdstrandniemeyer: no. tyhicks reviewed the security policy. pedronis reviewed the code. I incorporated all applicable feedback from everywhere19:04
niemeyerSo let's get it in19:04
niemeyerThank you!19:04
jdstrandniemeyer: 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 you19:06
elopiomorphis__: looking at your homeassitant reply, it's not really necessary to have the snapcraft.yaml in the root19:13
mupPR 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
elopioit looks better, that's true. And sometimes using the relative path might cause a mess. But it should work.19:14
jdstrandniemeyer: 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 policy19:15
jdstrandniemeyer: since your previous 'requested changes' is still in effect, I'll leave this to you to pres the merge button?19:17
morphis__elopio: interesting19:19
mupPR 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/ghostwriter19:38
kyrofaahoneybun, did you run into problems with it?19:41
ahoneybunkyrofa: tbh I've not even tried19:41
ahoneybunI've only gotten 1 snap to work19:42
ahoneybunwell half work as it needed flash for some content19:44
kissielmy network problems are gone, lesson learned: KEEP AWAY FROM NETGEAR20:04
kyrofakissiel, yikes, was it compromised?20:05
kissielnot that bad; 9/10 snap commands timed out20:06
kissielreason being bad DNS via ipv6 handling20:06
kissieland causing a mess/timeouts20:06
kyrofakissiel, if it makes you feel better, I think my asus is dying on me, too20:09
kissielkyrofa: which one is it, cause from today on I got two :D20:10
kyrofakissiel, RT-N66U, but it's pretty old nowadays20:10
kyrofakissiel, and it might also be my modem. Or ISP :P20:10
kyrofaTough to debug problems like that20:11
kissielkyrofa: oh man; oh yeah20:11
kissielkyrofa: my wget -4 apps.ubuntu.com took 0.2s, while without `-4` it took 15s+20:12
mhall119jdstrand: if a snap uses the removable-media interface, where will the snap environment see that media?20:31
jdstrandmhall119: /media on classic. an all snaps system with udisks2 snap installed, /run/media20:38
mhall119jdstrand: thanks, does it only make it visible when you try to access it?20:39
jdstrandmhall119: 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 directory20:41
mhall119jdstrand: 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, etc20:42
mhall119trying to determine if this is a snapd thing, or a krita thing20:42
jdstrandmhall119: 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 readable20:44
jdstrandmhall119: let me check the exact rule for under /media20:44
jdstrandmhall119: 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 dialog20:45
jdstrandthese 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
mhall119that's kind of hard to discover, is there any way we can make this better?20:46
jdstrandmhall119: 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-hub20:48
jdstrandmhall119: that way the application doesn'20:48
jdstrandt have to care about snappy. the user drives the interaction, and the out of process trusted helper mediates the access20:49
jdstrandthere is a bug on this and that is what was outlined20:49
mhall119jdstrand: ideally yes, and that's likely to come in the future, but doesn't help yet20:49
mhall119strangly, the open dialog can see /home and /snap when I point it to /20:49
jdstrandthat is indeed strage20:50
jdstrandI mean, we *could* allow '/home/ r, / r, /media/ r,'. that would allow enumerating users. It wouldn't be the worst thing, especially on classic20:53
jdstrandthere 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 apps20:54
jdstrandand because HOME is set to /home/user/snap/$SNAP/$REVISION/, apps start down there. there is a bug on that too20: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, etc20:55
mupPR 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
kyrofaogra_, ^^ if you're still around21: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 wireless21:11
ogra_(there is a bug with the pi33 driver on first boot setup, but it works fine later)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 there21: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, sorry21: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
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 snap21:39
knight__Oh I see. So not using the "intro" image21: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 features21:40
knight__Ahh beautiful, ok.21:40
ogra_well, to get a custom build you would start from there21:40
ogra_install the official core image, add your additional snaps and configure them etc21: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 UI21: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 image21: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 roadmap21:42
knight__oh nice21:44
knight__so not avail yet, but on the roadmap21:44
ogra_there is also a so called "model creator" planned, that should make it trivial to build your own custom images21:47
knight__oh wild21:49
knight__ok, all that right there just made me excited for Core21: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 needed21: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 right21: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
mupPR 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
mupPR snapd#2487 opened: overlord/snapstate: implement snapstate.ResetAlias <Created by pedronis> <https://github.com/snapcore/snapd/pull/2487>22:11
* ogra_ goes afk22:13
knight__ogra_ ... does that mean you don't have to get network up and logged in first?22:20
mupPR 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!