[00:23] PR # closed: snapd#3734, snapd#3852, snapd#3872, snapd#3916, snapd#3945, snapd#3951, snapd#3954, snapd#3958, snapd#3960, snapd#3963, snapd#3964, snapd#3965, snapd#3970, snapd#3971, snapd#3972, snapd#3976, snapd#3978, snapd#3989, snapd#3990, snapd#3992, snapd#3993, snapd#3994, snapd#3995, [00:23] snapd#3998, snapd#3999, snapd#4001, snapd#4002, snapd#4003, snapd#4004, snapd#4005 [00:24] PR # opened: snapd#3734, snapd#3852, snapd#3872, snapd#3916, snapd#3945, snapd#3951, snapd#3954, snapd#3958, snapd#3960, snapd#3963, snapd#3964, snapd#3965, snapd#3970, snapd#3971, snapd#3972, snapd#3976, snapd#3978, snapd#3989, snapd#3990, snapd#3992, snapd#3993, snapd#3994, snapd#3995, [00:24] snapd#3998, snapd#3999, snapd#4001, snapd#4002, snapd#4003, snapd#4004, snapd#4005 === ikey is now known as ikey|zzz [01:11] PR snapcraft#1584 closed: style: use dedent for multiline strings [01:20] kyrofa there you go === JoshStrobl is now known as JoshStrobl|zzz === chihchun_afk is now known as chihchun [04:06] PR snapcraft#1553 closed: lxd: instructions for /etc/sub{u,g}id after failed start === JanC is now known as Guest53841 [06:07] PR snapd#4004 closed: interfaces/lxd: lxd slot implementation can also be an app snap [06:15] PR snapd#4001 closed: release,cmd,dirs: Redo the distro checks to take into account distribution families [06:46] snappy good morning [07:08] PR snapd#4003 closed: interfaces: deny lttng by default [07:10] PR snapd#4002 closed: interfaces: misc updates for default, browser-support, home and system-observe [07:25] o/ [07:25] * zyga-fedora feels bad but will try to work today [07:38] hey zyga-fedora! good morning [07:39] hey [07:39] how are you doing [07:43] zyga-fedora: I'm doing well, thank you [07:43] zyga-fedora: how do you do? [07:47] zyga-fedora: Still affected by the Ubuflu? [07:48] mvo: https://github.com/snapcore/snapd/pull/3872 <- ready for merge finally??? [07:48] PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) [07:48] :) [07:49] kalikiana: no, I have my own polflu here :) [07:55] mwhudson: looking, but yeah, hopefully finally :) [07:56] mwhudson: it needs a second +1 afaics - maybe zyga-fedora can look at 1682308? ideally jdstrand as well [07:57] mvo: ah ok [08:00] PR snapd#4006 opened: snap-exec: update tests to follow main_test pattern [08:07] PR snapd#4007 opened: interfaces: add plugRef/slotRef helpers for PlugInfo/SlotInfo [08:12] mwhudson: looking [08:25] mwhudson: reviewed [08:26] zyga-fedora: well um your points seem valid but after four weeks of this i am tired :) [08:26] i guess they are simple enough [08:27] mwhudson: mind if I rename that constant? [08:27] zyga-fedora: i am totally happy for you to do it, sure :) [08:27] I can do that, i feel s***y today and this is the complexity I can handle [08:36] * mvo hugs zyga-fedora [08:36] mwhudson: sorry for the long wait [08:37] mvo: it's ok, but it has been a long time [08:37] i guess the rally didn't help [08:39] mwhudson: indeed not [08:41] mwhudson: done [08:42] sorry, it I spent some time to iterate on the flag names [08:42] zyga-fedora: btw the glibc header that contains these variable names is not installed afaict [08:43] so to go generate it you need a glibc source tree lying around [08:43] mwhudson: aww, that sucks [08:43] which of course you and i probably have but :-) [08:43] mwhudson: or very creative strings | awk statement [08:43] zyga-fedora: i'm going to pretend you didn't say that, i think [08:43] right, I meant perl [08:43] ;-) [08:44] * zyga-fedora gets back to reviews [08:44] ha [08:57] mvo: 4006 has really borken test [08:58] zyga-fedora: uh, let me check [08:58] rm without -f failing [09:05] * kalikiana doing some snapcraft reviews [09:28] PR snapd#3993 closed: snap-confine: is_running_on_classic_distribution() looks into os-release [09:30] when absolute paths are used in snap[craft].yaml, are they required to be prefixed with $SNAP* variables? [09:31] PR snapd#4005 closed: Add an exception for Firefox's access to /dev/shm, [09:32] q - does the snapstore support the branches concept yet? I have fixes I want to validate without having to use the edge channel [09:34] jamespage: pretty sure it does [09:34] jamespage: easy to try? :) [09:35] mwhudson: maybe - snapcraft push --help was not helpful [09:35] jamespage: it's on release shurely [09:36] examples:\n...snapcraft release my-snap 9 lts-channel/stable/my-branch [09:37] mwhudson: indeed it is - thanks! [09:37] just the ticket [09:38] PR snapd#3970 closed: interfaces/mount,cmd/snap-update-ns: move change code [09:40] I'm hitting this failure when trying to build snapd master: http://paste.ubuntu.com/25678585/, anyone knows what could be causing it? [09:43] niemeyer, hey, 3852 has all your review feedback addressed, can you have another look? [09:56] pstolowski: can you look at https://github.com/snapcore/snapd/pull/3965 again please [09:56] PR #3965: interfaces/mount: add support for parsing x-snapd-mkdir-{mode,uid,gid}= [09:56] zyga-fedora, sure, I meant to [10:03] thanks [10:10] ppisati_, FYI, todays daily dragoonboard image works fine again [10:16] * __chip__ ~> physio [10:16] ogra_: ok, but i'm off today [10:17] heh [10:17] ppisati_, enjoy [10:26] zyga-fedora, have you seen that ? https://forum.snapcraft.io/t/snapped-lxd-has-stopped-working-aa-exec-doesnt-exist-in-the-snap/2356/7 [10:26] (core noot providing any interfaces anymore) [10:26] huh [10:26] yeah [10:26] pretty huh [10:26] pstolowski: is that one of the things we got from a report from sergiusens before the rally? [10:27] ogra_: thanks [10:30] zyga-fedora, sergiusens' problem was about vanishing plugs https://forum.snapcraft.io/t/vanishing-plugs/1823 [10:30] pstolowski: looks like the same problem to me [10:30] * zyga-fedora thinks [10:31] * kalikiana going for a lunch break in a few minutes [10:36] zyga-fedora, I couldn't reproduce the problem as documented in the vanishing-plugs thread. not sure how to get insight into that problem without finding a pattern to reproduce :( [10:36] pstolowski: thinking about how the code can ever allow that to happen [10:36] pstolowski: I agree it's not easy [10:37] mvo, hmm ... do you see any reason why we shouldnt enable ntp out of the box on the core images ? (i just noticed it is only half configured (ntp.ubuntu.com is in the config) but turned off by default) [10:37] we only do the time sync on connect but if you never reboot or reconnect the device it migth start to drift [10:41] Is the stable channel completely unrelated to all the other stable channels? 'snap info go' shows me Go 1.9 in stable, but Go 1.9.1 in 1.9/stable [10:43] stub, one is a channel the other is a track ... while i would expect both to be in sync in this case, probably someone forgot to sync over the package fom the track [10:44] stub, you should talk to the publisher ;) [10:45] mwhudson: oi! [10:48] mvo: what happens when I change one of the snaps in tests/lib/snaps [10:48] mvo: how do I upload it to the store/ [10:48] ogra_: The cli makes no distinction between channels and tracks that I can see. eg. 'sudo snap refresh --channel 1.9/stable go' [10:54] mvo: another piece of the mount machinery puzzle https://github.com/snapcore/snapd/pull/4008 - stacked on top of https://github.com/snapcore/snapd/pull/3971 [10:54] PR #4008: cmd/snap-update-ns: create missing mount points automatically [10:54] PR #3971: interfaces/mount: make Change.Perform testable and test it [10:54] PR snapd#4008 opened: cmd/snap-update-ns: create missing mount points automatically [10:54] hmm, some network failures [10:54] # cd .; git clone https://go.googlesource.com/sys /tmp/go/src/golang.org/x/sys [10:54] Cloning into '/tmp/go/src/golang.org/x/sys'... [10:54] fatal: unable to access 'https://go.googlesource.com/sys/': The requested URL returned error: 502 [10:57] ok, I need a break, `for { back.hurt() }` [10:57] I need to pick up my son from school soon so I'll just go there anyway [10:59] * sergiusens waves [10:59] ogra_: +1 for ntp [11:00] zyga-fedora: I can upload it to the store, which snap is it? for some we have snapcraft auto-build branches [11:00] aha [11:00] I haven't finished the test yet but I'm working on richer tests for the content interface [11:00] I think I may end up creating a new snap due to the auto-connect logic [11:00] ok [11:00] and the lesser impact on other tests [11:02] pstolowski zyga-fedora my problem was differen, things connected but actually didn't [11:03] aha [11:08] wow [11:08] opensuse changed policy for golang package [11:08] there will be no more golang- packages [11:08] go get is the recommended way to do stuff [11:08] that's going to be annoying for packaging as we'll need two packages for opensuse now, a trivial one and the legacy one for before the decision was made [11:10] in any case, I need to go to school now [11:10] bbl [11:12] happy learning then ... [11:27] :) [11:40] PR snapcraft#1572 closed: catkin plugin: allow ROS_MASTER_URI change === ikey|zzz is now known as ikey [11:56] Love seeing more code getting merged! [12:02] re [12:10] @elopio q for when you get in, how long does ./runtests static usually take on your system? It's extremely slow for me, I can prepare and drink a coffee whilst it's running... [12:10] kalikiana: No such command! [12:11] elopio: q for when you get in, how long does ./runtests static usually take on your system? It's extremely slow for me, I can prepare and drink a coffee whilst it's running... [12:12] hmm, tests are not happy [12:12] It seems like it wasn't so slow before... unless something on my system affects it === JoshStrobl|zzz is now known as JoshStrobl [12:17] ikey: what's your guys' software centre jobbie called? [12:18] ohhh [12:18] since when do we have snapcraft.io/$SNAP_NAME [12:18] Chipaca, Software Center [12:18] Yep... [12:19] FWIW I put out a feeble request @ NYC for people to come up with a better name [12:19] that's so nice [12:19] Store McStoreFace was the best. [12:19] zyga-fedora, since last week or so [12:19] nice [12:19] zyga-fedora, not officially announced yet though [12:19] In terms of project name its just known as "solus-sc" on github [12:19] aha [12:19] (i guess there is more to come first) [12:19] ikey: but the pattern is Mcface [12:19] ogra_: snapcraft G+ account mentioned it [12:19] Yeah they can't even get that right :P [12:19] ah [12:20] then it is now announced :) [12:20] i thought there was a search to come first [12:20] ikey: I was trying to work your thing into a list of more well-known ones, but don't feel i can do it without it being a little in the eye :( [12:20] so lemme read between the lines here and translate into ikeynese [12:21] the name is an embarrassment and the other bullet points would complain [12:21] ? [12:21] ikey: currently it read "GUI software center applications like gnome software or the kde software store” [12:21] just drop the "like ..." [12:21] yea i mean in theory its just "the Solus Software Center" with or without capitals [12:22] Most people (sadly) confuse it for gnome-software anyway [12:22] S^2C [12:22] I should change it to "the gnome software centre store" [12:22] oh "Discombobulation Station" was another suggestion [12:22] zyga-fedora, now thats intuitive ! [12:22] right [12:22] at least it's catchy [12:23] zyga-fedora: S²C FTW [12:23] now is that at a valid chemical? [12:24] zyga-fedora: or is that 2ⁿ edgy 2²ⁿ u? [12:24] squaresulfurcarbon ! [12:25] brilliant [12:25] is it toxic? [12:26] according to my googles S²C is "Smart Sollution Computer's" (2×sic) [12:27] ikey: "system destroyer" [12:27] oo [12:27] wait wait i got a real friendly cross-distro collab sounding one [12:28] "All Your SuSE Are Belong To Us" [12:28] ikey: I don't know if that's a breathless "ooh", or a noseless "o‸o" [12:28] nah was an ooh [12:28] ikey: "rootkit installer v7.337" [12:29] XD [12:41] my tests are timing out [12:50] niemeyer: good morning sah! does our discourse have checklists? [12:59] Chipaca as fancy as github's? [13:07] * ogra_ wonders if the core team started giving out bonuses for most new topics/day [13:09] ogra_: cake [13:10] does gustavo bake it himself ? [13:10] Chipaca: Sort of.. it has icons, and we can abuse them [13:11] Chipaca: Per roadmap and our review sprint boards [13:19] mvo: can you please land 3971, I think it's ready now [13:21] zyga-fedora: wrt night-rider, don't give me ideas [13:21] (or rather, don't reinforce ideas i'm struggling to ignore) [13:22] Chipaca: just think about what you could make if there were ansi escape codes for sound effects [13:22] zyga-fedora: there are! [13:23] zyga-fedora: beep + strings-of-nulls-as-delays [13:23] Chipaca: I know but those are limited and often disabled; think 8 bit sound :) [13:32] PR snapd#3971 closed: interfaces/mount: make Change.Perform testable and test it [13:34] \o/ [13:34] thanks [13:36] and 4008 now looks easy to review [13:36] (and I'll add some spread tests for it) [13:37] * kalikiana time for a break, back in a bit [13:41] mvo: Release notes LGTM [13:41] ta [13:42] mvo, mwhudson: I took a look at https://github.com/snapcore/snapd/pull/3872. I think someone should consider my question on preserving LD_* [13:42] PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) [13:42] jdstrand: hello, thank you for the reviews! [13:43] mvo, mwhudson: beyond that it is renaming two tests (or tell me I'm wrong! :) and adding one more and I'll +1 [13:43] zyga-fedora: hey-- feeling better? [13:43] jdstrand: meds make me feel better [13:43] well, that's astart [13:43] jdstrand: I think my rain-and-cold-o-meter is full for the year already [13:43] oh no! [13:44] you have at least a couple more days of that this year I'm sure [13:44] not unless I buy a one-way-ticket somewhere :-) [13:45] does anyone know what this snapd error means exactly? https://paste.kde.org/pdbxoeiqc [13:46] apol_: is squashfs loaded into the kernel? or maybe the .snap files got corrupted? [13:48] ah, wrong squashfs... SQUASHFS error: Filesystem uses "xz" compression. This is not supported [13:48] * apol_ looks into it further [13:49] looks like you need one kernel config option flipped [13:49] XZ support for squashfs is a separate knob [13:50] apol_: What distro is that? [13:51] mvo: Just added a topic link to the last entry in the notes [13:51] plasma mobile [13:51] mvo: Also fixed roadmap to reflect notes, and to push dates forward [13:51] niemeyer: thanks alot! [13:52] apol_: Who maintains its kernel? We should get in touch to suggest enabling that upstream [13:53] yes yes, it's what we are doing [13:53] 5' it didn't have squashfs at all [13:53] 5' ago* [13:57] <__chip__> niemeyer: didn't we have a list of all the things that needed to be enabled? [13:58] stgraber: I was just looking at 16325008 again (i.e. that you need a way to differentiate uninstall/shutdown from stop script. we now have a bunch of hooks (post-refresh, install, uninstall). will these hooks help you with the bug? i.e. setting the right states based on the hooks that stop-commnad-daemon.wrapper could pick up? [13:58] <__chip__> maybe that's closer to ogra_'s purview [13:58] apol_: Oh, yay! [13:58] __chip__: I haven't seen one, but it's a great idea [13:58] <__chip__> niemeyer: I suspect ondra knows this [13:59] <__chip__> ondra: OHAI [13:59] <__chip__> ondra: is there a list of kernel options needed for snappy? [14:00] pstolowski: can you please re-look at 3965 [14:01] zyga-fedora, yes, sorry, i was looking at it and got distracted. on it [14:03] no worries, thank you [14:06] now for that NFS + udp test [14:11] niemeyer: oh I know what that thing was [14:11] niemeyer: opensuse changed packaging rules for golang [14:11] niemeyer: (again) [14:11] niemeyer: and the new rules are ... go get :) [14:11] zyga-fedora, approved, but please add two extra checks to the test (see comment) [14:11] niemeyer: so I'm happy to not have to maintain any golang package in suse anymore [14:11] zyga-fedora: Nice! [14:12] niemeyer: we'll have to to some work to update our package [14:12] * kalikiana doing some pulling/ checking for red PRs [14:12] pstolowski: ack, will do [14:16] __chip__ hey [14:16] __chip__ if you build using snapcraft, it will already warn you about missing options [14:17] <__chip__> apol_: ^ ! [14:17] __chip__ also have look here https://github.com/snapcore/sample-kernels [14:17] <__chip__> apol_: ^^ [14:17] <__chip__> ondra: awesome stuff [14:17] PR snapd#3945 closed: snap: refactor cmdGet.Execute() [14:17] that's usually good place to start [14:20] <__chip__> apol_: you got that? [14:33] elopio: could you maybe give me a hand with https://github.com/snapcore/snapcraft/pull/1536 I can't get it to pass on Travis [14:33] PR snapcraft#1536: repo: implement :target suffix for package names [14:35] Haha, kalikiana elopio is in high demand today, I'm having problems as well [14:35] He probably hasn't woken up yet [14:35] :-D [14:36] * kyrofa dives into our testing infrastructure because it's all black magic [14:36] kyrofa: btw I saw your PR for the stderr output. By the looks of it we have a common enemy in those false negatives [14:36] __chip__ out of curiosity which hw are you trying to enable? [14:37] kalikiana, actually no, my problem is that I have a test that runs for longer than ten minutes. Since we show nothing, Travis thinks it stalled and kills it :P [14:37] kalikiana, but yeah, this can also make failures easier to trace [14:38] kyrofa: Ah, maybe... I just checked some branches that failed in the middle of downloading or even invalid syntax because something gets stopped in between. So not sure they're timeouts or rather network breaking down [14:39] Although it would seem odd for Travis' network to die during a test run? [14:40] It's raining sooo much. I'm trying to wake up now, but outside of the bed it's scary. [14:41] I'll check soon [14:41] __chip__, apol_ , if it is arm, i'd actually suggest to check our existing geneic kernel if the device is already supported ... by default oour arm kernel works on 430 devices OOTB (and with my allwinner changes even on 550), you just need to pick the rigth dtb from the gadget [14:42] elopio: good morning ^_^ didn't mean to rush, mainly so I wouldn't forget to ping you later [14:45] kyrofa: would you feel like being the second reviewer here? https://github.com/snapcore/snapcraft/pull/1546 [14:45] PR snapcraft#1546: cli: update parts cache in the container [14:46] __chip__, apol_ also, you probably want to use this starting doc instead of just the snapcore/sample-kernels (which just has the linux boilerplate as README ) https://github.com/piso77/sample-kernels [14:46] cachio: could you please look at 1703798 and do the sru verification for 2.27.6 once that is done I will upload 2.28.1 to -proposed [14:46] mvo, sure+ [14:46] though i'd always check generic first ... thats a great timesaver [14:49] PR snapcraft#1592 opened: travis: run snapd tests only if not cron [14:51] mvo, wrt socket activation, I'm wondering if using $SNAP_DATA/$SNAP_COMMON should be supported, or those should be rendered by snapcraft and snapd only accept a "rendered" path [14:51] ackk: I think its fine to support $SNAP_{DATA,COMMON} [14:53] Oh, missed a q in there... I really wish sometimes top-level comments didn't exist separate from actual review comments... [15:01] jdstrand: will you have some time to look at 4008 today? [15:01] jdstrand: it's tiny (the actual new code) apart from tests [15:02] jdstrand: again I'm just interested in the approach taken, you can do the full review later [15:02] zyga-fedora: I think so. looking at https://github.com/snapcore/snapd/pull/3958 now [15:02] PR #3958: many: add support for /home on NFS [15:03] jdstrand: excellent, thank you [15:03] jdstrand: I've added a test for UDP, will push after it runs locally [15:07] tyhicks: I pushed some test fixes to 3998, I hope you don't mind, if you prefer I can also do them as separate PRs [15:08] mvo: any help pushing this along is much appreciated - thanks! :) [15:08] mvo: I'm currently working on the libseccomp and kernel SRUs to zesty and xenial [15:09] tyhicks: great, thanks for this! [15:09] no problem! === cachio is now known as cachio_lunch [15:24] mvo: did you have an opinion on preprocessing? https://github.com/snapcore/snapd/pull/3998#discussion_r142661507 [15:24] PR #3998: snap-confine, snap-seccomp: Utilize new seccomp logging features [15:35] kalikiana: your errors are connection problems on travis or the archive. I see no other solution than retrying. [15:36] kyrofa: which one is failing for you? [15:36] elopio, I re-ran it, I think it was network issues after comparing to other tests [15:36] elopio, the plugin integration tests, though. They take forever [15:37] elopio: Hrm, I guess that's what I'll keep doing. The fact that I see this more frequently worries me, though... and it gets very difficult to get reviews... [15:37] kyrofa: yes, things like python are very very slow. [15:38] mvo: I haven't tried that yet since we've got a workaround in place already, I'll have to figure out if those run at the right time for us and then switch away from our hack. [15:38] I want to time the tests, and see if we can improve a little. But I will start with unittests, and not this week. [15:38] elopio, I think I found a workaround (hack) for the long-running tests with no output: travis_wait [15:39] oh, nice. I didn't know about it. [15:41] kalikiana: well, it happens some times. If it persists, you can open a ticket in travis. [15:42] jdstrand: thank you! [15:50] would it be possible for snapcraft/snapd to do some magic so that if i say my applications manpages live at a given path in the snap, that /etc/manpath.config could be adjusted to make those manpages available to all users (not sure if MANDATORY_MANPATH or MANPATH_MAP is better), without having to do an install hook? THen when the snap is removed, that line that was specifically added can be removed? [15:50] it feels like bash completions and manpages are going to be quite common for classic snaps, as general things to expose to all users [15:50] sergiusens: --^ [15:50] nacc: snapd will eventually support man pages, for now it's not something we have on the roadmap [15:51] nacc if we do anything in a way of "placing a file somewhere" style of thing I think we should go down the same path we do for hooks [15:51] I'd propose a forum topic though [15:51] well the file already exists :) [15:51] (/etc/manpath.config) [15:51] sergiusens: yeah yeah :) [15:51] nacc we can discuss all you want here, but as soon as the conversation is over it will be forgotten :-) [15:52] zyga-fedora: even for classic snaps? [15:52] nacc that should not make a difference [15:52] sergiusens: well, I would agree in principle [15:52] sergiusens: but I want to be sure [15:52] because my experience with classic so far has been painful :) [15:53] alternatively, would it make sense to add an interface for confined snaps that says "let me read/write anywhere the calling user can read/write to" [15:53] if that was the case, i thinkn our snap could be confined [15:53] nacc: in general [15:53] zyga-fedora: ok, thanks [15:53] tyhicks: I have a look at the pre-processing now, I had not really thought about it yet [15:54] I guess my interface idea doesn't actually make sense in confined, since you can't see the host FS. But it's like the home interface, but broader [15:54] I want something squarely between classic and confined, which I think basically every CLI wants [15:54] tyhicks: sounds sensible, I will do it [15:56] jdstrand, the password-manager-service interface doesn't seem to work for qtkeychain [15:56] mvo: thanks! [15:59] ogra_: yep, daily works fine [15:59] ogra_: thought i'm slightly confused [15:59] ppisati_, thanks fo confirming [15:59] ogra_: http://pastebin.ubuntu.com/25680457/ [15:59] waiting for a proper fix from ondra though he first needs to get his dragonboard back to life [15:59] it says 'core' is @ 2973 [16:00] and it's tracking edge, but edge is @ 3074 [16:00] freshed: 2017-09-20 04:30:03 +0000 UTC [16:00] ogra_: but you built it today [16:00] i mean,. it's a daily [16:00]