| mbenz | Did you see Tino is gone as of today? | 00:07 |
|---|---|---|
| morphis | morning! | 06:20 |
| tvoss | good morning :) | 06:32 |
| mup | PR snapd#3167 opened: interfaces: fold network bind into core support with tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3167> | 06:44 |
| tvoss | pedronis: so tyhicks is proposing /run/snapd as the place to put the temporary key files | 06:45 |
| tvoss | pedronis: is that reasonable for you? | 06:46 |
| zyga | good morning | 06:46 |
| zyga | tvoss: what's up? :-) | 06:46 |
| tvoss | zyga: aiming to finalize the key generation PR | 06:47 |
| zyga | tvoss: mhm | 06:47 |
| zyga | mvo: hey | 06:47 |
| tvoss | zyga: tyhicks is proposing /run/snapd to place the temporary key files, I'm fine with that. Do you have any objections? | 06:48 |
| zyga | mvo: I merged one of the approved PRs last night | 06:48 |
| zyga | tvoss: who will place them there? | 06:48 |
| tvoss | zyga: snapd itself, when generating the device key. cleaning them up once the operation finishes | 06:49 |
| zyga | tvoss: /run/snapd/lock and /run/snapd/ns are touched by snap-confine but I think this is fine | 06:49 |
| zyga | tvoss: maybe you can use a sub-directory, not sure what your plan is fully | 06:49 |
| tvoss | zyga: I just need a place to put the key files temporarily | 06:50 |
| zyga | tvoss: and /tmp is not good? | 06:50 |
| tvoss | zyga: so readable/writable by snapd only is pretty much the only requirement | 06:50 |
| zyga | aha | 06:50 |
| morphis | zyga: so this static/non-static build of snap-confine is really tricky now, why did you drop the the --enable-partially-static thing and switched to individual --enable-static-* switches? | 06:52 |
| tvoss | zyga: with that, /run/snapd seems like a good choice | 06:52 |
| zyga | morphis: because --enable-partially-static is a no-op in the new scheme, it's always like that | 06:52 |
| zyga | morphis: you can pick any partially static part of snap-confine | 06:52 |
| zyga | morphis: and it is not possible to build a fully static snap-confine anyway, because of udev | 06:53 |
| zyga | tvoss: and /tmp? | 06:53 |
| tvoss | zyga: does snapd get its own /tmp? If not, I would rather put it in a more specific directory | 06:53 |
| zyga | tvoss: no, snapd doesn't get any magic treatment, /tmp is shared | 06:54 |
| tvoss | zyga: so I would rather go for /run/snapd then | 06:54 |
| * zyga is still somehow confused, why /run vs /tmp for temp file | 06:54 | |
| zyga | it's not that /run is bad, I just want to understand why it was picked over /tmp | 06:54 |
| tvoss | zyga: following securities advice. /tmp is world readable, right? | 06:55 |
| zyga | tvoss: as is run | 06:55 |
| zyga | tvoss: it's just a matter of giving the right mode to the file | 06:55 |
| tvoss | zyga: it get's the right mode from ssh-keygen already | 06:56 |
| zyga | tvoss: so there's no difference | 06:56 |
| tvoss | zyga: feel free to comment on the PR, too. | 06:56 |
| zyga | tvoss: yep, thanks | 06:58 |
| zyga | tvoss: is that 2.24 material? | 06:58 |
| zyga | tvoss: or 2.25? | 06:58 |
| tvoss | zyga: well, ideally, we would have it in 2.24 | 06:58 |
| * zyga nods | 07:00 | |
| zyga | pedronis: hey | 07:05 |
| zyga | pedronis: so I'd like to understand how we are going to proceed | 07:05 |
| zyga | pedronis: (fold and fix later vs fix now) | 07:06 |
| zyga | pedronis: do I understand correctly that the root issue is how auto-connect works? | 07:06 |
| mvo | https://forum.snapcraft.io/t/unblocking-2-24/238 is my proposal to get 2.24 out and then fix the deeper issues | 07:07 |
| pstolowski | morning | 07:10 |
| zyga | pstolowski: hello :) | 07:11 |
| morphis | zyga: so for whatever libtool/autotools reason https://github.com/snapcore/snapd/pull/3162 disables linking libcap statically, it ends up in _STATIC but is linked against the .so | 07:11 |
| mup | PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162> | 07:11 |
| morphis | pstolowski: morning! | 07:12 |
| zyga | morphis: because the .la files now dictate everything | 07:12 |
| zyga | morphis: kind of suspected this would happen though, did we merge that already by any chance? | 07:12 |
| morphis | sure, but shouldn't we be able to override that? | 07:12 |
| morphis | zyga: we didn't | 07:13 |
| morphis | tests are detecting that libcap is dynamically linked | 07:13 |
| zyga | morphis: yes but the way is not the same, I suspect | 07:13 |
| pedronis | mvo: zyga: I answered there | 07:13 |
| zyga | morphis: look at the resulting makefile | 07:13 |
| zyga | pedronis: thanks! | 07:13 |
| morphis | zyga: I do | 07:14 |
| morphis | zyga: .._STATIC = -lcap is what we have there | 07:14 |
| mvo | pedronis: so just picking selected bits from 3145 ? let me see | 07:14 |
| zyga | pedronis: "this part" is fixDisconnectedCorePlugs or the hack further down in autoConnect? | 07:16 |
| zyga | morphis: those are just variables, look at rules | 07:16 |
| pedronis | zyga: the hack in autoconnect, after thinking it seems we don't need fixDisconnectedCorePlugs ... when we intall the new core we run autoconnect logic again | 07:16 |
| zyga | pedronis: aha, interesting | 07:17 |
| * zyga thinks | 07:17 | |
| pedronis | zyga: remember that for core we run setup-profiles twice, once in the old snapd and once in the new one | 07:17 |
| zyga | yes, that's right | 07:18 |
| zyga | and the 2nd try will already have the hack and will connect things | 07:18 |
| zyga | (the plugs that is) | 07:18 |
| zyga | mvo: I think it will work too | 07:19 |
| zyga | I worry about folding (a little) that it's a slippery slope we will have to climb out of for some reason we cannot forsee yet | 07:19 |
| pedronis | this is not true for very old snapds but then those have other bugs around running configure too | 07:19 |
| zyga | (that we will end up needing the privilege separation in core0 | 07:20 |
| zyga | mvo: I think this is your call ultimately, while we discuss more and more there will be more and more branches proposed/merged | 07:20 |
| zyga | mvo: so if you want to limit the extent of the changes we put into 2.24, I think the way is to release now | 07:21 |
| mup | PR snapd#3168 opened: .travis.yml: add option make raw log less noisy <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3168> | 07:21 |
| mvo | zyga, pedronis: I am fine with adding a special case for core/core-support in auto-connect, if its small and targeted, but I really want to get on with 2.24, that is my overriding priority right now (of course while still making sane decisions) | 07:21 |
| mvo | zyga: release now with 3167? or release now now :) ? | 07:22 |
| zyga | mvo: "now" as in quickly | 07:22 |
| mvo | +100 | 07:22 |
| mvo | pedronis: so your second suggestion is to use folding + special case, a special case like http://paste.ubuntu.com/24359539/ ? | 07:25 |
| pedronis | mvo: well if we also fold the special case could be just about core-support but yes | 07:25 |
| mvo | pedronis: do you have something simpler in mind already, if so, would you mind sketching it out? I'm fine with fold+special-case as it feels like we at least have everything ready when autoconnect is fully fixed this way. as long as its straightfoward :) | 07:27 |
| * zyga would like to know what the fully fixed autoconnect is like | 07:28 | |
| mvo | zyga: thats for later, lets not get distracted ;) | 07:29 |
| pedronis | that's a bigger thing | 07:29 |
| * mvo puts on his tunnel vision glasses | 07:29 | |
| pedronis | not doing to think about that now (though I have ideas) | 07:29 |
| pedronis | mvo: I think just taking that bit and plug.Interface == "core-support" first would be enough for now , if we fold ... we can improve/change it later | 07:30 |
| zyga | do you want me to prepare that branch? | 07:33 |
| mvo | zyga: if you don't mind, as small as possible please :) | 07:35 |
| zyga | mvo: OK | 07:36 |
| morphis | zyga: ok, problem is that libtool needs the full-path to the .a we want to statically link | 07:37 |
| mup | PR snapd#3164 closed: tests: ensure network-bind and core-support are connected <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3164> | 07:39 |
| mup | PR snapd#3165 closed: interfaces: adjust shm accesses to use 'm' for updated mmap kernel mediation <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3165> | 07:41 |
| mvo | I need reviews for 3167 - at leat one, the underlying branch (without the spread test) got a +1 from gustavo already | 07:43 |
| zyga | mvo: running tests locally | 07:52 |
| mvo | zyga: great, looking forward for this branch | 07:53 |
| mvo | to this branch | 07:53 |
| zyga | mvo: I included the small yaml cleanup as I didn't want to tear that out and it is harmless (just variable rename for correctness) | 07:55 |
| zyga | mvo: (same that was there originally) | 07:55 |
| mvo | zyga: sounds good, push it | 07:56 |
| * mvo is being pushy | 07:56 | |
| mup | PR snapd#3168 closed: .travis.yml: add option to make raw log less noisy <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3168> | 07:57 |
| pstolowski | we don't seem to have any spread tests which exercises gadget config defaults, do we? | 08:03 |
| pedronis | pstolowski: no, also that functionality is broken in other ways | 08:03 |
| pstolowski | pedronis, how do you mean? | 08:04 |
| pedronis | pstolowski: that at first boot it will not always be applied because of order issues | 08:04 |
| pedronis | of things | 08:04 |
| pstolowski | pedronis, oh i see. ty | 08:06 |
| pedronis | something to fix for 2.25 (I think) | 08:08 |
| mup | PR snapd#3169 opened: many: fix plug auto-connect during core transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3169> | 08:10 |
| zyga | pedronis, mvo: ^ | 08:11 |
| mvo | zyga: could you have a look at 3167 please? | 08:12 |
| Chipaca | morning eurofriends | 08:12 |
| Chipaca | anything particularly lit today? | 08:12 |
| zyga | mvo: certainly, looking now | 08:12 |
| mvo | ta | 08:13 |
| zyga | Chipaca: morning separatistic islander, nothing particularly on fire | 08:13 |
| mvo | hey Chipaca! good morning | 08:13 |
| mvo | Chipaca: I'm having slight tunnel vision to get 2.24 out but otherwise things are fine | 08:14 |
| mvo | s/slight/huge/ | 08:14 |
| Chipaca | mvo— as well you should | 08:14 |
| Chipaca | mvo— as long as it's not from getting up too quickly or something :-) | 08:14 |
| zyga | mvo: the regexpes there feel too generic, if we grow core-support-apparatus they will still match | 08:14 |
| zyga | mvo: but since tests are passing ignore me for now :) | 08:15 |
| mvo | zyga: :) happy to do a followup | 08:15 |
| zyga | mvo: in 2.25 :) | 08:15 |
| zyga | mvo: I just approved it | 08:15 |
| * zyga is getting hungry | 08:16 | |
| zyga | I'll talk to you after some 1-2-1s | 08:16 |
| mvo | Chipaca: if you don't mind a review of 3167 would be great, should be very simple | 08:16 |
| mvo | zyga: sure, thanks for your help! | 08:17 |
| Chipaca | zyga— my whole house is going to be smelling of slow-cooking beans, onions, peppers and bay leaves today. I think I'm having another breakfast. | 08:17 |
| Chipaca | mvo— +1; there's a typo in a comment, but you can fix later | 08:20 |
| mvo | Chipaca: hahahaa - thats such a freudian slip - cure-support! | 08:21 |
| Chipaca | :-) | 08:21 |
| Chipaca | mvo— maybe you're just missing '80s rock | 08:21 |
| mvo | Chipaca, ogra_: and now - https://github.com/snapcore/core/pull/33/files | 08:22 |
| mup | PR core#33: the core snap only needs core-support (not network-bind) <Created by mvo5> <https://github.com/snapcore/core/pull/33> | 08:22 |
| mup | PR snapd#3166 closed: interfaces/builtin: fold network-bind into core-support <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3166> | 08:22 |
| mup | PR snapd#3167 closed: interfaces: fold network bind into core support with tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3167> | 08:22 |
| mvo | Chipaca: lol | 08:22 |
| mvo | pretty please | 08:22 |
| * mvo is still pushy | 08:22 | |
| ogra_ | approved | 08:22 |
| mvo | ta! | 08:22 |
| Chipaca | yeah, +1. Bring on the two-line merges. | 08:22 |
| ogra_ | heh | 08:23 |
| mup | PR core#33 closed: the core snap only needs core-support (not network-bind) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/33> | 08:23 |
| pedronis | zyga: does #3169 work from your tests? | 08:24 |
| mup | PR snapd#3162 closed: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3162> | 08:29 |
| mvo | ogra_: and one more for core (sorry for that) | 08:39 |
| mup | PR core#34 opened: really remove network-bind-plug <Created by mvo5> <https://github.com/snapcore/core/pull/34> | 08:39 |
| pedronis | zyga: mvo: core-support is interesting because is probably the only? one of the only interfaces where plug and slot that connect are on the same snap? | 08:41 |
| mvo | pedronis: yeah, I think so | 08:41 |
| zyga | pedronis: network-manager and modem-manager have some smilar properties | 08:41 |
| zyga | or maybe something related to location support, I recall really wacky archtecture | 08:42 |
| zyga | but core-support is certainly most common | 08:42 |
| fgimenez | mm i'm getting a lot of "2017-04-11 04:37:02 Discarding linode:ubuntu-core-16-64 (Spread-06), cannot connect: cannot connect to linode:ubuntu-core-16-64 (Spread-06): ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain" this morning https://travis-ci.org/snapcore/spread-cron/builds/220818086#L382 | 08:42 |
| zyga | aha | 08:42 |
| zyga | maybe some other spread collected that machine since it was started? | 08:42 |
| pedronis | zyga: if we have more maybe (I say maybe) it would be interesting to consider the concept of self-plugging , instead of abusing autoconnect for this | 08:43 |
| zyga | pedronis: implicit or somehow explicitly declared in yaml? | 08:44 |
| pedronis | well somehow/somewhere we would need to say that core-support plug on core is supposed to plug into the same snap slot | 08:45 |
| DonAlex | Does anyone know what barriers there are to getting tincd running as a snap? | 08:45 |
| pedronis | anyway if it's just core-support if might be easier to just special case (also because the issue is mostly transition) | 08:45 |
| zyga | DonAlex: we don't know what tincd is so probably you need to tell us more | 08:47 |
| zyga | pedronis: I agree we should explore how connecting should work | 08:47 |
| zyga | pedronis: including a way to say "this snap requires connection before it is functional" | 08:48 |
| zyga | pedronis: something that is currently not possible | 08:48 |
| mvo | Chipaca: one more trivial review please https://github.com/snapcore/core/pull/34 - silly me for overlooking this earlier | 08:51 |
| mup | PR core#34: really remove network-bind-plug <Created by mvo5> <https://github.com/snapcore/core/pull/34> | 08:51 |
| Chipaca | mvo— hah | 08:52 |
| Chipaca | +1'ed | 08:52 |
| DonAlex | zyga: https://tinc-vpn.org/ | 08:52 |
| DonAlex | If I am using a snap on a server I want to be able to put it on my VPN | 08:52 |
| mup | PR core#34 closed: really remove network-bind-plug <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/34> | 08:56 |
| mup | PR snapd#3170 opened: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170> | 08:58 |
| zyga | DonAlex: we don't have support for user services | 08:59 |
| zyga | DonAlex: not sure if that is required | 08:59 |
| zyga | DonAlex: I'd recommend building it as a snap and checking what is missing | 08:59 |
| zyga | DonAlex: we will gladly take feedback | 08:59 |
| zyga | DonAlex: as for permissions, you may need to run in devmode initially (not sure) | 08:59 |
| zyga | DonAlex: devmode means that confinement is advisory, not mandatory | 09:00 |
| zyga | DonAlex: but we can add new interfaces quickly | 09:00 |
| zyga | DonAlex: (or extend existing interfaces where appropriate) | 09:00 |
| zyga | DonAlex: stay in the loop, post on forum.snapcraft.io, try things out | 09:00 |
| mvo | we are close to user services, there is a PR, let me try to find it | 09:00 |
| mvo | https://github.com/snapcore/snapd/pull/2752 | 09:01 |
| mup | PR snapd#2752: snap: add support user-sessions from snaps <Blocked> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2752> | 09:01 |
| pedronis | mvo: so 2.25 is probably more likely to be around the 25th, after yesterday discussion? | 09:01 |
| * zyga is done with breakfast | 09:01 | |
| mvo | pedronis: correct | 09:01 |
| zyga | and heads to 1-2-1 | 09:01 |
| pedronis | mvo: changing the date on github | 09:01 |
| mvo | pedronis: \o/ | 09:01 |
| DonAlex | zyga: I guess the biggest problem will be with creating the device or loading the tun module. | 09:02 |
| DonAlex | zyga: That is normally a system action. Though if you use user permission on some system it works. | 09:02 |
| zyga | DonAlex: tun module can be loaded with the kmod interface | 09:02 |
| zyga | DonAlex: essentially snapd will load the module for you | 09:02 |
| zyga | DonAlex: does it take any parameters that need to be tweaked / set | 09:03 |
| zyga | DonAlex: what devices do you need to create? | 09:03 |
| DonAlex | zyga: hmm no i don't think so .. just needs the device to be created | 09:03 |
| zyga | DonAlex: does the module do that or is that done from userspace? | 09:03 |
| DonAlex | zyga: it creates and iterative interface names per network so tun1 tun2 etc. | 09:04 |
| ogra_ | mvo, hmmm | 09:07 |
| ogra_ | unknown plugs interface name reference 'network-bind-plug' lint-snap-v2_hook_plugs_plug_reference (configure, network-bind-plug) | 09:07 |
| mvo | ogra_: yeah, see above | 09:07 |
| ogra_ | mvo, thats what the store mailed me for the last round of core buillds | 09:07 |
| ogra_ | ah, k | 09:07 |
| mvo | ogra_: the fix is in, Chipaca was kind enough to review. silly me for overlooking a plug reference | 09:07 |
| mvo | too much tunnel vision :( | 09:08 |
| mup | PR snapd#3171 opened: snapstate: normalize gadget defaults <Created by stolowski> <https://github.com/snapcore/snapd/pull/3171> | 09:08 |
| ogra_ | mvo, well, i'D appreciate a tunnel vision that distracts me from that awful spreadsheet | 09:08 |
| mvo | ogra_: :( | 09:09 |
| zyga | oh | 09:11 |
| zyga | darn, I forgot | 09:11 |
| Chipaca | mvo, ogra_, zyga, all the unknowns there are killing me (and there's 2+ weeks to go for those) | 09:11 |
| ogra_ | Choh, i thought it was supposed to be done by friday | 09:12 |
| ogra_ | Chipaca, | 09:12 |
| Chipaca | nope, 2-3 weeks | 09:12 |
| ogra_ | sigh | 09:12 |
| Chipaca | yep | 09:12 |
| ogra_ | mvo, this build got through ! | 09:13 |
| mvo | ogra_: yeah, I'm running a local test now and fire spread | 09:14 |
| mvo | up | 09:14 |
| mikeb_ | Chipaca: In case you didn't see my note yesterday, I've put up that promised demo at https://github.com/mabnhdev/snappy-daemon-demo. | 09:14 |
| Chipaca | mikeb_— I didn't, no | 09:15 |
| Chipaca | network's been iffy and irc doesn't cope well with that | 09:15 |
| Chipaca | mikeb_— why is 'devmode' needed? | 09:17 |
| woodrowshen | mvo: hi | 09:17 |
| Chipaca | mikeb_— anyway, thanks, I'll look into this | 09:18 |
| mvo | hey woodrowshen | 09:18 |
| DonAlex | Ok .. gonna have a go at building it myself. Will let you know what happens via the forums. | 09:18 |
| mikeb_ | Chipaca: devmode is force of habit - I mostly play with code that violates containment. | 09:19 |
| Chipaca | mikeb_— cheeky :-) | 09:19 |
| Chipaca | mikeb_— but seriously, thank you, and I'll be playing with this | 09:19 |
| Chipaca | might get something into 2.25 if it's concise enough | 09:20 |
| mikeb_ | Chipaca: I appreciate your time. Thanks. | 09:20 |
| Chipaca | (and if we all agree on it) | 09:20 |
| woodrowshen | mvo: i built snappy image with armhf, and just found core snap rev. is 1580, is it current rev. in stable ? | 09:21 |
| mvo | woodrowshen: that sounds correct | 09:23 |
| mvo | woodrowshen: 1580 is the stable core on armhf with snapd 2.23.6 | 09:24 |
| woodrowshen | mvo: ok, thanks. i met the weird case of failure to exec `snap list` | 09:24 |
| zyga | re | 09:25 |
| zyga | how can I help? | 09:25 |
| mvo | woodrowshen: what is the failure? can you please pastebin it | 09:27 |
| mvo | zyga: mostly waiting for tests now, the new core breaks the interfaces-network-bind spread test testing a fix locally and then we should be good again | 09:29 |
| woodrowshen | mvo: http://paste.ubuntu.com/24359921/ | 09:31 |
| woodrowshen | mvo: just output "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: EOF" | 09:32 |
| zyga | woodrowshen: let me help you | 09:32 |
| zyga | mvo: focus on the fix :) | 09:32 |
| mvo | woodrowshen: Apr 11 08:46:07 localhost snapd[1994]: runtime: out of memory: cannot allocate 258801664-byte block (510001152 in use) | 09:32 |
| mvo | woodrowshen: what system is that? how much ram? | 09:32 |
| mvo | zyga: ha! thank you | 09:32 |
| zyga | woodrowshen: how about "snap version" | 09:32 |
| mvo | zyga: even better | 09:32 |
| zyga | woodrowshen: and systemctl status snapd.service | 09:32 |
| woodrowshen | zyga: mvo: thanks a lot | 09:33 |
| woodrowshen | zyga: ooo... | 09:33 |
| mup | PR snapd#3172 opened: tests: fix interfaces-network-bind to match the new core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3172> | 09:34 |
| woodrowshen | zyga: all snap commands can't work | 09:34 |
| zyga | woodrowshen: how much memory do you have there? | 09:36 |
| woodrowshen | zyga: 1G | 09:36 |
| zyga | woodrowshen: what is that system, is it a VM? | 09:37 |
| zyga | woodrowshen: what dis | 09:37 |
| zyga | distribution? | 09:37 |
| woodrowshen | zyga: roseapple-pi, a devel board | 09:38 |
| zyga | woodrowshen: aha | 09:38 |
| zyga | woodrowshen: which kernel are you running | 09:38 |
| woodrowshen | zyga: 3.10.37 | 09:38 |
| zyga | woodrowshen: and how did you install the system; did you build an all-snap (aka core) image or is this a distro running on your board and you just installed/compiled snapd there | 09:39 |
| zyga | woodrowshen: with 1GB of ram, are you running anything like a graphical UI there? | 09:39 |
| woodrowshen | zyga: https://github.com/xapp-le/SnappyUbuntuCore/blob/master/builder/build-snappy.sh | 09:41 |
| woodrowshen | zyga: i used this script to build it | 09:41 |
| zyga | woodrowshen: let me see | 09:41 |
| woodrowshen | zyga: no any graphics satck | 09:41 |
| woodrowshen | zyga: s/satck/stack/ | 09:41 |
| zyga | woodrowshen: aha, so it's an all-snap/core image | 09:42 |
| woodrowshen | zyga: yes, and previous images i had built didn't happen that. | 09:42 |
| zyga | woodrowshen: can you pastebin "top -b -n 1" | 09:43 |
| woodrowshen | zyga: i wonder if we have pastebin snap XDDD | 09:43 |
| zyga | woodrowshen: you can ssh in | 09:44 |
| zyga | woodrowshen: run that command | 09:44 |
| zyga | woodrowshen: and copy-paste | 09:44 |
| zyga | woodrowshen: (into something like pastebin.ubuntu.com | 09:45 |
| woodrowshen | zyga: http://paste.ubuntu.com/24359952/ | 09:45 |
| zyga | woodrowshen: does snap version run? | 09:47 |
| zyga | woodrowshen: or is that crashing too? | 09:47 |
| woodrowshen | zyga: no, the system still works normally. just snap commands will get stuck | 09:48 |
| tvoss | pedronis: mind having another look here: https://github.com/snapcore/snapd/pull/3130 | 09:48 |
| mup | PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130> | 09:48 |
| woodrowshen | zyga: even snap version | 09:48 |
| tvoss | pedronis: switched back ssh-keygen :) | 09:49 |
| woodrowshen | zyga: sorry fix the description, snap commands will get stuck for a while, and output "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: EOF" | 09:49 |
| zyga | right | 09:51 |
| Chipaca | woodrowshen— journalctl -u snapd.service | 09:52 |
| Chipaca | please | 09:52 |
| mvo | hm, unreleated - I think we need spread tests for the core options, I just got a failure trying to snap set core ystem.power-key-action - looks like we have no /etc/systemd/logind.conf.d directiory | 09:52 |
| zyga | woodrowshen: and after you get that log, can you systemctl restart snapd.service | 09:54 |
| zyga | woodrowshen: and see if memory usage drops | 09:54 |
| zyga | woodrowshen: and if you can run snap changes or what not | 09:54 |
| woodrowshen | Chipaca: http://paste.ubuntu.com/24359985/ | 09:54 |
| mvo | zyga: do you know if there is a way to allow only a single "mkdir" on a directory via apparmor. i.e. not full write but just mkdir? | 09:55 |
| Chipaca | woodrowshen— there you go then | 09:55 |
| Chipaca | woodrowshen— this is probably bug #1674778 | 09:56 |
| mup | Bug #1674778: snapd hangs with 100% CPU usage when image has a custom gadget snap <gadget> <snapd> <Snappy:Confirmed> <https://launchpad.net/bugs/1674778> | 09:56 |
| Chipaca | woodrowshen— IOW you probably have a bug in your gadget snap, and we have a bug in snapd where it OOMs on gadget snap weirdness | 09:56 |
| Chipaca | to be clear: “runtime: memory allocated by OS (0x7286e000) not in usable range [0x965c2000,0xffffffff)” | 09:57 |
| Chipaca | on a 32-bit system | 09:57 |
| Chipaca | means OOM | 09:57 |
| zyga | mvo: yes, directoy and stuff inside are separate | 09:57 |
| zyga | mvo: e.g. /path/to/dir w, | 09:57 |
| zyga | er | 09:57 |
| mvo | zyga: thanks, excellent | 09:57 |
| zyga | mvo: e.g. /path/to/dir/ w, | 09:57 |
| zyga | the trailing slash matters | 09:57 |
| zyga | try that as I suspect you need more than w in practice | 09:58 |
| Chipaca | mikeb_— you around? | 09:58 |
| woodrowshen | zyga: http://paste.ubuntu.com/24359994/ | 09:58 |
| zyga | right | 09:59 |
| woodrowshen | zyga: snapd cna't free the memory | 09:59 |
| woodrowshen | zyga: ok, i see. | 09:59 |
| mvo | zyga: thanks, running it locally now. I'm adding a test to ensure that snap set core after the transition *actually* really works and hit a bug :) | 09:59 |
| zyga | mvo: good call, outch, what bug? | 10:00 |
| zyga | Chipaca: what's the reason for the extra memory use, do you know? | 10:00 |
| Chipaca | zyga— no | 10:00 |
| Chipaca | somebody should look into that bug at some point :-) | 10:01 |
| zyga | Chipaca: maybe the hook hangs and we buffer something it says into memory? | 10:01 |
| Chipaca | mikeb_— I'm trying to reproduce the issues you're seeing, and I'm not being able to | 10:01 |
| Chipaca | zyga— we've seen the OOM also because the gadget asks for an interface it hasn't been granted | 10:01 |
| mvo | zyga: I push a PR once my local test finishes, but its not super critical, just adding it to really ensure all angles are tested | 10:01 |
| Chipaca | zyga— and because its assertion is signed with the wrong key | 10:02 |
| Chipaca | zyga— these things happen before the hook afaik | 10:02 |
| Chipaca | zyga— also afaict it's not spamming changes; there was a relatively low amount of changes at the time | 10:02 |
| zyga | aha | 10:02 |
| Chipaca | as i say, somebody needs to dig | 10:02 |
| zyga | yes, for sure | 10:02 |
| Chipaca | mikeb_— ah, i might be understanding one of the issues you mention now | 10:04 |
| * Chipaca looks further | 10:04 | |
| pedronis | Chipaca: do we know if it's reproducible on amd64? undoing a first boot install and OOM ? | 10:05 |
| mup | PR snapd#3173 opened: tests: add extra test after the core transition for snap get/set core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3173> | 10:06 |
| mvo | zyga: ^- thats the one I talked about | 10:06 |
| zyga | aha | 10:07 |
| woodrowshen | Chipaca: the last comment on bug said removing the interface on hook can fix the issue, but my gadget didn't use that like him | 10:11 |
| Mirv | bye bye | 10:11 |
| Mirv | I'll rejoin if I'll create snappy products | 10:11 |
| Chipaca | woodrowshen— that comment comes from a different thread and was posted to that bug in error | 10:11 |
| Chipaca | woodrowshen— while it is related, in that on second pass the gadget's yaml was wrong because it asked for that interface, it's not the only cause of the bug | 10:12 |
| Chipaca | woodrowshen— when the bug was first created, the OOM was because of bad signing | 10:12 |
| Chipaca | woodrowshen— at this point I believe any issues with the gadget snap will cause this | 10:13 |
| Chipaca | pedronis— I don't know | 10:13 |
| Chipaca | pedronis— should be easy to test with a core amd64 | 10:13 |
| woodrowshen | Chipaca: oh, indeed. | 10:13 |
| woodrowshen | Chipaca: how to define the "bad signing" | 10:14 |
| fgimenez | mvo: tests/main/interfaces-network-bind is failing with the latest edge i386 core (rev 1682), not sure if that's expected https://travis-ci.org/snapcore/spread-cron/builds/220883610#L731 | 10:15 |
| Chipaca | woodrowshen— model under one account, gadget under another | 10:15 |
| mvo | fgimenez: https://github.com/snapcore/snapd/pull/3172 will fix that | 10:17 |
| mup | PR snapd#3172: tests: fix interfaces-network-bind to match the new core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3172> | 10:17 |
| fgimenez | mvo: great thank you! | 10:17 |
| Chipaca | hmm, why is 'snap try' setting snapsup.Flags.RemoveSnapPath | 10:17 |
| zyga | mm | 10:18 |
| woodrowshen | Chipaca: hmmmm, got it. | 10:18 |
| zyga | Chipaca: feels wrong, right? | 10:19 |
| Chipaca | woodrowshen— there's an exception there where i think they don't have to match if canonical is the signer of one of those things | 10:19 |
| Chipaca | zyga— well, it doesn't break stuff, but prints an ugly warning | 10:19 |
| Chipaca | 2017/04/11 11:11:00.366879 handlers.go:299: Failed to cleanup /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: remove /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: directory not empty | 10:19 |
| zyga | Chipaca: worse, it feels like with a simple slip it could rm -rf your code | 10:20 |
| Chipaca | zyga— it's not a -r :-) | 10:21 |
| zyga | right | 10:21 |
| zyga | yet | 10:21 |
| Chipaca | found the issue, i think | 10:22 |
| mvo | zyga: looks like 3169 is failing, maybe a fluke? could you please have a look (spread still runnig but the failure is in the log) | 10:22 |
| zyga | checking | 10:24 |
| zyga | mvo: I have one thing I'd like to add, from last evening | 10:26 |
| Chipaca | mikeb_— looking into this is pointing out several little warts even before getting at the issues you're seeing (yay!) | 10:28 |
| pedronis | zyga: mvo: Error executing linode:ubuntu-14.04-64:tests/main/refresh-delta-from-core | 10:29 |
| Chipaca | mikeb_— wrt ordering though, there is no implicit ordering other than with the service that flags "the network is up" | 10:29 |
| Chipaca | and the mount unit that mounts the snap into place | 10:29 |
| zyga | pedronis: right, I'm looking it at it | 10:31 |
| mup | PR snapd#3172 closed: tests: fix interfaces-network-bind to match the new core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3172> | 10:31 |
| zyga | Apr 11 10:06:39 ubuntu snapd[4401]: 2017/04/11 10:06:39.614845 helpers.go:173: cannot connect plug "core-support" from snap "core", no such plug | 10:33 |
| zyga | this will never go away, we don't have a system where plugs change and we forget past connections | 10:33 |
| mvo | zyga: what do you want to add? | 10:34 |
| mvo | fwiw, from my POV 2.24 is now ready, 3169 is mostly a bonus for me | 10:35 |
| zyga | mvo: fine, not for 2.24 | 10:35 |
| zyga | mvo: debugging | 10:35 |
| mvo | zyga: feel free to add, the tests need to re-run anyway | 10:36 |
| zyga | mvo: something like this http://paste.ubuntu.com/24360222/ | 10:36 |
| zyga | mvo: + for slots, symmetrically | 10:36 |
| mvo | zyga: sounds good | 10:36 |
| mvo | zyga: and if things are ready after lunch it lands | 10:36 |
| mvo | otherwise… | 10:36 |
| zyga | mvo: surE :) | 10:36 |
| zyga | pedronis: that failed because: Apr 11 10:06:35 ubuntu /usr/lib/snapd/snapd[4213]: store.go:1264: DEBUG: Available deltas returned by store: [] | 10:37 |
| zyga | I'm checking what the test is doing now to see if that's expected | 10:37 |
| woodrowshen | Chipaca: so how can i help to track the issue ? | 10:41 |
| zyga | mvo: hrm hrm hrm, I think we need something for that dangling slot connectiong | 10:41 |
| zyga | *connection | 10:41 |
| zyga | not super critical but we should do somehing about it or it will stay forever | 10:41 |
| mvo | zyga: please add it to the 2.25 page | 10:42 |
| zyga | ok | 10:43 |
| zyga | mvo: so the failure you mentioned | 10:43 |
| zyga | mvo: if edge<->beta on core snap had no delta in the store then the failure is a fluke | 10:44 |
| zyga | https://github.com/snapcore/snapd/pull/3174 <- debugging | 10:45 |
| mup | PR snapd#3174: interfaces,overlord: log interface auto-connection failures <Created by zyga> <https://github.com/snapcore/snapd/pull/3174> | 10:45 |
| mup | PR snapd#3174 opened: interfaces,overlord: log interface auto-connection failures <Created by zyga> <https://github.com/snapcore/snapd/pull/3174> | 10:45 |
| zyga | mvo: this is failing now https://github.com/snapcore/snapd/pull/3173 | 10:52 |
| mup | PR snapd#3173: tests: add extra test after the core transition for snap get/set core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3173> | 10:52 |
| zyga | mvo: I think it needs one of the other branches after network-bind was reomved from core | 10:52 |
| zyga | re | 11:04 |
| mvo | zyga: ta, I add it now | 11:19 |
| mup | PR snapd#3169 closed: many: fix plug auto-connect during core transition <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3169> | 11:20 |
| zyga | thanks! | 11:22 |
| zyga | mvo: can you also merge https://github.com/snapcore/snapd/pull/3129 | 11:23 |
| mup | PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129> | 11:23 |
| zyga | mvo: it's harmless but I want that extra debug output there | 11:23 |
| mup | PR snapd#3129 closed: interfaces/mount: add InfoEntry type <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3129> | 11:25 |
| mvo | zyga: mixing the debug and the entry in a single PR is a bit unfortunate, lets try to have two next time. but its in, its harmless indeed | 11:26 |
| zyga | yeah, it's an old PR | 11:26 |
| zyga | I just wanted to merge that deubg output | 11:26 |
| zyga | mvo: I can move it to a separate PR if youwant | 11:26 |
| mvo | zyga: too much hassle and tests will take too long :/ | 11:26 |
| mvo | zyga: its ine | 11:26 |
| mvo | in | 11:26 |
| zyga | thanks! | 11:26 |
| zyga | ok, what's left for 2.24 | 11:27 |
| mvo | I prepare 2.24 now, so the window is almost closed if someone has some last minute things | 11:27 |
| * zyga looks | 11:27 | |
| mvo | its all in | 11:27 |
| zyga | woot! | 11:27 |
| zyga | great | 11:27 |
| mvo | I'm running 3173 locally just to feel good but in parallel prepare changelog tag etc | 11:28 |
| zyga | mvo: did you branch off master? | 11:28 |
| mvo | zyga: it was probably not current | 11:28 |
| zyga | I mean, for the release | 11:29 |
| zyga | I'd like to land approved thins with 2+1s | 11:29 |
| zyga | (for 2.25) | 11:29 |
| mvo | zyga: lets wait a tiny bit, I branched locally so I guess its ok | 11:29 |
| zyga | OK | 11:30 |
| mvo | zyga: what branches do you have in mind? I think we need to go over the previous 2.24 now that network-bind is no longer used and fix those | 11:30 |
| zyga | https://github.com/snapcore/snapd/pull/3153 | 11:30 |
| mup | PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153> | 11:30 |
| zyga | I'll just enjoy the sun and get back to update-ns code | 11:30 |
| mvo | zyga: sounds good, I will merge master into 3153 in the meantime to ensure we have no surprises (but I think we won't) | 11:31 |
| pedronis | mvo: yea, tomorrow I would like to start merging some of the aliases stuff that will need the move completed before we can release again | 11:41 |
| pedronis | zyga: 3145 can be closed now? | 11:42 |
| pedronis | mvo: so we didn't rename the plug in the end for 2.24? I see all the rename PRs in 2.25 | 11:45 |
| zyga | pedronis: checking | 11:46 |
| zyga | pedronis: yes, I believe so | 11:47 |
| mup | PR snapd#3145 closed: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3145> | 11:47 |
| mup | PR snapd#3175 opened: daemon: do not set RemoveSnapPath flag when doing a try <Created by chipaca> <https://github.com/snapcore/snapd/pull/3175> | 11:47 |
| mvo | pedronis, zyga: https://github.com/snapcore/snapd/pull/3154 this one got in | 11:50 |
| mup | PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3154> | 11:50 |
| pedronis | mvo: so only 3160 left ? | 11:53 |
| mvo | pedronis: it looks like it yes, but it also still has network-bind in there which needs updating. but I think we can go out with 2.24 without it, or am I missing something? | 11:54 |
| mvo | pedronis, zyga: also in 3154 we also rename network-bind, this can now be removed I think | 11:55 |
| pedronis | mvo: I don't know :) too many moving parts, maybe zyga has a better idea there | 11:55 |
| zyga | mvo: yes, I will follow up and remove it | 11:55 |
| zyga | pedronis: haha, you think too highly of me, | 11:56 |
| zyga | pedronis: let me see | 11:56 |
| zyga | aha | 11:56 |
| mvo | pedronis: I'm pretty sure things are fine (within the limits we set) and the migration works and no surprises, I think we can do the remaining bits for 2.25 | 11:56 |
| mvo | but I will let zyga double check :) | 11:56 |
| zyga | that one, I think it's not really needed anymore because we auto-connect the plug correctly now | 11:56 |
| mvo | thats my understanding as well | 11:57 |
| zyga | I'd tweak it to remove the core network-bind connection as it's just garbage now (and it will stay annoying forever) | 11:57 |
| mup | PR snapd#3176 opened: snapcraft.yaml can come in many guises now <Created by chipaca> <https://github.com/snapcore/snapd/pull/3176> | 12:01 |
| Chipaca | mikeb_— ping | 12:04 |
| icey | so, the issue I was having with Rust binaries isn't because of linking to the wrong thing: https://pastebin.ubuntu.com/24360512/ | 12:07 |
| icey | if sergio were here, I'd ping him... | 12:07 |
| pedronis | mvo: yes I see more clearly what landed, yes seems it's a consistent set | 12:07 |
| ogra_ | icey, try rocket.ubuntu.com instead | 12:08 |
| icey | yeah but that means authing to _one more thing_ :-/ | 12:08 |
| icey | and he doesn't seem to be in there either :_/ | 12:09 |
| icey | fail | 12:09 |
| Chipaca | zyga— run-snapd-ns-snappy\x2ddaemon\x2ddemo.mnt.mount loaded active mounted /run/snapd/ns/snappy-daemon-demo.mnt | 12:09 |
| Chipaca | zyga— why is that left behind when the snap failed to install? | 12:09 |
| === chihchun is now known as chihchun_afk | ||
| zyga | Chipaca: interesting, is anything else left behind? | 12:12 |
| zyga | Chipaca: e.g. apparmor profile? | 12:12 |
| zyga | Chipaca: this should go away the same way as apparmor profiles | 12:12 |
| zyga | Chipaca: but maybe there's a bug | 12:12 |
| * zyga looks | 12:12 | |
| mvo | pedronis: thanks a lot for double checking | 12:12 |
| zyga | Chipaca: ohhh | 12:12 |
| zyga | Chipaca: we don't write .mount files | 12:13 |
| zyga | ah | 12:13 |
| zyga | sorry | 12:13 |
| * zyga is so dumb | 12:13 | |
| zyga | I confused this entirely | 12:13 |
| zyga | Chipaca: that file is harmless | 12:13 |
| zyga | Chipaca: we don't remove them because there's no need | 12:13 |
| zyga | Chipaca: we discard the namespace but we don't unlink | 12:13 |
| Chipaca | a bunch of /var/lib/lxcfs stuff :-) but that's probably not our fault | 12:13 |
| zyga | Chipaca: that file should be empty | 12:13 |
| zyga | Chipaca: and should be (if you stat -f it) not nsfs or proc | 12:14 |
| Chipaca | and a lockfile and some apparmor stuff | 12:14 |
| zyga | Chipaca: apparmor stuff? | 12:14 |
| Chipaca | type: nsfs | 12:14 |
| zyga | Chipaca: interesting | 12:14 |
| Chipaca | that's for /run/snapd/ns/snappy-daemon-demo.mnt | 12:14 |
| zyga | Chipaca: so it's a namespace that lives on | 12:15 |
| zyga | Chipaca: did we remove the snap? | 12:15 |
| Chipaca | zyga, yes, the snap failed to install | 12:15 |
| zyga | Chipaca: looks like an omission then | 12:15 |
| * zyga looks | 12:16 | |
| Chipaca | and a bunch of /sys/kernel/security/apparmor/policy/profiles/snap.snappy-daemon-demo.* things | 12:16 |
| Chipaca | but those might be because apparmor is append-only or something | 12:16 |
| Chipaca | dunno | 12:16 |
| zyga | doDiscardSnap should remove that | 12:16 |
| zyga | Chipaca: those should be removed as well | 12:16 |
| zyga | feels like a bug mr Chipaca :) | 12:16 |
| Chipaca | zyga— well it doesn't, at least when a 'snap try' fails | 12:16 |
| zyga | Chipaca: can you show me snap change for this number? | 12:17 |
| Chipaca | which number? | 12:17 |
| zyga | of the change that installed it | 12:17 |
| Chipaca | zyga— http://pastebin.ubuntu.com/24360558/ | 12:17 |
| zyga | Chipaca: so we only discard in doDiscardSnap (discard-snap) | 12:19 |
| zyga | pedronis: if the initial install of a snap fails we should clean up after it | 12:20 |
| zyga | pedronis: trying to figure out which task should do it | 12:21 |
| zyga | Chipaca: what is odd is that we undone setup security profiles | 12:21 |
| zyga | Chipaca: but the profile is still there | 12:21 |
| Chipaca | niemeyer— any objection to allowing use of "last" as a change id that gets the last change? | 12:21 |
| zyga | Chipaca: is /var/lib/apparmor/profiles/ also full of leftovers? | 12:21 |
| Chipaca | zyga— sounds like the undo doesn't | 12:21 |
| zyga | Chipaca: well, I bet it does but I bet something is missing :) | 12:22 |
| Chipaca | zyga— that directory is empty | 12:22 |
| Chipaca | (i've got 3 snaps installed) | 12:22 |
| Chipaca | zyga— i think you meant /var/lib/snapd/apparmor/profiles | 12:22 |
| Chipaca | zyga— and i've got some garbage there, but nothing related to this | 12:23 |
| Chipaca | (it seems when i was trying out the bcc snap we weren't cleaning this up after ourselves or something) | 12:23 |
| zyga | Chipaca: yes, sorry | 12:23 |
| pedronis | zyga: the undo of each tasks in the install | 12:24 |
| zyga | pedronis: here it is tricky, what needs to (maybe) be undone is a result of the configure hook | 12:27 |
| zyga | pedronis: but only if this is the only revision | 12:27 |
| zyga | pedronis: (discarding the namespace) | 12:27 |
| pedronis | of the hook? | 12:27 |
| pedronis | you mean sideeffects or running the hook? | 12:27 |
| zyga | of the snap (it's global to the snap) | 12:27 |
| mup | Bug #1681833 opened: Devmode Edge Snap not automatically updating <Snappy:New> <https://launchpad.net/bugs/1681833> | 12:27 |
| zyga | here it looks like configure hook failed | 12:27 |
| zyga | so installation stopped there | 12:27 |
| pedronis | you we undid everything before that | 12:28 |
| zyga | but the bug is that at this time we're essentially erasing the snap existence | 12:28 |
| pedronis | yea | 12:28 |
| zyga | we don't discard the namespace/connections though, apparently | 12:28 |
| pedronis | connections? | 12:28 |
| zyga | we only do that in discard-snap | 12:28 |
| zyga | pedronis: "conns" in state | 12:28 |
| pedronis | ah | 12:28 |
| zyga | right | 12:28 |
| zyga | which is only done if we're removing a snap | 12:28 |
| pedronis | well something is wrong then | 12:28 |
| zyga | so there's assymetry | 12:28 |
| pedronis | zyga: there's a discard-conns task actually | 12:29 |
| zyga | pedronis: we do that when removeAll is set | 12:30 |
| pedronis | yes | 12:30 |
| pedronis | but that's not relevant | 12:30 |
| pedronis | it needs to be done in some relevant undo | 12:30 |
| pedronis | we don't do more tasks when something fails | 12:30 |
| zyga | pedronis: I yes, I think som | 12:30 |
| pedronis | we just undo things | 12:30 |
| Chipaca | https://forum.snapcraft.io/t/rfc-easy-way-to-get-last-change/246?u=chipaca <- RFC thing | 12:30 |
| zyga | pedronis: right | 12:30 |
| Chipaca | mup— you could preview forum links, couldn't you | 12:30 |
| zyga | pedronis: I think we should graph what tasks are added in install/remove see if something is missing | 12:31 |
| zyga | pedronis: I don't fully grok the extra cases that are there | 12:31 |
| pedronis | zyga: well what we do in other places would be do something in remove-profiles if we are the last revision standing | 12:32 |
| pedronis | instead of an extra task | 12:32 |
| pedronis | I'm not sure why we have the extra task | 12:32 |
| zyga | pedronis: I agree it should be something like that | 12:32 |
| pedronis | I don't think I worked on that afair | 12:32 |
| zyga | pedronis: I'll spend some time graphing this on paper and post in the forum | 12:33 |
| pedronis | zyga: fwiw clear-aliases is going away in the new world | 12:33 |
| zyga | FYI I simplified https://github.com/snapcore/snapd/pull/3160/files | 12:34 |
| mup | PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160> | 12:34 |
| dragly | What is the current status of snap dependencies? Is or will it be possible to have a snap depend on a specific version of a different snap as a library? | 12:37 |
| zyga | dragly: no, can you tell me why you would like to have that? | 12:37 |
| zyga | dragly: the content interface can be used to do that to some extent but I bet some edge cases are still very rough | 12:38 |
| dragly | To reduce the size of snap packages. | 12:38 |
| zyga | dragly: note that the content interface is something only snaps from one publisher can use | 12:38 |
| zyga | dragly: with the exception of snaps that are blessed in the store, where anyone can share them | 12:39 |
| dragly | Just curious about how far snaps are thought to go in terms of replacing apt in the long run. | 12:39 |
| zyga | dragly: so if you upload a snap | 12:39 |
| zyga | dragly: and then a 2nd one | 12:39 |
| zyga | dragly: and you want to share some libraries between the two | 12:39 |
| zyga | dragly: you can make a third snap with those libraries | 12:39 |
| jdstrand | mvo: allowing write on a dir> the best you can do is '/path/to/dir/ w,' (the trailing '/' is important). that does allow changing the inode data too though (eg, perms, ownership) | 12:39 |
| zyga | dragly: and update either or both of the first two snaps to useit | 12:39 |
| mvo | jdstrand: thanks, that is what I used now | 12:40 |
| zyga | dragly: but, the key is that youare in control of the three snaps still | 12:40 |
| dragly | zyga: I see. That sounds like a reasonable middle way. | 12:40 |
| zyga | dragly: the exception is for "blessed" snaps (not a strict term) | 12:40 |
| zyga | dragly: where e.g. the qt project publishes a polished snap that they say they will responsibly update | 12:40 |
| zyga | dragly: and that the ABIs are stable and what not | 12:40 |
| zyga | dragly: and that snap can have an assertion that says anyone can now use it for content sharing | 12:41 |
| zyga | dragly: we don't have any better mechansims yet but remember that there was never any plan to do dpkg/apt granularity packages | 12:41 |
| zyga | dragly: I think as the content interface matures we'll have more option | 12:42 |
| dragly | Qt was exactly the project I was thinking of. We have a couple of large snaps because we include a bit too much of Qt. | 12:42 |
| zyga | dragly: but for now what's what we offer | 12:42 |
| zyga | dragly: I would encourage you to make your own shared qt snap for now | 12:42 |
| zyga | dragly: and experiment with this | 12:42 |
| zyga | dragly: it's not perfect | 12:42 |
| zyga | dragly: I'm hoping to make big improvement in 2.25 | 12:42 |
| zyga | dragly: (there are cases now where it will not work well) | 12:42 |
| zyga | dragly: but this is the "taste" of the idea | 12:42 |
| zyga | dragly: once qt project publishes a snap you could evaluate and switch to it | 12:43 |
| dragly | Sounds good. What is your take on the issues of bundling say crypto libraries in a snap that might need security updates? | 12:43 |
| zyga | dragly: same as everything else | 12:43 |
| zyga | dragly: it's just something someone needs to update | 12:43 |
| zyga | dragly: if it's not updated it doesn't matter (it's broken) | 12:43 |
| zyga | dragly: if it gets updated that's good | 12:43 |
| zyga | dragly: it's never perfect | 12:43 |
| zyga | dragly: note that some libraries are available in the core snap | 12:44 |
| zyga | dragly: if the ssl project starts publishing a ssl runtime snap | 12:44 |
| zyga | dragly: and commit to maintaining it | 12:44 |
| zyga | dragly: people can use it | 12:44 |
| zyga | dragly: otherwise snapcraft can offer some features | 12:44 |
| zyga | dragly: where you can just rebuild it | 12:44 |
| zyga | dragly: (the snap you are building) | 12:44 |
| zyga | dragly: and include updated ssl (again, just an exapmle) | 12:44 |
| dragly | Sounds like that would solve most issues. I understand that this is a really hard balance to keep between containerized packages and shared packages for reduced size and security updates. | 12:45 |
| zyga | dragly: also the impact of an update | 12:45 |
| zyga | dragly: maybe the update actually breaks your snap | 12:45 |
| dragly | Yes, I guess that has been the biggest issue with shared packages like dpkg or conda. | 12:46 |
| mup | PR snapd#3177 opened: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 12:47 |
| dragly | One wants the security updates, but not the breaking API changes. | 12:47 |
| zyga | dragly: sometimes it's not possible | 12:47 |
| morphis | mvo: can you mark https://github.com/snapcore/snapd/pull/3177 for 2.25? | 12:48 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 12:48 |
| dragly | zyga: Do you have some thoughts on NixOS and similar "everything-is-a-package-version" distros? | 12:48 |
| zyga | dragly: they advance a lot of the theory and some of the tooling, I'm happy to see them | 12:48 |
| zyga | dragly: e.g. reproducible builds initiative in general is very valuable for trust | 12:49 |
| zyga | dragly: otherwise I think we are putting a different idea forward | 12:49 |
| dragly | do you think much of that will be merged into Ubuntu's snap+dpkg ecosystem? | 12:49 |
| zyga | dragly: not really, not at a whole distro level | 12:50 |
| zyga | dragly: I think reproducible builds will spread across all binary distributions though | 12:50 |
| zyga | dragly: that part is really generic, important and in progress across the landscape | 12:50 |
| dragly | that's good | 12:51 |
| morphis | Son_Goku: I don't have a good fix yet for the libtool/static linking problem | 12:51 |
| morphis | Son_Goku: the best we can do for now is to drop all other patches and just keep the one for libtool support once we update to 2.24 | 12:51 |
| zyga | dragly: snaps aim to be practical | 12:51 |
| zyga | dragly: ship software now, iterate, improve, learn | 12:52 |
| dragly | As an application developer, I find the idea of NixOS intriguing, but the target audience is of course way bigger for snap packages. | 12:52 |
| zyga | I think it's like with all research and business | 12:52 |
| zyga | dragly: forget snaps, look at all the linux packaging formats and the play store | 12:52 |
| zyga | dragly: it's clear that you can ship a zip file and win ;) | 12:53 |
| zyga | dragly: and the rest is irrelevant at large | 12:53 |
| dragly | excactly | 12:53 |
| dragly | zyga: and in terms of security, I guess containerization is of greater importance than many other issues | 12:55 |
| zyga | dragly: yes, the old trust model is not realistic, I think | 12:55 |
| dragly | zyga: no. I'm looking forward to be able to download more binaries with less worry about their origin. | 12:57 |
| zyga | (old trust model == manually reviewed software from trustworthy developers) | 12:58 |
| * zyga -> call | 12:58 | |
| dragly | ah, I see. I was thinking more along the lines of trusting some random site which gives you a binary to download. | 12:58 |
| mup | PR snapd#3178 opened: Release 2.24 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3178> | 13:01 |
| zyga | dragly: that is even worse :) I was referring to the change from trusted source / binary to untrusted binary and sandboxing | 13:07 |
| mup | PR snapcraft#1248 opened: snap: include asset tracking details in snap/snapcraft.yaml <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1248> | 13:07 |
| mup | PR snapcraft#1249 opened: Add Linux Mint support <Created by nefelim> <https://github.com/snapcore/snapcraft/pull/1249> | 13:16 |
| === chihchun_afk is now known as chihchun | ||
| mvo | fgimenez: sorry to push more work towards you but do you think you could put the verification for https://bugs.launchpad.net/snapd/+bug/1673568 on your todo please? | 13:34 |
| mup | Bug #1673568: snapd 2.23.6 SRU tracking bug <verification-needed> <snapd:New> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1673568> | 13:34 |
| fgimenez | mvo: sure np, will let you know how it goes | 13:36 |
| mvo | fgimenez: thanks! | 13:36 |
| mup | PR snapd#3176 closed: snapcraft.yaml can come in many guises now <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3176> | 13:53 |
| mup | PR snapd#3153 closed: interfaces: validate plug/slot uniqueness <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3153> | 14:09 |
| Chipaca | Apr 11 15:26:17 fogey snap[29722]: cannot snap-exec: cannot read info for "snappy-daemon-demo": stat /var/lib/snapd/snaps/snappy-daemon-demo_x1.snap: no such file or directory | 14:27 |
| mup | PR snapd#3179 opened: packaging: add `built-using` header for 16.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3179> | 14:27 |
| Chipaca | I hope that's not what I think that is :-( | 14:27 |
| mpt | Hi, in “track/risk/branch” for channel names, what does “branch” refer to? <https://forum.snapcraft.io/t/channels-2-0-implementation/156> facubatista mvo | 14:28 |
| davidcalle | facubatista: ^ | 14:28 |
| davidcalle | (oh sorry, didn't noticed you were pinged already) | 14:29 |
| mvo | mpt: hey, nice to see you! facubatista is probably the better person to answer, but my understanding is that this is a new store feature that allows to open "branches" with arbitrary names (like latest/stable/hotfix-for-lp1334) | 14:30 |
| facubatista | mpt, the branch is a kind of "sub channel" for the "stable" channel, that will allow people to release temporary fixes | 14:31 |
| mvo | mpt: AIUI those will not be surfaced in snap info, someone need to tell you about the branch. but I was not in this paricular design meeting so take it with a slight grain of salt :) | 14:31 |
| facubatista | mpt, the names are arbitrary, you can just release into them, but after 30 days they will be removed (or you can remove them before, when the fix is integrated into stable) | 14:31 |
| === chihchun is now known as chihchun_afk | ||
| facubatista | mpt, there's a bigger doc explaining better, we're just holding off the formal announcement until all tools properly support them | 14:32 |
| facubatista | mpt, in any case, I can answer any question you have | 14:35 |
| mpt | mvo, nice to see you too :-) | 14:42 |
| Chipaca | jdstrand, daemons of type "notify" need to talk to /run/systemd/notify. Is that added anywhere? Is this anywhere on your radar? | 14:43 |
| mpt | facubatista, thank you. So as I understand it at the moment, snaps are (about to be) four-dimensional: each combination of {channel × track × branch × architecture} can have a different binary in it. Is that correct? | 14:44 |
| mpt | Or maybe more accurately, the store is four-dimensional | 14:44 |
| jdstrand | Chipaca: it isn't and no | 14:45 |
| Chipaca | jdstrand— noted and noted | 14:45 |
| Chipaca | niemeyer— i'm struggling a little bit with when to file bugs in launchpad and when to opne a new topic in the forum | 14:47 |
| Chipaca | niemeyer— so if you see i'm doing it wrong, shout :-) | 14:47 |
| morphis | zyga: I am going to play around with the unshared /etc tomorrow or did you already started that work? | 14:47 |
| facubatista | mpt, it's tricky, you don't have a whole "product" on branch, as branches only exist for the stable channel | 14:47 |
| niemeyer | Chipaca: If you need coordination across teams, Launchpad.. if you want awareness and a nice conversation about it, forum.. if you want both, both :) | 14:48 |
| zyga | morphis: I have a trivial branch but nothing useful, just comment out /etc and see what happens | 14:48 |
| zyga | er | 14:48 |
| zyga | well, roughly so | 14:48 |
| mpt | facubatista, so you can’t have a branch for a custom channel, then | 14:48 |
| facubatista | mpt, we consider it four-dimensional, yes, but channel x track x architecture x series (series == release), being branches a special case of stable channel | 14:49 |
| facubatista | mpt, what do you mean with "custom channel"? | 14:49 |
| facubatista | mpt, we have pre-fixed channels (edge, beta, candidate, stable) and you can only create branches for "stable" (in any track, though) | 14:50 |
| mpt | Oh, right, so branches *are* the custom channels | 14:50 |
| mpt | Ok, I misunderstood | 14:50 |
| facubatista | mpt, mmm... I don't know if call it like that... "custom channel" sounds like you could add a fifth or sixth channel to the well defined risk sequence (edge, beta, candidate, stable) | 14:51 |
| mpt | facubatista, I was just copying mvo’s phrase in my link above, “This allow publishers to go beyond the current 4 channels we offer and provide custom channels” | 14:52 |
| facubatista | mpt, yes, they're custom in the sense that you can arbitrarily name them, but are more "sub channels from stable" | 14:52 |
| mpt | understood | 14:52 |
| facubatista | mpt, :) | 14:53 |
| mpt | facubatista, but this is the first time I’ve heard of series for the store. What is that? | 14:53 |
| facubatista | mpt, the "release": 16, 18, etc | 14:53 |
| facubatista | mpt, it's a name mess, because originally you didn't "publish an upload", you "released it", so name colision was high :/ | 14:54 |
| * zyga has mild food poisoning, ttyl :/ | 14:55 | |
| mpt | facubatista, thank you. One more question for now: Is there an existing UI design doc on how (any of) these should be presented to uploaders? | 14:56 |
| jdstrand | zyga: :( feel better | 14:56 |
| zyga | fresh juice, sometimes not healthy | 14:56 |
| facubatista | mpt, presented in the web ui or in the command line tools? so far, we're all using the slash-separated names, and everybody seems to understand it perfectly... so, for example, you could "snapcraft release" to 2.2/candidate, or stable/hotfix3, etc | 14:58 |
| mpt | facubatista, Web UI | 14:58 |
| morphis | zyga: ok, will play a bit with that | 14:59 |
| facubatista | mpt, for the web ui we're using the slash separated names to present the channels... I don't think the web ui is ready to actually release into tracks or branches, it's holding a little back and not given priority... in any case, there's no design that I'm aware of | 14:59 |
| mpt | ok, thanks again | 15:00 |
| facubatista | mpt, no problem | 15:00 |
| morphis | mvo: was there anything which was blocking https://github.com/snapcore/snapd/pull/2592 other than missing time from your side? | 15:00 |
| mup | PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592> | 15:00 |
| mvo | morphis: a little bit of extra work, we need to generate the host /etc/dbus.d configuration automatically for the re-exec case | 15:01 |
| mvo | morphis: otherwise I think its good | 15:01 |
| mvo | morphis: why? is that something you want to see? | 15:01 |
| qengho | fg | 15:02 |
| qengho | bah | 15:02 |
| morphis | mvo: would be nice to have, I can have a look if you want | 15:03 |
| zyga | morphis: I think that it would be nice to get to a point where we can run unit tests and spread tests on debian and fedora equally; we still have a lot of catch-up to do | 15:04 |
| morphis | zyga: yeah, I finalizing the first round for a debian setup | 15:05 |
| morphis | fedora is next on my list | 15:05 |
| morphis | just need some lines of real code in between instead of writing shell scripts all the day .. :-) | 15:05 |
| morphis | niemeyer: by that chance, from what I've heard you are the one who can help me to get a debian-9 image on our linode farm, right? | 15:06 |
| niemeyer | morphis: Yes! Thanks for working on that | 15:06 |
| morphis | niemeyer: np, its time for that :-) | 15:06 |
| niemeyer | morphis: Please open a topic on the forum and I'll follow up with instructions | 15:06 |
| morphis | niemeyer: aye | 15:06 |
| mvo | morphis: I would not say no, I think the way to model this is similar to the appamor host file writing, let me look for the code | 15:11 |
| mvo | morphis: lets talk tomorrow morning, I think there is little left to do for this feature | 15:12 |
| morphis | mvo: sounds good | 15:12 |
| morphis | niemeyer: https://forum.snapcraft.io/t/extending-ci-for-snapd-to-debian-fedora/250 | 15:14 |
| niemeyer | morphis: Thanks! Will reply after lunch.. biab | 15:17 |
| morphis | niemeyer: thanks! | 15:17 |
| zyga | morphis: some comments on https://github.com/snapcore/snapd/pull/3177/ | 15:21 |
| mup | PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177> | 15:21 |
| morphis | zyga: thanks | 15:22 |
| zyga | morphis: very rough feedback so far, let's iterate and I'll help you out | 15:23 |
| morphis | zyga: let me rework those tomorrow | 15:23 |
| zyga | morphis: thanks! | 15:24 |
| zyga | morphis: can you please merge master into https://github.com/snapcore/snapd/pull/3170 | 15:41 |
| mup | PR snapd#3170: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170> | 15:41 |
| === chihchun_afk is now known as chihchun | ||
| === jgrimm is now known as jgrimm-away | ||
| ogra_ | hey suhamera | 16:17 |
| suhamera | hi | 16:17 |
| suhamera | i'm trying to run Ubuntu Core on my DragonBoard 410c | 16:17 |
| zyga | suhamera: hey | 16:17 |
| * zyga feels mildly sick but better | 16:17 | |
| ogra_ | we dont really have any way to install the core image to the MMC.... and the dragonboard is a bit tricky in that regard | 16:17 |
| suhamera | :) | 16:18 |
| suhamera | but is any way to do it? | 16:18 |
| zyga | niemeyer: hey, can you re-review https://github.com/snapcore/snapd/pull/3095 please | 16:18 |
| mup | PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095> | 16:18 |
| ogra_ | specifically because the little-kernel hardcodes the boot device, so you cant just dd an img to the MMC device | 16:18 |
| ogra_ | you would have to dd partition for partition and leave out the lk one | 16:18 |
| zyga | niemeyer: I think that if this lands today I could do a full cycle, for subset of problems, tomorrow | 16:18 |
| niemeyer | zyga: Responding to Simon and have a call in 10 mins, happy to do right after that | 16:18 |
| suhamera | yes, i've tried it with no success | 16:18 |
| zyga | niemeyer: thank you! | 16:19 |
| zyga | suhamera: you'd need an installer that copies a core image to nand | 16:19 |
| zyga | suhamera: otherwise sure, why not | 16:19 |
| ogra_ | s/nand/MMC/ | 16:19 |
| suhamera | ogra_ so what will the difference with dd? | 16:22 |
| suhamera | the image will be the same? | 16:22 |
| ogra_ | suhamera, you would need to dd each partiton from the SD to the equivalent partition on the MMC, leaving out aboot (which holds the lk) ... and indeed that only works if the partition sizes match (which they probably do not) | 16:23 |
| ogra_ | well ... | 16:23 |
| mpt | Someone should make an app that installs a random snap, launches it, and takes a screenshot | 16:32 |
| mpt | They could call it … Snapshot | 16:32 |
| mpt | I’m so sorry | 16:32 |
| === JanC_ is now known as JanC | ||
| morphis | davidcalle: thanks for writing https://insights.ubuntu.com/2017/04/11/snap-support-lands-in-fedora-24-25-26 ? | 16:39 |
| morphis | s/?/!/ | 16:40 |
| morphis | niemeyer: didn't read through your reply in detail yet, but do I need access to linode for that? | 16:43 |
| Croepha | Hello | 17:03 |
| === alan_g is now known as alan_g|EOD | ||
| Croepha | for Core, is there a bank of debug symbol files? specifically /lib/x86_64-linux-gnu/libm.so.6 with build id: 9247f19167971267b6fadf4ba633290188a5483b core_394.snap doesn't seem to match any version of that file in ubuntu... (apt-file search b6fadf4ba633290188a5483b yielded no results...) | 17:07 |
| ogra_ | 394 ? | 17:08 |
| ogra_ | thats pretty ancient | 17:08 |
| Croepha | I only update everyone once and a while, its too much of a moving target | 17:09 |
| ogra_ | erm ... it auto-updates itself usually | 17:09 |
| Croepha | if you are saying that newer version would have debug symbols then that would be another thing | 17:09 |
| ogra_ | no | 17:09 |
| Chipaca | Croepha— how have you disabled updates? | 17:10 |
| ogra_ | if we'd ship debug symbols the package would be huge ... :) | 17:10 |
| Croepha | I agree that i should update, but Ive already been burned by an update once before, making me rework some things, so, I haven't made updating a priority, until I get closer to being finished with all of my parts | 17:11 |
| Croepha | Chipaca, no DNS entry | 17:11 |
| Chipaca | ogra_— how're they handled in ubuntu anyway? i thought they were 'automatic' | 17:11 |
| Chipaca | ogra_— but i don't really know what that means | 17:12 |
| Chipaca | other than there not being a -dbg package | 17:12 |
| ogra_ | Croepha, well, given that ubuntu core is rolling not upgrading is not really wise | 17:12 |
| Chipaca | ogra_— he's not disabled it! just extreme revision vetting | 17:12 |
| ogra_ | Croepha, but anyway ... https://launchpadlibrarian.net/291962392/core_16.04.1_amd64.manifest is the manifest file of 402 (we dont have one for 94, but this should have the same libm) | 17:13 |
| ogra_ | Chipaca, i thought via DNS hacking ? | 17:13 |
| niemeyer | morphis: You need to have a Linode key.. the same you use for running your spread tests | 17:13 |
| niemeyer | morphis: Do you have one? | 17:13 |
| ogra_ | s/94/394/ | 17:13 |
| Croepha | im not saying I won't update, or am advocating not updating as a good thing, its just like when you are working on a car, its best if its not rolling down the highway whilst your under it | 17:14 |
| Chipaca | Croepha— aw, where's the fun in that? | 17:14 |
| ogra_ | Croepha, what you can do is to bind-mount the libm binary with dbg symbols on top of the actual libm in the readonly core | 17:14 |
| ogra_ | Croepha, well, the system is designed in a way that each single part should be upgradeable on its own without breaking | 17:15 |
| ogra_ | Croepha, if anything breaks, that is definitely a bug we need to know about | 17:15 |
| Croepha | ogra_, I agree completely, but what im saying is that when you are working with custom stuff, sometimes it helps freeze everything that you aren't working on.... its so frustrating when you are working on stuff, and the system is changing beneath you without you knowing... even little things like the default location of a file or the size of something in memory... | 17:20 |
| Chipaca | I agree | 17:20 |
| Chipaca | when you're building stuff, if something you don't control changes, it sucks | 17:20 |
| Chipaca | because then you don't know if failures are yours, or some random change in the thing that changed | 17:21 |
| Chipaca | so you separate those: change your stuff until it works, then upgrade the system, repeat | 17:21 |
| Chipaca | right? | 17:21 |
| ogra_ | well, but 394 is really ancient ... updating and noticing that you can throw away half your work because the system changed in large amounts is equally bad | 17:21 |
| Croepha | I am 100% for updates, and I think that Snappy Core is awesome in the way it does updates, and agree that it helps solve a lot of compatibility changes | 17:22 |
| Chipaca | yeah, 394 sounds like an iteration takes 6+ months :-) | 17:22 |
| Croepha | ogra_, well, I guess, I could update more often :) | 17:22 |
| ogra_ | 394 was around november ... | 17:22 |
| Croepha | Chipaca, yeah, its been a slow ride working on this stuff | 17:22 |
| Croepha | or im really slow... | 17:23 |
| ogra_ | http://people.canonical.com/~ogra/core-builds/ ... (doesnt have manual builds, seems 394 was one) | 17:23 |
| Chipaca | 394 is probably ubuntu-core, not core | 17:23 |
| pedronis | 394, sounds very ancient, wonder what snapd version is inside that | 17:23 |
| ogra_ | oh, yeah, even that | 17:23 |
| Croepha | core 16.04.1 394 canonical - | 17:24 |
| ogra_ | ah, phew | 17:24 |
| Chipaca | ah! cool :-) | 17:24 |
| Chipaca | still, so many bugs fixed :-D | 17:24 |
| ogra_ | but still, what pedronis said applies ... | 17:24 |
| ogra_ | snapd might be rather feature-less | 17:24 |
| Chipaca | Croepha— what does "snap version" say? | 17:24 |
| ogra_ | or have features that have long changed | 17:24 |
| Croepha | snap 2.17 snapd 2.17 series 16 | 17:25 |
| ogra_ | woah | 17:25 |
| Chipaca | :-) | 17:25 |
| pedronis | well, newer than 2.0.10 | 17:25 |
| ogra_ | heh | 17:25 |
| Chipaca | yep | 17:25 |
| pedronis | so middle ages instead of antiquity :) | 17:25 |
| ogra_ | pre-re-exec ... | 17:26 |
| Chipaca | ogra_— 2.0.10 had re-exec | 17:26 |
| Croepha | lol, ok you have convinced me to update at earliest connivence | 17:26 |
| Chipaca | ogra_— 2.17 is post-un-re-exec | 17:26 |
| ogra_ | Chipaca, and then dropped it | 17:26 |
| pedronis | there's no pre and after rexecec | 17:26 |
| pedronis | because we turned it off and then on again | 17:26 |
| niemeyer | zyga: reviewed | 17:26 |
| ogra_ | yeah, only on-off-re-exec | 17:26 |
| Chipaca | 5 months, 1 wee ago | 17:27 |
| Chipaca | week* | 17:27 |
| Chipaca | Submission date | 17:27 |
| Chipaca | 2016-11-02 11:55 - 5 months, 1 week ago | 17:27 |
| Chipaca | ogra_— https://myapps.developer.ubuntu.com/dev/click-apps/6021/rev/394/ | 17:27 |
| ogra_ | yeah | 17:27 |
| Croepha | just to give you guys a peek into why i don't want to update all the time, is that in the past there has been issues with versioning of the core, and the ubuntu-image tool and snapcraft, and right now I know that all of those tools work together with the current versions of things, and when I update, then I will basically have to update all the other things... Also, I have sort of cobbled together a really odd build iteration routine... instead | 17:30 |
| Croepha | of using snapcraft, I just use a prime directory, and build straight to it, and I rsync over the prime dir to the ubuntu core system.... this is much faster than running snapcraft every iteration | 17:30 |
| Chipaca | Croepha— sergiusens and/or kyrofa might be interested in that | 17:31 |
| Chipaca | Croepha— (otoh i think snapcraft has done some work around making things quicker) | 17:31 |
| === chihchun is now known as chihchun_afk | ||
| Chipaca | Croepha— always interested in pain points around the build process | 17:31 |
| Chipaca | well, I say always. Not *always* always: right now i'm more interested in going AFK for a while | 17:32 |
| Chipaca | :-) | 17:32 |
| Croepha | later | 17:32 |
| Chipaca | ttfn :-) | 17:32 |
| morphis | Pharaoh_Atem, zyga: https://phoronix.com/scan.php?page=news_item&px=Snap-In-Fedora | 17:53 |
| Pharaoh_Atem | morphis: well, I guess that's what prompted mattdm to email me | 17:56 |
| Croepha | thanks for the help Orga! i think I found what I need | 17:58 |
| ogra_ | cool | 17:59 |
| Croepha | btw, instead of mounting the symbol files over, you can just use "set solib-search-path" | 18:00 |
| ogra_ | ah | 18:00 |
| ogra_ | but doesnt that change the path for all libs ? | 18:01 |
| Croepha | you can add a path | 18:01 |
| Croepha | just add a new path | 18:01 |
| Croepha | like, you aren't changing which lib is actually loaded... thats what LD_PRELOAD... does | 18:02 |
| Croepha | you are just helping gdb find the debug symbol files | 18:02 |
| Croepha | so, what I am doing, is I am running some binaries on a core machine and connecitng to it over via gdbserver | 18:03 |
| Croepha | on my local machine, I have a copy of the core snap and the prime dir, and can manually mount the snap and set sysroot in gdb | 18:04 |
| ogra_ | ah | 18:04 |
| ogra_ | clever | 18:04 |
| Croepha | imho, this is the best debug workflow | 18:04 |
| Pharaoh_Atem | morphis, zyga: testing scratch build of 2.24 | 18:08 |
| morphis | Pharaoh_Atem: nice | 18:09 |
| Pharaoh_Atem | https://koji.fedoraproject.org/koji/taskinfo?taskID=18934608 | 18:09 |
| Pharaoh_Atem | also a test to see if ppc64 is fixed: https://koji.fedoraproject.org/koji/taskinfo?taskID=18934608 | 18:10 |
| nacc | is there a way in a snapcraft.yaml to specify that not only do i want a set of packages to be in stage-packages, but any packages they depend on? | 18:17 |
| nacc | or do i need to explicitly specify them/ | 18:17 |
| ogra_ | no | 18:18 |
| ogra_ | deps are processed b default | 18:18 |
| ogra_ | *by | 18:18 |
| nacc | ogra_: hrm, i just built a snap that has ptyhon-pygit2 but not libgit2 | 18:18 |
| nacc | oh wait | 18:18 |
| ogra_ | but maintainer scripts are not run ... | 18:18 |
| nacc | i bet LD_LIBRARY_PATH didn't get set! | 18:18 |
| Pharaoh_Atem | ~_~ | 18:18 |
| Pharaoh_Atem | isn't pygit2 by default linked statically to libgit2? | 18:18 |
| nacc | it does a 'from _pygit2 import *' | 18:19 |
| nacc | and that spits a backtrace in the interpreter about not finding libgit2.so.24 | 18:19 |
| nacc | let me try with LD_LIBRARY_PATH set | 18:19 |
| Mutter | Hi, i already ask question about boot Core on Dragonboard and get the reply to make some changes in kernel | 18:23 |
| nacc | yeah it worked by specifing LD_LIBRARY_PATH=$SNAP/usr/lib64 | 18:24 |
| nacc | err LD_LIBRARY_PATH=$SNAP/usr/lib/x86_64-linux-gnu | 18:24 |
| nacc | is this possibly due to using 'classic' confinement? would snapcraft normally have wrapped this? | 18:24 |
| Mutter | But I have to rebuild the kernel from source - right? | 18:24 |
| Mutter | So where I can get the core kernel source? | 18:26 |
| nacc | ogra_: iirc, the wrapper script generator set it before. Does the /usr/bin/snap method not do that? | 18:29 |
| ogra_ | nacc, i dont think there are any wrappers in use when classic confinement is on | 18:30 |
| nacc | ogra_: ah, so in classic, i need to explicitly specify values in my yaml to use the snapped libs? | 18:30 |
| ogra_ | i dont really know ... never did a classic snap ... afaik it functions exactly like a deb | 18:31 |
| nacc | ah ok | 18:31 |
| nacc | yeah maybe i should switch back to devmode confinement :) | 18:31 |
| ogra_ | probably a good forum question ;) | 18:31 |
| nacc | ogra_: yep, i'll try and ask there | 18:32 |
| nacc | it's almost certainly just me not having messed with my snap in some time (just been fixing bugs) and trying to refresh it with lots of changes to snapcraft since | 18:32 |
| Pharaoh_Atem | morphis: pushing snapd-2.24 builds for F24+ | 18:32 |
| morphis | Pharaoh_Atem: that is wonderful! | 18:34 |
| morphis | will give it a try tomorrow | 18:34 |
| suhamera | ogra_: could you please show the direction to fix issues with .img on eMMC? | 18:37 |
| ogra_ | suhamera, well, i doubt it will work with the existing partitioning of the MMC | 18:39 |
| ogra_ | http://paste.ubuntu.com/24362438/ ... the aboot partition size seems to be smaller on the MMC | 18:40 |
| ogra_ | suhamera, so this will be non trivial ... first of all make a backup of the eMMC aboot partition with dd ... | 18:41 |
| suhamera | Ok | 18:41 |
| ogra_ | then dd the whole sd image to /dev/mmcblk0 | 18:42 |
| ogra_ | that should force the SD card partition table onto the eMMC | 18:42 |
| suhamera | But | 18:42 |
| ogra_ | then dd the backed up aboot partition content to the aboot partition on the eMMC | 18:42 |
| ogra_ | and then ... good luck | 18:42 |
| suhamera | :) | 18:42 |
| suhamera | But on my eMMC I have the android or Debian partition table | 18:43 |
| suhamera | And it could be different | 18:43 |
| ogra_ | (by "dd the whole sd image ..." i mean you should use a virgin img, not the Sd you are using indeed) | 18:43 |
| ogra_ | suhamera, well, check the size of the aboot partition | 18:44 |
| suhamera | Ok, thanx | 18:44 |
| ogra_ | that is the only important bit ... the one on the SD has booting from the external port hardcoded ... so you cant use that on the eMMC | 18:44 |
| Croepha | ogra_: you may be interested to know, that updating /was/ the answer in the final analysis, its easier to get debug symbols for the newer versions | 18:50 |
| Croepha | but im glad I know about the build logs/manifests so I can find the versions in the future | 18:51 |
| ogra_ | :) | 18:52 |
| Croepha | btw, for my debug/dev workflow, this is what I am doing for an rsync server: sudo classic sudo rsync --daemon --no-detach -v --log-file=/dev/stdout --config=./rsyncd.conf | 18:53 |
| ogra_ | neat | 18:55 |
| ogra_ | (to bad we dont support services inside classic else you could have it auto-start) | 18:56 |
| Croepha | ehh, its not a big deal, I just have a text file of stuff to run on a restart | 18:57 |
| === elfgoh_ is now known as elfgoh | ||
| kyrofa | zyga, https://stackoverflow.com/questions/43354435/snapd-dead-after-installing-a-snap-with-requested-plugs is that the core/ubuntu-core plug/slot issue? | 19:32 |
| nacc | if `snap info usd-nacc` shows a snap (with classic confinement), why would `sudo snap install usd-nacc --classic` say 'snap not found'? | 19:35 |
| kyrofa | nacc, because usd-nacc is only available on edge | 19:36 |
| kyrofa | nacc, snap install by default uses stable | 19:36 |
| nacc | kyrofa: ah so i need --classic --edge ? | 19:36 |
| kyrofa | Bingo | 19:36 |
| nacc | kyrofa: thanks! wonder if that could be a bit more user-friendly :) | 19:37 |
| nacc | but yeah, pebkac :) | 19:37 |
| kyrofa | nacc, yeah I've hit the same issue | 19:37 |
| tvoss | niemeyer: hey, thanks for the review. Looking into your remark about using a dynamic name for the key file. would you be okay with a dynamic directory under /run/snapd instead. Easier to just use ioutil.TempDir as opposed to ioutil.TempFile (which returns an open File). | 19:41 |
| niemeyer | tvoss: What's the win compared to using the real temporary dir? | 19:51 |
| tvoss | niemeyer: assuming that you mean real temporary file: I would have to close the file and figure out its name. code looks nice with ioutil.TempDir: http://pastebin.ubuntu.com/24362847/ | 19:56 |
| Pharaoh_Atem | morphis: updates proposed for snapd to F24, F25, and F26 | 19:59 |
| Pharaoh_Atem | morphis: Wut | 20:02 |
| Pharaoh_Atem | my name was mentioned in the Ubuntu Insights blog post | 20:02 |
| Pharaoh_Atem | O.o | 20:02 |
| morphis | Pharaoh_Atem: congratulations! | 20:03 |
| * Pharaoh_Atem feels very odd about all this | 20:03 | |
| ogra_ | a celebrety! | 20:03 |
| niemeyer | tvoss: Why do we need to use /run for a temporary file? | 20:11 |
| tvoss | niemeyer: I'm following guidance from security here | 20:12 |
| niemeyer | tvoss: Okay... can we find that out? :) | 20:12 |
| tvoss | tyhicks: ^ | 20:12 |
| niemeyer | tvoss: There's a directory in the system which is meant to be used for temporary content like this.. | 20:12 |
| niemeyer | tvoss: It's not about dir vs. file.. it's about /tmp vs. /run | 20:12 |
| tvoss | niemeyer: ah, I misread your comment then | 20:13 |
| tyhicks | niemeyer: the code was writing the device key temporarily to $PWD where it wasn't clear what $PWD was | 20:13 |
| niemeyer | tyhicks: Yeah, definitely a good improvement to not do that.. the point above is unrelated | 20:13 |
| tvoss | niemeyer: I'm fine with putting it into /tmp | 20:14 |
| tyhicks | I'm not | 20:14 |
| tyhicks | it needs to be somewhere where the world can't read the key file, doesn't it? | 20:14 |
| tyhicks | this is private key material, not public | 20:14 |
| tyhicks | well, public is included | 20:14 |
| tyhicks | we're not wrapping the key with a passphrase so I don't think it should be stored, even temporarily, in a world readable location | 20:15 |
| tyhicks | creating a subdir inside of /tmp/ is fine as long as the perms are sufficient | 20:15 |
| niemeyer | tyhicks: Yes, I completely agree it shoudn't be world readable | 20:15 |
| niemeyer | Somewhat obviously :) | 20:15 |
| niemeyer | That's still unrelated to /tmp vs. /run | 20:15 |
| tyhicks | ok | 20:16 |
| tyhicks | I didn't want to dictate where it should go | 20:16 |
| tyhicks | other than the directory permissions part | 20:16 |
| tyhicks | thanks niemeyer :) | 20:16 |
| niemeyer | Yeah, I think we're all sort of in agreement, but were talking slightly across purposes | 20:16 |
| tyhicks | I think so, as well | 20:16 |
| tvoss | let's be explicit, because it's late here :) /tmp/snapd{RANDOM} with 0700 would do the trick, correct? | 20:18 |
| tyhicks | tvoss: if using /tmp, please use whatever equivalent golang has for securely creating a temp directory (such as what the mktemp utility provides) | 20:18 |
| tyhicks | tvoss: that meets my requirements | 20:18 |
| tvoss | niemeyer: ^ are you fine with the approach, too? | 20:21 |
| niemeyer | tvoss: Yeah, I was assuming simply ioutil.TempDIr | 20:22 |
| tvoss | niemeyer: cool, thx | 20:22 |
| niemeyer | tvoss: If that's not offering the right mode, then something equivalent that does | 20:22 |
| tvoss | niemeyer: mode is not documented for ioutil.TempDir, but I can easily os.Chmod() the tempdir prior to calling ssh-keygen. Or am I missing a potential attack vector here? | 20:24 |
| niemeyer | tvoss: Seems better to have a osutil.PrivateTempDir | 20:25 |
| niemeyer | tvoss: In snapd itself.. | 20:25 |
| tvoss | niemeyer: okay, will add it | 20:27 |
| niemeyer | ahtvoss: Note we already have a handy strutil.MakeRandomString (which should really be called RandomString simply) | 20:27 |
| niemeyer | tvoss: Thank you! | 20:28 |
| niemeyer | I'm going to step out for some exercising.. o/ | 20:28 |
| tvoss | ah, reading code helps, ioutil.TempDir creates with 0700 | 20:28 |
| tvoss | https://golang.org/src/io/ioutil/tempfile.go?s=2138:2195#L66 ff | 20:28 |
| tvoss | tyhicks: ^ | 20:29 |
| tyhicks | looks good to me | 20:29 |
| tyhicks | wish it were documented | 20:29 |
| tyhicks | that's not your problem though | 20:29 |
| tyhicks | thanks tvoss | 20:30 |
| stokachu | facubatista: just ran into that issue again, emailed you a copy of what i see | 21:09 |
| cholcombe | this is prob a silly question but do you have to be logged into the store to install private snaps? | 21:47 |
| cholcombe | i ask because i want a juju charm to install a private snap | 21:47 |
| cholcombe | i also don't want to put my credentials in the charm haha | 21:48 |
| mup | PR snapd#3095 closed: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3095> | 22:21 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!