[00:23] <mup> 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] <mup> snapd#3998, snapd#3999, snapd#4001, snapd#4002, snapd#4003, snapd#4004, snapd#4005
[00:24] <mup> 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] <mup> snapd#3998, snapd#3999, snapd#4001, snapd#4002, snapd#4003, snapd#4004, snapd#4005
[01:11] <mup> PR snapcraft#1584 closed: style: use dedent for multiline strings <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1584>
[01:20] <sergiusens> kyrofa there you go
[04:06] <mup> PR snapcraft#1553 closed: lxd: instructions for /etc/sub{u,g}id after failed start <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1553>
[06:07] <mup> PR snapd#4004 closed: interfaces/lxd: lxd slot implementation can also be an app snap <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4004>
[06:15] <mup> PR snapd#4001 closed: release,cmd,dirs: Redo the distro checks to take into account distribution families <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4001>
[06:46] <kalikiana> snappy good morning
[07:08] <mup> PR snapd#4003 closed: interfaces: deny lttng by default <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4003>
[07:10] <mup> PR snapd#4002 closed: interfaces: misc updates for default, browser-support, home and system-observe <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4002>
[07:25] <zyga-fedora> o/
[07:25]  * zyga-fedora feels bad but will try to work today
[07:38] <mvo> hey zyga-fedora! good morning
[07:39] <zyga-fedora> hey
[07:39] <zyga-fedora> how are you doing
[07:43] <mvo> zyga-fedora: I'm doing well, thank you
[07:43] <mvo> zyga-fedora: how do you do?
[07:47] <kalikiana> zyga-fedora: Still affected by the Ubuflu?
[07:48] <mwhudson> mvo: https://github.com/snapcore/snapd/pull/3872 <- ready for merge finally???
[07:48] <mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
[07:48] <mwhudson> :)
[07:49] <zyga-fedora> kalikiana: no, I have my own polflu here :)
[07:55] <mvo> mwhudson: looking, but yeah, hopefully finally :)
[07:56] <mvo> mwhudson: it needs a second +1 afaics - maybe zyga-fedora can look at 1682308? ideally jdstrand as well
[07:57] <mwhudson> mvo: ah ok
[08:00] <mup> PR snapd#4006 opened:  snap-exec: update tests to follow main_test pattern  <Created by mvo5> <https://github.com/snapcore/snapd/pull/4006>
[08:07] <mup> PR snapd#4007 opened: interfaces: add plugRef/slotRef helpers for PlugInfo/SlotInfo <Created by stolowski> <https://github.com/snapcore/snapd/pull/4007>
[08:12] <zyga-fedora> mwhudson: looking
[08:25] <zyga-fedora> mwhudson: reviewed
[08:26] <mwhudson> zyga-fedora: well um your points seem valid but after four weeks of this i am tired :)
[08:26] <mwhudson> i guess they are simple enough
[08:27] <zyga-fedora> mwhudson: mind if I rename that constant?
[08:27] <mwhudson> zyga-fedora: i am totally happy for you to do it, sure :)
[08:27] <zyga-fedora> 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] <mvo> mwhudson: sorry for the long wait
[08:37] <mwhudson> mvo: it's ok, but it has been a long time
[08:37] <mwhudson> i guess the rally didn't help
[08:39] <mvo> mwhudson: indeed not
[08:41] <zyga-fedora> mwhudson: done
[08:42] <zyga-fedora> sorry, it I spent some time to iterate on the flag names
[08:42] <mwhudson> zyga-fedora: btw the glibc header that contains these variable names is not installed afaict
[08:43] <mwhudson> so to go generate it you need a glibc source tree lying around
[08:43] <zyga-fedora> mwhudson: aww, that sucks
[08:43] <mwhudson> which of course you and i probably have but :-)
[08:43] <zyga-fedora> mwhudson: or very creative strings | awk statement
[08:43] <mwhudson> zyga-fedora: i'm going to pretend you didn't say that, i think
[08:43] <zyga-fedora> right, I meant perl
[08:43] <zyga-fedora> ;-)
[08:44]  * zyga-fedora gets back to reviews
[08:44] <mwhudson> ha
[08:57] <zyga-fedora> mvo: 4006 has really borken test
[08:58] <mvo> zyga-fedora: uh, let me check
[08:58] <zyga-fedora> rm without -f failing
[09:05]  * kalikiana doing some snapcraft reviews
[09:28] <mup> PR snapd#3993 closed: snap-confine: is_running_on_classic_distribution() looks into os-release <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3993>
[09:30] <ackk> when absolute paths are used in snap[craft].yaml, are they required to be prefixed with $SNAP* variables?
[09:31] <mup> PR snapd#4005 closed: Add an exception for Firefox's access to /dev/shm, <Created by oSoMoN> <Closed by oSoMoN> <https://github.com/snapcore/snapd/pull/4005>
[09:32] <jamespage> 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] <mwhudson> jamespage: pretty sure it does
[09:34] <mwhudson> jamespage: easy to try? :)
[09:35] <jamespage> mwhudson:  maybe - snapcraft push --help was not helpful
[09:35] <mwhudson> jamespage: it's on release shurely
[09:36] <mwhudson> examples:\n...snapcraft release my-snap 9 lts-channel/stable/my-branch
[09:37] <jamespage> mwhudson: indeed it is - thanks!
[09:37] <jamespage> just the ticket
[09:38] <mup> PR snapd#3970 closed: interfaces/mount,cmd/snap-update-ns: move change code <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3970>
[09:40] <ackk> 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] <pstolowski> niemeyer, hey, 3852 has all your review feedback addressed, can you have another look?
[09:56] <zyga-fedora> pstolowski: can you look at https://github.com/snapcore/snapd/pull/3965 again please
[09:56] <mup> PR #3965: interfaces/mount: add support for parsing x-snapd-mkdir-{mode,uid,gid}= <Created by zyga> <https://github.com/snapcore/snapd/pull/3965>
[09:56] <pstolowski> zyga-fedora, sure, I meant to
[10:03] <zyga-fedora> thanks
[10:10] <ogra_> ppisati_, FYI, todays daily dragoonboard image works fine again
[10:16]  * __chip__ ~> physio
[10:16] <ppisati_> ogra_: ok, but i'm off today
[10:17] <ogra_> heh
[10:17] <ogra_> ppisati_, enjoy
[10:26] <ogra_> 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] <ogra_> (core noot providing any interfaces anymore)
[10:26] <zyga-fedora> huh
[10:26] <ogra_> yeah
[10:26] <ogra_> pretty huh
[10:26] <zyga-fedora> pstolowski: is that one of the things we got from a report from sergiusens before the rally?
[10:27] <zyga-fedora> ogra_: thanks
[10:30] <pstolowski> zyga-fedora, sergiusens' problem was about vanishing plugs https://forum.snapcraft.io/t/vanishing-plugs/1823
[10:30] <zyga-fedora> 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] <pstolowski> 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] <zyga-fedora> pstolowski: thinking about how the code can ever allow that to happen
[10:36] <zyga-fedora> pstolowski: I agree it's not easy
[10:37] <ogra_> 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] <ogra_> we only do the time sync on connect but if you never reboot or reconnect the device it migth start to drift
[10:41] <stub> 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] <ogra_> 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] <ogra_> stub, you should talk to the publisher ;)
[10:45] <stub> mwhudson: oi!
[10:48] <zyga-fedora> mvo: what happens when I change one of the snaps in tests/lib/snaps
[10:48] <zyga-fedora> mvo: how do I upload it to the store/
[10:48] <stub> 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] <zyga-fedora> 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] <mup> PR #4008: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
[10:54] <mup> PR #3971: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <https://github.com/snapcore/snapd/pull/3971>
[10:54] <mup> PR snapd#4008 opened: cmd/snap-update-ns: create missing mount points automatically <Created by zyga> <https://github.com/snapcore/snapd/pull/4008>
[10:54] <zyga-fedora> hmm, some network failures
[10:54] <zyga-fedora> # cd .; git clone https://go.googlesource.com/sys /tmp/go/src/golang.org/x/sys
[10:54] <zyga-fedora> Cloning into '/tmp/go/src/golang.org/x/sys'...
[10:54] <zyga-fedora> fatal: unable to access 'https://go.googlesource.com/sys/': The requested URL returned error: 502
[10:57] <zyga-fedora> ok, I need a break, `for { back.hurt() }`
[10:57] <zyga-fedora> I need to pick up my son from school soon so I'll just go there anyway
[10:59]  * sergiusens waves
[10:59] <mvo> ogra_: +1 for ntp
[11:00] <mvo> zyga-fedora: I can upload it to the store, which snap is it? for some we have snapcraft auto-build branches
[11:00] <zyga-fedora> aha
[11:00] <zyga-fedora> I haven't finished the test yet but I'm working on richer tests for the content interface
[11:00] <zyga-fedora> I think I may end up creating a new snap due to the auto-connect logic
[11:00] <mvo> ok
[11:00] <zyga-fedora> and the lesser impact on other tests
[11:02] <sergiusens> pstolowski zyga-fedora my problem was differen, things connected but actually didn't
[11:03] <zyga-fedora> aha
[11:08] <zyga-fedora> wow
[11:08] <zyga-fedora> opensuse changed policy for golang package
[11:08] <zyga-fedora> there will be no more golang- packages
[11:08] <zyga-fedora> go get is the recommended way to do stuff
[11:08] <zyga-fedora> 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] <zyga-fedora> in any case, I need to go to school now
[11:10] <zyga-fedora> bbl
[11:12] <ogra_> happy learning then ...
[11:27] <pstolowski> :)
[11:40] <mup> PR snapcraft#1572 closed: catkin plugin: allow ROS_MASTER_URI change <enhancement> <Created by cratliff> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1572>
[11:56] <kalikiana> Love seeing more code getting merged!
[12:02] <zyga-fedora> re
[12:10] <kalikiana> @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] <nothal> kalikiana: No such command!
[12:11] <kalikiana> 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] <zyga-fedora> hmm, tests are not happy
[12:12] <kalikiana> It seems like it wasn't so slow before... unless something on my system affects it
[12:17] <Chipaca> ikey: what's your guys' software centre jobbie called?
[12:18] <zyga-fedora> ohhh
[12:18] <zyga-fedora> since when do we have snapcraft.io/$SNAP_NAME
[12:18] <ikey> Chipaca, Software Center
[12:18] <ikey> Yep...
[12:19] <ikey> FWIW I put out a feeble request @ NYC for people to come up with a better name
[12:19] <zyga-fedora> that's so nice
[12:19] <ikey> Store McStoreFace was the best.
[12:19] <ogra_> zyga-fedora, since last week or so
[12:19] <zyga-fedora> nice
[12:19] <ogra_> zyga-fedora, not officially announced yet though
[12:19] <ikey> In terms of project name its just known as "solus-sc" on github
[12:19] <zyga-fedora> aha
[12:19] <ogra_> (i guess there is more to come first)
[12:19] <Chipaca> ikey: but the pattern is <diminutive noun> Mc<noun>face
[12:19] <zyga-fedora> ogra_: snapcraft G+ account mentioned it
[12:19] <ikey> Yeah they can't even get that right :P
[12:19] <ogra_> ah
[12:20] <ogra_> then it is now announced :)
[12:20] <ogra_> i thought there was a search to come first
[12:20] <Chipaca> 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] <ikey> so lemme read between the lines here and translate into ikeynese
[12:21] <ikey> the name is an embarrassment and the other bullet points would complain
[12:21] <ikey> ?
[12:21] <Chipaca> ikey: currently it read "GUI software center applications like gnome software or the kde software store”
[12:21] <ogra_> just drop the "like ..."
[12:21] <ikey> yea i mean in theory its just "the Solus Software Center" with or without capitals
[12:22] <ikey> Most people (sadly) confuse it for gnome-software anyway
[12:22] <zyga-fedora> S^2C
[12:22] <Chipaca> I should change it to "the gnome software centre store"
[12:22] <ikey> oh "Discombobulation Station" was another suggestion
[12:22] <ogra_> zyga-fedora, now thats intuitive !
[12:22] <zyga-fedora> right
[12:22] <zyga-fedora> at least it's catchy
[12:23] <Chipaca> zyga-fedora: S²C FTW
[12:23] <zyga-fedora> now is that at a valid chemical?
[12:24] <Chipaca> zyga-fedora: or is that 2ⁿ edgy 2²ⁿ u?
[12:24] <ogra_> squaresulfurcarbon !
[12:25] <zyga-fedora> brilliant
[12:25] <zyga-fedora> is it toxic?
[12:26] <Chipaca> according to my googles S²C is "Smart Sollution Computer's" (2×sic)
[12:27] <Chipaca> ikey: "system destroyer"
[12:27] <ikey> oo
[12:27] <ikey> wait wait i got a real friendly cross-distro collab sounding one
[12:28] <ikey> "All Your SuSE Are Belong To Us"
[12:28] <Chipaca> ikey: I don't know if that's a breathless "ooh", or a noseless "o‸o"
[12:28] <ikey> nah was an ooh
[12:28] <Chipaca> ikey: "rootkit installer v7.337"
[12:29] <ikey> XD
[12:41] <zyga-fedora> my tests are timing out
[12:50] <Chipaca> niemeyer: good morning sah! does our discourse have checklists?
[12:59] <sergiusens> 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] <Chipaca> ogra_: cake
[13:10] <ogra_> does gustavo bake it himself ?
[13:10] <niemeyer> Chipaca: Sort of.. it has icons, and we can abuse them
[13:11] <niemeyer> Chipaca: Per roadmap and our review sprint boards
[13:19] <zyga-fedora> mvo: can you please land 3971, I think it's ready now
[13:21] <Chipaca> zyga-fedora: wrt night-rider, don't give me ideas
[13:21] <Chipaca> (or rather, don't reinforce ideas i'm struggling to ignore)
[13:22] <zyga-fedora> Chipaca: just think about what you could make if there were ansi escape codes for sound effects
[13:22] <Chipaca> zyga-fedora: there are!
[13:23] <Chipaca> zyga-fedora: beep + strings-of-nulls-as-delays
[13:23] <zyga-fedora> Chipaca: I know but those are limited and often disabled; think 8 bit sound :)
[13:32] <mup> PR snapd#3971 closed: interfaces/mount: make Change.Perform testable and test it <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3971>
[13:34] <zyga-fedora> \o/
[13:34] <zyga-fedora> thanks
[13:36] <zyga-fedora> and 4008 now looks easy to review
[13:36] <zyga-fedora> (and I'll add some spread tests for it)
[13:37]  * kalikiana time for a break, back in a bit
[13:41] <niemeyer> mvo: Release notes LGTM
[13:41] <mvo> ta
[13:42] <jdstrand> 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] <mup> PR #3872: preserve TMPDIR and HOSTALIASES across snap-confine invocation (LP: #1682308) <Created by mwhudson> <https://github.com/snapcore/snapd/pull/3872>
[13:42] <zyga-fedora> jdstrand: hello, thank you for the reviews!
[13:43] <jdstrand> 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] <jdstrand> zyga-fedora: hey-- feeling better?
[13:43] <zyga-fedora> jdstrand: meds make me feel better
[13:43] <jdstrand> well, that's astart
[13:43] <zyga-fedora> jdstrand: I think my rain-and-cold-o-meter is full for the year already
[13:43] <jdstrand> oh no!
[13:44] <jdstrand> you have at least a couple more days of that this year I'm sure
[13:44] <zyga-fedora> not unless I buy a one-way-ticket somewhere :-)
[13:45] <apol_> does anyone know what this snapd error means exactly? https://paste.kde.org/pdbxoeiqc
[13:46] <zyga-fedora> apol_: is squashfs loaded into the kernel? or maybe the .snap files got corrupted?
[13:48] <apol_> ah, wrong squashfs... SQUASHFS error: Filesystem uses "xz" compression. This is not supported
[13:48]  * apol_ looks into it further
[13:49] <zyga-fedora> looks like you need one kernel config option flipped
[13:49] <zyga-fedora> XZ support for squashfs is a separate knob
[13:50] <niemeyer> apol_: What distro is that?
[13:51] <niemeyer> mvo: Just added a topic link to the last entry in the notes
[13:51] <apol_> plasma mobile
[13:51] <niemeyer> mvo: Also fixed roadmap to reflect notes, and to push dates forward
[13:51] <mvo> niemeyer: thanks alot!
[13:52] <niemeyer> apol_: Who maintains its kernel?  We should get in touch to suggest enabling that upstream
[13:53] <apol_> yes yes, it's what we are doing
[13:53] <apol_> 5' it didn't have squashfs at all
[13:53] <apol_> 5' ago*
[13:57] <__chip__> niemeyer: didn't we have a list of all the things that needed to be enabled?
[13:58] <mvo> 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] <niemeyer> apol_: Oh, yay!
[13:58] <niemeyer> __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] <zyga-fedora> pstolowski: can you please re-look at 3965
[14:01] <pstolowski> zyga-fedora, yes, sorry, i was looking at it and got distracted. on it
[14:03] <zyga-fedora> no worries, thank you
[14:06] <zyga-fedora> now for that NFS + udp test
[14:11] <zyga-fedora> niemeyer: oh I know what that thing was
[14:11] <zyga-fedora> niemeyer: opensuse changed packaging rules for golang
[14:11] <zyga-fedora> niemeyer: (again)
[14:11] <zyga-fedora> niemeyer: and the new rules are ... go get :)
[14:11] <pstolowski> zyga-fedora, approved, but please add two extra checks to the test (see comment)
[14:11] <zyga-fedora> niemeyer: so I'm happy to not have to maintain any golang package in suse anymore
[14:11] <niemeyer> zyga-fedora: Nice!
[14:12] <zyga-fedora> niemeyer: we'll have to to some work to update our package
[14:12]  * kalikiana doing some pulling/ checking for red PRs
[14:12] <zyga-fedora> pstolowski: ack, will do
[14:16] <ondra> __chip__ hey
[14:16] <ondra> __chip__ if you build using snapcraft, it will already warn you about missing options
[14:17] <__chip__> apol_: ^ !
[14:17] <ondra> __chip__ also have look here https://github.com/snapcore/sample-kernels
[14:17] <__chip__> apol_: ^^
[14:17] <__chip__> ondra: awesome stuff
[14:17] <mup> PR snapd#3945 closed: snap: refactor cmdGet.Execute() <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3945>
[14:17] <ondra> that's usually good place to start
[14:20] <__chip__> apol_: you got that?
[14:33] <kalikiana> 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] <mup> PR snapcraft#1536: repo: implement :target suffix for package names <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1536>
[14:35] <kyrofa> Haha, kalikiana elopio is in high demand today, I'm having problems as well
[14:35] <kyrofa> He probably hasn't woken up yet
[14:35] <kalikiana> :-D
[14:36]  * kyrofa dives into our testing infrastructure because it's all black magic
[14:36] <kalikiana> 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] <ondra> __chip__ out of curiosity which hw are you trying to enable?
[14:37] <kyrofa> 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] <kyrofa> kalikiana, but yeah, this can also make failures easier to trace
[14:38] <kalikiana> 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] <kalikiana> Although it would seem odd for Travis' network to die during a test run?
[14:40] <elopio> It's raining sooo much. I'm trying to wake up now, but outside of the bed it's scary.
[14:41] <elopio> I'll check soon
[14:41] <ogra_> __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] <kalikiana> elopio: good morning ^_^ didn't mean to rush, mainly so I wouldn't forget to ping you later
[14:45] <kalikiana> kyrofa: would you feel like being the second reviewer here? https://github.com/snapcore/snapcraft/pull/1546
[14:45] <mup> PR snapcraft#1546: cli: update parts cache in the container <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1546>
[14:46] <ogra_> __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] <mvo> 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] <cachio> mvo, sure+
[14:46] <ogra_> though i'd always check generic first ... thats a great timesaver
[14:49] <mup> PR snapcraft#1592 opened: travis: run snapd tests only if not cron <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1592>
[14:51] <ackk> 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] <mvo> ackk: I think its fine to support $SNAP_{DATA,COMMON}
[14:53] <kalikiana> Oh, missed a q in there... I really wish sometimes top-level comments didn't exist separate from actual review comments...
[15:01] <zyga-fedora> jdstrand: will you have some time to look at 4008 today?
[15:01] <zyga-fedora> jdstrand: it's tiny (the actual new code) apart from tests
[15:02] <zyga-fedora> jdstrand: again I'm just interested in the approach taken, you can do the full review later
[15:02] <jdstrand> zyga-fedora: I think so. looking at https://github.com/snapcore/snapd/pull/3958 now
[15:02] <mup> PR #3958: many: add support for /home on NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/3958>
[15:03] <zyga-fedora> jdstrand: excellent, thank you
[15:03] <zyga-fedora> jdstrand: I've added a test for UDP, will push after it runs locally
[15:07] <mvo> 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] <tyhicks> mvo: any help pushing this along is much appreciated - thanks! :)
[15:08] <tyhicks> mvo: I'm currently working on the libseccomp and kernel SRUs to zesty and xenial
[15:09] <mvo> tyhicks: great, thanks for this!
[15:09] <tyhicks> no problem!
[15:24] <tyhicks> mvo: did you have an opinion on preprocessing? https://github.com/snapcore/snapd/pull/3998#discussion_r142661507
[15:24] <mup> PR #3998: snap-confine, snap-seccomp: Utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
[15:35] <elopio> kalikiana: your errors are connection problems on travis or the archive. I see no other solution than retrying.
[15:36] <elopio> kyrofa: which one is failing for you?
[15:36] <kyrofa> elopio, I re-ran it, I think it was network issues after comparing to other tests
[15:36] <kyrofa> elopio, the plugin integration tests, though. They take forever
[15:37] <kalikiana> 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] <elopio> kyrofa: yes, things like python are very very slow.
[15:38] <stgraber> 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] <elopio> 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] <kyrofa> elopio, I think I found a workaround (hack) for the long-running tests with no output: travis_wait
[15:39] <elopio> oh, nice. I didn't know about it.
[15:41] <elopio> kalikiana: well, it happens some times. If it persists, you can open a ticket in travis.
[15:42] <zyga-fedora> jdstrand: thank you!
[15:50] <nacc> 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] <nacc> 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] <nacc> sergiusens: --^
[15:50] <zyga-fedora> nacc: snapd will eventually support man pages, for now it's not something we have on the roadmap
[15:51] <sergiusens> 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] <sergiusens> I'd propose a forum topic though
[15:51] <nacc> well the file already exists :)
[15:51] <nacc> (/etc/manpath.config)
[15:51] <nacc> sergiusens: yeah yeah :)
[15:51] <sergiusens> nacc we can discuss all you want here, but as soon as the conversation is over it will be forgotten :-)
[15:52] <nacc> zyga-fedora: even for classic snaps?
[15:52] <sergiusens> nacc that should not make a difference
[15:52] <nacc> sergiusens: well, I would agree in principle
[15:52] <nacc> sergiusens: but I want to be sure
[15:52] <nacc> because my experience with classic so far has been painful :)
[15:53] <nacc> 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] <nacc> if that was the case, i thinkn our snap could be confined
[15:53] <zyga-fedora> nacc: in general
[15:53] <nacc> zyga-fedora: ok, thanks
[15:53] <mvo> tyhicks: I have a look at the pre-processing now, I had not really thought about it yet
[15:54] <nacc> 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] <nacc> I want something squarely between classic and confined, which I think basically every CLI wants
[15:54] <mvo> tyhicks: sounds sensible, I will do it
[15:56] <kyrofa> jdstrand, the password-manager-service interface doesn't seem to work for qtkeychain
[15:56] <tyhicks> mvo: thanks!
[15:59] <ppisati_> ogra_: yep, daily works fine
[15:59] <ppisati_> ogra_: thought i'm slightly confused
[15:59] <ogra_> ppisati_, thanks fo confirming
[15:59] <ppisati_> ogra_: http://pastebin.ubuntu.com/25680457/
[15:59] <ogra_> waiting for a proper fix from ondra though he first needs to get his dragonboard back to life
[15:59] <ppisati_> it says 'core' is @ 2973
[16:00] <ppisati_> and it's tracking edge, but edge is @ 3074
[16:00] <ogra_> freshed:   2017-09-20 04:30:03 +0000 UTC
[16:00] <ppisati_> ogra_: but you built it today
[16:00] <ppisati_> i mean,. it's a daily
[16:00] <ppisati_> uhm
[16:00] <ogra_> yeah, thats a bit strange ... admittedly
[16:01] <ppisati_> so it's a daily with a 2 weeks old core :D
[16:01] <ppisati_> it's a daylish :D
[16:01] <ogra_> ogra@dragonboard:~$ snap list core
[16:01] <ogra_> Name  Version                   Rev   Developer  Notes
[16:01] <ogra_> core  16-2.28.1+git405.377ffd6  3074  canonical  core
[16:01] <ogra_> my image got 3074
[16:01] <ppisati_> uhm
[16:01] <ppisati_> let me check if i flashed the correct img
[16:01] <ogra_> very strange
[16:02] <ogra_> note that my images get built in-house here ... i rarely downlooad them from people.c.c ... let me check, perhapsd the upload failed
[16:02] <ppisati_> ogra_: i downloaded the one from
[16:02] <ppisati_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ubuntu-core-16-dragonboard-410c.img.xz
[16:02] <ogra_> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/ is mine
[16:02] <ondra> ogra_ I will do fix and if somebody can test it
[16:03] <ppisati_> let me check the img i flashed
[16:03] <ppisati_> ogra_: indeed, i had an old .img laying around
[16:04] <ppisati_> never mind
[16:04] <ogra_> phew ... i was just comparing md5's :)
[16:14] <apol_> now I'm getting "snap-confine has elevated permissions and is not confined but should be. Refusing to continue to avoid permission escalation attacks"
[16:14] <apol_> is there a way to workaround this to test it runs to some extent?
[16:16] <jdstrand> kyrofa: do you have a snap that demonstrates the issue?
[16:16] <kyrofa> jdstrand, I do, although it's not in the store (it's someone else's) would a github link do?
[16:17] <kyrofa> Ah, I can wormhole it to you if you like
[16:17] <jdstrand> kyrofa: if it is easy enough to build, sure
[16:17] <jdstrand> either way
[16:17] <kyrofa> jdstrand, it's easy to build, but requires qt and whatnot so you'll probably want to do it in a container
[16:18]  * sergiusens takes a lunch break
[16:19] <sergiusens> nacc the problem with your interface idea is the underlying filesystem
[16:19] <jdstrand> kyrofa: if it can snapcraft cleanbuild, that's fine
[16:19] <sergiusens> but the 17.10 classic snap thread fixes should get you on track again
[16:19] <kyrofa> jdstrand, here you go: https://github.com/kyrofa/client_theming , the update_snapcraft branch
[16:19] <kyrofa> jdstrand, you need to cd into the linux/snap/ dir
[16:19] <kyrofa> But then yeah, should build fine
[16:21] <nacc> sergiusens: not sure I follow? I believe you, but I don't understand why the underlying filesystem type should matter?
[16:29] <jdstrand> kyrofa: it's dying: Issues while validating snapcraft.yaml: Specified icon '../../nextcloudtheme/theme/colored/Nextcloud-icon.svg' does not exist
[16:29] <kyrofa> jdstrand, ah, sorry, run from just the linux dir
[16:30] <elopio> sergiusens, kyrofa, kalikiana: so, let's hacktober https://community.ubuntu.com/t/hacktoberfest/278
[16:30] <jdstrand> kyrofa: $ snapcraft cleanbuild
[16:30] <jdstrand> Issues while validating snapcraft.yaml: Specified icon '../../nextcloudtheme/theme/colored/Nextcloud-icon.svg' does not exist
[16:30] <kyrofa> jdstrand, ah, fetch again and reset that branch
[16:31] <kyrofa> jdstrand, or cd into snap and build from there. There were some misunderstandings
[16:31] <kyrofa> elopio, excellent
[16:31] <jdstrand> kyrofa: it seems to be getting farther now
[16:32] <jdstrand> kyrofa: spoke too soon. trying in ./snap now
[16:33] <jdstrand> $ snapcraft cleanbuild
[16:33] <jdstrand> Issues while validating snapcraft.yaml: Specified icon '../nextcloudtheme/theme/colored/Nextcloud-icon.svg' does not exist
[16:33] <jdstrand> kyrofa: perhaps give me a working snap? :)
[16:33] <kalikiana> elopio: Sweet!
[16:33] <kyrofa> jdstrand, hahaha
[16:33] <kyrofa> jdstrand, stupid nested directories...
[16:33] <jdstrand> kyrofa: so, the previous failure was: subprocess.CalledProcessError: Command '['lxc', 'exec', 'local:snapcraft-slowly-first-gull', '--', 'sh', '-c', 'cd /root/build_nextcloud-client; snapcraft snap --output nextcloud-client_2.2.4+git_amd64.snap']' returned non-zero exit status 2.
[16:42] <kyrofa> jdstrand, here you go: http://people.canonical.com/~kyrofa/nextcloud-client_2.2.4+git_amd64.snap
[16:42] <jdstrand> kyrofa: thanks
[16:54] <zyga-fedora> apol_: snap-confine does not have an apparmor profile loaded
[16:54] <zyga-fedora> apol_: not sure which distribution yours is based upon
[16:57] <sergiusens> nacc in non classic, core is your underlying filesystem
[16:57] <kyrofa> What is stealing all my travis...
[16:57] <nacc> sergiusens: right, i can see why confined is not feasible
[16:57] <nacc> sergiusens: but for classic?
[16:58] <zyga-fedora> jdstrand: replied/updated the NFS PR
[16:59] <zyga-fedora> jdstrand: the only unanswered problem is the .real file, I wonder how to approach that one
[16:59]  * kyrofa wants to go cancel all of kalikiana's hogging PRs
[16:59] <sergiusens> nacc yeah, classic is just that, with enforcing libc and library loading from specific locations
[16:59] <zyga-fedora> jdstrand: it feels like a rat's nest of problems
[16:59] <sergiusens> kyrofa is there a way to cancel? if he is EOD, cancel and restart them before you EOD yourself
[17:00] <kalikiana> kyrofa: Noooooo. This is all because of New York. We were incontinently productive
[17:00] <kyrofa> sergiusens, well sure. I was kidding though, the tests are killing him :P
[17:00] <kyrofa> Hahaha
[17:00] <ogra_> incontinently ...
[17:00]  * ogra_ hands out dispes to the snapcaft team
[17:00] <ogra_> *diapers
[17:00] <ogra_> *sigh*
[17:00]  * ikey no longer wants nutella
[17:01] <kyrofa> ogra_, it's not as funny when you can't type
[17:01] <zyga-fedora> ikey: nutella is bad for you
[17:01] <ogra_> kyrofa, yeah, i trash alll my jokes with my typing :/
[17:01]  * sergiusens wonders where his suspend button went to in the latest ubuntu 17.10
[17:02] <kyrofa> sergiusens, it's called the lid
[17:02] <zyga-fedora> sergiusens: hold alt
[17:02] <sergiusens> kyrofa it is not suspending :-/
[17:02] <zyga-fedora> sergiusens: power turns to suspend
[17:02] <sergiusens> latest update did something weird
[17:02] <ikey> because discoverability. :P
[17:02] <zyga-fedora> sergiusens: at least for gnome vanilla
[17:02] <kyrofa> Maybe that's why. Ubuntu knows it's not possible :P
[17:02] <sergiusens> lol, it's an x1 carbon, working just 2 days ago
[17:03] <zyga-fedora> sergiusens: does it work if you do what I said?
[17:03] <kyrofa> zyga-fedora, you know if you used e.g. lounge you wouldn't need a million different nicks, right?
[17:03] <kalikiana> sergiusens: FYI still working a little bit, trying to get my PRs green, tho probably half an hour max
[17:03] <sergiusens> zyga-fedora I don't know how to convert the power, I don't have the power, "you've got the power"
[17:03] <ogra_> sergiusens, add water ...
[17:04] <zyga-fedora> kyrofa: longue?
[17:04] <kalikiana> Agathe Bauer?
[17:04] <kyrofa> ogra_, yeah, it would probably sleep then
[17:04] <ogra_> for a longish time
[17:04] <zyga-fedora> sergiusens: ah, sorry, click on the power icon in top-right, the menu will show up
[17:04] <sergiusens> zyga-fedora snap install thelounge --edge
[17:04] <zyga-fedora> sergiusens: then you have a trio of icons in the popup
[17:04] <sergiusens> will be in stable as soon as I have time to make setting up ssl easier
[17:04] <zyga-fedora> sergiusens: settings, lock and power off
[17:04] <zyga-fedora> sergiusens: if you hold alt the poweroff icon turns into suspend
[17:05] <sergiusens> zyga-fedora wow, why, why, why?
[17:05] <ogra_> so use friendly !
[17:05] <ogra_> *user
[17:05] <zyga-fedora> sergiusens: it's been like that for years in gnome 3
[17:05] <zyga-fedora> sergiusens: I read about this being done maybe over 2 years ago in a blog
[17:06] <zyga-fedora> sergiusens: I think the argument at the time was that mostly people just close the lid and this optimizes the UI but keeps the ability
[17:06] <zyga-fedora> sergiusens: you are welcome ;)
[17:06] <ogra_> it is like needing 10 clicks to switch to  a different wlan ... i'm sue they did a lot usability tests for that
[17:06] <sergiusens> in any case, I would remov shutdown and tell people to use the power button as there is an actual physical button for it on any device :-/
[17:06] <zyga-fedora> sergiusens: well
[17:06] <zyga-fedora> sergiusens: it usually suspends
[17:06] <zyga-fedora> (in windows)
[17:07] <zyga-fedora> sergiusens: so ironically.... it makes sense
[17:07] <sergiusens> the optimization should be the other way around...
[17:07] <zyga-fedora> sergiusens: power doesn't poweroff since windows 10
[17:07] <zyga-fedora> sergiusens: laptops suspend when you hit it
[17:07] <sergiusens> yeah, my TV suspends on power pressing too, as does my phone ;-)
[17:08] <sergiusens> the power button these days is relegated to turning the screen on and off (and some other innards) but not a cold power down :-)
[17:09] <sergiusens> zyga-fedora I still appreciate the tip, given that for some strange reason the lid event may not be coming through or doing the right thing
[17:10] <ppisati_> ogra_: FWIW, i can reconfirm the image is fine now
[17:10] <ppisati_> though i still can't get the bluetooth ctrl to show up with a custom kernel snap
[17:10] <ppisati_> :(
[17:11] <zyga-fedora> I'll get a coffee
[17:11] <zyga-fedora> sergiusens: so what happened to your surface?
[17:12] <zyga-fedora> sergiusens: try running opensuse or fedora on your device for a few weeks
[17:12] <zyga-fedora> sergiusens: I'd love to see broader support for snapcraft
[17:13] <kyrofa> sergiusens, I can't add any lounge users
[17:14] <kyrofa> Oh, sudo, duh
[17:14] <sergiusens> zyga-fedora I started to get a feeling of disgust of running desktop linux
[17:14] <sergiusens> zyga-fedora in the end, it seems good hardware support is all you need to like desktop linux ;-)
[17:15] <sergiusens> also, touch is a waste, nothing really works and I took the change that my wife needs to run some windows specific apps that crossover doesn't really support well so I did a swap
[17:15] <kyrofa> sergiusens, could you compare RAM usage to something like slack?
[17:15] <jdstrand> kyrofa: are there any special instructions for triggering the denial with this snap?
[17:16]  * zyga-fedora has a simple solution for the .real problem
[17:16] <kyrofa> jdstrand, right, so: it needs to be configured to point at Nextcloud (e.g. you can install the nextcloud snap for a quick test, then use http://localhost in the initial wizard)
[17:16] <jdstrand> kyrofa: this can all work in a vm?
[17:16] <kyrofa> jdstrand, after you give it auth info, quit it. Then run it again, and it'll complain about not being able to access the keyring
[17:16] <kyrofa> Yep
[17:16] <sergiusens> kyrofa oh, adding users requires a configuration change, `thelounge.lounge config` should open it in an editor, but currently I don't add one into the snap
[17:17] <sergiusens> kyrofa /var/snap/thelounge/current/home/config.js
[17:17] <kyrofa> sergiusens, actually it didn't, it seems you default to private
[17:17] <kyrofa> sergiusens, then `sudo thelounge.lounge add foo` worked
[17:17] <sergiusens> oh great, and you added users from the cli?
[17:17] <kyrofa> Yep
[17:18] <kyrofa> Works wonderfully
[17:18] <sergiusens> ah, great; yeah, cannot add users from the webui
[17:18] <kyrofa> Just needs a little spit and polish and SSL
[17:18] <kyrofa> sergiusens, that doesn't bother me. This is already a level beyond bouncers
[17:18] <kyrofa> sergiusens, go configure ZNC, THEN complain :P
[17:19] <sergiusens> I have, once and never again
[17:19] <kyrofa> Yep, me too. If the one I have in canonistack dies, I'm done with them :P
[17:19] <kyrofa> Hopefully it lasts long enough for me to switch over
[17:20] <kyrofa> sergiusens, but yeah, have you noticed any resource usage issues with it? Slack kills me
[17:20] <jdstrand> kyrofa: does the nextcloud snap need a lot of ram?
[17:21] <kyrofa> jdstrand, I've not tried constraining it dramatically. It runs on the rpi3
[17:21] <kyrofa> jdstrand, give it a gig or so, maybe?
[17:22] <kyrofa> jdstrand, note that it'll claim port 80, so make sure that doesn't clash
[17:25] <sergiusens> kyrofa totally unnoticeable
[17:25] <kyrofa> sergiusens, excellent
[17:31] <kyrofa> sergiusens, is there a reason you haven't moved it upstream?
[17:34] <kyrofa> sergiusens, also, talk to me about SSL. What is your vision? Do you want it on ports 80/443 by default?
[17:34] <kyrofa> Do you want a webserver in front?
[17:35]  * kalikiana wrapping up for today - kyrofa, sergiusens  enjoy your day off, see you on Tuesday!
[17:36] <kyrofa> kalikiana, alright man, have a good one
[17:44] <jdstrand> kyrofa: I don't see any security denials. I do see that it isn't able to find a keychain. do you see denials?
[17:46] <jdstrand> kyrofa: I did like you said: installed nexcloud, used firefox to set up the admin user. closed it. started the nextcloud client, logged in for first time (no denials), shut it down, started it again, no keychain. connected the interface, logged in, logged out, stopped/started, no keychain. no denials anywhere
[17:47] <kyrofa> jdstrand, huh... no. But when it's not snapped, it uses it just fine
[17:47] <kyrofa> jdstrand, I just tried in devmode and it doesn't work either. I don't know anything about the keyring stuff... is there something environmental about it?
[17:48] <kyrofa> jdstrand, by the way, I didn't thank you for this: I tested it this morning on another app and it works great
[17:48] <kyrofa> jdstrand, so thank you for that
[17:48] <jdstrand> yw
[17:50] <jdstrand> as for using it-- I don't know the qtstore bits. if I were to hazard a guess since it isn't working in devmode, I would guess a missing library or stage package. secret-service and kwallet are all dbus, so shouldn't have to do anything weird with paths
[17:50] <kyrofa> Maybe something with the XDG spec done by the desktop helpers...
[17:51] <kyrofa> jdstrand, from qtkeychain, this sounds fishy: "Linux/Unix: If running, GNOME Keyring is used, otherwise qtkeychain tries to use KWallet (via D-Bus), if available."
[17:51] <kyrofa> jdstrand, that sounds like it only uses dbus for kwallet, and uses gnome-keyring somehow differently
[17:51] <kyrofa> I'm taking a look at the code now
[17:53] <jdstrand> qtkeychain* - I've not specifically used this. I wrote the interface for libsecret, gnome-keyring consumers and kwallet. looking at https://github.com/frankosterfeld/qtkeychain I see files for libsecret and gnome-keyring
[17:54] <jdstrand> it would be weird for it to access the keyring files directly. I suspect that is just written weird
[17:56] <zyga-fedora> jdstrand: I updated the NFS branch, not sure if you have time for a 2nd look today
[17:56] <kyrofa> jdstrand, it seems that it's looking for a gnome-keyring.so
[17:56] <zyga-fedora> jdstrand: I'll work on testing the mkdir-before-mount branch tomorrow, after that we may look at fixing the content interface as niemeyer has discussed at the rally
[17:56] <kyrofa> jdstrand, which is not in the snap. Let me stage libgnome-keyring0 and see what happens
[17:57] <zyga-fedora> jdstrand: I'll probably spend some time on a overlayfs experiment I was discussing
[17:57] <zyga-fedora> jdstrand: I'll try to write my thoughts on the forum as well
[17:59] <kyrofa> jdstrand, if I used libsecret though, does that support both gnome-keyring as well as kwallet?
[17:59] <jdstrand> kyrofa: ah
[17:59] <kyrofa> jdstrand, it's loading everything at runtime, which explains why nothing is supported: nothing is staged, and it doesn't make it into the ELF so snapcraft doesn't grab it either
[17:59] <jdstrand> kyrofa: libsecret is a different dbus api. it is the modern one that freedesktop.org defined. gnome adopted it, some things in kde did
[18:00] <jdstrand> kyrofa: I think your question is about what to stage. you should stage all of them
[18:00] <zyga-fedora> for now I'll EOD - I need to put my laptop together
[18:01] <jdstrand> zyga-fedora: I've not gotten to your other request yet, so will do that first and then see what happens
[18:02] <kyrofa> jdstrand, indeed, this makes more sense now. If gnome-keyring.so is available, it supports gnome-keyring. If libsecret, it uses that. There is no .so for kwallet, so it uses dbus directly
[18:02] <zyga-fedora> jdstrand: thank you for your time :) no need to rush anything tonight
[18:02] <kyrofa> jdstrand, so sorry, this was not your problem to solve, but I appreciate the sanity checks :)
[18:03] <zyga-fedora> https://twitter.com/zygoon/status/916000719949455363
[18:03] <zyga-fedora> (I was working like that today)
[18:03] <jdstrand> kyrofa: sounds fine. I've not used qtkeychain before, so I thought it was yak (yet another keyring :)
[18:07] <kyrofa> jdstrand, success \o/
[18:07] <zyga-fedora> ooooh
[18:07] <zyga-fedora> darn
[18:07] <zyga-fedora> http://www.omgubuntu.co.uk/2017/10/lenovo-unwraps-25th-anniversary-thinkpad
[18:07] <zyga-fedora> distraction of the evening
[18:08] <jdstrand> kyrofa: ok, cool
[18:15] <sergiusens> kyrofa keep it simple, 443
[18:15] <sergiusens> kyrofa one of the reasons I use 443 and a webclient for that matter is easy access when at coffee shops
[18:15] <kyrofa> sergiusens, well, upon initial install there will be no cert
[18:15] <sergiusens> kyrofa right, no cert -> 80, setup cert -> 443
[18:16] <kyrofa> sergiusens, perfect
[18:16] <sergiusens> options to config to a different port should be fine, bt that is all doable from config.js
[18:16] <sergiusens> so I would keep it as human as possible
[18:16] <kyrofa> sergiusens, yeah I like it. Should be easy
[18:30] <sergiusens> kyrofa elopio so what is the deal with travis today?
[18:31] <kyrofa> sergiusens, we're hammering it
[18:31] <kyrofa> sergiusens, its network seems odd
[18:31] <sergiusens> why? I don't see anything green :-)
[18:32] <elopio> we can always run locally, if it's too much wait. The lxd setup makes sure that the results will be identical.
[18:32] <kyrofa> Lies! https://github.com/snapcore/snapcraft/pull/1591
[18:32] <mup> PR snapcraft#1591: snapd integration tests: print stdout/stderr <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1591>
[18:32] <kyrofa> But yeah, everything is taking longer than it should
[18:35] <kyrofa> nessita, is there a way to add someone as a collaborator to a snap that is registered but does not yet have any revisions?
[18:42] <kyrofa> sergiusens, also, thelounge: are you intending on moving it upstream or to snapcrafters, or maintain it yourself?
[19:01] <sergiusens> kyrofa upstream, as soon as all the niceties are in
[19:04] <kyrofa> sergiusens, slight complication: Let's Encrypt can work in essentially one of two ways for us: webroot mode, where it just assumes its acme challenges are available, or standalone mode, where it runs its own server on port 80
[19:08] <kyrofa> sergiusens, actually, nevermind. I think I worked out how to use standalone without needing to stop thelounge
[19:14] <kyrofa> sergiusens, given that they ship the example.css by default, you might want to consider leaving it alone when moving upstream. Or was there something broken with it?
[19:15] <sergiusens> kyrofa the other one is what is used in the demo server
[19:15] <kyrofa> Huh. Wonder why THAT one isn't the default, then
[19:16] <kyrofa> sergiusens, when you're able, can you take one last pass through https://github.com/CanonicalLtd/snappy-docs/pull/132 ? Should be good now
[19:16] <mup> PR CanonicalLtd/snappy-docs#132: languages: add ROS guide <Created by kyrofa> <https://github.com/CanonicalLtd/snappy-docs/pull/132>
[19:17] <mup> PR snapcraft#1592 closed: travis: run snapd tests only if not cron <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1592>
[19:24] <sergiusens> elopio mind taking a final look at snapcraft#1554 ?
[19:24] <mup> PR snapcraft#1554: store: handle revoked developers <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1554>
[19:26] <kyrofa> jdstrand, nowadays, if I chown root to root, will I get killed?
[20:14] <mup> PR snapcraft#1569 closed: tests: refactor the fake snapd to not hardcode values <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1569>
[20:16] <elopio> \o/
[20:16] <elopio> thanks for the merge
[20:17] <sergiusens> elopio hah, you are alive, do your reviews ;-)
[20:17] <elopio> sergiusens: you have a +1 already
[20:18] <sergiusens> ah, great!
[20:19] <sergiusens> elopio mind checking kyrofa's stderr/stdout PR?
[20:24] <elopio> the extra execution time is a disappointment there :( It kind of breaks my idea for the container tests.
[20:27] <elopio> Hello cratliff ! How was the trip back home?
[20:27] <kyrofa> elopio, I'm not convinced it's due to the test changes... everything seems to be slow today
[20:27] <kyrofa> I had to re-run the plugin tests and they took half as much time
[20:28] <elopio> kyrofa: can you give it a try locally with/without print?
[20:28] <kyrofa> elopio, I can re-run the snapd tests on that PR and see if the tighten back up if you like
[20:28] <cratliff> elopio, it was good.  I was pretty tired afterwards, but got some sleep later.  How was yours?
[20:28] <kyrofa> cratliff, haha, join the club
[20:29] <elopio> it was ok. It's good to be back home. There's a big storm and everything is terrible on the streets, but still it feels better than NY 😆
[20:34] <sergiusens> kyrofa about your scriptlet thing, it only adds a rule to copy over the launch file, is it assumed that the catkin_packages make their way to the snap with proper install rules already? If so, mind clarifying that?
[20:35] <kyrofa> sergiusens, yeah in the case of our example, all the install rules are correct. There are no pre-baked examples that are broken
[20:35] <kyrofa> sergiusens, so the addition of the install rule just copies over the top
[20:36] <kyrofa> sergiusens, can you clarify what needs clarification? :P
[20:36] <sergiusens> kyrofa the text text right before the example doesn't match the expectations of what I saw, mind amending the text to clarify that?
[20:36] <kyrofa> Ah, okay
[20:36] <sergiusens> kyrofa "the upstream ros application does not provide proper install rules" part of it
[20:37]  * sergiusens begins the trek to aikido
[20:41] <kyrofa> sergiusens, done. I made the example a bit more theoretical to avoid confusion
[20:42] <kyrofa> lewciie, what are you doing here?
[20:42] <lewciie> @kyrofa I'm always here! :)
[20:42] <nothal> lewciie: No such command!
[20:43] <kyrofa> Haha, I didn't know you guys actually used IRC
[20:43] <lewciie> we do, we're everywhere!
[20:55] <cratliff> elopia, is everything good at your house?  Not much damage or anything I hope.  Seeing some sun when getting home was nice.
[20:56] <jdstrand> kyrofa: that is allowed if you don't specify '-1' as an argument
[20:56] <jdstrand> kyrofa: -1 is something I'm working on
[20:56] <kyrofa> jdstrand, alright, thanks!
[20:58] <kyrofa> sergiusens, I'm a little nervous altering thelounge config when it's in a writable area. Do you intend for users to modify it (I assume so)? How should we deal with conflicts?
[21:02] <kyrofa> I'm starting to think maybe we do want a webserver in front to handle the HTTPS stuff
[21:03] <kyrofa> Then thelounge can just use a unix socket by default
[21:09] <cholcombe> sergiusens: i love the new github integration!
[21:16] <mup> PR snapd#3852 closed: hooks: commands for controlling own services from snapctl <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3852>
[21:38] <cholcombe> looks like the rust plugin doesn't know how to use workspaces in cargo
[23:09] <kyrofa> elopio, after all that work, the ros2 test that takes 15 minutes on my machine causes travis to run too long
[23:09] <kyrofa> elopio, so we need another solution
[23:10] <kyrofa> elopio, ideally I could say on the PR "this requires such and such long test to run" and CI would run it
[23:10] <kyrofa> elopio, also, travis_wait sucks. It masks ALL output
[23:11] <kyrofa> Runs everything in a subshell