| === chihchun_afk is now known as chihchun | ||
| === 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 | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === zyga is now known as zyga_ | ||
| oparoz | I have a question regarding: https://developer.ubuntu.com/en/snappy/build-apps/your-first-snap/ | 08:25 |
|---|---|---|
| oparoz | It says that the snap will only work on Core, so how do we pick a target since snaps can also be created for the desktop? | 08:26 |
| davidcalle | oparoz: actually, the snappy is running on core on the desktop, so yes, it should work as long as the snap targets the right arch | 08:27 |
| davidcalle | s/the snappy/the snap :) | 08:28 |
| oparoz | Thanks davidcalle, so it's just a problem with the doc then. I can install snapcraft on a desktop, create a multi-arch snap and deploy on desktop,server and core without any issue as long as they all use the same Snappy engine (16.04) | 08:29 |
| zyga_ | good morning | 08:29 |
| oparoz | Do we report doc problems on LP, in the Snapcraft project? | 08:31 |
| davidcalle | oparoz: yes, snapcraft doc is being updated to match the latest state of things. Examples in here (https://developer.ubuntu.com/en/desktop/) are the most recent (less detailled, though). | 08:31 |
| davidcalle | oparoz: snapcraft project, yes. https://bugs.launchpad.net/snapcraft | 08:31 |
| oparoz | Thank you davidcalle | 08:32 |
| davidcalle | yw | 08:32 |
| === zyga_ is now known as zyga | ||
| slvn | hello ... a few questions : 1) I have a few .click (arm, native binary) package for ubuntu phones, does it make sense to upgrade to snappy package ? | 09:00 |
| zyga | slvn: what kind of app is that? | 09:02 |
| zyga | slvn: I guess right now the answer is "if that snap would run on desktops" | 09:02 |
| slvn | zyga, games based on libSDL2 | 09:02 |
| zyga | slvn: sure, you can target the desktop with your snap | 09:03 |
| slvn | the games could also run on desktop, provided I compiled them for desktop | 09:03 |
| zyga | slvn: and inevitably the phone will adopt snaps at some point so you will already know how things work there | 09:03 |
| slvn | also I tried to install my .click package on my destkop and it refused to be installed (cannot be install on X ...) | 09:04 |
| slvn | so I should look how to provide a snap package that contains both arm and x86 libs for arm and desktop | 09:05 |
| slvn | Will snapy packages run *confined* like .click on phones ? | 09:06 |
| === chihchun is now known as chihchun_afk | ||
| === JamesTait is now known as Guest6158 | ||
| === Guest6158 is now known as JamesTait | ||
| davidcalle | slvn: to some extent, yes. Eg. snaps on the desktop can be granted access to $HOME | 09:14 |
| davidcalle | slvn: note that the phone switch to snap will take time. | 09:15 |
| === chihchun_afk is now known as chihchun | ||
| === seb128_ is now known as seb128 | ||
| slvn | davidcalle, zyga, thanks for the answers, I will have a look on snapy ! | 09:36 |
| seb128 | is there an "apt-cache show" equivalent in the snap world? | 09:37 |
| seb128 | snap list lists names, but that's not very useful to figure out what the snaps are exactly | 09:38 |
| zyga | seb128: I don't think there is one | 09:40 |
| seb128 | :-/ | 09:40 |
| zyga | seb128: as a hack, you can look at /snap/$name/current/meta/snap.yaml | 09:41 |
| zyga | seb128: but that's just a portion of the information we have about each snap (2nd part comes from the store) | 09:41 |
| seb128 | zyga, I'm not hacking | 09:41 |
| seb128 | just trying to use it as an user | 09:41 |
| zyga | seb128: I know that Chipaca is working on a richer REST API | 09:41 |
| seb128 | k, I'm also trying if we have those info available so we integrate them with the desktop frontend | 09:42 |
| zyga | seb128: you mean in gnome-software? | 09:46 |
| seb128 | yes | 09:46 |
| zyga | seb128: AFAIR gnome software should use the rest api | 09:46 |
| zyga | seb128: there we can expose many details easily | 09:46 |
| seb128 | right | 09:46 |
| seb128 | I was just trying to see what is currently exposed | 09:46 |
| seb128 | and I though I would start as an user with using the command line to see what is displayed there | 09:46 |
| seb128 | but I hit that wall ;-) | 09:47 |
| zyga | yep, I understand | 09:48 |
| zyga | seb128: perhaps this can be of some use: https://github.com/ubuntu-core/snappy/blob/master/client/packages.go | 09:48 |
| zyga | this is the client side rest API | 09:48 |
| plars | popey: you still have these problems like we discussed yesterday with building images with udf, right? fgimenez just sent me a rebuilt binary, but it didn't seem to help, and then I found myself wondering if there was some known-fix that I just didn't hear about yet | 09:48 |
| zyga | it's in go but you can make the query in any language | 09:48 |
| seb128 | right | 09:49 |
| popey | plars: i haven't tested since it made my laptop unusable | 09:49 |
| seb128 | zyga, is there an easy way to see what is currently available? I'm looking after the license info | 09:49 |
| zyga | seb128: available as in "can install"? | 09:49 |
| plars | popey: ack, thanks | 09:49 |
| popey | happy to test to confirm any thing you might need plars | 09:50 |
| seb128 | zyga, no, I was wonder if there is a way to query the license from a snap through the rest api atm | 09:50 |
| zyga | ah | 09:50 |
| * zyga looks | 09:50 | |
| plars | popey: I just wonder how it works for others | 09:50 |
| popey | plars: i expect people don't run that commanbd | 09:50 |
| zyga | seb128: no, I don't think so, AFAIR some license code was removed before 16.04 as it wasn't ready | 09:50 |
| seb128 | attente, ^ | 09:50 |
| zyga | seb128, Chipaca: will know more for sure | 09:51 |
| seb128 | zyga, thanks | 09:51 |
| Chipaca | no i won't | 09:51 |
| * Chipaca reads | 09:51 | |
| seb128 | willcooke, do we maintain a list of things we would need? until ^ is resolved g-s is going to show snaps with a "that software is non free" banner | 09:51 |
| seb128 | Chipaca, can we query the license of a snap through the rest api? | 09:52 |
| Chipaca | seb128: nope | 09:52 |
| Chipaca | not sure why not though | 09:52 |
| Chipaca | gimme a sec | 09:52 |
| Chipaca | seb128: so, no. But it could be added easily. | 09:53 |
| seb128 | Chipaca, we have https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1555567 could you comment/triage the snappy/store side? | 09:54 |
| ubottu | Launchpad bug 1555567 in gnome-software (Ubuntu) "License information from the store not being used" [Medium,Triaged] | 09:54 |
| willcooke | seb128, we need to get it on to the backlog, so we attend the stakeholders meeting and request it. (wow! such manager speak) | 09:54 |
| seb128 | willcooke, :-) | 09:54 |
| seb128 | willcooke, ^ bug reference there | 09:54 |
| willcooke | seb128, so I think we should log bugs and tag them | 09:54 |
| willcooke | ah nice | 09:55 |
| willcooke | I'll think up a suitable tag name | 09:55 |
| Chipaca | seb128: done | 09:57 |
| seb128 | Chipaca, willcooke, thanks | 09:57 |
| Chipaca | willcooke: our bad, wrt licensing | 09:57 |
| Chipaca | as long as we're not talking of *accepting a license prompt*, shipping the info should be doable rsn | 09:57 |
| Chipaca | if it's urgent i mean :-D | 09:57 |
| Chipaca | the interactive license thing is for in about a month? wild-arsed guess | 09:58 |
| seb128 | yeah, no need of interaction | 09:59 |
| willcooke | just spoke to seb128 about this - this issue is that there is a fairly large and unsightly banner in g-s which nags "Freedom hater" | 09:59 |
| willcooke | so it would be /nice/ to have that fixed | 09:59 |
| willcooke | for the first release of the snappy enabled g-s | 09:59 |
| === chihchun is now known as chihchun_afk | ||
| stevebiscuit | https://code.launchpad.net/~stevenwilkin/webdm/snappy-2-0/+merge/292902 # gets WebDM building against recent Snappy | 10:37 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| slvn | got some error when doing "snappy -v" : "snappy version 0.3.7" .... "(snappy:16290): GLib-GObject-CRITICAL **: g_object_set: assertion 'G_IS_OBJECT (object)' failed.No media set. ' | 10:57 |
| slvn | http://paste.ubuntu.com/16061735/ | 10:57 |
| slvn | sorry stupid question, don't know which tutorial makes me install that :) | 11:10 |
| Chipaca | slvn: that's probably not this snappy | 11:14 |
| Chipaca | :-) | 11:14 |
| flexiondotorg | If I create a snap that uses a reserved interface in a snap, such as unity7, is it subject to manual review when submitted to the stire. | 11:15 |
| flexiondotorg | *store | 11:15 |
| slvn | Chipaca, yes, I figured out :) (though this "snappy" fails anyway). Just build the hello-world opencv snap :) | 11:16 |
| slvn | In addition to "snappy", the package "snap" is also confusing .. one should install "snapd" | 11:22 |
| jamiebennett | flexiondotorg, thats the idea, yes | 11:51 |
| kyrofa | Good morning | 11:56 |
| dpm | hm... it seems somehow 'ubuntu-core' got uninstalled from my system? | 11:58 |
| dpm | Is this a known issue, shall I just manually reinstall? | 11:58 |
| dpm | on a 16.04 desktop, that is | 11:58 |
| dpm | flexiondotorg, although I believe right now only 'home' triggers manual review in the store. 'opengl' will trigger manual review too until the store starts recognizing it | 12:00 |
| dpm | so somehow 'snap list' does not list 'ubuntu-core' for me, yet if I try to install it, snap install tells me it's already installed | 12:02 |
| dpm | and 'snap interfaces' does not list any slots available | 12:03 |
| dpm | ubuntu-core cannot be removed, either | 12:03 |
| flexiondotorg | dpm, jamiebennett Is there a 'mir' interface as an alternative to x11 and unity? | 12:05 |
| flexiondotorg | If so, is it confined? | 12:05 |
| dpm | flexiondotorg, these are the interfaces currently available: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md, but there is ongoing discussion about interfaces in general | 12:07 |
| flexiondotorg | dpm, Thanks. Understood. I thought I'd seen mention of a 'mir' interface, but I must have been mistaken. | 12:09 |
| dpm | flexiondotorg, perhaps you've seen it in a discussion here on the mailing list, but I don't think it's available | 12:09 |
| flexiondotorg | Maybe, I thought I'd seen something. | 12:10 |
| oparoz | flexiondotorg, it will probably be available once snaps replace clicks | 12:10 |
| === mcphail_ is now known as mcphail | ||
| josepht | 'snap refresh <snap>' gives me a wrapper error. I have to 'snap remove <snap>' twice to remove both revisions and then 'snap install <snap>' to get it working again. | 12:40 |
| kyrofa | josepht, any chance you had an app running when you tried to remove? | 12:45 |
| josepht | kyrofa: no | 12:45 |
| sergiusens | josepht kyrofa this happens when sideloading, I hope the fix lands soon | 12:52 |
| sergiusens | kyrofa I have gulp working btw! EOD I might get vscode working; then I'll try atom but we need to support grunt | 12:53 |
| josepht | sergiusens: ah, thanks. | 12:53 |
| kyrofa | sergiusens, yeah make sure you create bugs so we don't forget to upstream what we're working on! | 12:54 |
| sergiusens | stevebiscuit as a user, would you prefer using a nodejs snapcraft plugin with a possibility to select npm, gulp or grunt as a build driver or individual plugins for each? So we'd have a nodejs plugin (which already exists), then a gulp plugin and a grunt one? | 12:55 |
| sergiusens | kyrofa upstream? as in snapcraft? | 12:55 |
| sergiusens | kyrofa the bug report depends on stevebiscuit's output ;-) | 12:55 |
| kyrofa | sergiusens, haha, yeah | 12:55 |
| * sergiusens puts some weight on someone else | 12:55 | |
| kyrofa | sergiusens, same question to you regarding qmake for qt4 versus 5 | 12:56 |
| sergiusens | kyrofa qmake afaik is tied to Qt versions, is it not? | 13:07 |
| kyrofa | sergiusens, sort of. There are different qmake packages for each version, but the qt5 one can call the qt4 one | 13:08 |
| kyrofa | sergiusens, but maybe it would be more clear to keep them separate | 13:08 |
| sergiusens | kyrofa yeah, I'd hop on to #ubuntu-touch and ask those guys ;-) | 13:11 |
| kyrofa | sergiusens, alright | 13:11 |
| stevebiscuit | jdstrand: http://pastebin.ubuntu.com/16062943/ # AppArmor is giving a denial when starting WebDM, I think similar has already been reported? | 13:13 |
| stevebiscuit | sergiusens: I'd be tempted to see which toolchain the JS community is favouring, build a solution based on that and wait to see if there's demand for the other options | 13:15 |
| bloodearnest | jdstrand, hi there! beuno sent me your way regards finding out more about a) cgroups/namespace used to confine snaps, and b) the kernel boot/rollback process, if you've any pointer to docs? | 13:15 |
| ogra_ | i think jdstrand is out this week | 13:17 |
| stevebiscuit | ogra_: cheers for the headsup | 13:17 |
| ogra_ | stevebiscuit: try tyhicks | 13:18 |
| stevebiscuit | tyhicks: http://pastebin.ubuntu.com/16062943/ # AppArmor is giving a denial when starting WebDM, I think similar has already been reported? | 13:19 |
| stevebiscuit | ogra_: ta | 13:20 |
| sergiusens | stevebiscuit from what I am seeing, gulp and grunt are a waste of time | 13:20 |
| sergiusens | stevebiscuit used when the project target's windows as people think npm scripts need to be shell scripts | 13:21 |
| jdstrand | stevebiscuit: what version of webdm are you using? | 13:21 |
| jdstrand | ogra_: I was only out yesterday | 13:21 |
| sergiusens | stevebiscuit http://blog.keithcirkel.co.uk/why-we-should-stop-using-grunt/ | 13:22 |
| stevebiscuit | jdstrand: building from https://code.launchpad.net/webdm | 13:24 |
| sergiusens | stevebiscuit ok, I think I'm sold on separate plugins that inherit from the nodejs plugin | 13:24 |
| sergiusens | so I can deprecate the other ones in an easier fashion | 13:24 |
| ogra_ | jdstrand: oops :) | 13:24 |
| zyga | jdstrand: hey, how are you | 13:25 |
| jdstrand | bloodearnest: the documentation is all in flux. I believe that the community team (dpm) is handling updating that | 13:25 |
| jdstrand | zyga: hi, good. you? | 13:25 |
| jdstrand | bloodearnest: if you had specific questions, I might be able to help with some | 13:25 |
| zyga | jdstrand: good :-) | 13:25 |
| bloodearnest | jdstrand, ah, ok | 13:25 |
| jdstrand | stevebiscuit: I don't see snap.yaml or snapcraft.yaml in that tree. what are you using for that? | 13:25 |
| beuno | jdstrand, wasn't there a whitepaper something or another? | 13:26 |
| jdstrand | beuno: there is a whitepaper for 15.04, yes, but it wasn't ever published (I asked to have it done but don't think that ever happened) | 13:26 |
| jdstrand | beuno: the whitepaper for 16 is done except it'll need updates for GA | 13:27 |
| beuno | ah | 13:27 |
| bloodearnest | jdstrand, ok, so I've seen various mentions of cgroups and namespace usage for snaps, would like to know what cgroups/namespaces are used, and how they interact with plugs/slots | 13:27 |
| zyga | jdstrand: I read that on developer.u.c somewhere (the whitepaper) | 13:27 |
| beuno | bloodearnest, there's also apparmor | 13:27 |
| stevebiscuit | jdstrand: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/pkg/meta/snap.yaml | 13:27 |
| beuno | to complete a buzzwork bingo | 13:27 |
| bloodearnest | beuno, right, that part I understand | 13:27 |
| zyga | beuno, bloodearnest: and dbus and seccomp and udev tagging | 13:27 |
| bloodearnest | or at least, understand enough of | 13:27 |
| roadmr | at least there's no synergy! | 13:28 |
| stevebiscuit | jdstrand: it needs updating to use snapcraft and currenly has it's own build.sh | 13:28 |
| jdstrand | stevebiscuit: ah, I missed that. what are the perms of /snap/webdm/100001/snappyd? | 13:29 |
| stevebiscuit | sergiusens: so you're going to have something that can be installed via npm initially? the JS community seems intent or re-inventing *everything* in JS heh | 13:29 |
| sergiusens | stevebiscuit I am chatting from a snap that uses the nodejs plugin already ;-) | 13:30 |
| sergiusens | nodejs/npm | 13:30 |
| sergiusens | but I ignored gulp and grunt; but turns out vscode uses gulp and atom uses grunt | 13:30 |
| stevebiscuit | jdstrand: 0755. It can be run fine standalone oddly | 13:30 |
| jdstrand | stevebiscuit: sorry, what is the ownership | 13:31 |
| stevebiscuit | jdstrand: it's owned by ubuntu:ubuntu | 13:32 |
| jdstrand | stevebiscuit: ok, that is your problem. how are you building your snap? | 13:32 |
| jdstrand | dholbach: note, https://developer.ubuntu.com/en/snappy/guides/security/ is terribly out of date | 13:32 |
| jdstrand | dpm: ^ | 13:33 |
| dholbach | jdstrand, yes, we're on it | 13:33 |
| dholbach | AFAICT it's not more than 2 weeks out of date | 13:33 |
| stevebiscuit | jdstrand: it's still being built with sergiusens origional build.sh, I've not yet looked into what it needs to be moved to using snapcraft | 13:33 |
| jdstrand | dholbach: zyga mentioned the 15.04 security whitepaper was on developer.u.c. I can't seem to find it. do you know where it is? | 13:33 |
| dholbach | jdstrand, no, I don't think it ever was on there | 13:33 |
| jdstrand | stevebiscuit: ok, let me look at that real quick | 13:33 |
| ogra_ | you need to at least use snapcraft snap instead of snappy build | 13:34 |
| zyga | that was a while ago | 13:34 |
| jdstrand | stevebiscuit: right, build.sh is using 'snappy build $builddir' | 13:34 |
| jdstrand | stevebiscuit: I think if you change that to 'snapcraft snap $builddir' it should work | 13:35 |
| stevebiscuit | jdstrand: cool, I've give that a whirl | 13:35 |
| thomas25 | Hi | 13:37 |
| jdstrand | bloodearnest: I shared the link with you | 13:37 |
| jdstrand | bloodearnest: for 16 | 13:38 |
| jdstrand | bloodearnest: note in general most things should be all settled, but there might be a few things that will change (nothing architecturally) | 13:38 |
| jdstrand | bloodearnest: but for the benefit of people in this channel, Ubuntu Core uses a combination of technologies to implement the sandbox. the heart is apparmor, but we also use seccomp, device cgroups, private /tmp and devpts newinstance | 13:39 |
| bloodearnest | jdstrand, great, thanks! | 13:40 |
| thomas25 | Hi | 13:41 |
| jdstrand | bloodearnest: the only namespace is the mount namespace for /tmp. we chose to implement the snadbox in this manner because it allows snaps to integrate more fully with the system and to better interact with each other. for people wanting full containers, people can use lxd or docker (though atm neither is available on 16, but will be before GA) | 13:41 |
| thomas25 | I have a question about the configuration file | 13:41 |
| thomas25 | How are they handle since the snaps are read only | 13:42 |
| jdstrand | tyhicks: fyi, in case you didn't notice, I answered stevebiscuit | 13:42 |
| thomas25 | I tried the mosquitto snap but I can't edit the mosquitto.conf file. | 13:42 |
| bloodearnest | jdstrand, right, I assumed a fairly limited namespace usage, was just looking for details | 13:42 |
| jdstrand | thomas25: I'll answer since I happened to have seen the question. In general, the snap would be set up to copy the configuration file from $SNAP to $SNAP_DATA and have the daemon use the file in $SNAP_DATA so that the file is then readable. I don't know how mosquitto is packaged though | 13:43 |
| ogra_ | thomas25: there used to be a "snap config" command that would use the conf as input and put it into the writable space ... that is temporarily gone and being re-worked | 13:44 |
| thomas25 | ok thanks | 13:44 |
| sergiusens | thomas25 mosquitto from snapcraft sources? | 13:44 |
| thomas25 | yes | 13:45 |
| sergiusens | that is just an example, not meant to be configurable afaik | 13:45 |
| jdstrand | bloodearnest: if you want the implementation details of what we do with the devices cgroup, see http://bazaar.launchpad.net/~snappy-dev/ubuntu-core-launcher/trunk/view/head:/README | 13:45 |
| ogra_ | boo | 13:45 |
| sergiusens | you can add the smarts for it thought (like have it read from SNAP_DATA or SNAP_USER_DATA) | 13:45 |
| sergiusens | ogra_ the examples are also a stress tester for snapcraft itself; not for snaps | 13:45 |
| sergiusens | ogra_ I wish the core guys wrote more snaps as that would really make sure the system is good | 13:46 |
| jdstrand | I should have said "is then *writable*" | 13:46 |
| ogra_ | they will come over time :) | 13:46 |
| thomas25 | SNAP_DATA nad SNAP_USER_DATA are used to override the path of configuration file in snaps ? | 13:48 |
| bloodearnest | jdstrand, thanks! already skimming the whitepaper has answers most of my questions! :D | 13:48 |
| jdstrand | cool | 13:48 |
| kyrofa | thomas25, this question might help: https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data | 13:48 |
| thomas25 | Or the snap just copy the configuration file in SNAP_DATA path ? | 13:49 |
| ogra_ | thats up to you :) | 13:49 |
| ogra_ | the snap only provides the path ... weather you copy it and make your service use it is up to you | 13:50 |
| ogra_ | (you could ship an immutable config just in the readonly dir and not allow the user to alter it at all) | 13:50 |
| thomas25 | In the snapcraft.yaml how to you say that this goes to SNAP_DATA and that in SNAP_USER_DATA ? | 13:53 |
| thomas25 | Just using "copy" plugin ? | 13:54 |
| ogra_ | no, you would write a wrapper that does the copying for you on service startup | 13:54 |
| sergiusens | kyrofa with great pleasure I deliver this bug to you https://bugs.launchpad.net/bugs/1575188 ;-) | 13:55 |
| ubottu | Launchpad bug 1575188 in Snapcraft "Fix for bug #1572664 had broken my snap package build" [Undecided,New] | 13:55 |
| kyrofa | sergiusens, yes I just saw that come in | 13:55 |
| kyrofa | sergiusens, thanks :P | 13:56 |
| thomas25 | ogra_: Thanks | 13:56 |
| sergiusens | kyrofa while the snapping might work, not sure it would ever be accepted by the store with so many dead symlinks | 13:56 |
| kyrofa | sergiusens, yeah might be a question for beuno | 13:57 |
| sergiusens | jdstrand rather | 13:57 |
| sergiusens | I'm sure it won't | 13:57 |
| kyrofa | sergiusens, so is this a wontfix, or should the review tools change? | 13:58 |
| sergiusens | kyrofa I'd ask him if the review tools passed without warnings in his previous working snaps | 13:58 |
| kyrofa | sergiusens, alright :) | 13:59 |
| === zyga_ is now known as zyga | ||
| asac | the pi2 really has no reset button right? (or do i need glasses?) | 14:14 |
| zyga | asac: it has no buttons at all AFAIK | 14:15 |
| zyga | looking at mine now | 14:15 |
| asac | good :) | 14:15 |
| ogra_ | you can use a strobe light to reset it though | 14:15 |
| josepht | lol | 14:15 |
| zyga | heheh | 14:15 |
| zyga | we need strobe interface | 14:15 |
| asac | hehe | 14:16 |
| asac | maybe i should use my ttl power and then i can use some tricks with /dev/ttyUSB to repower? | 14:16 |
| zyga | asac: whad are you trying to do? | 14:16 |
| asac | just rebooting | 14:17 |
| asac | without having to fiddle myself through 5 layers of cables :) | 14:17 |
| asac | hoping to not unplug some other board or ttl | 14:18 |
| asac | ok installing hello-0world to look at hello-world.sh | 14:18 |
| asac | to see what is going on | 14:18 |
| asac | nice | 14:18 |
| asac | doesnt work :) | 14:18 |
| asac | bah the pi2 kernel really always get a reset by peer | 14:19 |
| asac | so i cannot even try the latest | 14:19 |
| asac | error: cannot perform the following tasks: | 14:19 |
| asac | - Download snap "canonical-pi2-linux" from channel "stable" (read tcp 10.42.0.95:56112->69.88.149.140:443: read: connection reset by peer) | 14:19 |
| ogra_ | you really dont make friends with that nordic guy today eh ? | 14:20 |
| asac | hehe | 14:20 |
| asac | he seems to not like the pi2 | 14:20 |
| ogra_ | i just built aa set of images here | 14:20 |
| asac | db worked fine | 14:20 |
| ogra_ | no issues | 14:20 |
| asac | to update | 14:20 |
| asac | hmmmmmmm | 14:20 |
| asac | think its only when you use it from the device | 14:20 |
| asac | not during udf | 14:21 |
| zyga | yep, same here | 14:21 |
| ogra_ | hmm | 14:21 |
| zyga | asac: are you on 3g? | 14:21 |
| ogra_ | lol | 14:21 |
| asac | no stble landline | 14:21 |
| asac | super stable | 14:21 |
| zyga | 4g :-) ? | 14:21 |
| asac | 5L | 14:21 |
| asac | : | 14:21 |
| asac | :P | 14:21 |
| ogra_ | who would do a kernel update of his pi2 over 3G ? | 14:21 |
| zyga | super proxy in betweeen to read your mail? | 14:21 |
| asac | not that i know | 14:21 |
| zyga | hmm | 14:21 |
| asac | i am direct | 14:21 |
| * zyga looks from device | 14:21 | |
| asac | its really something else | 14:22 |
| asac | but the device goes through my desktop | 14:22 |
| asac | e.g. connection share | 14:22 |
| asac | so could be due to that | 14:22 |
| zyga | hmm, all up-todate | 14:22 |
| zyga | ahh | 14:22 |
| asac | let me think | 14:22 |
| zyga | maybe, try direct | 14:22 |
| asac | have no lan | 14:22 |
| asac | but i never had problems | 14:22 |
| zyga | until today ;) AFAIR n-m doesn't use a proxy but I might be wrong | 14:23 |
| asac | no it doesnt | 14:23 |
| asac | its pure routing | 14:23 |
| asac | too bad nothing works on image so i cannot download a big iso to see | 14:23 |
| asac | i am sure that would work :) | 14:23 |
| asac | well not so | 14:23 |
| asac | let me get a wget | 14:23 |
| asac | oh i have chroots | 14:24 |
| asac | let me try there | 14:24 |
| ogra_ | snap install doesnt work either ? | 14:24 |
| asac | for instance i had zero issues setting up those chroots | 14:24 |
| zyga | works for me | 14:24 |
| zyga | just tried on pi2 | 14:24 |
| zyga | image built yesterday | 14:24 |
| asac | ok wget http://cdimage.ubuntu.com/ubuntu-core/releases/xenial/release/ubuntu-core-16.04-core-amd64.tar.gz is running | 14:25 |
| asac | wget finished | 14:25 |
| * zyga goes to pick up kids from school | 14:25 | |
| asac | no issues | 14:25 |
| asac | ogra_: tells me its already installed | 14:26 |
| ogra_ | asac, i mean a random snap | 14:26 |
| * asac tries | 14:26 | |
| asac | yeah nmap gives me same error | 14:27 |
| asac | xkcd-webserver works | 14:27 |
| asac | install mvos image, try refresh | 14:28 |
| asac | not working | 14:28 |
| ogra_ | weird | 14:29 |
| oparoz | Is it asking for trouble if bundling python 2.7 in a snap? | 14:52 |
| ogra_ | just use snapcrafts python plugin | 14:52 |
| oparoz | ogra_, I don't need to build anything in python, it's just that dtrx needs python 2.7 | 14:53 |
| oparoz | ogra_, So I'm just wondering what should be done for such scripts | 14:54 |
| ogra_ | using the python plugin ;) | 14:54 |
| ogra_ | it makes sure the right bits get bundled | 14:54 |
| ogra_ | there was some trick to only get the interpreter ... | 14:54 |
| ogra_ | source: . | 14:55 |
| ogra_ | or some such | 14:55 |
| oparoz | ogra_, So you mean, not use the deb, but the source archive? | 14:55 |
| ogra_ | no, define a snapcraft part that uses the python plugin | 14:55 |
| ogra_ | in your snapcraft.yaml | 14:55 |
| oparoz | and use the deb as a staging deb | 14:55 |
| ogra_ | which deb ? | 14:55 |
| oparoz | dtrx | 14:55 |
| ogra_ | oh | 14:56 |
| ogra_ | yeah, with teh copy plugin or so | 14:56 |
| oparoz | The problem is how to run it on the other side | 14:56 |
| oparoz | But I'm guessing Snapcraft will include python2.7 | 14:56 |
| oparoz | Thus my question whether it's a good idea since python 3 is already present | 14:57 |
| oparoz | Because the script calls /usr/bin/python | 14:58 |
| ogra_ | well, what does the deb depend on ? | 14:58 |
| oparoz | Depends: python (>= 2.7), python (<< 2.8), bzip2, unzip, cpio, rpm, binutils, p7zip-full, cabextract, unshield, lzma, xz-utils | 14:58 |
| ogra_ | smaller than 2.8 ... | 14:58 |
| ogra_ | there you got your answer :) | 14:58 |
| oparoz | OK, so Snapcraft will ship Python2.7 and create a wrapper which points /usr/bin/python to /usr/bin/python2.7 ? | 14:59 |
| ogra_ | i dont know, thats a sergiusens or kyrofa question :) | 15:00 |
| kyrofa | ogra_, oparoz if python is pulled in via stage-packages snapcraft won't do anything special | 15:00 |
| ogra_ | but i think it replaces the shebang line in all py scripts it finds | 15:00 |
| ogra_ | kyrofa: no, via the python plugin | 15:00 |
| oparoz | kyrofa, Ah, then the script will fail in the snap | 15:01 |
| kyrofa | Ah, but ogra_ is right-- the shebangs should be fixed via the stage-packages | 15:02 |
| oparoz | Ah, no, the default in core is 2.7, so I'm guessing v3 scripts in debs use /python3 | 15:03 |
| oparoz | kyrofa, Ah, that's good if snapcraft fixes shebangs | 15:03 |
| kyrofa | oparoz, should be replaced with "#!/usr/bin/env python" | 15:04 |
| oparoz | kyrofa, OK and the wrapper will provide the correct env | 15:04 |
| ogra_ | yeah | 15:05 |
| kyrofa | oparoz, assuming you're using the python plugin, yeah | 15:05 |
| oparoz | OK, I'm going to try that and see if it works, thanks | 15:05 |
| sergiusens | python is very unflexible about installation paths which is sad for such a flexible language in itself | 15:05 |
| ogra_ | wobbly-python :) | 15:06 |
| oparoz | :D | 15:07 |
| _morphis | zyga: whats with the changes you did for the bluez itnerface? did jdstrand review them? | 15:19 |
| jdstrand | I wanted to sync on that today. I'm not sure what is expected at this point | 15:19 |
| ogra_ | will be interesting to see what happens if you install it on a desktop :) | 15:20 |
| jdstrand | that's another converstation that needs to be had. sdoc interfaces vs core interfaces | 15:22 |
| seb128 | jdstrand, hey, I think you had a go at making at snap from gnome-calculator, is your work available somewhere? we are at a sprint and would like to have a look to start tomorrow, would be nice to restart from scratch if you resolved some of the issues already though | 15:25 |
| jdstrand | seb128: I tried, it failed. I talked to dsert and he gave some tips but I was unable to continue. someone I think last week was trying something similar and so I gave my notes. let me find that | 15:26 |
| seb128 | jdstrand, thanks | 15:27 |
| jdstrand | seb128: this is the branch (note, it is horrible) -- lp:~jdstrand/+junk/gnome-calculator . Still digging up notes | 15:31 |
| seb128 | jdstrand, thanks | 15:32 |
| jdstrand | right, it was sergiusens I talked to about it | 15:32 |
| jdstrand | seb128: http://paste.ubuntu.com/15923754/ | 15:32 |
| seb128 | sergiusens, ^ did you look more into that one (before we dup work)? | 15:33 |
| jdstrand | seb128: sergiusens was looking at snapping firefox (which is gtk) and I gave him those notes. not sure how much farther he got if at all | 15:33 |
| seb128 | jdstrand, thanks, hopefully we can move things forward at the sprint this week | 15:33 |
| jdstrand | cool | 15:33 |
| sergiusens | seb128 no I haven't | 15:34 |
| jdstrand | though I imagine you're going to need some interfaces work. I was trying to get it to a point where I could look at that, but couldn't at first and then was busy helping with interfaces/etc for release | 15:34 |
| seb128 | sergiusens, no worry | 15:35 |
| jdstrand | so a working snap in --devmode would be great | 15:35 |
| seb128 | right | 15:35 |
| _morphis | jdstrand: not sure, zyga just said he wanted your eyes on what we he implemented | 15:36 |
| jdstrand | I thought I did that... | 15:36 |
| _morphis | jdstrand: https://github.com/ubuntu-core/snappy/pull/1037#issuecomment-214386816 | 15:37 |
| * jdstrand looks at the PR again | 15:37 | |
| _morphis | jdstrand: hah, sounds like we're deadlocking :-) | 15:37 |
| jdstrand | _morphis: I need zyga to comment. I gave zyga a patch for him to build off of. I haven't seen anything else | 15:38 |
| _morphis | jdstrand: he implemented https://github.com/zyga/snappy/commit/16228ad739da17d0ff975a1d781db4a53dfdbc79 | 15:38 |
| jdstrand | _morphis: ok, commented in both | 15:44 |
| _morphis | jdstrand: thanks | 15:44 |
| _morphis | jdstrand: didn't looked through the snappy code yet for this, but isn't there an easy way to figure the plug name? | 15:45 |
| jdstrand | _morphis: not at that point in the code | 15:45 |
| _morphis | jdstrand: ok | 15:46 |
| _morphis | ssweeny: can you pull those changes in from zyga? | 15:46 |
| _morphis | jdstrand: will implement the same for networkmanager tomorrow | 15:46 |
| jdstrand | _morphis: that is the bit that zyga needed to look at (I gave him a similar patch as the commit which he was going to work off of to get the app name, which isn't available in any of the structures in that function atm) | 15:46 |
| ssweeny | _morphis, already pulled them locally and tested them | 15:46 |
| ssweeny | _morphis, pushing now | 15:46 |
| _morphis | ssweeny: awesome! | 15:47 |
| jdstrand | please add a FIXME comment though | 15:47 |
| _morphis | jdstrand: could you have a look on the minimize dbus policy at https://github.com/ubuntu-core/snappy/pull/1036 too? | 15:48 |
| _morphis | jdstrand: will add the same changes we're doing for security label tomorrow | 15:48 |
| ssweeny | jdstrand, it should end up as "snap.bluez." ? | 15:48 |
| ssweeny | trying to parse the punctuation in your comment | 15:48 |
| jdstrand | ssweeny: what 'it' are you referring to? | 15:50 |
| jdstrand | the future fix or the current implementation? | 15:50 |
| jdstrand | current proposed* implementation | 15:51 |
| jdstrand | _morphis: commented | 15:51 |
| _morphis | jdstrand: thanks | 15:52 |
| ssweeny | jdstrand, I mean, should the comment be "FIXME: this glob turns into snap.bluez.* where it *SHOULD* be snap.bluez." | 15:52 |
| jdstrand | ssweeny: 'where it *SHOULD* be snap.bluez.<app>' | 15:54 |
| ssweeny | jdstrand, ok that's what I wanted to understand | 15:55 |
| jdstrand | ssweeny: also, really, it should say 'where it *SHOULD* be snap.<name>.<app>' | 15:55 |
| ssweeny | jdstrand, I think your <app> got lost in the comment | 15:55 |
| jdstrand | ah | 15:55 |
| * jdstrand shakes fist at github | 15:55 | |
| ogra_ | what do you expect from a site that requires flash to provide you tarballs of the trees :P | 15:56 |
| jdstrand | ssweeny: fixed github comment | 15:56 |
| mvo | jdstrand: snappy-debug is your baby, right? would be nice to have an update for 16 - looks like it is using old-security, anything we can do in the short term with it? do we have an interface that works ? | 15:58 |
| jdstrand | mvo: it is completed broken | 15:59 |
| mvo | jdstrand: and we can not bring it back because it has to be unconfined? | 15:59 |
| jdstrand | mvo: it has to be rewritten. best to remove it at the moment | 15:59 |
| jdstrand | the tool itself is broken | 15:59 |
| jdstrand | interfaces moved all policy into go and so there is nothing to grep | 16:00 |
| mvo | jdstrand: oh, I see | 16:00 |
| mvo | jdstrand: ok, I updated the bug about it (doing triage now and stumbled over this one) | 16:00 |
| jdstrand | is it in 16? | 16:00 |
| jdstrand | I didn't ask for it to be there | 16:01 |
| jdstrand | once it is rewritten it should work with log-observe | 16:01 |
| jdstrand | but that isn't autoconnected | 16:01 |
| jdstrand | mvo: ^ | 16:02 |
| mvo | jdstrand: its not in 16 | 16:02 |
| jdstrand | ok | 16:02 |
| mvo | jdstrand: there is a bug that its broken in rolling and I was checking the state | 16:02 |
| jdstrand | are you taking my irc comments and putting them in the bug? | 16:03 |
| jdstrand | or shall I? I can, but what is the bug number? | 16:03 |
| mvo | jdstrand: I will add them | 16:06 |
| slvn | hello. I'm trying to build/install my first snap package. I use SDL2 which needs to access "libmirclient". After building, "libmirclient" is not in my "/snap/mytest/current/..." whereas libSDL2 is. I think I should set a magic line in cmake to install it ? any idea ? | 16:06 |
| mvo | jdstrand: https://bugs.launchpad.net/snappy/+bug/1543118 | 16:06 |
| ubottu | Launchpad bug 1543118 in Snappy "Snappy-debug installation on 16" [Wishlist,Triaged] | 16:06 |
| jdstrand | mvo: thanks! fwiw, this is the next thing I will move to after various interfaces work | 16:07 |
| mvo | jdstrand: ta | 16:07 |
| sergiusens | jdstrand can I invoke your wisdom http://pastebin.ubuntu.com/16065450/ ? | 16:14 |
| sborovkov | ogra_: Hello, are there still 2 gadget snaps for rpi? | 16:15 |
| sergiusens | jdstrand oh, seems to not be related to security; crashes with --devmode too | 16:16 |
| sergiusens | I guess I need to do some sort of gtk dance | 16:16 |
| ogra_ | sborovkov: yes, canonical-pi2 and canonical-pi3 | 16:16 |
| ogra_ | they share the canonical-pi2-linux kernel package | 16:16 |
| jdstrand | I'll still add those denials as something to consider | 16:17 |
| * jdstrand is gathering a list | 16:17 | |
| ogra_ | sergiusens: videos though, or it didnt happen | 16:17 |
| ogra_ | i guess seb128 knows the exact steps for all gkt dances | 16:18 |
| ogra_ | *gtk | 16:18 |
| sergiusens | yeah, it might not be gtk | 16:18 |
| sergiusens | ogra_ jdstrand I'm running into this code path https://chromium.googlesource.com/chromium/src/+/lkgr/crypto/nss_util.cc#206 | 16:18 |
| ogra_ | uh, nss | 16:19 |
| jdstrand | sergiusens: you might ask ChrisCoulson if he knows anything about that chunk of code. I have a feeling he had to work with that before with webapp-container | 16:20 |
| jdstrand | (as webapp-container relates to oxide) | 16:20 |
| sergiusens | jdstrand yeah, it will be a hard fix as this is electron | 16:29 |
| sergiusens | necessary though as all apps are written with this now :-) | 16:30 |
| ogra_ | "all apps" | 16:30 |
| sborovkov | ogra_: so for RPI2 and RPI3 different images will need to be built always? | 16:45 |
| ogra_ | sborovkov: unless ppisati made the uboot binary work on both, yes ... the pi3 uboot breaks the pi2 serial | 16:46 |
| ogra_ | i'll look into an arm64 build too in the near future | 16:47 |
| ogra_ | so there might even be a third gadget | 16:47 |
| === chihchun_afk is now known as chihchun | ||
| sborovkov | Is it possible to mount directory with binaries instead of squashfs temporarily? So that I have write access but still run inside of the snap | 16:52 |
| * ogra_ doesnt understand that question | 16:56 | |
| ogra_ | you can only deliver snaps as squashfs ... so there is no way to make the snap itself writable | 16:57 |
| ogra_ | you can mount overlays on top of files manually i guess ... for temporary changes and tests | 16:57 |
| sborovkov | ogra_: yeah, I don't want to deliver, just to be able to make quick changes locally | 16:58 |
| zyga | _morphis: not that I know of yet, could you push them to the branch so that they appear in the pull request? | 17:31 |
| zyga | test | 17:43 |
| * zyga wonders if this works | 17:43 | |
| zyga | jdstrand: hey, around? | 17:46 |
| jdstrand | zyga: yes, hi | 17:58 |
| zyga | jdstrand: hey | 17:58 |
| zyga | jdstrand: I sent a pull request the other day, that changed the x11 interface | 17:58 |
| sborovkov | zyga: Hello, do you have any time estimations when RPI interfaces going to be in? If not - is that a difficult change to do to allow access to /dev/vchiq and may be I could it myself then? | 17:58 |
| zyga | jdstrand: I also made a change to bluez but I'm not sure if you've seen that | 17:59 |
| zyga | sborovkov: hey, no estimate yet, our focus is on devices but I'm sure I'll be split between desktop and iot world for now | 17:59 |
| zyga | sborovkov: I can guide you with interface work, I will gladly review and merge new interfaces | 17:59 |
| zyga | jdstrand: https://github.com/zyga/snappy/commits/bluez-fix-rules | 18:00 |
| sborovkov | zyga: ah, alright cool, could you point me to the source code of some similar interface may be? | 18:00 |
| zyga | jdstrand: https://github.com/zyga/snappy/commit/e0f7f3bec17b0f33f3aaf4fa0c0f4273c98a788a | 18:00 |
| zyga | sborovkov: there aren't any yet, please familarize yourself with the two articles I've published on interfaces already, I have the third one half-written (specifically about how interfaces work internally), reading interfaces/core.go would be useful | 18:01 |
| sborovkov | zyga: Ok | 18:02 |
| jdstrand | zyga: I commented on https://github.com/zyga/snappy/commit/16228ad739da17d0ff975a1d781db4a53dfdbc79 a few minutes ago | 18:02 |
| * zyga looks | 18:02 | |
| jdstrand | (https://github.com/zyga/snappy/commits/bluez-fix-rules) | 18:02 |
| zyga | jdstrand: replied | 18:03 |
| jdstrand | zyga: I didn't see the x11 PR. where is it? (I didn't see the bluez one either until _morphis pointed it out to me) | 18:03 |
| zyga | jdstrand: trying to find the pull request | 18:03 |
| zyga | https://github.com/ubuntu-core/snappy/pull/1069 | 18:04 |
| zyga | jdstrand: mvo merged it | 18:04 |
| jdstrand | zyga: replied to your question | 18:06 |
| jdstrand | zyga: getsockname is fine | 18:07 |
| zyga | jdstrand: I think we need a protocol to ensure that in the future all such requests are acked by you before they land | 18:07 |
| jdstrand | I agree. we said before that any changes to policy should go through the security team | 18:07 |
| jdstrand | its fine if that is me for now, but it could be anyone on the team once things settle a bit | 18:08 |
| jdstrand | it's | 18:08 |
| zyga | jdstrand: thanks for clarifying the bluez patch, I will fix it shortly! | 18:08 |
| jdstrand | np, thank you! :) | 18:09 |
| zyga | jdstrand: offtopic, can we do a pulseaudo interface so that games can have sound :) | 18:09 |
| jdstrand | well, that is a very interesting conversation | 18:09 |
| jdstrand | cause it brings out a problem we have | 18:09 |
| zyga | (perhaps just for playback as 1st attempt) | 18:09 |
| zyga | auto-connect? | 18:09 |
| jdstrand | Ubuntu Core systems vs sdoc | 18:09 |
| zyga | sdoc? | 18:09 |
| jdstrand | which we are seeing already | 18:09 |
| jdstrand | snappy dimension on classic | 18:10 |
| zyga | ah | 18:10 |
| jdstrand | snappy on desktop | 18:10 |
| zyga | yes, I see | 18:10 |
| zyga | same with network-manager and pulseaudio really | 18:10 |
| zyga | and bluez | 18:10 |
| jdstrand | for example, we have a bluez interface, about to have nm and pulseaudio | 18:10 |
| jdstrand | yeah | 18:10 |
| jdstrand | you see what I'm getting out | 18:10 |
| zyga | I was thinking that we should auto-create the slots on desktop systems and not create them on IOT systems | 18:10 |
| jdstrand | the interfaces are with slots/plugs snaps in mind | 18:10 |
| jdstrand | but classic has these as debs | 18:10 |
| ogra_ | and if my IOT wants to use sound notifications ? | 18:10 |
| jdstrand | ogra_: then you install the pulseaudio snap | 18:11 |
| zyga | I think the value should be that the interface is the same (if you have pulse snap) | 18:11 |
| ogra_ | jdstrand: and that provides the same interface ? | 18:11 |
| jdstrand | zyga: I'm not so sure | 18:11 |
| zyga | and the same client snap would work on desktop (with deb based pulseaudio) and on iot with a pulse snap | 18:11 |
| jdstrand | ogra_: that is the question | 18:11 |
| zyga | no? | 18:11 |
| ogra_ | heh | 18:11 |
| zyga | eeek, no power | 18:11 |
| zyga | brb | 18:11 |
| ogra_ | get an M10 ! | 18:12 |
| jdstrand | traditional desktop apps might use things in pulseaudio that we wouldn't want to allow to apps | 18:12 |
| jdstrand | for example | 18:12 |
| jdstrand | pulseaudio has a socket interface and a dbus interface | 18:12 |
| jdstrand | on touch, we only allow access to one because the other is dangerous | 18:12 |
| ogra_ | yeah | 18:12 |
| jdstrand | so, core systems might want a different policy than classic systems | 18:12 |
| zyga | ogra_: I'm not sure it could replace my activities today, I'm tempted to see how it plays out at the upcoming sprint | 18:12 |
| zyga | jdstrand: ok, simplifying this for now, I'd like a sound interface that works for 80% of the desktop games out there | 18:13 |
| ogra_ | zyga: well, it is good if you do a lot on remote machines ... i doubt i'd want to use it for loacl image builds or so :) | 18:13 |
| zyga | jdstrand: because that's a vaiable target for snappy today and because it's a good thing to have :) | 18:13 |
| jdstrand | zyga: obviously I'm not saying no to accessing pulseaudio. I'm just saying all this brings up questions | 18:13 |
| zyga | ogra_: I hack on snappy | 18:13 |
| ogra_ | mail, irc, browsing and terminals definitely work fine ... and it lasts a good 16-18h | 18:13 |
| zyga | jdstrand: yes, but I think we have to be pragmatic, we should populate 16.04 with useful desktop interfaces rapidly | 18:14 |
| ogra_ | zyga: and ? | 18:14 |
| zyga | ogra_: and nothing else, I use udf to build snap images | 18:14 |
| zyga | ogra_: not heavyweight | 18:14 |
| ogra_ | zyga: i hack on all sorts of stuff ... rarely on teh machine i'm typing on :) | 18:14 |
| jdstrand | zyga: no one is arguing that. I think a conversation with niemeyer would be worthwhile though :) | 18:14 |
| zyga | ogra_: I don't want two machines, tried that, went back to one | 18:14 |
| zyga | jdstrand: no disagreements there :) | 18:14 |
| jdstrand | my inclination is actually maybe put these in unity7, or maybe unity7-audio | 18:15 |
| jdstrand | and leave pulseaudio interface as a proper interface for a pulseaudio snap | 18:15 |
| zyga | ogra_: I'd be sold iff I could get usable editor (vim) with my settings and ability to run it without squinting my eyes in the terminal | 18:15 |
| zyga | ogra_: assuming I can do a xenial chroot | 18:15 |
| ogra_ | yeah | 18:15 |
| zyga | jdstrand: hmm, interesting | 18:15 |
| ogra_ | and even natively ... | 18:16 |
| zyga | jdstrand: I'm sure we'll bring this up at the sprint | 18:16 |
| jdstrand | zyga: because these are all of the 'classic desktop' persuasion and shoehorning stuff that wasn't designed for snappy | 18:16 |
| zyga | asac: offtopic, I just built the bbb image | 18:16 |
| jdstrand | zyga: on an image that isn't ubuntu core plus a bunch of magical dbus things that appear to be from no where (from the app's perspective) | 18:17 |
| jdstrand | anyway, niemeyer said he is back tomorrow I think. we can pick it up then | 18:18 |
| zyga | yep | 18:18 |
| sergiusens | jdstrand ok, so my vscode snap turns out to fail even when running locally but preferring the libraries from the snap; coincidentally most of them are glib/gtk ones ;-) | 18:22 |
| jdstrand | interesting | 18:22 |
| zyga | sergiusens: once we make it work, do we sent that to microsoft to release? | 18:23 |
| sergiusens | zyga yeah, I already learned gulp and created a `snap` target and have snapcraft.yaml fully building | 18:24 |
| sergiusens | it just doesn't work ;-) | 18:24 |
| zyga | sergiusens: does a pre-made binary work? | 18:24 |
| sergiusens | zyga I don't think so; the electron binary is prebuilt (fetched from the build system) | 18:25 |
| sergiusens | zyga and the `snap` works as long as ld_library_path (toup()) is not set to point to the snap | 18:25 |
| zyga | sergiusens: any idea what the problem is/ | 18:25 |
| zyga | hmm | 18:25 |
| zyga | rpath? | 18:26 |
| sergiusens | zyga I suspect it is gtk initialization | 18:26 |
| zyga | sergiusens: did you try to snap the gtk demo app with all the widgets? | 18:26 |
| sergiusens | zyga no; gtk is black magic to me | 18:27 |
| sergiusens | zyga you try ;-) | 18:27 |
| zyga | sergiusens: why? :) | 18:27 |
| zyga | sergiusens: I can try on Friday | 18:27 |
| sergiusens | zyga ask jdstrand :-) | 18:27 |
| zyga | jdstrand: ^^ :-) | 18:27 |
| jdstrand | ask me? | 18:28 |
| zyga | (I want to know what I'm getting into) | 18:28 |
| jdstrand | I'm no gtk guru | 18:28 |
| jdstrand | seb128 is sprinting this week and are going to look at this stuff | 18:28 |
| sergiusens | jdstrand I didn't tell him to ask you to do it, but rather how your endeavour came through ;-) | 18:28 |
| jdstrand | I suggest talking to him | 18:28 |
| jdstrand | oh | 18:28 |
| jdstrand | my endeavor failed | 18:28 |
| zyga | hehe | 18:29 |
| zyga | in what way? | 18:29 |
| sergiusens | from the looks of it; there are more vars than for Qt and there are dependencies on fixed paths | 18:29 |
| jdstrand | I was able to start the calc without crashing, but menus, themes, gsettings, etc all failed | 18:29 |
| zyga | gtk loves to have various processes | 18:29 |
| zyga | I wonder what the approach should be | 18:29 |
| zyga | isolate each snap | 18:29 |
| zyga | or have them see a part of gtk (daemons) | 18:30 |
| zyga | from the system | 18:30 |
| zyga | e.g. themes will be a problem otherwise, I don't know what qt does here | 18:30 |
| zyga | (apart from fully-skinned apps) | 18:30 |
| jdstrand | zyga: note, I talked to dsert about this a bit a while ago, but couldn't go farther due to other snappy work. I forwarded that conversation to seb128: http://paste.ubuntu.com/15923754/ | 18:30 |
| zyga | I suspect gtk will need a few patches to love $SNAP first | 18:31 |
| jdstrand | that would not surprise me | 18:31 |
| * ogra_ whispers "static builds" | 18:31 | |
| sergiusens | reason I love go ogra_ | 18:32 |
| sergiusens | just drag and drop! | 18:32 |
| ogra_ | so just do it in go-gtk :) | 18:33 |
| ogra_ | trivial ... just port the app :P | 18:33 |
| sergiusens | ogra_ go-gtk dyn links against gtk | 18:33 |
| ogra_ | lol | 18:33 |
| sergiusens | it would have to be an api compatible rerwite using Qt underneath ;-) | 18:33 |
| zyga | ogra_: what's the battery life like on m10? | 18:41 |
| ogra_ | zyga: i'm at 60% after doing 6h of constant work on it | 18:42 |
| zyga | ogra_: wow, what perhiperhials are you using? | 18:43 |
| zyga | ogra_: do you have a screen attached? | 18:43 |
| ogra_ | and i have a bunch of apps excluded from lifecycle mgmt ... meaning it actually consumes more than a default system | 18:43 |
| ogra_ | only a k480 Bt keyboard | 18:44 |
| zyga | ogra_: no mouse? | 18:44 |
| zyga | ogra_: do you work with the only screen being the 10" tablet? | 18:44 |
| ogra_ | nah | 18:44 |
| ogra_ | yep | 18:45 |
| zyga | ogra_: man, you must have good eyes | 18:45 |
| zyga | ogra_: how do you physically keep it in place on your desk? any stands/arms holding it? | 18:45 |
| zyga | ogra_: I was wondering if I'd switch to that device entirely or just use it in addition to my laptop | 18:49 |
| sergiusens | zyga jdstrand GI is s glib/gtk thing, right? http://pastebin.ubuntu.com/16069260/ | 18:50 |
| ogra_ | zyga: http://i.imgur.com/apYL565.png | 18:51 |
| zyga | looks like gobject introspection | 18:51 |
| zyga | ogra_: it looks big on my 15" screen ;) | 18:51 |
| zyga | hmm | 18:51 |
| ogra_ | heh | 18:51 |
| jdstrand | glib, yes | 18:52 |
| zyga | I wonder if someone could come up with hdmi-over-ethernet snap for x86 boxes | 18:52 |
| zyga | pick old laptop | 18:52 |
| zyga | install that snap | 18:52 |
| zyga | and use it as a networked monitor | 18:52 |
| zyga | use modern hw with all the spare "monitors" :) | 18:52 |
| sergiusens | ogra_ what chat app is that | 18:53 |
| ogra_ | kiwi | 18:53 |
| ogra_ | excluded from lifecycle | 18:53 |
| ogra_ | the app from the store | 18:54 |
| zyga | how do you do that? | 18:54 |
| zyga | I was actually thinking that lifecycle elision would be a nice interface | 18:54 |
| zyga | I'm sure we'll have to solve a lot of very interesting cases before phone and snappy merge | 18:54 |
| ogra_ | its a gsettings key that takes a list of app ids | 18:54 |
| zyga | ah | 18:55 |
| ogra_ | i got dekko, kiwi and the terminal added there | 18:55 |
| sergiusens | ogra_ why dekko? | 18:56 |
| sergiusens | I use dekko all the time, never had the need to exclude it from lc | 18:56 |
| ogra_ | because my mailserver is a single core machine running off a 4200rpm disk | 18:56 |
| zyga | ogra_: do you have a chroot or did you made / writable? | 18:56 |
| ogra_ | takes a century to deliver a mail ... so i want dekko to sync in bg | 18:56 |
| zyga | ogra_: (as in, will you get OTAs?) | 18:56 |
| ogra_ | nothing writable, no | 18:57 |
| ogra_ | i have a local libvertine container for X apps | 18:57 |
| ogra_ | *libertine | 18:57 |
| ogra_ | the device is proper on teh stable channel, system partition untouched | 18:57 |
| zyga | ogra_: you should blog about how you set that up | 18:58 |
| zyga | ogra_: I'm not sure I even heard about libertine :) | 18:58 |
| ogra_ | i was planning to do that on teh weekend ;) | 18:58 |
| ogra_ | it gives you containers hooked into xmir | 18:58 |
| ogra_ | so you can run firefox and stuff | 18:58 |
| zyga | ogra_: is firefox readable on the fhd screen? | 18:59 |
| ogra_ | well, it doesnt use the proper DPI settings yet ... | 18:59 |
| ogra_ | it is very small ... but you noticed already that i have good eyes ;) | 19:00 |
| ogra_ | but i obnly used it twice for a few mins ... the ubuntu browser is really superior to it imho | 19:00 |
| sergiusens | I am using the ubuntu browser on desktop as well fwiw ;-) | 19:00 |
| sergiusens | so light weight! | 19:01 |
| ogra_ | yeah | 19:01 |
| === devil is now known as Guest52703 | ||
| === Guest52703 is now known as devil_ | ||
| sborovkov | Is /writable still the place to write a lot of stuff? I don't want to write to SNAP_USER_DATA because it would be replicated (from what I understood) and since I am on RPI and there is a lot of stuff I need to store that would be pretty bad for SD card | 19:16 |
| ogra_ | your snap cant see /writable ... | 19:16 |
| ogra_ | but yes, it is still the writable area (as the name kind of implies ;) ) | 19:17 |
| ogra_ | and actually our only system partition nowadays | 19:17 |
| sborovkov | Wait, so what do I do if it can't see it | 19:17 |
| ogra_ | you write to SNAP_DATA | 19:18 |
| ogra_ | afaik there was work going on to allow your snap to override the duplication/copying on upgrade ... not sure where that stands though | 19:18 |
| sborovkov | ogra_: SNAP_DATA won't be replicated and will be persistent, right? | 19:19 |
| ogra_ | it will be replicated by default, but yes, it is persistent | 19:19 |
| sborovkov | ogra_: Ok. May be it would be better to use HOME interface? it allows access to /home/ubuntu as far as I understand. We keep playlist which can be pretty large | 19:20 |
| sborovkov | any additional replications won't be good for SD card | 19:21 |
| ogra_ | not sure if teh home interface actually works on IOT ... thats a desktop thing | 19:21 |
| ogra_ | also note that you can not attch to the home interface automatically | 19:21 |
| ogra_ | requires user interaction | 19:21 |
| ogra_ | as i said, there was work to allow you to prevent the duplication ... but i dont know where that stands | 19:22 |
| oparoz | ogra_, regarding "your snap cant see /writable" is this a new thing which is going to stay that way? | 19:29 |
| sborovkov | ogra_: Yeah, I understand, but while it's not in I'd prefer to use something else without replication. We implemented slot in gadget snap (which we use custom version of) before to allow access to /dev/vchiq. Is it possible to do the same with new security to grant access to /writable or /home/ubuntu or any other directory? | 19:29 |
| ogra_ | oparoz: nope, has always been that way | 19:30 |
| sergiusens | elopio kyrofa standup today? | 19:30 |
| kyrofa | sergiusens, ah yeah on my way | 19:30 |
| ogra_ | oparoz: a snap can only see its own subdirs | 19:30 |
| oparoz | ogra_, I'm able to access data from another snap by using a /writable path | 19:30 |
| ogra_ | (one of them is a writable one) | 19:30 |
| sergiusens | kyrofa let me get some coffee first | 19:31 |
| ogra_ | oparoz: that would be a bug if yuor snap is actually confined | 19:31 |
| kyrofa | sergiusens, ugh, you remind me I need to roast some | 19:31 |
| oparoz | I'm on the older mvo image though... | 19:31 |
| oparoz | Ah, good point, ogra... I was testing with unconfined | 19:31 |
| ogra_ | ah | 19:32 |
| ogra_ | yeah, then you have access everywhere :) | 19:32 |
| ogra_ | sborovkov: install the hello-world snap ... then use hello-world.sh .... that gives you a shell inside a confined snap env | 19:32 |
| ogra_ | so you can inspect what you can access and what you cant | 19:33 |
| oparoz | ogra_, so the way forward is to wait for you guys to implement an interface giving writable storage access to other snaps | 19:33 |
| oparoz | that would help make snaps more atomic | 19:34 |
| ogra_ | well, not sure that is planned at all ... you can have a "library" snap that all your other snaps can access ... i guess that way you could have a shared dir | 19:34 |
| ogra_ | but i think these library snaps are also still a bit away | 19:34 |
| oparoz | ah, that famous library snap :) | 19:34 |
| ogra_ | zyga could probably tell you more ... i'm mainly guessing here from what i pick up in drive-by conversations | 19:35 |
| jdstrand | tyhicks: can you advise how I should fix https://bugs.launchpad.net/ubuntu/+source/ubuntu-core-launcher/+bug/1574556 ? it seems like I should add to ubuntu-core-launcher's policy the ecryptfs workaround rules from the base abstraction | 19:53 |
| ubottu | Launchpad bug 1574556 in ubuntu-core-launcher (Ubuntu) "apparmor denials reported for encryped HOME" [Undecided,New] | 19:53 |
| tyhicks | jdstrand: that's the best option for now - there'll soon be a kernel fix upstream for this and then we can SRU that and drop the workaround rules | 19:54 |
| jdstrand | that would be fantastic! :) | 19:54 |
| * jdstrand hugs tyhicks :) | 19:54 | |
| tyhicks | jdstrand: actually, it was a contribution from chromeos (I still need to review and test v2 of their patch) | 19:55 |
| wililupy | Ok, let me ask if this makes sense for adding kernel modules to my kernel snap... | 19:55 |
| wililupy | I get my source (apt-get source linux-image-`uname -r` | 19:56 |
| jdstrand | I don't know how to hug chromeos, so I'll leave that with you | 19:56 |
| wililupy | I build it with snapcraft (snapcraft build) | 19:56 |
| tyhicks | jdstrand: :) | 19:57 |
| wililupy | I then build my kernel modules against the build (make all KSRC=/tmp/ksnap/parts/kernel/build) | 19:57 |
| wililupy | I then stage (snapcraft stage) | 19:57 |
| wililupy | I copy the modules into ./stage/lib/modules/`uname -r`/extra/*.ko) | 19:58 |
| wililupy | depmop them (depmod -b ./stage/kernel `uname -r`) | 19:59 |
| wililupy | then build the snap (snapcraft snap) | 19:59 |
| wililupy | Does that make sense? I want to script this for the customer and want to know if this is a good solution. | 20:01 |
| === devil is now known as Guest16642 | ||
| === Guest16642 is now known as devil_ | ||
| * zyga looks at backlog for that one bit | 21:25 | |
| kgunn | so, if i'm adding an interface...and i go to install my built snap for the very first time...bout how long should the 'Setup snap "mir-server" security profiles' take? | 21:31 |
| kgunn | seems to be spining quite some time... | 21:31 |
| kgunn | any hints what i might have done wrong | 21:31 |
| zyga | jdstrand: around | 21:31 |
| zyga | kgunn: can you share your branch please | 21:32 |
| kgunn | will do | 21:32 |
| jdstrand | kgunn: it would be nearly instant. no more than a second or two | 21:32 |
| jdstrand | zyga: yes | 21:32 |
| jdstrand | s/would/should/ | 21:32 |
| sergiusens | jdstrand kyrofa zyga nailed the vscode problem down to libnss3 being included in the snap | 21:32 |
| zyga | jdstrand: I want to show you the bluez code with 2nd fix, let me quickly share it | 21:32 |
| zyga | sergiusens: \o/ | 21:32 |
| jdstrand | sergiusens: nice! :) | 21:33 |
| === chihchun is now known as chihchun_afk | ||
| sergiusens | I don't know how to solve it yet though :-P | 21:33 |
| zyga | sergiusens: solve it? | 21:34 |
| sergiusens | zyga I know what causes the SIGABRT | 21:34 |
| sergiusens | but not why | 21:34 |
| zyga | ahh | 21:34 |
| sergiusens | zyga - Remove snap "vscode" from the system (remove /snap/vscode/100001/CHANGELOG.md: read-only file system) | 21:35 |
| sergiusens | what is going on? | 21:35 |
| zyga | sergiusens: oh, nice bug | 21:36 |
| zyga | sergiusens: please report this, note that it wants to remove the *changelog* | 21:36 |
| zyga | sergiusens: I saw it before but I wasn't sure how to reproduce it | 21:36 |
| zyga | jdstrand: https://github.com/zyga/snappy/commit/e9b2da3d1459d1f0dfa92036f0de477757024a4b | 21:36 |
| zyga | (no more globs :-) | 21:37 |
| sergiusens | zyga I've just installed and removed repeatedly | 21:37 |
| zyga | sergiusens: please report it with snap changes and syslog parts (journalctl -u snapd) | 21:37 |
| zyga | sergiusens: keep your state around if you can, I'm sure pedronis will want to see it | 21:37 |
| zyga | sergiusens: (or attach it to the bug as well please) | 21:37 |
| sergiusens | zyga seems to be a systemd mount issue | 21:40 |
| sergiusens | zyga https://bugs.launchpad.net/snappy/+bug/1575385 | 21:41 |
| ubottu | Launchpad bug 1575385 in Snappy "After installing and removing for a while I can't remove anymore" [Undecided,New] | 21:41 |
| zyga | Apr 26 18:34:53 lindon /usr/lib/snapd/snapd[16408]: overlord.go:142: Failed to stop "/etc/systemd/system/snap-vscode-100001.mount": [stop snap-vscode-100001.mount] failed with exit status 1: Job for snap-vscode-100001.mount failed. See "systemctl status snap-vscode-100001.mount" and "journalctl -xe" for details. | 21:42 |
| zyga | , but continuing anyway. | 21:42 |
| zyga | Apr 26 18:34:53 lindon snapd[16408]: 2016/04/26 18:34:53.066860 overlord.go:142: Failed to stop "/etc/systemd/system/snap-vscode-100001.mount": [stop snap-vscode-100001.mount] failed with exit status 1: Job for snap-vscode-100001.mount failed. See "systemctl status snap-vscode-100001.mount" and "journalctl -xe" for details. | 21:42 |
| zyga | Apr 26 18:34:53 lindon snapd[16408]: , but continuing anyway. | 21:42 |
| zyga | I suspect this is key | 21:42 |
| zyga | thanks sergiusens! | 21:42 |
| sergiusens | zyga np | 21:42 |
| zyga | jdstrand: is the patch sensible? | 21:43 |
| zyga | jdstrand: if so I can propose it and we can close the earlier branch | 21:43 |
| * jdstrand looks | 21:44 | |
| zyga | jdstrand: as a full pull request: https://github.com/ubuntu-core/snappy/pull/1078/files | 21:44 |
| zyga | I also closed the earlier one | 21:45 |
| jdstrand | zyga: so, I think this looks generally fine. I've been working under the assumption that you can do a connection between snaps, between apps or between apps and snaps. if this is the case, will slot.Apps() contain all the apps if connection to a snap? | 21:49 |
| zyga | slot.Apps is the map of all apps bound to that slot | 21:50 |
| zyga | it's not about connections | 21:50 |
| jdstrand | zyga: ie, what this does is get rid of the glob entirely, but the glob is useful for connecting to a snap | 21:50 |
| zyga | connections are handled by calling the interface many times | 21:50 |
| zyga | so if both, say, bluetoothctl from the same snap is connected | 21:50 |
| zyga | and a 3rd party snap with some apps are connected | 21:51 |
| zyga | those will get separate snippets | 21:51 |
| jdstrand | sure | 21:51 |
| zyga | that both specify the peer label precisely | 21:51 |
| sergiusens | zyga ok, another weirdness; now on every `snap install` I get this old snap installed that can't be removed | 21:51 |
| zyga | not sure if that answers your question | 21:51 |
| sergiusens | zyga already ran your cleanup script twice! | 21:51 |
| zyga | sergiusens: oh? | 21:51 |
| zyga | sergiusens: did you restart snapd too? | 21:51 |
| zyga | sergiusens: I think the script stops it | 21:51 |
| sergiusens | zyga your script does that, does it not? | 21:51 |
| zyga | yep | 21:51 |
| zyga | hmm | 21:51 |
| zyga | so run the script, don't start snapd | 21:52 |
| zyga | see if anything else remains, systemd mount units maybe? | 21:52 |
| zyga | but actually | 21:52 |
| zyga | snapd restarts changes + tasks | 21:52 |
| zyga | hmm | 21:53 |
| * zyga has no idea | 21:53 | |
| sergiusens | zyga not unmounting now | 21:53 |
| jdstrand | zyga: I understood that. what I'm saying is this: snap connect foo.bar:bluez bluez5:bluez vs snap connect foo.bar bluez5.bluezd:bluez | 21:54 |
| jdstrand | where foo has: | 21:54 |
| jdstrand | name: foo | 21:54 |
| sergiusens | zyga /var/lib/snapd/snaps/vscode_100001.snap (deleted) on /snap/vscode/100001 type squashfs (ro,relatime) | 21:54 |
| jdstrand | apps: | 21:54 |
| jdstrand | bar: ... | 21:54 |
| jdstrand | and bluez5 has: | 21:54 |
| jdstrand | name: bluez5 | 21:54 |
| jdstrand | apps: | 21:54 |
| jdstrand | bluezd: ... | 21:54 |
| jdstrand | bluetoothctl: ... | 21:54 |
| zyga | jdstrand: note that you cannot connect an application, if you connect foo's plug, you connect the bar app from foo snap (reading rest) | 21:55 |
| zyga | jdstrand: I'm not sure if I understand what you are saying, in your example you would do the following connect: | 21:55 |
| jdstrand | zyga: ok, fine, so snappy does magic | 21:55 |
| zyga | jdstrand: snap connect foo:something bluez5:bluez5 | 21:56 |
| jdstrand | let me come up with a paste | 21:56 |
| zyga | or s/bluez5:bluez5/bluez5:bluez/ | 21:56 |
| zyga | sergiusens: we merged better remove today | 21:56 |
| zyga | sergiusens: remove removes all revisions now | 21:56 |
| zyga | sergiusens: maybe it hit the ppa by now | 21:56 |
| zyga | (though I don't know if you want to follow the ppa) | 21:57 |
| wililupy | crap. Ok. So I built my kernel snap using snapcraft, I add it as the --kernel= with u-d-f but when I try to boot up, I get the following error: http://pastebin.ubuntu.com/16071576/ and then I go back to GRUB menu... | 21:57 |
| wililupy | Any ideas? | 21:59 |
| zyga | wililupy: nope, sorry | 21:59 |
| wililupy | Everything looks good, just no ideas. At first I thought maybe it was becuase I wasn't root when building the kernel snap, but even that doesn't work... | 22:00 |
| zyga | I don't think you should ever be root with snapcraft | 22:01 |
| zyga | ogra_: any idea if I can try convergence/firefox on nexus 7? | 22:02 |
| wililupy | zyga it builds fine with my normal user account as well, everything builds fine, I just haven't been able to build a working kernel snap since 2.5... | 22:02 |
| zyga | ogra_: I have a channel (pd-proposed or something) that has the firefox icon but it does nothing | 22:02 |
| zyga | wililupy: I think you want to talk to sergiusens | 22:02 |
| sergiusens | no, I'm not a kernel person | 22:02 |
| zyga | he is just teasing ;) | 22:03 |
| sergiusens | jdstrand zyga ok, apparently I can't "relocate" nss, but it is not in ubuntu-core | 22:03 |
| zyga | sergiusens: isn't nss using lots of plugins and a socket to talk to various parts and a daemon | 22:04 |
| zyga | sergiusens: doesn't sound like something we should put into snaps | 22:04 |
| zyga | sergiusens: it does name resolution among other things IIRC | 22:04 |
| sergiusens | zyga right, but if core doesn't provide it, what to do? | 22:04 |
| zyga | sergiusens: provide it in core | 22:04 |
| sergiusens | zyga do it then ;-) | 22:04 |
| sergiusens | ogra_ ^ | 22:05 |
| sergiusens | :-) | 22:05 |
| zyga | ogra_: correct me if I'm wrong but it feels like a core item | 22:05 |
| zyga | btw are you sure it's not in core? | 22:05 |
| zyga | extra users AFAIR use nss | 22:05 |
| zyga | (some fancy plugin to look at places other than /etc/passwd) | 22:05 |
| jdstrand | zyga: http://paste.ubuntu.com/16071638/ | 22:05 |
| sergiusens | zyga if I don't add it $ vscode /snap/vscode/100001/code-oss: error while loading shared libraries: libnss3.so: cannot open shared object file: No such file or directory | 22:05 |
| * zyga focuses on the pastebin | 22:06 | |
| kgunn | zyga: will send you a mail with info later...got to attend to a house calamity atm :) | 22:06 |
| zyga | kgunn: sure | 22:07 |
| jdstrand | sergiusens, zyga: not libnss3 is Network Security Services, an encryption library from the mozilla project and not 'Name Service Switch' from glibc name resolution | 22:07 |
| jdstrand | s/not/note/ | 22:07 |
| jdstrand | ie, there is no daemon, etc, etc with libnss3 | 22:07 |
| zyga | jdstrand: I see | 22:07 |
| zyga | jdstrand: /o\ | 22:07 |
| zyga | jdstrand: as for the pastebin, I think we can special case 2. to just use the app name, for 1 I'd keep it as-is, it's precise and does the same thing | 22:08 |
| jdstrand | sergiusens: I wonder if you need libnspr4 | 22:08 |
| * zyga will name all his new libraries libnss | 22:08 | |
| zyga | libnewstuffsomething | 22:08 |
| zyga | with a random number | 22:08 |
| sergiusens | jdstrand it is in there | 22:09 |
| sergiusens | jdstrand I am manually adding the plugins now to see if that is it | 22:09 |
| sergiusens | adding libnss as a stage-package | 22:09 |
| jdstrand | zyga: so I'm inclined to agree, but note that complex alternations ({1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,...}) can be a bit unwieldy when a glob would be better | 22:10 |
| zyga | jdstrand: hmmm, so the glob might make sense if slot.Apps != slot.Snap.Apps | 22:10 |
| zyga | jdstrand: we can special case both cases so that we get a glob or no globs or alternation | 22:10 |
| zyga | jdstrand: if you think it's worth doing | 22:10 |
| zyga | s/!=/==/ | 22:11 |
| jdstrand | zyga: it is most correct and since we are thinking about it, it would be better to do it now. otherwise I would suggest you add a comment saying that snaps with a lot of apps in them could be better written with a glob rule | 22:11 |
| zyga | jdstrand: you mean special case both of those? | 22:12 |
| zyga | jdstrand: I can do it quickly | 22:12 |
| jdstrand | zyga: yes please | 22:13 |
| sergiusens | jdstrand zyga ok I stage-package'd libss3 and am further ahead, happy to see apparmor denials :-) http://paste.ubuntu.com/16071766/ | 22:13 |
| jdstrand | zyga: which means we need a test for case 1 and case 2 in addition to your existing test (of course) | 22:13 |
| jdstrand | sergiusens: ok, two of those are the same as you gave earlier and I'll do a PR to add them (the /proc denials). the /etc/profile.d you need to invoke bash differently (ie with a bashrc) so it doesn't look there and /var/tmp is probably a noisy denial | 22:15 |
| jdstrand | sergiusens: it is probably trying /var/tmp then going to /tmp | 22:15 |
| sergiusens | jdstrand maybe, yeah, the first ones were there already, just put it to be thorough | 22:16 |
| sergiusens | jdstrand wrt bash, I not invoking it directly so no idea | 22:16 |
| sergiusens | will need to debug some more | 22:16 |
| sergiusens | jdstrand the vscode electron process is running, but I don't see anything on screen; so that's my next issue | 22:17 |
| jdstrand | sergiusens: I mean, we could allow /etc/profile.d, but that would just open up whatever is in in there and cause trouble (eg, it adds apps-bin-path.sh which updates PATH which is not what we want) | 22:18 |
| jdstrand | sergiusens: I suspect that read on /etc/profile.d is not causing any issues and just noice (but I don't know that) | 22:18 |
| jdstrand | noise | 22:18 |
| sergiusens | jdstrand --norc is the default if called as /bin/sh so I'll need to dive into the vscode code | 22:20 |
| sergiusens | thanks | 22:20 |
| zyga | ok, done, pushing | 22:20 |
| zyga | jdstrand: https://github.com/ubuntu-core/snappy/pull/1078/commits/c1c084f186a6e747db2d03109206d387760b73a4 | 22:23 |
| croepha | what do you all use for a text editor on snappy? the best I can come up with is to run nano inside of docker with a mounted volume out to the host | 22:24 |
| zyga | croepha: I use vim on my host | 22:24 |
| zyga | croepha: I don't hack on snappy itself, I did when we had classic (we're getting classic back soon) | 22:25 |
| zyga | croepha: when I had classic I also used vim | 22:25 |
| zyga | croepha: don't settle for less :) | 22:25 |
| croepha | what is classic? | 22:25 |
| zyga | croepha: on snappy you could say "snappy enable-classic" and you got a regular classic, deb-based ubuntu | 22:25 |
| zyga | croepha: we removed it before the 16.04 release to polish it before it is brought back | 22:26 |
| croepha | ahh ok | 22:26 |
| zyga | croepha: it essentially lets you apt-get install anything you need inside snappy in a lxc container that is integrated with the host in a special way (more than a regular lxc ubuntu container would) | 22:26 |
| zyga | e.g. apt-get install minicom and use the serial port directly | 22:27 |
| croepha | zyga, ahh thats clever, kinda similar to what I was doing with docker | 22:27 |
| wililupy | Ok, I installed the .snap on a current system, and when I look at /writables/snap/im-kernel, it has the symbolic links still set to the system I build the snap on... Is that normal? | 22:27 |
| sergiusens | zyga another one for you https://bugs.launchpad.net/snappy/+bug/1575399 | 22:27 |
| ubottu | Launchpad bug 1575399 in Snappy "Half installation for a snap" [Undecided,New] | 22:27 |
| zyga | jdstrand: I'm EODing, it was great to work on this but I'm falling asleep now | 22:27 |
| wililupy | I rebooted the system, but it didn't boot my new kernel snap... | 22:28 |
| zyga | sergiusens: thanks! | 22:28 |
| zyga | sergiusens: we're sure we have bugs in install/remove code | 22:28 |
| zyga | sergiusens: and in undo code for those bits | 22:28 |
| zyga | sergiusens: more testing == faster bug fixing :) | 22:28 |
| croepha | Im really new to snappy, just picked it up today, is one of the goals to basically make system upgrades bullet proof? like no issues where you did a dist-upgrade and now you have to get into recovery mode... stuff like that? | 22:28 |
| zyga | croepha: among other goals | 22:29 |
| * zyga EODs for real, ttyl | 22:29 | |
| wililupy | later zyga! | 22:29 |
| croepha | bye | 22:29 |
| wililupy | It's almost like snappy is seeing my kernel snap as a gadget... | 22:29 |
| wililupy | It didn't ask to reboot after installing it to make it active... | 22:30 |
| jdstrand | zyga: thanks for the PR, I made a nitpick comment but feel free to ignore. thanks and good evening! :) | 22:31 |
| sergiusens | jdstrand last one http://paste.ubuntu.com/16072031/ (I hope) | 22:39 |
| jdstrand | sergiusens: seems you need 'plugs: [network]' but possibly 'network-bind' for 'shutdown' (assuming this is amd64) | 22:41 |
| jdstrand | sergiusens: do you know why it is using the shutdown syscall? | 22:41 |
| jdstrand | actually, strike that | 22:42 |
| jdstrand | shutdown is in 'network' | 22:42 |
| jdstrand | just plugs network | 22:42 |
| wililupy | Has anyone successfuly built a kernel snap with snapcraft 2.8.4? | 22:43 |
| sergiusens | jdstrand oh, they weren't auto assigned | 22:51 |
| sergiusens | jdstrand this is totally weird http://paste.ubuntu.com/16072127/ | 22:51 |
| sergiusens | ok, back to the known issues | 22:53 |
| jdstrand | sergiusens: huh. sounds like a bug. I know I've seen times when they didn't get autoassigned... | 23:00 |
| sergiusens | jdstrand I've logged my fair share of bugs today! | 23:02 |
| jdstrand | heh | 23:06 |
| === wililupy is now known as wililupy|afk | ||
| === blr_ is now known as blr | ||
| === wililupy|afk is now known as wililupy | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
